#ubuntu-devel 2005-06-13
<Mithrandir> hm
<tseng> hi tollef.
<Mithrandir> we might want to upgrade emacs or backport something to it or something.
<Mithrandir> pasting utf8 from the character selector is broken.
<Mithrandir> hi tseng.
<lsuactiafner> man pages in console display wrong also
<Mithrandir> no, they don't
<Mithrandir> not if your locale is set correctly
<lsuactiafner>        be mounted, like /dev/cdrom or /dev/sdb7.  For NFS mounts one will  have  <host>:<dir>,  e.g.,  knuth.aeb.nl:/.
<lsuactiafner>        For procfs, use proc.
<lsuactiafner> might be that..
<Mithrandir> your terminal is probably not in utf8 mode.
<lsuactiafner> heh
<Mithrandir>        <host>:<dir>, e.g., knuth.aeb.nl:/.  For procfs, use proc.
<Mithrandir> lots of beautiful quotes there.
<lsuactiafner> how do i set it in bash/console?
<Mithrandir> in the console?  unicode_start should switch the console into utf8-mode
<lsuactiafner> tan unicode looks better
<lsuactiafner> i cant be bothered with moving my mouse, console is less effort
<lsuactiafner> is the devel and motu only for applicable discussions or is it ok to ask if marvell wireless cards are any good?
<trulux> tseng: good job made by those *hardened* guys ;)
<tseng> trulux: which?
<trulux> tseng: the bad, false and inaccurate marketing about myself ;)
<tseng> are we going to fight about this again?
<tseng> im sortof tired.
<trulux> tseng: no need, but this won't take long to get hard for those who were involved ;)
<tseng> im not sure what issue we are even on now
<tseng> but if you want to fight more people, I dont want to be part of it.. the last one was tiresome
<trulux> tseng: fight more people? No, I mean I don't like to see my conversation with a devrel guy being unresponsible published in public availability in a bugzilla bug full of false claims and other weird stuff that I might did when I was 11-12 and what I definitely didn't do
<tseng> trulux: gentoo devrel?
<trulux> tseng: yes
<tseng> im not sure how that is relevant to #u-d
<tseng> we dont have a devrel.
<trulux> tseng: you're as cinic as the others, if we need to discuss anything someday, let's /query.
<tseng> sure, but lets leave your problems with method, devrel or whatever else out of here please.
<trulux> tseng: sure, I've found a way of making this stuff both reliable and fun, and it's going to rock in the next years ;)
<tseng> -hardened?
<tseng> rock on.
<trulux> tseng: not that. reliable in economical terms ;)
<trulux> tseng: though that would rock too
<trulux> tseng: I just hope to keep the stuff strictly technical there and accurate
<trulux> tseng: sad how SSP died :)
<tseng> SSP upstream isnt as responsive as it could have been
<trulux> tseng: I'm not talking on that, I was working with others on defeating it, and double injection came to mind. the code might get available during the LSM 2005
<tseng> oh, you made a POC :(
<trulux> tseng: *we*, I was with migraines and only gave random bits and theory
<tseng> any fix?
<tseng> or its too critical
<trulux> tseng: can't be fixed
<trulux> tseng: certain archs could be non expoitable due to the conditions
<trulux> tseng: but those are not supported by SSP
<trulux> *evil grin*
<alexandros-se> Dear staff behind UBUNTU
<alexandros-se> I would like to talk about a future project with someone in priv.
<alexandros-se> Anyone?
<Jormundgand> ide-cd is broken for CyberDrive devices. I know people were looking at it beforehand, but will Ubuntu look to do anything?
<kent> alexandros-se, why in private?
<Jormundgand> Additionally, bugs 263198 and 260621 apply to versions of Firefox up to and including 1.0.4 - could the relevant source from the relevant build be backported to Ubuntu's build as a bugfix?
<alexandros-se> kent: we are starting a project and I would like to ask for permission of using ubuntu...
<kent> alexandros-se, Im not a lawyer, but I dont think you need permission to do that.
<alexandros-se> well it's under the project's name...
<alexandros-se> and I would like to talk about making huger amount of "shiping-orders" of ubuntu...
<Kathita> bvcbvcb
<Kathita> holaaa
<Keybuk> ...why, after my PC has been off for a few days, does it feel the need to spend ages running updatedb
<Keybuk> it was OFF!  the chances of any files moving is pretty slim <g>
<jsgotangco> hello
<Unfrgiven> jsgotangco: hey dude
<jgotangco> hey
<jgotangco> hmm
<Unfrgiven> hmmm?
<jgotangco> my other instance still isnt disconnecting
<Mez> hmm
<Mez> there's only 9 ubuntu members?
<bob2> mako has the official list
<jgotangco> if you're talking about the wiki list, that's incredibly outdated
<Mez> last edited 5 days ago :P
<tsume_> eww
<tsume_> cafuego is in #ubuntu, the #debian trolls are coming to #ubuntu
<bob2> cafuego is certainly not a troll
<wasabi> looks like they're coming to -devel.
<jsgotangco> ahh the edit is a self-addition then
<crimsun> tsume_: heh, cafuego has been a healthy member of the debian[-based]  distro community for ages
<whiprush> bob2 is my favorite #debian person.
<jsgotangco> whiprush, hey long time no see
<whiprush> hey
<whiprush> I've been idling
<jsgotangco> theres no rush
<mako> Mez: just because it was edited 5 days ago does mean it's not outdated
<mako> Mez: it just means someone edited an outdated list 5 days :)
<jsgotangco> heh
<jsgotangco> ahh mako you're still awake at this time
<bob2> mako is always awake
<whiprush> man I just scanned the #ubuntu logs.
<whiprush> that place is horrible.
<jsgotangco> tell me about i
<jsgotangco> t
<bob2> all user support channels are
<mako> jsgotangco: i spent all day in the park
<mako> jsgotangco: just got back
<jsgotangco> spending sunday at the park is one of my fave activities
<lamont> malloc: ../bash/dispose_cmd.c:322: assertion botched
<lamont> free: called with unallocated block argument
<lamont> ew.  bad bash
* Micksa pokes mjg59
<fabbione> morning
<tsume> crimsun: oh please, cafuego is a loose gun who loves banning people over stupid arguments
<tsume> crimsun: banning over personal disagreements is not healthy for a channel
<daniels> and stupid petty personal disagreements aren't healthy for a channel, either.  don't do it here.
<fabbione> daniels: do you have any idea for #3015 ?
<fabbione> daniels: if X is not using DRI because it's not supported on that card, i start to even doubt it's a kernel problem
<daniels> fabbione: if X isn't using DRI because it's unsupported on that card, then it can hardly be a DRI problem ...
<daniels> fabbione: getting them to try different kernels would be best, I suppose
<daniels> fabbione: i know of a problem in radeon drm that could theoretically cause hardlocks on newer cards, but we're not using that on r400, IIRC
<fabbione> daniels: DRI is the only X <-> kernel direct communication
<daniels> fabbione: right
<fabbione> daniels: at least that i know off
<daniels> fabbione: which means if DRI's not in use, then X isn't at fault at all :P
<daniels> but yeah, if we can narrow the problem down to 'this kernel works', 'this kernel's broken' and no X changes, then we've got something better to start from
<fabbione> X is always at fault :)
<daniels> haha
<daniels> i thought there were no X bugs
<daniels> (only GTK bugs)
<tsume> daniels: heh. I just really don't like a abusive op to be in a friendly channel
<Amaranth> tsume: I've never even seen him use his ops.
<daniels> tsume: 'abusive' is subjective.  if you have complaints about his behaviour here, feel free to bring them up, but I'm sick of disagreements from channels being dragged in here for no other reason than people don't like other people.
<Amaranth> tsume: me and bob2 ban more people than he does
<tsume> Amaranth: I have, there was even a incident which crawled all the way to the mailing list
<Amaranth> wait, he isn't even an op in #ubuntu
<Amaranth> so what's the big deal?
<tsume> Amaranth: because hes "there"
<Amaranth> tsume: We are not banning someone for no reason.
* desrt remembers cafuego from back in the day :)
<bob2> cafeuego is an op?
<tsume> Amaranth: I never said/wanted that
<Amaranth> tsume: he provides the ubuto bot and it nothing but helpful
<Amaranth> bob2: no
<bob2> so what on earth is tsume whinging about?
<Amaranth> err, ubotu
<Amaranth> bob2: Appearently the fact that he is in the channel at all has him pissed.
<tsume> Amaranth: big whoop. I could provide a dozen bots if asked
<bob2> tsume: if you have a problem with anything in particular, tell me or Amaranth 
<bob2> if you don't like him as a person, you're free to /ignore him
<daniels> 'he is there' is not a valid reason for banning someone who hasn't done anything bad towards ubuntu in the past, and that's all there is to it.  if you have anything specific in #ubuntu-devel or #ubuntu to complain about, feel free to do it, but for the time being, this pointless discussion is clogging up #ubuntu-devel, and I consider it ended here.
<Amaranth> What daniels said.
<bob2> amen
<bob2> daniels: ps tart o'clock
<tsume> daniels: "Amaranth: I never said/wanted that"
<Amaranth> xbase-clients isn't broken anymore, is it?
<daniels> nope
<tsume> what was the problem with it?
<Keybuk> meh, I hate brown paper bags :(
<fabbione> Keybuk: what did you do this time? :P
<Keybuk> dh_install can't rename things, so something ended up in a directory with the filename I wanted it to have
<fabbione> ah
<Keybuk> of course, this is a fucking difficult problem to undo :p
<Keybuk> so I'm going to hope very hard that this particular deb never sees the light of day
<fabbione> Keybuk: how long ago did you upload it ? and where? :)
<Keybuk> about 5 minutes, to Debian
<fabbione> oh you have plenty of time to upload the old one :)
<Keybuk> the fixed one :p
<Keybuk> of course, this gives away which package just got fucked up
<fabbione> Keybuk: if you uploaded only 5 minutes ago, there should be no packages built with it
<Keybuk> I haven't maintained libtool in a while ... <g>
<Keybuk> if that's what you thought I meant
<Amaranth> should we be thankful? :)
<pitti> Morning
<bob2> hey pitti 
<svenl> Kamion: you there ? 
<svenl> or elmo ?
<svenl> i wanted to investigate on the segfault issues you are seing on ppc buildds and which fabbione said you qualify as "normal" ?
<fabbione> svenl: there is a bug in bugzilla for it
<fabbione> https://bugzilla.ubuntu.com/show_bug.cgi?id=1596
<svenl> oh, cool.
<svenl> that bug report doesn't say much, and i suppose the comment from elmo means it also appears on debian's dual G4 buildds.
<fabbione> i start to believe it's a gcc problem
<fabbione> same kernel different gcc more segfaults
<svenl> if you find out, please tell me per mail. I will be mostly offline until friday. Going to the IBM power.org event in barcelona.
<svenl> not sure about connectivity.
<fabbione> i doubt i am going to spend too much time on it
<lifeless> anyone know if the 0000:02:01.2 0805: Ricoh Co Ltd: Unknown device 0822 (rev 17) has drivers under development ?
<bob2> memory card reader?
<lifeless> AFACT its the SD potion of the roch R5C552 which does have drivers
<lifeless> *ricoh*
<lifeless> bob2: yes, single chip firewire/SD 
<lifeless> the CF works fine, except for pmount/hal/gnome-volume-manager hating it
<pitti> lifeless: http://www.ubuntulinux.org/wiki/DebuggingRemovableDevices
<lifeless> pitti: thanks
<lifeless> pitti: so you would like me to run up those logs and file a bugzilla bug >
<lifeless> ?
<pitti> lifeless: yes, either that or just mail me
<lifeless> ok
<lifeless> will do 
<fabbione> elmo: can you please upgrade breezy{,-i386} on concordia?
<fabbione> (i need the new kernel-wedge)
<fabbione> meh
<fabbione> kernel-package
<daniels> so, in summary, yeah, that's a gnome bug -- file it on libgtk2.0-0
<daniels> preferably severity critical
<seb128> hey daniels 
<daniels> yo seb :)
<seb128> what are you trying to do to gtk again? :)
<daniels> nothing really, was just checking if you were watching IRC or whether it was too early
<seb128> ah ah
<Treenaks> daniels: RoboSeb128 vs RealSeb128 ?
<daniels> roboseb128 might explain the days where he uploads 50 new upstream versions of packages
<Treenaks> daniels: so would cloning
<seb128> elmo: could you fix libecal1.2-3 beeing universe instead of main? :)
<pitti> Hi seb128 
<seb128> hey pitti 
<seb128> grumpf
<seb128> lib/ephy-dbus.c:254: undefined reference to `dbus_connection_close'
<daniels> pitti: yo
<daniels> seb128: er?  that changed??
<seb128> I guess that's dbus_connection_disconnect () now ?
<daniels> god
<seb128> daniels: apparently
<seb128> /usr/include/dbus-1.0 has no mention to `dbus_connection_close'
<daniels> 'spose, yeah
<daniels> hold onhold on
<daniels> are you updating to a new upstream version?
<daniels> if so, iirc thom put in a patch to make ephy fine with the new dbus APIs into the last upstream version
<daniels> so you probably want to grab that
<seb128> hum
<seb128> I'm updating to 1.7.1 yep 
<seb128> and upstream code has stuff like
<seb128> #ifdef HAVE_NEW_DBUS
<seb128> 		dbus_connection_close (bus);
<seb128> #else
<seb128> 		dbus_connection_disconnect (bus);
<seb128> #endif
<seb128> 
<seb128> the issue is just this one beeing reversed apparently
<daniels> heh
<daniels> whoohoo! :)
<fabbione> Kamion: ping?
<seb128> daniels: the current package is using thom's patch
<fabbione> YAY for yet another ppc segfaults
<fabbione> infinity: can we add somekind of option to get ppc buildd's to build the kernel, but not to upload it?
<fabbione> or put it in @no_auto_build and process it manually?
<fabbione> i have to review the build logs before binaries upload
<fabbione> Trying patch debian/patches/06_translations.patch at level 0...1...2...failure. <- gksu
<fabbione> seb128: ^^
<seb128_> k, thanks
<seb128_> mvo: you broke gksu :)
* mvo blames gtk
<seb128_> roh
<seb128_> bad guy
<seb128_> gtk did the sync for you? :)
<fabbione> we need a better FTBFS notification
<seb128_> right
<pitti> debgtksync
<fabbione> and people to pre-build prio upload
<pitti> fabbione: elmo's testing environment should pick this up in the future
<seb128_> we need a FTFBS notification rather
<seb128_> there is no atm
<fabbione> seb128_: well a local build is not that expensive
<fabbione> at least one :)
<seb128_> I do local builds, but not pbuilder builds
<fabbione> seb128_: a local build would catch at least 90% of the problems like that one
<fabbione> a patch that doesn't apply is not really pbuilder/sbuild related
<seb128_> yeah, don't say that to me, I do local builds ... mvo did the sync :)
<fabbione> eheh
<mvo> I check it now
* infinity takes notes.
<mvo> I'm puzzled because I always testbuild/run the stuff
<infinity> Auto-FTBFS notification can be done, methinks.
<fabbione> infinity: is it possible to do the above???
<mvo> that would be cool!
<seb128_> would be nice
<fabbione> infinity: i mean the kernel stuff
<infinity> fabbione : build the ppc kernels without uploading?
<fabbione> infinity: yes
<infinity> fabbione : Not the way things currently work (unless I take a buildd offline and build manually)
<seb128_> sometime I notice 2 weeks after an upload when a guy say "how come than we don't have the new gnome-whatever"
<fabbione> infinity: what about @no_auto_build and build it manually?
<infinity> fabbione : The way things currently are, it would need to be uploaded to a seperate dist, so it didn't get autosigned and uploaded.
<fabbione> infinity: if the buildd are similar to davis i must see the logs before upload
<infinity> Log your own build output and grep for errors in debian/rules check :)
<fabbione> infinity: i just got a segfault that was not detected as fatal while building vmlinuz
<fabbione> infinity: the buildd would kill something like that
<fabbione> infinity: > 150 minutes
<infinity> Not if you tee it to the log and stdout.
<fabbione> infinity: is buildd hw the same as davis?
<infinity> I'm all for more autobuilding, not less.  Anything we need to by hand, we need to ask "why?"
<fabbione> i am really not sure if it is hw or gcc related
<infinity> The PPC buildds do segfault occasionally, yes.
<fabbione> infinity: oh but i am not asking for a permanent solution
<fabbione> infinity: i just want one or two checks
<fabbione> then it can go by itself again
<fabbione> (given that it works...)
<fabbione> infinity: i know about the random segfaults
<infinity> Not sure what kind of machine davis is, but the buildds are all G5 XServes.
<fabbione> but here we are talking about an average of 8 to 10 on a single kernel build run
<fabbione> infinity: they are the same :/
<infinity> Looks like it, yes.
<infinity> seb128, mvo : How would you guys like to see Auto-FTBFS stuff?... I can't very well aim at the Changed-By address, as it's not always correct, and for autosyncs it would break miserably.
<infinity> I could have elmo set up a specific list you could track, or I could auto-file bugs.
<infinity> I don't like autofiling bugs, though.
<mvo> infinity: is there a way to detect autosyncs and not send a mail to the changed-by address in that case (and send one in all other cases)?
<infinity> Well, in theory, unless elmo changes it, all autosyncs are Changed-By katie@jackass.
<infinity> Relying on that feels fragile, though. :)
<pitti> elmo: please sync postgresql-{7.4,8.0,common} from experimental and postgresql from Debian/incoming; this also needs some NEW love. TIA
<pitti> phear your databases
<infinity> mvo : I'll think of something.
<mvo> infinity: cool, thanks!
<infinity> mvo : I'll bounce them off a list to start with, just to make sure the output is sane, then we'll see if we can detect appropriate people (uploaders, or whatever) to CC.
<fabbione> infinity: well i will upload and see...
<fabbione> infinity: davis is segfaultorama
<infinity> I blame the kernel team.
<fabbione> i blame gcc
<fabbione> it was not that bad with the old gcc
<fabbione> i am dead serious
<infinity> Have you tested identical builds with gcc-3.3, and with older glibc, and, and?
<fabbione> infinity: yes. i always do a test build run before upload
<fabbione> infinity: i was getting a random kill once very 10/12 builds?
<fabbione> now we are at 10 kills per build
<fabbione> almost 100 times more
<infinity> Lovely. :/
<koke> hi all!
<pitti> Hi koke
<infinity> fabbione : Want to toss the sources my way, and I'll spin them on some drastically different hardware?
<infinity> fabbione : Different kernel too, but otherwise, it'd be current breezy.
<fabbione> infinity: it's on the way to jackass now
<koke> mvo: I'd like to work on FindingPackages :)
<fabbione> infinity: so you can just grab it as soon as it's in the archive
<koke> and let google to pay me...
<infinity> fabbione : Alright, I'll spin them on my machine and give you the build log.
<pitti> infinity: btw, can you do syncs?
<infinity> fabbione : If it's userspace, it should break the same.  If it's hardware or kernel, my machine might be fine.
<infinity> pitti : Nope.
<fabbione> infinity: i hope you have an idea on how long it will take :)
<infinity> fabbione : <shrug>... I can leave it overnight.  I don't much care. :)
<mvo> koke: that sounds good 
<fabbione> infinity: you will still need to try to build a few times
<infinity> fabbione : No problem, I can loop it. :)
<fabbione> infinity: it's not 100% predictable
<fabbione> infinity: and if it builds.. the next step would be to install elmo's kernel on your box
<fabbione> infinity: if it builds.. than it's the hardware :)
<infinity> fabbione : Yup.
<fabbione> infinity: also try the stock kernel would be useful
<infinity> (My kernel is a pure upstram 2.6.11.11 with no patches and a very barebones .config)
<infinity> Which is a luxury I have due to havient seriously ancient hardware.
<fabbione> infinity: elmo does build his own
<infinity> s/havient/having/  <stares at his fingers>
<fabbione> ok
<elmo> fabbione: it's your source, just a custom config, FWIW
<fabbione> elmo: i know.. but a change in the config can make a big difference :)
<fabbione> elmo: i am not blaming it on you.. i am just analysing all the options given that davis has been segfaultorama since yesterday and it's having some I/O problems
<infinity> Oh, hey.  Look at the time.  I'm in volunteer mode now.
* infinity trades hats.
<fabbione> infinity: ehhehe
<infinity> fabbione : How many images does this current source build?
<fabbione> infinity: 8
<infinity> Joy.
<fabbione> infinity: hell of a lot :)
<fabbione> infinity: i just added ppc64 :)
<infinity> Is all the biarch stuff in current breezy now?
<fabbione> elmo: the new kernel will need some NEW love
<fabbione> infinity: yes
<infinity> I don't need any hand-built packages?
<infinity> Oh, good.
<fabbione> infinity: just satisfy the build-dep and you are done ;)
<infinity> Huzzah.
<fabbione>  linux-image-2.6.12-1-powerpc64-smp - Linux kernel image for version 2.6.12 on PowerPC 64 SMP.
<fabbione>  linux-image-2.6.12-1-iseries-smp - Linux kernel image for version 2.6.12 on PowerPC iSeries SMP.
<daniels> \o/
<fabbione> but for now we have udebs only for ppc64
<fabbione> not the iseries
<elmo> why iseries and powerpc64?
<fabbione> elmo: ppc64 will replace power3 and power4. iseries needs to be special cased
<infinity> Because ppc64 is generic (Macintosh G5, pSeries), iSeries is specific to iSeries machines.
<fabbione> elmo: but since i can't test anything of the above direclty.. i didn't want to kill power3 and power4 in the first run
<infinity> svenl suggest pseries/iseries, but Kamion and I both asked "then what do I install on my Apple?"
<elmo> never mind kernel image names, we need to fix that stuff in yaboot
<fabbione> elmo: for curiosity, when an arch builds some new binaries and they need NEW love... is the entire set of binaries placed on hold or only the new ones?
<fabbione> (like in the kernel case)
<elmo> fabbione: the whole thing
<infinity> The whole .changes.
<elmo> katie deals in units of whole uploads
<fabbione> elmo: great! please don't NEW ppc if it builds
<fabbione> i will ping you back after checking the logs
<fabbione> i386 can be newed
<infinity> (You realise he probably already added the overrides while we were talking)
<infinity> (Just to irritate you)
<fabbione> (dude.... i know elmo is a machine.. but i still have hope he can temporary revert it ;))
<elmo> I figure jackass could use some diskspace before I deal with NEW etc.
<fabbione> elmo: ehhehe
* fabbione hands ddraid and clvm to elmo
<koke> mvo: do you know how to fix https://savannah.nongnu.org/bugs/?func=detailitem&item_id=13306 ??
<koke> I tried to run gnome-app-install as user and only synaptic as root
<koke> but then I can't pass the selections to synaptic :(
<mvo> koke: it's pretty hard to fix it in gksu, a better way is probalby to add ---set-selection-file in synaptic
<seb128> elmo: around?
<mvo> koke: it's pretty hard to fix it in gksu, a better way is probalby to add ---set-selection-file in synaptic
<mjg59> Uh. Can anyone actually run gok in Hoary?
* mjg59 gets two free() invalid pointer errors, and then a floating point exception
<daniels> mjg59: gok works fine, gdk breaks
<daniels> er, gdb
<mjg59> I'm just typing "gok"
<mjg59> Oh. Now I get "Could not locate registry, aborting"
<mjg59> Which means at-spi isn't running
<seb128> elmo: have you fixed libecal1.2-3 beeing universe? 
<koke> mvo: yep, but gksu should pass the stdin to the child proccess, IMO
<jordi> pitti: hello!
<mvo> koke: yes. I talked to kov (upstream of gksu) about it and he told me that it's not easy to do (I haven't looked myself)
<jordi> pitti: in case you haven't noticed yet, 1.0.9 incoming
<pitti> yay
<jordi> pitti: jdthood and I are looking at the set-default-card stuff
<jordi> pitti: do you think that should go in Debian mroe or less as it is?
<mjg59> 800MHz Celerons = teh suck
<pitti> jordi: that probably depends on whether you want to depend on python 
<pitti> jordi: we don't need in Ubuntu since we have python-minimal
<pitti> jordi: I sent the stuff to gnome upstream, they are looking at it, too
<pitti> jordi: maybe they reimplement it in C, or something
<jordi> pitti: nod.
<jordi> pitti: I dunno, I sense debian will get that python-minimal stuff too
<pitti> jordi: that would really rock
<koke> mvo: maybe patching sudo to have a --password-fd option...
<jordi> doko: do you know if there has been talk of that for etch?
<allee> mjg59: I looked at keycodes of external USB keyboard (Dell).  Nothing (kernlog, xev).  Any other tools to 'debug' this?
<mjg59> allee: Oh. With USB, i'm not sure
<mvo> ping doko 
<doko> jordi: "that" is what?
<doko> mvo: pong
<mvo> koke: could be a option but it would be hard to get that into all distros that gksu supports
<allee> mjg59: ah and evbug shows nothing too.  I'll try to borrow some Logitech keyb.  and see if it's a 'general' problem.
<allee> mjg59: n.p.
<jordi> doko: Debian having python-minimal in base
<doko> I'll upload -minimal, but I don't know, if it will arrive in -base ...
<jordi> how big is minimal?
<jordi> doko: we're discussing adding the Ubuntu alsa python stuff in the Debian packages, but that makes us depend on python. If that's gong to hapen in a reasonable timeframe, we might want to wait for -minimal maybe
<doko> jordi: 700k, 2MB installed
<pitti> jordi: if not, rewriting it in perl is not a biggie
<doko> pitti: you're nasty ...
<jordi> i'd prefer not to do that :)
<pitti> doko: no, I'm realistic
<pitti> doko: I'm not going to write it in C, if you or jordi wants to, that's fine for me :-)
<mdke> mjg59, would you give me some advice on laptop-related issues? Not to worry if you're busy atm
<jordi> I think it's reasonable to think python will make it in base for etch
<jordi> pi	that would make 
<jordi> alsa-base arh any, I think that's not cool.
<jordi> damn arch any
<mjg59> mdke: Sure
<mdke> mjg59, thanks, is /query ok?
<mjg59> mdke: Yeah
<bob2> mjg59: what data should someone send in with a "the wifi kill sswitch on my laptop doesn't work on linux" bug?
<mjg59> bob2: What sort of laptop they have
<bob2> mjg59: that's all? no dsdt/etc?
<mjg59> bob2: For now, yeah
<bob2> mjg59: 'k
<bob2> mjg59: on "linux"?
* #ubuntu-devel  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
(Nafallo/#ubuntu-devel) zul: sync rt2500 cvs, kthanxbai :-)
<Riddell> lamont: I've added hppa as an architecture to kubuntu-desktop (you might want to check it to ensure I did it properly)
<Kamion> elmo: please sync perl and libgetargs-long-perl
<Kamion> elmo: (perl from experimental)
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Ubuntu 5.04 is released! | MOM is awake! | Colony CD 1 released | gcc4 transition finished, breezy probably well broken, uploads of C++ packages in universe restricted || don't use ppc64 kernels yet. wait for the next release kthxbye.
<Keybuk> Kamion: was to experimental anyway
<Kamion> Keybuk: well, either
<seb128> Keybuk: can I use hct to repackage gdm now? 
<Keybuk> why, did you break something?
<Keybuk> seb128: no, cause gdm won't import :(  haven't had time to work out why yet
<Kamion> Keybuk: it's goodness, not breakage
<seb128> no, but when I asked like 2-3 weeks ago you said gdm is no imported yet
<fabbione> probably Keybuk means: "why.. do you need to break something?"
<Keybuk> seb128: the first was to Kamion
<seb128> oh, k :)
<seb128> Keybuk: any idea if that's going to be fixed soon?
<Keybuk> it's on my list of things to look at
<seb128> in the bottom of 478 other items? :p
<Keybuk> nah, import problems are near the top
<seb128> k, thanks
<jordi> seb128: you're going to use the cdbs packaging we have in ubuntu?
<jordi> lucky
<seb128> jordi: yep, that's the plan
<doko> Kamion, elmo: please move lib32z1 and lib32z1-dev to main
<ogra> mjg59, thom, ping
<tseng> hi ogra!
<ogra> hey tseng 
<ogra> tseng, why isnt monodevelop available for me ? it builds fine in my pbuilder....and works great too
<tseng> ogra: ill look for the log. maybe the arch isnt set right
<tseng> yep
<ogra> ah, ok
<tseng> we need to add amd64 to it
<tseng> i have stuff building up to do..
<tseng> until my key is moved for main and i can fix mono on ppc
<tseng> i dont want to upload a bunch of stuff that will just ftbfs on ppc
<ogra> ah, ok
<jane_> is the warthogs wiki down?
<bob2> JaneW: wfm!
<JaneW> bob2: sorry wrong # and huh?
<tseng> "works for me"
<bob2> JaneW: works for me.
<JaneW> bob2: oic, ta...
<JaneW> hmm I can send and receive mail and IRC, but not browse the web
<bob2> it's a No-Work-Monday!
<\sh> right
<tseng> those are the best kind.
<\sh> g'afternoon btw
<ogra> bob2, where ? 
<bob2> ogra: only in capetown, sadly
<Simira> US and au, I think?
<ogra> oh
<bob2> ogra: unless your intarweb is broken, too
<ogra> heh..
<Nafallo> Sweden is no-work to :-)
<ogra> or youre in .de
<Nafallo> as in. everything is closed :-P.
<bob2> next monday is an actual public holiday here
<Simira> we have no public holidays until christmas or something now, I think
<Simira> JaneW: troublesome connection today?
<zul> we have like one everymonth
<Nafallo> zul: you saw my message earlier? :-)
<zul> Nafallo: yes i wont be able to do it today because ill be out most of the day
<Nafallo> zul: they have fixed connection to aps without essid :-)
<Nafallo> zul: ahh, oki. I should have pinged you yesterday I guess ;-)
<mjg59> ogra: Hi
<ogra> mjg59, the power manager is packaged so far here... i'm pondering to upload it, since it doesnt do anything useful yet
<mjg59> ogra: Heh. Upload it to universe to make it easier to hack on?
<ogra> it sends out dbus messages that nobody recieves yet... i guess we need a listener daemon or something similar
<bob2> nifty
<tseng> i think if we make every component of the desktop depend on d-bus for no reason
<tseng> there will be no more hunger
<tseng> and hunger is bad.
<thom> tseng: that was a very rob love comment
<lamont> Riddell: won't make much difference until arts stops ICEing, but thanks
* lamont goes to get ready and head to the office
<`anthony> bob2: ah yes, the one day a year where all australians are happy to have the monarchy still...
<bob2> `anthony: we'll totally replace it with Drink To The Republic Day when we kick her out
<`anthony> sure, we have a foreign descendant of a family of inbreeds as our head of state, but! long weekend! long weekend!
<thom> bob2: pfft, the country will fall apart before you get a chance to
<`anthony> bob2: Viva La Revolution!
<bob2> thom: hey, the Falklands did just fine without the queen.
<`anthony> bob2: aside from that little invasion issue.
<`anthony> fortunately, maggie's not in power any more, so Australia could probably become a republic without the threat of invasion now.
<thom> bob2: better start brushing up on your spanish then
<Riddell> lamont: what's the issue with arts and ICE?
<lamont> Riddell: arts is ftbfs: gcc- internal compiler error (ICE)
<lamont> ICE!=ice :)
<lamont> I need to reduce that down to a test case, and then file a gcc-bug
<`anthony> so gcc4 not quite ready for primetime then?
<tseng> `anthony: seems to be something like 90%
<ogra> `anthony, only for c++ ... but who uses c++ software anyway ;) 
<`anthony> only stinky hippies.
<Kamion> C++ seems more designed for suits than hippies :)
<ogra> `anthony, nope, i'm using gnome here *g*
<tseng> some kid in here the other day told me we'd better rewrite beagle in C++
<Mithrandir> Kamion: with all that crack?
<Kamion> Mithrandir: good point
<ogra> tseng, at least the dependencys would match then ;)
* tseng hides.
<ogra> heh
<tseng> stupid monodis
<ogra> yep
<tseng> upstream is working on a similar tool to dh_cli that they use for rpms
<tseng> not sure if it will be better or worse
<jbailey> Kamion: I would *not* trust a suit with the type of machinery that is c++. =)
<ogra> jbailey, come on, as long as he carrys his clipboard and stopwatch with him ....
<winkle> hm, 404 on libxml-libxml-common-perl_0.13-5_i386.deb and libxml-libxml-perl_1.58-0.3_i386.deb on hoary
<winkle> xmltv uninstallable
<tseng> 404?
<tseng> hm.
<winkle> not found in archive
<tseng> is that from security?
<tseng> the archive has 1.56
<trulux> lalala
<winkle> hm and 0.13-4
<trulux> pitti: ping
<pitti> trulux: pong
<trulux> pitti: I will receive the patch for the fs capabilities stuff from a fellow hopefully today
<pitti> nice
<trulux> pitti: for the pid randomization stuff I'll need to know if it should be enabled by default
* trulux thinks that sysctl's for such thing are nothing but useless
<pitti> trulux: yes, why not
<trulux> pitti: OK, will do right now
<pitti> trulux: since the modules will not be loaded by default for now, the good stuff should be on if they are loaded
<pitti> trulux: if everything works, we could make them loaded by default, but we have to test it thoroughly first
<trulux> pitti: PIDs randomization can't be implemented as module
<pitti> trulux: I thought you can use LSM for everything?
<pitti> trulux: btw, that's #u-h stuff :-)
<trulux> pitti: OK, let's get it there :)
<trulux> pitti: PIDs are managed by the kenrel task scheduler, etc
<trulux> pitti: LSM has no access to the point where the pid gets initialized
<trulux> pitti: that's init stuff (check child_reaper)
<fabbione> elmo, lamont, infinity: what's the status with the last kernel upload for i386/ppc build? 
<doko> elmo: please could you update the breezy chroot on concordia (just apt-get update)?
* dilinger starts upgrading desktop machines to hoary, to test it out (finally)
<elmo> doko: already done
<elmo> Kamion/pitti/seb128: done
<doko> elmo: thanks
<pitti> elmo: thanks; I'll upload a new psql 8.0 shortly, had to fix some things
<elmo> fabbione: i386's still building, which means ppc probably is too
<fabbione> elmo: ok thanks
<fabbione> elmo: we have a working ppc64 kernel now.. (not the one in the archive)
<fabbione> elmo: should we give it a spin on davis?
<elmo> fabbione: will it "just build" with an-up-todate breezy chroot, if I want to build my own?
<pitti> elmo: will new versions uploaded to experimental be automatically synced?
<elmo> pitti: no, sorry
<seb128> elmo: thanks
<elmo> pitti: syncing from experimental's easy tho, just ping me
<fabbione> elmo: yes. the sources are in my home on davis, but i would love if you can also test the stock kernel
<pitti> elmo: alright, thanks
<elmo> fabbione: hmm, ok.  can't right now (there's an IBM engineer in the way), but will do while I'm down here
<fabbione> elmo: specially because the config is tweaked to actually work :)
<pitti> yay, new PostgreSQL in Breezy
<fabbione> elmo: sure.. no problem. i have no rush
<Treenaks> pitti: \o/
<Treenaks> pitti: could you send me the list of affected universe packages again, so I can test-build/upload them this week?
<pitti> Treenaks: sure, I'll followup to -devel shortly with some instructions and patch pointers
<pitti> Treenaks: I prepared most of the main patches already
<pitti> Hi stub 
<stub> hi
<Treenaks> pitti: cool
<pitti> stub: psql 8 is in breezy :-)
<stub> pitti: Cool. I'll tell elmo to upgrade emperor tomorrow.
<pitti> erm...
* elmo stabs stub in the face
<pitti> stub: however, testing highly appreciated (on non-production machines *hehe*)
<pitti> elmo: please sync postgresql-8.0 from debian/incoming
<whiprush> mako: it ends up that JohnDong lives like 5 minutes from where I work, we'll sign his key and assimilate him into the LoCo.
<ogra> whiprush, yeah
<whiprush> heh, had I known this I could have worked on him for 2 release cycles to become an motu.
<whiprush> perhaps I can find new ways to motivate him. :)
<ogra> whiprush, go ahead, i'm also working on his MOTUness ;)
<ogra> whiprush, he wants (and we too.... somehow) to have the backports in an official archive... so he wont get around becoming a MOTU for uploading ;)
<ogra> seb128, ping
<seb128> pong
<ogra> seb128, seems we need to tighten the dependencys for serpentine a bit....
<ogra> seb128, https://developer.berlios.de/bugs/?func=detailbug&bug_id=3939&group_id=3081
<mako> whiprush: awesome :)
<seb128> not a surprise
<ogra> the older hal seems to miss a handful of settings...
<ogra> seb128, and second ping.... do i find gnome-about-me in the cvs already ?
* mako just scored an air conditioner for USD$10
<Clint> does it have freon?
<mako> Clint: quite probably
<Clint> good deal
<whiprush> ogra: I read the meeting log. I'll work on him seeing the light. He's just young.
<mako> Clint: once i helped a friend install a freon-powered boat-horn into his honda prelude
<mako> it sounded like a barge
<mako> didn't want to cut him off in a tunnel
<dilinger> mako: heh, had you asked a year ago, i could've given you 3 free a/cs
<ogra> whiprush, great, all Uvelopers will owe you something for that :)
<mako> dilinger: last night i had trouble sleeping.. craigslist had one for $10 :) the cab to get it home will cost twice than i think
<dilinger> mako: my roommate and i ended up w/ 5 a/cs somehow; we lived on the 3rd floor, so we ended up leaving 3 when we moved.  damned things are so heavy :)
<mako> yeah, getting this upstairs is gonna be fun
<Clint> you could have just used gravity to get them down
<mako> Clint: david nusinow?
<mako> he's kinda shrimpy
<seb128> ogra: serpentine use the n-c-b 2.10 or 2.11 API?
<seb128> ogra: gnome-about-me is for like 6 months on the CVS
<seb128> but I don't think it's usuable
<ogra> seb128, good question, ill find it out
<mako> the owners claim it can be good as new with a little bit of cardboard :)
<mako> (it is $10 after all)
<Clint> cardboard in place of what?
<ogra> seb128, we need something to change the password and its required for http://udu.wiki.ubuntu.com/DotUbuntuRegistrationClient it seems....
<mako> Clint: the little fit-it-to-the-window-wings
<mako> or one of them
<ogra> seb128, there is a bounty for it, do you know anyone we could push that to ?
<mako> Clint: evidently, the frmae for the wing is there, but the flexible fabric stuff is gone
<seb128> ogra: no
<ogra> hmm, sad
<Clint> ahh
<pitti> Hi lamont__ 
<lamont__> morning pitti
<seb128> lamont_r: is evolution waiting for something?
<lamont_r> was dep-wait-ish... checking
<lamont_r>   evolution-data-server-dev: Depends: libedata-cal1.2-dev (= 1.3.2-0ubuntu1) but t is not going to be installed
<lamont_r> *4
<seb128> that should be fixed, no?
<seb128> pool/main/e/evolution-data-server/libecal1.2-3_1.3.2-0ubuntu1_i386.deb
* lamont_r gives it back again - that didn't help it yesterday, though....
<seb128> elmo fixed that like 1 hour ago
<seb128> it was universe due to soname change
<lamont_r> ah, ok
<seb128> the buildd doesn't detect such changes?
<seb128> universe to main move I mean
<lamont_r> the issue is more basic than that...
<lamont_r> if the failure is that a build-dep can't be found, or a newer version is explicitly specified, then it catches it just fine (and the package being in universe causes it to retry every cron.daily run, which is yet a different bug)
<lamont_r> if the failure is that foo Build-Depends bar, but bar is _uninistallable_, then I get a failure message, and manual intervention is required.
<lamont_r> on good days, I can dep-wait it on something.  On bad days, I can't, or haven't.
<seb128> I see
<seb128> thanks
<lamont_r> (basically, the auto-dep-waiter handles the first, but not the second case)
<lamont_r> likewise, if the package Build-Depends on a virtual package, then I eventually have to clear the dep-wait manually, since w-b doesn't deal with virtual packages. :-(
<lamont_r> I hate virtual package deps...
<lamont_r> ] 
<seb128> he he
<mvo> ping mdz
<Mithrandir> hmm, what's the tool used for building rsyncable CD images used on i386 called again?
<Kamion> partimage
<Mithrandir> ah, thanks.
<{Seb}> hey all
<{Seb}> is xorg fixed?
<{Seb}> thing in topic has gone!
<mdz> mvo: pong
<dooglus> {Seb}: it's OK here
<{Seb}> yey!
<{Seb}> i can upgrade to breezy now and get inotify
<dooglus> {Seb}: GNOME doesn't want to start for me unless I kill esd a few times, but other than that...
<dooglus> {Seb}: apt-cache search inotify didn't give me any outp...  oh well.
<doko> Kamion: is there a way to determine all binaries in an archive, which are not built by a source package anymore?
<Kamion> doko: one of the tools in the katie suite does that, namely rene
<Kamion> any particular thing you're interested in?
<doko> yes, find out all source packages, which have binaries depending on libstdc++5, but don't consider binaries without recent sources
<doko> Kamion, I assume rene runs on the archive machine only?
<Kamion> yes
<doko> :-(
<Kamion> currently the list is hamlib3++, icomlib1, libinti-gl1, libinti-sourceview1, libinventor0c102, liblog4cpp1c102, libpgtcl, libpgtcl-dev, python2.3-kde3
<doko> not more? that's not much
<doko> anyway, thanks
<Kamion> no, not more
<SloMo_> Amaranth: any news with smeg?
<Amaranth> SloMo_: sorry, no
<Amaranth> SloMo_: it's on my todo list for today, if i wake up :)
<Kamion> doko: lib32z1, lib32z1-dev moved to main
<fabbione> elmo: can you please NEW the ppc kernel?
<fabbione> elmo: i am happy with the build. davis needs love. kthxbye
<fabbione> ;)
<elmo> done
<mako> mdz: hey dude.. 
<fabbione> elmo: thanks :)
<{Seb}> hi all
<{Seb}> which kernel in breezy has inotify
<{Seb}> 2.6.11 or 2.6.12?
<mako> mdz: verdict on the ul packages? we should move quick
<fabbione> 2.6.12
<{Seb}> as x is no longer broekn
<{Seb}> i'm upgrading
<{Seb}> so i can do beagle testing
<mdz> mako: dude, I only heard about this on Saturday
<herzi> doko: gdb?
<herzi> *blinzel*
<{Seb}> is there any change i could make a custom hoary kernel with inotify?
<jdthood> I have a question about the Ubuntu alsa-driver package.
<pitti> jdthood: just ask it :-)
<jdthood> I understand a lot of ubuntu's patch.  However, I wonder about:
<jdthood> -	unmute_and_set_level "PCM,1" "90%"
<jdthood> +	unmute_and_set_level "PCM,1" "70%"
<mako> mdz: alright.. i'll let you breath :)
<mako> mdz: FOR NOW
<jdthood> and similar changes.  Are there reasons for these changes?
<mako> mdz: you knew i'd been making the packages, right? there have been a few threadson -devel
<ogra> mako, where is the prob ? cant you upload ?
<jdthood> I mean, did Ubuntu scientists in white coats determine that 70% was a better default value than 90% for the majority of users, or what?
<pitti> jdthood: probably, otherwise it wouldn't have been made :-) is there any changelog entry related to this?
<mako> ogra: um.. i think i did upload
<pitti> jdthood: it indeed might be
<mako> ogra: mark wants the in hoary-updates
<pitti> jdthood: at least for me (however, I didn't do the change, mdz maybe)
<ogra> mako, OH !
<Kamion> we had some incredibly long conversation about the default volume settings
<jdthood> pitti: In 1.0.5a-1ubuntu3: * Unmute Master, PCM, Synth controls at boot and set them to 70% volume
<jdthood> -- Matt Zimmerman
<mako> ogra: i uploaded them on friday or saturday i think but they need to approved
<Kamion> I remember either bugs or mailing list posts of the form "warty sounds nearly blew my eardrums"
<Kamion> (after doing auto-unmute-at-boot)
<ogra> mako, yep
<pitti> in addition, 90% often causes clipping effects
<mako> ogra: i think my ubuntu.com address is not whitelisted.. or wasn't at the time
<mako> so i'm not entirely clear what's going on :)
<jdthood> Hrm, OK I guess I'll adopt the ubuntu values upstream then.
<pitti> jdthood: you don't experience clipping with 90%? I do on both of my machines
<mdz> mako: oh, yes, I knew you were working on them, but the "we're ready to put them into hoary-updates" is new to me
<mdz> jdthood: yes, it was made in response to user feedback and some simplistic tests
<mako> mdz: mark suggested it like, no joke, 2 hours after hoary was released
<mdz> jdthood: our goal was to have a volume where _something_ could be heard by default on as many systems as possible, and in consideration of the fact that it was better for the user to be able to hear a quiet sound (and know to turn the volume up) than to have a sound play too loud
<mdz> mako: yes, I remember
<mdz> mako: but you didn't even have packages yet at that point, did you?
<mdz> (ones that you were satisfied with)
<mako> well, i didn't have pacakges that the userlinux guys were satisfied with
<mako> and i think not me either
<Mithrandir> mdz: apparently, the ooo changes I did for amd64 so printing works with the gtk frontend is ok (or at least I haven't gotten any reports about it being broken) so we might want to consider it for hoary-updates.
<mako> i can't remember.. they weren't upload able then
<mdz> Mithrandir: ok, mail me the proposed debdiff?
<jdthood> mdz: How about we compromise on the binary-friendly figure of 75%?
<Mithrandir> mdz: ok
<wasabi_> mdz, i know you wanted to get the java stuff done, but I'm hung up on xerces. It's probably going to be awhile.
<wasabi_> I can give you an overview of the problem as I see it though.
<mdz> wasabi_: I saw you mention that it failed to build; is it a xerces problem or a compiler problem?
<wasabi_> Sorta both.
<wasabi_> The Debian maintainer is doing something a litlte bit hacky in it. He's including in debian/dom2-sources source copies of another package (a DOM2 implementation) to compile xerces against.
<wasabi_> And he's using a compiler trick to compile against it without compiling it.
<wasabi_> Which seems to work with jikes but not with ecj.
<wasabi_> And that's where I left off.
<mako> this makoto guy on #ubuntu is rendering my nick highlying completely useless there
<maswan> mako: the trick is to teach your irc client not to highlight on it as a part of a longer word.
<Mithrandir> mako: add an ignore makoto?
<Lathiat> or chose a more uniue nickname :)
<Lathiat> *unique
<toresbe> mako: you can ignore it
<toresbe> mako:  ...somehow :P
<jdthood> mdz, pitti: With playback levels at 75% my PCM output is faint in comparison with my system bell.  However, you are right that too faint is better than too loud.
<toresbe> mako: just curious, did you choose your nick based on the Final Fantasy game series?
<pitti> lamont_r: here?
<toresbe> particularily, FF VII?
<mako> maswan: i like it when it's people talking about, say, URLS from my website or something
<mako> toresbe: i chose my nick based on my name :)
<mako> toresbe: which was not based on the final fantasty website
<toresbe> mako: that would explain it ;)
<maswan> mako: so, trickier, but /~. etc should not be counted as within a word. :)
<mako> maswan: or mako.cc or mako.yukidoke.org or something.. yeah
<lamont_r> pitti: yes
<Mithrandir> mako: you're cc licensed? ;)
<mdz> jdthood: I don't know how 75 compares to 70, but we've been using 70 for some time now and have ceased to receive negative feedback
<jdub> mdz: hrm, has the repository of debuginfo packages discussion come up again? i don't remember a spec about it at UDU
<\sh> hmmm....if I would be a doctor, then I would say: "My dear \sh, you're not living healthy and what you're eating is rubbish"
<mdz> jdub: there was a spec and a discussion at UDU
<jdub> ah, good
<mdz> http://udu.wiki.ubuntu.com/AutomatedProblemReports
<jdub> oh, that was the one we discussed instrumented builds and stuff, too?
<jdub> oh
<jdub> mdz: ah, so they won't be packaged
<mdz> yeah, it doesn't really make sense to have them all indexed and installable as .debs in my opinion
<jdub> kinda handy when tracking software, and getting upgraded debug stuff at the same time
<pitti> mdz: are you fine with changing the seeds for the new postgresql architecture?
<pitti> mdz: (i. e. I'll do it, just asking for your ack)
<mdz> jdub: kinda insane from an archive management perspective
<mdz> pitti: yes
<jdub> mdz: just looking for my pouch of magic launchpad pixie dust, one second.
<pitti> mdz: i. e.  I seed the server (which pulls in the client), and the -dev stuff is pulled in via build-deps
<mdz> pitti: yes, fine
<mako> Mithrandir: i've written an article about CC which might make a splash :)
<mako> Mithrandir: not so complimentary
<mako> Mithrandir: rms somehow got a copy and is urging me to release it
<Mithrandir> mako: sounds fun.
<mako> rms tells me he agrees with me and i start doubting myself :)
<Lathiat> heh
<Mithrandir> mako: ;)
<elmo> is there a way to get a wireless card to prefer an AP if it's available but not use it exclusively?
<Simira> mako: got my stuff on thursday. Yay! :D
<mako> Simira: great :)
<jdub> elmo: strongly worded admonitions
<Mithrandir> elmo: while true; iwlist scan | grep $AP && iwconfig eth1 ap $AP || iwconfig eth1 ap any ; sleep 1 ; done ?
<elmo> eww
<Mithrandir> elmo: it's probably more or less what such a tool would do anyhow. :P
<Lathiat> gtk-wifi does that
<Lathiat> .. im a little conerned about its setid python script tho, its uh, not looking so security conscious
<Lathiat> the gui is nice and it works well tho... :)
<Mithrandir> setuid python doesn't work anyhow, though.
<Mithrandir> AIUI
<Lathiat> its sudod
<Lathiat> wrong term
<Mithrandir> sudone?
<Lathiat> either way a a quick glance it looked like i could execute arbitrary commands :)
<Lathiat> (sudo /usr/bin/gtkwifi....)
<Lathiat> with a NOPASSWD: allow
<mdz> mako: which CC?
<mako> mdz: creative commons
<mdz> mako: I was afraid you meant Community Council
<mako> mdz: i like that CC
<mdz> I was like, man, mako isn't happy about the council?
<mako> mdz: thanks for reminding me, i need to write up that summary today
<elmo> Mithrandir: the "in an office, but next door has a stronger AP than us" can't be an uncommon use case/scenario tho, I'm surprised there isn't something in iwconfig for it
<elmo> well I suppoed it'd need to be more than just iwconfig
<Mithrandir> elmo: with the same essid and wep key?
<elmo> Mithrandir: no wep, essid set to any, on both routers, and I don't want to change that, because then the user has to change that when she goes home
<elmo> and AFAIK we don't have remotely useful/usable profile type support yet?
<Mithrandir> elmo: waproamd might work, or possibly networkmanager from thom's repo.
<siretart> elmo: I *think* that could be possible with wpasupplicant. there you can set priorities. this should be the effect you try to acheive
<thom> leave the NM in my repo well alone, i'm just about to delete it
<Mithrandir> thom: it's crack?
<thom> out of date, old, broken
<jdthood> thom: Is a less-broken NM package on its way?
<thom> jdthood: yes
<Burgundavia> mdz, do you bother updating the translation stuff during breezy release? (I have someone on the forums asking)
<jdthood> thom: Let me know if there is some way of integrating with resolvconf.  I'll be happy to work on that.
<thom> jdthood: or try http://bootlab.org/~j/NetworkManager/ for hoary stuff; that's the 
<siretart> elmo: I tried to do that with my hardware (madwifi). The problem is that there are issues with wpasupplicant and madwifi when using networks without encryption or plain wep. I already mailed madwifi user list. Greg did answer me privatly that the problem is known, but unclear how to solve it
<thom> 0.3 branch
<thom> jdthood: i need to look at that; i'll let you know
<thom> jdthood: also, j@bootlab.org is interested in ifupdown integration with NM
<jdthood> thom: I can work with people on that too.
<jdthood> thom: I recently rewrote ifupdown in Python with the plan of translating to C++ later.  That may be of use for someone wanting NM to emulate ifupdown.
<mdz> Burgundavia: what translation stuff, specifically?
<Burgundavia> mdz, updated translation packs
<jdub> oh, doko's playing with perl again :)
<Burgundavia> jdub, you seen this? http://www.spreadubuntu.org/
<jdub> i knew it was purchased, hadn't seen anything done with it yet
<jdub> ta
<eruin> Burgundavia, work in progress?
<Burgundavia> eruin, no idea, just saw it on the forums, figured I would tell those in power about it
<eruin> should have some way to become a "registered ubuntu user" and a download counter too, eventually ;)
<tseng>  thats a nice page
* mvo is away for hockey now
<seb128> Amaranth: around?
<Amaranth> seb128: yeah
<seb128> Amaranth: do you know what other distros do about the .menu files conflict between desktops?
<Amaranth> seb128: gentoo seems to ignore it, suse does .menu.gnome and etc, not sure about the rest
<dooglus> I installed a new kernel earlier, rebooted, and when gnome came back up after the reboot there was a little 'something' on the top of the screen telling me to reboot as soon as possible because the kernel had been updated.  couldn't it tell that i had already rebooted?
<seb128> Amaranth: we are probably going to change the namespace for GNOME as well, do you think that's a good idea?
<seb128> ie: applications-gnome.menu or something like that
<seb128> does it break anything, like menu editors, etc?
<Amaranth> i think the way SuSE does it is better, actually
<seb128> how do they do?
<Amaranth> but yeah, it'll break anything that works with menu files
<Amaranth> applications.menu.gnome, applications.menu.kde, applications.menu.xfce
<Amaranth> at least, that's what i was told they do
<fabbione> infinity, lamont_r: can you please kick linux-source-2.6.12 back on i386?
<seb128> Amaranth: how is that better than applications-<desktop>.menu ?
<Amaranth> seb128: it looks nicer ;)
<seb128> Amaranth: or <desktop>-applications.menu
<Amaranth> seb128: and someone else already does it, might as well be compatible with them
<seb128> atm kdelibs does kde-....menu
<Amaranth> since compatibility with the spec is shot
<seb128> for ubuntu
<Amaranth> yeah, kde-applications.menu in ubuntu and debian
<seb128> I guess gnome-applications.menu makes sense so
<Amaranth> yeah, but let me explain
<seb128> sure
<Amaranth> if we can't follow the actual standard, it would be better to try to make a de-facto standard
<Lathiat> Amaranth: no it would be better to udpate the standard :)
<Amaranth> if SuSE (and i assume NLD) are doing applications.menu.gnome and ubuntu does too, others could fall in to line and we still get something usable
<Amaranth> although i don't know how they handle applications-merged/
<Amaranth> apple stole the rosetta name :?
<Amaranth> their PPC-x86 translation stuff is called rosetta
<seb128> Amaranth: need to figure what redhat does
<Kamion> it's not as if rosetta is a particularly non-obvious name for something that does translation
<Amaranth> i know
<Amaranth> it just sucks
<Amaranth> when people think rosetta they'll think apple now
<Kamion> most people will still think of the Rosetta Stone. :-)
* fabbione goes off for dinner
<seb128> Amaranth: the redhat way is:
<seb128> * Tue Feb  1 2005 Matthias Clasen <mclasen@redhat.com> - 2.9.90-2
<seb128> - Don't include .directory and .menu files,
<seb128>   we want those from redhat-menus
<seb128> 
<seb128> they have common menus for both desktop probably
<Amaranth> yeah, bluecurve and all that
<seb128> ?
<seb128> is that a theme?
<Amaranth> yeah, that's a theme
<Amaranth> but i mean they try to make KDE and GNOME look the same
<Amaranth> so having the same menus goes along with that
<seb128> k
<jdub> seb128: bluecurve was a brand, so covered more than just the theme
<seb128> jdub: tell me again why we don't do a commun menu for both desktops?
<jdub> seb128: i think that would mean we'll end up with a sucky lowest common denominator for both.
<seb128> hum, k
<robertj> btw, its getting mighty cold in here. Apparently news is in from the WWDC and Apple is switching to Intel
<seb128> let's rename gnome menus too so
<Kamion> debconf (developer): <-- METAGET kbd-chooser/no-keyboard Description-en_GB.UTF-8
<Kamion> debconf (developer): --> 0
* Kamion hits debconf
<jdub> robertj: http://www.apple.com/pr/library/2005/jun/06intel.html
<robertj> It feels odd
<doko> Kamion: could you provide breezy_probs for universe as well?
<Kamion> doko: it's on my to-do list ...
<Kamion> requires me to set up a separate britney run on rookery
<doko> no haste ...
<mjg59> So. How do we cope with keyboardless devices?
<thom> run away screaming?
<mjg59> I think that's about it at the moment
* mjg59 notes that it's a bit awkward to log in at the moment
<mdz> Burgundavia: once the infrastructure is in place, we'll be rolling new packs regularly during the development cycle
<mdz> weekly perhaps
<ogra> mjg59, not even a touchpad ? 
<mjg59> ogra: Touchscreen
<ogra> thats what i meant... sorry...familiar linux should have some drivers... 
<ogra> dunno if they apply for all kinds of touchscreens....
<Amaranth> so...
<Amaranth> sarge like, just released?
<thom> yep
<Amaranth> isn't it a little early?
<tseng> Amaranth: "early"?
<tseng> this is sarge.
<Amaranth> i heard 21:00 UTC, that's two hours from now
<tseng> early passed years ago
<thom> Amaranth: no, april 1 was some time ago
<Amaranth> or is that when all the mirrors will have it?
<Kamion> announcement won't be 'til 20:30 UTC
<Kamion> (was previously quoted as 21:00 UTC)
<Kamion> we're still letting mirrors catch up
<Riddell> I'm getting complaints that the torrent doesn't work and http://torrent.ubuntu.com:6969/ seems to be down
* Riddell wonders who to poke
<crevette> Riddell> it's known issue
<crevette> see #ubuntu
<tseng> um
<tseng> "Evolution Desktop" on sounder
<tseng> heh.
<thom> tseng: crashy slow and may eat your mail?
<tseng> thom: no, this guy is going to make a script to install mono apps + his custom theme on a ubuntu breezy system it sounds like
<thom> ah
<tseng> im just trying to figure out what he is smoking
<tseng> We are planning on an 'Expansion
<tseng> > Pack' for the GNOME 2.10/Ubuntu Desktop called 'Evolution
<tseng> > Desktop'.
<wasabi_> oGo?
<tseng> oh nm thats not to sounder, thats to mako.
<\sh> http://people.zoy.org/~sam/phd-sarge.png
<pitti> hi
<sivang> hey pitti 
<sivang> pitti: almost time for bed, isn't it?
<sivang> pitti: (for me at least)
<\sh> sivang: CC meeting this evening :)
<pitti> sivang: yep, just returned from dancing, I wanted to see what I broke with my upload rave today
<pitti> huh, CC today?
<Burgundavia> mdz, thanks
<\sh> pitti: 0:00 our time
<sivang> pitti: for pg ?
<sivang> \sh: huh?
<sivang> \sh: tommorow no?
<pitti> \sh: no, it's tomorrow
<pitti> \sh: i. e. Wednesday morning of our time
<\sh> no
<\sh> 06.06. 22:00 utc
<\sh> http://www.ubuntulinux.org/wiki/Calendar
<sivang> \sh: that;s not whay the topic in #u-m says
<seb128> pitti: dholbach said that meeting is tonight too
<\sh> The next meeting of the Council will be on June 6th 2005 at 22:00 UTC 
<\sh> http://www.ubuntulinux.org/wiki/CommunityCouncilAgenda
<pitti> oops
* pitti looked into the topic of #u-m
<pitti>  Tue 7 June 22:00 UTC Community Council 
<\sh> well...irc is not trustable
<pitti> bah
<pitti> I'm totally tired
<\sh> where's janeW? she knows :)
<pitti> why it is on Monday, it was always Tuesday...
<\sh> pitti: for us it's tuesday
<sivang> \sh: where are you on?
<sivang> s/on/in/
<\sh> .de
<sivang> so, it's the same as for me,
<crevette> de is tuesday ?
<sivang> late monday :-)
<sivang> so it is tommorow
<sivang> then
<crevette> fr is sitll monday and its only 10:30
<crevette> :)
<sivang> pitti: well, another CC meeting I'll miss :-/
<sivang> pitti: just came back from work, am exhusted
<\sh> sivang: you're not the only one...
<sivang> \sh: strange, topic over u-m says 22:00 UTC, Tue
<sivang> \sh: where am I going wrong there?
<\sh> one information is wrong
<\sh> mako: ping 
<whiprush> jdub: fridge!
<shaya> anyone using new evolution? :)
* shaya pokes seb
<shaya> bug report time "Evolution Error: Could not create composer window, unable to activate the html editor control"
<zul> bah...html in email is evil
<shaya> zul: yes
<shaya> but even plain text evo email uses that control
<shaya> and i fixed it
<shaya> dependency problem
<shaya> libgtkhtml3.8 which evo depends on, didn't pull in gtkhtml3.8 package
<shaya> which is what editor needs
<moquist> does anybody here know if Hoary supports / on RAID?
<moquist> sorry, I meant to post in #ubuntu.
<moquist> irssi windows ain't where they used to be...
<KaiL> should packages from debian/sid currently automatically move into breezy?
<KaiL> everybody in meeting?
<jdub> KaiL: probably bad time, timezone wise
<jdub> KaiL: sid stuff is merged once daily, i think
<KaiL> jdub: could you take a look at ncmpc?
<KaiL> crashes on startup and is broken since ages
<KaiL> quite interesting: this -1 was never in debian, it's taken from progn.org
<\sh> Package: libbonobomm1.3
<\sh> Binary: libbonobomm1.3-9c2, libbonobomm1.3-dev
<\sh> but libbonobomm1.3-9c2 is not on the servers
* lamont__ tries to remember if it's the oss or alsa device that he wants
<anibal> where does the Community Council meet?
<dholbach> anibal: #ubuntu-meeting
<anibal> dholbach, thanks
<dholbach> de rien
<tseng> hi dholbach 
<dholbach> elmo: do you require some of action of me to get into the main keyring?
<dholbach> hey tseng :)
<Kamion> CC meeting should be tomorrow, I believe; there was some date confusion
<Kamion> somebody put "Tuesday 6 June" as the date of the next meeting
<Kamion> they're generally Tuesdays, so I've changed the topic to say 7 June
<Kamion> I certainly can't be at this meeting anyway; I need to fall over soon
<\sh> hmmm...
<dholbach> i will change Calendar and CommunityCouncil accordingly
<\sh> confusion ;)
<\sh> so tomorrow
<Kamion> dholbach: thanks
<Kamion> mako: you agree it's tomorrow, right?
<Burgundavia> Kamion, oh, crap, that was me
<mdke> didn't we have one last week?
<mdke> time flies
<Burgundavia> Kamion, I editing the wiki page and didn't confirm the date
<elmo> dholbach: mail keyring@?
<dholbach> elmo: ok
<dholbach> elmo: will do
<\sh> lets welcome sarge ;)
<\sh> a big bottle of champagne :)
<mdke> hmm
<jdub> mjg59: around?
<mako> Kamion: it's tomorrow
<mdke> hey mako
<dholbac1> ok, i'm off to bed now too
<mdke> night dholbac1 
<dholbac1> have a nice evening
<\sh> g'night too
#ubuntu-devel 2005-06-14
<mako> mdke: hey
<mdke> mako, did anything come of the ops in #ubuntu for CC members?
<mako> man.. i can't recall
<mdke> fair enough
<mdke> is it worth discussing tomorrow?
<mdke> mako ^
<mako> mdke: put it on the agenda, we can skip over it if isn't
<mdke> mako, alrighty
<Lowe_Gear> hey
<Lowe_Gear> i've looked thru the Breezy wiki
<Lowe_Gear> having hopped over from Google's Summer of Code page
<Lowe_Gear> am interested in working for one of the bounties, namely LightweightDesktop
<Lowe_Gear> is there anybody i can talk to with regard to this?
<IFRFLY1> Hi, all. the latest version of linux-headers-2.6.10-5-386 has caused several problems with my notebook. Where can i find the last version and revert entirely?
<xhaker> is there someone here that i can talk to in regard to speedstep-centrino and acpicpufreq modules?
<IFRFLY1> I should mention no one on #ubuntu could answer this over the past several hours
<xhaker> the thing is bios.max_speed = 1700 and it only scales to 1600
<mdke> IFRFLY1, not sure, but it would be very helpful if you could file a bug about that
<IFRFLY1> I will do that on...where, the wiki?
<xhaker> IFRFLY1, Linux-headers caused problems?
<mdke> IFRFLY1, http://bugzilla.ubuntu.com, thanks very much
<IFRFLY1> Yes. First, it reverted to 0.19 of the ipw2200 driver (current stable is 1.0.0), second I've been experiencing several weird things...including the fact that my fan now never turns off despite operating temps WELL at the low end of the spectrum.
<IFRFLY1> mdke, I will do that.
<IFRFLY1> Can anyone offer an idea about how I might revert?
<tseng> im not sure how linux-headers affects your running drivers and acpi
<IFRFLY1> linux headers own the drivers and bring in the /wireless
<IFRFLY1> afaict
<xhaker> tseng, exactly, he might be talking abou linux-image
<xhaker> lol
<IFRFLY1> Maybe!
<tseng> linux-headers brings in.. headers
<xhaker> IFRFLY1, ubuntu never shiped 1.0+ drivers for ipw2200
<tseng> and we didnt revert anyone ipw
<xhaker> so it wasn't that what reverted yours to version 0,19
<IFRFLY1> Righto. I know. But 0.19 don't work for me or anyone else (lots of forum activitiy on that one.
<IFRFLY1> Okay, I'm willing to admit total defeat. 
<IFRFLY1> However...
<IFRFLY1> (locate ipw2200: /usr/src/linux-headers-2.6.10-5-386/include/config/ipw2200)
<tseng> erm no
<tseng> those are headers
<xhaker> IFRFLY1, compile the ipw2200 module yourself.. there is more than enough info on that on the forums
<tseng> headers are used to build glibc and 3rd party kernel modules
<tseng> stuff like that
<IFRFLY1> I did compile them myself and wrote the howto at http://www.nickselby.com/articles/?a=1807
<IFRFLY1> BUt
<IFRFLY1> after accepting an update last week offered by the update applet, I was reverted to 0.19
<IFRFLY1> The only thing I saw was "Linux Headers"
<tseng> so install it again
<IFRFLY1> I did. 
<tseng> so whats the problem
<IFRFLY1> However while wireless is working fine, this fan problem started at exactly the same time
<KaiL> uhm, the ipw2200 in hoary doesn't work?
<tseng> because its not linux-headers.
<tseng> KaiL: WFM
<IFRFLY1> Right. I'm willing to admit both ignorance and helplessness
<KaiL> 2 Laptops here ;)
<IFRFLY1> However I would really like all to work as it did last week!
<KaiL> and I'm SHURE, there would be activitily like hell, if there's a bug ;)
<IFRFLY1> KaiL: on many people's laptops it did not.
<xhaker> IFRFLY1, try lsmod | grep acpi
<IFRFLY1> sony_acpi               6280  0
<IFRFLY1> pcc_acpi               11264  0
<xhaker> KaiL, ipw2200 v0.19 is known to die if you the connection idles a bit
<IFRFLY1> KaiL: there was a LOT of activiity on the forums about it. I get thank you notes almost daily for the howto
<IFRFLY1> xhaker, others also experienced difficulty in changing networks
<xhaker> maybe,
<KaiL> interesting...
<IFRFLY1> Yes, esp as it was *not* universally suffered
<xhaker> i compiled 1.0.4 and am using gtkwifi
<KaiL> ...good, that the breezy kernel will come with 1.0.4 ;)
<xhaker> :)
<xhaker> didnt know that
<IFRFLY1> I could not get anything above 1.0.0 to work on my machine, neither could literally dozens of people on the lists and forums
<xhaker> i've been interested in the audio developments for breezy :P
<IFRFLY1> I'd LOVE to help track it down, despite my limited technical knowledge  :)
<IFRFLY1> I'd be willing to test and document
<IFRFLY1> Did the result of that lsmod | grep acpi interest anyone?
<xhaker> IFRFLY1, what? 1.0.4 modules doesnt work there?
<Lowe_Gear> anybody: is there anybody i can talk to regarding BreezyBounties?
<IFRFLY1> Correct. I have a presario v4020 US and nothing above 1.0.0 worked after a reboot
<xhaker> IFRFLY1, yes.. you have a sony laptop and  the module was loaded.. 
<IFRFLY1> I have a compaq presario V4020. A problem dawns
<xhaker> lol
<xhaker> compaq presario loads sony_acpi module.. something is not right
<xhaker> is it a centrino?
<IFRFLY1> Yes, xhaker, I would be extraordinarily grateful if someone could suggest a course of action. 
<xhaker> IFRFLY1, sony sowing the is no problem
<xhaker> showing
<IFRFLY1> good
<IFRFLY1> !
<xhaker> it is just statint that you have the module there
<xhaker> now
<xhaker> try /etc/init.d/powernowd start
<Lowe_Gear> ....... anybody: is there anybody i can talk to regarding BreezyBounties?
<IFRFLY1> okay... It started
<xhaker> Lowe_Gear, maybe you'll be more successful if you send a mail to the mailbox they setup?
<Lowe_Gear> already did. thanks.
<tseng> can you put a * in .install?
<tseng> yes.
<xhaker> IFRFLY1, load the cpu frequency applet
<xhaker> see if it is scaling
<xhaker> IFRFLY1, ?
<IFRFLY1> Sorry, is that cpufreq-selector?
<IFRFLY1> xhaker?
<xhaker> lets see
<xhaker> do that thingie again -> lsmod | grep acpi
<IFRFLY1> sure
<IFRFLY1> sony_acpi               6280  0
<IFRFLY1> pcc_acpi               11264  0
<xhaker> hmm
<xhaker> try.. sudo modprobe acpi_cpufreq
<IFRFLY1> hmm. FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.10-5-386/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): Device or resource busy
<IFRFLY1> But ps aux | grep cpufreq shows nothing. . . If that means anything. 
<xhaker> what is your cpu?
<IFRFLY1> One sec. .. 
<IFRFLY1> 1.5GHz Intel Centrino  Mobile Technology featuring Intel Pentium M Processor 715A
<lsuactiafner> would upgrading from GLIBC_2.3.3 to GLIBC_2.3.5 create problems on hoary
<Unfrgiven> did you guys hear that Apple's technology for allowing the same binaries on intel & ppc is called Rosetta?
<IFRFLY1> Nice.
<xhaker> IFRFLY1, try sudo modprobe speedstep-centrino
<IFRFLY1> OKay...It didn't complain...
<xhaker> :)
<jdub> Unfrgiven: yeah, lots :)
<xhaker> is it scaling?
<IFRFLY1> I am unable to launch that monitor
<xhaker> IFRFLY1, d you know how?
<IFRFLY1> The cpu frequency applet? Probably not - is it the cpufreq-selector?
<xhaker> right click in gnome pannel.. add to pannel
<IFRFLY1> I was doing ALT+F2 cpufreq and it autocompleted - selector...sorry, yes?
<IFRFLY1> Ah
<IFRFLY1> Okay. It's running and says, 600MHz
<xhaker> :)
<xhaker> so it is working :P
<IFRFLY1> Righto. However I must say I'm still not sure what is causing my fan to be constantly on with temps at 43C... Though that monitor is cool! 
<IFRFLY1> And I take it I could scale this up to go to 1.5MHz if I liked life on the wild side? 
<xhaker> IFRFLY1, run glxgears on the terminal and see if it goes up
<lsuactiafner> not wild but warm and melty
<xhaker> and btw.. you should be using linux-image-586
<IFRFLY1>  Isuactiafner....MMM, gooey CPU. And xhaker, affirmative: up to 1.50 and I'm stoping it before I have an intel sandwich.
<xhaker> instead of 386 stuff
<IFRFLY1> THAT was a cool thing, xhaker.  
<IFRFLY1> I agree -- I asked on forums as to why I had 386 and no one could tell me. Being new and all......
<IFRFLY1> Can you tell me how I can get the 586 stuff?
<lsuactiafner> xhaker : how would i go about updating to GLIBC_2.3.5? and will it be relativly safe on hoary?
<xhaker> IFRFLY1, it doesn't melt or something :P
<IFRFLY1> Grill?
<xhaker> lsuactiafner, i believe someone answered that already.. don't!
<lsuactiafner> didnt see anyone answer me? except someone that told me glibc aint fun
<xhaker> IFRFLY1, 386 kernel is the kernel that works on every x86 platform :P but if you want to get a speed boost from current cpus.. you should use 586
<lsuactiafner> becuase i want to install newest nvidia drivers
<xhaker> lsuactiafner, when you try to install glibc 2.3.5 does it tell you that it has to remove anything?
<IFRFLY1> Actually, here's the thing: I'm actually quite pleased with ALL ubuntu has bropught me: speed, power, battery management, color, it's lovely. Until last week when the fan started running all the time with temps in the 40s. HP says temp operating range is 40 to 60C before the fan needs to be on. But since accepting the upgrade option from the update applet, the fan has kicked on constantly. 
<xhaker> IFRFLY1, ohh.. and if you install the 586 kernel you'll have to recompile the i386 module again
<lsuactiafner> well sadly i cant find the apt-get package to install to upgrade.. heh
<xhaker> ipw2200
<xhaker> i meant
<IFRFLY1> I don't mind that at all>...
<IFRFLY1> Long as the breeze and fan noise stops. 
<IFRFLY1> it's like  three minute compile all steps included!
<xhaker> IFRFLY1, i guess i'm lucky.. my fans are quiet most of the time.. but my processor only scales to 1600 and it is 1700 max
<xhaker> lol
<xhaker> IFRFLY1, you have to install the linux-headers-586 too
<xhaker> you should know that by now ;)
<IFRFLY1> I see. But I guess what I am saying is that the fan should NOT be on and didn't used to be on and I wonder how I can track down what has changed since last week as I've not changed anything except the upgrade .......
<IFRFLY1> Can you help me track down the problem?
<xhaker> is the fan still making noise now?
<IFRFLY1> Yes!
<IFRFLY1> It has not turned off in the past four hours!
<xhaker> try  lsmod | grep thermal
<IFRFLY1> thermal                13576  0
<IFRFLY1> processor              22708  2 speedstep_centrino,thermal
<lsuactiafner> IFRFLY1 : run top check if something is using your CPU
<lsuactiafner> more than it should
<xhaker> lsuactiafner, he has the cpu freq applet in gnome.. and it says 600mhz
<xhaker> its in low profile
<xhaker> IFRFLY1, is the monitor still saying 600mhz?
<IFRFLY1> I did, and I'm running gkrellm and it shows NOTHing. CPU at no more than 16% and temps showing as 41.C and 43C for the two sensors
<IFRFLY1> Yessir
<KaiL> IFRFLY1: you are shure, it's the cpu fan?
<IFRFLY1> NO!
<IFRFLY1> No one has asked me.
<IFRFLY1> What other fans would there be?
<xhaker> HD
<xhaker> hard drive maybe
<KaiL> there could be one on the graphcs chip...
<lsuactiafner> cat /proc/cpuinfo
<IFRFLY1> Well. The disk activity monitor shows very little actitivity.....one sec...
<lsuactiafner> cat /proc/cpuinfo | grep MHz
<IFRFLY1> just like the monitor says: cpu MHz         : 598.719
<lsuactiafner> what power management does his chip use? maybe the process aint running..
<xhaker> lsuactiafner, it is man..
<xhaker> i made him load it
<lsuactiafner> am tailing @ the end of a discussion so not sure if you guys checked that already
<xhaker> speedstep-centrino
<KaiL> xhaker: should that be autoloaded by powernowd?
<IFRFLY1> xhaker, should that have loadded...
<lsuactiafner> config correct?
<IFRFLY1> Oh.
<KaiL> shouldn't.. better
<xhaker> KaiL, correct.. powernowd should have loaded that automaticly but it didnt
<xhaker> :S
<KaiL> lsuactiafner: his clock is at 600MHz, so the CPU is NOT that problem.
<KaiL> xhaker: strange - never saw that happen on a Pentium M
<lsuactiafner> think powernowd is amd only
<KaiL> lsuactiafner: don't think to much :p
<lsuactiafner> i run my 3200+ @ 100% cpu usage with FAH@Home to keep my room warm.. winter..
<lsuactiafner> prolly an expensive way to convert energy to heat..
<xhaker> KaiL, never? I have a Pentium M 1.7 ghz.. it loads acpicpufreq instead of speedstep-centrino and my max speed is limited to 1.6ghz
<xhaker> lol
<KaiL> if you don't need to pay for it and like it to waste energy...
<xhaker> lsuactiafner, powernowd is a daemon for all cpu types
<lsuactiafner> heh
<lsuactiafner> south-africa got cheap energy
<lsuactiafner> but.. my roomie pays power since i rent from him
<xhaker> KaiL, saw what i wrote before?
<lsuactiafner> he got me using energy-effiecient bulbs that make practially no light
<IFRFLY1> When I look at gkrellm's disk section it seems to be under 20K, mostly around 12K and lots of idle time. Doesn't seem to be too busy . . . 
<KaiL> xhaker: about your lap?
<xhaker> yes
<xhaker> speedstep-centrino gives an error when trying to load
<xhaker> no such device
<xhaker> lol
<lsuactiafner> i got so much lag suddenly on the dailup
<IFRFLY1> Perhaps I can put this another way: is there anything which would have changed in the latest image for my machine which could have affected whether the fans kick on as silly as that sounds?  
<KaiL> xhaker: strange, shure it's a 1.7? ;)
<xhaker> it is
<xhaker> bios.max_speed = 1700
<KaiL> lol
<xhaker> model name      : Intel(R) Pentium(R) M processor 1.70GHz
<xhaker> if i disable powernowd it runs at 1.7gz
<lsuactiafner> whats min_speed?
<xhaker> 600
<KaiL> that's VERY strange
<xhaker> i had filled a bug on warty times
<KaiL> IFRFLY1: even more funny: that was only a sec....
<IFRFLY1> Sorry KaiL?
<lsuactiafner> sysctl -a | grep min
<KaiL> do you have a geforce go in that?
<xhaker> huh?
<KaiL> IFRFLY1: ?
<IFRFLY1> Sorry, ?
<KaiL> the graphics chip
<IFRFLY1> AH. ONe sec.
<KaiL> we had somebody who had a broken nvidia driver after that update
<IFRFLY1> HP says: Intel Graphics Media Accelerator 900-
<KaiL> maybe same here and that killed something
<IFRFLY1> But how can I be certain?>
<IFRFLY1> The other question was, is it possible to revert to what worked?
<KaiL> lspci | grep VGA
<IFRFLY1> yes....one sec
<IFRFLY1> 0000:00:02.0 VGA compatible controller: Intel Corp. Mobile Graphics Controller (rev 03)
<xhaker> its not your graphics card then
<xhaker> lol
<IFRFLY1> Nice to know!
<KaiL> looks like intel....
<xhaker> not more wierd than my problem but wierd nonetheless
<KaiL> whyever that is called "Accelerator" (650fps in glxgears(, but that's OT
<xhaker> i have a question.. is it sure or shure?
<xhaker> i'm portuguese but i'm pretty sure it's sure
<KaiL> think so
<mdke> yes
<xhaker> KaiL and I'm SHURE, there would be activitily like hell, if there's a bug ;)
<xhaker> lol
<xhaker> KaiL, you need to learn english.. jk
<IFRFLY1> I have, it seems, demo effect. No matter what machine I am on it crashes. I visited Nokia HQ a few years ago and their newest Nokia Communicator crashed as they demo'd it to me. 
<IFRFLY1> So I wouldn't be surprised to learn it's not a widespread bug ;)
<xhaker> lol
<xhaker> you're Doomed
<IFRFLY1> Yes. 
<xhaker> (with mexican accent)
<xhaker> what is the model younhave? compaq presario..
<IFRFLY1> But seriously, would it be possible for me to revert to the last version of the linux-image without actually reinstalling from the CDRom I originally used?  
<IFRFLY1> V4020US!
<IFRFLY1> http://h10025.www1.hp.com/ewfrf/wc/genericDocument?lc=en&cc=us&docname=c00302894
<IFRFLY1> BTW, after hours on the phone with HP I got a guy at corporate who said there was one (count 'em) guy in the building who used Linux. 
<IFRFLY1> (he was on holiday)
<KaiL> IFRFLY1: quite from interest, how fast is glxgears on that intel 9xx?
<IFRFLY1> Errr. It zooomed up to 1.5ghz before I got scared and turned it off ;)
<xhaker> no reason to get scared
<xhaker> run it again
<xhaker> it doesnt go past 1.5
<xhaker> lol
<IFRFLY1> okay. I got scared as it was the exact moment someone mentioned, um, melting.
<xhaker> see in the terminal what fps fdo you get
<IFRFLY1> okay, it's running now. 3899 frames in 5.0 seconds = 779.800 FPS
<IFRFLY1> 5322 frames in 5.0 seconds = 1064.400 FPS
<IFRFLY1> up to 5416...5372, that kind of thing it seems
<xhaker> ok
<IFRFLY1> That is a seriously cool program.
<IFRFLY1> Which I've just stopped again!
<xhaker> hehe
<lsuactiafner> lol
<xhaker> IFRFLY1, cat /proc/cpufreq
<lsuactiafner> i didnt mention melting..
<lsuactiafner> or incineration
<lsuactiafner> or fireballs from space..
<IFRFLY1>           minimum CPU frequency  -  maximum CPU frequency  -  policy
<IFRFLY1> CPU  0       600000 kHz ( 40 %)  -    1500000 kHz (100 %)  -  userspace
<lsuactiafner> *innocence self*
<IFRFLY1> (18:44:21) lsuactiafner: not wild but warm and melty
<IFRFLY1> ;)
<lsuactiafner> rofl
<lsuactiafner> fake logs!!
<lsuactiafner> IFRFLY1 is an imposter!
<lsuactiafner> he is here to discredit me...
<IFRFLY1> It's true. I've accidentally got two copies of gaim running. My real name is...IFRFLYR
<IFRFLY1> :P
* lsuactiafner 's reputation will not be tarnished.
<tseng> comeon guys
<lsuactiafner> tseng : you by any chance know much about tc qdisc?
<tseng> i havent the slightest idea what you are talkinng about
<xhaker> what about texas instruments 3in1 disk reader?
<xhaker> lol
<IFRFLY1> Any other ideas xhaker?
<lsuactiafner> i want a 1in3 reader..
<lsuactiafner> just to phreak ppl out
<mjg59> jdub: Hello
<jdub> mjg59: yo
<jdub> mjg59: do you have anyone on planet debian using blogspot?
<mjg59> jdub: Uh. No idea whatsoever, I'm afraid
<mjg59> jdub: One thing I did want to ask, though - is there any way we can hack something in so Livejournal people can tag their entries for certain planets?
<mjg59> There's no way to have multiple rss feeds, but it would be nice to be able to prevent certain entries hitting planets
<IFRFLY1> Look, I"m really grateful for all the help everyone's given, and I'm sadly despairing because I know that this fan issue wasn't an issue before this update. I am sorry to be a pain, but can anyone tell me if/how I can revert to the last linux-image or whether upgrading to the 586 stuff will help?
<xhaker> IFRFLY1, ty
<xhaker> try
<IFRFLY1> try.....?
<xhaker> yes 
<IFRFLY1> Ah, try the 586 stuff. 
<xhaker> install the 586 kernel
<xhaker> you'll have both
<mjg59> What?
<IFRFLY1> Yes. Is this an apt-get thing?
<xhaker> and be asked to chose which one to boot
<mjg59> IFRFLY1: Are you running Hoary or Breezy?
<IFRFLY1> Hoary (5.04 if that's hoary)
<mjg59> There has been no change in Hoary that should affect when your fan is enabled or disabled
<mjg59> If your system behaviour has changed after a Hoary update, then file a bug
<KaiL> daniels: please add SiS 6326 to the "16bit only list", that chip has some strange bugs
<IFRFLY1> That was where the discussion began, and I am delighted to file the bug and track it, but people on the list were helping me to determine just *what* was buggy
<xhaker> mjg59, powernowd is loading acpicpufreq instead of speedstep centrino
<xhaker> Hoary here
<mjg59> xhaker: Uh. That's a perfectly reasonable thing for it to do.
<HrdwrBoB> KaiL: what specifically, I used one for a long time in 24bit
<xhaker> it is?
<mjg59> Yes
<xhaker> i have a pentium m ..
<mjg59> xhaker: Put the contents of /proc/cpuinfo somewhere
<xhaker> ok
<mjg59> The only way that powernowd could change behaviour with a kernel change is if /proc/cpuinfo changed
<xhaker> it was always like this
<mjg59> Ok, in that case it's likely to just be a powernowd bug
<xhaker> i've filled a bug in warty days
<mjg59> There's no good way to tell whether a chip is a pentium m or not
<KaiL> HrdwrBoB: the strange memory with the 4MB normal and 4MB texture
<mjg59> And some pentium ms have broken BIOSes which mean you can't use the centrino driver
<HrdwrBoB> KaiL: ahh, yech
<mjg59> In that case, there's a reasonable chance that the acpi driver will work, so we fall back to that
<KaiL> the driver can use the texture mem for normal work, but get's slow like hell then
<KaiL> HrdwrBoB: well, and with 24bit, you come over that limit quite fast
<HrdwrBoB> KaiL: yeah 4mb isn't very much at all
<xhaker> mjg59, https://bugzilla.ubuntu.com/show_bug.cgi?id=5591 this guy has the same laptop.. but, my laptop with acpicpufreq only scales to 1600 when infact it is a 1700. so that can't be right
<IFRFLY1> mjg59, since I had no trouble until the upgrade is it possible for me to revert to what I had whch worked perfectly?
<mjg59> xhaker: Bios bug
<xhaker> bios.max_speed is 1700
<xhaker> :S
<mjg59> IFRFLY1: If you know which package was updated, then yes
<mjg59> xhaker: ?
<xhaker> in the device manager
<mjg59> xhaker: That's DMI information. It's entirely separate to the ACPI performance state tables.
<KaiL> HrdwrBoB: normal cards would tell us, if they don't have enough RAM
<mjg59> Most bits of your BIOS are written by different people
<xhaker> so.. it is a DSDT problem?
<KaiL> this one just get's slow
<IFRFLY1> Okay, thank you. Is there a record of updates which I make somewhere I can access? I blindly accepted the suggestion of the update applet so wasn't actually paying attention.
<mjg59> xhaker: No, it's an ACPI performance table issue
<mjg59> That's kept separately to your DSDT
<mjg59> Oh, christ, it's an Acer
<xhaker> hmm.. can i do something?
<mjg59> File a bug about the driver not giving you full speed
<mjg59> Then we'll see what we can do
<mjg59> You're *certain* it's a 1.7GHz machine?
<KaiL> lol
* jdub wails in pain at plone css
<xhaker> mjg59, i am.
<xhaker> i can get that speed if i disable powernowd
<xhaker> and the cpu id is right too
<mjg59> xhaker: Ok. Please file a bug, and we'll see what we can do
<xhaker> model name      : Intel(R) Pentium(R) M processor 1.70GHz
<xhaker> should i include any attachments
<xhaker> like dmesg..
<mjg59> xhaker: If it's that fast, it's a Dothan. They *need* BIOS support for frequency scaling.
<mjg59> And if the BIOS provides us incorrect information, then things don't work too well.
<mjg59> Yeah, please attach dmesg and /proc/cpuinfo
<xhaker> ok
<IFRFLY1> mjg59, I am sorry to bother you but is there a log of what software updates does? I cannot find it. 
<mjg59> IFRFLY1: No idea, I'm afraid
<IFRFLY1> Thank you
<mjg59> Sorry about that
<mjg59> If there isn't, then there probably ought to be :)
<KaiL> IFRFLY1: in synatic is one (if you use that)
<IFRFLY1> KaiL, I don't. Is there any way I can determine what was done by it, as I really don't relish the idea of reinstalling from the disk just to solve this one problem!
<xhaker> IFRFLY1, /var/cache/apt/
<xhaker> in there are the packages you installed
<xhaker> probably
<xhaker> if you didnt clean them
<xhaker> :P
<KaiL> IFRFLY1: but that kernel update was only a security patch, so this is VERY strange
<IFRFLY1> I wish I understood it and do not claim to. 
<IFRFLY1> I just know that suddenly the fan started running all the timne!
<IFRFLY1> I didn't clean the cache, though it was software update which installed it - I just signed off on it!
<IFRFLY1> Would the record be there or in some synaptic place?
<xhaker> IFRFLY1, /var/cache/apt/archives
<xhaker> the packages you installed recently are all there
<xhaker> they're downloaded to that location
<IFRFLY1> Thanks!
<xhaker> :)
<xhaker> check the attributes if you want to know when where they installed
<xhaker> and such
<IFRFLY1> Interesting. I see linux-image-2.6.10-5-386_2.6.1 0-34.1_i386.deb was installed. ...On May 20. Meaning that this is not - as several of you surmised - the problem. The only other install done has been mozilla-firefox_1.0.2-0ubuntu5 .3_i386.deb and mozilla-firefox-gnome-support_ 1.0.2-0ubuntu5.3_i386.deb, on the 24th. 
<xhaker> so there you have
<xhaker> your ears are super sensitive
<xhaker> lol
<IFRFLY1> Mmmm.
<KaiL> *g*
<IFRFLY1> It's possible that it is what several have considered: a hardware problem!
<KaiL> go on a party and it'll be solved *g*
<IFRFLY1> Everyone, thank you for your help and patience. 
<xhaker> np
<jdub> elmo: planet update please :)
<IFRFLY1> I guess I won't file that bug report now!
<tseng> jdub: yay!
<xhaker> mjg59, should i leave the bug unconfirmed or set it has new?
* xhaker is away (Away, bnc logging)
<daniels> KaiL: can you elaborate?  got any pointers?
<jsgotangco> morning
<lamont> Failed to fetch http://ia/ubuntu2/dists/breezy/universe/source/Sources.gz  MD5Sum mismatch
<lamont> where is mvo when I want to bitch at him?
<lamont> (that's when it fetches the .bz2 file, not the .gz file...)
<whiprush> jdub: fridge!
<fabbione> morning
* dilinger smirks
<dilinger>   # See, mom?  You *can* bubble exceptions in shell...
<dilinger> jbailey: when i think of all the times i've argued about that w/ my mom.. :p
<pitti> good morning
<fabbione> hey pitti
<Unfrgiven> pitti: gday
* Treenaks pokes Mithrandir's mail queue..
<Treenaks> I just got ~5 months old mail :)
<Treenaks> no wait
<Treenaks> I got mail he prepared 5 months ago, nm
<pitti> elmo: can we promote the new postgresql stuff to main today to resolve all these build failures?
<Amaranth> "The newer versions of the GNU Emacs documentation, meanwhile, uses the GNU Free Documentation License and makes use of "invariant sections" to force the inclusion of the same documents, additionally requiring that the manuals proclaim themselves as GNU Manuals, whether or not this would be accurate."
<Amaranth> i now know why the GFDL sucks
<\sh> anyone alive who can check, why libbonobomm1.3-9c2_1.3.8-2.2ubuntu1_*.deb is not on archive.ubuntu.com? it's compiled already since yesterday night ;)
<\sh> and why is libccrtp compiled (failed) without even an upload
<\sh> sourceuploaded new version libccrtp-1.3.1
<pitti> seb128: uh, gamin finally works now? I saw that you closed the upstream bug
<seb128> sjoerd dropped the patch for 0.1.0/Debian
<seb128> so I've tried with the while.... without the patch
<seb128> works fine
<seb128> let's assume that's fixed :)
<seb128> the other case described which was b0rked here too works fine with 0.1.0
<Amaranth> was the gamin stuff the reason gnome-menus doesn't update at all anymore?
<Amaranth> or is that a gnome-menus bug i should file?
<seb128> that's not a known issue
<seb128> since when
<seb128> what have you changed?
<Amaranth> 2.11.1
<Amaranth> upgraded to that, it stopped working
<seb128> works for me(tm)
<Amaranth> several other people have this problem
* pitti kisses seb128
<Amaranth> well, at least 2 others
<seb128> you can set GAM_DEBUG and send a debug log
<Amaranth> err
<infinity> seb128 : Will you take care of making sure gamin 0.1.0 gets synced?
<infinity> seb128 : I have an open Ubuntu bug which was closed in the Debian 0.1.0.
<Amaranth> can you put that in stupid terms (example command line)? it's 3am
<seb128> infinity: I've already synced it half an hour ago, why ?
<infinity> seb128 : Ahh, cool.  Then I'll close my bug. :)
<seb128> infinity: it fixes the libfam Conflicts stuff, you have a bug open about this IIRC
<infinity> seb128 : That's the one, yes.
<seb128> I was going to close it sometime today, but go ahead :)
<infinity> Closed.
<seb128> Amaranth: I don't get your bug, if you want to be useful open a proper bug with a debug log of what gamin is doing
<seb128> Amaranth: you can read gamin page on how to get a such log
<Amaranth> i don't know how to find out what gamin is doing
<seb128> I need to google for you?
<seb128> a sec
<Amaranth> ok, that'll have to wait until i've had sleep and remember to do it
<seb128> http://www.gnome.org/~veillard/gamin/debug.html
<seb128> read that 
<Amaranth> ok
<Amaranth> how do i kill gnome-panel and make it not start again on it's own?
<Amaranth> oh, i can just send it a signal
<seb128> gnome-session-remove gnome-panel
<Amaranth> I'm guessing the problem is Queue Full
<Amaranth> which is the bug in b.g.o about that part of the code needing to be completely rewritten
<Amaranth> the debug log is basically nothing but Queue Full
<seb128> you use inotify or dnotify?
<Amaranth> no clue
<Amaranth> i'm on the 2.6.10 kernel
<seb128> so probably dnotify
<seb128> and you have gamin 0.1.0 ?
<Amaranth> yeah
<seb128> k, I've no idea about your bug but that seems to be a gamin issue
<seb128> feel free to bug upstreams, but don't bug on gamin without following the upstream page and beeing clear on the bug
<Amaranth> pretty sure it's a gnome-menus bug, markmc has admitted that part of the code sucks
<seb128> how so?
<Amaranth> let me find the bug #
<seb128> gamin should not break even if the gnome-menus code is crap
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=172046 ?
<Amaranth> http://bugzilla.gnome.org/show_bug.cgi?id=160194 says it's fixed, the one you linked to says it isn't
<Amaranth> seb128: would this happening even with a 2.6.12 kernel prove it's a gnome-menus thing?
<Amaranth> i'm assuming gamin uses inotify on 2.6.12
<seb128> no
<seb128> gamin could be bugged as well
<Amaranth> ok
<Amaranth> Well, i'm going to bed. I'll try to get someone to help me figure out which tomorrow, I guess.
* Amaranth goes to bed
<seb128> later
<fabbione> elmo: ping+??
<pitti> fabbione: what's that, an increased ping? more urgency?
<fabbione> pitti: well i need to know how much he will hate me before i upload the next kernel, if the total amount of kernel binaries (in size) will be over a GigaByte
<bob2> jesus
<pitti> fabbione: yeah, given the current lack of hd space on jackass... :-)
<fabbione> mirrors might NOT like that
<fabbione> [   ]  linux-image-2.6.12-1-686-dbg_2.6.11.93-1.3_i386.deb          07-Jun-2005 09:57  147M
<fabbione> what's wrong with that?
<fabbione> ;)
<pitti> fabbione: then make the kernel arch:all and implement it in shell *duck*
<fabbione> pitti: that would be easier :)
<elmo> fabbione: err, WTF?
<elmo> dude, that's really not cool
<fabbione> ahaha
<fabbione> elmo: we know :)
<pitti> Hi elmo, howdy
<fabbione> i was just teasing you
<fabbione> we are finding another solution
<fabbione> elmo: i really really couldn't resit to see your face
<fabbione> "face" -> reaction
<pitti> elmo: do we need mdz for promoting packages to main? (the postgresql stuff, which causes ftbfs since it's still in universe)
<fabbione> from #ubuntu-kernel:
<fabbione> <fabbione> can you image over a GB of kernel push to the mirror on each update?
<fabbione> <fabbione> elmo will hang us on a cross, starts the witch dance and burns us alive
<pitti> fabbione: do we really need to have the -dbg packages in the normal archive? how many people actually use it?
<fabbione> pitti: no we can't push that to the archive.
<fabbione> pitti: we are thinking of another solution
<elmo> pitti: do we really want both versions in main?
<seb128> pitti: have you planned to roll language-pack updates soon?
<seb128> pitti: they changed the evolution translation domain to evolution-2.4 for the new version, so no it's not translated; which sucks
<pitti> elmo: I think so, we need 7.4 for upgrades and 8.0 for - well - it's the latest crack
<pitti> elmo: I have to support both anyway
<pitti> seb128: as soon as daf builds me a new tarball
<pitti> back, crappy network
<pitti> I lost everything after <seb128> pitti: they changed the evolution translation domain to evolution-2.4...
<pitti> seb128, elmo: ^ did you say anything to me after that?
<Burgundavia> pitti, no, he didn't
<pitti> ok, thanks
<seb128> <pitti> seb128: as soon as daf builds me a new tarball
<seb128> <pitti> back, crappy network
<seb128> pitti: nobody spoke between that
<pitti> got that, thanks
<pitti> elmo: thanks for the psql processing
<pitti> sjoerd: if you have some time to discuss the gvm stuff, just ping me
<sjoerd> pitti: this evening if you don't mind.. currently working 
<pitti> sjoerd: sure, that's fine
<elmo> Kamion: I just upgraded a box from piglet (!) to hoary and ended up without an ssh user... ever seen anything like that?
<Kamion> do you mean sshd?
<Kamion> there's no ssh user
<Kamion>         if ! getent passwd sshd >/dev/null; then
<Kamion>                 adduser --quiet --system --no-create-home --home /var/run/sshd sshd
<Kamion>         fi
<Kamion> that's run unconditionally in openssh-server.postinst; would getent passwd sshd have exited zero despite the lack of the user, for some reason?
<elmo> hmm, checking
<elmo> (obviously can't just ssh in ;-)
<elmo> can't see why that would fail - and it didn't when reran.  oh well
<Kamion> elmo: unless openssh-server.postinst fell over before that
<Kamion> it's set -e ...
<elmo> debconf was kind of upset as I purged it's front-end-of-choice, but I didn't think that'd be enough to not run the rest of the postinst?
<elmo> and dpkg definitely exited 0, not with an error
<Kamion> no, debconf should fall back cleanly
<Kamion> hm, I'm looking at current trunk, I'll dig out hoary
<Kamion> same thing
<Kamion> could adduser have failed silently?
<elmo> it's possible I guess, I'm not sure what adduser was installed at the time
<elmo> Kamion: sorry, don't worry about it, it's a fairly odd ball machine, with a unique setup, I just wondered if it's something you'd seen elsewhere - if not, I'm happy to ignore it
<Kamion> elmo: it's not something I've heard of, certainly; just don't like to rule out weird shit
<elmo> how have apple (or someone) NOT got sued for bodily harm resulting from the front facing laptop cd drives ejecting
<Treenaks> elmo: expensive lawyers & disclaimers, probably
<mdke> elmo, you can be the first
<thom> elmo: because fortunately no-one sells sharpened cds yet
<mdke> *grins*
<jbailey> dilinger: =)
<Kamion> I See A Great Need
<nictuku> what are udusessions?
<Kamion> UDU == Ubuntu Down Under == our last conference
<Treenaks> thom: shuriken-shaped CDs... *hmm*
<seb128> pitti: http://lists.freedesktop.org/archives/xdg/2005-June/006986.html
<pitti> seb128: I read it, thanks for the link
<seb128> np
<netdur> I use windows at moment, I'm downloading eclipse to re-compile some test code I made on ubuntu, now I'm downloading 87 MB and still able to browse web sites pretty fine, on ubuntu downloading process "eat all bandwidth" which make other uses of net a pain... mayeb should be there a way to control/limit how many bandwidth a software may use
<sladen> netdur: QoS out-of-the-box.  Can you add it to the Ideas page?
<netdur> okay
<jbailey> Kamion: ping?
<Kamion> jbailey: pong
<jbailey> Kamion: Is /etc/kernel-img.conf generated by d-i?
<netdur> sladen, wiki url!?
<Kamion> jbailey: yes
<jbailey> Kamion: Tx.
<Kamion> jbailey: partly, at least ...
<Kamion> jbailey: base-installer and the various bootloader installers cooperate to get something useful in there - I'm not sure if .debs have a say as well
<mdke> netdur, IdeaPool
<jbailey> Kamion: We were applying dpkg -S to it to see if someone provided it originally and not coming up with anything useful.
<sladen> netdur: http://www.ubuntulinux.org/wiki/IdeaPool  for hit on Google for   ubuntu ideas
<sladen> first hit
<netdur> I found :) I did search wiki for "idea pool"
<fabbione> seb128: ping????
<seb128> pong!!!!
<fabbione> seb128: why did you reenable inotify backend in gamin?
<seb128> why not?
<Lathiat> apparently it doesnt suck so bad now
<fabbione> it's utterly broken, it crashes and people keep ranting that it's a kernel problem
<seb128> it's supposed to work fine now, and we are not in freeze or whatever
<tseng> 0.1 is greatly improved WRT inotify
<Mithrandir> tseng: 0.1! That MUST be stable! :P
<seb128> fabbione: feel free to reassign bugs to gamin
* Mithrandir  hides
<tseng> Mithrandir: i said greatly improved, not stable :P
* ogra _is_ freezing over here !
<Mithrandir> tseng: "now crashes immediately rather than taking five seconds!" :P
<tseng> Mithrandir: hah!
<fabbione> seb128: ok, just that you know :)
<seb128> fabbione: you got a lot of complain since yesterday ?
<tseng> dsd and this other guy have done a ton of work on inotify + gamin now
<tseng> the old one we had problems with was alot of stub code
<tseng> missing features in the dnotify backend
<fabbione> i did disable it exactly because we were pushing kernel crack :)
<fabbione> seb128: it was uploadedd this morning :)
<tseng> like allowing to fall back to polling
<tseng> for things like /media
<fabbione> seb128: difficult to get complains so fast
<seb128> dunno, you are complaining about user bugging the kernel
<seb128> some people are kick to rush into troubles :)
<doko> pitti: pike FTBFS
<doko> 7.4
<fabbione> seb128: well they did a lot with the previous version.. it's not like i love to upload your packages MrSebrobot128 :)
<seb128> fabbione: anyway let's see how it works, should be better now
* fabbione gets ready for long debugging sessions... again
<seb128> one of the gnome-vfs guy is working to use inotify directly without using gamin apparently
<elmo> what the hell?
<elmo> some build install ntp-server into the chroots
<elmo> gar, go nagios-plugins
<jdub> daniels: STOOOOOOOOOOONER!
<jdub> daniels: my X refuses to believe that i am typing!
* jdub seriously considers returning to hoary
<ogra> jdub, get via voice....
<jdub> ogra: interesting suggestion, but not a viable solution :)
<pitti> doko: thanks, I have a look
<pitti> doko: oh, that's still the old failure from the time when libpq-dev was still in universe
<pitti> seb128: ++
<pitti> seb128: do you know the progress of that?
<seb128> gicmo was coding on it 2 days ago
<elmo> and how the _hell_ did ntp in the chroot take out ntp in base
<infinity> "take out", as in one in the base stopped running?
<elmo>                 if [ "$1" = "install" ]  || dpkg --compare-versions "$2" lt 1:4.2.0a-10
<elmo>                 then 
<elmo>                         killall ntpd || true
<elmo>                 fi
<infinity> Either a bad init script, or ntpd's usual fragile "I fall over at the first sign of trouble".
<elmo> rock on mister ntp maintainer
<infinity> Oh, yay.
<elmo> 'cos "" is probably lt anything
<elmo> smurfix: DUDE
<Mithrandir> killall is SUCH A GOOD IDEA to have in maintainer scripts.
<infinity> killall in scripts is bad, mmkay.
<Treenaks> Mithrandir: let's make it POLICY
<elmo> is build-depending on daemons so you can do path checks in configure sane?
<infinity> No.
<infinity> I hardcode daemon locations.
<elmo> what's the alternative tho?  hard-code?
<elmo> ok
<Mithrandir> why should it do path checks, really?
<elmo> Mithrandir: variable paths between unices?
<infinity> The only excuse to build-dep on a daemon is if you need it for testsuites (like that crazy libapache2-perl-apreq package)
<Mithrandir> elmo: PATH is a run-time thing, I think they should just use that.
<Mithrandir> elmo: unless you mean "look in weird non-PATH directories"
<infinity> And we['ve put a lot of work into apache2 to make sure it behaves in chroots, specifically for that weirdass use case.
<elmo> Mithrandir: oh, well, there is that
<Mithrandir> in which case hardcoding is good, since we're like, a distribution, and supposed to know where we put our stuff.
<elmo> oh,yay, nagios is no longer turbo's - there's a chance this bug I'm filing may actually get read
<infinity> Turbo is my favouritest person ever.
<Kamion> should be lt-nl not lt
<infinity> I love that "roxen4's logrotate script kills MySQL every week" bug.
<Mithrandir> infinity: nobody's used roxen4 for a week, so it'd take a bit of time for anybody to notice.
<infinity> <snicker>
<elmo> Kamion: aha, thanks forgot about those
<elmo> how did roxen reach 4 anyway?  or is that just the number of users world-wide?
<Kamion> haha
<Mithrandir> elmo: they rolled a die, I guess.
* mvo snickers
<JaneW> seb128: thanks for the breezygoal update :)
<JaneW> seb128: is it complete complete, or is testing and tweaking still likely?
<seb128> np ;)
<seb128> some feedback doesn't hurt but it should be fine
<JaneW> seb128: ok, well feel free to move it right to 'implemented' when you think it's 100% - that will earn you a 'gold star' ')
<seb128> k :)
<diego> ooh a gold star? nice
<diego> are they shipped for free?
<pitti> no, you got to earn them
<Treenaks> diego: gold is cheap in .za, they have mines there ;)
<diego> pitti: but say i were to earn a gold star, would it be shipped to me for free?
<pitti> hehe
<pitti> seb128: btw, rhythmbox still locks up with the new gstreamer
<ogra> grrrr
<ogra> ./TLS_AsciiConvertor.hpp:32:22: error: X11/Xlib.h: No such file or directory
<ogra> hmm, libx11-dev is a build dep....
<seb128> pitti: a guy put a comment to say that's fixed witht he new alsa
<seb128> pitti: and it works for me
<pitti> seb128: new == 1.0.9?
<pitti> or the rc3 we have ?
<seb128> current ubuntu one
<JaneW> pitti: yes it;s shipped for free, but since it's part of your earnings you would be taxed on it :P
<seb128> ie: a guy added a comment like 2 hours ago saying it's fixed for him
<seb128> and that works on my box today
<pitti> seb128: oh neat, 1.0.9 was autosynced, upgrading now...
<pitti> seb128: yay, works! thanks; I seemed to remember that this was a gstreamer issue, sorry for bothering
<seb128> np
<seb128> it has been pointed as a gstreamer0.8-alsa issue
<seb128> since downgrading this one fixed the issue
<seb128> but the new alsa fixes the issue, so maybe a version mismatch issue or something
<seb128> anyways that works now
<Lathiat> mjg59: so will canonical buy me a docking station for the purposes of testing? :)
<mjg59> Lathiat: Haha. We'll see.
<Lathiat> mjg59: cus i dont need a whole new laptop :) 
<doko> jdub: perl time!
<jdub> ;-0
<jdub> ;-)
<Lathiat> doko: are you going for like the highest uploader? :)
<ogra> Lathiat, he's trying to cope with seb128 ;)
<pitti> do"I kill the buildds"ko
<Lathiat> hehe
<pitti> Hi sabdfl 
<mvo> mjg59: did you get the report about the compaq notebook I send some days ago?
<mjg59> mvo: Yeah
<mvo> mjg59: anything I can do? 
<mjg59> There's a few things I need to catch up on first
<mvo> sure
<jdub> ok, so
<jdub> current X, i can't type or hit ctrl-alt-del
<jdub> known issue with the very latest upgrade?
<\sh> message.data.address = (uint32)(&message);
<\sh> hmmm....
<\sh> this will give an error...
<\sh> hmm
<ogra> jdub, works here
<mdz> pitti: I thought we already discussed postgresql?
<pitti> Hi mdz 
<mdz> morning
<mvo> morning mdz
<pitti> mdz: yes, I asked elmo to sync the archive to the new seeds
<pitti> mdz: libpq-dev was still universe this morning
<pitti> mdz: it's settled now, depending packages have built/are building
<\sh> going home...then more
<mdz> ok
<pitti> mdz: btw, I am already hacking heavily on http://udu.wiki.ubuntu.com/AudioInfrastructure
<pitti> mdz: but that is not yet formally approved
<pitti> mdz: is this mdz or Kamion approval-ish?
<mdz> pitti: I'll look over it now
<mdz> pitti: has the reconsideration of polypaudio happened yet?
<pitti> mdz: Erik de Castro wrote me a mail a few days ago where he said that he fixed some important bugs
<pitti> mdz: right now we have gstreamer->alsa directly, but I think this might be too hot for breezy
<pitti> mdz: so yes, I'd like to give polypaudio another shot soon
<pitti> mdz: (we can't use esd, it sounds terrible with the new alsa)
<bob2> pitti: with gstreamer or dmix doing the mixing?
<sabdfl> whoohoo! once more into the sound breach, boys!
<sabdfl> have we reviewed dmix for stability?
<pitti> bob2: dmix, gstreamer doesn't mix (at least not by default)
<pitti> sabdfl: breezy is using it right now :-)
<sabdfl> iirc that was considered the best strategy long term, once dmix stabilised
<bob2> pitti: pimpalicious
<Lathiat> gst+dmix wfm (tm)
<jdub> dmix is b00000rk ;)
<pitti> sabdfl: it works fine on many devices, but it is said to break on many as well, that's why I'd like to use polypaudio for breez
<sabdfl> ok
<pitti> sabdfl: so we have dmix for non-esd/gstreamer applications that will work now (in contrast to hoary, where esd blocked the whole audio card)
<pitti> but we still keep the esd interface and have polypaudio do the gstreamer mixing, which is (said to be) more robust
<jdub> elmo: planet update please :)
<wasabi_> Is dmix what I think it is?
<wasabi_> Finally.
<elmo> jdub: you so typoed the css didn't you?
<jdub> elmo: i did not baz add the new planet.css :)
<jdub> elmo: quick, record your laughter!
<elmo> jdub: done (baz, not laughter)
<pitti> wasabi_: it's mixing in the alsa library, without any sound daemon
<jdub> elmo: gar. having withdrawal symptoms.
<jdub> (thanks)
<wasabi_> ssh could totally do with proper kerberos support. *growl*
<wasabi_> or at least the ability to read keys from ldap
<scorpix> when will the next ubuntu colony will release?
<Kamion> scorpix: when it's ready
<Kamion> seriously
<scorpix> there's no roadmap for it?
<Kamion> no, colonies are "when it works well enough to release"
<wasabi_> we don't need roads where we're going.
<Kamion> scorpix: it's almost certainly overdue, but on the other hand the dailies haven't actually been sufficiently bug-free to release for some time
<Netsnipe> hey everyone
<scorpix> so, is breezy will come with selinux/pax/exec-shield by default? or we'll have to download a hardened kernel?
<pitti> scorpix: we might get selinux, but not pax/ES by default
<scorpix> nice
<pitti> ajmitch: btw, any news wrt the selinux packages?
<scorpix> more derotification will be good also ;)
<scorpix> *derootification
<pitti> scorpix: what in particular?
<pitti> scorpix: X.org is a really tough one :-)
<Netsnipe> I need some opinions on how to fix Debian #311109: gnome-applets: SUID handling via debconf for cpufreq-applet
<elmo> pitti: wimp
<pitti> elmo: sudo sed -i 's/root/nobody/' /etc/passwd
<Netsnipe> since the debconf stuff hasn't been ported from the stand alone package to the 2.10 gnome-applets package either
<Netsnipe> two questions concerning ubuntu policy
<Netsnipe> 1. how sensitive are you guys to SUID bits for hardware controlling programs
<elmo> pitti: ok, running that on *.ubuntu.com.  thanks for the tip dude!!
<pitti> elmo: see? it's easy :-)
<Netsnipe> 2. and should a standard desktop install raise any debconf questions to begin with.
<thom> elmo: about as good an idea as removing libnss-db... ;-)
<pitti> Netsnipe: Ubuntu policy mandates that (2) doesn't happen
<\sh> re
<pitti> Netsnipe: (1): if it is small and auditable, really justified, and gets a review, that's considerable
<elmo> thom: ouch
<pitti> scorpix: seriously, do you have a good target for derooting?
<Netsnipe> pitti: ok. I'm setting the priority=low (seb128 and np237 from #gnome-debian have agreed on that)
<thom> elmo: *g*
<pitti> scorpix: I still have unix_chppwd, hplip, and arpwatch on my list
<Netsnipe> now the question that remains is...what should the default be?
<Netsnipe> It should just work (TM) and default the cpufreq selection tool to SUID 
<pitti> Netsnipe: we have priority high as default, so even normal would work (for Ubuntu, that is)
<pitti> Netsnipe: if it doesn't work without setuid, then the question is rather unnecessary, or does it?
<Netsnipe> or be paranoid, disable it, and bury the fact you have to turn it on for the applet to be able to change CPU speeds on the fly in the README
<scorpix> pitti: im trying to remember how to get the suid programs
<Netsnipe> that's what duck has done right now (but without the debconf question)
<Netsnipe> pitti: you need SUID
<Netsnipe> pitti: otherwise you can't do jack to sysfs
<Netsnipe> s/to/in/
<Netsnipe> pitti: the applet still works if the selector isn't SUID. it just displays the frequency
<Netsnipe> and doesn't let you set it
<pitti> Netsnipe: ah, so the wrapper would basically do the equivalent of "echo speed > /sys/.../frequency"?
<Netsnipe> pitti: yep.
<pitti> Netsnipe: then it should be 4751 and restricted to a "desktop" group
<ogra> Netsnipe, cant you do that through dbus/hal ? 
<pitti> ogra: how so?
<pitti> ogra: you still need a setuid wrapper for the call
<Netsnipe> ogra: cpufreq is still sysfs as far as I know
<ogra> 0.5.0 should be capable with the acpi patches from richard huges... it would need a little hack...
<pitti> Netsnipe: erm, to get me right, the only thing that is setuid is the echo speed thing, nothing more, right?
<scorpix> pitti: add cups to your list if possible :)
<pitti> scorpix: huh, that happened in warty
<pitti> scorpix: that was one of the most important things to do since cups is complex and had many vulns 
<ogra> pitti, it should not be different to the dmidecode integration....
<pitti> ogra: right, but that required a suid wrapper, too
<scorpix> pitti: i get /etc/cups/ as setuid !!
<Netsnipe> pitti: yes
<pitti> scorpix: www.ubuntulinux.org/wiki/DerootificationStatus
<ogra> pitti, yes, but behind hal, tightly tied to the hal group... which seems somewhat safer
<pitti> ogra: that doesn't work, since the user has to change it. dmidecode does not need to be parameterized by the user
<pitti> scorpix: drwxrwsr-t  4 cupsys lpadmin 544 2005-05-30 09:49 /etc/cups/
<pitti> scorpix: ^ what's wrong about that?
<scorpix> pitti: i forget that it should be /etc/bin/***, my fault
<pitti> Netsnipe: it should be a group like "video"; video isn't meant for that, but the group should have the same privilege level
<ogra> pitti, afaik the acpi patches from richard are capable of doing two way communication.... i just packaged gnome-power, it uses send and recieve on the dbus.... and we will need something similar to the above to handle the pmi calls from power-manager
<Netsnipe> pitti: I'm not going to hack the kernel just to change the perms on a sysfs node
<pitti> ogra: is setting the property restricted in any way?
<Netsnipe> the question really boils down to
<zyga_> hello
<Netsnipe> de we default to SUID and have the applet Just Work (TM) as advertised
<Netsnipe> or be paranoid and leave it disabled and hope the user reads the README
<zyga_> what is the recomended filesystem for / ext3 or ext2?
<Netsnipe> and is brave enough to run dpkg-statoverride him/herself
<ogra> pitti, i'm not sure... but what i'm saying is that we have to implement something similar anyway.... 
<pitti> phone
<ogra> Netsnipe, we dont do such things to our users ;) (running things like dpkg-statoverride)
<bob2> zyga_: #ubuntu, but ext3.
<ogra> Netsnipe, so the solution should follow the "just works" approach
<Netsnipe> ogra: but that goes against my Debian instinct
<Netsnipe> enabling SUID root without asking the user
<Netsnipe> seems to be against tradition
<wasabi_> I guess that's why we aren't Debian.
<ogra> Netsnipe, if it can be wrapped in a safe way, its ok...
<Netsnipe> oh well
<Netsnipe> it's not as if cpufreq-selector is listening on any sockets
<ogra> no, bu the things it does should be done through hal, thats what its for....
<pitti> back
<Lathiat> Netsnipe: ping doesnt tell me its setuid root, nor does passwd. :)
<pitti> ogra: the problem is: if you call the wrapper directly, then you can restrict it to a group; if you allow calling through hal, then *everybody* can change the cpu frequency, which is not desirable
<pitti> ogra: the hal approach worked fine for "output-only" things like dmidecode, but not for things that need input from users
<ogra> pitti, but doesnt "Hardware Abstraction Layer" somehow imply that you do interaction to your hardware through it ? :)
<pitti> ogra: right, that was asked for very often, but you open a can of worms wrt authentication
<ogra> pitti, but some day it has to get implemented...
<pitti> I'm not a big friend of hal doing hardware settings...
<ogra> else this thing is nice, but fails its target....
<wasabi_> I am. Because every other OS does it. And they do it fine. =)
<scorpix> pitti: will initng or cinit be in breezy?
<pitti> ogra: depends on how you define its goal
<ogra> pitti, "Hardware abstraction Layer" ;)
<pitti> ogra: if the goal is to provide an abstracted interface for getting hardware information and hotplug events, then hal works just fine :-)
<wasabi_> And interacting with, i'd hope. ;)
<Netsnipe> ogra: I've got the ITP on gnome-power-manager in Debian
<pitti> ogra: it's not "Hardware mangling layer" :-)
<ogra> pitti, a layer has two surfaces ;)
<Netsnipe> ogra: we should swap IM details = )
<pitti> scorpix: no idea
<Netsnipe> ogra: it's stable/useful enough for distribution now? I've put it on hold until Sarge was out
<Kamion> scorpix: erm, setgid directories != privilege elevation
<Kamion> ogra: dpkg-statoverride is a lot better than how it used to work. :)
<ogra> Netsnipe, the backend is missing.... it looks nice and runs stable
<wasabi_> I'd go a step furthur and replace gnome-system-tools' backend with HAL.
<wasabi_> Well, the network part of it. ;0
<Netsnipe> ogra: the backend is missing?
<Netsnipe> ogra: so it does nothing?  = P
<ogra> Netsnipe, exactly :)
<pitti> yay, a shiny GUI
<ogra> Netsnipe, and if it would do something i guess it would be very redhat-ish
<ogra> Netsnipe, which i doubt is compatible to the way we do powermanagement in ubuntu....
<wasabi_> Crazy. When I click on a mms:// link in Epiphany, totem launches.
<wasabi_> And quickly says no handler installed to handle it.
<jbailey> Mmm..  Segfatuls, sweet sweet segfaults.
<\sh> looks like i will get all the showstoppers today
<\sh> libpq-dev 
<\sh> is not going to be installed
<ogra> \sh, its not better on my side....
<ogra> unicon breaks with an Xlib.h not found.....
<ogra> tyvis cant find libclutils.a
<Kamion> Yay, now X just totally hangs my console on a fresh breezy install
<ogra> heh.... yes, X is always good for fun....
<ogra> Kamion, i had a neon green frame on my desktop display for the last week.... no keyboard input accepted.... but ssh worked fine... 
<Kamion> I wouldn't care if I could actually release Colony CDs
<zyga_> chattr man page says that 'c', 's' and 'u' are not implemented - could anyone kernel savvy confirm this?
<zyga_> I'm hacking chattr
<Netsnipe> morning jdub 
<Netsnipe> doh. reconnect
<mdz> elmo: does your sync tool allow me to easily get a list of the packages which are out of date with respect to merging?
<elmo> mdz: beyond the lorraine needs merged output?
<elmo> mdz: in any event 'josie -an' in ~/scratch/1 will give you even more verboseness
<elmo> (yes, the path stuff is ueber lame)
<mdz> elmo: I don't know lorraine
<elmo> mdz: it's what mom deals with
<elmo> /srv/ftp.n-n-y.com/www/lorraine/
<mdz> elmo: so needs-merged reflects everything which is currently out of date, and not just the ones which are new since the last run, right?
<elmo> mdz: right
<elmo> and it's run in cron.daily
<elmo> so it's everything and up-to-date
<mdz> ok, that's exactly what I wanted then, thanks
<jdub> no janew?
<ogra> jdub, she wanted to try to be back for CC
<mdz> Kamion: ISTR this coming up before, but I don't remember the outcome...---passphrase-fd for openssh?
<mdke> what language is this? https://www.ubuntulinux.org/wiki/InstalandoPlacaWirelessComNdiswrapper
<mdke> pt?
<pitti> lamont__: do you know why qt-x11-free 3:3.3.4-1ubuntu5 is not attempted to be built?
<lamont__> pitti: libs/qt-x11-free_3:3.3.4-1ubuntu5: Dep-Wait by buildd+rothera [optional:out-of-date] 
<lamont__>   Dependencies: libmysqlclient-dev
<lamont__> kicking
<pitti> lamont__: ah, thanks; is there a similar problem with pike-7.{2,4,6}?
* lamont__ is kicking _all_ the build-deps
<lamont__> iz big hammer
<pitti> lamont__: iz nice from you :)
<mwh_> hi, im trying to find out what goes wrong when im inserting my usb, flash card reader, it does not get mounted automatically and shown, I want to find out what is wrong so I can write a bugreport, maybe some of you can help me
<mwh_> it normally works
<mwh_> I use ubuntu hoary
<mwh_> dmesg shows that the kernel finds the flash reader
<mwh_> and I can manually mount it
<mwh_> so I guess it might be higher in the software stack
<mdz> pitti: have we disabled the use of /etc/fstab for cdroms yet, so as to use pmount instead?
<mwh_> maybe some service which needs to be restarted
<mwh_> btw the device was pluged in during boot
<mwh_> maybe thats the cause I have to test that
<mdz> mwh_: http://www.ubuntulinux.org/wiki/DebuggingRemovableDevices
<mwh_> anyways, anyone of you heard of something similar to this
<pitti> mdz: no, we didn't disable it
<mwh_> mdz: thanks
<pitti> mdz: by keeping it in fstab, you see icons in the computer place even if there is no CD inserted
<pitti> mdz: which is not a big deal, though
<lsuactiafner> thing is usb is sdb for ppl with 1 sata disk
<mdz> pitti: does the icon provide some functionality?
<lsuactiafner> i have two.. so my usb is sdc.. can be problematic
<lsuactiafner> and some disks have partitions that start on sdc2 not sdc1 as expected.
<pitti> mdz: hmm, not really
<ogra> mdz, you could manually mount with a doubleclick if g-v-m fails... 
<pitti> mdz: ^ well, yes
<lsuactiafner> or just make an alias.. alias usb='mount -t auto /dev/sdc /mnt/Usb'
<ogra> but given that it doesnt fail *shrug*
<pitti> lsuactiafner: that needs root, please rather use pmount for removable devices
<pitti> mdz: does fstab hurt?
<ogra> pitti, it desnt react dynamically if yo add a nem CD-Rom or writer..... hal/g-v-m/pmount does :)
<ogra> man.... what am i typing...
<mwh_> mdz: great guide, ill fill a bugreport imediately
<pitti> ogra: oh, if you just add one, you will get a new icon if you insert a CD
<ogra> pitti, yeps, but fstab still has old entrys if you remove one for example...
<pitti> ogra: right
<ogra> imagine a usb CD-ROM/Writer plugged into a laptop at install time...
<pitti> I'm not opposed to dropping the fstab stuff
<pitti> however, that's a Kamion thing since the installer creates the fstab
<mdz> pitti: it relies on certain paths on disk, can't adjust for hardware changes, etc.
<mdz> pitti: the less configuration we do in the installer, and the more we adapt on the fly, the better I think
<pitti> mdz: right
<pitti> mdz: I think it is easy for Kamion to just disable that part in the insaller
<Lathiat> has anyone noticed/fixed the bug where if you have a usb hard drive plugged in during install it puts /dev/sda instead of /dev/sda1 in fstab?
<mdz> pitti: yes, and early so that we get plenty of feedback
<mdz> pitti: can you follow up with him so that it gets done?
<pitti> mdz: sure
<mdz> Lathiat: if you're installing to the USB hard disk, that isn't supported yet
<Lathiat> mdz: nah not installing to it
<Lathiat> it was just plugged in at the time
<mdz> Lathiat: so you did manual partitioning and asked that it be mounted?
<Lathiat> didnt set it up or anything
<Lathiat> mdz: no, it just stuck it in fstab for me
<Lathiat> without touching it
<Lathiat> and it puts sda instead of sda1
<mdz> ubuntu 5.04 doesn't do that
<Lathiat> yes it does
<Lathiat> for me, at least
<mdz> Lathiat: please show me the fstab entry
<Lathiat> humm
<Lathiat> i'll have to do an install
<Lathiat> all i can remember is it was along the lines of /dev/sda /media/usb0 ext3 defaults 0 0 right now
<Lathiat> the first 2 i remember correctly, not sure about the rest
<Lathiat> i'll try it out and let you know if you want
<mantiena> Hi all
<mantiena> Kamion: thanks for good working casper-automount ;)
* mantiena tested partition automouting on about 5 computers... past 2 days ;)
<allee> mjg59: ping?
<mjg59> allee: Hi
<allee> mjg59: Not all laptops here run (k)ubuntu yet ...
<mjg59> allee: What's the issue?
<allee> mjg59:  are debian keycodes reports useful too?
<mjg59> All keycodes are useful
<mjg59> :)
<allee> mjg59: I tried 4 external USB keyboard today.  Looks like the kernel map them already to useful keycodes
<allee> mjg59: so support for them will be easy ;)
<allee> mjg59: keycodes have you looks at, e.g., lineak?  It's config file contains lots of keycode definitions
<mjg59> Yeah, I've checked that. I'm concentrating mostly on laptops at the moment, since it's a lot easier to work that out
<mjg59> The problem with external keyboards is that there's no way to tell if a PS/2 keyboard is a Microsoft or a Logitech, and they use different mappings
<allee> mjg59: yeap.  But external usb should be easy (if one can define 160 keycodes even is keyboard has on 105)
<elmo> why on EARTH didn't they add keyboard type to the USB keyboard stuff?
<Mithrandir> elmo: because they wanted sun to look good, or something.
<mjg59> allee: Yeah, we can tell what sort of USB keyboard is in use, but we still need to have a static table of mappings in some cases
<allee> elmo: for me it looks like logical keys emit same keycodes.  So AFAI can see one can use one mapping for 'all' external keyboards
<allee> mjg59: I plan to try a  pc10* + huge-usb-extern map.   AFAIU yet.  This should work  (+ a little model-specific map)
<mjg59> allee: Yeah, that sounds good
<allee> mjg59: okay.  looks like nothing obvious against my plan.  I go for it.   Thx
<hunger> any estimation on when wine will be installable again in breezy?
<Treenaks> hunger: when it's fixed? 8)
<ogra> hunger, not after october ;)
<hunger> Treenaks: Ok. so it is a known issue?
<Treenaks> hunger: I don't know :)
<hunger> I do not need to write a bugreport then;-)
<lupusbe> daniels X server won't start after upgrading to latest packages it complains about not finding fixed fonts
<lupusbe> breezy
<Kamion> mantiena: cool
<Nafallo> lupusbe: change your fontpaths in xorg.conf to /usr/share/X11/fonts/*
<chol> hiya, do you know if there's a problem using a hpux remote font server with ubunto/xorg?
<lupusbe> Nafallo k thx but is the program that updates xorg.conf fixed for this?
<chol> or perhaps if it doesn't like "tcp/localhost:port" as opposed to tcp/remote_ip which works
<lupusbe> or should I open a bug report :)
<Nafallo> lupusbe: dunno. ask daniels ;-).
<lupusbe> :)
<chol> fslsfonts works with localhost:port to hpux server but xset +fp doesn't...
<dholbach> hi
<chol> xfree on debian works aswell
<lupusbe> the paths point to /usr/share/X11/fonts/* but there is no fonts.dir file in the directories
<syndicate> This might be a long shot, but where is Scsi_Host_Template defined in the kernel headers?
<syndicate> I'm trying to compile the UNH-iSCSI initiator under hoary
<chol> syndicate, grep -r is your friend :)
<syndicate> yeah, it's not there
<zul> syndicate: try include/scsi/scsi_host.h
<chol> ah.. well i've had alot of problems building fiber channel software with 2.6 kernels
<syndicate> ahh well, that didn't work either
<syndicate> I guess I'll pester the UNH people :D
<lupusbe> can someone tell me how I can regenerate fonts.dir files
<lupusbe> or what is wrong :)
<chol> lupusbe, mkfontdir, ttmkfdir, mkfontscale, fc-cache
<lupusbe> isn't there a deb package that I can run or something :)
<lupusbe> dpkg-reconfigure  something like that
<chol> lupusbe, try :) update-fonts-*
<Kamion> dpkg-reconfigure is *only* for debconf
<Kamion> it's not a catch-all do-everything. :)
<chol> lupusbe, but they for sure depends on some other config
<lupusbe> :)
<shaya> hmm
<shaya> new gnome-menu/panel got rid of crossover's windows menu
* shaya looks at seb
<Lathiat> menu-xdg might help
<shaya> root@dent:/usr/share/doc/gnome-menus # dpkg --status menu-xdg |grep Status
<shaya> Status: install ok installed
<chol> lupusbe, what is it that doesn't work?
<chol> lupusbe, for adding truetype fonts, put them in ~/.fonts, run ttmkfdir in that dir, and then run fc-cache to update
<lupusbe> chol it says that it can't find the default font
<lupusbe> fixed 
<chol> lupusbe, oh.. i know that one.. run into it a few times
<chol> but i have to figure out how to fix it every time...
<chol> lupusbe, try running fc-cache -f
<chol> as root then, could take a while to finish
<mdke> thesaltydog, wela
<thesaltydog> cia matt
<mdke> how's things?
<thesaltydog> mdke, just back from work. Too much..
<pitti> seb128: do you know whether it's possible to tell gnome-volume-control to show a particular device initially?
<thesaltydog> mdke, I have seen that the doc team is not very active on the list in wiki..
<seb128> pitti: there is a /apps/gnome-volume-control/active-element gconf key, maybe with that?
<pitti> seb128: nobody will beat me up if I change that in g-v-m at runtime?
<pitti> seb128: I hoped for some command line option, but there doesn't seem to be a (documented) one
<seb128> over user, or by asking?
<pitti> seb128: the idea is: http://people.ubuntu.com/~pitti/audio.png
<seb128> a sec
<pitti> seb128: i. e. I plugin my headset
<pitti> seb128: I get the upper dialog (with the "Configure..." button, "Einstellungen" in German)
<pitti> seb128: this button spawns g-volume-control
<pitti> seb128: but it would make sense to select the device just plugged in, not the default device
<shaya> seb128:     - use the current version of gtkhtml, thanks Daniel. (hmph)
<seb128> what?
<ska-fan> Urgh, yes no answers
<shaya> my name isn't daniel!
<seb128> shaya: dholbach (his name is Daniel) pinged me on IRC about this before I upload
<dholbach> shaya: shortly before you reported the bug, i tried to upload a fixed version - my name is daniel :)
<seb128> I've read the bug after uploading
<seb128> shaya: thanks anyway :)
<shaya> ah
<seb128> pitti: /j #gstreamer please
<shaya> oh well
* shaya goes off to hide
<shaya> actually, before I do that
<shaya> menu aint working :)
<allee> mjg59: ping
<shaya> new panel/menu packages got rid of crossover menu
<shaya> also no run menu right now
<shaya> run menu I dont know if by choice
<shaya> but I doubt the crossover menu issue is
<shaya> and now I go off and hide
<thesaltydog> dholbac1, good evening. I have a question.
<dholbac1> thesaltydog: fire away
<dholbac1> hi :)
<thesaltydog> dholbac1, I have just seen your remarks on the package. Thanks. The question:
<seb128> shaya: what do you mean about crossover?
<thesaltydog> dholbac1, is concerning the changelog. BUM is noe 1.2.7 and I would like to include all the preceedings changelogs..
<dholbac1> those are upstream changes?
<dholbac1> you can have them in ./ChangeLog
<thesaltydog> no, this is the very first upstream version, but it is 1.2.7 from development and distribution
<dholbac1> if 1.2.7 is the first ubuntu revision, the initial package, it should be there
<dholbac1> yeah
<dholbac1> one 1.2.7 entry in debian/changelog
<dholbac1> but the "upstream history" in ./ChangeLog
<thesaltydog> ./Changelog should be a text file in which dir?
<dholbac1> one will end up in /usr/share/doc/bum/changelog.gz and the other in /usr/share/doc/bum/changelog.Debian.gz
<dholbac1> directly in the source tree
<thesaltydog> ok
<thesaltydog> sorry but I am a developer, not a packager!!
<dholbac1> that's where you document source changes
<Kamion> thesaltydog: might be better to work with a packager, then
<dholbac1> yeah... you should have a changelog for your project as well :)
<Kamion> and have them release 1.2.7-1, etc.
<thesaltydog> Kamion, I have asked for... but I am still waiting so I have decided to study.:-(
<dholbac1> we're short on maintainers, thesaltydog - everybody has to be patient atm
<shaya> seb128: crossover office
<shaya> wine
<thesaltydog> dholbac1, I am patient. In the meanwhile I am trying to help myself..
<dholbac1> thesaltydog: that's good
<shaya> they create their own menu that windows apps that create "program" entries go into
<shaya> with new gnome stuff it disappeared
<thesaltydog> dholbac1, so don't you mind if in the next days I will bother you more?
<seb128> so that needs to be fixed
<shaya> well it just disappeared in latest upload
<shaya> dont know what would have changed to get rid of user menu entries
<dholbac1> thesaltydog: just add a comment on MOTUNewPackages, so people will know you cleared those issues
<thesaltydog> dholbac1, I'm going to fix right now. Thanks a lot.
<dholbach> thesaltydog: de rien
<thesaltydog> ciao to all
<shaya> seb128: is it possible that before .gnome/apps was being pulled in, but not anymore?
<shaya> hmm, ~/.menu that is
<lupusbe> someone with breezy here?
<seb128> would be weird
<shaya> yes
<shaya> I would think most people here have breezy
<lupusbe> shaya can you do cat /usr/bin/mkfontdir
<lupusbe> and give me the output
<louie> lupusbe: at least here, that still points at /usr/X11R6/bin/mkfontscale
<lupusbe> idd
<lupusbe> this is wrong
<torkel> lupusbe: change it to /usr/bin/mkfontscale
<lupusbe> yeah I know
<lupusbe> I wonder if this is why fonts.dir is missing
<thesaltydog> dholbach, I forgot an issue...
<lupusbe> since mkfondir was broken when installing the fonts I think
<torkel> lupusbe: probably yes
<dholbach> thesaltydog: which one?
<lupusbe> I'll open a bug report
<lupusbe> or is someone already filling it in? :)
<thesaltydog> dholbach, su-to-root is in the menu file for kde.. the same reason for which I need postins (update-menus)
<\sh> grmpf
<dholbach> but the postinst i looked at didnt do anything
<\sh> anybody there who knows something about stdint.h magic? especially about __INT64_C(...) Macro?
<shaya> lupusbe: I'm not running breezy X
<shaya> it dont work for me
<shaya> always gives me cant find fixed font
<thesaltydog> mmhh. I will check, but I have bum in the "debian" menu installed after an upodate-menus
<shaya> even when changed the menus
<lupusbe> shaya yeah I'm debugging the problem a little bit ;)
<mdke> shaya, me too
<dholbach> thesaltydog: unfortunately i have no real idea about menu/debian-menu entries, Amaranth can surely help you there
<thesaltydog> if I remove the menu file, the non-Gnome user should run the program from CLI..
<shaya> thesaltydog: my debian menu works fine
<lupusbe> can someone tell me of which deb package mkfontscale is
<shaya> lost my other non gnome menus though
<lupusbe> I'm in windows at the moment so I can't check :)
<thesaltydog> shaya, you mean bum in the debian menu?
<Amaranth> thesaltydog: what's up?
<shaya> bum?
<Amaranth> what menu do you want bum to go into?
<dholbach> lupusbe: packages.ubuntu.com should know :)
<thesaltydog> Amaranth, in order to have a menu entry for KDE, do I need to put a menu file in the package?
<thesaltydog> Amaranth, and run update-menus?
<Amaranth> thesaltydog: In order to have a menu for KDE, GNOME, or KDE you need to put a menu file in the package.
<mantiena> Kamion: still online ? my network connection is not so good :(
<lupusbe> thx dholbach
<thesaltydog> Amaranth, Ok. That was my issue. And that is why there is a postins in my package. Correct?
<Amaranth> say what?
<thesaltydog> Amaranth, in the postins I run update-menus
<Amaranth> you don't need to do that
<Amaranth> just make sure your .desktop file gets into /usr/share/applications/
<thesaltydog> Amaranth, should it be enough to put the menu file in /usr/lib/menu?
<thesaltydog> Amaranth, yes, the .desktop file is in the right place.
<Amaranth> if it's in /usr/share/applications you should be done
<Amaranth> /usr/lib/menu is only for the 'Debian' menu
<thesaltydog> Amaranth, sorry, but /usr/share/applications is not only for gnome?
<thesaltydog> Amaranth, I don't know kubuntu, does it work the same for menus?
<Amaranth> no, /usr/share/applications is for any freedesktop.org complient menu system
<Amaranth> which in Ubuntu is KDE, GNOME, and XFCE
<thesaltydog> Amaranth, ok. So i can get rid of the menu file in /usr/lib/menu?
<Amaranth> actually, you probably want to put one there and run update-menus too, sorry
<thesaltydog> Amaranth, :-) ... I was saying just that since 15 minutes...
<Amaranth> you want one in /usr/share/applications and one in /usr/lib/menu
<Amaranth> yeah
<thesaltydog> Amaranth, yes. I did that way.. And run update-menus in postins.
<Amaranth> you should be good then
<thesaltydog> Amaranth, thanks a lot! Ciao..
<dholbach> brb
<Kamion> mantiena: not really, too busy packing
<mantiena> Kamion: ok, will talk with you when you will have time to talk ;)
<lupus1010> w00t breezy X works again :D
<pitti> Keybuk: btw, any ETA for hct in breezy?
<sabdfl> elmo: ping
<elmo> sabdfl: aha, yay
<sabdfl> hi, what's up?
<mdz> wasabi: java-main.txt updated
<mvo> ping seb128 
<seb128> mvo: pong
<mvo> seb128: is vte upstream more reposonsive these days? 
<seb128> no
<seb128> there is no upstream virtually
<seb128> why?
<allee> daniels: where is the translation in xkb/symbol/* of:  key (like <i65>) to keycode (of xev) defined?  Once I knew :(
<mvo> bad :/
<mvo> I have a patch to enable forkpty() in the python bindings
<seb128> put it on bugzilla.gnome.org
<seb128> some people review patches
<seb128> I can try to ping one guy to get it reviewed
<mantiena> mvo: Hi, when you upload update-manager to debian ?
<mvo> and I would like to add a flag that forkpty() not closes all fds on the fork but leave some open
<mvo> mantiena: it needs a updated python-apt in debian
<hunger> harden-clients will remove ubuntu-base and ubuntu-standard... What is telnet needed for there anyway?
<mvo> seb128: the python bit is already in gnome bugzilla (including a patch)
<mvo> seb128: I had hoped to get feedback about the "dont-close-all-fds" thing :/
<seb128> mvo: oh, feedback ... don't expect on that
<mantiena> mvo: it's too hard to make to work update-manage with pyhton from debian sid ?
<mvo> mantiena: it's possible but a PITA because sids python-apt does not know about the depcache (I added that recently). it's a matter of moving the python-apt from experimental into sid, should happen pretty soon I guess. than it's not hard to port it (it uses some python2.4 stuff, but that shouldn't be a big deal)
<mvo> seb128: :(
<mantiena> mvo: hehe, maybe you could upload update-manager to experimental ?
<mvo> mantiena: actually not a bad idea :)
<mantiena> mvo: ;)
<mantiena> mvo: so, why not to make this idea real ?
<dholbach> elmo: thanks
<mvo> mantiena: it still leaves the "backport it to python2.3" problem
<seb128> mvo: why doing that?
<mvo> seb128: why doing what? not closing all fds?
<seb128> no, backporting
<seb128> you'll not get it for sarge now
<seb128> no need to bother
<mvo> yes, I assume debian will get python2.4 as default pretty quick
<Amaranth> i assume sid is going to break worse than breezy in the next couple weeks
<mvo> even worse :P ?
<Amaranth> so it won't matter anyway
<Amaranth> :)
<ogra> Amaranth, why ? they have our patches ;)
<ogra> so they can have it quicker/easier if they want....
<Amaranth> you're assuming they'll a) accept all of those packages and b) get things moving as fast as you did
<Amaranth> err, patches
<Amaranth> not packages
<ogra> its their choice.... but they could if they wanted ;)
<wasabi_> Oh intersting
<wasabi_> Ooo has a UNO bridge for .Net?
<ogra> but they dont have a dholbach to fix their universe indeed ;) so it will take longer for sure
<dholbach> ogra: and a charles and an herve and and and and and
<wasabi_> So ya'll need to give Eclipse a spin.
<wasabi_> (and help me with it of course!)
<wasabi_> apt-get install eclipse-jdt
<wasabi_> !!!
<thesaltydog> dholbach, almost done.. but I have a warning in genchanges and an error in lintian..
<ogra> error is bad.... 
<ogra> hi thesaltydog 
<thesaltydog> ogra, ciao oliver
<thesaltydog> ogra, E: bum_1.2.7-0ubuntu1_i386.changes: bad-distribution-in-changes-file breezy
<dholbach> you're still on hoary?
<thesaltydog> yep
<dholbach> then ignore it
<ogra> thesaltydog, you can ognore that
<thesaltydog> ok. now genchanges
<ogra> ignore even
<thesaltydog> dpkg-genchanges: warning: unknown information field  in input data in package's section of control info file
<thesaltydog> the same?
<dholbach> have a look at the Package's section in debian/control
<thesaltydog> I have just added the Version: 1.2.7-1ubuntu0
<thesaltydog> before I had no version info in control.
<dholbach> yeah... cool - now have a look at debian/control
<dholbach> version info in control is wrong
<thesaltydog> dholbach, what should I look for?
<dholbach> has to go to debian/changelog
<thesaltydog> aahh. ok, so I remove from there and put in debian/changelog
<dholbach> yes
<thesaltydog> BTW, how should I have both chengelog.gz and changelog.Debian.gz?
<thesaltydog> I have only one changelog file in debian dir
<Keybuk> pitti: by "hct in breezy" do you mean HCT packages in breezy?  or just usable for doing breezy?
<dholbach> thesaltydog: let's take this into #ubuntu-motu
<thesaltydog> ok
<pitti> Keybuk: well, packages are always appreciated, but actually I'm curious about both :-)
<dholbach> ok
<Keybuk> former, august most likely
<Keybuk> latter, uh, couple of hours?  something like that
<pitti> ah, thanks
#ubuntu-devel 2005-06-15
<mdz> jbailey: ping
<mdz> Lathiat: apparently someone else has experienced this: https://bugzilla.ubuntu.com/show_bug.cgi?id=10900
<mdz> Lathiat: the installer certainly doesn't intend to add fstab entries for a flash drive; perhaps it is being treated as a CD-ROM
<mdz> Lathiat: please send a copy of the fstab after install to Bugzilla if you find one
<wasabi_> mdz, jbailey says he's going to try to tackle libxerces2-java tomorrow. I am out of time this week for it.
<mdz> wasabi_: I fixed it today
<jdub> http://gtkperf.sourceforge.net/index.php?page=testing&id=1
<jdub> ^ site has an ubuntu logo on it ;)
<tseng> jdub: a nice one too
<tseng> wow.
<seb128_> daniels: where is XRes.h ??
<seb128_> boooog
<ogra> seb128, my pbuilder doesnt find Xlibs.h anymore since today
<uniq> i can confirm that.
<uniq> Xlib.h rather. 
<uniq> same goes for Xutil.h
<seb128> daniels has declared .h files useless, that's it? :)
<uniq> my guess is that x11proto-gl-dev (and probably atleast one more) lags behind. 
<uniq> they are there.. just beeing moved around.
<shaya> seb128: he's a c++ programer?
<shaya> :)
<uniq> seb128: they are at /usr/X11R6/include/X11 
<ogra> seb128, yeah, looks like
<shaya> btw, on the wiki anywhere is there a plan that describes what's going on with X and why?
<seb128> uniq: XRes.h is not
<shaya> I'm just curious
<ogra> uniq, yes... 
<uniq> seb128: yes, xres.h is gone. 
<seb128> daaaaanieeeeel
<Nafallo> seb128: does he highlight that? ;-)
<seb128> not sure :)
<Nafallo> he probably should ;-)
<Nafallo> and wire his alarmclock to it ;-)
<zyga> hello
<zyga> I've rewritten chattr and included user-friendly argp command line parser
<zyga> I was wondering if anyone would be interested in taking a look
<lsuactiafner> zyga : you seem to be very busy with scrips
<lsuactiafner> heh
<zyga> lsuactiafner: ?
<lsuactiafner> your mplayer-rtc seems to have improved my sync
<zyga> lsuactiafner: thats good to hear
<lsuactiafner> i think it was you..
<zyga> lsuactiafner: yes
<lsuactiafner> watched a movie today and could lip read
<zyga> lsuactiafner: but that script is very questionable as I've learned (bad way to do what I wanted to do)
<lsuactiafner> didnt notice the out of sync was that bad before since i watch anime mostly
<lsuactiafner> worksforme(tm)
<lsuactiafner> and i'm critical of most packages
<zyga> lsuactiafner: you don't have a centrino cpu ;-)
<lsuactiafner> ah ok hehehe
<lsuactiafner> cat /proc/cpuinfo ; if not centrino then go ahead..
<zyga> actually if I could detect that speedstep stuff this way that would be enough
<mjg59> allee: Hi
<allee> mjg59: hi ...
<allee> mjg59: where is the translation in xkb/symbol/* of:  key (like <i65>) to keycode (of xev) defined?  Once I knew :(
<mjg59> allee: That's based on your keymap
<mjg59> xkb sets it
<mjg59> The kernel gets a scancode from the keyboard. It turns that into a keycode and gives it to X. X uses its xkb table to turn that into a keysym.
<jdub> mjg59: o/~ the thigh bone's connected to the knee bone... o/~
<allee> mjg59: the way of the event is clear to me.  but I miss what to use for key <xyz> to get out the right keycode keysym combo
<wasabi_> mdz, oh what did you do?
<allee> mjg59: I did it once year ago but can't find it :(
<mjg59> allee: I'm not quite sure what you mean
<mjg59> The keycode keysym combination is keymap specific
<allee> mjg59: status:  I have the keycode (from xev).  I know the XF86<whatever> from XF86symdef.h (or so) ...
<allee> mjg59: but to write add a map in xkb/inet  I to find the translation table  keycode -> key <xyz>.
<mjg59> allee: Look under /etc/X11/xkb
<mdz> wasabi_: I had it build against the dom2 stuff in libjaxp1.2-java (you don't read ubuntu-changes?)
<allee> mjg59: done.  but I check again.
<mdz> wasabi_: unfortunately ecj wouldn't compile it, so it's still using jikes at the moment
<mjg59> allee: I don't pretend to understand xkb. It's a complicated specification.
<allee> mjg59: me too :(
<mdz> wasabi_: I got a very weird failure on libbsf-java: http://people.ubuntu.com/~lamont/buildLogs/libb/libbsf-java/1:2.3.0+cvs20050308-1ubuntu2/libbsf-java_1:2.3.0+cvs20050308-1ubuntu2_20050607-2349-i386-failed.gz
<allee> mjg59: nevertheless it drives me cracy that I cant find the keycode defs of <SPCE>  <AE01>  etc :(
<mdz> all I did was remove the jython deps and test that it still built locally
* allee hits head at the wall.   xkb/keycodes/xfree86 is it.   
<allee> mjg59: thx for making me search twice.  Now I can produce a xkb symbol file :)
<dholbach> good night, have a nice evening
<wasabi_> mdz, I don't tend to read nor pay that much attention to anything while at work all day. ;)
<wasabi_> But I do idle in IRC and read/say things as my nick hilights
<eazel7> hi ppl
<pitti> night everybody
<jbailey> mdz: pong
<mdz> jbailey: looking for updates on EarlyUserspace, especially the hook for LTSP and getting hotplug or hotplug-ng going
<jbailey> mdz: I worked out with Fabio this morning how we're going to make it so that you can use initramfs with an option in /etc/kernel-img.conf.  I have some test hooks in my local tree right now but they just execute whatever scripts in a directory unordered, which I think won't work.  For the hotplug stuff, there's bits in 2.6.12-rc6 which Fabio is working on tomorrow that allow you to just feed that info to mod
<jbailey> probe to load the right driver.
<jbailey> mdz: So there should be no need for hotplug-ng in the initramfs at all.
<jbailey> mdz: Also, I have mdadm tentatively working, but there's a segfault that wants 1.0.10 at least to fix (or a fix backported that I looked at this afternoon before I ran out)
<jbailey> I've listed in the EarlyUserspace spec all the configs I think we have to support and a status beside them.
<jbailey> mdz: I also looked at what it would take to use busybox + uclibc.  busybox's modprobe doesn't support ppc64 and uclibc doesn't have the pieces for hppa, ia64 or x86-64.  It looks like I can get it down to about 400k with the features that I need, though.
<\sh> good night folks :)
<lamont> mdz: 10463: fixed in breezy postfix, I believe...  is that worth a hoary-updates?
* lamont heads of to the FD meeting
<mdz> jbailey: what are the bits in 2.6.12-rc6 like?  a tool which scans the various buses and calls modprobe?
<mdz> jbailey: how is it different from hotplug-ng or hotplug?
<jbailey> hotplug-ng is just a hotplug bit that accepts the calls from kernelspace.  hotplug includes a bunch of 'coldplug' scripts that walk the bus and sorts out what should be loaded when.
<jbailey> Those were going to be ported to hotplug-ng, but in the annoucement of v002 on lkml he mentioned this new thing for coldplugging.
<jbailey> (fetching)
<jbailey> http://lkml.org/lkml/2005/5/6/101
<jbailey> It appears to put all the information needed into sysfs.  Because fabio's uploading -rc6, it semes to make sense to take a look at it before moving all the old hotplug scripts into the initramfs.
<daniels> jdub: what's happening with your X?
<jdub> daniels: keyboard seems non-functional once X starts
<jdub> daniels: though, i haven't remotely killed it to see if it still works at the console after the fact
<jdub> hold on, i'll try
<jdub> oh
<jdub> that's great
<jdub> screen goes blank, doesn't chvt, and ctrl-alt-fx doesn't work
<daniels> er, wack
<daniels> send me your log and I'll do what I can
<daniels> got to drop offline for a little bit now, back in ~1hr
<schweeb> jdub: I've had that problem before myself
<schweeb> (with breezy)
<schweeb> but I'm back on safe old hoary now ;)
* Keybuk dies at the LugRadio "Ubuntu Jingle"
<jdub> ha ha
<jsgotangco> Ubuntu Jingle?
<jdub> UM-BONGO!
<jsgotangco> this i gotta hear
<Keybuk> it's just under an hour into Season 2, Episode 13
<jsgotangco> gotcha
<tseng> i know, we'll call it ubuntu!
<tseng> thats brilliant.
<Keybuk> it makes a lot more sense if you got the Umbungo TV adverts, I guess
<jsgotangco> oh my god
<mdz> jbailey: won't we need hotplugging functionality anyway, in order to handle e.g. USB?
<jbailey> mdz: The only case I can think of was someone racing to plug their USB device in that's required for boot after the initramfs had started and before the bit needing the device ran.
<jbailey> Aside from that, the system hotplug should deal with it when it fires up.
<jbailey> Food time
<mdz> jbailey: I'm more interested in, e.g., USB keyboards
<mdz> which need to be activated as early as possible for debugging and recovery
<whiprush> jdub: fridge!
<lu|away> whipppprush
<ajmitch> hey whiprush 
<whiprush> so much news lately ... need ... place ... to ... post .... <boom>
<whiprush> heya luis, aj.
<lu|away> hrm
<lu|away> there was something I wanted to steal you away from ubuntu for
<lu|away> but now I can't remember what it was
<lu|away> :)
<whiprush> me?
<whiprush> whew!
<lu|away> yeah
<lu|away> :)
<jbailey> mdz: Right, but the coldplugging pass should cover all those.
<jbailey> Hmm.
<jbailey> I guess there could be a cryptroot or debug setup where the user gets prompted for a password and discovers at that point that they need a keyboard handy.
* syndicate rols@ jorge
<whiprush> jdub: ping.
<bob2> FRIDGE
<jsgotangco> FRIDGE
<whiprush> put your drinks in the fridge bob2
<bob2> whiprush: I would if there WAS ONE.
<whiprush> Well, I'm ready to give out the drinks.
<fabbione> morning
<fabbione> mdz: ping?
<whiprush> bob2: hmmm, jdub is running a prototype off his dsl just running drupal.
<whiprush> bob2: think he'll mind if I set up a prototype on a proper host and get people started on stuff?
<bob2> last time I spoke for jdub I ended up in the bottom of sydney harbour with concrete shoes
<whiprush> the hair float you back up?
<bob2> fortunately
<bob2> but I don't know if I'd be so lucky the second time!
<whiprush> "Luckily the air was trapped in my hair so I could survive long enough to be rescued. I'll get you Jeff Waugh!"
<bob2> *brrrrrruh*
<ajmitch> hi bob2 
<bob2> aloha
<ajmitch> yay, a new bazaar package
<bob2> shiny! NEW!
<ajmitch> is there a proper changelog in it somewhere?
<syndicate> whiprush: i'm with you
<syndicate> been fixing this iSCSI drive
<syndicate> r
<Jormundgand> Could we get some bugfixes backported from Firefox Deer Park alpha 1?
<bob2> if there are serious existing bugs in the bts on firefox, which are fixed in a later version, please post patches to the bugs
<lifeless> mako: are you mako@ubuntu.com ?
<Jormundgand> bob2: Easier said than done, unfortunately. I am by no standards a programmer, and I'm certainly not equipped to tackle something the size of Firefox.
<Lathiat> mdz: its not a lash drive, its a 200GB external hard drive
<daniels> jdub: any luck with the log?
<Lathiat> mdz: *flash
<mako> lifeless: umm.. yes
<lifeless> have you had correspondence from Aldo ?
<mako> lifeless: why?
<mako> lifeless: i send like 200+ messages a day
<lifeless> random I want to be a developer and have cd's email landed in my mailbox
<lifeless> want to flick it to you
<mako> lifeless: go ahead, i looked in my sent mail and didn't see anything
<lifeless> done
<lifeless> thanks
<fabbione> hey mako!
<mako> i'm off to sleep
<mdz> fabbione: yes?
<fabbione> mdz: busy?
<mdz> Lathiat: they use exactly the same driver, you see
<mdz> fabbione: going to bed shortly
<Lathiat> mdz: yeh :)
<Lathiat> mdz: i'll let you know
<fabbione> mdz: eheh ok..
<mdz> Kamion: I could really use a way to tell ssh to close the connection when the command exits, rather than allowing x11 forwards to linger open.  is there any way to do that?
<Lathiat> mdz: could just -f it ?
<Lathiat> mdz: theres also -& "Background ssh at logout whenw aiting for forwarded connetion/X11 sessiosn to terminate"
<Lathiat> oh, actually, thats a ~ escape thing, my bad
<Amaranth> i think i missed the end of the meeting :D
<Amaranth> right as i was about to talk my internet died and stayed dead for 6 hours
<pitti> Morning
<Amaranth> morning
<jsgotangco> morning
<ajmitch> hi JaneW 
<pitti> Hi JaneW
<pitti> ajmitch: Hi, what's new in selinux land? :)
<ajmitch> pitti: selinux patches may start landing in debian soon, i hope :)
<ajmitch> I haven't talked with manoj about it yet, and I've got to finish off the 0.76 pam patching
<whiprush> jsgotangco: awake?
<ajmitch> hi sabdfl 
<sabdfl> hi guys
<whiprush> morning sabdfl 
<jsgotangco> whiprush, hey
<fabbione> hey sabdfl 
<jsgotangco> morning sabdfl 
<jsgotangco> sure im awake its only 4pm
<jsgotangco> heh
<whiprush> jsgotangco: I have a cool fridge/docteam idea I need to run by you. I'm editing the spec, gimme a few minutes.
<jsgotangco> sure
<Simira> morning sabdfl, fabbione 
<sabdfl> hey simira!
<jsgotangco> ill continue listening to my weird japanese heavy metal cd then
<sabdfl> Simira: how are you feeling?
<Simira> sabdfl: well, I've got a serious cold, but else I'm fine. When are you leaving for Bergen? Saturday?
* Simira reminds of Mithrandir's birthday today: http://www.simira.net/files/IMG_0249.jpg
<sabdfl> ah, thanks for the reminder, i'll sing Happy Birthday on #canonical :-)
<JaneW> hi ajmitch/pitti
<jsgotangco> err is that a lego set?
<fabbione> hi Simira :)
<sabdfl> hey fabbione!
<Simira> jsgotangco: Mindstorms
<fabbione> sabdfl: how is life in uk today?
<jsgotangco> whoa
<sabdfl> fabbione: blue blue skies, so of course i'm flying out this afternoon to Galicia
<fabbione> sabdfl: ah cool :)
<JaneW> Simira: cute! is that from you?
* fabbione would like to get there too ;)
<sabdfl> fabbione: to mars? or galicia?
<fabbione> both :)
<jsgotangco> heh
<JaneW> sabdfl: are we meeting up at the school on saturday?
<Simira> JaneW: me, and a few others. Mindstorms + MArs exploration expansion
<fabbione> but galicia would be a good start ;)
* JaneW makes note to remember to go collect visa...
<JaneW> Simira: my son would love that!
* Mithrandir chuckles and blushes
<jsgotangco> heh i would love a set of mindstorms as well
<jsgotangco> (for myself)
<Simira> JaneW: you should bring him when you're coming to Oslo, then ;)
<JaneW> HAPPY BIRTHDAY Mithrandir !
<JaneW> Simira: shame I wish I could... 
<Mithrandir> thanks JaneW :-)
<jsgotangco> Mithrandir, Maligayang Bati sa iyong Kaarawan (happy birthday)
<ajmitch> Mithrandir: happy birthday :)
<jsgotangco> hmm
<whiprush> jsgotangco: http://udu.wiki.ubuntu.com/TheFridge
<whiprush> see the "Original Content" section.
<JaneW> Mithrandir: gratulerer med dagen :)
<jsgotangco> whiprush, we have a wiki transition at the moment where henrik is in charge
<jsgotangco> whiprush, but the end result of the transition is that we'll have clean docs
<whiprush> excellent.
<whiprush> obviously we don't want to do this in the middle of the wiki transition.
<jsgotangco> i'll revisit this option once the wiki transition is done and the fridge can be viewed
<whiprush> okey.
<jsgotangco> whiprush, the spec is awesome i'm sold on it heh
<whiprush> I have more ideas I'm adding.
<whiprush> I was sleeping then got motivated for some reason (It's 4:30am here.)
<jsgotangco> yes i notice you are still awake
<pitti> Kamion: got a minute to talk about CD-ROMs in pmount vs. fstab?
<Lathiat> wow, first kernel vuln in a while
<fabbione> Lathiat: ?
<pitti> he certainly means the USN released this morning
<Lathiat> indeed
<fabbione> oh you unleashed it this morning :)
<fabbione> that makes sense
<bob2> hah
<pitti> fabbione: sorry, the build took a while and I sort of forget about it yesterday evening
<fabbione> ahah
<pitti> fabbione: I hacked at the alsa hotplug stuff for ours, who thinks about security at that time .. :-)
<pitti> s/ours/hours/ *cough*
<fabbione> so bets are open to see how many people will get an unbootable system
<Lathiat> haha
<zyga> hello
<pitti> Hi zyga 
<zyga> pitti: I rewritten part of e2fsprogs utils
<zyga> pitti: to be more user friendly
<pitti> uh, which?
<zyga> I'm targeting all misc/ utilities (like chattr lsattr and so on)
<zyga> right now I've finished chattra and sent the code to the maintainer I've found on the man page 
<zyga> (no response yet)
<zyga> I've added argp - it's now more like proper CLI tool
<zyga> (old version was really bad here)
<mvo> if newer udev no longer has a /.dev dir, dosn't /dev/MAKEDEV needs to be updated as well (it checks for /.dev to detect udev)?
<zyga> I'd  be cool if ubuntu could get my improvements :)
<Kamion> mdz: ssh> short of the ~& escape mentioned, I don't see a way to do that, I'm afraid
<\sh> hmm...
<\sh> when I'm using #include <limits> and then using std::numeric_limits<int>max() will it give me on 32bit and 64bit the maximum of int depending on the arch?
<zyga> \sh: on amd64 int is still 32 bits
<zyga> \sh: size_t will be 64 bits, long will be 64 bits but int stays 32 
<\sh> ok...i will explain the other way around
<\sh> right now, the source is using stdint.h
<\sh> anjd trying to use INT64_MAX and INT32_MAX
<\sh> when I compile this code with g++-4 it's complaining that those defines are not declared in this scope
<\sh> so now, i'm trying to rewrite this section with real c++ code
<\sh> using limits should help me..
<zyga> hmm macros have global scope, don't they?
<\sh> zyga: # define INT64_MAX              (__INT64_C(9223372036854775807))
<\sh> this is the define in stdint.h
<zyga> right
<zyga> strange... what does the compiler say?
<zyga> as for the proper-c++-method of doing this
<zyga> I'm not a c++ developer but your limits approach sounds good
<zyga> I just don't understand one thing
<\sh> zyga: that INT64_MAX was not declared in this scope
<\sh> funny thing is, u have to define another conditional define to include those defines
<\sh> and it is
<mvo> \sh: what package?
<\sh> warped
<\sh> there is a patch from debian
<\sh> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=268250
<\sh> but this is not working either
<Amaranth> ooh, i got copy/paste working in smeg
<zyga> does std::numeric_limits<int64_t>max() work?
<Amaranth> now to make it worth having
<\sh> zyga: i don't know..i want to try it
<\sh> let me try the c++ solution
<zyga> \sh: do you want different value based on current arch?
<Kamion> pitti: sure ...
<pitti> Kamion: mdz, ogra, and me had a short discussion yesterday about this CD-ROM issue
<Kamion> pitti: the main thing is that /cdrom is used before pmount is installed
<\sh> zyga: well, warped defines 
<\sh> const warped64_t warped64Max = INT64_MAX;
<\sh> const warped64_t warped64Min = INT64_MIN;
<\sh> const warped64_t warped32Max = INT32_MAX;
<\sh> const warped64_t warped32Min = INT32_MIN;
<pitti> Kamion: are there issues with removing the cdrom stuff from fstab?
<pitti> Kamion: ah, for apt-cdrom and the like?
<Kamion> yes
<pitti> hm, true
<zyga> \sh: I see - well you might as well try to get those #defines working
<Kamion> nowadays that's in the first stage, in fact, before the first reboot
<zyga> \sh: they are probably regarded as 'evil' since they have global scope ;-)
<Kamion> although mind you, apt-setup does 'mount $CDDEV /cdrom' or some such
<pitti> mvo: would apt-cdrom be able to deal without an fstab entry?
<Kamion> ah, but it looks in fstab to find the device
<\sh> zyga: yes Iwill :) but it breaks on all archs :) and the debian patch breaks, too...so I need another solution..as we're speaking about c++ lets try the c++ way
<Kamion> I think we might run into trouble in situations where the device is not just /dev/cdrom
<pitti> Kamion: hm, right
<Kamion> just trying to work out if that ever happens
<pitti> Kamion: although it equally breaks on my system where the actual CD-ROM is _not_ /dev/cdrom nor /cdrom either
<KaiL> 855resolution (or better a Version compatible with 915) should go into main - seams to be needed very often...
<mvo> pitti: not right now
<zyga> hmm
<zyga> pitti: do you have /dev/cdrom ?
<Kamion> pitti: let me try a quick install test with removable media support killed from partman-target
<pitti> Kamion: hm, it's a special case either way (try to mount /dev/cdrom or /cdrom)
<zyga> (on ubuntu I never had /dev/cdrom or /dev/dvd created)
<Kamion> pitti: what is the actual problem with having it in fstab? I've never quite understod
<Kamion> +o
<pitti> zyga: yes, but I also have a /dev/cdrom1 and a /dev/cdrw, and my usual drive is the cdrw one
<pitti> Kamion: oh, it's just to support changing hardware better
<mvo> pitti: what would apt have to do to find a cdrom? what steps/dependencies would be involved?
<zyga> pitti: strange... something must be buggy here I guess
<pitti> mvo: well, on my system it seems to try to mount /cdrom
<pitti> mvo: which fails, because the CD is in /media/cdrom1
<zyga> pitti: what creates those links? I have none {cdrom,cdrw,dvd} ?
<pitti> mvo: so instead of trying to mount /cdrom, maybe it could try to mount /dev/cd* until it finds a Debian CD?
<pitti> zyga: udev
<pitti> Kamion, mvo: if we manage to drop this hardcoded /cdrom from apt-cdrom, we might be able to drop the CD-ROMs from fstab at all and even make the stuff work on multi-CD systems, too
<Kamion> pitti: I guess part of what concerns me is that, if we rely entirely on pmount for this, we screw over server installs. Servers have CD drives too ...
<Kamion> and pmount is only in desktop
<Kamion> pitti: also /dev/dvd*
<zyga> pitti: oh well it's broken then 
<mvo> pitti: if it depends on pmount I wouldn't want to do it. debian will probably not follow us here (at least not yet)
<pitti> Kamion: well, apt-cdrom needs sudo anyway, so it could just use mount?
<zyga> I got /media/cdrom and /media/cdrom0 but nothing in /dev
<pitti> Kamion: I didn't thing about using pmount in apt-cdrom
<Kamion> pitti: that only works for aptable CDs
<Kamion> pitti: people want to mount CDs that we did not make, surprisingly enough ;-)
<pitti> ah, ok
<pitti> hm, fair point
<Kamion> and 'mount /cdrom' is a traditional way to do it
<Kamion> which I'm quite reluctant to break
<pitti> we didn't think about that yesterday, we thought it was an easy thing to do
<pitti> right, that should work
<pitti> alright, then let's keep it like it is now
<Kamion> pitti: isn't udev supposed to create a /dev/cdrom symlink in a sensible place?
<pitti> Kamion: actually yes (it has worked fine for me since warty on my boxes)
<Kamion> pitti: ah, I guess partman-target is using the canonical device names rather than /dev/cdrom
<Kamion> pitti: would it help if I made it use /dev/cdrom etc. if available?
<pitti> Kamion: I don't know in general, but it wouldn't help to unbreak apt-cdrom on my system at least
<pitti> well, unbreak is too harsh
<pitti> make it work better 
<Kamion> pitti: it would seem to help with the hardware-changing case
<pitti> Kamion: yes, for this use case it does
<pitti> Kamion: not for the case where sb has more than one drive, but it shouldn't hurt either then
<mvo> pitti: I think I could make apt smarter about multiple cdroms. if it importend for us I can spend a bit of time on it
<mvo> pitti: it's a matter of checking /dev/{cd*,dvd*}?
<pitti> mvo: it's not really a biggie, but if it could become smarter, that would rock
<pitti> mvo: it should iterate through all /dev/cd* and dvd*, try to mount, check if it's an Ubuntu CD and unmount if it isn't
<pitti> mvo: the mountpoint does not necessarily need to be /cdrom, right? It could be /var/foo/cdrom, as in the installer
<pitti> mvo: so at least apt-cdrom would not depend on an fstab entry any more
<Kamion> could just be /media/$devicetail
<Kamion> which would fit with where (I think) Debian wants to go
<mvo> that should be possible
<pitti> Kamion: so if we had only one fstab entry for /dev/cdrom, that would reasonably cover the hw changing, too AFAICS
<Kamion> until apt supports this, it's probably best to have the installer use /dev/cdrom only if that matches the drive your CD is actually in
<pitti> right
<HiddenWolf> Kamion, don't forget people who have dvd-drives only, (if that matters)
<pitti> HiddenWolf: I have, and I still have /dev/cdrom
<Kamion> HiddenWolf: udev has not forgotten them ;-)
* Kamion is a big fan of delegation
* thom shakes his fist at gnome-session segfaulting on ia64
<fabbione> thom: are running ubuntu on ia64?
<fabbione> if so does our kernel actually work?
<thom> running the 2.6.10-5 kernel
<thom> seems fine
<bob2> so
<bob2> warty amd64 was NPTL, right?
<bob2> like every other debian-related amd64 port?
<Kamion> amd64 never had LinuxThreads
<Kamion> (AFAIK)
<bob2> that's what I thought
<fabbione> thom: ah cool
<fabbione> thom: feel lucky to give 2.6.12 a shot?
<thom> why not
<fabbione> thom: i am just building 12rc6 if you really want something bleeeeeeeding edgeeee
<fabbione> ;)
<thom> i'll try 93-1.3 for now ;-)
<fabbione> gcc-3.4: Internal error: Segmentation fault (program cc1)
<fabbione> GO DAVIS! IT
<fabbione> GO DAVIS! IT'S YOUR BIRTHDAY!
<fabbione> thom: sure.. i plan to upload rc6 in one hour or max 2 anyway
<fabbione> i need to wait davis to finish
<fabbione> elmo: (btw that's only the 4th time since this morning.. it wasn't bad as usual)
<bob2> I thought chinstrap was King Of  The Random Crashes
<elmo> only for arch people
<fabbione> bob2: nope.. chinstrap is nice and dandy :)
<thom> 2.6.12 causes lots of red lights
<thom> and no booting system
<fabbione> neat
<thom> not so much
<thom> ;-)
<fabbione> well there is not much i can do.. it's ia64 :)
<elmo> ia64s are amusingly scary when they don't boot
<fabbione> it builds.. it's ready for stable release ;)
<fabbione> thom: i will hand you rc6 soon to see if it has been fixed
<thom> making all sorts of fun noises too
<fabbione> configs should be the same as .10 (or almost)
<elmo> thom: the beeps actually make up "THE SKY IS FALLING" in morse code
<fabbione> make[5] : *** [drivers/usb/media/pwc]  Segmentation fault
* fabbione sighs
<thom> elmo: seriously? (i can well believe it)
<bob2> haha
<fabbione> elmo: i start to think it's a temperature problem...
<fabbione> more i go deep in the build, more it crashes
<elmo> fabbione: I doubt it - the fans are on (at full speed) and the ia64 beneath it thinks the temperature is fine
<elmo> thom: no :P
<fabbione> rotfl
<fabbione> elmo: probably ppc is allergic to ia64.. move it in another rack :)
<fabbione> actually.. if you notice...
<fabbione> davis started to segfault after Apple announced the switch to ia64..
<fabbione> it that a coincidence?
<elmo> ?!?! ia64?
<fabbione> well they say intel..
<fabbione> so my guess is ia64 :)
* Nafallo says morning all!
* pitti says "Good morning" to Nafallo
<Burgundavia> fabbione, I think jobs specifically mentioned x86
<Nafallo> pitti: :-). I'm lazy. I use /ame ;-)
* pitti doesn't even know this command
<fabbione> Burgundavia: apparently he only said intel
* pitti hi
<infinity> fabbione : The kenote was delivered while he was running OSX on a Pentium4, so it's a good bet that'll be the direction they go.
<HrdwrBoB> infinity: most likely p-m
<HrdwrBoB> but yeah, same thing
<infinity> Not really.
<infinity> P-M is a P3.
<fabbione> infinity: i am betting on ia64 just to give a meaning to our buildds :)
<infinity> fabbione : :)
<HrdwrBoB> p-m runs at about the same speed as an a64, clock for clock, and it's much lower heat/power/etc
<shawarma> When it says that the Community Council meetings are at 12:00 UTC.. That's PM, right? As in in the middle of the day?
<elmo> hey the ia64's may be slow but they don't randomly segfault
<HrdwrBoB> but the problem is now that PPC will become obsolete very quickly
<fabbione> elmo: well.. after breezy release they won't even boot :)
<elmo> HrdwrBoB: being shipped in millions of next gen consoles isn't exactly obsolete
<HrdwrBoB> elmo: as a PC I mean
<fabbione> HrdwrBoB: they will find a way to run Linux on consoles...
<fabbione> do you think that's an issue?
<HrdwrBoB> me?
<HrdwrBoB> they will run it, but it won't be a mainstream thing
<fabbione> probably
<\sh> infinity: ping
<koke> mvo: around?
<mvo> koke: yes
<koke> http://koke.amedias.org/img/g-a-i-mockup-1.png <-- I now it lacks an apply button, but that's my main idea
<mvo> koke: integrating your patch right now
<koke> great :)
<koke> also the mockup needs some HIG love :)
<\sh> HIG?
<mvo> koke: I love the package view, I'm not sure about the left/right side
<mvo> human-interface-guidlines
<\sh> update manager? 
<ogra> \sh, gnome app install
<koke> mvo: left for browse/search packages
<ajmitch> hey mvo, koke 
<koke> right is the list of selected packages to install
<ogra> koke, is the right pane necessary ?
<ajmitch> koke: nice mockup
<ajmitch> lots of blank space though
<koke> ogra: the idea is to remove the checkboxes from the left
<ogra> koke, and drop the left pane completely ?
<koke> ogra: you mean browsing/searching from the browser?
<ajmitch> koke: having blank space on both left & right is a bit much, don't you think?
<ogra> cant you implement the search on the right ? o even better, mozilla like ....
<ogra> koke, i would drop one of the panes.... else i think its awesome :)
<koke> ajmitch: yep, that's why I said it needs HIG love ;)
<koke> but you caught the main idea :)
<ajmitch> yep, looks good :)
<koke> maybe an expander
<koke> do we have vertical expanders?? I don't think so
<ogra> hmm
<jdong> guys, quick question about the new *c2 package names....
<ogra> ask :)
<jdong> how do you want me to handle them?
<Kamion> daniels: #11545's causing CD image trouble - sorry to hassle, but when will you get a chance to fix it?
<\sh> mvo: where is your repos for gnome-app-install? ,-)
<ogra> jdong, like we do it ?
<jdong> I'm backporting qca for Hoary
<Kamion> NOOOOO
<mvo> \sh: it's in gnome-cvs
<Kamion> jdong: use the C++ ABI in Hoary
<jdong> do you want me to preserve the libqcac2?
<ajmitch> jdong: c2 is only if it's built with the new C++ ABI
<ogra> jdong, there is a bunch of wiki pages about the Cxx transition
<jdong> ok, so you want me to strip off the "c2"?
<Kamion> jdong: use package names that match those in Hoary
<jdong> Kamion: the package isn't in Hoary ;)
<Kamion> jdong: they may be missing c2 entirely, or they may have c102
<Kamion> jdong: ok, probably drop c2 entirely then
<ogra> jdong, it can be a PITA to backport c++ packages, i'd consider it twice
<jdong> k
<Kamion> jdong: doesn't libqca have a soname?
<\sh> mvo: i have this repos here http://www.burtonini.com/arch/
<\sh> and yours http://people.ubuntu.com/~mvo/arch/ubuntu/gnome-app-install--mvo--0/
<Kamion> ah, libqca1c2
<ogra> jdong, at least at this state of the transition...
<Kamion> so make it libqca1
<\sh> jdong: what?
<mvo> \sh: ross recently imported it into gnome-cvs, I asked the baz people to import it from gnome-cvs back into arch again :)
<Kamion> ogra: shouldn't be an issue as long as they only ever use the Hoary ABI
<ogra> \sh, backpting c++ libs
<Kamion> oh, although I guess the Breezy package would have to conflict with the backport
<ogra> Kamion, i mean dependency wise.... 
<jdong> Kamion: not really
<Kamion>  Conflicts: libqca1
<Kamion>  Replaces: libqca1
<\sh> ogra: ja w8
<ogra> Kamion, they do
<Kamion> ... except it already does
<Kamion> jdong: yes really. :)
<ogra> Kamion, we conflict with the old names.... that shouldnt be an issue
<jdong> I'll remove the Replaces:, but rename Conflicts: to libqcalc2
<jdong> that ok?
<Kamion> jdong: no, remove both replaces and conflicts
<jdong> ok
<Kamion> matching the version in Debian
<\sh> jdong: source package qca
<Kamion> ogra: it would be an issue if a C++ library were newly introduced in Breezy
<ogra> Kamion, but we also apply debian patches for gcc4, so they might be incompatible with the old one in some cases....
<mvo> koke: the main package view is great! but the lefthand side is not optimal. how would we eg display the categories?
<Kamion> ogra: if they do, you've broken it, don't do that
<ogra> depending on the patch
<\sh> ogra: libqca is qt lib for tls stuff for psi
<Kamion> ogra: patches for gcc4 should make it *more* standards-compliant, not less
<\sh> ogra: and it doesn't have any patches
<ogra> Kamion, i didnt try if they compile with the old version...
<ogra> \sh, ok
<Kamion> ogra: if a C++ library were newly introduced in Breezy, backporting it would involve adding c102 to the package name and getting the package in Breezy to conflict/replace the backport
<Kamion> that would be correct ...
<ogra> Kamion, yep
<Kamion> ogra: you should, I think
<Kamion> ogra: otherwise the patch cannot cleanly go upstream
<Kamion> which should be part of our job
<ogra> Kamion, they come *from* upstream (debian)
<ajmitch> the most likely case of new C++ libs will still be syncs from sid
<Kamion> ogra: they come from random Debian bug reports, usually
<Kamion> which isn't quite the same thing
<ogra> yep
<Kamion> and that's only one step upstream, anyway
<ogra> Kamion, i had the impression etch would switch soon to gcc4
<Kamion> ogra: I imagine it will, yes. That doesn't mean upstream (not Debian) don't care about older compiler versions
<ajmitch> ogra: depends on how long the flames last
<ogra> so if they compile with gcc4 it should be fine
<Kamion> it's just sloppy to fix for gcc4 and break older compilers, unless you know and clearly document that you're doing it ...
<koke> mvo: it's like the current patch
<koke> if there's no search, the categories view is shown
<koke> http://koke.amedias.org/img/g-a-i-mockup-2.png <-- suggestions accepted :)
<ogra> koke, looks way cooler :)
<tseng> koke++
<tseng> the top left box should wrap lines
<tseng> vs horizontal scrolling
<tseng> thats the only ugly part
<ajmitch> koke: looking better
<Nafallo> koke: nice :-)
<tseng> or better
<tseng> you could use the ellipsizing widget from gtk 2.6
<zul> heylo
<tseng> as in "Instant messaging client for multiple..." when you run out of space
<whiprush> omg, slick-n-run lives.
<Amaranth> koke: hey, can you make the g-a-i we have now work while you're at it? ;)
<mvo> koke: I think that it looks nicer this way :) 
<Amaranth> yes, i like this design
<Amaranth> where does it get it's app list from?
<jdong> and another question relating to the Forums: what should we recommend as the preferred way of compiling/installing from source? Checkinstall? /usr/local?
<Kamion> either of those should work fine, as long as it doesn't touch /usr outside /usr/local ...
<jdong> so you guys are fine with either method?
<Kamion> speaking for myself only
<jdong> k
<Kamion> I don't really see a need to recommend a single method; I don't find that one size fits all
<Kamion> but I don't know checkinstall well
<koke> Amaranth: that data is hard-coded (by now) :P
<Amaranth> koke: but where will it come from eventually?
<Amaranth> koke: the package data and the screenshot, i mean
<ajmitch> Amaranth: eventually launchpad, I'd say
<Amaranth> launchpad? this is ubuntu specific, isn't it?
<jdong> Kamion: it makes a very hasty .deb, so at least the installed files are managed by the dpkg system
<Amaranth> unless you're using that autopackage crack :)
<Kamion> jdong: using /usr or /usr/local?
<mvo> Amaranth: the .desktop files of the packages provide quite a bit of information already
<jdong> Kamion: wherever 'make install' does it by default
<Kamion> I guess if it's in a .deb, /usr is sort of OK, but it brings up issues of distributed packages having to conflict with local packages, so /usr/local would be better
<Kamion> jdong: ok, should generally be /usr/local then
<koke> Amaranth: my idea is to integrate with launchpad
<jdong> Kamion: yeah, depending on the source... Lots of stuff, in my experience, install in /usr by default
<koke> I'll heve to talk to the launchpad guys about extending DOAP
<koke> http://155.210.13.152/fpkgs/web-details-gaim.html <-- this could be the view for an apps.ubuntu.com (?)
<Kamion> jdong: might be worth advising people to be cautious; if they install stuff into /usr, they can't expect support for that situation
<koke> I mean, similar view, with an "install this" button
<Amaranth> koke: aside from the wrapping issue there it looks nice :)
<\sh> koke: can't we create an xml file out of the Packages and putting these infos into DOAP and let the user fill in screenshot and all?
<Amaranth> can konq handle XHTML 1.1 (you need to send as application/xml+xhtml)?
<\sh> Amaranth: tryit :) normally yes
<\sh> (latest versions i think)
<mvo> koke: does your mockup already uses pymozemed?
<koke> \sh: DOAP is an RDF format, ergo it's XML
<Amaranth> \sh: I don't know any site using 1.1, you'd be nuts to use it on a regular website.
<koke> mvo: yep, it's called gtkmozembed though
<jdong> can someone (attempt) to explain to me how the msttcorefonts package works?
<Zomb> jdong: IIRC it fetches the MS fonts packages from sourceforge or so and installs the ttf files
<Zomb> or tries to make symlinks to your local fonts (Windows installation), I don't remember
<Lathiat> jdong: any chance of fixing transcode?
<jdong> Zomb: it fetches.. that's what I'm interested in
<jdong> Lathiat: what's wrong?
<Lathiat> jdong: uninstallable
<Lathiat> jdong: libgcc1 broken dep
<jdong> Lathiat: strange; it works here
<Lathiat> transcode: Depends: libgcc1 (>= 1:4.0.0-7) but 1:4.0-0pre6ubuntu7 is to be installed
<ogra> jdong, if you point users to the checkinstall method, make clear that checkinstall packages have *no* dependencys (a little warning or something would be nice here)
<jdong> Lathiat: what architecture?
<Lathiat> jdong: x86
<jdong> ogra: sure
<jdong> Lathiat: hoary-backports has libgcc1 v 1:4.0.0-7ubuntu6~5.04ubp1
<ajmitch> Lathiat: is it fetching transcode from backports?
<jdong> As far as msttcorefonts, I'm interested in how the fetching mechanism works; I want to make similar packages for Java & such
<Lathiat> jdong: i only show libgcc1 from archive.u.c
<Lathiat> ajmitch: yes
<Lathiat> ahh
<Lathiat> i have hoary-backports commented
<jdong> Lathiat: LOL
<Lathiat> any reason it cant use ubuntus version of libgcc?
<ajmitch> apt-cache policy can be your friend
<Lathiat> ajmitch: well i wasnt aware until jdong told me that backports had its own libgcc1 version
<jdong> Lathiat: transcode's makefile calls gcc-4.0 explicitly
<Amaranth> that's crack
<jdong> I'd rather not violate that...
<Reza_1> Hello, I have some questions about Breezy Bounties. I want to work on http://udu.wiki.ubuntu.com/SmallBusinessServer, what should I write in my proposal?
<Lathiat> i was trying not to use backports and only extras for a couple things
<jdong> Lathiat: nothing wrong with just pulling a few debs individually from the backports archive...
<Lathiat> there goes that idea
<Lathiat> installs now :)
<\sh> jdong: how is it going with the migration of backports into ubuntu backports?
<ogra> \sh, you will see it...
<jdong> \sh: in the keysigning stage ;)
<jdong> I need to talk with a local guy about my key
<ogra> \sh, jdon needs upload rights to the main servers....
<jdong> will get my key signed by the end of the week
* pitti sighs at new Perl's MakeMaker which breaks *everything*
<ogra> pitti, switch it to automake ;)
<pitti> ogra: I just need to fix this damn libpg-perl since it is FTBFS on the buildds
<ogra> gah
<pitti> ogra: and perl mods can't/shouldn't use autoff
<ogra> no, i know.... i was kidding
<ogra> does anybody know if or when the X headers are fixed ? 
* trulux heh
<Reza_1> Hello, I have some questions about Breezy Bounties. I want to work on http://udu.wiki.ubuntu.com/SmallBusinessServer, what should I write in my proposal?
<Lathiat> synaptic 0.56+revertedto+officialhoary+0.55+cvs20050406-1~5.04ubp1
<Lathiat> hmmm. :)
<ogra> err ?
<Amaranth> Lathiat: That's almost worse than warty's firefox.
* ogra cries
<ogra>  error: X11/Xlib.h: No such file or directory
<Lathiat> Amaranth: :)
<Amaranth> ogra: your includes are wrong :P
<ogra> Amaranth, my includes are right
<ogra> Amaranth, Xlibs.h is where it belongs
<ogra> its just broken...
<mvo> Lathiat: I'm preparing a new 0.56.2-1 version now 
<Amaranth> *boggle*
<ogra> seb128, ping, how did you work around that ?
<seb128> around what?
<jordi> pitti: ping
<pitti> jordi: hi
<seb128> oh, .h move, yep
<jordi> jdthood and I recommend you sync alsa packages that will be uploaded in the next few mins to incoming
<seb128> jordi: what's new? :)
<crimsun> 1.0.9b for alsa-driver, no?
<jordi> a few minor bugfixes for the 1.0.9 stuff.
<jordi> noooo
<pitti> jordi: cool, thanks
<ogra> seb128, yep is not a stifying answer ;)
<pitti> jordi: however, it will be autosynced anyway
<ogra> satisfying
<seb128> oh, "how"
<ogra> hehe
<seb128> I didn't get this issue
<seb128> but I would workaround it time to get xorg fixed
<ogra> seb128, i thought you had the same yesterday
<seb128> probably by using -L/...
<seb128> now, you said you have the same issue
<ogra> uhh, an absolute path...
<seb128> I just said that XRes.h is not shipped with current version
<ogra> oh, ok
<ogra> so it was something else... i misunderstood....
<jordi> jdthood: crimsun just pointed us at our new PITA: 1.0.9b :)
<ogra> jordi, fun :)
<Amaranth> seb128: small bug in the latest gnome-menus https://bugzilla.ubuntu.com/show_bug.cgi?id=11616
<jdthood> Sharp eyes, crimsun.
<jordi> ok, it's a fix for the bug we reported :)
<jordi> jdthood: should be as easy as removing the patch and changing the tarball
<seb128> Amaranth: what an useful bug
* jordi licks a lollipop.
<jdthood> 1.0.9b: "fix compilation on 2.2/2.4 kernels"
<jdthood> yep
<seb128> Amaranth: gnome-menu-spec-test? gnome-panel? gmenu-simple-editor?
<seb128> Amaranth: where do you get the bug, how, etc
<Amaranth> oh, heh
<Amaranth> gnome-panel
<seb128> Amaranth: so why do you bug on gnome-menus?
<Amaranth> because the gnome-menus source package provides the lib that loads gnome-preferences.menu
<Amaranth> unless i don't understand how that works, which i probably don't
<seb128> Amaranth: gnome-panel opens the .menu
<seb128> what happens for you? panel crash?
<seb128> you have an empty menu?
<Amaranth> no menu
* Amaranth will just go back to not filing bugs
<seb128> which one?
<Amaranth> i end up having to answer stuff on IRC anyway
<Amaranth> um, the preferences one
<seb128> bah, let's say it, your bug is useless
<seb128> it doesn't describe anything from your issue
<Amaranth> no, i sound like a user
<stuNNed> hi can i ask what is the current status of http://udu.wiki.ubuntu.com/CalendaringSynchronisation , still waiting on upstream?  I've noticed the bounty isn't claimed yet.
<seb128> Amaranth: grep preferences /etc/xdg/menus/gnome-settings.menu ?
<seb128> I guess you have modified this conffile
<seb128> so it didn't get update
<seb128> which creates your "bug"
<seb128> no?
<Amaranth> no
<seb128> what returns the grep?
<Amaranth> <MergeFile>preferences.menu</MergeFile>
<Amaranth> i haven't modified this file
<seb128> <MergeFile>gnome-preferences.menu</MergeFile>
<seb128> ls /etc/xdm/menus ?
<seb128> ups
<seb128> ls /etc/xdg/menus ?
<Amaranth> well, that will have preferences.menu in it, because i made a copy to see if that was the bug
<Amaranth> dpkg-new, wtf
<seb128> ?
<Amaranth> i didn't touch those files
<seb128> you changes preferences.menu at some point
<seb128> md5sum /etc/xdg/menus/gnome-settings.menu
<Amaranth> obviously it isn't going to match yours
<seb128> 027cd947acfea2cfd4aa3056577de07c  /etc/xdg/menus/gnome-settings.menu
<seb128> so you changed it
<Amaranth> i have not touched it
<Amaranth> smeg has not touched it (doesn't suppose those yet)
<seb128> /etc/xdg/menus/settings.menu
<Amaranth> doesn't exist
<seb128> yeah, but it used to
<seb128> it has been moved to gnome-settings.menu
<Kamion> jbailey: did https://bugzilla.ubuntu.com/show_bug.cgi?id=10933 get fixed in initrd-tools, by any chance? A breezy initrd seems to be able to handle that situation fine ...
<seb128> with preservation of users changes on settings.menu
<seb128> you never ever touched settings.menu since you installed your distro?
<Amaranth> not that i'm aware of
<seb128> weird
<seb128> somebody did
<Amaranth> *groan*
<seb128> anyway, just change it
<Amaranth> gmenu-simple-editor?
<seb128> I'm closing the bug :)
<Amaranth> no, that didn't run as root
<jbailey> Kamion: not intentionally by me.  We might have inherited it from Sarge.
<Amaranth> unless someone broke into my system through apache and got my password that file hasn't been touched
<seb128> diff between the .new and the current one?
<seb128> gnome-settings.menu and gnome-settings.menu.dpkg-new?
<Amaranth> already got rid of the old one
<seb128> k, so forget about it, just edit it to change the filename
<Kamion> jbailey: the hoary->breezy diff doesn't look as if it could be responsible, at least ..
<Amaranth> would a timestamp change count as an edit?
<Amaranth> i know gnome-applications.menu changed that way
<ajmitch> Amaranth: it shouldn't
* Amaranth blames dpkg
<Kamion> hmm, I wonder if it's an LVM1 thing
<Kamion> nah
<pitti> thom: can I please have the qt-x11-free build-deps in concordia's breezy dchroot?
<pitti> thom: and the ones of pike7.6?
<pitti> daniels: ping
<Kamion> pitti: uh ... if perl 5.8.7's MakeMaker is broken, please report that to bod
<Kamion> pitti: he explicitly asked for us to report bugs back to him
<pitti> yes, I will do that
<Kamion> that's why we're syncing his stuff from experimental
<elmo> pitti: please direct install requests to me
<pitti> elmo: ok :-) 
<elmo> pitti: done
<pitti> thanks
<danielk> hi
<tseng> is it possible to set defaults for casper?
<tseng> so that it doesnt ask for locale etc on boot
<lu|sleep> tseng: if you want it to just be en_US, use the i18n tips in the liveCD howto
<tseng> oh!
<tseng> thanks.
<lu|sleep> that should work, at any rate :)
<tseng> is the keyboard map in the same file
<lu|sleep> hrm
<lu|sleep> don't know
<tseng> or you havent figured it out.
<lu|sleep> good question
<Kamion> preseed/locale=en_US kbd-chooser/method=us
<Kamion> or similar
* tseng adds to wiki
<pitti> infinity: ping
<sparkling> hi all
<pitti> infinity: are you able to give-back packages? or is that still lamont-ish?
<tseng> pitti: he did it for me.
<Kamion> infinity has w-b access now, so yes
<sparkling> is there a money manager tool like gnucash or kmymoney in unbutu livecd for ppc?
<tseng> sparkling: no.
<sparkling> is it possible to install in live?
<Kamion> you can install packages while running the live CD, yes
<sparkling> and is it possible (and simple) insert the program in the iso? or install on a usb pendrive and load the program during boot?
<Kamion> if you've got network access you can just use synaptic
<Kamion> oh, customise the ISO
<Kamion> see the wiki, LiveCDCustomization or similar
<tseng> https://www.ubuntulinux.org/wiki/LiveCDCustomizationHowTo
<sparkling> ok
<sparkling> is also possible the second chance? install it on a usb pendrive and load the program each time at boot?
<sparkling> at live cd boot i mean
<tseng> LiveCDPersistence
<Kamion> you'd have to customise the ISO anyway to get it to do that automatically
<infinity> pitti : What do you need?
<pitti> infinity: http://people.ubuntu.com/~lamont/buildLogs/p/pike7.4/7.4.117-1ubuntu2/pike7.4_7.4.117-1ubuntu2_20050607-0452-i386-failed.gz looks rather weird
<pitti> infinity: some "could not install packages" foo
<sparkling> Kamion ok tnx i'll try the wiki
<pitti> infinity: dunno whether a g-b helps, though
<infinity> pitti : That looks like the sort of thing you should whine to daniels about, not me.
<infinity> pitti : (Actually, don't, I'm just trying to irritate him)
<infinity> pitti : Probably build-deps with conflicting dependencies, leading to X stuff getting uninstallable.
<pitti> infinity: don't worry, I tried to ping him already about the qt-x11-free FTBFS
<infinity> (At a guess)
<pitti> infinity: ok, I try in a dchroot
<infinity> A give-back almost certainly won't fix it.
<infinity> (I['ll give 'em back anyway, spinning a build for 3 seconds doesn't hurt)
<infinity> Yay, I'm turning into lamont, lazy troubleshooting and all.
<infinity> I blame the fast buildds.
<pitti> elmo: can I please have the pike7.4 b-deps in concordia's breezy dchroot?
<pitti> (bah, and WTH is pike anyway...)
<sparkling> tseng what does "as a persistent Copy-On-Write overlay" mean exactly?
<tseng> it means what it says really
<tseng> its an overlay of the cd filesystem
<infinity> pitti : It's a scripting language.
<tseng> so if you write a file, it makes a changed copy in the overlay
<tseng> and overrides the one on the cd
<pitti> infinity: I know, it's just sooo common... :-)
<ogra> pitti, morgue it :-D
<sparkling> so after that procedure..each time i boot from the live with the usb inserted i can use a program installed on the usb pen?
<infinity> pitti : Also the core for roxen and causium.  Which makes it evil by definition.
<sparkling> for example
<ogra> pitti, who needs pike ;)
<infinity> s/causium/caudium/
<tseng> sparkling: presumably.
<sparkling> ok tnx
<pitti> infinity: ah, so we have a language that nobody uses as a dependency for a web server that nobody uses and both is in main???
<infinity> pitti : Nope, same build-dep breakage on a retry.
<pitti> infinity: ok, thanks
<infinity> pitti : caudium is in main?!
<infinity> pitti : You must be joking.
<pitti> no, it isn't
<pitti> however, pike is in main, something must pull it in...
<infinity> Build-dep for swig.
<infinity> I bet nothing in Debian/Ubuntu actually generates pike extensions with swig.  Maybe I should just turn that language off, and kick pike to universe. :)
<pitti> ++ :-)
<Treenaks> people use pike? ;)
<ajmitch> why does pike appear in universe here?
<pitti> infinity: anyway, you're right. both qt and pike looks rather danielish
<pitti>    pike7.6 | 7.6.24-1ubuntu2 | http://archive.ubuntu.com breezy/main Packages
<pitti>    pike7.6 | 7.6.24-1ubuntu3 | http://archive.ubuntu.com breezy/main Sources
<pitti>    pike7.6 | 7.6.9-2ubuntu1 | http://archive.ubuntu.com warty/universe Sources
<pitti>    pike7.6 |   7.6.13-1 | http://archive.ubuntu.com hoary/main Sources
<ajmitch> ah, pike7.6, not pike
<infinity> ajmitch : 7.2 and 7.4 are in universe, 7.6 is in main.
<infinity> (Though that situation was different in warty)
<pitti> ajmitch: 7.4 is main in warty only
<infinity> For the same reason, swig build-dep.
<infinity> And that appears to be the only reason.
<infinity> There isn't even a binary dep.
<elmo> pitti: done
<pitti> elmo: thanks
<infinity> Someone remind me later to see if any swig-using packages actually generate pike extensions.  I find myself oddly curious now, but also rather tired.
<pitti> infinity: hmm, so if elmo is able to install the b-deps of pike7.4 (I am too, locally), why can'T the buildd?
* Amaranth heads for bed
<infinity> pitti : Cause the buildds are less bright?  Let me have a look.
<elmo> no, probably because the buildds have restricted views
<elmo> tho given pike7.4 is in universe, that shouldn't matter
<infinity> Right.
<pitti> elmo: yeah, I just wanted to fix it again after breaking it with postgresql foo...
<infinity> Any better theories, then? :)
<pitti> infinity: blame daniels and get to sleep :-)
<infinity> (other than "apt-get build-dep finally surpassed sbuild's installation routing a while ago, and we should just use it")
<infinity> s/routing/routine/
<elmo> haha, right
<infinity> Ah, there is it.
<infinity> pitti : Replace "xlibmesa-glu-dev | libglu-dev" with "libglu-dev-xorg | libglu-dev"
<infinity> At least...
<infinity> And curse daniels while you do it.
<pitti> infinity: ok, thanks for investigating that
<infinity> np/
<infinity> Now I see sleep in my near future.
<pitti> infinity: sleep well!
<robertj> Ouchie. CD installs of Debian 3.1 didn't ship with security repos :(?
<bob2> robertj: fixed, new cd images are already up
<robertj> bob2: yeah, that was rather bad though
<maswan> bob2: are up:ish.
<bob2> maswan: still rsyncing or something?
<maswan> bob2: still building
<JohnDong> can we eventually get the new nvidia modules in Breezy?
<maswan> bob2: i386 is done though, so I guess most people are ok
<JohnDong> I'm playing with this right now
<ogra> JohnDong, we dont have l-r-m yet
<ogra> JohnDong, since the new kernel is still in universe
<JohnDong> k
<fabbione> JohnDong: when the new nvidia drivers come out?
<ogra> if it moves, we'll have l-r-m too very soon....
<fabbione> last i checked they are the same version as in hoary
<JohnDong> fabbione: a few days ago
<JohnDong> http://ubuntuforums.org/showthread.php?t=39236
<Kamion> robertj: was one of those things that was painful to check in advance, due to the way apt-setup works
<JohnDong> I'm already gettin bugged about it
<Kamion> robertj: as in, in order to test it properly, you had to hack up your mirror to pretend that sarge was already stable
<JohnDong> weren't you guys planning to offer "update packs" for Hoary?
<JohnDong> at least that was referenced to in Bugzilla
<robertj> Kamion: maybe it should just always point to sarge
<JohnDong> and also, do you guys mind if I apply the Firefox frame injection patch to the Backports version
<Kamion> robertj: people say that a lot; I don't understand why it's done this way, but I know there was a reason
<fabbione> JohnDong: please do not backport the kernel or l-r-m
<Kamion> well, s/understand/remember/ maybe
<robertj> Kamion: I suspect its because theoretically you should be able to dist-upgrade via crond and never have a problem, in some bizzarre fantasy world
<fabbione> JohnDong: it's a bad idea if you don't backport hell of a lot of other stuff
<JohnDong> fabiione: I won't... wasn't planning on it
<JohnDong> so... the Firefox question?
<robertj> Kamion: are they going to alter stable to fix that bad adding a dep on base?
<robertj> err by adding
<ogra> JohnDong, ?
<JohnDong> ogra: can I add https://bugzilla.mozilla.org/show_bug.cgi?id=296850 to the Backports version, as it is vulnerable
<JohnDong> supposedly 1.0.2 (Hoary) is unaffected, so it's just a Backports/Breezy problem
<JohnDong> since it's already included in the aviary branch, I assume it's pretty well reviewed
<ogra> JohnDong, i cant answer this, talk to pitti or thom about ff/security
<JohnDong> k, e-mail time :)
<Kamion> robertj: I don't understand your question
<pitti> JohnDong: breezy has 1.0.4 and should have all issues fixed...
<JohnDong> pitti: no, this is a brand-new thing
<JohnDong> pitti: breezy's 1.0.4 is affected
<pitti> ah, ok
<JohnDong> pitti: https://bugzilla.mozilla.org/show_bug.cgi?id=296850
<JohnDong> pitti: I'm interested in the "aviary branch..." patch
<pitti> JohnDong: ah, I see, an 1.0.3 regression
<JohnDong> yep
<pitti> JohnDong: that's a thom issue; but supposedly they will release 1.0.5 soon then?
<JohnDong> pitti: maybe. I don't know if they feel it's urgent enough
<JohnDong> pitti: but in the meantime....
<JohnDong> I'll e-mail thom and cc to you
<robertj> Kamion: If you broke the rules and added a package to *ahem* Stable, you could fix the sources.list in a postinst
<Kamion> robertj: nah, overcomplicated compared to just rebuilding the CDs, and posting the trivial fix to announcement lists
<robertj> Kamion: I think, except for policy dogma, it's worth it because Debian is going to have trouble living this one down
<Kamion> building the CDs against a current archive fixes the problem; the problem was just that the CDs were built before release, and the tweaks to make sure they thought they were stable weren't complete
<Kamion> robertj: oh, rubbish, it's happened before. :)
<robertj> Kamion: really?
<Kamion> certainly similar things
<Kamion> and no, it's not worth the support issues with that approach
<robertj> I guess mirrors might not check for changes on stable anyway...
<Kamion> robertj: depending on the type of install you do, you may not have *any* network repositories in sources.list
<Kamion> robertj: so that fix is not even possible
<Kamion> we did talk about this and go through just about all the alternatives. :)
<Kamion> reminds me, though, I have some testing to do ...
<dato> is there a known problem in hoary-security with the md5sum of main/binary-i386/Packages.bz2?
<dato> nevermind, transparent proxy going astray at $work
<Nafallo> zul: got time to sync rt2400 && rt2500 before the next kernel hit the archive? :-)
<elmo> hey, why is discover still in base?
<elmo> oh, it's not in breezy nm
<zul> Nafallo: no...next version
<Nafallo> zul: oki. cool.
<Kamion> elmo: was there for xserver-xorg.config
<elmo> Kamion: ah
<Kamion> (now we just install it on-demand)
<eruin> are the installer cds functional atm?
<Kamion> eruin: no, X is broken
<ogra> heh, eruin what a question :)
* eruin hides :p
<Kamion> assuming you mean the dailies
<eruin> yup
<wasabi_> So is there a script to run to recreate /dev? :)
<cartman> daniels: ping 
<daniels> cartman: pong
<jdub> Kamion: for a new ubuntu administrator, would you recommend command line use of aptitude over apt-get?
<Kamion> jdub: I don't see why not
<cartman> daniels: libxrandr-dev should install Xrandr.h to /usr/include/X11/extensions
<cartman> daniels: randr.h is there already
<daniels> cartman: it's in /usr/X11R6 still
<Kamion> jdub: you certainly don't lose anything, and it has more facilities
<daniels> when libxrandr gets split (which it will), it will be in /usr
<cartman> daniels: yes and causing Qt not to find it
<cartman> daniels: ok
<daniels> cartman: qt needs -I/usr/X11R6/include for the time being
<Kamion> jdub: and is somewhat more unified (aptitude install/search vs. apt-get install/apt-cache search)
<daniels> Kamion: tomorrow (AEST) fo'sho
<cartman> daniels: its ok if you are aware. I already workarounded it here
<cartman> daniels: thanks for your time
<daniels> no worries
<ogra> daniels, i have similar issues with Xlibs.h, any ETA when this is fixed ?
<daniels> ogra: xlib.h will be in the upload tomorrow, for better or worse
<ogra> daniels, thanks :) 
<daniels> Kamion: gar
<daniels>          AssignedTo|debzilla@ubuntu.com         |daniel.stone@ubuntu.com
<daniels>              Status|PENDINGUPLOAD               |UNCONFIRMED
<Kamion> daniels: it just did that, I didn't tell it to
* Kamion blames bugzilla
<Kamion> sorry ...
<Nafallo> jdub: and aptitude helps to clean the system when/if you remove stuff :-).
<daniels> Kamion: no worries
<seb128> daniels: hey. Read my msg about XRes.h? :)
<daniels> seb128: hrm
<daniels> seb128: it should be in /usr/X11R6/include/X11/extensions
<daniels> or maybe /usr/include/X11/extensions
<daniels> let me check
<seb128> daniels: libxres-dev doesn't ship any .h atm
<daniels> seb128: right, it's in /usr/include/X11/extensions now
<daniels> seb128: correct, it just depends on x11proto-resource-dev
<daniels> seb128: the way to include all X headers is <X11/foo>
<daniels> so you need to include <X11/extensions/XRes.h> and have -I/usr/X11R6/include as a fallback
<daniels> that covers both cases
<seb128> I don't have X11/extensions/XRes.h
<seb128> what package should ship that? 
<daniels> x11proto-resource-dev
<seb128> thanks
<seb128> libxres-dev should depends on that :)
<daniels> erk, it doesn't?
<seb128> hum
<seb128> no
<seb128> $ apt-cache show libxres-dev | grep Depends
<seb128> $
<daniels> yeah
<daniels> seems a couple of them are missing.  hm.
<jdub> seb128: planning to package istanbul (or know of someone who is)?
<seb128> jdub: dholbach did yesterday
<seb128> it's up for review I guess
<jdub> cool
<seb128> needs 3 review to be uploaded, feel free to be 1 of them
<seb128> s/be/do/
<kartman> jdub: istanbul?
<ogra> jdub, dholbach
<kartman> jdub: are you packing my city? ;)
<ogra> jdub, it is on MOTUNewPackages since the weekend
<Burgundavia> kartman, we like the blue mosque and figured that we could use it elsehere
<kartman> Burgundavia: damn
<ogra> jdub, i'm very much after it for edubuntu, so you'll see it soon in universe
<Burgundavia> ogra, the doc team is after it too
<ogra> hehe
<jdub> kartman: live.gnome.org/Istanbul
<kartman> jdub: jealus jealus I am...
<daniels> woah, go istanbul
<lu|sleep> jdub: oh, hey, you might know; is the magic gstreamer streaming java applet open/available anywhere?
<Lathiat> lu|sleep: well, fluendo have the java applet that decodes theora, no idea of its openness
<lu|sleep> yeah, that's the one I meant
<lu|sleep> there was some discussion of using that on gnome.org instead of flash
<lu|sleep> for desktopcast
<ogra> jdub, the planet css could need some additional love, i cant see any links if they are in the text
<ogra> at least not in your text...
<Nafallo> lu|sleep: The Fluendo playerless streaming applet is released under the GPL and currently available for download from the Flumotion website.
<ogra> jdub, or in \sh's
<Nafallo> lu|sleep: from fluendo.com :-)
<lu|sleep> this is what I get for asking people instead of google
<lu|sleep> ;)
<ogra> heh
<jdub> lu|sleep: that'd mean running gstreamer process or flumotion though, i believe.
<Nafallo> lu|sleep: I didn't even google ;-)
<jdub> lu|sleep: i don't think cortado does "play this ogg"
<jdub> maybe it does though
<lu|sleep> <nod>
<lu|sleep> jdub: thomas was pushing it as a more open option, but we didn't have time to discuss the details
<jdub> makes sense
<lu|sleep> yeah
<lu|sleep> I'd definitely prefer that to flash
<lu|sleep> assuming it is workable, the load isn't much worse on the servers, etc.
<lu|sleep> jdub: hrm, yeah, looks like flumotion is required on the backend
<lu|sleep> which is fine
<jdub> where "fine" means "as your attorney, i suggest you fire all of your sysadmins"
<lu|sleep> haha
<lu|sleep> well
<lu|sleep> there is that
<lu|sleep> :)
<dholbach> jdub: you can review it on MOTUNewPackages - it will speed things up ;-)
<lu|sleep> I mean 'fine for me' :)
<ogra> dholbach, i'm just reviewing it too... get a third one... quick ;)
<jdub> dholbach: ok
<dholbach> *snigger*
<jdub> lu|sleep: http://ubuntu.gplan.info/istanbul/
<dholbach> i was bored from my thesis yesterday, saw istanbul on the planet and had the package an hour later :)
<lu|sleep> jdub: I built it myself yesterday :)
<jdub> lu|sleep: test the packages you hippie!
<ogra> jdub, lu|sleep is no MOTU ..... (still not *sigh*)
<ogra> lu|sleep, but that would be a good start indeed *g*
<jdub> ogra: luis time is better spent on other things. like my massage. over a bit, to the left, up a bit, aaaahhhh.
<dholbach> hahahaha :)
<ogra> hehe
* lu|sleep hears pia enter the house, hides under the bed
<ogra> loool
* jdub notes that luis is asleep on one network, awake on the other.
* lu|sleep notes that luis owns luis on one network, and not on the other
<jdub> suck!
<jdub> dholbach: no source repo bits :)
<dholbach> jdub: excusez-moi?
<ogra> dholbach, .ex ?
<jdub> dholbach: your istanbul dir is just files, can't use it with deb-src :)
<ogra> jdub, you download the bits and run  dpkg-source -x istanbul_0.1.0-0ubuntu1.dsc ;)
<dholbach> those files include  .dsc .diff.gz and .orig.tar.gz
* jdub boggles.
<jdub> guys
<dholbach> ogra: oh yes...
<ogra> jdub, we dont expect form a MOTU to be able to set up repo servers ;)
<jdub> using source repositories means i don't have to copy and paste all those file names to wget
<Kamion> dholbach: you need a Sources.gz file for apt-get source
<jdub> ogra: it's really easy
<ogra> jdub, i know, i run my own repos
<dholbach> deb-src sucks
<dholbach> it really does :)
<Kamion> dholbach: apt-ftparchive sources . | gzip -c > Sources.gz
<dholbach> i want to see what i pick :)
<jdub> so if you have one dir with those in it, i can just apt-get source your stuff whenever you want me to review it
<dholbach> i had a source repo set up, but didnt like it
<jdub> which makes life easier, and reviews faster :)
<Kamion> eh? you only ever get sources by hand
<dholbach> i have to review packages from 42697426 repositories :)
<dholbach> it makes no difference in the end
<ogra> Kamion, yes, and he is twice as fast as we all are if he needs.... he will blow up if you give him deb-src repos ;)
<Kamion> ogra: it wasn't giving *him* Sources files that I was talking about. :)
<jdub> dholbach: for regular MOTUs (like yourself), it will
<jdub> if Packages/Sources could include http: lines, we could do aggregations
<jdub> oh
<jdub> oh
<jdub> holy shit
<jdub> mvo: dude?
<mvo> jdub: ?
<Nafallo> lol
<ogra> *g*
<ogra> dholbach, ergh... gstreamer0.8-plugins is not installable....
<dholbach> that's funny
<dholbach> at my place it is
<ogra> hmm...
<ogra> strange
<ogra> do you use the german mirror ?
<JohnDong> greetings, world :)
<ogra> dholbach, erhg, why does it install in multimedia ? 
<JohnDong> Openoffice.org2 in Breezy is kind of old... are there any plans to update it? (I know, it's monstrous)
<ogra> jdub, is that the right place ? i would expect it in tools
<ogra> oohhh, i lost my control-center completely
<ogra> seb128, ?? ^^^
<seb128> due to the menus rename
<dholbach> ogra: fixed the manpage
<mdz> Kamion: I ended up writing an askpass program to pass the passphrase on an fd
<seb128> nobody uses that anyway, it'll be fixed with next upload
<ogra> dholbach, great... i think you missedmy last question.... shouldnt that be in the tools menu ? or is it a playback tool too ?
<ogra> seb128, i use it :)
<dholbach> ogra: i didnt write that desktop entry, but it's ok in audio&video i think
<ogra> seb128, gnome-powermanager puts its icon in there.... 
<seb128> that'll be fixed
<seb128> but that's low priority
<seb128> there is no menu entry for this panel
<seb128> and I doubt many people run it from the command line
<Kamion> mdz: sounds like a sane approach
<ogra> seb128, i'm just to lazy to start it from alt-f2, dont worry....
<mdz> Kamion: oh, you were responding to the backgrounding thing
<mdz> that's still an issue
<pitti> Morning mdz
<mdz> I can only think of awful hacks to do that
<mdz> pitti: morning
<mvo> morning mdz
<ogra> dholbach, i think its a tool, not a multimedia app.... as i think CD recording apps dont belong there since they are backup tools too...
<ogra> dholbach, but i might be wrong :)
<dholbach> :)
<ogra> as i'm not a HIG guru.....it just feels wrong :)
<ogra> heh, recording and running it fullscreen afterwards is funny....
<ogra> dholbach, if the manpage is fixed its a go from my side....
<dholbach> a bit bumpy, but funny
<dholbach> well, the binary has no command line options, so it was easy to write :)
<ogra> heh
<dholbach> ogra: wouly you make a note on MOTUNewPackages?
<ogra> yup
<dholbach> excellent
<ogra> btw, Desktop as the default save location would be cooler i think...
<ogra> like the screenshot tool does
<dholbach> i have my home as "desktop", so i'm happy :)
<ogra> but thats not the default (yet) ;)
<dholbach> unfortunately not
<fabbione> hey mdz
<dholbach> ogra: could you file those items as bugreports? upstream? :))
<dholbach> jdub: did you try it already?
<mdke> where's the package dholbach?
<dholbach> mdke: ubuntu.gplan.info/istanbul
<dholbach> but it's a source package
<mdke> genius
<mdke> right
<dholbach> i would have packaged istanbul whatever it was... istanbul rocks :)
<mdke> Burgundavia was saying maybe we could use it for documentation
<mdke> would be awesome for tutorials
<dholbach> yeah
<dholbach> that sounds good
<jdub> mdke: istanbul + annodex :)
<jdub> (annodex.net)
<Nafallo> daniels: ping
<JohnDong> ugh... I spend an hour compiling Firefox.. just to figure out that I forgot the security patch. I'm gonna start crying.... :(
<rob_afk> is there a web backend speced out for hwdb?
<mdz> fabbione: what are the factors affecting the 2.6.12 release?  is losing bitkeeper causing a lot of problems?
<Nafallo> fabbione: ping
<ogra> robertj, not yet, but it will be a postgres DB 
<fabbione> mdz: 2.6.12 should be out next week. the major issue was some internal stuff apparently, that got solved pretty quickly
<fabbione> mdz: 12rc6 was out today and it's already in the archive. we have 2 successfull ppc64 tests and i plan to kill power3/power4 soon
<fabbione> Nafallo: pong
<mdz> wasabi,doko: libxerces2-java build-depends on libxml-commons-resolver1.1-java which build-depends on libxerces-java (the old one).  that can't possibly be correct, can it?
<fabbione> mdz: there is some stuff (packaging related) that needs real cleaning.
<Kamion> smurfix: fancy putting keymapper in Debian? it'd reduce the amount of dependency-chasing in my life ...
* Kamion -> TV
<Nafallo> fabbione: is there any specific patchorder in xfree86/debian/patches I should use for patching CAN-2005-0605? :-)
<fabbione> Nafallo: yes. look at debian/README*
<smurfix> Kamion: sure, will do
<Nafallo> fabbione: k, thanx
<fabbione> it explain how patches should be numbered and why
<Kamion> smurfix: great, thanks
* Nafallo was stunned about the amount of files in there ;-)
<robertj> ogra: is any help needed with that? I've done lots of stuff with php and MySQL, but I think I could probably survive a move over to pgsql
<ogra> robertj, it will most likely be python or even zope.... but once i have speced everything out, i could need helping hands indeed
<robertj> ogra: I'm pretty much a one-trick poney these days :(
<ogra> you mean youre bound to php ?
<robertj> Yeah, I'm sure it wouldn't be a horrible experience breaking out
<ogra> python is cool.... especially for cgi and web development :)
* fabbione goes for dinner
<robertj> is Formal Test Plans speccing out the db or are you?
<robertj> (are you FTP ?)
<Burgundavia> jdub, as soon as that fridge is live I have content for it
<dholbach> have a nice evening
<dholbach> ah... btw: some of you STILL didnt sign my key (since UDU)!
<dholbach> *wave*
<robertj> ogra: is the web frontend part of formal test plans or is it on its own?
<ogra> robertj, formal test plans is something completely different....
<ogra> robertj, the hwdb is specced out in the HardwareDatabaseRoadmap
<robertj> Oh, I had hoped that you would be able to use hwdb to pull a list of all software that was formally tested
<ogra> later perhaps... currently its a _hardware_ database :)
<robertj> ogra: so really, the interface hardly matters
<ogra> robertj, see the roadmap.... there are some milestones
<robertj> I'd imagine the first months would be consolidating existing databases
<robertj> will do, let me finish up reading HardwareDatabase
<ogra> the first thing is to make the flatfile thing more sane... then: to have a script that can present the xml for debugging purposes and after this we can care about a SQL ER diagram and DB design....
<robertj> Count me out on the XML portion ;)
<ogra> and in the last step we'll have a searchable web interface... but thats really not the biggest amount of work...
<ogra> since the DB should do the work here
<robertj> Frequency might be interesting as well
<ogra> Frequency ?
<robertj> "11.4% of our users have X integrated video, and it doesn't do A B and C properly"
<ogra> yep, thats the target....
<mdz> Kamion: you're going to be on TV? ;-)
<ogra> mdz, where, when ?
<mdz> ogra: * Kamion -> TV
<ogra> hehe
<ogra> ok, i'm slow today
<robertj> ogra: okay, done reading HwDb, no Roadmap page on the wiki, where should I look?
<ogra> robertj, http://udu.wiki.ubuntu.com/HardwareDatabaseRoadmap
<robertj> doh, forgot to check udu
<ogra> heh.... i even forgot there was a hwdb page on the ubuntu wiki.... 
<robertj> ogra: its kinda big brotherish, but if you checked back periodically with the hwdb, and the hwdb saw a large % of users of a certian type of hardware dissapear...
<chmj> what are the chances that sarge's 2.4 kernel will work with ubuntu 
<ogra> robertj, as long as you cant map the userdata to the hwdb data i see nothing bigbrotherish there
<ogra> chmj, small ?
<chmj> ok 
<ogra> up to sery-small i guess...
<ogra> very even
<ogra> but it depends what you expect....
<robertj> ogra: I guess you right, no need to track to a particular machine
<chmj> now, compiling a 2.4 kernel will do me any justice ?
<ogra> i guess it will boot, but with a big lack of functionallity....no idea how much essential stuff will be included there...
<ogra> (in the lacking functionallity)
<ogra> robertj, we even cant do that....
<doko> mdz: yes, will look, if wasabi doesn't beat me. need an ooo2 build as well, but ant looks broken
<ogra> robertj, it would be possible if you have some additionalk databases to link with..... i.e. manufacturers + sellers (in the hope they store customer data) + hwdb a hell lot of money to pay the programmers to make this work together....
<mdz> doko: ant is working for me with other packages
<robertj> ogra: so where do the " More than 20,000 datasets in < 30 days (currently 755 submissions a day on average)" currenty reside?
<ogra> hwdb.ubuntu.com
<ogra> robertj, the average dropped a bit to 5-600 a day.... but its still plenty :)
<tseng> i post 10 times a day
<tseng> 20 on weekends.
<ogra> tseng, ah, now i know why my bandwith bill is this high :)
<robertj> ogra: what machine is that thing on?
<robertj> its kinda ... not so speedy
<ogra> the current DB ?
<robertj> whatever it is
<ogra> its a PII 233.... 128MB.... soon to move....
<robertj> yeah, I can see where the slowness would be from
<ogra> robertj, nope
<ogra> robertj, if i run flatfile its really speedy.... 
<ogra> robertj, but to have some diskspae left i had to bzip2 all files....
<robertj> how big is the dataset?
<ogra> robertj, so there are running tons of bunzips for every small action to grep through the files... thats what causes the slowness
<Lathiat> ogra: oh nice
<Lathiat> ogra: why do we stillnot have some new hardware for this?:)
<ogra> and if i'm at 65000 files i'm fucked.... so something will happen very soon....
<robertj> bwahaha
<ogra> Lathiat, its not a hardware issue
* robertj sets up a script to help out Ogra reach 65k
<Lathiat> ogra: disks are hardware :)
<robertj> is 65k the limit of files that can be in a single directory?
<ogra> Lathiat, its there
<mdz> Kamion: hmm, after a recent (debconf?) upgrade of my ltsp client, dpkg-reconfigure -fnoninteractive now asks questions with whiptail
<ogra> Lathiat, but i'm not there yet ;)
<Lathiat> ogra: ah right
<Lathiat> ogra: where is there?
<ogra> robertj, yep
<ogra> Lathiat, DC
<mdz> this will also break the live CD
<robertj> ogra: so what is the XML view of the data going to be used for
<ogra> robertj, just display the whole set with a dtd and css on top 
<robertj> seems like that should come after the sql database instead of before  then
<ogra> robertj, i'm planning to have something like the device manager online... so you actually can look up data with the id...
<ogra> robertj, we need access to the data for certain tasks, so it has to come first
<ogra> s/certain tasks/certain tasks bound to the release cycle/
<ogra> (bugtracking, laptop testing etc)
<robertj> ogra: it just seems like it would almost be just as easy to put it right into a db proper and then spit the xml back out
<ogra> the DB itself does not depend on this cycle.... so this can be postponed rather then full access to the data
<\sh> re
<robertj> ogra: whats the disk-size of the set uncompressed?
<ogra> robertj, i stopped measuring at 3GIG
<ogra> that was around 25000 sets....
<robertj> what about compressed?
<ogra> 1GIG
<ogra> (now)
<robertj> do you give out copies ;)
<ogra> robertj, heh
<ogra> robertj, i'm fearing the first mail of a marketing company regarding this data.....
<robertj> What could they really do with it
<robertj> I guess they could figure out where Ubuntu was used
<ogra> robertj, which hw is mixed with which.... what are the users complaining about HW wise etc.... you can read a lot out of this data.... 
<robertj> yeah, but other than "Your using Linux, were not accepting your warranty," I don't see what harm it could do
<robertj> which would be illegal here anyway
<ogra> i have reports from 43000 users....
<Kamion> mdz: TV> no ;-)
<Nafallo> ogra: two or three are from me ;-)
<ogra> alone a percentage report of the used HW would be very valuable
<Kamion> mdz: a DEBCONF_DEBUG=developer log would be useful
<robertj> ogra: oh, it's certainly useful
<mdz> Kamion: I just uploaded a patch to breezy
<mdz> Kamion: and sent it to joeyh
<robertj> But is it bad to give companys useful information? Would Canonical want to sell it?
<ogra> robertj, thats not what i mean.... 
<mdz> even though he's being a wanker lately
<Kamion> *shrug* a number of his points are valid I think
<mdz> I've personally sent him gobs of code in the past
<ogra> robertj, i dont want to see it in the wrong hands.... marketing companys may be even more creative with this data thenm we both can imagine ;)
<Kamion> hmm, I didn't think that code had changed lately
<robertj> ogra: perhaps you could deliver it to me via a droid?
<mdz> I understand his gripe about linking to the patches from the BTS, but there's nothing I can do about it, and it's an awfully minor thing
<Kamion> I do think we need to change that now that Ubuntu is well-known
<mdz> apart from that, I think his arguments are more emotional than rational
<Kamion> it was originally to get our name known, and I think we're pretty safe on that front now
<mdz> which holds for most of the extreme views in that thread
<robertj> ogra: I can see how HP might be unhappy if saled underperformed and the whole world could see...
<Kamion> well, I'm glad he said what he did about base-config
<Kamion> since it's pushed me into a re-merging effort
<ogra> robertj, thats what i mean... i dont want it to be abused in such a way...
<robertj> so frequency data has to be kept private?
<Mithrandir> we've sucked at giving patches back and I think we should concentrate more on that, but the debate so far hasn't exactly been constructive.
<mdz> I'm not entirely glad about that, since you have enough to do already without spending a lot of time on code which already works
<Kamion> base-config merges take me entire days
<mdz> (even if it is sort of an overgrown mess)
<Kamion> really
<mdz> I'd rather days in the future than days now
<ogra> robertj, nope.... but be treated very sensible
<Mithrandir> mdz: at some point it'll be weeks, not days.
<Kamion> they're also soul-crushing
<Kamion> I like having a soul
<mdz> Mithrandir: if base-config undergoes major change, then we'll do the work at that time to make it easier
<mdz> it's fine to be reactive with this
<Kamion> hmm, bubulle deleted that code in r1700 (1.4.43) for some reason
<Kamion> the changelog entry does not match it
<mdz> Kamion: which, the debconf stuff?
<Kamion> yes
<mdz> yeah, I didn't see anything in the changelog about it
<mdz> oh, it used to look exactly like I changed it to look
<mdz> I wrote that without looking at the old version; I thought the fallback was new :-)
<robertj> ogra: hrmm, could you zip up a hundred reports maybe and send em my way?
<mdz> Mithrandir: we haven't sucked.
<ogra> robertj, could you produce them yourself by runnin the hwdb client without network access ?
<robertj> ogra: I could I suppose, but they would be similar ;)
<ogra> it drops the dataset on your desktop
<ogra> the structure is always the same...
<Mithrandir> mdz: I disagree; we've a lot of changes which haven't been pushed back well enough.  We have a bunch of ubuntu-specific packages which should really have been rolled into debian, we're far from up-to-date on merging stuff.
<elmo> Mithrandir: dude, be fair, do we suck compared to everyone else?
<elmo> if not, then the correct terminology is "we could do better"
<elmo> since AFAICS, we are like a bazillion times better than anyone else has even tried to be
<Mithrandir> elmo: ok, we could do better.  We could be as good as the goals we've set for ourselves.
<Mithrandir> and I think we're a fair distance from what we'd end up at.
<ogra> haha http://www.daskeyboard.com/
<jdub> elmo: has that point been made well on the lists?
<mdz> Mithrandir: we have never set a goal of having every patch in the BTS, or having a minimal delta relative to Debian at any given time
<Mithrandir> mdz: we've been going around saying "we give back" and I think we're far from good enough at that.
<mdz> our goal is to contribute back, and we have been and are doing that.  of course everyone would like to do more, but this is a zero-sum game and our resources are limited.
<Kamion> I do think http://www.ubuntulinux.org/ubuntu/relationship implies a bit more than that
<Kamion> and I'm not saying we necessarily have to do more, but perhaps that we should be claiming less
<mdz> yes, that document doe scontain some inaccuracies
<elmo> jdub: I don't know, the  threads make me cry, and I'm certainly not going to get involved
<elmo> (hello oil, meet fire)
<jdub> heh
<Nafallo> hehe
<mdz> that would have been a good thing to raise at the CC meeting yesterday
<mdz> jdub: yes, it has been made, several times, by me.
<Kamion> I wasn't available unfortunately
<tseng> its on the agenda for the next motu meeting
<ogra> yep
<tseng> since we hold the majority of packages
<mdz> tseng: what is?  I'm talking about the document on the website
<ogra> mdz, colaboration
<mdz> that, too, is a much broader issue than MOTU
<mdz> that's a decision to be taken by Ubuntu as a whole
<tseng> mdz: the initial issue I started posing was what to do with NEW motu packages not in Debian
<mdz> Mithrandir: if you feel that more work should be done, why don't you spend your own time doing the work?  the problem with this whole attitude is that everyone expects someone else to pay for it.
<tseng> but yes, the issue in general affects everyone.
<elmo> yay, syncs work better when the mirror your sync from isn't 2 days out of date
<jdthood> I don't agree with the complainers.  Ubuntu patches are freely available.  Any Debian maintainer who cares can backport the relevant portions of those patches; then the patches will be smaller when ubuntu does the next sync.
* Kamion *is* spending some of his own time (i.e. not work time) doing the work
<Mithrandir> mdz: I try to make all my packages have the exact same source in ubuntu and Debian, even when doing stuff such as the python transition.  I, like everybody else, have a limited amount of time available, but I try to do my part at least.
<mdz> everyone is doing a part, and the response is "fuck you, not enough"
<dilinger> Mithrandir: i wouldn't mind seeing a team with debian dedicated to pulling back changes from the various derived distributions
<dilinger> s/with/within/
<Mithrandir> dilinger: hmm, that's an interesting thought.
<tseng> dilinger: indeed
<Mithrandir> mdz: the whole is bigger than the sum of all the parts.
<tseng> dilinger: we've got a few dds in motu wondering how they can help out
<Mithrandir> but, I gotta go, shower and then pub.
<tseng> maybe that could be something to pose to them.
<Kamion> anyway, speaking of non-work time, I need to go shopping
<Mithrandir> tseng: can you take that forward with them?  I think it's an excellent idea.
<Nafallo> Mithrandir: have fun! :-)
<tseng> Mithrandir: sure ill push people that way if they keep popping up
<dilinger> tseng: when's the next motu meeting?  i'd like to sit in on that discussion
<tseng> its not that often but they do show up at times
<tseng> dilinger: second.
<tseng> we've talked about it impromptu on irc a few times and your idea is the best thats come up so far
<tseng> also elmo gave us a "canonical" list of merges
<tseng> 206 conflicts atm
<jdthood> What would such a "pulling back" team do?  Take patches from ubuntu's site, edit them down and mail them to the Debian BTS?
<tseng> which is resolvable at this point
<tseng> jdthood: maybe work one-on-one with the maintainer?
<tseng> is how I do it for my own stuff
<tseng> dilinger: "Our next MOTU Meeting is scheduled for Monday, 20 June, 2200 UTC."
<ogra> dilinger, 20th
<tseng> http://www.ubuntulinux.org/wiki/MOTUMeeting/view?searchterm=motu%20meeting
<robertj> ooh xconfinfo is pretty interesting
<snow> hello - one question guys. i try to inst 5.10 but the f. machine (intel) says its not able to mount a filesys ext2 (or ext3) on /dev/ide/host0/bus0/target0/lun0/disc1 - i have tried lots of things
<ogra> robertj, but bad bad xml :)
<tseng> Kamion: do you know if that amd64/libxss issue from beagle was resolved?
<robertj> ogra: looks well formed to me
<snow> and "stat of the device /dev/ide/host0/bus0/target0/lun0/disc1 failed
<snow> please help
<ogra> robertj, but wrapping the data linewise is silly.... 
<ogra> robertj, the next client should do better
<chol> snow, 5.10 is in development, try 5.04 and see if it works better for u
<ogra> (wrapping == wrapping in xml)
<robertj> ogra: I don't see what you mean
<robertj> do you mean xloginfo?
<ogra> robertj, err, yes...
<robertj> oh yes, that sucks, but xconfinfo looks neat
<ogra> robertj, that should be a big chunk of CDATA
<snow> chol, 5.04 works fine - i tried to play arond a little bit on 5.10 - just bug reporting and so on
<snow> and it says, the device apparently does not exist - bullshit!
<chol> snow, but you've confirmed that the device file is there, fdisk reports that partition and if you make another fs on that partition, does that work?
<dilinger> jdthood: i was thinking more in terms of a larger context; not only pulling in patches from ubuntu, but others as well.  the easy tasks would be pulling in bugfixes and such; however, they could also determine desired features/reworkings that would be beneficial for debian to pull in, and work w/ the derived distribution maintainers and debian maintainers to get it complete
<dilinger> tseng: thanks
<dilinger> jbailey: the initramfs stuff you've been working on, have you managed to get netboot/pxeboot working w/ it?
<jbailey> dilinger: I'm not setup to test that config.  What's special about it?
<snow> chol, fdisk reports the disk - what means another fs?
<chol> snow, another file system
<dilinger> jbailey: just curious.  i'm not sure how pxeboot and friends handle initrds (if they do at all); however, if the equivalent initramfs image could simply be appended to the kernel image..
<dilinger> jbailey: a coworker and i were just discussing ways around system disk failures; with netbooting that sort of thing, we wouldn't have to rely on system disks at all (we already use openafs for important data and home directories)
<Lathiat> pxeboot with syslinux does initrd
<Lathiat> pxelinux/syslinux, whatever it is
<jbailey> dilinger: I wonder if you can pxeboot a usable grub2?
<dilinger> Lathiat: ah.  what about other architectures?
<Lathiat> dilinger: nfi
<jbailey> dilinger: That will eventually include bits that you need for loading things off of nfs and http, apparently.
* dilinger nods
<snow> chol, creating ne fs worked fine
<chol> snow, thats nice
<chol> snow, i think both you and I are looking for a channel somewhere between user and developer :)
<snow> shit
<\sh> pitti: ping
<Nafallo> \sh: no pitti here ;-)
<\sh> seems so...anyone knows about postgresql-*?
<ska-fan> \sh: what do you need to know?
<\sh> ska-fan: postgresql-dev right now is a showstopper...:( 
<ska-fan> I'm not sure if I can help you. I know stuff about postgresql, and nothing about debian packaging.
<\sh> ska-fan: nono.it has to do with packages :)
<ogra> \sh, why dont you just ask ? 
<ogra> probably someone knows...
<mpt> hi ogra
<ogra> hey mpt...
<mpt> ogra, I assume you've seen the thread in ubuntu-devel about laptop testing and possible integration with the hwdb client?
<ogra> mpt, i didnt plan to have the word user on the button....so dont worry, its just a mockup....
<ogra> mpt, yeps
<mpt> good good :-) ... just checking
<mpt> hmmm
<ogra> it will take time to implement.... jwz (the original coder) doesnt like the logo to be changed... so its hard to implement....
<mpt> heh
<ska-fan> Hmm, can such things like when you have this mother board and this soundcard, you need to turn off acpi be incorporated?
<mpt> Obfuscated?
<ogra> he implemented the pixmap headerfile....
<\sh> ogra: as I said: showstopper...dep problems
<ogra> s/implemented/reimplemented
<\sh> libpqxx
<ogra> \sh, ah
<mpt> ogra: You mean something like #define LOGO "ridiculouslylongbinarydata"?
<ogra> heh, if it would be this easy... nope... 
<ogra> the complete xpm library....
<ogra> i.e. the functions
<ogra> and he is right to do that security wise... but renaming every bit is not nice :)
<ogra> mpt, what says the usability expert to this nice device *g* ? http://www.daskeyboard.com/
<Treenaks> ogra: let the Ubuntu "persuasion" team pay him a visit ;)
<mpt> that's the blank one, isn't it
<ogra> yep
<mpt> ogra: Slashdot tells me what to think, therefore it's an overpriced copy of one I could get elsewhere, and not a good idea anyway if you plan to be typing any "~" or "\" characters :-)
<tseng> ogra: thats cool
<ogra> Treenaks, lets see... as i see it someone once should fork this code, someone who is open to secure changes that can integrate with desktop environments safely...
<Burgundavia> mpt, ogra I can do the same by scrapping the letter off my keyboard
<mpt> ogra: What happened to gnome-screensaver?
<ogra> Burgundavia, have the keys on your keyboard different springs...
<ska-fan> \sh: so pg-dev depends on libpqxx which doesn't build?
<Burgundavia> ogra, oh, that
<ogra> mpt, its insecure ... you cant implement it this way
<\sh> ska-fan: no..libpqxx depends on postgresql-dev :)
<ogra> Burgundavia, i think thats the intresting part ...
<Burgundavia> ogra, yes, but not worth the cost
<ogra> mpt, but if i find the time, i'll implement the settings in gconf keys.... its not more insecure then using a hidden file in your home....
<ogra> and integrates with the desktop
<ogra> but accessibility issues will remain in this interface for a long time.... there is no safe way to solve them
<tseng> ogra: are you getting one?
* mpt wonders how Windows and OS X handle that problem
<mpt> ogra: I find the xscreensaver preferences quite confusing, too, though that's probably just a labelling problem
<ogra> mpt, i'd love to rip them apart ... especially since tey have redundant settings with gnome-power now....
<\sh> ogra: thx for the warped fix upload :)
<ogra> the power powermanagement should happen completely in the powermanager ....
<ogra> \sh, it was a one liner....
<mpt> ogra: breezy? or breezy+1? :-)
<ogra> heh... too much power in the above sentence
<ogra> mpt, breezy
<mpt> MORE POWER
<ogra> mpt, gnome-power will be our frontend to all the powermanagement stuff, xscreensaver has a own powermanagement, i'd like to integrate it where it belongs, so the screensaver preferences will have a big gap and should get a bit of redesign
<Nafallo> ogra: sounds very sane indeed :-).
<ogra> Nafallo, yes, but a good bunch of extra work....
<ogra> but given that the screensave is the worst integrated thing we have, probably worth the time....
<Nafallo> :-)
<mpt> ogra: Unfortunately, it *does* make sense for the screensaver choice to be next to the screensaver delay, and for the screensaver delay to be next to the screen blanking delay, and for the screen blanking delay to be next to the standby/suspend/whatever delay, and for the standby/suspend/whatever delay to be next to the other power settings
<ogra> mpt, you mean a xscreensaverandpowermanagementinterface *g* ?
<mpt> :-/
<Nafallo> hehe
<mpt> They're a continuum -- it makes little sense for screensaver choice to be in the same panel as battery status display, but each of those steps makes sense
<ogra> yep
<mpt> OSes I've seen differ in where they draw the line, but it ends up being quite awkward
<mpt> I think Windows and OS X both have a button to take you from one to the other
<mpt> So, it'll be a fun design challenge :-)
<ogra> mpt, www.grawert.net/pm1.png 
<ogra> mpt, www.grawert.net/pm2.png 
<ogra> thats gnome-power
<tseng> thats alot of widgets
<ogra> yeps
<Nafallo> ogra: does the settings do anything yet? :-)
<ogra> the first one looks ok to me... but i still have no idea about the second one
<ogra> Nafallo, nope
<ogra> Nafallo, they need integration with pmi
<mpt> ogra: For the second one you can make it simpler by making arbitrary decisions and sending people to gconf if they want to twiddle
<Nafallo> ogra: and the panel I guess :-)
<Burgundavia> I think that "critically low battery icon" has no use case for not having it displayed
<mpt> ogra: e.g. battery is critical when below 5 minutes
<ogra> Nafallo, thats pmi :)
<Nafallo> ogra: hehe, oki.
<Burgundavia> and users don't need to set the critical limit
<Burgundavia> some sane default should be chosen for that
<mpt> Burgundavia: read up :-)
<ogra> mpt, or how many percent ? i like to adjust it to 1% .... to be able to work as long as possible
<ogra> Burgundavia, its cool for keyboardy and mice
<mpt> ogra: Percent means nothing, because power usage varies. Minutes are the useful unit.
<ogra> keyboards even
<ogra> mpt, all laptops i have dont report minutes
<Burgundavia> ogra, the UI is not clear that it affects keyboards and mice, and there is still no use case
<ogra> they only show percentage.... (which is the fallback if te bios doesnt report that)
<mpt> ogra: They don't need to, you can calculate it by taking constant measurements :-)
<ogra> mpt, that means reimplementing gnome-power :) thats to much....
<mpt> E.g. if the battery left has dropped from 25% to 20% in the past 10 minutes, you know you've got 20 minutes left
<mpt> fie
<mpt> ok
<ogra> mpt, at least for breezy.... 
<mpt> ok, complain upstream :-)
<mpt> Seriously, asking people to twiddle a percentage is crack.
<ogra> yep
<Burgundavia> mpt, I have already done some work with gnome-power devel upstream regarding user interface
<ogra> it shows the time if time is available....
<Burgundavia> but this one is new to me
<ogra> Burgundavia, thats the cvs version.... 
<mpt> If I take out my old clapped-out battery that only does 2 hours, and put in a new battery that can do four hours, I shouldn't need to twiddle my settings.
<ogra> Burgundavia, just install gnome-power, its in universe
<ogra> mpt, desirable, yes... but thats all stuff to be done in the kernel layer or in hal...
<Burgundavia> ogra, is that the latest cvs?
<ogra> Burgundavia, from last weekend
<ogra> (as the version number says ;) )
<mpt> ogra: userland software can calculate it from the percentage decline. But anyway. You're the wrong person to talk about that with :-)
<mpt> and it's 8am and I really really should get to bed
<ogra> mpt, probably not... i also hack on HAL stuff...
<ogra> heh, yes, you probably should
<Burgundavia> mpt, email sent
<mpt> thanks Burgundavia
<Kamion> chol: if you're still in contact with snow, I fixed his partitioning problem several days ago.
<chol> Kamion, okey, i'll let him know if i see him
<chol> thx
<loo> hi
<loo> I have a little question to ubuntu's  package policy
<jackobill> I'm trying to build gnome from cvs with the instructions here http://www.gnome.org/~newren/tutorials/developing-with-gnome/html/ch04.html#building-instructions
<loo> win 2k3 server sp1 need pam_winbind 3.0.14a, which is in breezy, is it possible that this version comes in hoary?
<jackobill> when I try to use jhbuild bootstrap it says that the command is not found
<Amaranth> jackobill: you need to add ~/bin to $PATH
<jackobill> how?
<Amaranth> or cd to ~/bin and run ./jhbuild bootstrap
<Amaranth> export PATH="$PATH:~/bin"
<jackobill> ok
<ogra> jackobill, why do you do that ?
<ogra> breezy has the cvs packages from seb128 may correct me, last weekend ? 
<jackobill> well to build gnome from cvs to be able to do some programming and compiling with the programs from HEAD<
<jackobill> yeah but I have no idea how to keep my hoary and install breezy on the same system that as also a windows xp
<seb128> use jhbuild if you want to keep an hoary and hack on GNOME on a different dir
<jackobill> if you can explain me how to, I'd like pretty much to test breezy and work with it
<jackobill> k
<Amaranth> ogra: it has 2.11.3 things, yeah
<ogra> Amaranth, yep
<jackobill> but is there any way to keep hoary and windows on a box and to add breezy?
<Amaranth> does jhbuild pull GTK+ from CVS?
<ogra> Amaranth, but i rely on seb128's word  :)
<Amaranth> that would be a reason to use it, to test out the cairo goodness
<seb128> jackobill: use a partition for it
<seb128> Amaranth: you can use jhbuild for that right
<jackobill> seb128 : ok... can you give me an example of how to partition everything? do I keep the same /home?
<seb128> there is zillions of ways
<seb128> you can have a common /home if you want
<jackobill> k
<seb128> a way is:
<seb128> /dev/hda1 windows
<seb128> /dev/hda2 linux1
<seb128> /dev/hda3 linux2
<seb128> /dev/hda5 home
<seb128> and make a swap, like /dev/hda6
<jackobill> is there a program in ubuntu to see the current partitions
<xhaker> sudo fdisk -l
<ogra> jackobill, gparted
<xhaker> nice one too ogra, but if he has a messed up partition table he won't see anything
<elmo> Kamion: are there any udeb only source packages you're aware of off hand?
<ogra> xhaker, might be... but we want to include gparted, so i'm happy about every tester ;)
<Burgundavia> ogra, got a nice bug for you, haven't filed it yet, for gparted
<ogra> Burgundavia, go ahead :)
<Burgundavia> ogra, the thing is, I think the bug was caused by something else, not gparted
<jackobill> I got this : /dev/hdb3   (system)  Extended , what extended means?
<ogra> Burgundavia, sad...
<Burgundavia> basically it created a screwed up partition table on a sata drive
<ogra> jackobill, there are other partitions inside....
<xhaker> an extended partition is like a container Burgundavia 
<Burgundavia> xhaker, huh?
<jackobill> can I show you my partitions scheme and then you could give me advice on how to install breezy with this?
<ogra> Burgundavia, curretly i'm only aware that it breaks sd cards...
<Burgundavia> ogra, well, once I get on the machine again (my brothers), I will report it in a more useful manner
<xhaker> Burgundavia, an extended partition is a host partition for other partitions...
<ogra> Burgundavia, great, thanks
<Burgundavia> xhaker, yes, but I wonder why you are telling me
<xhaker> ohh, right.. i should be directing this to jackobill 
<Burgundavia> xhaker, it is ok, I was a little confused, that is all
<jackobill> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
<jackobill> See `config.log' for more details.
<jackobill> *** error during stage configure of pkg-config: could not configure package *** [8/10] 
<jackobill> how can I get this working?
<jackobill> forget this
<thesaltydog> is there any goodwill mate who can spend 10 min. on this page and edit/review contents? http://www.ubuntu.com/wiki/InitScriptHumanDescriptions
<\sh> thesaltydog: KDE == KDE and not Kde ;)
<\sh> PPP is also wrong..u need it also for DSL...as a sub of pppoe
<\sh> samba: Share files among computers on a LAN ... difficult..nfs is doing the same
<\sh> i would say: MS netbios shares ;)
<Nafallo> \sh: how many know about netbios? ;-)
<Nafallo> \sh: users that is.
<seb128> calc: around?
<\sh> ok..MS shares
<\sh> xorg-common: Main Graphical Interface
<\sh> is a nono
<\sh> it's the same when u say: X is a Windows alike System 
<Nafallo> anacron?
<KaiL_> any WLAN experts? I have some very strange ipw2100, which doesn't want to enable it's txpower
<\sh> also a question...vixie-cron do the same ;)
<Nafallo> \sh: but anacron doesn't do that?
<\sh> Nafallo: not only
<Nafallo> anacron runs stuff cron misses to run :-)
<\sh> my anacron does also something else
<\sh> i think the first sentence in anacron(8) says all: "Anacron can be used to execute commands periodically, with a frequency specified in days."
<Nafallo> drop "Internet " from inetd :-)
<Nafallo> \sh: ahh, then it's days then ;)
<\sh> hdparm: is not only for hard disks
<\sh> Nafallo: anacron doesn't assume that your computer is running 24h
<Nafallo> \sh: yepp
<ogra> acpi-support isnt tied to laptops, it also manages power events e.g. the powerbutton etc
<\sh> it's nasty btw.
<Nafallo> networking is for networking, not only internet :-)
<\sh> makedev
<\sh> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<\sh> <body>Creates special files to interact with hardware</body>
<ogra> alsa initscripts are something a user shouldnt be able to restart from a gui
<\sh> not true.../dev/null is not hardware
<\sh>  /dev/tty* is mostly not hardware
<jcole>  /dev/urandom
<ogra> \sh, and makedev isnt really used in the face of udev....
<\sh> apache: webserver ... hmmm...apache2: second generation webserver
<\sh> what is lighthttpd then?
<\sh> mdadm: manages multiple disk devices for fault-tolerant...
<Nafallo> ssh: allows encrypted shell-access :-)
<Nafallo> you might even use it on localhost if you like ;-)
<ogra> and also file transfers and remote X sessions :)
<\sh> rsync is quite nice for local file syncs as well :)
<\sh> and remote file execution
<\sh> and light tunnel software
<Nafallo> ssh: allows encrypted access :-)
<Nafallo> webmin is better as it where IMHO
<Nafallo> same goes for xorg-common
<Nafallo> hmm, thesaltydog timed out a while ago ;-)
<ogra> hmm, i doubt xorg-common does anything usefull if you run it with restart or stop....
<\sh> ok...time to sleep more then 4 hours a night
<\sh> trying to sleep 5
<Nafallo> :-)
<Nafallo> \sh: g'night :-)
<\sh> last cigarette
<\sh> before I'm falling apart
* mvo goes to bed now
<\sh> I will be happy when this transition is over..
<Burgundavia> ok, this idea is cool --> http://www.ubuntuforums.org/showthread.php?t=40322
<\sh> "Redmund Artistic Recycling Project (RARP)" lol
<\sh> off to bed
<Kamion> elmo: loads - main-menu, anna, kbd-chooser, partman*, partconf, rescue, debian-installer-utils, {grub,lilo,yaboot,...}-installer, prebaseconfig come to mind immediately
<elmo> kamion: doh, okay, thanks
<Kamion> elmo: (curious?)
<elmo> nah, trying to work out if I need to bother generating Packages files for all the udeb components for breezy-{auto,}test
<elmo> the way they work with apt-ftparchive makes them a pain/repetitve in the config file
<elmo> (if I don't generate them and there are udeb only source pakcages, the buildd will never know they've been compiled)
#ubuntu-devel 2005-06-16
<Riddell> seb128: how is Debian planning on handling the menu issue?
<seb128> installing to /etc/gnome
<Riddell> seb128: so ignoring /etc/xdg altogether?
<seb128> and setting XDG_CONFIG_DIRS from gnome-session
<Riddell> doesn't seem very elegant
<seb128> why ?
<seb128> renaming is not a good option
<Riddell> that's true
<seb128> you need to patch every single app usings the menus
<seb128> XDG_CONFIG_DIRS is documented by the spec and doesn't break the compatibility with any piece of code
<seb128> and the standard /etc/xdg/menus/applications.menu will be the Debian menu
<seb128> so you can pick the Debian menu or the desktop one 
<Riddell> ah hah
<Amaranth> *boggle*
<seb128> what?
<Amaranth> /etc/gnome?
<seb128> using /etc/xdg/gnome or /etc/gnome/xdg is the same no ?
* Amaranth pesters the xdg list harder to come up with a solution
<seb128> that doesn't matter
<seb128> XDG_CONFIG_DIRS is a spec point
<seb128> and can point to any folder, doesn't make a difference
<Amaranth> yeah, but smeg is not going to work on debian
<seb128> why ?
<Amaranth> because they have the same name but are in different locations
<seb128> it doesn't respect XDG_CONFIG_DIRS ?
<Amaranth> they all get dumped in XDG_CONFIG_HOME/menus/
<Amaranth> all the user .menu files, i mean
<seb128> and ?
<Amaranth> /etc/gnome/xdg/applications.menu and /etc/kde/xdg/applications.menu
<Amaranth> both would be $XDG_CONFIG_HOME/menus/applications.menu
<Amaranth> well, the real paths, but yeah
<Amaranth> i left out menus/
<seb128> I don't get the issue
<seb128> you edit the GNOME menu with smeg
<Amaranth> they overwrite each other
<seb128> what happens?
<Amaranth> on debian ~/.config/menus/applications.menu would be created
<Amaranth> you edit the KDE menu with smeg, on debian ~/.config/menus/applications.menu would be created
<seb128> bah, you are just saying that for an user, custom launcher are defined for both menus?
<seb128> seems all right to me
<Amaranth> no, i'm saying if they edit a GNOME menu then edit a KDE one the GNOME one gets wiped out
<seb128> why ?
<Amaranth> ...
<Amaranth> because they both will get saved as ~/.config/menus/applications.menu
<Amaranth> actually, it'll be worse than wiping it out
<seb128> oh, right, that's the full menu
<seb128> not only the changes
<Amaranth> it'll basically dump the two together in weird ways
<Amaranth> no, it's the changed
<Amaranth> err, changes
<seb128> is that the changes to merge?
<Amaranth> yes
<seb128> or the menu?
<seb128> if that's the changes, that's fine
<seb128> they can be merge with the current desktop menu
<seb128> no?
<Amaranth> actually, smeg will probably just end up with the debian menu at /etc/xdg/menus/applications.menu and users will bitch at me
<Amaranth> no
<Amaranth> if they edit the GNOME one then edit the KDE one you'll get the KDE's one changes dumped into the GNOME menu
<seb128> "dumped"?
<seb128> you create a launcher for "emacs" by example
* Amaranth starts over
<seb128> it's listed as a new item for editor
<seb128> both GNOME and KDE menus will list it, no ?
<Amaranth> that's not what i'm talking about
<Amaranth> /etc/gnome/xdg/menus/applications.menu and /etc/kde/xdg/menus/applications.menu
<Amaranth> both of these will be ~/.config/menus/applications.menu for the user changes
<seb128> right
<Amaranth> if you edit the GNOME menus with smeg this file gets created with <MergeFile> pointing to the gnome one and has changes to the gnome menu
<Amaranth> if you then edit the kde menus with smeg this file gets editted and KDE changes added to it
<seb128> kright
<Amaranth> but <MergeFile> still points to the gnome one
<Amaranth> and it will then have KDE and GNOME stuff in it
<seb128> changing the .menu names is not good neither since it means to patch every app using them
<Amaranth> this solution is worse
<mdz> seb128: what do you think is the best way to handle https://bugzilla.ubuntu.com/show_bug.cgi?id=7150 ?
<seb128> which one?
<Amaranth> seb128: /etc/gnome/xdg
<mdz> seb128: we need some way to disable the locking at boot time
<Amaranth> having gnome-applications.menu and kde-applications.menu but having applications-merged/ still work for both of them is the best solution, imo
<seb128> mdz: thinking about it
<mdz> seb128: perhaps a gconf key to disable the menu item?
<azeem> if you add gconf keys, you could make it point out the location of XDG_CONFIG_DIRS as well
<seb128> mdz: this key is /apps/panel/global/disable_lock_screen
<seb128> mdz: but the issue is only the menu item?
<seb128> ie, what happen if you close your laptop with the liveCD running, does it get locked?
<seb128> azeem: speaking about what?
<azeem> about the need to set XDG_CONFIG_DIRS as environment variable in gnome-session or so
<azeem> but uhm, I haven't followed the discussion, so you'd better ignore me
<seb128> azeem: the discussion is not about the variable, but the .menu file names
<Amaranth> unless they have a different name they can't live side-by-side even if they are in different directories, due to the way the whole system works
<Amaranth> actually...
<Amaranth> if gnome-session sets $XDG_CONFIG_HOME too it just might work
<seb128> discussion about it with Debian guy on #gnome-debian
<seb128> that starts to be ugly
<seb128> depending on environment variables is not really robust
<Amaranth> the only other real option is having different names then
<seb128> <Np239> the case of the user using both KDE and GNOME, and wanting different menus in both, is almost unsolvable
<seb128> <Np239> are there *really* such users?
<seb128> he has a point too
<Amaranth> sure, but it's better to find a solution than just say it'll never happen
<mdz> seb128: I can fix the lid problem by modifying the configuration file
<mdz> seb128: the menu item is the only issue
<tseng> Amaranth: why find a solution if there isnt a problem, though
<seb128> mdz: the menu item has already a key, just set /apps/panel/global/disable_lock_screen
<mdz> seb128: perfect, thanks
<Amaranth> tseng: These files don't just go away when you stop using GNOME or whatever.
<seb128> mdz: "gconftool-2 -s /apps/panel/global/disable_lock_screen true"
<mdz> seb128: my next issue is that for LTSP I need to force xscreensaver to only blank (no graphics hacks)
<seb128> with a "-t bool" 
<Amaranth> tseng: If you've been using GNOME for a couple months and editting menus with smeg then decide you'd rather be a KDE user things will be broken.
<Amaranth> If you try to use smeg with KDE, I mean.
<seb128> that will learn you to no go away from GNOME :p
<tseng> :D
<Nafallo> hehe
<Amaranth> seb128: What if they were a KDE user for a couple months and edited their menus with smeg then decided to switch to GNOME?
<Amaranth> Once again, broken.
<seb128> make a special case to smeg to make this one working :)
<Amaranth> really broken, actually
<Amaranth> because the menus will use ~/.config/menus/applications.menu and it merges the KDE one
<Amaranth> so your GNOME menus are KDE menus
<Amaranth> and the /etc/gnome/xdg/menus/applications.menu is completely ignored
<Nafallo> hmm, router reboot, bbl.
<Amaranth> seb128: I'm not adding any more hacks to work around broken implementations.
<Amaranth> just set $XDG_CONFIG_HOME to ~/.config/gnome/ or ~/.config/kde/ and all is fixed
<seb128> bah
<tseng> Amaranth: er so what happenes to openbox and monodevelop in the same session
<tseng> do i get ~/.config/gnome/openbox/rc.xml ?
<seb128> Amaranth: atm Mandriva uses XDG_CONFIG_DIRS
<Amaranth> not unless you're using gnome-session
<tseng> well I am
<tseng> and I use both those apps which use the XDG standard
<tseng> please dont break them.
<Amaranth> tseng: Ok, so the _only_ solutions are gnome-*.menu, kde-*.menu or just using the same menu in all DEs.
<seb128> do they use applications.menu ?
<tseng> no
<seb128> does rename it to gnome-applications.menu break them ?
<tseng> but he wants to set the whole directoy to something else than where my configs already are
<Amaranth> tseng: I don't want to. I'm trying to figure out how to fix the problems Debian is trying to cause me.
<tseng> heh
<seb128> Debian is not trying to cause any problem to you
<mdz> ogra: are you around?
<srbaker> hrm
<srbaker> i want update-manager to give me the changelog entry.
<srbaker> looks like i might ahve some hacking to do
<tseng> thats what the bottom panel is for
<tseng> ie the Changes tab
<Amaranth> sure, but that's always empty
<tseng> because its never on the server
<tseng> its not a matter of adding any code to the client.
<mdke> hey Amaranth did you hear smeg is in gentoo portage
<Amaranth> mdke: yeah, the author of pyxdg is a gentoo dev, he did it
<mdke> awesome
<mdke> i'm gonna try it
<Nafallo> *sigh* someone has broken usb-storage :-P
<daniels_> Nafallo: pong
<Nafallo> daniels: ahh, I asked fabbione before. it's solved :-)
<tseng> daniels: dbus?
<daniels> tseng: *cough*
* tseng *COUGH*
<jsgotangco> morning everyone
<tseng> hi
<jdub> mdz: ping
<mdz> jdub: pong
<jdub> mdz: so, php4-mysql -> doesn't pass security review?
<mdz> I know of no reason why it can't be in main
<mdz> I think infinity based php4-universe on what happened to be in universe at the time
<jdub> right
<jdub> that's a pretty crucial package, really should be in main
<mdz> and it's been in universe since warty
<mdz> yeah, it should be
<mdz> all the best php4 crapware uses it
<daniels> right
<jdub> definitely can't diddle with main/universe in hoary? :)
<mdz> no, not in hoary
<daniels> if mysql's in main, php4-mysql should be so too
<jsgotangco> i agree
<daniels> the only reason it was in universe was for b-ds, not security
<blueyed> will breezy have php5 packages?
<mdz> jdub: since you're timezone compatible, can you relay that to infinity?
<mdz> blueyed: yes
<jdub> mdz: ok
<jdub> mdz: now is actually a very good time though
<mdz> jdub: yeah, and so of course I'm on my way out
<wasabi> X in breezy fixed?
* wasabi installs anyways.
<fabbione> morning
<wasabi> interesting. there is no breezy pbuilder script for my ppc box.
<wasabi> n/m!
<bob2> so, just how terribly gross is supermount and submount?
<Lathiat> last check supermount worked but was a bit 'wrong'
<stuNNed> hi
<stuNNed> i stopped getting mail from the -devel list, is it down or?
<Amaranth> it could just be quiet
<Keybuk> meh
<Keybuk> so now, the version of dpkg I build in sid chroot is uninstallable on hoary
<Keybuk> and the version I build on hoary is uninstallable on sid
<Keybuk> ...sometimes I see Ian's point :p
<schweeb> Keybuk: hey, at least sarge is out, so they can start making some more drastic changes
<schweeb> not that it'll change much of anything
<Keybuk> actually, sarge released with libc6 2.3.2.ds1-22
<Keybuk> hoary only had 2.3.2.ds1-20ubuntu13
<Keybuk> and there's a shlibs difference in there
<Keybuk> so stuff built on sarge won't install on hoary \o/
<schweeb> nice
<Keybuk> and firefox is busted :-/
<Keybuk> nothing to do with shlibs, hoary or sargfe
<Keybuk> just it's busted
<daniels> if it crashes all the time, try disabling greasemonkey
<Keybuk> wasn't that, just some random XUL corruption
<Keybuk> download manager won't work, password manager, etc
<daniels> oh, right
<daniels> yeah, that's definitely firefox
<Keybuk> I blame thom
<Amaranth> daniels: thanks, maybe that'll help
<Amaranth> i don't even use greasemonkey
<Amaranth> but it's installed and firefox dies randomly
<daniels> if I go to theage.com.au and middle-click four links with greasemonkey enabled, it'll crash
<daniels> sometimes on the first, sometimes it takes all four
<daniels> but I can open as many as I like without it, and it's fine
* Amaranth just installed session saver
<Amaranth> even if firefox goes down more than <insert dirty joke> i just reopen it and keep working
<Lathiat> heh
<Lathiat> i like that in epiphany
<Lathiat> comes free :)
<daniels> i did the same, but it's still annoying
<Keybuk> well, purging firefox and my config, and reinstalling fixed it
<tepsipakki> hmm, the kernel update-notifier probably shouldn't alarm the user if the running kernel version has not been updated, but another
<tepsipakki> ?
<mdz> tepsipakki: it shouldn't alarm them, but it should notify them that they should reboot in order to update their kernel
<tepsipakki> that's what i meant
<tepsipakki> ok, maybe a normal user doesn't have more than one kernel version at a time..
<fabbione> mdz: we don't have much choise in that respect without a lot of hackery in kernel postinst
<fabbione> mdz: probably the easiest is to make a better notification message..
<tepsipakki> fabbione: what I actually meant was that if I have two different kernel versions installed (in this case 2.6.10/2.6.12) and the one that is not running got updated, I still am told to reboot ;)
<tepsipakki> minor thing though
<fabbione> tepsipakki: yes i understood the problem. 
<fabbione> and the issue is that to compare the running kernel with the one in upgrade phase is a lot of hackery 
<fabbione> so my suggestion is to change the notification message to be more clear
<tepsipakki> isn't that already done at least if you make a kernel of your own with kernel-package?
<tepsipakki> I mean, it warns if you are updating a running kernel
<tepsipakki> or at least it used to in debian
<fabbione> partially yes
<Zomb> tepsipakki: I cannot remeber any signle time where this message has helped me in any way. Never.
<Zomb> s,single,case,
<tepsipakki> zomb: you mean the warning and the "do you _really_ want to continue updating" -message?
<fabbione> we did shut that off
<Zomb> tepsipakki: yes, that one. Makes as much sense as saying "you are crossing the road on green, are you really really really really ... sure, it has been green when you arrived, ..."
<fabbione> we only really yell and scream if you are trying to remove the running kernel
<tepsipakki> zomb: yeah, true ;)
<tepsipakki> the more I think of it, the more I'm ok with the current way it works, because when a normal user updates the distro the kernel either gets critical updates or a totally new version that replaces the old one..
<tepsipakki> so it really doesn't matter much if the breezers see that message a few times more
<tepsipakki> (breezer = a wacko running breezy)
<tepsipakki> (like me)
* daniels kicks automake int eh nuts.
<Lathiat> daniels: so, moving X to autotools was a good idea right? :)
<infinity> daniels, jdub, mdz : Part of the ServerTeam spec for Breezy was to get all the supportable PHP extensions re-seeded to main.
<daniels> Lathiat: i think so
<Lathiat> daniels: :)
<daniels> libx11's compile is completely stuffed though
<Lathiat> daniels: does X in breezy "work" yet?
<daniels> Lathiat: sudo ln -s /usr/bin/mkfontscale /usr/X11R6/bin/mkfontscale, and yes
<Lathiat> daniels: do all these symlinks break future upgrades? :)
<daniels> Lathiat: not this one, no
<daniels> well, the best solution, actually
<daniels> edit /usr/bin/mkfontdir, change /usr/X11R6/bin to /usr/bin
<mdz> and then run it on all the fontdirs
<mdz> depending on when you upgraded, possibly
<Lathiat> i think i'll just wait a little more :)
<bob2> is it just me or is podcasting stupidly overhyped?
<\sh> podcasting is stupidly overhyped
<Lathiat> indeed
<bob2> it's just rss with urls to mp3/vorbis files, right?
<Lathiat> nah no vorbis
<Lathiat> cus ipod doesnt play it
<Lathiat> it doesnt exist!
<Lathiat> i do th esame thign for amateur internet tv shows
<Lathiat> its not like its amazing :)
<bob2> is there any relationship at all to "ipods" or did someone just go "ipod...casting, AWESOME.  oh wait, we'll get sued.  PODCASTING!"
<Treenaks> bob2: no relation to ipods, other than a piece of software that /downloads/ the mp3 and puts in on your ipod
<Treenaks> bob2: for macos
<Treenaks> bob2: so, yes, I'd say it's massively over-hyped
<bob2> hah
<mpt> Roughly, podcasting is to audio files as shell scripts are to Unix
<Treenaks> mpt: isn't it more like "audio blogging" (like "photo blogging") ?
<mpt> Treenaks: That's a subset. Radio stations also use it, and radio stations don't regard themselves as Weblogs.
<Treenaks> mpt: true, but they tend to use it for on-demand re-streaming of programs
<koke> mvo: around?
<koke> mvo: look at http://www.w3.org/RDF/Validator/ARPServlet.tmp/servlet_153904.png
<koke> mvo: or http://www.w3.org/RDF/Validator/ , validate http://www.amedias.org/~koke/gaim.appinstall , graph only
<koke> if there's any RDF guru in the room, help is welcome
<mvo> koke: looking now
<pitti> elmo: please sync libpg-perl and php4-pgsql from Sid
<pitti> seb128: pin
<pitti> g
<Amaranth> mpt: as shell scripts are to Unix? there are too many of them that suck but when you find a good one you cherish it? :)
<seb128> pitti: pong
<seb128> pitti: got my mail?
<mpt> Amaranth: No, as in they're an automation mechanism
<Amaranth> seb128: are you doing the /etc/gnome/xdg move? i noticed you reverted the name change
<seb128> Amaranth: please join #gnome-debian on irc.gnome.org
<mvo> koke: looks good so far
<fabbione> does anybody remember how to print all the items after a certain item in awk?
<fabbione> like: foo bar baz tla
<fabbione> i want awk to print only all the entries AFTER bar (known as $2)
<sladen> normally I'd just use 'cut'
<fabbione> sladen: cut is not the best with whitespaces
<fabbione> specially when you don't know what kind of whitespace can be in the file
<fabbione> and how many
<Kamion> I tend to use tr first to sort out the whitespace
<Kamion> e.g. tr -s '\t' ' '
<Kamion> actually probably tr -s ' ' '\t' to avoid having to use cut -d
<fabbione> hmm ok
<sladen> fabbione: what you appear to be doing is  sed -e 's/^(.*[ \t] *)//'  ?
<sladen> or [^ \t] +[ \t] +
<fabbione> sladen: basically i need parse a file similar to fstab
<fabbione> where i have the first entry as a device, the second entry as a name and the rest are options
<fabbione> but i want to grab all the options in one shot
<fabbione> to pass the export command
<pitti> fabbione: echo "hallo foo bar baz" | perl -ne '@a = split; print "@a[2..100] \n"'
<infinity> fabbione : echo " foo bar baz tla" | awk '{n=3; while(n <= NF) {print $n; n++}}'
<Kamion> you could use perl's autosplit if you're going to do that
<pitti> right
<Kamion> 
<Kamion> er
* fabbione scratches his head :)
<Kamion> echo "hallo foo bar baz" | perl -alne 'print "@F[2..100] "'
<fabbione> ok thanks :)
<Kamion> or 2..$#F, better
<Kamion> enough now? :)
* infinity prefers awk's startup time to perl's...
<fabbione> way too muc h:)
<pitti> fabbione: C, use getpwent() (just to spam you a little further :-) )
<fabbione> pitti: ehehe
<fabbione> infinity: your solution is almost right :) except that print in awk adds \n
<fabbione> for now the winner is....
<fabbione> Kamion!
<Kamion> aha
<Kamion> pitti: I thought we'd agreed not to apply pkgstriptranslations to dpkg - or do I misremember?
<Kamion> # dpkg -L dpkg | grep usr/share/locale
<Kamion> # 
<pitti> Kamion: hmm, odd, I asked lamont to blacklist it...
<pitti> Kamion: I check that again with him
<Kamion> infinity: do you know about the translations blacklist stuff?
<pitti> infinity: ^ /etc/pkgstriptranslations.conf on the buildds
<pitti> Kamion: Hoary is alright at least, that's only breezy
<Kamion> right, I should've said, yeah
<infinity> pitti : Will fix in a few.  Thanks.
<Kamion> elmo: please sync dpkg from experimental
<elmo> kamion: is it going to BREAK THE WORLD(tm)? :p
<pitti> maybe dpkg should be synced after fixing the pkgstriptranslations blacklist?
<mdke> Simira, around?
<Simira> mdke: yup
<seb128> pitti: going to update the languagepacks?
<mdke> that was quick
<Kamion> elmo: includes our previous changes; it does change DEB_*_GNU_CPU to i486, which doko asked for I think
<mdke> Simira, how is your shop going?
<pitti> seb128: still no go from Rosetta...
<seb128> pitti: grumpf, k
<pitti> seb128: however, for breezy I can crank up my scripts gain
<pitti> agian, even
<Kamion> elmo: I think anything liable to be broken by that will already have been broken by the last BREAK THE WORLD though
<pitti> seb128: it requires some manual work which was probably already done in Rosetta, but shouldn't take more than an hour
<seb128> pitti: would be nice, some app have 0% of translation atm
<pitti> seb128: alright, will schedule it
<seb128> thanks
<Simira> mdke: I've barely started planing it yet. I have no time for it before august, the earliest. And I don't have any idea about how to run a webshop, so I need to look up some things around it.
<pitti> seb128: btw, you uploaded some gnome packages recently? let's see whether the POT extraction worked...
<seb128> pitti: a bunch
<Simira> mdke: I'm ordering a bunch of t-shirts soon, though. Hoping to bring them to Debconf, maybe
<elmo> Kamion: done
<elmo> pitti: done too
<mdke> Simira, ooh, where do you order em?
<seb128> pitti: it should works fine, I got a FTBFS because of a POTFILES.in listing a sourcefile not shipped with the tarball :p
<pitti> elmo: merci
<Simira> mdke: a Norwegian profiler bureau
<seb128> that's sign it runs the pot generation :)
<pitti> neat
<mdke> Simira, oh gotcha
<pitti> seb128: you uploaded gnome-panel, but not gnome-menus?
<pitti> seb128: http://people.ubuntu.com/~pitti/dload-strippedtar.txt
<seb128> I uploaded both a couple of times
<mdke> Simira, ok cool well good luck with it after august anyhow
<infinity> pitti : Should it only be blacklisted in breezy, then?.. Not retroactively in old chroots, I assume.
<pitti> infinity: it should be alright in hoary
<pitti> infinity: can you please copy hoary's blacklist to breezy for now?
<seb128> pitti: lemme try on gnome-menus
<Kamion> elmo: hmm ... how about we make that dpkg from incoming, so that #312383 doesn't annoy us
<mdke> Simira, maybe you can convince someone at canonical to give you a hand
<Kamion> (he says, having done a baz update)
<pitti> seb128: Warning: tarball gnome-menus_2.11.1.1-0ubuntu4_translations.tar.gz does not contain a POT file
<pitti> seb128: ^ is that the latest version?
<seb128> yep
<infinity> pitti : Hoary and breezy have the same blacklist.  Neither lists dpkg.
<pitti> infinity: hum, then this was apparently just good luck.. can you please fix both then?
<seb128> pitti: but gnome-menus has not C files translated
<elmo> grr
<pitti> seb128: btw, the list is not complete (see the error below)
<seb128> pitti: the only translations here are .directory files
<seb128> and 2 .py files
<pitti> seb128: ah, right, so no gettext anyway?
<seb128> it seems to use getting, a sec
<pitti> seb128: oops, I should clean up my overrides
<elmo> Kamion: done
<Kamion> ta
<infinity> pitti : Erm.  /etc/pkgstriptranslations is a conffile belonging to your package.  Why don't you just keep it up to date with the current list, and I can stop making changes to these conffiles altogether? :)
<pitti> infinity: I can do that for my sake; can you please mail me the current version?
<pitti> infinity: since security updates for dpkg are very unlikely, we can probably ignore hoary for now
<jamesh> seb128: I was looking at http://udu.wiki.ubuntu.com/LaunchpadIntegration a bit more, and I thought of one integration point that we didn't cover before: bug-buddy
<seb128> jamesh: what about it ?
<infinity> pitti : Nothing stopping an upload to hoary-updates too, but it's probably a non-issue.
<jamesh> seb128: application crashes -> display bug buddy -> file bug in malone
<infinity> pitti : Anyhow, mailed.
<jamesh> (or some crash dump reporting launchpad component
<pitti> thanks
<seb128> jamesh: there is a spec running about automatic crash reporting too
<pitti> infinity: so the next time the buildds are updated, you need to force the overwriting of the conffile?
<infinity> pitti : If you rewrite it to use a static (non-conffile) list in /usr/share, then I won't have to make sure the conffiles get properly updated. :)
<infinity> pitti : But I will babysit and make sure they all get updated properly anyway, yes.
<tseng> is anyone getting mail from breezy-changes?
<jamesh> seb128: okay.  Is that going to replace bug-buddy?
<pitti> tseng: yes, works
<tseng> pitti: k, i stopped getting sometime last night I think
<seb128> jamesh: that's in discussion ... pitti's find the bug-buddy UI too complicated by example
<tseng> might be all mail :/
<pitti> tseng: hm, I didn't check that thoroughly
<pitti> jamesh: well, the program it self is too big for our purposes, of course we could strip it down (but that would still be a fork)
<pitti> jamesh: for my part I'd prefer a small pygtk app
<jamesh> seb128/pitti: imo, it is good to separate crash dumps from actual bug reports, so it probably shouldn't just dump stuff directly into malone
<pitti> jamesh: right
<seb128> yeah
<pitti> jamesh: we'll keep a separate db
<pitti> jamesh: right now a prototype is at http://debcrash.piware.de
<pitti> jamesh: this actually works already, but of course it's not used so far
<jamesh> pitti: we might want it integrated with launchpad
<infinity> pitti : Just ping me when the new stripstanslations is ready to go, so I can hit all the chroots and make sure things update sanely.
<jamesh> pitti: to associate crash reports with bugs
<pitti> jamesh: at least we should preprocess them and group crashes together by pacakge, version, and function the crash occurred in
<jamesh> pitti: yep.
<jamesh> pitti: have you seen the Microsoft crashdump software, or the mozilla Talkback (again, for Windows) apps?
<pitti> jamesh: no
<jamesh> pitti: The talkback app lets you enter a comment, email address and a URL
<infinity> Epiphany has one too.
<infinity> So, go crash epiphany to see it.
<jamesh> pitti: and lets you see the data it's about to send, and exclude parts you don't want to send
<Amaranth> isn't that what bug-buddy is?
<infinity> (Not hard, there's a bug against firefox with a page that crashes it reproducibly)
<jamesh> Amaranth: bug-buddy is half bug reporting and half crash reporting
<pitti> jamesh: http://people.ubuntu.com/~pitti/crashrep-gui.png <- that's my current prototype; needs much beautification, but it shouldn't be more complicated than that
<Lathiat> infinity: just ptrace it and write some random code over some page :)
<shawarma> infinity: Or kill -11 `pidof epiphany` ? That should also to the trick.
<jamesh> pitti: here's one of Talkback: http://www.czilla.cz/clanky/images/tb-06-talkback-4.png
<Treenaks> jamesh: nice, works in SuSE here as well
<pitti> jamesh: that looks nice. we can hide the details behind a button, but IMHO the user should always see what he reports
<pitti> jamesh: i. e. environment variables and stack traces might contain sensitive information
<jamesh> pitti: here's an official URL: http://www.mozilla.org/quality/qfa.html
<pitti> jamesh: I think the idea of TB and my prototype is the same: a very easy one-step dialog
<jamesh> pitti: the talkback code also sends potentially sensitive data: list of shares you're connected to, list of printers, processes currently running, etc
<pitti> jamesh: bug-buddy has several pages, fetches info from some gnome db, etc, and is too big for us
<jamesh> pitti: it also sends data about how long the process was running before it crashed, number of times you've run the program, system uptime, etc
<pitti> jamesh: good idea, we should add that as well
<jsgotangco> jdub, ping?
<jamesh> pitti: I think it also does total runtime for all runs of a program -- can be useful to guess how bad a crash bug is
<seb128> yeah
<pitti> jamesh: well, I don't think we can add the total number of runs to the report, since we have to modify packages for that
<jamesh> pitti: yeah.
<pitti> jamesh: but we can add the uptime and the process uptime; still, the stack trace is certainly the most interesting piece anyway
* jamesh goes to see if he can crash firefox on a windows box
<pitti> infinity: ah, now I know why we made this a conffile...
<pitti> infinity: the idea was to not enable stripping by default, it should only be enabled manually
<infinity> pitti : So we can do rapid changes, or so it can be turned on/off?
<pitti> infinity: but I think we should externalize the blacklist
<infinity> pitti : cat /etc/default/pkgstripstranslations | grep ^ENABLED
<pitti> infinity: /etc/pkgstriptranslations.blacklist ?
<pitti> infinity: I should also add regexp support while I'm at it
<pitti> infinity: by keeping the blacklist separate, buildd maintenance should be easy, right?
<infinity> pitti : Oh, neat.  It's written in shell.
<infinity> pitti : If the blacklist is sometihng that should always be handled by you, just move it out of /etc entirely.  I only want it as a conffile if there's value in that.
<pitti> infinity: in theory other distros or even users might want to customize it
<pitti> infinity: I think it should be a conffile
<infinity> pitti : Other distros would customise at the source level, so that's a non-issue.  Users, though.  <shrug>.. leave it a conffile, then.
<pitti> infinity: but since we won't touch it at the buildds, that doesn't hurt us
<infinity> pitti : Just move everything to /etc/pkgstriptranslations/{main.cf,blacklist.cf}
<pitti> ok
<infinity> That has the added bonus that the old conffile won't get in your way on this upgrade. ;)
<pitti> infinity: hmm, well, moving conffiles ...
<pitti> infinity: no, I have to handle the move properly...
<infinity> pitti : Is usually a bad and horrible thing.  But, seriously, who is using this package right now other than the buildds?
<pitti> infinity: nobody will use this package in practice, but still
* infinity thinks this is a package that probably should have been in a private repo.
<infinity> Too late for that, I guess.
<pitti> I think having it in the archive for derivatives and people to play with it makes sense
<infinity> I still don't see the harm in hardcoding the blacklist in the source package, though.
<infinity> The only people who really want to change it are distributors, who can customise the package.
<pitti> infinity: well, yes; keeping the original conffile location would save me much unnecessary maintscripts fu
<infinity> But.  Whatever you feel is best.  I don't much care, as long as updating it is easy enough for us.
<infinity> Touching a bunch of chroots is icky and wrong.
<pitti> infinity: if you agree, I just add /etc/pkgstriptranslations.blacklist
<infinity> <shrug>... Okay.
<infinity> And just make sure it's read AFTER the conf file.  SO it can overwrite an old blacklist in the conffile. :)
<pitti> yeah, the old list will be ignored entirely
<infinity> Cool.  Then I officially don't have to do anything.
<infinity> Yay me.
<pitti> infinity: the blacklist will just consist of a bunch of package names or regexps
<infinity> (I'll go clean up the conffiles anyway)
<infinity> I still dislike having a conffile that you KNOW will be modified.
<infinity> That feels broken.
<infinity>  /etc/default/pkgfoo makes more sense if you just want enabled/disabled to be edited without people (usually) touching the rest of the config.
<pitti> infinity: for my sake I'll add a default file
<pitti> *sigh* three conffiles for a simple shell script, but well, I'll do it
<infinity> Well, if you add the /etc/default one, you can not break out the blacklist.
<tseng> Kamion: you said the problem with beagle ftbfs amd64 was libxss-dev doesnt depend on libxss?
<pitti> hm?
<infinity> Since the main conffile will almost never be touched, right?
<pitti> infinity: right
<infinity> (Assuming the only reason people usually touch it, including the buildds, is to enable/disable the package)
<pitti> infinity: so why I can't separate the blacklist then?
<infinity> Oh, you can if you want.  I meant you can (not seperate), not you (can not) seperate.
<pitti> ah :-)
<pitti> you should declare the precedence of your language operators :-)
<infinity> Will do in the future. :)
<Kamion> tseng: yeah
<tseng> Kamion: thanks, ill work around it for now.
<infinity> pitti : Anyhow, whatever you end up doing, just ping me when you upload, so I can make sure it all updates correctly. :)
<pitti> yes, will do; thanks for your input
<infinity> I think I may go buy some ice cream.
<jamesh> pitti: here's the other half of the mozilla talkback stuff: http://talkback.mozilla.org/
<mdke> where is the best place to ask for nautilus help on irc?
<Treenaks> #ubuntu probably ?
<mdke> hmm tried that
<mdke> is there an official nautilus chan?
<seb128> mdke: bugzilla for bugs
<seb128> mdke: there is #nautilus chan on irc.gnome.org but that's not really an user chan
<mdke> seb128, yeah found it
<mdke> thanks
<Lathiat> ss
<jbailey> elmo: Are you able to sync from experimental to breezy?
<pitti> that's possible
<jbailey> Ooo.
<seb128> mdke: it used to work?
<mdke> seb128, what is that?
<jbailey> Does it keep syncing, or do I have to poke for each sync?
<Kamion> jbailey: the latter
<seb128> mdke: you have not opened a bug on nautilus?
<mdke> seb128, yes, just now
<jbailey> Kamion: Thanks.
<seb128> mdke: is that a request for a new feature, or a bug?
<mdke> seb128, new feature
<shawarma> Am I the only one unable to run 'apt-get build-dep evolution-exchange' ?
<seb128> <alex_away> man
<seb128> <alex_away> now i have to close that bug
<seb128> ah ah
<seb128> mdke: <alex_away> we don't generally want hover things
<mdke> well he can close it I guess
<mdke> one of the other guys in there gave me good feedback on the idea
<mdke> seb128, i guess another way of showing the information apart from hover would be equally helpful, like in the bar at the bottom
<elmo> jbailey: yes
<ogra> seb128, ping
<seb128> ?
<ogra> seb128, you got mdz's xscreensaver mail ?
<seb128> yep
<ogra> seb128, what do you think ?
<seb128> I've no clue on this atm
<ogra> seb128, ah, ok....
<seb128> dunno xscreensaver enough
<seb128> I've never played with it
<ogra> seb128, long term there is a bug from jdub i'd like to close and put the settings in gconf....
<ogra> but thats rather breezy+1
<ogra> ok, but if you have no clue, i'll try to sort it myself
<mdke> seb128, i'd like it if you comment on the bug. If it gets closed, no problem
<seb128> I've no comment to make on this
<mdke> ok
<mdke> sorry
<doko> ogra: an option to disable the 3D screensavers would be very nice. the screen can sleep, but not me, because the fan in the powerbook turns on.
<ogra> doko, file a bug ? ;)
* ogra would rather have an option that ebales a preselection of screensaver groups..... one could be "only 2D screensavers"
<ogra> enables
<KaiL_> the only good screensaver is a blank screen
<KaiL_> at least in times of DPMS
<ogra> KaiL_, depends :)
<ogra> KaiL_, i love to read panlet.ubuntu.com on my screensaver :)
<ogra> planet even
<Lathiat> doko: xscreensaver shoud be throttled if you shut the lid
<ogra> even with a 3D font ;)
<Lathiat> i.e. screensavers stop running
<Lathiat> aiui anyway
<ogra> Lathiat, thats an excellent idea.... yo should follow up on dokos bug ;)
<Lathiat> ah
<Lathiat> url?
<ogra> Lathiat, doko ?
<doko> Lathiat: no, that's not the same.
<ogra> doko, it is, if you get a lid on your desktop PC .... ;)
<Lathiat> heh
<Lathiat> just fold your monitor over :)
<ogra> doko, and i really cant resolve your lack of hardware ;-P
<doko> ogra: I can't help that you cannot sleep because the fan on your amd64 notebook is always turned on.
<Treenaks> I see a solution:
<Treenaks> ogra: give him your notebook :)
<doko> otoh, it drains the battery so fast, that it get's quiet without a bugfix
<KaiL_> lol
<ogra> doko, notebook == living room or office room, bed == sleeping room
<KaiL_> or send the Laptop to S3 :)
<ogra> i dont sleep in front of my hardware ;)
<Treenaks> KaiL_: S5
<KaiL_> Treenaks: or that
<KaiL_> at least not S0
<Treenaks> true
<Treenaks> ok.. 8mpix pics can safely be enlarged to 75x50cm posters
<Treenaks> \o/
<KaiL_> ...and if the Laptop doesn't support S3 on Linux, it sucks ;)
<KaiL_> the only box, I've seen, which doesn't want S3 is my desktop - as always
<stuNNed> i stopped getting mail from the list for some odd reason, am i banned? :D
<Amaranth> stuNNed: -devel is just quiet, i think
<tseng> no I think the lists are actually broken
<stuNNed> Amaranth: i checked the archives, there are new messages from yesterday didn't come through..
<tseng> i uploaded many packages since the last ones shown on breezy-changes
<stuNNed> yes as couldn't access the archives like 2 days ago
<Amaranth> stuNNed: iirc if they get 3 bounces from you you're dropped form the list
<lamont> pitti: grep -l  dpkg build-*/chroot-*/etc/pkgstriptranslations.conf produces no output on any buildd
<lamont> (none of which still have hoary chroots, only hoary-{security,updates} and others
<pitti> lamont: yes, we already noticed; I'll fix pkgstriptranslations to maintain a separate black list which I can update by uploads
<lamont> I expect that the true blacklist wants to be the union of what's in pkgstriptranslations.conf, and the builtin list
<danielki> hey
<shawarma> Is there a way to match the Suite:-keyword from the Release file in /etc/apt/preferences ?
<shawarma> And how about the Codename-entry?
<doko> elmo, Kamion: please can you move libgcj-dev from universe to main, build dependency for ecj-bootstrap, db4.3
<ogra> doko, you know the new process for moving to main ? http://www.ubuntulinux.org/wiki/UbuntuMainInclusionQueue
<mdke> jdub, around?
<doko> eek, even for library packages?
<ogra> doko, for reverse dependencys.... pitti has to review them and requires a Report before
<ogra> he mailed -devel about it ;)
<pitti> doko: you can create a report yourself to speed things up :-)
<tseng> infinity: can you please give back beagle?
<doko> ogra, pitti: a report for a symlink. nice.
<pitti> doko: it's *only* the -dev package?
<doko> pitti: yes
<doko> I'll add gnat-4.0 and bison-doc later
<lamont> seb128: what does gdk-pixbuf-query-loaders do?
<lamont> (besides hang on hppa, that is...)
<Treenaks> they load gdk pixbuf queries?
<pitti> doko: hm, alright, fine for me :-)
<lamont> Treenaks: that was my thought, but then I wondered why do they need their queries loaded, and into what?
<Treenaks> lamont: good point
<pitti> elmo: libgcj-dev is empty, adding to main is fine
<infinity> tseng : Sure.
<tseng> infinity: thanks.
<infinity> Is it somehow going to magically be happier now?
<tseng> infinity: yes, i broke gecko-sharp and it wasnt fixed yet when it tried to build beagle
<tseng> i guess the dep-waiter would fix that eventually
<infinity> No.
<infinity> That particular bug just stays as a failure until a real person looks at it.
<tseng> k
<infinity> (Well, currently... I'm going to see about making it even smarter)
<tseng> well building it now should work a bit better.
<infinity> Looks like it's going better, yeah.
<tseng> do you have the lamont workspace?
<infinity> As in, it didn't die in the first 3 seconds with "I can't install anything, cause the world is broken, help!"
<tseng> 30 tiled xterms on buildd shells
<infinity> I don't have the screen resolution to do that, yet.  But i type fast. :)
<infinity> (I'm ordering a new laptop, then I'll do the 7000 xterms thing, just cause it'll make my girlfriend frightened of touching my computer... A great security feature)
<infinity> "Oh my god, what's all that scrolling text, argh!
<tseng> hah
<tseng> you need ogra's keyboard
<tseng> no key labels
<infinity> dvorak?
<tseng> and then make it dvorak.
<ogra> heh
<tseng> thatd show her.
<infinity> I've had no labels, but qwerty still.
<infinity> I can't type on dvorak to save my life.
<tseng> ive not tried it.
<doko> Mithrandir: can you update ia32-libs in breezy? I get a "error creating symbolic link `./usr/lib32/libGL.so.1': No such file or directory
<\sh> infinity: sktream and simage are ok :) please remove sear from the frozenapps 
<ogra> infinity, http://www.daskeyboard.com/
<ogra> If you are an elite programmer who can write sophisticated code under tight deadlines, someone who makes impossible projects possible; or a Silver Web Surfer your colleagues turn to when they need IT advice: this keyboard is for you.
<ogra> hahaha
<pitti> infinity: you should do to save your fingers
<tseng> ogra: as funny as the page is, i think it might be cool to have one.
<spacey> is linux virtual server suppose to work on ubuntu?
<ogra> but $80, just because they saved money on printing ?
<tseng> ogra: the spring thing.
<tseng> might be handy
<ogra> tseng, i'd like to test that first :)
<infinity> ogra : Looks nice.
<tseng> ya.
<infinity> \sh : on it.
<ogra> it sounds very reasonable though
<tseng> the one I really dont get is the happy hacker keybd
<\sh> infinity: thx
<infinity> ogra : I like the text about the key switches and the weight... I do like a good keyboard.  I don't much care if ithas printing or not, though it's a cute "feature".
<ogra> infinity, yes, but i wouldnt buy such a thing without testing.... 
<infinity> Yeah, I'm really picky about keyboards.
<infinity> Also sucks that it's USB only.
<tseng> ps2-usb is a very simple adapter
<tseng> it might even come with one.
<tseng> i have several
<infinity> System Requirements
<infinity>     * DOS, Windows 3.1 or higher. If you still use DOS or Windows 3.1, please send us a postcard screen shot.
<pitti> elmo: please sync postgresql-8.0 from sid
<Lathiat> infinity: haha
<infinity> As for the USB/PS2 thing, does the device not have to be capable of speaking both protocols?... The adapters are just electrical adapters, not logical.
<infinity> (Which is why said adapter will work with, say, an MS IntelliMouse, but not some random BrandX USB mouse)
<Lathiat> infinity: in most cases
<Lathiat> i have heard of some active translators
<tseng> ah there goes the mailing lists
<\sh> infinity: can u remove glcpu as well from the frozenapps...I just try to rebuild it with the new libcommoncpp2 version
<mvo> elmo: can you please sync synaptic from debian incoming? (override ok)
<infinity> tseng : Looks like beagle was much happier this time around.  You win a gold star.
<tseng> infinity: amd64 pass?
<infinity> tseng : Yup.
<tseng> infinity: woo, thanks for the kick.
<ogra> YAYYYYYYYYYYYYYYYYYYYYYYYyyyyyyy
<Treenaks> ogra: ?
<ogra> Treenaks, <tseng> infinity: amd64 pass?
<Treenaks> ogra: ah
<Treenaks> ogra: leet :)
<tseng> Treenaks: E-LITE.
<infinity> \sh : I already unfroze glcpu a day or two ago.  If it's still in my list, I suck. :)
<\sh> infinity: it is ;) 
<infinity> \sh : Is not.
<infinity> :)
<\sh> infinity: u r a cheater ;)
<pitti> infinity: could you please have a look why qt-x11-free 3:3.3.4-1ubuntu6 is not attempted to be built?
<infinity> pitti : Spite.
<infinity> (And an sbuild bug)
<infinity> Let me fix the latter and get back to you.
<pitti> thanks
<pitti> infinity: (and congrats of becoming the "my package doesn't build" pestering guy :-)
<ogra> oh, thats infinity now
<ogra> ?
* ogra goes to look for the list
<pitti> infinity: is it the same bug that keeps pike7.6_7.6.24-1ubuntu4 from being built on anything but amd64?
<\sh> pitti: ha..problems with postgresql-dev .. does it depend on your postgresql-8.0 breaks da world announcement?
<infinity> pitti : Looks like it, yes.
<pitti> \sh: postgresql-dev 7.5.4 just depends on libpq-dev to aid in transition for users, but that won't help to make most packages build again
<pitti> \sh: in particular, packages already using pg_config will even work now, but most packages don't, so they are screwed
<infinity> pitti L And several others.
<pitti> \sh: but I didn't understand your question properly, can you re-explain? (or /msg me in German *hehe)
<\sh> pitti: postgresql-dev doesn't want to install on breezy
<pitti> hm?
<\sh> pitti: so i'll get some errors from pbuilder 
<\sh> (the last try was this morning)
<pitti> whoops
<pitti> \sh: WTH? it only depends on libpq-dev (unversioned) and libpq-dev is installable
* pitti is confused
<pitti> \sh: I mean, it isn't particularly useful anyway, but it should at least work
<infinity> pitti : Yay.  sbuild bug fixed, qt-x11-free blows up spectacularly on configure. :)
<ajmitch> pitti: libpq-dev: Conflicts: postgresql-dev but 7.5.4 is to be installed
<infinity> XRandR support cannot be enabled due to functionality tests!
<infinity>  Turn on verbose messaging (-v) to ./configure to see the final report.
<infinity>  If you believe this message is in error you may use the continue
<infinity>  switch (-continue) to ./configure to continue.
<infinity> make: *** [libqt-stamp]  Error 101
<pitti> infinity: still? *sign*
<pitti> infinity: I added the missign libxrandr b-dep, I hoped that this would fix it
<infinity> *sign* indeed. ;)
<\sh> pitti: moment...i'll try again :)
<infinity> pitti : Can you get it to build locally?
<pitti> ajmitch: ah, right. my bad
<infinity> pitti : Or are you just bouncing random sources off the buildds and praying? :)
<ogra> infinity, all X includes are borked currently....
<infinity> ogra : Sweet.
<ogra> at least randr and xlibs
<ogra> daniels said it should be solved today...
<\sh> -> Considering  postgresql-dev (>= 7.4.6-1)
<\sh>    -> Trying postgresql-dev
<pitti> infinity: I need the lib in the dchroot to test
<\sh>        -> Cannot install postgresql-dev; apt errors follow:
<\sh> Reading package lists... Done
<\sh> Building dependency tree... Done
<\sh> Some packages could not be installed. This may mean that you have
<\sh> requested an impossible situation or if you are using the unstable
<\sh> distribution that some required packages have not yet been created
<\sh> or been moved out of Incoming.
<\sh> The following information may help to resolve the situation:
<pitti> \sh: alright, I know the bug
<\sh> The following packages have unmet dependencies:
<\sh>   postgresql-dev: Depends: libpq-dev but it is not going to be installed
<\sh> and the last breezy update was 5 mins ago
<infinity> \sh : THe bug is known. :)
<\sh> pitti: k
<infinity> \sh : In future, that kind of stuff is a little more appreciated in #flood. :)
* \sh should go home now and he should take a nap...after this horrible day
<infinity> (Or someone could start #ubuntu-flood, if you feel like being gratuitously different)
<pitti> \sh: my original idea was that an already installed p-dev would automatically be replaced by libpq-dev on upgrade, and p-dev removed
<infinity> pitti : pike7.6 seems to be going fine though, so you win 1 out of 2.
<pitti> hehe
<\sh> infinity: sry...:(
<infinity> Parsing "/build/buildd/pike7.6-7.6.24/build/linux-2.6.10-i686/traditional.xml"...
<infinity> Layouting...
<infinity> "Layouting"?
<infinity> In whose world is that a word?
<pitti> infinity: qt is really a daniels-ish thing now, the added b-dep was just a quick try...
<infinity> pitti : Sounds like, yeah.
<\sh> argl...do not put any "ish" in your sentence..until tomorrow
<infinity> I could set it to an arbitrary dep-wait on some random X lib or other >> the current version.
<infinity> You don't hilight on "ish" do you?
<infinity> That would be kinda weirdish.
<ogra> infinity, http://www.ish.de/
<pitti> maybe that's the reason for his backslash?
<ogra> infinity, thats where he works ;)
<infinity> Ahh. :)
<ogra> and i can understand he doesnt like to read it here, i worked there too ;)
<ajmitch> \sh: my condolences, a hard day at work? :)
<\sh> ajmitch: company politics suck
<\sh> ajmitch: and spreading lies suck more
<ajmitch> ouch, yes
<ogra> ajmitch, thats what made me resign :)
<ogra> but \sh has a thicker skin it seems :)
* tseng wonders why the new gnome removes Run
<ajmitch> tseng: menu rearrangement & patching?
<\sh> ogra: u know exactly about whom I'm talking...
<\sh> ogra: i need the money
<tseng> ajmitch: it was removed intentionally
<ogra> probably we finally get a running gnome-launchbox
<tseng> just not sure of the rationale
<infinity> Oh, dear god.
<tseng> because starting a terminal and doing (foo &) is lame
<infinity> That's not the sbuild bug I thought it was, it's a lamont bug.
<tseng> i guess ill just add the panel button
<azeem> tseng: there's still a keyboard shortcut for it I thought?
<tseng> azeem: i could make one
<tseng> azeem: i use a real window manager
<ogra> tseng, alt-f2 should be default 
<tseng> indeed.
<AndyFitz> audit(1118319949.184:0)initialized
<AndyFitz> kernel panic - not syncing : vfs : unable to mount root fs on unknown-block(0,0)
<tseng> AndyFitz: owned.
<AndyFitz> whats the rizzie dizzie ?
<zul> hmmm...
<AndyFitz> tseng,   totally pwned
<ajmitch> AndyFitz: initrd didn't get created right, I guess, boot with the old kernel & renstall the new one?
<AndyFitz> ajmitch,   the old kernels will be there ?  grub isnt showing them
* AndyFitz hopes they are still there
<ogra> AndyFitz, they are not in the menu if you hit ESC at boot ?
<zul> AndyFitz: i just had the same thing happen to me..can you do the following when rebooting next add the following to your boot params ramdisk_size=640000
<zul> somehow the dbg kernel is booting first on the grube
<AndyFitz> zul,  cheers mate
<AndyFitz> ogra,  dunno mate  i'll check on reboot
<zul> ill talk to fabbione when he gets back
<AndyFitz> ajmitch.   thanks for your help too mate
<AndyFitz> brb
<zul> AndyFitz: the non-debug kernels should be lower down on the grub list as well
<pitti> infinity: new pkgstriptranslations uploaded
<pitti> infinity: no action required from your side; however, you may remove the nostrip" option from the conffiles to clean up, if you want
<seb128> pitti: can you read the current comment on #9760 please? 
<seb128> pitti: not sure if that's an alsa issue ...
<infinity> pitti : Spiff.  Thanks.
<pitti> seb128: hm, I'm a bit confused about that bug
<pitti> seb128: the mic is normally muted
<pitti> seb128: otherwise many people would get unexpected feedback loops which should be avoided
<seb128> k, so that's probably his "bug"
<AndyFitz> bugger  ,  same panic error.   the version is  2.6.10-5-386
<zul> oh i thought you were talking about 2.6.12...not sure whats up then previous version should be in grub
<elmo> pitti: WTF?  empty?
<pitti> elmo: well, it only provides a dependency and the usual changelog/copyright stuff, but no interesting stuff
<elmo> pitti: postgres sync done
<elmo> mvo: done
<pitti> thanks
<elmo> libgcj-dev promoted
<mdke> elmo, hi. can you add Mikko Virkkil to the docteam repo, he says he emailed his key to ya
<Treenaks> pitti: can I start fixing/uploading postgresql stuff from universe yet? (and do you have a howto?)
<pitti> Treenaks: sure, I sent one to u-devel
<pitti> Treenaks: main transition is done
<Kamion> mako: you don't need to change the meta-userlinux source package name as well?
<pitti> Treenaks: and Debian folks start to fix packages, too, so it's (hopefully) just a matter of time
<pitti> Treenaks: so if you fix something, please give the maintainer a short ping
<Treenaks> pitti: oh cool
<Nafallo> pitti: should cryptsetup lucsFormat /dev/sda -y segfault or am I doing something wrong? :-)
<Treenaks> Nafallo: luksFormat with a k
<Treenaks> Nafallo: not a c
<pitti> still, it shouldn't segfault
<Treenaks> pitti: good point
<Nafallo> Treenaks: right. typo here, not in the console ;-).
<pitti> Nafallo: can you compile a debug version and get a backtrace?
<Nafallo> pitti: k
<infinity> pitti : When the X stuff gets fixed, remind me to kick QT again.
<pitti> infinity: sure
<mako> Kamion: they won't notice it :)
<elmo> mdke: yes, it only got oked, like a day ago, I'll get to it in a bit
<mdke> elmo, thanks. who ok's em?
<shaya> what's the policy for what libraries on x86-64 get 32bit versions for /lib32 ?
<Kamion> shaya: the ones that are needed for applications we have to ship 32-bit
<Kamion> which is basically OpenOffice.org
<Kamion> pitti: perl's been fixed, in case you didn't notice
<pitti> Kamion: cool, thanks
<pitti> Kamion: will try that soon
<elmo> mdke: I asked enrico, since he's been the one managing the accounts on the svn server so far
<shaya> Kamion: reason I ask is that Sun gave us an opteron box and we installed hoary on it
<shaya> but then when we went to install sunray (32bit app) many libs werent available
<mdke> elmo, ok cool
<mdke> thanks!
<shaya> hacked around it via ar -x of the 32 bit libs
<shaya> but not a good solution
<Kamion> shaya: we know that there isn't a full 32-bit environment. In reality, you're probably better off with a chroot until full multiarch gets implemented.
<shaya> is that a breezy goal?
<shaya> or future?
<Kamion> future I think, ask Mithrandir
<shaya> k, thanks
<Kamion> pitti: just warning so that you can stop working around it. :)
<pitti> Kamion: yeah, I talked with bod about this yesterday, and he had an update in the works; I just didn't see the outcome
<jdub> infinity: rad!
<Nafallo> pitti: you got mail :-)
<pitti> Kamion: rad, perl works :-)
<Kamion> cool
<pitti> Nafallo: thanks; can you generate a stack trace, too, please?
<Nafallo> pitti: i.e. strace? gdb doesn't give anything :-/
<pitti> Nafallo: huh, no stack trace with gdb?
<Nafallo> Program received signal SIGSEGV, Segmentation fault.
<Nafallo> 0x00002aaaaaf455b0 in strlen () from /lib/libc.so.6
<pitti> Nafallo: strace traces system calls, not stacks
<Nafallo> that's all :-/
<pitti> Nafallo: you might need a debugging version
<Nafallo> pitti: I've followed http://www.ubuntulinux.org/wiki/DebuggingProgramCrash :-)
<pitti> Nafallo: apt-get source cryptsetup; cd cryptsetup-*; DEB_BUILD_OPTIONS=nostrip,noopt debuild -us -uc -b
<pitti> Nafallo: then you can sudo gdb on the binary in the built source directory (or install the deb, as you wish)
<pitti> Nafallo: ah, wait
<Nafallo> pitti: cryptsetup needs to have sudo? I might try that first then ;-)
<pitti> Nafallo: is above output just the standard reaction after run? or the output after actually doing "backtrace"?
<pitti> Nafallo: well, it needs it to setup the device mapper, and to access /dev/sda in the first place
<Nafallo> pitti: after run.
<pitti> Nafallo: ah, please do a "backtrace" after it crashed
<Nafallo> pitti: hehe, I should not trust wikis blindly ;-)
<pitti> Nafallo: calling it without sudo and with -y doesn't crash for me (it just prints out some failure messages)
<pitti> Nafallo: point 5 in the wiki describes the bt call
<SquishyWaffle> before I go reporting this would someone mind duplicating it for me?: Open mozilla-thunderbird and select multiple messages, hit reply-all. This crashes the client entirely for me with a strange error message in the console.
<Nafallo> "thread apply" and stuff yes. just typing backtrace worked better :-).
<newz2000> I keep getting an OOPS during install (configuring iptables)
<newz2000> I'm trying to make a kickstart install cd
<newz2000> I've tried all I know (not much) and can't get around it
<newz2000> Any way that you know of to track this down?
<Nafallo> why can't I copy the damn text from the console?
<Nafallo> pitti: mail sent :-)
<Nafallo> irritating that I couldn't copy paste from the console right to evo though...
<Nafallo> pitti: is there a sizelimit that must be meet?
<pitti> Nafallo: no, that should work fine
<newz2000> does this mean anything? http://rafb.net/paste/results/YQ1PlQ51.html
<pitti> Nafallo: i c&p multiple pages of output already
<Nafallo> pitti: hmm, strange.
<Nafallo> pitti: in any case. the device is a 8MB CF-card ;-)
<otavio> Hello folks, I saw some people having same problem I have on Debian using EsounD and ALSA. esd keeps using /dev/dsp and then other applications cannot use it. Some idea how solve it?
<tseng> you can solve it by not using esd
<tseng> or making your other apps play to esd
<pitti> otavio: yes, switch to libesd-alsa0
<otavio> tseng: but then GNOME doesn't play some songs
<otavio> pitti: I'm already using it
<otavio> pitti: that's why i'm asking about it.
<pitti> otavio: then upgrade to libasound2 1.0.9 to get dmix by default
<ogra> otavio, just let your apps use esd too... and this belongs to #ubuntu
<otavio> pitti: I doesn't understand why
<otavio> ogra: not exactly since it's a bug
<pitti> ovavio: it works fine in breezy
<otavio> pitti: I already tried to upgarde and didn't work.
<ogra> otavio, nope
<otavio> pitti: yeah?
<ogra> otavio, its a bug of the app if it doesnt support esd output in hoary....
<pitti> otavio: hm, then dmix does not work for your sound card apparently. Can you please file a bug? (assign it to martin.pitt)
<pitti> otavio: oh, that's hoary?
<pitti> otavio: no bug then, please, that's a known issue
<pitti> otavio: it's fixed in breezy
<ogra> pitti, no, thats debian if i got it right
<pitti> hrm
<otavio> pitti: and what was did to solve it? can you inform me?
<pitti> file a Debian bug then :-)
<otavio> ogra: yes, Debian
<otavio> pitti: I want to try to have it fixed on Debian also
<Nafallo> pitti: segfault on my 64MB usbstick to ;-)
<otavio> pitti: since we can cooperate on it.
<pitti> otavio: I already did: switch to libesd-alsa0, libasound 1.0.9 and best thing is to get rid of esd and replace it with polypaudio (since esd sounds terrible with the new libasound)
<ogra> otavio, for hoary we made sure all supported apps support esd output by default....
<pitti> ^ yes, but that doesn't help Debian
<pitti> for Debian we have to offer a non-esd interface, too
<ogra> nope... but explains his problem .....
<pitti> (same for ubuntu, FWIW)
<otavio> ogra: not exactly since I saw some people having problems with hoary too
<ogra> otavio, not with supported apps ;)
<pitti> otavio: yes, in hoary we used libesd0 which used the oss interface and blocks *everything*
<zyga> :-)
<pitti> ogra: right, but folks might want to use nonsupported ones, too :-) (I want at least)
* zyga used gaim to get on IRC for the first time
<ogra> otavio, i admit, there is a good bunch of apps in universe that might have that bug
<otavio> pitti: thanks a lot 
<pitti> otavio: I think using polypaudio on top of ALSA dmix is a sane solution for now
<otavio> pitti: thanks a lot 
<pitti> otavio: just odd that it doesn't work for you...
<pitti> otavio: btw, I filed an alsa upstream bug recently, and they said that they are interested in hearing about devices where dmix doesn't work out of the box
<otavio> pitti: i think polyaudio doesn't exist on Debian yet
<pitti> ah, bad
<pitti> otavio: well, we tried it in Hoary and it was too buggy, but it should be much better now
<otavio> pitti: but this isn't a big issue since we can add it
<pitti> otavio: esd+dmix = the suck
<pitti> that's the problem
<tseng> does polyp+dmix still have audio sync issues?
<tseng> gst audio is always goofy on esd
<pitti> otavio: right now breezy has gstreamer -> alsa directly, but that's still too unstable
<ogra> heh, tseng your changelogs get famous :)
<ogra> http://lists.ubuntu.com/archives/ubuntu-users/2005-June/038225.html
<tseng> ogra: heh.
<otavio> pitti: so the best solution right now is use polyaudio + alsa?
<pitti> otavio: I think so, yes
<pitti> otavio: that was at least the outcome of the AudioInfrastructure BoF
<pitti> otavio: you still don't get sound for multiple users, but at least you can use esd+alsa in parallel
<pitti> s/esd/polypaudio/
<otavio> pitti: can you point to me where I can find the sources of it?
<pitti> "it" == ?
<ogra> hmm, tseng but he is our best tester ;) http://lists.ubuntu.com/archives/ubuntu-users/2005-June/038227.html
<tseng> i saw that
<otavio> pitti: polyaudio
<otavio> pitti: sorry
<tseng> i think his beagled is broken because he is too bleeding edge
<tseng> i broke the sqlite dllmap
<pitti> ah
<ogra> ah
<pitti> otavio: right now, just from archive.u.c
<otavio> pitti: do you have any problem if I include it on Debian?
<pitti> otavio: however, some upstream guy fixed some bugs in his branch, I will pull and apply them soon
<pitti> otavio: of course now :-)
<tseng> ogra: it can stay broken until I fix it, its breezy, I dont support it :)
<pitti> otavio: not, even
<pitti> otavio: to the contrary
<pitti> otavio: however, what about this:
<ogra> otavio, we appreciate every package that goes back upstream (to debian)
<pitti> otavio: I'll apply the fixes soon and ping you back when I have an updated and tested package?
<ogra> tseng, yep, no objections :)
<otavio> pitti: nice
<pitti> otavio: of course you can already upload the current version, it is not _that_ bad :-)
<otavio> pitti: I'll put it on Debian-BR-CDD for testing in meanwhile
<pitti> otavio: actually, uploading right now is pretty good, so it can pass NEW
<otavio> pitti: nice. I'll look at it
<pitti> otavio: http://archive.ubuntu.com/ubuntu/pool/universe/p/polypaudio/
<daniels> ogra: eh, not all X includes
<tseng> http://packages.ubuntu.com/breezy/sound/polypaudio is easier to use imo
<pitti> Hey daniels, good to meet you :-)
<daniels> ogra: basically, stuff which didn't put -I/usr/X11R6/include and instead just hoped it'd land in the include path somehow is now broken
<ogra> daniels, error: X11/Xlib.h: No such file or directory is a *bit* essential ;)
<daniels> it'll get unbroken later
<tseng> daniels: cough.
<daniels> ogra: -I/usr/X11R6/include, it's the app's fault
<pitti> daniels: could you please take a look at the current qt-x11-free FTBFS? it complains about an xrandr issue; I already added the build-dependency, but that didn't help :-(
<daniels> ogra: but it will get fixed anyway
<daniels> pitti: probably needs -I/usr/X11R6/include
<daniels> will check it out
<pitti> thanks
<ogra> daniels, i trued several variations of -I :) but i'll try again
<ogra> tried even
<tseng> daniels: are you fixing libxss-dev doesnt dep on libxss1?
<daniels> tseng: yeah, all the -devs
<tseng> daniels: thanks :D
<pitti> tseng: indeed, I'm still not used to p.u.c...
<tseng> pitti: its great stuff i send the page to my sponsor to grab sources
<tseng> its all on there now
* pitti -> dinner
<otavio> pitti: thanks a lot
<daniels> gah, I'm way too tired, and autotools has defeated me :(
<daniels> http://www.livejournal.com/users/fooishbar/61082.html in particular, as well as EXTRA_DIST stupidity (it will silently fail to actually put the files in the distdir in some circumstances)
<daniels> xorg tomorr,w
<daniels> sorry about that
<Kamion> daniels: would you mind if I did the xfonts-core fix, then (unless it's already in your queue)? if possible, I'd really like to have a serious go at Colony 2 tomorrow, before I have to move house and have an as-yet-undetermined amount of time when I can't do CD work
<daniels> Kamion: sure, if you need it
<Kamion> ok, thanks
<daniels> no worries
<Kamion> yeah, it bones fresh installs
<daniels> sorry to be blocking; didn't realise you were trying to get it done tomorrow
<daniels> yeah, I can see how that would be a problem if you were doing a colony ;)
<Kamion> s'ok, ADSL stuff has been ... interesting
<daniels> i've spent all frigging day banging my head into banks, travel agents, and autotools
<Kamion> don't know yet whether it'll be up when I move
<daniels> ahr, wot fun
<daniels> colony release over gprs? :)
<Kamion> and it'll only be a megabit rather than 2 as I'd hoped, due to line quality
<Kamion> daniels: is there a baz archive I should be branching or anything?
<daniels> Kamion: not yet, unfortunately.  i've been shit in that regard.
<Kamion> oh, bugger, it's xutils, not xfonts-utils
<Kamion> damnit, that means uploading xorg
<daniels> yeah
<daniels> i'm getting libx11 out now, which is up to 10min on my amd64
<daniels> that'll be the first noticeable chink in the time it takes to compile xorg (well, *really* noticeable; fonts were a fair hit)
<daniels> Kamion: my solution was to ship a local copy of mkfontdir (ship it out of debian/local), that has /usr/bin rather than /usr/X11R6/bin
<Kamion> I might leave it to you then; I don't have disk space handy to compile xorg :(
<daniels> ok
<daniels> any specific time it'd be good to have it done by?
<pitti> seb128: alright, I imported breezy with my langpack scripts, I'm going to build new packs now
<daniels> Kamion: so yeah, any specific time tomorrow?
<daniels> Kamion: i'd like to get to the travel agent asap tomorrow morning, then go to the gym after, so all that probably has me getting home about 3pm, so uploading by about 6?
<daniels> (UTC+10)
<Kamion> daniels: if I had them built by lunchtime my time after I get back from collecting the removal van, that'd be top
<Kamion> so 6 your time sounds good
<daniels> cool, I'll try to stick to that as closely as I can
<Kamion> cheers dude
<daniels> just need to get in in the morning so Thai don't cancel my ticket and leave me holding a $700 cancellation fee and no way to get to Karlsruhe
<daniels> no worries
<Kamion> yeah, that sounds bad
* Kamion recovers 1.8GB from an old build tree inside a chroot
<daniels> mmm, I know how that goes
<daniels> i worked out at one stage I had about 30GB of X build trees from packages alone
<daniels> my ~ expands to fit the available space; it was fitting in 6 once upon a time, then 10, then 25, then 40, then 100, and now it's about 230GB
<Lathiat> ouch
<infinity> Yeah, I have goldfish diskspace usage too.
<infinity> Makes me wonder if perhaps I should just stop buying hard drives.
<daniels> i need to get another couple of 250GB drives soon
<Lathiat> i wish i had that much disk space :)
<infinity> daniels : Also, go to bed.  It's late.
<daniels> infinity: this is true
<daniels> but I'm watching libX11 builds spin around and around
<daniels> i'll go to bed when it passes make distcheck
* daniels 's eyes glaze over watching gcc scroll through the same bit of code.  Again.
<bob2> does ccache help much?
<daniels> hrm
<Lathiat> daniels: did you break your build so it loops...? :)
<bob2> Lathiat: go to bed!
<Lathiat> bob2: workign :(
<pitti> bob2: can I teach "baz replay" to strip off initial directories, like "patch -p1"?
<bob2> pitti: hm, no
<bob2> why would you want to?
<pitti> bob2: I just patched postgresql-8.0.3/debian/rules in postgresql--devel--8.0
<bob2> use case, use case, usecase :-)
<Lathiat> USE="case"
<pitti> bob2: and it would be cooool to replay the patch to postgresql-7.4.8/debian/rules in postgresql--devel--7.4
<bob2> pitti: replay doesn't Just Work?
<pitti> bob2: i. e. "baz replay -p1 branch--patch-foo
<pitti> bob2: nope
<bob2> hm, why?
<Kamion> why does postgresql--devel--7.4 have a postgresql-7.4.8 subdirectory?
<Kamion> that seems pretty pointless
<pitti> bob2: it stumbles over the wrong dirnames
<bob2> pitti: that's odd
<pitti> Kamion: well, that's still from the time when we actually managed other files in the parent directory
<bob2> they should be the same logical file
<bob2> regardless of how it was moved
<Kamion> pitti: I think that's why you're losing
<Kamion> bob2: assuming they actually share history ...
<pitti> bob2: $ baz replay pkg-postgresql-private@lists.alioth.debian.org--2005/postgresql--devel--8.0--patch-86
<pitti> * patching for revision pkg-postgresql-private@lists.alioth.debian.org--2005/postgresql--devel--8.0--patch-86
<pitti> A   {arch}/postgresql/postgresql--devel/postgresql--devel--8.0/pkg-postgresql-private@lists.alioth.debian.org--2005/patch-log/patch-86
<pitti> ?M  postgresql-8.0-8.0.3/debian/changelog
<pitti> ?M  postgresql-8.0-8.0.3/debian/rules
<bob2> Kamion: well, yeah
<pitti> Kamion: no, of course they don't share history, otherwise I could just merge
<bob2> oh
<Kamion> pitti: well then
<pitti> Kamion: that's why I tried replay with a single -patch-N
<Kamion> move those trees to have sensible structures :-)
<pitti> bob2: anyway, it's not a big deal and it doesn't occur very often
<bob2> pitti: baz get-changeset pkg-postgresql-private@lists.alioth.debian.org--2005/postgresql--devel--8.0--patch-86 ,,cset ; baz show-changeset --diffs ,,cset > foo.patch
<pitti> bob2: get-changeset, show-changeset, and good old patch -p1 do the same
<bob2> right
<bob2> yeah, when you don't have history baz kinda curls up in the corner and cries
<daniels> Lathiat: no, I'm just running distcheck.  a lot.
<pitti> bob2: I thought replay could apply patches regardless of history and branching
<Lathiat> daniels: ah
<Lathiat> daniels: ccache?
<bob2> pitti: nah, same applicagtion code as replay
<pitti> bob2: another thing, will show-changeset eventually work with archive/branch arguments in addition to directories?
<pitti> bob2: I often want to look at a patch, but always typing two commands and remove the temporary dir is a bit cumbersome
<bob2> hmm
<bob2> it should, yes
<jdub> http://www.alobbs.com/images/3ubuntu.jpg
<tseng> jdub: wow thanks for the warning.
<jdub> oops
<jdub> sorry :)
<mdz> not worksafe :-)
<\sh> ROTFL
<daniels> no, not even close
<daniels> Lathiat: keep touching CFLAGS et al
<tseng> unless you work for mark, I guess
<bob2> hah
<Lathiat> daniels: ah
<\sh> jdub: blog it :)
<jdub> i've soundered it
<Lathiat> haha
<Lathiat> thats class
* jdub blogs
<\sh> hmm....
<pitti> elmo: FYI, I seeded the NEW language-pack-ug
<Kamion> UG
<Kamion> what an excellent language code
<pitti> Kamion: ever heard of "Uighur"?
* pitti does not even know the earth quadrant this comes from...
<Kamion> no - I just found it in iso_639.tab ...
<pitti> Kamion: nice, there is a language "Umbundu" :-)
<daniels> WHOOHOO!
* daniels looks at libX11-6.2.1.tar.bz2.
<daniels> so, make distcheck took between 9 and 10 minutes to run
<luis_> uighur is from the same neck of the woods as mongolian, IIRC
<daniels> xorg on the same machine takes between 45 and 50 minutes to do its thing
<daniels> do the maths.
<daniels> 'night kids.
<pitti> sleep well, daniels
<jdub> luis_: no necks left in those woods. :)
<Nafallo> daniels: night :-)
<luis_> northwestern china, so I was pretty close
* mvo goes to play hockey now
<\sh> can somebody reach http://sourceforge.net/projects/eric-ide
<ska-fan> need the homepage of eric3?
<ska-fan> \sh: I can reach the sf site
<\sh> hmmmm..
<\sh> now it works..strange..the whole morning and afternoon i couldn't get sf.net
<ska-fan> Ah, bist ja auch deutsch
<pitti> mdz: btw, Kamion and I talked about the CDROM-in-fstab issue; the problem was that a server install doesn't have pmount, and "mount /cdrom" is still a very common idiom
<dholbach> hi
<pitti> mdz: so it's questionable whether we want to break server installations and maybe a bunch of other things (apt-cdrom, for example) just to get rid of CD-ROMs in fstab completely
<pitti> Hi dholbach 
<dholbach> elmo: could you pretty please sync  ncmpc  from unstable?
<dholbach> hi pitti
<Kamion> mdz: the real problem seems to me to be that partman puts the fully resolved device name in fstab, not the /dev/cdrom alias or similar
<Kamion> mdz: so I'll have a look at fixing that
<pitti> mdz: however, we can change e. g. /dev/hdc to /dev/cdrom if it is available, so that this will survive changing the wiring of CD-ROMs
<pitti> right :-)
<Kamion> I can also change to /media/cdrom etc. fairly easily if we can confirm that apt-cdrom will be happy without /cdrom
<dholbach> hi mako, do you know who Andrs Orellana is?
<tseng> (gnome-cups-icon:5798): WARNING **: IPP request failed with status 1030
<tseng> pitti do you know why i get this in my log every few seconds?
<tseng> are we polling something now
<dholbach> hey AndyFitz, you wanted to put some UDU movies online ;-)
<pitti> tseng: did you activate network printing?
<pitti> tseng: erm, LAN printer detection?
<tseng> pitti: not inentionally
<tseng> intentionally.
<pitti> tseng: in g-cups-manager, is the option set in global settings?
<tseng> no
<AndyFitz> dholbach,  hey yes.  that would be rad
<dholbach> :)
<AndyFitz> gotta compress them first
<AndyFitz> and get my kernel working first
<pitti> tseng: then I assume cups just tries to find an IPP server, but doesn't find one
<tseng> pitti: yeah.
<bob2> AndyFitz: htf are you still up?
<tseng> pitti: i guess its the icon, thats running.
<dholbach> hey bob2 :)
<pitti> yeah, gnome-cups-icon
<tseng> yes.
<AndyFitz> bob2:  nah i slept now im awake
<bob2> hah
<bob2> dholbach: oh, I suck, I know, sorry :)
<AndyFitz> audit(1118319949.184:0):initialized
<dholbach> bob2: no... you don't - you like "bernd, das brot", which is advanced coolness - for someone not living in germany :)
<tseng> jdub: youre such a twat
<jdub> :-)
<tseng> :)
<bob2> hahaha
<AndyFitz> jdub,  you're awake tooo ?
<mdz> Kamion, pitti: sounds like a reasonable compromise
<jdub> yes
<jdub> i am having terrible trouble getting back into a sane rhythm
<dholbach> bob2: and you're not the only one :)
<AndyFitz> insanity
<\sh> dholbach: bernd das brot?
<dholbach> \sh: yes
<dholbach> bob2: jblack is a fan of "bern, das brot" too - and you're not the only one lagging behind key-signing wise :)
<\sh> dholbach: u don't talk about this strange tv series?
<tseng> i dont think i signed any keys yet
<tseng> besides the ones i did while still in sydney
<dholbach> \sh: i do: imagine talking to random guys in sydney and you end up talking about "bernd, das brot" in the end...
<tseng> dholbach: was ist bernd?
<\sh> dholbach: oh my.."who is bundescancelor of germany?" "bernd, das brot"
<bob2> dholbach: hehehe
<dholbach> tseng: http://www.bernddasbrot.com/
<bob2> dholbach: we stayed up late watching it in england
<tseng> oh yes I have seen him
* dholbach shakes head in disbelief
<bob2> I just wish it had subtitles
<bob2> he has a website!
<bob2> and a BerndBoard!
<dholbach> hahaha
<tseng> if he is das brot, i wonder what he eats.
<bob2> das boot, maybe?
<bob2> "episodenfuhrer" = "episode list"?
<dholbach> \sh: here you can see, why i like all these guys :)
<dholbach> bob2: yes
<tseng> bob2: mmm, steel
<jdub> tseng: das keine brot
<\sh> well...
<dholbach> he has a wikipedia page as well: http://de.wikipedia.org/wiki/Chili_TV and merchandise
<bob2> MERCHANDISE?
<bob2> oh man
<AndyFitz> kernel panic - not syncing : vfs : unable to mount root fs on unknown - block (0,0)
<\sh> i wonder why "bernd, das brot" is much more known then helmut schroeder, i mean gerd kohl, ey man, gerhard schroeder and helmut kohl ;)
<AndyFitz> bugger me, how did that happen
<bob2> helmut the former porn star is awesome, too
<bob2> but not many people got to listen to Choice Bro Tafe
<\sh> jdub: thx for blogging this nifty picture..right now, i'm thinking about a kde splash with it ;)
<pitti> Dear seb128, I want my Applications menu back
<dholbach> pitti: i still have it
<ogra> dholbach, including the gnome-control-center ? 
<dholbach> yes
<lamont> infinity: ??
* pitti 's Applications menu is empty. zero. null. nada.
<Lathiat> pitti: haha
<Kamion> pitti: I ate it. It was crunchy.
<pitti> *whine*
* pitti goes out to beg for a new one
* dholbach pats Kamion on the back
<lamont> so should we ban CarlFK if he doesn't quit bouncing?
<Lathiat> i think so
<Treenaks> lamont: maybe for a while
<Lathiat> it appeasr to be his fault
* mode/#ubuntu-devel [+o lamont]  by ChanServ
* mode/#ubuntu-devel [+b CarlFK!*@*]  by lamont
* mode/#ubuntu-devel [-o lamont]  by lamont
* lamont notes that /deop and /frop are pretty close, in the keyboard scheme of things
* pitti reboots
<Stargazer> I'm running Ubuntu 5.04 PPC with a G3 Lombard.. Can someone give me some advice as to why playing video (divx, qt etc) produces shimmering white dots all over the screen, and when using KDE there is graphic corruption in the title bars, and viewing jpgs everything appears with a yellow film/filter??
<sladen> Stargazer:  the 'shimmering' is possibly the result of drawing-whilst the DAC is also reading out the image
<sladen> Stargazer: eg.  lack of double-buffering
<lsuactiafner>  just.. /ignore CarlFK all
<Stargazer> Sladen - How is this fixed?
<sladen> Stargazer: daniels maybe to shed some light
<doko> seb128: do you have contact with the cairo maintainer?
<seb128> doko: no
<seb128> why
<seb128> ?
<doko> to sync cairo for libgcj
<seb128> sync cairo where from where?
<seb128> I've updated to 0.5 for ubuntu, Debian has 0.4
<mdz> wasabi: did you see my question yesterday about xerces-j?  if we can get that out of the dependency chain, we're basically done
<mdz> fabbione: so I have discovered further corruption in my filesystem
<mdz> and my RAM tests out OK
<mdz> I need to pull backups to determine approximately when it happened
<mdz> Riddell: please review the anastacia output that elmo provided, seed anything which ought to be seeded, and let me know when we can proceed with demoting the remainder
<dholbach> what was the solution for the "fixed font" problem again?
<ogra> dholbach, setting the right font path
<doko> mdz: currently looking at xerces-java, wasabi is short of time
<mdz> dholbach: there were two, one had to do with the font path, the other with the path in mkfontdir
<jdub> WITNESS THE POWER OF sebuild!
<\sh> jdub: check the planet, dude :) 
<seb128> hey jdub :)
<dholbach> mdz: i changed so many things, i couldn't remember, when i told a friend
<\sh> and why can't I see my links on the planet?
<seb128> jdub: I'm considering package gtk CVS (not for the archive but to put the packages online for people who wants to try it)
<jdub> the top three blog entries on planet ubuntu are about nudity or bottoms
<seb128> jdub: we will not do 10x10 if we keep trying to slow down every single change by fear to break something
<dholbach> jdub: we're getting there :)
<\sh> jdub: no :)
<jdub> seb128: ha ha! :)
<\sh> mine is about kde and love
<desrt> seb128; i finally convinced davyd to take the battstat patch
<seb128> jdub: seriously, is there any reason to be that cautious against gtk?
<seb128> desrt: cool
<desrt> seb128; just a heads up for when gnome-applets breaks next time you try to patch it
<seb128> desrt: I've read the comments on the bug
<desrt> oh.  good :)
<seb128> you guys are going to roll a 2.11.3 ?
<desrt> up to davyd, i guess?
<seb128> right
<seb128> doko: ?
<doko> seb128: !
<seb128> doko: 
<seb128> <doko> to sync cairo for libgcj
<seb128> <seb128> sync cairo where from where?
<seb128> <seb128> I've updated to 0.5 for ubuntu, Debian has 0.4
<seb128> is there any issue with 0.5 ?
<doko> they need to be in sync for a binary compatible libgcj
<seb128> I'm probably to change cairo again soon
* Treenaks ROFLs at jdub-blog
<seb128> GNOME starts using cairo so I'm probably going to update that with GNOME when required
<doko> it's ok if it doesn't change the API, or else we have keep two versions
<seb128> it breaks the API
<seb128> there are breaking it as much as possible now to get it stable soon
<dholbach> why does libgcj want cairo?
<doko> fun, then it looks like we will need two versions
<doko> dholbach: swing?
<dholbach> hmhmmhmh
* dholbach nods slowly
<seb128> doko: what 2 versions?
<doko> 0.5 and the version for which you'll break API compatibility
<seb128> 0.4 and 0.5 which conflicts?
<seb128> versions have to conflict...
<doko> why?
<seb128> because they keep the same soname
<seb128> that's a working branch, no API stability garanty
<seb128> so they don't change the soname when they change the API
<doko> I don't care, I can rename the lib or choose a random soname
<seb128> ugly
<doko> upstream looks more ugly
<seb128> no
<seb128> if you break the API every commit you want to change the soname every time?
<doko> no, but for releases.
<seb128> that's a working branch, that's not mean to be used by stable apps
<dholbach> g*mm for example changes the soname for every api-breaking release in an unstable branch
<seb128> dholbach: ...
<dholbach> seb128: what? :)
<seb128> stop making advertissement for g*mm
<dholbach> i don't :)
<seb128> I don't care of what they do, that's not the discussion
<seb128> :p
<seb128> and g*mm is used and follow GNOME
<jdub> haha
<dholbach> yeah... i talked about the unstable releases
<danielki> hehe
<danielki> the murrayc virus
<dholbach> danielki: want to add some remarks on API stability? :)
<seb128> dholbach: I know but still, nothing to do with the discussion :)
<danielki> dholbach :)
<dholbach> seb128: i wanted to add an example - now stop complaining :)
<seb128> dholbach: I complain because I don't like this "I'm going to fork cairo package with a random soname"
<dholbach> *nod* somebody should bug upstream imho to change it every release
<seb128> let's update cairo on Debian and Ubuntu by following new version
<seb128> dholbach: oh, c'mon
<seb128> DUDE
* pitti sighs at polypaudio
<seb128> they are working to stabilize it soon so they can use it for gtk2.8
<pitti> why oh why all audio stuff is so utterly broken?
<seb128> stop bitching about a 0.4/0.5 version of a lib
<seb128> better to make all the required changes now
<dholbach> seb128: that's cool, but if people want to use it and that's a good thing in the stabilizing process they should try to avoid problems an unchanged soname causes
<dholbach> i'm not saying they shouldnt do changes
<seb128> you are bitching about details for a 0.n version of a lib
<dholbach> and recompiling 2-3 packages that already use the unstable branch doesn't hurt at all
<seb128> go to package something useful rather :)
<dholbach> i merely pointed out, what i'd do
<dholbach> seb128: new gnomecanvasmm is compiling, so i stopped by in the discussion
<pitti> dudes, and you two want to cooperate in the Gnome team? :-)
<seb128> yeah, he has main upload right now, I'm scared
<danielki> heh
<doko> pitti: it's easy, rewrite gnome in C# ;)
<pitti> doko: ah, and mono has The Perfect Sound Driver?
<dholbach> doko: you don't want that :)
<seb128> dholbach: gtkmm 2.6.2
<seb128> dholbach: oh, glibmm 2.7.1, be ready, that will start beeing fun soon
<dholbach> yeah
<ogra> doko, Novell does that after they brought yast in as a control-center replacement ;)
<\sh> can someone explain, why the gpl and openssl license are not compatible? 
<\sh> why is apache license and gpl license not compatible
<\sh> i got it ...:(
<bokko> What are possible alternatives to set for a mount point when doing a virgin ubuntu install?  Other Linux distributions may complain if there is another / mount point it sees on a different partition.
<tseng> a what?
<tseng> linux doesnt know where you are mounting a device until you tell it
<bokko> What else can I use besides / for a mount point for installation?
<tseng> or hal decides for you, in modern times.
<tseng> you can use anything you want
<bokko> well rhfc3 does not like seeing a / mount point on a different partition
<bokko> can I just make something up and mount it there?
<tseng> common for auxillary devices would be /media/foo or /mnt/foo
<tseng> fedora core doesnt know what a / mount point is.. it sees a partition
<bokko> tseng: it saw ubuntu mounted on / when I did the install last time
<bokko> tseng: terminated the install and said fix it
<tseng> oh the installer?
<bokko> tseng: yeah, I was booting from the cd to try and fix grb since the ubuntu grub install ignored freebsd on the first partition
<danielki> well I doubt the problem has anything to do with mount points
<dholbach> seb128: straaange, i packaged gtkmm 2.6.2 a month ago
<bokko> danielki: not entirely, I just was not sure if / was a requisite for any sort of linux install
<danielki> 'cause those aren't stored on the partitions but in fstab
<seb128> dholbach: weird
<danielki> every Unix needs a /
<bokko> danielki:oh ok
<dholbach> seb128: murrayc seems to have released new code with an old release number
<dholbach> seb128: but i'll have another look
<seb128> dholbach: the tarball would have been rejected I think
<dholbach> have a look at ftp://ftp.gnome.org/pub/gnome/sources/gtkmm/2.6/
<dholbach> gtkmm-2.6.2.news  	1 KB  	15.04.2005
<dholbach> gtkmm-2.6.2.tar.gz  	5865 KB  	09.06.2005  	
<seb128> k, so he has overwritten the previous tarball
<seb128> kick him :)
<danielki> murrayc sometimes forgets stuff like this :)
<bokko> Ok here is one other different question, I had ubuntu 5.4 installed and the nick was seend by the hardware browser, but it could not get an ip address from the router.  I modified the dhclient.conf to add a , and interface-mtu line in it as well as disabling ip6. still not ip.  Static assignments to valid ip4 address could not connect to the gateway, andy idea what is wrong?
<dholbach> i see :)
<danielki> no wonder considering the huge number of projects he's usually working on in parallel
<bokko> seend = seen
<tseng> bokko: did you read the topic btw
<dholbach> danielki: i absolutely don't blame him
<danielki> dholbach: usually he realizes it before uploading the tarball, though :)
<jdub> seb128: man, i am going to put a very noisy fascist scream in install-module when someone tries to overwrite a tarball
<dholbach> jdub: do it now! :)
<seb128> jdub: good idea, I thought he would reject the upload or at lest DISPLAY SOMETHING SCARY
<bokko> tseng: yeah, people told me to come here and ask since no one seemed to know the prob in #ubuntu
<tseng> those people should stop suggesting that.
<tseng> we should note that for the new "newbie help squad" team.
<bokko> haha well I am about to wipe ubuntu and just go with rhfc3 and solaris
<bokko> if I can't get the network stuff working
<bokko> dhclient.conf mod and disabling ip6 was wat the forums suggested
<dholbach> bokko: you might try the mailing list ubuntu-users@lists.ubuntu.com
<justin> bokko: most likely another fix that someone came up with after "fixing a similar problem" which isn't similar at all
<bokko> dholbach: oh ok 
<bokko> justin: yeah but it was all I came across when I googled the network problem in 5.4
<bokko> justin: hardware works cause other OS on the same machine can grab from the dhcp and route
<bokko> justin: I'll see what listserv has or just uninstall, fiddled with this thing for 2 days trying to get net working, probably not going to waste any more time on it...thanks for your time
<tseng> hm
<tseng> alt.erotica.ubuntu.networking
<tseng> might have something
<danielki> haha
<dholbach> i guess i'll wait for him to re-release :)
<danielki> yep
<danielki> shall I whack him for you? :)
<seb128> dholbach: waouh, upload to main :)
<dholbach> seb128: you're right... it was my first one!
<dholbach> seb128: first one without training wheels
<seb128> congrats
<dholbach> seb128: WOW, does that feel good!
<seb128> you call me wheel?
<dholbach> seb128: of course not... nobody could re-invent you :)
* dholbach hugs seb128 
<dholbach> danielki: don't worry... he'll manage :)
* seb128 hugs dholbach 
* danielki is touched
<dholbach> and pitti is not here... he couldn't witness gnome love :)
<mvo> group hug?
<dholbach> if somebody would blog this to planet.ubuntu ... ubuntu and its community was even more questionable ;)
<tseng> so i removed every copy of the tomboy pixmap on my system
<tseng> and it still comes up
<tseng> with tintin
<tseng> i wonder if he rolled it into the exe or something in cvs
<tseng> something is evil.
<dholbach> tseng: did you ever hear about audio images, like in  http://www.bastwood.com/aphex.php ?
<dholbach> must be in some .mp3 file :)
<tseng> hm no
<tseng> thats crazy
<dholbach> audio images are the geekiest thing i ever saw
<dholbach> but it'd explain a lot if aphex twin tried to make his songs *look* good ;-)
<seb128> dholbach: \o/ (new upload)
<dholbach> wowoohoo
<dholbach> excellent
<doko> elmo: please could you install on davis/breezy: unixodbc-dev firefox-dev kdelibs4-dev libarts1-dev libqt3-mt-dev libsndfile1-dev epm libdb4.3-dev libdb4.3-java libboost-dev sablotron libsablot0-dev libwpd8-dev
<martink> looks suspiciously like ooo build deps
<elmo> doko: doesn't seem to know about libdb4.3-java, but otherwise done
<doko> ok, then libdb4.2-dev and libdb4.2-java
<dholbach> elmo: could you pretty please sync  ncmpc  from unstable (if you didn't do so already)
<elmo> doko: done
<doko> elmo: thanks
<elmo> dholbach: no
<elmo>  [dpkg-source output:]  dpkg-source: error: file ncmpc_0.11.1.orig.tar.gz has size 273803 instead of expected 273489 
<dholbach> oh nice
<elmo> we have a different orig.tar.gz to Debian
<dholbach> argl
<dholbach> ok
<dholbach> will ask him, what went wrong there
<dholbach> thanks
<doko> elmo: ubuntu-changes-auto is not announced on http://lists.ubuntu.com/mailman/listinfo/
<mdz> doko: fixed
<mdz> doko: any luck with xerces-j?
<elmo> doko: tell jdub
<zyga> pitti: hello
<pitti> Hi zyga 
<zyga> do you know about any portable FILE * style library with customizable streams that can be used without glibc?
<elmo> dholbach: who uploaded that ncmpc?
<Nafallo> pitti: you're aware of luks-tools?
<pitti> zyga: no, sorry
<pitti> Nafallo: erm, no?
<Nafallo> pitti: http://www.flyn.org/projects/luks-tools/index.html
<dholbach> elmo: me, he sent me the adjusted patches - it will unfortunately be only fixed with a new upstream release
<zyga> I ran into portability problems unfortunatly
<elmo> dholbach: it was for 'unstable', didn't have a valid Changed-By and didn't have an 'ubuntu' in the version
<zyga> it seems that my favourite argument vector parser argp is tied to glibc stream implementation
<pitti> Nafallo: neat, thanks :-)
<zyga> and thus it cannot be used in portable code :/
<zyga> (lowest common denominator strikes again)
* Nafallo -> phone
<dholbach> elmo: thank you for telling me... arg - there you see what apt-get.org remnants do with me...
<ska-fan> How do I find out which package has ppmmake? xscreensaver's webcollage needs it.
<dholbach> dlocate or apt-file
<dholbach> or http://packages.ubuntu.com
* Nafallo -> here
<elmo> dear god why is apache-mod-auth-pam in main??
<Nafallo> elmo: you're cleaning? ;-)
<tseng> elmo: i fixed the gtkhtml stuff just for you
<elmo> tseng: cheers
<elmo> DOKO YOU ARE THE SUCK
<tseng> oh man
<ogra> pheew
* mako waves at elmo  and mdz
<mako> (btw: the ubuntu manifesto is going to totally rock)
<mdz> mako: so apparently meta-userlinux is in hoary-updates/universe
<mdz> the binaries don't seem to be there, though
<elmo> can't we just call it screwyouandthetrademarkhorseyourodeinon and be done with it?
<elmo> the binaries have a iiinteresting REJDCT
<mako> listen, if the option is "do insane shit and take it out now to avoid criticism" and "wait until IF someone says anything and then do the above" i say take the later
<elmo> ejected: meta-ul-desktop-base_0.02-1ubuntu2_all.deb: md5sum check failed.
<elmo> Rejected: meta-ul-desktop-base_0.02-1ubuntu2_all.deb: actual file size (3230) does not match size (3218) in .changes
<mako> elmo: 
<mako> ?
<dilinger> mako: is the spectre of Free haunting ubuntu?  is ubuntu planning to throw off the shackles that have bound it to lesser distributions?
<mdz> we shouldn't do a halfassed job of it; if we're going to remove the name from the packages, we should do that
<elmo> mako: that Should Not Happen
<elmo> (tm)
<mdz> the other 12 bytes were for the angels
<elmo> that's just like  crack
<elmo> to be bigger in the .changes
<elmo> the otherway round I can understand/conceive of how it would happen, but err.. 
<elmo> the deb itself is valid too
<mako> userlinux puts the meta in metapackages
<mdz> and the sig on the .changes is valid?
<elmo> mdz: yeah
<mako> or rather, the dyna in metapackages
<mako> dilinger: i read like 5 manifestos this afternoond and then did the outline and intro
<mdz> first I get silent data corruption on my desktop
<mdz> and now this
<mdz> maybe we're all pwned
<mdz> or maybe there's increased sunspot activity
#ubuntu-devel 2005-06-17
<elmo> yeah, that's the first thing I'd do if I hax0red ubuntu
<mako> go for the userlinux metapackages
<elmo> break the buildds in ways designed to send the archive maintainers mad
<ogra> heh
<elmo> dpkg-gencontrol: warning: unknown information field  in input data in package's section of control info file
<mako> mdz: in terms of the trademark stuff, i did show them these packages
<elmo> lots of that in the log
<mdz> is there a copy of the upload still on the buildd?
<mako> elmo: hmm.. i didn't get that on my end
<mako> if it got rejected, does that put us in a better position to just scrap it and do the new version?
<mako> although, ideally, not one that generates polymorphic packages
<elmo> wtf
<elmo> it's the right size on the buildd
* elmo goes insane
<Mithrandir> somebody collected the network traffic tax by eating a few bytes off the file?
<elmo> Mithrandir: it got BIGGER
<lsuactiafner> elmo : it evolved
<Mithrandir> elmo: hm, perhaps it ate something?
<lsuactiafner> soon it will turn into AI
<mako> elmo: wait.. it got bigger, then got smaller again?
<lsuactiafner> its pulsating..
<ogra> it pumps
<lsuactiafner> rofl
<elmo> mako: no, as the .deb 3218 on the buildd host and 3230 on ftp-master
<elmo> in the changes, it's 3218 both on the buildd host and on ftp-master
<mako> elmo: so it fucked up in the xfer
<mako> and the changes file didn;'t
<mako> i understand that this is not supposed to happen
<elmo> dude, it's still a valid deb
<elmo> it "fucked up" in a way that add 12 bytes but didn't validate the deb structure
<lsuactiafner>  483B/s 9h21m11s
<mako> is there a binary diff you can do?
<lsuactiafner> yay 
<Mithrandir> elmo: appended some random garbage, perhaps.
<elmo> Mithrandir: no
<mako> expanded the description :)
<mako> (it was garbage to begin with)
<mako> (bruce wrote it)
<elmo> -rw-r--r--  1 katie katie 1239 Jun  9 23:18 control.tar.gz
<elmo> -rw-r--r--  1 katie katie 1797 Jun  9 23:18 data.tar.gz
<Mithrandir> elmo: no?  Then there's something _really_ crackful going on. :-)  You're sure you transferred the correct deb and not a random other one?
<elmo> -rw-r--r--  1 katie katie 1238 Jun  9 23:17 control.tar.gz
<elmo> -rw-r--r--  1 katie katie 1788 Jun  9 23:17 data.tar.gz
<elmo> first bad, second good
<elmo> Mithrandir: dude, there's nothing human involved, this is a buildd upload
<elmo> hum, unless two buildds built and uploaded it simultaneously
<elmo> nope
<Mithrandir> the time stamps are different too.
<elmo> -Installed-Size: 32
<elmo> +Installed-Size: 8
<elmo> -9bb926ca7e0982a70876137021ec65c3  usr/share/doc/meta-ul-desktop-base/copyright
<elmo>  e606acc617f0fae635914b9223296e84  usr/share/doc/meta-ul-desktop-base/changelog.Debian.gz
<elmo> +9bb926ca7e0982a70876137021ec65c3  usr/share/doc/meta-ul-desktop-base/copyright
<elmo> this is SERIOUSLY FRYING MY BRAIN
<Mithrandir> it's not fabio's buildd or something which built it too?  perhaps check the upload logs to see which host transferred the files?
<elmo> oh, gar, I get it now
* elmo beats mako
<elmo> this is all your fault
<mako> sorry dude!
<Diablo-D3> hey all
<mako> i'm sure it is!
<elmo> ok, so here's what happened.
<Diablo-D3> silly question, does ubuntu actually include manpages for libc anywhere?
<Diablo-D3> they arent in glibc-doc
<Mithrandir> Diablo-D3: yes, manpages-dev
* mako gets embarassed in advance
<elmo> mako uploaded a source+binary upload a while ago, but it wasn't signed by a key katie knew
<mako> ahhhhhhh
<Diablo-D3> wow
<elmo> so katie threw away the upload, but didn't trust the .changes and so couldn't know to remove the binary debs he'd uploaded
<Diablo-D3> what an oddly named package
<mako> ahhhhh
<elmo> a buildd comes along and uploads a valid .changes for the binaries
<elmo> the .changes gets copied in, the other files don't
<Diablo-D3> thanks
<mako> same package, so same filename
<elmo> katie rejects the combination of buildd .changes + mako's .debs
<elmo> so, err anyway, after all that interesting distraction, what was the conclusion?
<elmo> chuck out meta-userlinux and reupload as meta-ul or not?
<Mithrandir> ah, makes sense then
<mako> (sorry)
<mako> elmo: so, what do you want to do now
<mako> elmo: since it rejected the binaries, it's not actually in hoary-updates, right?
<elmo> the source is
<elmo> but that's ok, it's no biggy to ditch it
<mako> elmo: yeah, if it's a not a biggy, mdz would prefer it and i don't care much either way
<mako> elmo: the second package is already NEW
<elmo> okay, done
<elmo> and processed
<mako> and, not prone to the whole, yeah
<mako> elmo: thanks
<mako> jdub: HEY
<mako> MORE TROUBLE THAN THESE PACKAGES WERE EVER WORTH
<mako> but i'm gonna make up for it with this manifesto
<mako> man.. causing unexplainable archive maintance script errors.. i feel like lamont
<luis_> mako: oh, man
<luis_> mako: I got an email from the author of the hacker manifesto
<mako> luis_: mckenzie wark?
<luis_> he apparently found my blog entry about it
<luis_> mako: yeah
<luis_> though apparently he goes by 'ken'
<mako> hah
<eruin> I've got an issue with users-manager. It's no biggy, really, other than that it doesn't seem to accept non- a-z content for users full names. Should I submit a bug on this?
<lamont__> mako: all my archive maintenenc script error-induction has been explainable...
<lamont__> "don't do that lamont"
<eruin> ie, I'd really like to spell my name ivind instead of Oivind
* luis_ is trying to figure out how to respond to him while tactfully shitting all over his 'command' of the language
<mako> luis_: did i "recommend" that book to you?
<mdz> dh_gencontrol -i
<mdz> couldn't open log `/var/log/dpkg.log': Permission denied
<mdz> wtf is that about?
<elmo> it's a bug, should have been fixed in -7 ?
<elmo>    * Reduced inability to open a log file to a warning, suppressed for
<elmo>      non-root operations.  Closes: #312383.
<elmo> ^-- guessing from that
<mako> luis_: i can't imagine i would have.. i didn't like it at all
<mako> luis_: if you haven't, read moglen's dotcommunist.. it's fucking *awesome* and made better by the fact that probablh 1/4-1/3 of the language is lifted, directly, from the communist manifesto
<luis_> mako: no, no one recommended it to me
<luis_> he emailed it to a friend of mine who does computer poetry
<luis_> which popped it into my head
<luis_> so I read it
<luis_> i've read eben's, of course
<luis_> what kind of an eben fanboy would I be if I hadn't?
<luis_> :)
<luis_> mako: http://www.beardofbees.com/gnoetry.html <- warkus sent a digital copy to these guys; it turned into pretty good commie/hacker poetry
<LikesHisLunch> Hello, does anyone know why the openoffice-evolution package doesn't work in Hoary? (my experiences are reminiscent of this thread: http://www.ubuntuforums.org/showthread.php?t=31267&highlight=mail+merge)
<doko> mdz: I currently cannot see, why libxerces-java is needed as a b-d for libxml-commons-resolver1.1-java at all, so it should be safe to drop this as a build dependency.
<mdz> doko: sounds good to me
<doko> libxml-commons-resolver1.1-java can be built by gcj-4.0, so we can drop kaffe there as well.
<doko> the fixes that I did for junit and libant1.6-java are wrong. I have to understand why /usr/share/ant1.6 and /usr/share/ant have to be both directories and wasabi wanted to replace one of them with a symlink
<doko> but that's a topic for tomorrow ... a bit too late now
<dholbach> good night everybody - sleep tight
<mdz> doko: ok, I would very much like to move all of the java stuff for ant into main tomorrow if possible
<mdz> there is a huge amount of desynchronization between the archive and the seeds right now because of it
<doko> I know, looking forward for a buildable OOo as well ...
* lamont_r heads out
<mdke> evening corey
<tseng> whiprush: im stealing your package (evolution-sharp)
<tseng> whiprush: k?
<whiprush> uhh, I don't have any packages
<tseng>    * Upload for Jorge, upgraded to 0.6.
<tseng> wrong jorge
<whiprush> heh
<whiprush> you must have me confused with a real developer. :p
<tseng> well since its not yours, i cant just ruthlessly clobber it
<whiprush> heh
<whiprush> koke is the other jorge btw.
<tseng> i see whos it is now
<tseng> i was sure you were working on it at some point
<whiprush> I recall trying and giving up
<mdke> check out the logo similarities between ubuntu and msn http://www.salvatore-aranzulla.com/?p=132
<HrdwrBoB> mdke: obviously it's a conspiracy
* mdke nods
<tseng> anyone seen koke lately
<mdz> keeeeyybuuuuuuuk
<whiprush> any networkmagic people awake?
<Nafallo> mdz: I'm not sure he highlights that ;-)
<mdz> he's not here anyway
<mdz> he's broken dpkg again and then gone to sleep
<Nafallo> wee! luck! :-)
<Nafallo> whiprush: thom's not here either :-)
<Amaranth> jdub: that blog entry should have NSFW in the title :P
<tseng> Amaranth: yeah, after you turn on line-by-line scrolling
<tseng> that might help
<Amaranth> clearlooks 0.6 is out :)
<tseng> Amaranth: way to read gnoemfiles
<Amaranth> tseng: actually the author told me last night
<tseng> :)
<Amaranth> i've been giving him input on the changes and such
<ficusplanet> jdub, I noticed that you guys are using serpentine for audio burning in breezy.  What would you think of integrating it with muine and rhythmbox (calling serpentine /tmp/burnplaylist.m3u or some such)?  It would be a really simple muine plugin. 
<tseng> ficusplanet: snorp did a nautilus-burn plugin.
<tseng> ficusplanet: you could talk to him?
<ficusplanet> tseng, OK, thanks.
<tseng> he is in #muine and all over the place
<ficusplanet> tseng, cool
<Riddell> mdz: all the packages from kde that are listed are fine to be demoted except kwalletmanager which I've added to seeds and kubuntu-desktop
<mdz>  o kdat, kdeadmin, kdeadmin-doc-html, kpackage, ksysv, lilo-config, secpolicy{kdeadmin}
<mdz>  o kdebase-doc-html, xfonts-konsole                                  {kdebase}
<mdz>  o kcoloredit, kdegraphics, kdegraphics-dev, kdegraphics-doc-html, kdvi, kfax, kgamma, kghostview, kiconedit, kmrml, kolourpaint, kpovmodeler, kruler, kuickshow, kview, kviewshell, libkscan-dev{kdegraphics}
<mdz>  o akode-mpeg, kaboodle, kdemultimedia, kdemultimedia-doc-html, libarts1-audiofile, libarts1-xine{kdemultimedia}
<mdz>  o dcoprss, kdenetwork, kdenetwork-doc-html, kdict, kget, knewsticker, ksirc, ktalkd, librss1, librss1-dev, lisa{kdenetwork}
<mdz>  o kandy, kdepim, kdepim-doc, kdepim-doc-html, kdepim-kfile-plugins, kitchensync, kleopatra, kmailcvt, knode, kode, konsolekalendar, korn, ktnef, libkgantt0, libkgantt0-dev, libkleopatra0-dev, libkpimexchange1-dev, libksieve0-dev, libmimelib1-dev, networkstatus{kdepim}
<mdz>  o kcharselect, kdelirc, kdessh, kdeutils, kdeutils-dev, kdeutils-doc-html, kdf, kedit, kfloppy, kgpg, khexedit, kjots, kregexpeditor, ksim, ktimer{kdeutils}
<mdz> all of that?
<Riddell> mdz: yep
<mdz> done
<Riddell> thanks
<lamont> elmo still around, or did he get sensible and go to sleep?
<helix> jdub: from now on, PLEASE WARN US WHEN SOMETHING IN YOUR BLOG IS NOT SAFE FOR WORK!
<tseng> ROFLCOPTER!!!ONE
<jdub> tseng: ha ha
* Nafallo night alla
<whiprush> jdub: got time for some fridge talk?
<jsgotangco> hello whiprush 
<whiprush> hey jsgotangco 
<jdub> whiprush: sho'!
<jdub> whiprush: meanwhile, i am going to finish that email TODAY!!
<jsgotangco> heh
<jdub> TODAY!
<whiprush> heh
<jdub> i am even going to tie myself to the chair
<whiprush> anyword on some prototype site?
<jdub> in such a way that will deny me the ability to untie it myself
<jdub> yeah, site is still there
<whiprush> well, I mean one not hosted at some dude's house, heh.
<jdub> no, we have stuff to sort out before going more live
<whiprush> k
<mdz> jdub: that blog entry of yours certainly has made the rounds
<jdub> but you're welcome to abuse it as much as you (singular) want
<whiprush> also, I updated the spec a bit if you want to check it out.
<jdub> mdz: neat :)
<jdub> cringely doesn't have an rss feed
<jdub> that's so bad
<mdz> that's a feature
<jdub> whiprush: cool
<jdub> (just read the diff0
<whiprush> rock
<ogra> mdz, sane code would use commandline options to override user config, xscreensaver doesnt....
<bob2> hehe
<ogra> mdz, could we let ltsp depend on xlockmore ? xlock -dpmsstandby 0 -mode blank  will do the trick
<ogra> (xlockmore is in universe)
<jnc> wtf...
* jnc pokes ubuntu breezy
<jsgotangco> nice intro
<jnc> when Evolution is open, no applications will launch
<jnc> i close Evo, other stuff launches fine
<jnc> i have like 300mb ram + free
<jnc> what else could it be?
<jnc> jsgotangco: gnome-terminal cannot possibly require 301mb ram to launch
<jnc> could it?
<jnc> maybe i'm out of ptys
<jnc> or something
<AndyFitz> was there a hoary kernel update yesterday ?.  if so it was satan
<jnc> AndyFitz: haha.  what's it do to you
<AndyFitz> jnc,  it raped me man.
<jnc> thems molestin' words
<AndyFitz> i guess thats the wrong word..  yeah i was about to correct myself and say molestered 
<jnc> no love for the kernel update?
* jnc prods breezy some more
<AndyFitz> kernel panic - note syncing : vfs : unable to mound root fs on unknown - block(0,0)
<jnc> ew
<jnc> sometimes you feel like a nut?
<jnc> and... sometimes you dont
* jnc giggles heiniously
<AndyFitz> and i dont have any backup kernels.  so as we speak im copying my photos and working directories to my ipod
<AndyFitz> lol   fammine before the feast  pain before the pleasure..  these are the ways of the linux kernel
<jnc> AndyFitz: how about "eat as much herring you can before the pundits beat you with large clubs"
<AndyFitz> yeah ,  seemingly more appropirate
<jnc> i just meowed at a cat
<jnc> i'm reaching new levels of dumb
<AndyFitz> jnc, no  you're safe.  yesterday i got on the wrong train and only realised after 6 stops in the wrong direction.  and then i caught the wrong one back missing the transferring train again
<AndyFitz> my date forgave me
<jnc> did you ..
<jnc> that explains it
<jnc> IT WAS THE TRAIN
<jnc> OF LOVE
<jnc> LIKE WOAH
* jnc stumbles back into obscurity
<AndyFitz> oh and i didnt have my phone on my  so i  open my laptop to get her number from evolution to ring from the station.   but my kernel panics
<AndyFitz> it all comes full circle back to the kernels fault
<AndyFitz> even love
<AndyFitz> ... kernels fault
<jsgotangco> this transcript is crack dudes
<jsgotangco> heh
<infinity> AndyFitz : Why not boot with an install CD in rescue mode and fix the kernel issue? :)
<AndyFitz> infinity.  fix the kernel issue by copying vmlinuz  over the existing one ?
<infinity> AndyFitz : By installing a non-broken linux-image package and re-running update-grub?
<AndyFitz> installing how ?  copying the vmlinuz file ?
<infinity> (Though, what actually broke?... initrd?)
<AndyFitz> sorry im a graphics pirate not a code ninja
<infinity> AndyFitz : Downloading the .deb and using 'dpkg -i linux-image-foo.deb'
<infinity> NINJA!
<infinity> *cough*
<AndyFitz> aayeee
<AndyFitz> sounds like good advice my friend .   i'll give it a shot
<infinity> AndyFitz : Or, y'know, bring that tank of a laptop to Melbourne for the Queen's Birthday long weekend, and get some personal service.
<AndyFitz> hey yeah  long weekend is upon us..  doesnt AU rock like that
<infinity> I'm so glad I moved somewhere with such silly holidays.
<AndyFitz> heh  like anyone knew the reason for this holiday.. really
<AndyFitz> i'll be going to melbourne with said chickie in a month actually
<AndyFitz> will have too say g'day
<AndyFitz> and introduce you to those crazy drum and bass  kiwis who use debian
<whiprush> heya infinity ... I remember you telling me that you were an ldap guy at UDU. I have a friend that is working on deploying Fedora's new directory thing and wants to do something with it for Ubuntu. Shall I shuffle him your way?
<infinity> whiprush : Was I drunk at the time?
<infinity> whiprush : (Sure, send him my way)
<whiprush> heh, k.
<jdub> rawk
<whiprush> he's a real good ldap dude, just doesn't know where to start.
<whiprush> he's got this big list of stuff that he does to an ubuntu machine to make it "work right" for ldap and things like windows interop.
<whiprush> it's pretty metal.
<infinity> Cool.
<wasabi_> Heh. I'm one of those LDAP guys. =/
<wasabi_> I missed the first part of that conversation. =(
<whiprush> I'll send him your way too then
<wasabi_> not without me knowing what's going on! 
<wasabi_> I was going to take a look at that fedora ldap server after I got eclipse fixed up.
<wasabi_> Anybody else working with that?
<whiprush> my friend is
<Amaranth> hah
<whiprush> he's got it built on ubuntu 
<Amaranth> it was funny watching that
<wasabi_> Oh rock.
<whiprush> apparently the build process is pretty crap
<wasabi_> http://www.ubuntulinux.org/wiki/DomainAuthenticationUtility
<whiprush> took him the better part of a morning to build it
<wasabi_> That's a ranty page I put together to presearve an idea.
<whiprush> man, I so feel your pain.
<wasabi_> the fedora server might actually be suitable for becoming a replica in active directory
<wasabi_> i haven't looked at it that closey, but it has most of the requisites.
<wasabi_> i bet the ACLs are totally different though
<whiprush> I've heard nothing but good things except for the build process.
<wasabi_> Yeah, it certainly beats out openldap.
* jdub is so psyched about it, but for one thing - it's not like i'll actually be using it.
<whiprush> it'd be a nice breezy+1 or +2 goal to have a plop in replacement for an AD Domain controller.
<wasabi_> I don't think there is much to be psyched about.
<wasabi_> whiprush, that's not going to be possible fora  long time.
<wasabi_> And this doesn't bring us closer to it
* whiprush nods
<whiprush> I'll take anything over nothing though.
<wasabi_> I think the only feature of the fedora one I'm excited about is hte ACLs
<wasabi_> openldap has everything else.
<whiprush> yeah, but openldap makes me want to cut myself.
<wasabi_> Why?
<wasabi_> openldap, especially as distributed by debian, is super easy to set up.
<whiprush> I just can't get anything ootb that isn't obtuse.
<wasabi_> Creates the DB and root for your automatically.
<Amaranth> can't samba work as as an AD domain controller?
<wasabi_> Amaranth, no.
<wasabi_> It can work as a NT4 PDC or BDC.
<Amaranth> hrm
<wasabi_> And can join AD as a member.
<Amaranth> i don't know what these terms mean :P
<Amaranth> i know active directory
<wasabi_> FOSS is missing a TON of requisites for AD.
<fabbione> morning
<wasabi_> bind has no kerberos SIG(0) support.
<whiprush> you can get halfway there with openldap and kerberos.
<whiprush> even then it's a pain.
<jsgotangco> IT IS
<wasabi_> Yeah. You can't serve a windows box properly.
<wasabi_> And serving a linux box is pretty non-par.
<wasabi_> Serving a linux laptop is basically unrealstic.
<jsgotangco> i share your pain
<wasabi_> (no cred caching)
<wasabi_> Oh, we also don't have a suitable file sharing protocol yet. NFSv4 might be it.
<whiprush> and it depends on the distro also. We can't get a single suse machine to even use ldap for auth.
<whiprush> argh.
<wasabi_> Oh that's easy. ;)
<wasabi_> I have all the pam and nss config files for you!
<whiprush> I'm so emailing you.
<wasabi_> In windows it's two button clicks and typing the name of the domain.
<wasabi_> Same with OS X.
<whiprush> can osx join an ad?
<wasabi_> Yes.
<wasabi_> Oh, that's anohter point.
<whiprush> surely it can't serve one.
<wasabi_> Our file system ACLs SUCK
<wasabi_> SUCK BAD
<wasabi_> Tiger actually added NT compatible ACLs to HFS
<wasabi_> Which are pretty darn slick.
<wasabi_> I think we should totally copy them.
<wasabi_> It's just not something most die hard unixers will accept
<whiprush> heh
<whiprush> all I know, is I'm stuck on nis and nfs, and I know I'm not the only one.
<wasabi_> I use AD at the office.
<jsgotangco> same here
<wasabi_> I'm a windows admin during the day time hours. ;)
<jsgotangco> heh
<jsgotangco> i like win2k3
<wasabi_> Me too.
<whiprush> yeah, it's pretty good.
<wasabi_> Check out this:
<wasabi_> http://www.padl.com/Products/XAD.html
<wasabi_> They've done it.
<whiprush> you've tries this?
<wasabi_> no
<wasabi_> it's $$$
<whiprush> oh
<jsgotangco> i haven't been updated in windows server stuff for a while though
<wasabi_> I think andrew bartlett point me to it.
* jsgotangco has been pimping his ubuntu servers with management
<whiprush> I wonder how it really works.
<jsgotangco> Pty
<jsgotangco> australian?
<wasabi_> It's apparently Samba + Kerberos + openLDAp
<wasabi_> all hacked up and made to work
<whiprush> and they did all that integration work?
<wasabi_> that's what they claim
<jsgotangco> that neat if it really works nicely
<whiprush> heh, I'll have to see it to believe it.
<whiprush> although, I do know people who have done it, it just takes them so freaking long.
<wasabi_> Well, they offer stuff nobody has done yet;
<wasabi_> Like group policy supportl.
<whiprush> just noticed that
<whiprush> ms's new SUS++ thing is out now too.
<wasabi_> WSUS
<jsgotangco> wow
<jsgotangco> im still using SUS
<whiprush> jdub: you know, we should have an #ubuntu-sounder for conversation like this ...
<jsgotangco> can SUS be upgraded?
<wasabi_> sounder?
<wasabi_> jsgotangco, don't think so.
<wasabi_> There's no reason to want to upgrade thoughl
<jsgotangco> argghh
<wasabi_> It's not like it reinstalls all your patches.
<whiprush> sounder is the chat/offtopic/justhangout list for ubuntu
<bob2> (ObHistoricalFact: it was originally the list for Warty beta-testers, before it became public; hence the name.)
<jdub> xandros also have client integration stuff done
<jdub> pretty wide ranging, too
<jsgotangco> a sounder of warthogs
<jsgotangco> a colony of hedgehogs
<jsgotangco> a cete of badgers
<jdub> we had 'array' for hedgehogs
<jsgotangco> oh wait
<jsgotangco> 'array' is correct
<hornbeck> anyone around?
<Stargazer> evening... Question, how does one get rid of graphic corruption using 5.04 PPC on a G3?
<bob2> #ubuntu
<Stargazer> sorry..
<fabbione> dilinger: ping?
<dilinger> pong
<fabbione> dilinger: mind if i change lvm2 b-d to drop libreadline4 ?
<fabbione> and bump libdlm-dev versioned b-d?
<dilinger> drop libreadline4 completely?  lvm2 is much nicer to use with it..
<dilinger> anyways, waldi's the person to talk to nowdays, i haven't done much w/ lvm2 lately
<fabbione> i mean replacing it with libreadline5 :)
<dilinger> ah
<dilinger> yea, i don't see a problem w/ it
<mdz> Keybuk: did anything change in dpkg recently which would explain this: dpkg: can't mmap package info file `/var/lib/dpkg/available': Invalid argument
<Keybuk> sounds like your available file is too large
<mdz> it's 0 bytes
<Keybuk> oh, heh
<mdz> copying a normal available file into place there gets it working
<Keybuk> you can't mmap() 0 bytes, can you? :)
<mdz> apparently not
<bob2> can that file just die yet?
<mdz> this sort of breaks debootstrap
<mdz> and by "sort of" I mean "utterly"
<Keybuk> deboostrap pre-seeds available and status, does it not?
<mdz> it just touches them
<Keybuk> is it consistently reproducible?
<mdz> oh yes
<mdz> try a debootstrap
<Keybuk> it would be nice to run gdb over it to see what arguments mmap is getting
<mdz> 10971 mmap2(NULL, 0, PROT_READ, MAP_SHARED, 5, 0) = -1 EINVAL (Invalid argument)
<Keybuk> hmm
<Keybuk> nope, you can mmap 0 bytes, it just returns NULL
<Keybuk> unless someone's broken mmap in a recent kernel?
<mdz> 2.6.12-1-k7
<fabbione> Keybuk: if mmap kernel behaviour is changed.. is a dpkg bug
<fabbione> mdz: did you upgrade the kernel yesterday?
<Keybuk> mdz: http://descent.netsplit.com/~scott/test.c
<mdz> fabbione: yes
<Keybuk> compile that, and run it with a 0-byte test file alongside
<fabbione> mdz: ok. that's 12rc6...
<mdz> Keybuk: I'd already got it written :-P
<mdz> mmap says: Invalid argument
<Keybuk> fabbione: is there a known change to mmap behaviour?
<mdz> Keybuk: what kernel are you on, assuming it works for you?
<daniels> mmap says: Success
<daniels> this is 2.6.10-5-686
<Keybuk> mdz: 2.6.10-5-k7 (hoary)
<fabbione> Keybuk: they did a bunch of security fixes to mmap..
<fabbione> so possibly yes
* Keybuk reaches for the heavy book that bends the shelf
<mdz> mmap(2) only describes EINVAL for length too large or not aligned
<mdz> 0 bytes should have every possible alignment :-)
<Keybuk> there's no restricted-modules for 2.6.12 ?
<mdz> nope
<Keybuk> bah, I can't test it then
<fabbione> Keybuk: why?
<daniels> fabbione: ath, I'm guessing
<Keybuk> because the machine with breezy on it needs lrm for the network card
<mdz> because he's a proprietary driver sellout
<fabbione> Keybuk is 0wn3d by b1n4ry dr1v3r5
<daniels> the openbsd guys reverse-engineered the ath hal
<daniels> it would be great if we could get that into our mainline kernel
<daniels> that way I could do away with my need for lrm also
<Keybuk> binary on chip, binary on disk, what is difference?
<daniels> mdz: i'm glad your machine is completely clear of any proprietary firmware also :P
<mdz>         if (!len)
<mdz>                 return -EINVAL;
<mdz> ^^ Linux 2.6.12
<Keybuk> mdz: cute
<fabbione> Keybuk: fix dpkg _)
<Keybuk> fabbione: I'm very carefully reading POSIX atm
<Keybuk> actually, POSIX seems pretty clear, len=0 shall be EINVAL
<crimsun> it says as much in the rc6 changelog, too
* fabbione point Keybuk to: <fabbione> Keybuk: fix dpkg _)
<mdz>         if (!len)
<mdz>                 return addr;
<mdz>         /* Careful about overflows.. */
<mdz>         len = PAGE_ALIGN(len);
<mdz>         if (!len || len > TASK_SIZE)
<mdz>                 return -EINVAL;
<mdz> ^^ linux 2.6.10
<Keybuk> fabbione: is a tricky fix, annoyingly
<fabbione> Keybuk: i can guess so
<jdub> Keybuk: fix POSIX
* Lathiat grins at jdub
<mdz> that's decidedly trickier
<jdub> let's see who's tricky now!
<Keybuk> mdz: so, I was thinking, why doesn't apt unpack packages as it downloads them?
<mdz> Keybuk: because that would require working out which groups of packages we would have to download at a time
<Keybuk> but don't you already do an ordering calculation for dpkg passing?
<mdz> later
* daniels hums at xorg's 1212-character Build-Depends line.
<daniels> wonder if that'll break sbuild or something in creative ways.
<mdz> and it pretty much cheats with dpkg anyway
<mdz> by unpacking as much as it can at once, modulo essential/pre-depends/conflicts
<daniels> actually, make that 1240 (FEAR THE CVS LIBX11)
<Lathiat> daniels: so does X work yet? :)
<daniels> Lathiat: yeah
<mdz> it is way more work than I am willing to do for the benefit of people who cannot manage their disk space
<Lathiat> in the archives?
<daniels> Lathiat: nope
<Lathiat> daniels: :)
<Keybuk> ...interesting
<Keybuk> FreeBSD seems to support len=0 too
<Keybuk> 	if ((ssize_t) uap->len < 0 ||
<Keybuk> 	    ((flags & MAP_ANON) && uap->fd != -1))
<Keybuk> 		return (EINVAL);
<mdz> pay no attention to them; they use parentheses around return values
* Lathiat laughs
<Lathiat> my lecturer does that
<Lathiat> its annoying
<mdz> was the fix explicitly trying to avoid a security issue?
<mdz> or were they just POSIXifying it while they were in there?
<Keybuk> I have an image of a kernel developer going "aha!  we can break a shit-load of software quietly, muahahahaha!"
<mdz> somebody snuck the patch in by trying to disguise it as an ia64-specific issue
<mdz> everyone ignored it because it said [IA64]  in front
<Keybuk> ok, fucking Solaris supports len=0
<Lathiat> like how mm snuck mppe in? :)
<Lathiat> err
<Burgundavia> jdub, ping
<Keybuk> fabbione: did you apply this same patch to hoary?
<jdub> Burgundavia: pong
<Burgundavia> jdub, I had a crazy thought about file managers, who would I chat with about it?
<fabbione> Keybuk: checking
<jdub> Burgundavia: chat to your blog, send me the link. :)
<Burgundavia> jdub, I wish I had a blog
<Keybuk> fabbione: this will break glibc too
<jdub> Burgundavia: easy to set up :)
<jdub> Burgundavia: and you're a member, so you'd get to be on planet ubuntu
<fabbione> Keybuk: i am still checking
<Burgundavia> jdub, got a suggestion, aside from livejournal?
<Keybuk> in fact, this will break glibc in lots and lots and lots and lots and lots of places :-/
<jdub> Burgundavia: blogger, advogato...
<Keybuk> they pretty much just pass st.st_size for length unilaterally
<Keybuk> do we know whether the kernel developers really have done this for a reason, other than just while they were in there?
<fabbione> Keybuk: no
<fabbione>         if (!len)
<fabbione> -               return addr;
<fabbione> +               return -EINVAL;
<fabbione> it's probably not a security fix
<fabbione> but if it is, it hasn't been announced yet
<fabbione> i will keep an eye
* infinity curses the jadetex maintainers for outsmarting him.
<infinity> Or outstupiding, as the case may be.
<Keybuk> mdz: doesn't dpkg error if available is empty anyway?
<Burgundavia> jdub, http://www.advogato.org/recentlog.html
<Keybuk> oh, no, is ok
<jdub> Burgundavia: you can also link here -> http://www.advogato.org/person/Burgundavia/
<jdub> :)
<Burgundavia> jdub, yes, I saw that, after I pasted the link
<jdub> Burgundavia: also, google for 'thunar' and have a look at the mockups
<jdub> Burgundavia: you are a member, right?
<Burgundavia> jdub, i have looked at thunar
<Burgundavia> but I couldn't remember if it did all those things
<fabbione> mdz: the ia64 patch is really ia64 specific :)
<fabbione> and the change seems to be older than 12rc3
<Burgundavia> jdub, ok, that is exactly what I was looking for
<fabbione> mdz, Keybuck: the change was introduced the 28/03/2005 and SignedOff by Andrew Morton and Linus. 
<Burgundavia> jdub, and yes I am a member
<fabbione> http://linux.bkbits.net:8080/linux-2.6/patch@1.2181.46.141
<fabbione> here it is
<jdub> Burgundavia: wanaa be on planet ubuntu?
<jsgotangco> wow
<Burgundavia> jdub, sure
<fabbione> jdub: i did ask you to be on planet.u.c eons ago...
<fabbione> jdub: am i there or not?
<jdub> fabbione: yep
<fabbione> ok
<Keybuk> fabbione: sweet
<jsgotangco> :)
<jsgotangco> face hacking
<jsgotangco> neat
<fabbione> Keybuk: i am pretty sure it's not easy to convince upstream that the fix is correct, but needs to be reverted :)
<fabbione> i can temporary revert or special case it
<fabbione> but userland needs fixing
<Keybuk> userland will have to catch up anyway
* fabbione needs more coffee
<Burgundavia> ok, someone needs to check that nats head is screwed on right
<Keybuk> fabbione: you realise, this makes the quickest set of dpkg releases in history, right? :p
<jdub> Keybuk: release name "in like flynn"
<Keybuk> what's what one mean? :p
<jdub> elmo: planet ubuntu update please :-)
<daniels> Kamion: um
<daniels> Kamion: so, like, locale handling in xlib
<daniels> Kamion: no-one uses that, right?
<daniels> In Like Flynn
<daniels> Dates back to 1945, refering to how easily movie star Errol Flynn could get women into bed with him.
<jdub> s/women/people/
<Keybuk> descent dpkg-1.13% ./src/dpkg-query -l
<Keybuk> ZERO BYTE PROTECTION MATRIX ACTIVE!
<Keybuk> kewl
<Burgundavia> jdub, cheers
<Treenaks> Keybuk: ooh, you let ogra add some messages to dpkg, to make it more movieos-ish? :)
<jdub> ha ha ha ha
<Treenaks> jdub: I want everything to give me messages like that
<Treenaks> jdub: especially when I'm using my full-screen xterms
<bob2> we need a en_MOVIEOS locale
<bob2> in rosetta
<jdub> ACCESS DENIED
<Keybuk> http://arch.netsplit.com/scott@netsplit.com--2005/dpkg--devel--1.13--patch-157
<fabbione> Keybuk: it's a pleasure to have this honour :)
<pitti> Morning
<fabbione> hey pitti
<allee> #kde-devel
<allee> wrong tab sorry
<daniels> Kamion: if I don't have something workable by :00, I'll just upload a couple of tiny fixes, no modular libX11
<daniels> Kamion: preparing a fixes-only -24 now
<daniels> er, -23
<Lathiat> daniels: for X so it would mostly work?
<daniels> yeah
<daniels> just the mkfontdir fix
<Amaranth> didn't you say you were going to break it all again in -24 though? :)
<AndyFitz> is doing a sudo apt-get dist-upgrade -you   to breezy from hoary is safe at this stage ?.   will it know what to disregard ?
<Lathiat> AndyFitz: not quite yet i think :)
<Lathiat> Amaranth: heh
<Amaranth> AndyFitz: If you care about X, universe, or KDE you shouldn't. :D
<AndyFitz> bugger,  I care about gnome, X, gaim and firefox
<pitti> Hey hey seb128!
<seb128> hey pitti :)
<pitti> seb128: you'll upload a new set of gnome packages soon? I think we should try to downsize http://people.ubuntu.com/~pitti/dload-strippedtar.txt soon to make the Rosetta guys happy
<seb128> weird, there is some packages I've uploaded yesterday in this list
<pitti> seb128: there might still be a bug
<seb128> seems so
<pitti> seb128: is the POT file created on your local build?
<seb128> Warning: tarball ximian-connector_2.3.3-0ubuntu1_translations.tar.gz does not contain a POT file
<seb128> Warning: tarball evolution_2.3.3-0ubuntu1_translations.tar.gz does not contain a POT file
<seb128> good question
<pitti> these are recent uploads?
<seb128> yesterday
<seb128> Warning: tarball gal2.4_2.5.3-0ubuntu1_translations.tar.gz does not contain a POT file
<seb128> 2 days ago
<seb128> Warning: tarball nautilus-cd-burner_2.11.3-0ubuntu1_translations.tar.gz does not contain a POT file
<seb128> yesterday
<pitti> seb128: do you have local builds?
<seb128> yep
<pitti> seb128: where you could do a find -name "*.pot"?
<seb128> ximian-connector has no pot
<pitti> ... but uses gnome.mk?
<seb128> but running "/usr/bin/intltool-update -p --verbose;" works fine
<seb128> yep, it uses gnome.mk
<pitti> seb128: can you look into the build log or put it somewhere?
<pitti> seb128: I'll fix some non-gnome packages in the next time
<seb128> Wrote ../storage/ximian-connector.xml.h
<seb128>  *** xgettext is not found on this system!
<seb128>  *** Without it, intltool-update can not extract strings.
<pitti> uh
<seb128> hum
<pitti> intltool depends on gettext...
<seb128> I have xgettext on my box
<seb128> and running "/usr/bin/intltool-update -p --verbose;" myself works
<pitti> well, wait
<pitti> is there an intltool in the source package?
<pitti> Hi thom
<pitti> seb128: cdbs prefers intltool in the sources and only uses /usr/bin if it isn't present
<seb128> oh k
<seb128> that's bad
<daniels> boooo cdbs
<pitti> seb128: so running ./intltool-update in the source package fails?
<seb128> the local intltool-update has
<seb128>     my $XGETTEXT = $ENV{"XGETTEXT"} || "/opt/gnome2/bin//xgettext";
<pitti> ARRRGH
<seb128> a lot of packages have this bug IIRC
<pitti> seb128: so XGETTEXT=/usr/bin/xgettext ./intltool-update works?
<seb128> now that you speak about it, a guy bugged me about that some time ago
<danielki> eeeep
<pitti> seb128: I can add the env variable to gnome.mk
<seb128> correct
<seb128> that fixes it
* pitti fixes
<daniels> OH FRIGGING HELL IMAKE
<daniels> build systems are crap.
<pitti> daniels: it's like mutt, they all suck, some suck less...
<daniels> xorg should build by osmosis or something.
<daniels> autotools is showering me in hate and derision in one tab, and imake is kicking me in the goods and taunting me in another
<seb128> pitti: this bug should be fixed though
<seb128>     my $MSGFMT = $ENV{"MSGFMT"} || "/opt/gnome2/bin//msgfmt";
<Lathiat> daniels: heh
<seb128>     my $MSGMERGE = $ENV{"MSGMERGE"} || "/opt/gnome2/bin//msgmerge";
<pitti> seb128: OMG
<Lathiat> hm, archive.ubuntu.com is running a tad slow
<pitti> seb128: but that's hardcoded into dozens of packages
<seb128> pitti: anyway to create the .pot we only need $XGETTEXT
<seb128> pitti: yeah
<pitti> seb128: it might be easier to just prefer /usr/bin/intltool-update then
<seb128> I think so
<seb128> no reason to prefer bugged copies
<pitti> seb128: alright, I swap the preference and add the XGETTEXT variable
<seb128> thanks
<pitti> seb128: so we'll need to upload that stuff again at some time
<seb128> what stuff?
<seb128> the bugged packages?
<pitti> seb128: I fixed postgresql yesterday btw, just not yet uploaded
<pitti> seb128: yes
<pitti> seb128: to have them rebuilt and the pot file extracted
<seb128> that cannot be done by hand?
<seb128> rebuilding evolution to just get the .pot seems a waste
<pitti> seb128: well, it can
<pitti> seb128: no, not just for the pot
<pitti> seb128: but there certainly will be a new upload anyway
<seb128> any hurry?
<pitti> seb128: until Breezy release :)
<seb128> anything will be upload within 2-3 weeks again
<seb128> oh, that's fine
<seb128> we have a bunch of GNOME versions before
<pitti> seb128: but given the number of outstanding packages we should start fixing that early
<seb128> your list is quite small
<seb128> I upload 60% of these packages on a normal new GNOME version
<pitti> seb128: which is good :-)
<seb128> just fix the CDBS hack and we are fine
<seb128> I've some stuff to upload today, I'll wait to get your fixed packages on the buildd
<pitti> I fixed it, now I test it, then I upload; gimme ~ 15 minutes
<pitti> seb128: oh, wait, the dchroots aren't updated until tomorrow anyway
<pitti> seb128: so just go ahead, if it's settled in 3 weeks, that's fine
* Amaranth beats xgettext
<pitti> Hi trulux 
<seb128> pitti: k, thanks
<pitti> seb128: uploaded, btw
<pitti> mvo: here`
<pitti> ?
<Keybuk> descent src% fakeroot ./dpkg --print-architecture
<Keybuk> i386
<Keybuk> yay, that's better
<pitti> hooray
<Keybuk> Unpacking banana (from /home/scott/tmp/banana_1.0.deb) ...
<Keybuk> couldn't open log `': No such file or directory
<Keybuk> free(): invalid pointer 0xbffff214!
<Keybuk> zsh: segmentation fault (core dumped)  sudo ./dpkg -i ~/tmp/banana_1.0.deb
<Keybuk> ...
<Keybuk> well, partly better
<mvo> pitti: yes
<daniels> argh, good god
<pitti> mvo: can you modify the update-manager package that it creates a POT file during build?
<daniels> i wonder if it ever occurred to whoever wrote xf86config that 3095-character strings means that YOU'RE DOING SOMETHING WRONG
<pitti> mvo: same for synaptic?
<Lathiat> daniels: whats that for?
<daniels> Lathiat: it's in xorgconfig.c
<daniels> the 'string length 3095 is longer than the 509 ANSI C compilers are required to support' warning caught my eye
<mvo> pitti: they don't do that right now? they should have a pretty much default config when it comes to gettext
<Lathiat> daniels: heh
<pitti> mvo: 
<pitti> http://people.ubuntu.com/~pitti/dload-strippedtar.txt
<Keybuk> daniels: ANSI only used to mandate 509 :p
<mvo> pitti: ok, I'll check
<daniels> Keybuk: right, hence the whole warning bit
<Keybuk> oh, sorry, you mentioned that
<Keybuk> I always thought that was such a "thumb up the arse" constant
<Keybuk> it's not even a power of 2, like real constants
<daniels> oh, sure
<danielki> 512 - 3
<daniels> but it's a great indication of stupid code ahead
<daniels> danielki: one for \0, two for ...
<Keybuk> \r\n
<Keybuk> ? :p
<danielki> if thought of in terms of dwords it makes some sense
<daniels> ah yes
<daniels> god, this cursor generation is annoying
<daniels> that *has* to go for -25
* Keybuk spots the deliberate mistake in the source
<Keybuk> if (log) nfmalloc...
<Keybuk> no, Keybuk, if (!log) :p
<daniels> gar, this manpage preprocessing thing is annoying me
<daniels> heh
<Keybuk> 2005-06-10 09:46:52 status k\uffffL\uffff,qx,q\uffff\uffff\uffff\uffff\uffff\uffff$
<Keybuk> hmm.... wrong pointer in there somewhere methinks
<daniels> smooth
<Amaranth> stupid netsplits
<Keybuk> ah, no, I wanted varbufvprintf
<Amaranth> if the old me comes back from the dead and knocks me off irc i'll be super pissed
<daniels> ah, crap, I hate Romanian kezboards
<daniels> grpalts?toggle lets me toggle to Romanian
<daniels> but not back to us
<Keybuk> why are you on a Romanian keyboard?
<daniels> #10939
<daniels> not so much a romanian keyboard as just hte layout
<Keybuk> ah
<daniels> aha.
* daniels conquers stupid setxkbmap semantics, gets back to a working keyboard.
<Keybuk> OMFG
* Keybuk smashes his head through his desk
<Keybuk> (after discovering a bug the size of a large planet in the dpkg config file parser)
<daniels> whoohoo
<thom> not a small moon?
<daniels> thom: dpkg ever has small bugs?
<Keybuk> Dear iwj, when storing a string you've just found in the file, it helps to strdup it so the memory isn't overwritten by the string in the next line
<daniels> i thought it only broke shit no-one cared about, like dpkg-architecture, and dpkg --print-architecture
<Keybuk> I deliberately broke dpkg-architecture though
<Keybuk> hmm
<Keybuk>   if (!strcmp(user, "branden"))
<Keybuk>     cause_strange_divert_bugs();
<daniels> heh
<danielki> eeep
<danielki> I hate this !strcmp() syntax
<Keybuk> danielki: read "strcmp" as "do these strings differ?"
<Keybuk> it's a common early mistake to try and read it as "are they the same?"
<danielki> well but that's not what it's doing
<Keybuk> so that's if not the strings differ
<danielki> it doesn't return a boolean
<danielki> so I prefer using == 0, < 0, > 0
<Keybuk> everything's boolean in C :p
<danielki> everything converts to boolean, yes
<Keybuk> I went through a phase of doing things like:  if (file == NULL) and stuff
<Keybuk> but got bored of it
<danielki> that's different
<Keybuk> too much typing :p
<pitti> hrmpf, bloody network; I lost everything after "<pitti> seb128: is system-tools-backends in the set of packages you upload soon?"
<seb128> I've not received this one
<seb128> probably not, but I can do an upload if you want
<pitti> not just for the pot
<pitti> seb128: I started to collect the packages that only require a rebuild in a list
<seb128> there is probably some bug to fix, I can look for one to pretext an upload :p
<pitti> hehe
<Keybuk> danielki: C doesn't have a boolean type, so nothing converts to boolean
<Keybuk> (ignoring the silly typdef in C99 for C++ freaks :p)
<danielki> Keybuk: well every expression can be evaluated in a boolean context
<danielki> ok now? :)
<Keybuk> indeed, and that's implemented as a comparison against zero
<danielki> btw I got C++ background
<Keybuk> so why add your own comparison against zero?
<Keybuk> if (x != 0) ... ends up as cmp(cmp(x, 0), 0)
<danielki> Keybuk: for clarification in cases where it's not obvious
<pitti> elmo: can I please have libgnomeprintui2.2-dev in concordia's breezy dchroot?
<danielki> I wouldn't explicitely compare the return value of say strequal() against 0
<Keybuk> if (x) and if (!x) are absurdly common idioms in C though
<danielki> yes
<danielki> and I don't have a problem with that
<pitti> seb128: oh, it doesn't use gnome.mk, so I have to fix it anyway
<Keybuk> there is no strequal() in C though ...
<danielki> but strcmp() doesn't return a boolean conceptionally
<danielki> it was a hypothetical example
<Keybuk> there are no C standard library functions that return conceptual booleans
<Keybuk> they all return richer information
<Keybuk> if (strchr("foo", 'f')) would be wrong, by your assertion, because it returns a pointer not a boolean
<Keybuk> etc.
<danielki> well yeah
<Keybuk> this was pretty deliberate
<Keybuk> and is actually why most functions return zero for "I worked"
<danielki> I'm not saying my coding style is entirely consequent :)
<Keybuk> so they can return lots more useful error information
<danielki> I know
<danielki> fortunately I'm doing C++ mostly
<Keybuk> poor man ;)
<danielki> heh
<elmo> pitti: done
<pitti> thanks
<mvo> pitti: I updated the u-m and synaptic repos. but I have no idea why the pots weren't included in the first place. it's a pretty stock "intltoolize" configureation (that seems to work for update-notifier just fine)
<pitti> mvo: well, all gnome packages are packaged that way, but don't generate a POT automatically
<Kamion> daniels: cheers, dude
<pitti> mvo: unless you use gnome.mk, you need to add the intltool-update --verbose -p call to debian/rules
<daniels> just waiting for the build to finish to verify now; imake outsmarted me before and broke for no reason
<daniels> and now I'm in the hillarious situation where I have no keyboard input but shift + control (everything else gets swallowed), but I can't restart X because the builds are running under it :P
<daniels> (totally rooted -- SSHing in and trying to fix it with setxkbmap for ten minutes has yielded nothing)
<daniels> mjg59: it would be awesome if dasher had symbols
<mvo> pitti: wouldn't it be better if we would patch intltool so that it includes the pot file in the dist-rule in the generated po/Makefile? so that at least in the future the problem goes away?
<pitti> mvo: if that's possible?
<pitti> mvo: but make dist isn't executed at build, is it?
<mvo> pitti: right. it was meant as a long term fix. because upstream would need to run intltoolize again in there po dir. then the pot file would be part of the upstream tarball
<pitti> mvo: no, that's not the point
<mvo> pitti: no?
<pitti> mvo: we really need to create the pot during package build
<pitti> mvo: e. g. if Ubuntu adds a patch involving strings, we want to have them in the POT
<mjg59> daniels: Select "English with lots of punctuation"
<pitti> mvo: so if at all, we need to patch intltoolize to add the "create pot" dependency
<daniels> mjg59: my hero
<mvo> pitti: that means that each package needs to be modified to include this "intltool-update -p"  (because we potentially modifiy string for each package in main)?
<pitti> mvo: well, I did a general solution for cdbs+gnome.mk
<pitti> mvo: so that Gnome is done
<mvo> pitti: for all cdbs packages :) 
<pitti> mvo: I asked Riddell to do a similar trick in KDE
<pitti> mvo: and many non-Gnome/KDE packages already come with a POT, and adding UBuntu-specific strings is relatively unlikey (and not as important as for Gnome/KDE)
<pitti> mvo: so in the end we only need to fix 20ish packages
<pitti> mvo: I'm doing that ATM
<mvo> pitti: ok, so intltool-update -p and a build-dep on intltool for u-m,u-n,synaptic?
<pitti> mvo: it's not already a build-dep?
<mvo> pitti: it is, right
<mvo> pitti: is it urgent? or is it good enough if it's part of the next regular update
<pitti> mvo: oh, it's not that urgent
<pitti> mvo: I just go down the list and make sure that it will be fixed in a few weeks at most
<pitti> mvo: the Rosetta guys need POT files for import, so the earlier they have them, the earlier I can build langpacks from Rosetta :-)
<fabbione> elmo: please NEW redhat-cluster-suite (the source and a couple of debs need to go in main - lvm2 b-d, the others in universe are ok for now)
<jordi> carlos: dude
<jordi> carlos: where's the src for the gnome status pages?
<carlos> jordi, I send it when someone asks me for it
<carlos> why?
<jordi> I want it :)
<jordi> for the lliurex status pages. :)
<jordi> carlos: should be in CVS I guess
<carlos> jordi, no way, it's so ugly and dark hack I don't want it in a CVS. New version is available as an ARCH repository
<carlos> jordi, but the old one is not
<jordi> carlos: new one as in the New Status Pages(TM)?
<carlos> yeah
<jordi> carlos: nobody expected woody would come out before the new status pages! :P
<carlos> the python one
<jordi> err, sarge
<jordi> once again I need a nap
* carlos pokes jordi 
<jordi> so is that usable?
<carlos> not yet
<jordi> how far from being usable?
<carlos> not too much, I have the database running already 
<carlos> jordi, but I cannot give you dates
<jordi> carlos: ok, so can you mail me the hackish code which I'll keep private? :)
<carlos> jordi, you are free to share it, is GPL, but will do, don't worry, let me finish my current task...
<jordi> k
<daniels> god, the install target is achingly slow tonight
* jordi tickles daniels.
<pitti> elmo: can I please have in conc/breezy: libgsf-gnome-1-dev libgda2-dev
<elmo> pitti: done
<daniels> OH< COCK
<daniels> my build would've completed a FULL HOUR EARLIER had festival not been spinning
<daniels> godamnit
<TerminX> say, does X still need a bunch of manual symlinks to work?
<daniels> TerminX: no
<daniels> right now, it needs one
<daniels> and as soon as this dput is finished, it will need zero
* Amaranth still has all those symlinks
<Amaranth> sucks, i don't know how to find them
<TerminX> alright.. I've been holding off upgrading for a few weeks so I'm still using 6.8.2-10
<Micksa> if anyone cares
<Micksa> "mozilla $file" from cmdline doesn't appear to work if $file contains spaces
<daniels> Micksa: mozilla "$file"
<Micksa> that either :P
<Micksa> gawddammit I sure get the newbie treatment a lot
<tseng> works in firefox
<tseng> so im pretty sure it works in moz too
<daniels> Kamion: enjoy -23
<daniels> tseng: nope, he's right
<daniels> daniels@catsby:~% echo '<html><head><title>foo bar</title></head><body>foo bar</body></html>' > 'foo bar.html' && mozilla 'foo bar.html'
<daniels> /usr/bin/mozilla: line 385: [: /home/daniels/foo: binary operator expected
<daniels> zsh: exit 3     mozilla 'foo bar.html'
<daniels> it's a pretty obvious lack of quoting thorughout
<Treenaks> go daniels :)
<tseng> well its fixed in FF then
<fabbione> elmo: thanks for NEW'ing
<pitti> mvo: I didn't see a POT-related change in the latest u-n upload, does that already build a pot?
<mvo> pitti: it should, does it not do it?
<pitti> mvo: dunno, I just read it at u-changes
<pitti> mvo: I'll see tomorrow, then the list is autogenerated again
<mvo> pitti: please ping me if it doesn't, it should do it now (I may have forgotten to add that change to the changelog)
<pitti> sure, I'll walk the list occasionally in the next time
<mvo> pitti: thanks
<daniels> argh, this is so not funny
<spo0nman> 
<daniels> hrm
<trulux> hey pitti 
<pitti> seb128: hm, system-tools-backends and gnome-system-tools don't use cdbs...
<seb128> I know
<daniels> jesus
<daniels> various chunks of X now expect /usr/X11R6/lib/X11/xkb, /usr/lib/X11/xkb, and /usr/share/X11/xkb for XKB data
<daniels> and the packaging uses /etc/X11/xkb
<tseng> daniels: i bet it sucks more than dbus
<daniels> tseng: yes, it does
<daniels> fwiw, the only reason dbus isn't done, is because I'm in the middle of a mirror pulse
<daniels> so I still have lots of broken packages, including mono
<tseng> :(
<tseng> its certainly not urgent, i just like to give you a raft of shit
<daniels> watch it :P
<Nafallo> hi all!
<AndyFit1> hi Nafallo
<Kamion> mdz: ltsp-client should Depends: openssh-client (>= 1:3.9p1)
<Kamion> (for SendEnv)
<doko> jbailey: looking at http://people.ubuntu.com/~lamont/buildLogs/s/sablotron/1.0.2-4ubuntu1/ I think we need to sync cdbs from unstable (if there's still something to sync).
<pitti> erm, nooo!
<pitti> merge, please
<pitti> unless jbailey adopts the gnome.mk change
<jbailey> I guess i'm going to have to start thinking about cdbs in debian again, since 1) There's no freeze, and 2) my comaintainer just resigned for Debian.  hmm
<Burgundavia> jbailey, who was your comaintainer
<jbailey> Burgundavia: Robert Millan
<pitti> what a pity
<doko> jbailey: would a sync/merge/whatever possible today?
<jbailey> doko: Yup, give me an hour?
<pitti> jbailey: cdbs-edit-patch is already in Debian, right?
<jbailey> pitti: I'm pretty sure it is.
<pitti> jbailey: how do you feel about the POT extraction change?
<jbailey> pitti: To gnome.mk?
<pitti> jbailey: that's the only other Ubuntu change so far IIRC
<pitti> yes
<azeem> jbailey: you also start needing to think who to push CDBS' street credibility again.  Everybody in Debian seems to hate it now :(
<jbailey> pitti: I defer all of those decisions to seb and the gnome team.  They're welcome to include all the crazy things they want in there.
<azeem> gar, s/who/how/
<pitti> jbailey: I'm currently changing two dozens of other packages to generate POT files; I'll submit the patches to Debian, too
<pitti> azeem: oh, why?
<jbailey> azeem: Robert made some crack-headed decisions with it, which is sad.
<azeem> yeah
<jbailey> azeem: Although so far when I ask people why they don't like cdbs, they can't actually tell me why.
<pitti> because it rock!!! :-)
<pitti> s/k!/ks!/
<jbailey> The majority of them seem unable to distinguish 'cdbs' and 'dbs', which is unfortunate.
<azeem> well, the let's change Build-Depends on-the-fly by putting @cdbs@ in it didn't go down well with some people
<jbailey> Right, but those people seem unable to accept the "then don't use that feature"
<pitti> azeem: erm, nobody forces you to, right?
<jbailey> And with the new DAM being a crack-head and refusing packages that use it, didn't help.
<azeem> pitti: some people == ftp-master who reviewed NEW packages with that crack applied
<doko> jbailey: cdbs isn't over-documentated
<jbailey> azeem: I think probably the ugliest bit is that dh_make --cdbs uses that mode by *Default*
<azeem> ugh
<pitti> oh, there is a --cdbs switch? Nice... /me makes mental note
<jbailey> The compromise that I worked out with the DAM for cdbs2 is that cdbs will continue to support that feature, *however*, it will be crippled such that if you don't have DEB_BUILD_OPTIONS="genconfig" set, it'll error rather than update debian/control if it's out of date.
<azeem> in any case I think we need some policy to freeze Build-Depends like cdbs way before release.  Robert hacked on and off on it until a couple of days before the hard freeze
<azeem> anyway, this is off-topic 
<jvw> fwiw, I agree with the policy to reject this type of build-time control mangling in Debian -- and it's likely to be forbidden by release policy too fwiw
<jbailey> azeem: It's not horribly off-topic, cdbs development affects a good chunk of Ubuntu as well.
<jbailey> jvw: At present that would mean refusing glibc and gcc.
<jvw> gcc & glibc have some weirdness that cause some ftp master scripts to complain yeah
<jvw> I didn't yet look into that because of the base freeze
<jbailey> jvw: That was my objection to the sudden refusal to accept the packages.  There's prior art for it and nothing in policy that prevents it.
<azeem> jvw: are you talking about Build-Depends mangling, or all kinds of control mangling?
<jvw> azeem: basicly all -- there's substitution support in dpkg already
<jvw> that should be used, as the Debian policy says
<jvw> like shlibs does
<jbailey> There's no reason why build-dep's *shouldn't* be auto-generated.
<jvw> other control file mangling is only likely to give you problems IMHO
<jbailey> It just needs to be done and locked before upload, and die if there's any chance of it happening at buildd time.
<jbailey> And jrg agreed to that.
<jvw> jbailey: yes, there is -- build-depends are stored in the .dsc, and an autobuild changing that from under it is WRONG
<jvw> ah, right
<jbailey> jvw: Read again. =)
<jvw> I typed before your last two lines :)
<jbailey> =)
<jvw> anyway, in what cases can it then suddenly die?
<jvw> seems to me like a great chance of later on suddenly the package starting to FTBFS
<jvw> and, still I don't see *at all* a need for control mangling
<jvw> substvars support in dpkg is exactly meant for that, and accepted
<jbailey> When using a tool.. cdbs, dpkg, debhelper, etc. there's always a chance of a package FTBFSing at a later date.
<jvw> rather than @cdbs@ voodoo
<jbailey> Right, except that substvars can't work for build-depends.
<jvw> jbailey: true, so I'm not necessarily saying it's not ok
<jbailey> Again, it's too late.
<jvw> jbailey: why not? They only apply to later stanza's...? Hm, can be
<jbailey> No, it's because the build-deps are stored in the .dsc file.
<jbailey> @subst@ substitutions happen when control is split into the various binary packages.
<jbailey> err, substvars, rather.
<jvw> ah, true
<jvw> well, I do maintain that the possibility of build-depends changing at build time is a no-no
<jbailey> The trick here is that cdbs should be able to make an accurate guess about things like minimum debhelper requirements, etc.
<jvw> FTBFS'ing is more like a maintainance problem, I don't think I like it, but I'm not opposed enough to argue against it
<jbailey> The gnome team might say universally that they need a minimum version of gnome-libs or something.  That's all bits that cdbs can now.
<jbailey> s/now/know/
<jvw> well, Debian's package management doesn't support that, and how could buildd's start to know that?
<jbailey> Because cdbs is macro-based.
<jbailey> So if you say that you want the debhelper feature.
<jbailey> It can automatically impliy debhelper >> 4
<jbailey> If you have a python app, and a module pulls in dh_python
<jbailey> It can know that it needs to update that to 4.2
<jbailey> So rather than relying on the developper to specify all these things by hand (which he generally won't), they can be inserted automatically and ease the backporting nightmare.
<jvw> that module got updated by an upload, that upload then should of course have the right depends then...
<jvw> missing dependency of that module
<jbailey> True for depends, not true for build-depends.
<jvw> you depend on cdbs, cdbs's module apparantly requires debhelper4.2
<jvw> then it that given cdbs version must depend on debhelper4.2
<jbailey> Except that there's no need for cdbs to depend on debhelper at all.
<jvw> quite clear, and works for lots of years in Debian already
<jbailey> You're not required to use debhelper in order to use cdbs.
<jbailey> (You'd be insane not to, mind you.. *g*)
<pitti> jbailey: the question is now many packages actually use cdbs without debhelper in reality
<jbailey> pitti: None.
<jbailey> But why should cdbs force you to get a *newer* debhelper, just because in one particular configuration you need a newer version?
<jvw> IMHO that's a design flaw in cdbs, but whatever, we'll see what cdbs2 brings
<pitti> jbailey: even if there was, having an unnecessary debhelper b-d for one or two packages in the archive is no biggie...
<jbailey> Or what about cdbs' distutils support?  Should it also depend on python?  ocaml?  ant?
<pitti> jbailey: well, wrt the version you are right
<jvw> I simly note that my trust in cdbs is not very high atm due to the frequent breakeage caused also in the last months before release
<jvw> that *really* was annoying
<jvw> I don't recall at all a debhelper upload suddenly causing tons of packages to FTBFS
<jbailey> I do. =)
<jbailey> But in any event, most of the breakage in the few months before the Sarge release I was generally unaware of.
<jvw> well, debhelper is more mature, it might have done so a while ago indeed
<jbailey> We froze cdbs in Ubuntu in January and didn't pull in the updates after that.
<jvw> http://packages.qa.debian.org/c/cdbs/news/1.html
<doko> jvw: generated control files aren't bad, if they don't change during the build
<jvw> if you have such a central build-depends like cdbs, it is a *must* to test building a number of packages with it to see if it breaks
<jvw> doko: I agree with that
<jbailey> I tried to avoid updating cdbs and initrd-tools after that.  All breakage from that point on was by comaintainers or NMUers who wouldn't accept my rational of "Leave it *alone*, it's good enough"
<jvw> jbailey: I don't blame you for it fwiw, I'm just noting my unhappyness with cdbs maintainance in Debian in general in the period before release :)
<jbailey> jvw: RIght, and before every upload I did to Debian until probably mid-last fall when I stopped doing serious new work on it, I used to build every cdbs-using package in the archive with each update.
<jbailey> It's hard to convine people to do that when they're NMUing, and the buildd maintainers get upset when you do that automatically. =)
<Burgundavia> is this license DFSG free?
<Burgundavia> http://www.opencontent.org/opl.shtml
<jvw> doko: gcc/glibc have some inaccurateness in the .dsc Binary: field though, but I'll mail/bug later about that :)
<doko> it will become interesting, when I want to automatically add/drop a binary package for an automatic build. but you could work around that by building the package twice, or a policy to call a target to regenerate the control file
<daniels> Burgundavia: doubt it
<daniels> You may not charge a fee for the sole service of providing access to and/or use of the OC via a network (e.g. the Internet), whether it be via the world wide web, FTP, or any other method. 
<doko> jvw: you mean packages not built anymore from one package?
<jvw> I think .dsc's should have a more accurate Binary: field support, more manifest-like: stating which archs build which binary package -- accurately
<jvw> doko: also packages built from it without admitting it iirc
<doko> really? that's fun
<jvw> doko: oh, that's gcc-2.95 only
<jvw> doko: gcc-2.95-nof is built without the .dsc admitting to it
<jvw> doko: will etch ship gcc-2.95?
<jbailey> jvw: Anyhow, if you're interested in cdbs and have a love of interesting shell tricks, see the build-common module on svn.debian.org =)
<doko> jvw: will m68k need it to build mac kernels? anyway, that's off topic ;-)
<jvw> jbailey: actually I'm not, I don't use cdbs and don't want to use it, because I disagree with the fundamental design of it :)
<jvw> doko: right, sorry :)
<Burgundavia> daniels, that license is made by the same people as the opl and that is non-free
* lamont heads office-wards
<pitti> seb128, do you happen to have heard about a polypaudio sink for gstreamer?
<seb128> there is one
<seb128> it's not built because Debian doesn't has polypaudio
<daniels> eww, polypaudio
<seb128> pitti: I can build it if you want
<pitti> seb128: oh, that would be cool
<pitti> seb128: btw, otavio salvador uploaded polypaudio to experimental
<pitti> seb128: I spoke with him and we will maintain the package together (using baz trees)
<pitti> seb128: with yesterday's fixes polypaudio behaves much better on my system at least
<pitti> I'd like to push it into main soon for wider testing, just need to talk with Erik about supportability before
<pitti> seb128: using the esd sink with it would forfeit many advantages, so if you could build the sink, that'd rock
<seb128> k
<seb128> I need to fix the gst-plugins0.8 build with cairo 0.5 first
<pitti> seb128: oh, would that mean to build-dep on libpolyp-dev or so?
<seb128> yep
<seb128> the Debian package has already the code for polypaudio
<pitti> seb128: hm, then we need the package in main first
<pitti> seb128: so we have to throw it out again if it shouldn't work for us
<jani> elmo ping
<pitti> Riddell: around?
<Nafallo> maswan: what's up with your syncs today? haven't synced since 5:20.
<Nafallo> maswan: ehm. rather your project/trace/ is a bit screwed ;-)
<pitti> Hi mdz 
<mdz> morning
<pitti> mdz: can we put polypaudio into main to receive some testing and be able to build a polypaudio gstreamer sink?
<mdz> pitti: sure
<pitti> mdz: if it still fails for too many users we might need to throw it out again
<pitti> mdz: but at least for me it works quite well now
<mdz> pitti: main, not desktop, right?
<pitti> mdz: supported for now to be able to depend on libpolyp-dev for gstreamer
<pitti> mdz: depending on how it behaves, we should later drop it again or put it into desktop as esd replacement
<mdz> pitti: will that resolve the issues with resampling that I am having?
<pitti> mdz: oh, dmix doesn't resample for you? yes, it should
<mdz> it sounds awful
<pitti> mdz: that's what I mean, dmix is still too flakey to use it direcly
<pitti> uh
<mdz> I have to start esd with -r 48000 to get reasonable sound
<pitti> mdz: ah
<pitti> mdz: that's known
<pitti> mdz: esd+dmix = the suck
<mdz> ok
<pitti> mdz: we changed the default gstreamer sink to alsa directly
<pitti> mdz: however, that won't happen automatically if you ever changed it manually
<pitti> mdz: kick esd for now and switch to alsa, that should work nicely
<pitti> seb128: ok, it seems that depending on libpolyp-dev is fine for now
<mdz> pitti: also, the esd output for xmms sounds terrible for some reason
<mdz> ogg123 and mpg321 sound fine
<mdz> but xmms pops and skips
<pitti> probably the same bug
<pitti> I tried to apply various patches to esd to make it work with the new alsa lib, but it didn't help
<seb128> elmo: can you sync gedit gconf-editor libgnomeui gucharmap(incoming) gcalctool(incoming) ?
<mdz> pitti: speaking of which, could you merge the new alsa-driver?  I think jdthood has merged most of our patches now, so it should be good
<pitti> mdz: sure, I already reassigned the bug to me
<pitti> mdz: just didn't have time yet
<mdz> ok, I am a bit behind on bugs :-)
<pitti> mdz: I'll do that on monday; I'd like to finish Ubuntu work now and fix some PostgreSQL bugs :-)
<mdz> seb128: what's the word on LaunchpadIntegration?
<seb128> mdz: I've discussed about that with jamesh 2 days ago, need to review all the desktop package to count the number of them using all of the differents option to build a menu
<shaya> anyone having problems w/ ctrl-alt-f-key vt switching in X?
<seb128> mdz: Mark wants the menu items for the standard Desktop and is fine with the spec's picker for the rest of packages ... we are trying to figure how much work/patching the menu changes require
<pitti> shaya: WFM
<shaya> hmm
<shaya> probably cause I'm on a mixture of -10 and -22
<shaya> oh well, can live without them for now
<daniels> er, yeah
<daniels> don't do that
<shaya> well full -22 dont work
<shaya> as font issue
<daniels> no, but full -23 will
<shaya> known problem I beleive
<shaya> and if I hold the font packages back, but install the server stuff, can't input anything
<shaya> so holding server and kebyoard stuff back
<shaya> and X works fine mostly this way
<daniels> sounds like you've created symlinks to fix stuff in the past, and they're coming back to eat your soul
<mdz> seb128: didn't sivang do that review already?  it's in the wiki somewhere
<seb128> mdz: he has reviewed the "about" boxes
<seb128> which would be an easy part to hack ...
<seb128> menu are tricky because they are not standard, every app list the items to put here
<Nafallo> maswan: thanx :-)
<shaya> daniels: I dont know why you assume I have a soul
<shaya> :)
<mxpxpod> thom: ping
<seb128> elmo: thanks
<doko> seb128: want 11680 back?
<doko> tell gnome-terminal that it should start a login shell ...
<seb128> doko: bah, you have a bug open about this on Debian for 130 days that you have not closed
<seb128> doko: "bash" should source it?
<doko> in Debian? didn't see it.
<seb128> doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292023
<doko> seb128: .bash_profile is only sourced, if it's a login shell. but you can tell gnome-terminal to start a login shell
<seb128> k
<doko> 292023 is something else, but maybe invalid
<seb128> doko: ubuntu bug closed, thanks
<Stargazer_> Hi.. nobody is answering me in #ubuntu..  I'm new to Ubuntu 5.04 PPC.. I have a few questions about playing video.. I have no problem installing VLC and it will play video (avi,divx) but never with sound.  If I use the Totem player it always plays sounds but no video.  Now, I install mplayer and I go to quicktime.com for example and the plugin downloads a movie trailer to 100% and then does nothing more at all.. no sound/no video.
<seb128> Stargazer_: that's not an user chan
* shaya prays to the X gods and installs -23
<Stargazer_> Any idea where I would find a user channel for ubuntu?
<seb128> #ubuntu
<Stargazer_> That's where no-one is answering me.
<Kamion> seb128: you meant "this isn't a user chan", otherwise it looks like you're saying that #ubuntu isn't a user channel
<bob2> Stargazer_: try the user list then, http://lists.ubuntu.com/
<seb128> Kamion: right
<Simira> Stargazer_: try your country channel? Where are you from?
<seb128> Stargazer_: for totem use totem-xine rather, or totem-gstreamer with gstreamer0.8-ffmpeg
<Stargazer_> I'm from Canada
<Simira> Stargazer_: try #ubuntu-ca ?
<Stargazer_> Ok.. didn't realize that channel existed... thanks
<jlj> Stargazer_: try #videolan for help with vlc
<shaya> what's the right answer to this Q
<shaya> "The X system keyboard settings differ from your current GNOME keyboard settings.  Which set would you like to use?"
<shaya> X? gnome?
<infinity> shaya : Doe syour keyboard work in GNOME?
<infinity> shaya : If so, I'd pick that one. :)
<shaya> I'm currently in gnome
<shaya> but I'd assume its working b/c its using X settings
<shaya> and clicking "Gnome" would change X and clicking X would change Gnome
<shaya> ls
<shaya> anyways -23 seems to work fine
<shaya> yay
<shaya> at least once I changed font paths to shared
<susus> JaneW: ping
<luis_> this is not *quite* on topic, but does anyone know why ooo 1.9 has not been updated recently to the newer michael-released ooo builds?
<Kamion> What happened to the Firefox and Evolution icons in the top panel on fresh installations?
<Kamion> otherwise, a fresh installation seems to work on at least i386 today
<Kamion> whoa, no more "open terminal" entry on the desktop context menu?
<luis_> apt-get install nautilus-open-terminal
<tseng> luis_: how does that make sense?
<luis_> how does what make sense?
<Amaranth> tseng: regular users don't need to open a terminal all the time
<mdz> Kamion: I noticed both of those as well
<tseng> moving the terminal button into a seperate package
<luis_> because most users shouldn't have to know what a terminal is
<luis_> much less have it as the first option in their file manager
<luis_> and because the new one in that package is much more powerful/flexible
<mdz> I have a keyboard shortcut for a terminal; I don't use the context menu for that anyway
<luis_> so it is actually more useful for the power users who want it there
<tseng> ok, ill try it
<mdz> Kamion: which version of dpkg was used in that test?
<luis_> it actually opens terminals in the right directory, for example, if you're browsing a directory and right-click there
<tseng> i have a keybinding, but on new/other systems
<tseng> i am in the habit of using that in the context menu
<mdz> Kamion: debootstrap fails for me with current dpkg
<Kamion> mdz: 1.13.7
<Kamion> works fine on fresh installations
<mdz> oh, never mind, that was a kernel thing
* lamont ponders the best way to have a chunk of python code execute at process termination time, regardless of how the process is killed/terminated (modulo kill -9, of course)
<mdz> dpkg fails with an empty available file under 2.6.12
<Kamion> hm, lots of warnings from new findutils
<tseng> luis_: show me the power!
<Treenaks> mdz: hm, 2.6.12 can load modules again?
<lamont> findutils was supposed to break a few things, right Kamion?>
<lamont> 2.6.12 isn't doing abi versioning right now, afaik
<daniels> tseng: mirror kick is still running
<daniels> xlib's locale support has defeated me for tonight; g'night
<daniels> lamont: correct
<tseng> bye daniels.
<luis_> <blink>
<luis_> computer is back?
<Amaranth> hmm
<Amaranth> if a GNOME release slips does Ubuntu's release slip too?
<mdz> Treenaks: I don't know what you mean, it has always loaded modules
<mdz> the ABI changes without warning, though, so you need to reboot after upgrading it
<Kamion> lamont: haven't noticed anything *break* yet ...
<mdz> Amaranth: possibly
<lamont> I thought he mentioned a dh_something that broke
<Kamion> that would be fun
<mdz> mvo: /etc/apt/apt.conf.d/99upgrade-notifier: FAILED open or read
<Treenaks> mdz: yes, on my last reboot it wouldn't work anymore
<mdz> working fine here
<Treenaks> mdz: no PCI stuff anymore, empty lsmod output etc.
<dieman> crazy. one of my users had a bug with matlab on ubuntu and the techsupport didn't do the 'your not running redhat!' response :)
<dieman> (64bit even)
* Mez yawns
<Mez> god... gnupg takes a long time to compile
<mvo> mdz: when did you got that message?
<mvo> mdz: oh, I see
<mdz> mvo: during my most recent upgrade
<infinity> lamont : I think you have to define a handler for each signal individually, like signal.signal(signal.SIGINT, handler_foo)
<infinity> lamont : But you can use the same handler for all, just just have to set them individually (in a loop or something, whatever, be creative)
<Mithrandir> dieman: amd64++ :-)
<tseng> Mithrandir++
<Mithrandir> *blush*
<mvo> mdz: it looks like dpkg prints it udring unpack ...
<mdz> mvo: oh, interesting
<mvo> mdz: but I haven't figured out more yet :/
<mvo> mdz: the message itself comes from md5sum, might be a bug in the conffile code of dpkg
<mdz> mvo: oh, dpkg started using coreutils md5sum instead of its own
<mvo> mdz: looking over the strace output it seems to use the systems tar now too
<lamont> Kamion: you around still?
<Kamion> lamont: yes
<Kamion> hooray, base-config all checked into arch
<Mithrandir> Kamion++
<Mithrandir> you rock.
<Mithrandir> (as usual :-)
<mdz> Kamion: saw your patch for doc-base; are you doing bootclean.sh as well?
<mdz> Kamion: re: base-config, yay!
<Kamion> mdz: hadn't noticed bootclean.sh, although I saw something fly by in the boot process; sure, I'll do that
<Kamion> (colin.watson@canonical.com--2005/base-config--ubuntu--0)
<mdz> Kamion: do we have all the history from svn?
<Kamion> yes
<mdz> ROCK
<Mithrandir> whoa
<Mithrandir> that's good
<Kamion>     Author: joeyh
<Kamion>     Date: 2000-01-06 20:57:52 GMT
<Kamion>     Initial checkin.
<mdz> lifeless: congratulations
<Kamion> through to patch-1171
<mdz> are you using hct, or doing it by hand?
<Kamion> and I merged everything by diffing against a source package, and applying diffs one by one in piecewise fashion, so I know the final result is OK
<Kamion> I haven't checked previous revisions
<Kamion> mdz: using baz for the moment
<mdz> did you break down the Ubuntu changes into branches?
<Kamion> no ...
<Kamion> just into patch-per-feature
<Kamion> it was too hard to work out what depended on what else, with that amount of stuff
<mez> ahh :D
<Kamion> mdz: sysvinit fixed; patch was already in the Debian BTS
<Kamion> (although I reinvented it byte-for-byte identical before noticing that)
<Kamion> night all
<mvo> night Kamion 
<mdz> Kamion: night
<sabdfl> night kamion
<sabdfl> really glad the import process is underway properly
<mdz> doko: should we just drop the dependency from xerces-j now?
<KaiL> stupid ATI driver :(
<mez> :P @ Kail :d
<mdz> I mean libxml-commons-resolvel1.1-java
<KaiL> has nobody ever told them, that there are People, who have Laptops?
<KaiL> and that those can't get linux drivers from the laptop vendor (as their excuse for windows is..)
<doko> mdz: yes, I'm currently preparaing an upload
<KaiL> not to mention, that these laptop vendors can also get no S3 compatible drivers :/
<mdz> doko: oh, ok.  I was just looking at it and it seems to build OK with java-gcj/ecj
<mdz> so we can change that at the same time
<doko> exactly
<mdz> doko: unfortunately it seems we have more packages still using kaffe which need fixing
<mdz> http://people.ubuntu.com/~cjwatson/germinate-output/breezy/rdepends/kaffe/kaffe
<mdz> with this java stuff it always seems that we are nearing the end, but we never quite reach it :-)
<doko> hmm, yes, looks like a longer evening ...
<Lathiat> hmm, esd sounds like ass with dmix stuff in ubuntu but polypaudio is good
<Lathiat> yet ive had esd working with dmix stuff fine before *humm*
<mez> hmm
<mez> if packages for breezy dont depend on a verison of any of it's depends, as long as all those depends exist in hoary, at some version, it can be used in hoary right?
<mez> no I'm being an idiot
<dabishop> has anyone had luck installing Haory on an iMac G5?
<sladen> dabishop: I believe it 'just works'
<mdz> there are some bug reports in bugzilla
<mdz> elmo: us.archive seems to be in some distress (again?)
<mdz> it's giving lots of 404s
<mdz> Kamion: breezy-live-amd64.iso came surprisingly close to working
* Mez yawns
<Mez> can i be botehred to install a breezy pbuild
<mdz> infinity: when you return, please see if you can help me explain this: http://people.ubuntu.com/~lamont/buildLogs/libd/libdate-manip-perl/5.44-1/libdate-manip-perl_5.44-1_20050608-2019-i386-successful.gz
<mdz> infinity: the .deb ends up missing everything but the stuff installed by debhelper; building it locally works
<mdz> infinity: the build log indicates that it is installing to debian/tmp for some reason, though the command line clearly points to debian/libdate-manip-perl
<katoc> hi!! i need to add packages to installation cd 
<\sh> hmmm..postgresql 7.5.4 is not in the archives :(
<ska-fan> 7.4.5?
<ska-fan> There is no 7.5
<\sh> Package: postgresql
<\sh> Binary: postgresql-contrib, postgresql-client, postgresql-doc, postgresql, postgresql-dev
<\sh> Version: 7.5.4
<ska-fan> There is no postgresql 7.5: http://www.postgresql.org/ftp/source/
<ska-fan> That must be a typo. But then again, who knows, maybe not.
<lamont> mdz: neato.
* lamont tries to remember what he needs to tell mozilla to open the .gz file inline
<lamont> mdz: current breezy in your build environment?
<Loki|muh> hi
<Loki|muh> I want to compile php4-mysql on my own because of segfaults corresponding to another package not in ubuntu. how can I do this without compiling all php?
<mdz> lamont: yes
<infinity> Yeah, works smashingly on an up to date system here.  Interesting.
<infinity> More to the point, I'm not entirely sure where it's pulling debian/tmp from.  Hrm.
<{Seb}> hi all
<{Seb}> any ideas when colony 2 will be released?
<mdz> {Seb}: it isn't scheduled yet; I expect we'll release one sometime after the live CD is back in working condition
<lamont> infinity: next try it with pkgstriptranslations turned on, and then gcc-opt
<{Seb}> i'm thinking of moving back to ubuntu from SUSE
<{Seb}> the only thing is that the kernel in Hoary ain't inotified
<{Seb}> two questions about breezy
<{Seb}> 1. will there be better bluetooth support?
<{Seb}> 2. will gnome 2.12 be included?
<{Seb}> 3. will the kernel be inotified
<JanC> gnome 2.12 should be AFAIK
<{Seb}> and also, what is the GNOME 10x10 thing i keep seeing everywhere
<infinity> lamont : Just tried it in a live chroot, same results.
<\sh> 10% of all Desktop Installations in 2010
<{Seb}> now that's a goal
<JanC> http://live.gnome.org/10x10
<lamont> live chroot?  == build-breezy-live/chroot-breezy?
<\sh> The Opposite of 90% of all Desktop Installation in 20010
<{Seb}> doesn't linux in general only have about 1%?
<azeem> there's a song by a german pop group which goes 'Meine Zeit wird kommen im Jahre 2010'
<infinity> lamont : No, as in "a real live buildd chroot".
<azeem> sounds like the appropriate soundtrack for GNOME
<infinity> lamont : build-breezy/chroot-breezy, on the buildd in question.  Built fine.
<infinity> lamont : How's that irritate you?
<{Seb}> i'm going to format my machine and move back to hoary
<doko> infinity, lamont: please kick sablotron to the buildd's again. a fixed cdbs is in the archives
<{Seb}> when colony 2 is released, i'll probally go up to breezy
<{Seb}> thanks gang
<{Seb}> bye all
<JanC> azeem : it's a good song ? :)
<infinity> doko : On it.
<mdz> {Seb}: the kernel in hoary does in fact have inotify, it's just disabled by default
<{Seb}> an old version though
<{Seb}> i'll talk again
<azeem> it rocks somewhat at least
<azeem> I like it
<{Seb}> once i've formated and back on ubuntu
<lamont> infinity: time to try it again on the actual buildd where it failed, eh?
<JanC> what band is this ?
<mdz> it was the latest version available at the time that Hoary released
<azeem> Echt
<JanC> yeah, just found it
<mdz> /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/X11R6/lib/libGLU.so, may conflict with libstdc++.so.6
<infinity> lamont : That was on the buildd it failed on. :/
<mdz> ^^ that's not a big deal, right?  because libstdc++ has versioned symbols?
<infinity> lamont : The only thing left is to do a build in REDO, but it should be identical to the by-hand build I just did.
<infinity> (will do anyway, for kicks)
<infinity> doko : kicked, BTW.
<doko> mdz: do you still b-d against xlibmesa-glu?
<doko> infinity: thanks
<mdz> doko: this is a package I am trying to make buildable on both hoary and breezy
<mdz> and was building on hoary
<lamont> mdz: buildd's will take first installable one (which _is_ diff than debian), so you could Build-Depend <breezy-pkg>|<hoary-pkg> where breezy's package doesn't exist in hoary
<mdz> the resulting package seems to work
<mdz> lamont: the trick is, it doesn't build with gcc-4.0 yet
<mdz> so I force it to 3.4
<mdz> which means the new ABI, both in hoary and breezy
<lamont> ah, neato
<doko> is this myth?
<mdz> yes
<Mez> mdz, if only that could be done in EVERYTHING until the transition was done proplery :D
<lamont> Mez: that just forces the transition
<mdz> it would be preferably to build with default gcc in hoary, I think
<mdz> preferable, even
<mdz> but that's non-trivial
<lamont> mdz: almost certainly
<doko> mdz: there are some apps in hoary/universe which may break ...
<Mez> :P
<infinity> Meh.
<lamont> does archive.u.c/ubuntu/dists/hoary-security accurately track security.u.c?
<\sh> X11/Xlib.h issue fixed in xorg -23? 
<infinity> lamont, mdz : It's either a heisenbug, or a transient bug that's since been fixed in some build-dep or other.  An automated rety on the same buildd also built the package properly.
<doko> \sh, no, look at the changelog ...
<\sh> doko: yeah...i was missing this entry
<mdz> infinity: that's _disturbing_
<infinity> mdz : Tell me about it.
<mdz> infinity: if you could make a new source upload and check that it builds properly, that'd be great
<\sh> doko: I've uploaded most of the stuff from Unfrgiven now all the things are missing concerning xorg issue...and ocaml.:(
<infinity> Will do.
<doko> daniels: any estimates, when xorg headers will be in the final place?
<doko> Kamion, mdz: http://people.ubuntu.com/~cjwatson/germinate-output/breezy/rdepends/kaffe/kaffe lists the alternatives as well, where kaffe is not the first alternative. so it lists a bit too much
<mdz> doko: ok, I'll re-germinate and see what happens
<mako> dholbach, tseng: dudes
<dholbach> mako: ?
<tseng> mako: dude.
<\sh> duderenos?
<mako> dholbach, tseng: http://mako.cc/outgoing/woman_test.png
<mako> that's an add i saw once
<\sh> the big lebowski..yeah...thats it...
<\sh> wow
<dholbach> hahaha! :)
<tseng> mako: nice!
<\sh> we can use it as "please use beagle to check"
<mako> i kept it because i thought it untrue
<mako> because it couldn't be more likely than i think when i knew i had HEAPS of pornography on my computer
<mdz> doko: xml-crimson still build-depends on kaffe
<tseng> well if you are a trusting middle age woman
<tseng> you might not suspect your husband to fill your computer with porn
<Nafallo> lol
<tseng> good thing beagle runs as a normal users
<tseng> *phew*
<Nafallo> hehe
<tseng> TAKE THAT HOUSEWIVES
<\sh> hmm
<\sh> that reminds me of one of my old customers
<mako> tseng: if you were married to me, you might
<mako> and i were married to any man, i would
<tseng> if you were sitting in your apartment and something was making a terrible buzzing noise for the last several minutes
<\sh> visit him at home...next day, I got a call of his wife.."Did u install this *censored* p0rn on our homecomputer?"
<tseng> would you get up and check it?
<mako> tseng: depends on how long
<mako> tseng: i would wait a few minuteds
<tseng> i think I will too.
<Nafallo> \sh: pervert
<Nafallo> ;-)
<infinity> doko : sablotron is still FTBFS... Trying patch debian/patches/00-relibtoolize.patch at level 0...1...2...failure.
<\sh> Nafallo: i didn't do anything..it was his p0rn
<Nafallo> \sh: that's what all those supporterguys say yes ;-)
<\sh> Nafallo: haha...yeah i know
<\sh> http://www.gamespot.com/news/2005/06/09/news_6127219.html
<mako> http://www.sexblo.gs/xxx/pornmath.gif
<\sh> Nafallo: this morning my colleague came to me, saw some nice chickitas on my desktop...and asked "where r ur pr0n movies". i said: not on this company laptop...*paus* they're at home on my portable 500tb usb3 hd"
<doko> infinity, jbailey: I'm lost ... it builds fine in unstable
<mako> that is the diagram from a patent for an algorithm that claimed to be able automatically detect porn
<Nafallo> \sh: hehe :-)
<mako> the picture of the naked women with (a) no nipples and (b) high-heals that appear to be part of her body is great
<\sh> http://kurioses.blogweb.de/archives/8-Sucht-jemand-Kontakt.html <- this will prevent pr0n at all
<mako> it's amazing how much that math *doesn't* work
<tseng> oh wow
<\sh> ah...
<chol> hi, is there any newer xorg debs than 6.8.2 availible?
<tseng> chol: the ones we have arent broken enough for your tastes?
<\sh> some of my colleagues wanted to known, to whom those jdub asses belonging ;)
<tseng> chol: because daniels will be awake again in a few hours
<jbailey> doko: Which package, sorry?
<chol> tseng, hehe, i've only found one thing that annoys me so far
<tseng> mako: so the beagle firefox plugin.. you can turn it off for porn sites
<tseng> mako: handy.
<chol> tseng, since my fastest ubuntu is 600mhz atm i'm not so keen on compiling
<chol> tseng, i'll get back later and ask daniels then, thanks
<doko> jbailey: sablotron
<Nafallo> tseng: beagle-firefox-what? :-)
<Nafallo> tseng: where can I get that thing? :-)
<tseng> Nafallo: sshhh
<\sh> mono-gnome-marriage
<\sh> gnome#
<tseng> read the beagle wiki.
<Nafallo> tseng: oki
<mako> tseng: i could have used that when i was 16 years old
<\sh> so if this is becoming the truth, then I understand why balmer and szulik ate together the last time
<jbailey> Feh.  Stupid mirror Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/s/sablotron/sablotron_1.0.2-4ubuntu1.diff.gz  MD5Sum mismatch
<Amaranth> us is having issues, isn't it?
<tseng> us mirror always has issues
<Amaranth> that's what someone was saying eariler
<Amaranth> i wish i could spell
<Amaranth> i blame being awake 25 hours
<jbailey> Amaranth: Right.  ca. points to us.
<LinuxJones> \sh, why is that... sorry I just joined ?
<\sh> LinuxJones: what?
<jbailey> doko: You're getting a failure on relibtoolise applying?
<infinity> jbailey : Yup.
<LinuxJones> \sh, about Ballmer and Szulik having lunch 
<\sh> LinuxJones: u mean "balmer and szulik eating together"?
<LinuxJones> :)
<jbailey> infinity: Aren't you supposed to be asleep?
<jbailey> doko: Looks like a bad clean pass happened at some point.  Want me to fix and upload?
<\sh> LinuxJones: w8...i will give u some infos
<LinuxJones> \sh, ok
<infinity> jbailey : Haven't slept yet.  Fully plan to very soon.
<\sh> LinuxJones: http://www.eweek.com/article2/0,1759,1823449,00.asp
<doko> jbailey: yes, if you have the sources already on your disk
<jbailey> Yup, I've got it here and tested the build.
<jbailey> The libtoolise patch is a bit confused.
<Nafallo> tseng: damn. this is kewl! :-)
<doko> ouch, found a fastjar bug ...
* lamont_r tries to remember if we liked isakmpd or racoon better
<Mithrandir> ogra: how's bergen?
<ogra> Mithrandir, GRR
<ogra> i'm stuck in amsterdam
<ogra> sitting in the ibis hotel... KLM fucked up all fligh plans...
<Mithrandir> ogra: ew :(
<Mithrandir> that sucks.
<Mithrandir> like, royally.
<ogra> absolutely...
<infinity> mdz : New source upload built fine.  I'm off to bed, finally.
<mdz> infinity: night
<ogra> i missed my filght at 12 because of a accident on the motorway (was stuck about an hour).....
<ogra> so i rebooked to the next flight at 5pm
<ogra> nicely they delayed this one for over an hour, just after i checked in
<ogra> when i arrived here, i could just see the flight to bergen leaving
<mvo> hey ogra 
<ogra> the only funny thing is, that the captain told us _why_ actually the filght was delayed....
<ogra> on the 12:00 flight (where i was supposed to be on) they had a engine breakdown... (it was the same plane).....which they "fixed quickly" (his words)
<ogra> btw, it was a 50ppl plane with propellers :)
<ogra> hey mvo 
<jbailey> doko: Done, I'll check on it when I get back from the gym.
<doko> jbailey: stop!
<jbailey> doko: Err.. I've already dput'd.
<doko> jbailey: no, does liblog4j-java look ok?
#ubuntu-devel 2005-06-18
<doko> mdz: once liblog4j1.2-java is in the archives, you could try to run germinate again
<mdz> doko: ok
<dholbach> good night
<mkde> night dholbach
<ogra> night dholbach 
<dholbach> *wave*
<calc> jdub: i see you are presenting at oscon :)
<jdub> calc: yeah
<calc> i noticed microsoft is on the sponsor list, funny stuff :)
<jdub> ooh, i should say something controversial
<jdub> SPONSOR THIS!
<jdub> (moons audience)
<maswan> heh. microsoft sponsored the grid conference I went to this spring. grid in this case means linux clusters talking with eachother. the first words from the microsoft guy that talked: "I come in peace"
<maswan> http://www.acc.umu.se/~maswan/bilder/20050419-EGEE.gr/index.html?view=IMG_3734.JPG
<maswan> also, take a look at the face of the microsoft booth person. rather bored after 3 days and noone talking to her, perhaps?
<trulux> once you toggle the menu off in gnome-terminal, how you get it back?
<jdub> trulux: there's a checkbox in the context menu
<Nafallo> maswan: hehe
<trulux> jdub: I can only see the tabs but no menu, and dunno how to get it back ;)
<jdub> trulux: right click for the context menu
<trulux> oh, yup
<trulux> jdub: many thanks
<maswan> But hey, we didn't have to pay for the lunch buffets, so we shouldn't complain. :)
<Amaranth> hahaha
<Amaranth> maswan: nice
<Nafallo> :-)
<Amaranth> damn jhbuild takes a long time
<Amaranth> stupid 1.2Ghz Duron machine
<Amaranth> building with gcc 3.4 even, so it's super painful
* Mez slaps amaranth a bit
<tseng> Mez: ..
<Mez> hey tseng
<tseng> hi.
<Mez> :D
* Mez gets bored
<jdub> daniels: ping
<tseng> jdub: ping
<tseng> he went to bed only a few hours ago
<jdub> oh
<tseng> gar im going to write a canned statement about the mono backport soon
<tseng> this is getting old.
<schweeb> you're getting old
<schweeb> :p
<tseng> not as old as you!
<schweeb> I'm 21!
<tseng> mr. senior tape backup
<tseng> I'm 20!
<tseng> schweeb: a/s/l?
<schweeb> you're a bish
<schweeb> I'm definitely goin bar hopping tonight
<schweeb> yay
<Mez> tseng - you sound like an AOLer
<tseng> Mez: except I do it as a joke
<Mez> tseng, I know... as was my comment
<Mez> god I'm bred
* lamont_r heads home
<stuNNed> mdz: welp, w/no firewall enabled connected to uni's wifi network nothing happens and all is well, thanks, so it is universe firewall related (#10090)
<Mez> anyone here on breezy with KDE willing to test a package for me/
<mdz> fabbione: my machine still requires irqpoll with the latest 2.6.12
<Mez> mdz, you're running breezy I assume ? (somewhere)
<Amaranth> are there any known issues with the hoary live cd on vmware/vpc?
<jnc> massive update action going on lately
<jnc> wowzer
<|QuaD-> hah
<|QuaD-> it still didn't fix x :(
<jnc> what's wrong w/ x?
<|QuaD-> jnc: have you upgraded and rebooted?
<jnc> nope
<|QuaD-> it messes with the font
<jnc> gah
<|QuaD-> something with fonts
<jnc> good thing it's a weekend
<|QuaD-> why?
<jnc> i'm getting an error about MD5 sums
<|QuaD-> lol
* jnc <-- work machine
<|QuaD-> oh
<jnc> call me crazy, it's amd64 box and i needed openoffice to print
<jnc> so i threw breezy on it
<jnc> W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/x/xscreensaver/xscreensaver_4.21-4ubuntu4_amd64.deb
<jnc>   MD5Sum mismatch
<jnc> pardon the paste
<jnc> what have i missed?
<Amaranth> /topic #ubuntu
<Mez> Amaranth, you there?
* jnc /joins #ubuntu
<jnc> oh, what's that got to do with MD5 sums
<Amaranth> the mirror is messed up
<Amaranth> use a different mirror
<Amaranth> uk works
<jnc> okay
<jnc> eh i guess i'll wait until it works again, uk doesn't seem to like me
<jnc> |QuaD-: fonts look okay
<|QuaD-> jnc: X won't start i don't think
<chol> daniels, are you awake? i'm looking for some newer debs of xorg to see if they can cope with an hpux xfs
<Nafallo> mono == love
<Nafallo> or rather
<Nafallo> mono == porn ;-)
<|QuaD-> therefore, mono == love == porn
<|QuaD-> which means love == porn
<|QuaD-> which means, why get married when you can watch porn?
<Nafallo> :-D
<jnc> |QuaD-: works here
<|QuaD-> jnc: you restarted?
<jnc> yes
<Nafallo> holy smokes! I'm out of memory+swap
<Nafallo> 2GB :-P
<|QuaD-> jnc: here it doesn't work
<|QuaD-> jnc: it was a known problem
<jnc> |QuaD-: nuts to your known problem
<|QuaD-> jnc: maybe it is the repo i am using?
<|QuaD-> archive.ubuntu.com
<jnc> could be
<jnc> Nafallo: yeah i've been getting that on my amd64 box here
<jnc> no idea why
<jnc> eventually i have to close evolution to start anything else
<jnc> it's hauntingly similar to win95 back in the day when you rebooted it 'cause of memory leaks
<Nafallo> jnc: using mono?
<Nafallo> jnc: i.e. beagle + f-spot
<tseng> im not sure beagle is a mem leak
<tseng> people seem to underestimate the daunting task that indexing gig after gig of files is
<|QuaD-> tseng: it used up my mem
<|QuaD-> i was able to index before this
<tseng> i can always index
<tseng> i guess it likes me.
<|QuaD-> tseng: haha
<|QuaD-> no memory leaks for you :)
<|QuaD-> are you using the packages you created for breezy?
<tseng> yes
<|QuaD-> oh
<tseng> are you?
<|QuaD-> yes
<tseng> k
<Nafallo> my laptop frooze ;-)
<jnc> Nafallo: nah, just normal office stuff.  evo, OOo, ff, gt
<Nafallo> jnc: ahh. that problem I don't have :-).
<tseng> Nafallo: EZ GTK BOOG
<Nafallo> hehe
<daniels> jdub: pong
<daniels> doko: i'm waiting for colony 2 to be released before I drop all the new stuff in
<Mez> hmm
<daniels> chol: nothing's changed in that regard, sorry
<Mez> I've just changed a line in a config file for konversation to change the autojoin channel #kde to autojoin #kubuntu
<Mez> and it#'s not working
<Mez> that shouldnt break it should it
<Mez> It's the only thing I chnaged
<Mez> and worked fine before I changed that one teeny thing
<Mez> any dieas anyone
<bob2> reverting "fixes" it?
<bob2> put your diff up somewhere
<Mez> http://www.thewock.com/ubuntu/breezy/konversation_0.18-1ubuntu1.diff.gz
<Mez> bob2, cna i pm?
<bob2> no ideas, sorry
<tseng> bob2: this train is for cockfosters.
<bob2> so, there's a road here..woodcock drive.
<tseng> oh man
<bob2> I'd like it moved closer to the airport for new arrivals to appreciate.
<Mez> hmm
<Mez> how to make a .dev when pruged rmove configs from users home dir?
<Mez> that arent included when installed first time
<thoreauputic> Amaranth: can we have an op in #kubuntu?
<Amaranth> i'm not an op there
<daniels> thoreauputic: what's the problem?
<thoreauputic> daniels: a troll, racist, blah blah
<thoreauputic> spamming the chan
<thoreauputic> thanks, daniels 
<Mez> thanks whoever you are (I assume fooishbar!)
<Mez> or thats a pseudo account
<daniels> Mez: fooishbar is linked to my nick, yeah
<Mez> fair enough
<Mez> anyways
<Mez> I think I'm going to bed now i sorte dout the konv problem (it was a crappy rc file
<wasabi_> is laptop sleeping expected to be working currently? (is it just me who can't wake up?)
<bob2> depends on the laptop
<bob2> works on most hp and ibm's
<wasabi_> ibook. ;0
<bob2> should work fine
<bob2> g3s have worked for years
<bob2> g4 since end of last year
<wasabi_> thanks. long as I know that i'll keep trying.
<stevedog> i can't install Hoary (or Warty) on my G5 iMac, its saying "cannot find common CD-Rom"
<blahrus> when I go to install beagle, it wants to remove firefox . . . any ideas?
<blahrus> this is in breezy
<bob2> ...
<bob2> it's breezy, it's not supposed to work!
<blahrus> yes yes, please don't give me that lecture, i know this, I can here to see if anyone else was aware of this
<blahrus> came* here
<bob2> nothing in the bts?
<stevedog> i can't install Hoary (or Warty) on my G5 iMac, its saying "cannot find common CD-Rom"
<blahrus> bob2: nothing I saw
<jdub> daniels: around?
<daniels> jdub: REPRESENT
<jdub> aye aye
<jdub> http://people.ubuntu.com/~jdub/random/xorg-ate-my-keyboard.txt
<jdub> fully up to date
<daniels> jdub: just call me captain birdseye
<daniels> jdub: so, if you SSH in and run xev, and give it focus with the mouse
<daniels> jdub: do you get nothing whatsoever for normal keys, but control and shift are mapped properly?
<bob2> daniels: is the "monitos on nvidia cards don't get setup correctly" fix the same as for i810?
<blahrus> jdub: those were the errors I got :)
<jdub> blahrus: you can't type?
<daniels> bob2: what was the fix for the former?
<bob2> daniels: run ddcprobe, find the v/h syncs, put them in x.org.conf manually
<jdub> daniels: ouch, xev gives me nothing
<daniels> jdub: is it focussed wit hthe mouse?
<daniels> bob2: XORG_SYNC_RANGES=yes sudo dpkg-reconfigure -phigh xserver-xorg
<jdub> daniels: i get more output by running X alone, btw
<blahrus> no I can type, I just updated to the new xorg
<blahrus> I just did an update like 2secs ago
<jdub> daniels: yes, it's getting mouse events
<jdub> expected keysym, got XF86_Switch_VT_1: line 8 of xfree86
<jdub> expected keysym, got XF86_Switch_VT_2: line 11 of xfree86
<jdub> expected keysym, got XF86_Switch_VT_3: line 14 of xfree86
<jdub> ...
<daniels> jdub: ok, do you get any output from control and shift?  or no key on the keyboard at all
<jdub> The XKEYBOARD keymap compiler (xkbcomp) reports:
<jdub> > Warning:          Multiple interpretations of "NoSymbol+AnyOfOrNone(all)"
<jdub> >                   Using last definition for duplicate fields
<jdub> 
<daniels> jdub: woah, what the shit
<jdub> ^ stuff like this in X output
<jdub> ooh, i get ctrl and shift
<jdub> and alt
<daniels> jdub: sweet
<daniels> jdub: your task is to figure out which of /usr/lib/X11/xkb, /usr/X11R6/lib/X11/xkb, and /usr/share/X11/xkb needs to be added as a symlink to /etc/X11/xkb
<jdub> ha ha
<jdub> jdub@ubuntu:~$ find /usr/lib/X11/xkb
<jdub> /usr/lib/X11/xkb
<jdub> BIM-BOW!
<daniels> is it a symlink?
<jdub> yes
<jdub> to /etc/X11/xkb
<daniels> jdub: what about /usr/X11R6/lib/X11/xkb?
<jdub> as is /usr/X11R6/lib/X11/xkb
<jdub> /usr/share/X11/xkb DOES NOT EXIST!
<jdub> WE HAVE A WINNER!
<daniels> try making that as a symlink and restarting X
<daniels> if it doesn't work, I'm going to be very disappointed, because that's what fixed it for me
<daniels> although I'm using a new, crazy, libX11 on my desktop
<jdub> ...
<daniels> not working?
<jdub> hold on, doing it with just X
<jdub> still get all those errors
<daniels> argh
<jdub> same thing
<jdub> i'll reconfigure and try again
<daniels> jdub: ok, for some reason the symbols aren't being found
<daniels> you definitely have /etc/X11/xkb/symbols with lots of files in it?
<daniels> including ... srvr_ctrl
<jdub> lots of files
<jdub> $ find /etc/X11/xkb/symbols/ | grep ctrl
<jdub> /etc/X11/xkb/symbols/ctrl
<jdub> /etc/X11/xkb/symbols/srvr_ctrl
<daniels> argh
<jdub> btw, why are we bothering to go modular for this release?
<daniels> because it will make updating everything no longer hard
<daniels> the monolithic tree is a serious pain in my arse
<daniels> in terms of maintaining it both throughout the development cycle and when released
<jdub> mmm
<daniels> this isn't a modular-tree fuckup, btw
<daniels> i haven't got to touching xkb yet
<jdub> heh
<daniels> this will be a /usr/X11R6 -> /usr problem
<blahrus> jdub: sorry to interupt, but are you Jeff Waugh?
<jdub> blahrus: yes
<jdub> i don't think you're interrupting though
<jdub> daniel is eating caviar or something
<blahrus> cool, i just bored reading through planet.gnome.com
<blahrus> saw Jeff Waugh . . .
<blahrus> and jdub under it . . .
<jdub> you were *bored* while reading planet gnome?
<jdub> you came to tell me this?! ;-)
<blahrus> hahahah
<blahrus> I mean I was done planing online poker for the night, and not ready to watch a movie
<blahrus> that sound better :)
<jdub> heh
<bob2> jdub: you're a celebrity!
<jdub> i'm a floating head.
* bob2 gets out the fish food
<blahrus> in the geeky world yea :) (still reading blogs trying to find what he does)
<blahrus> :)
<blahrus> well if that the case all the planet.gnome guys are
<daniels> jdub: oh man
<daniels> jdub: i want caviar now.  damnit.
<daniels> jdub: (not yet eaten today.)
<jdub> stop thinking of fish babies and help fix my X ;)
<blahrus> well its night time here, good luck with x
<daniels> jdub: yeah, I'm trying to work through it
<daniels> jdub: i've got no idea, sorry, and need to head off now
<jdub> ok
<Mez> hmm anyone here want to sponsor my gaim breezy 1.3.1 package?
<Riddell> Mez: gaim??  I thought you were doing konversation!
<Mez> I did gaim aswell
<Mez> I was bored
<Mez> anything i backport that isnt in breezy I compile for breezy too
<Mez> :P
<Mithrandir> well, gaim just needs a merge.
<Mez> yeah thats what I've done :d
<Mez> so if anyone wants to sponsor it
<Mez> lemme know
<zyga> hello
<zyga> what are the chances of commiting a translation for a totally untranslated package (for a given language) into hoary?
<pitti> Hi
<Nafallo> hi pitti :-)
<AndyFitz> damn  I've got apps compiling but not executing again
<Mez> lo
<AndyFitz> hows C++ stuff in breezy ?
<Mez> l
<AndyFitz> nevermind
<AndyFitz> :)  time to have some fun ;)
<Keybuk> ooh-err
<Mez> evening keybuk
<Keybuk> afternoon
<Mez> btw, out of curioity, whereabout sin birmingham do you live
<Mez> that's if you dont mind me asking (and i'll understand if you do)
<_konrad> what are you plannig for next release? I read how-to, but it is too long to be true? I know ablout d-nut, new kernel, something BIG more?
<Nafallo> _konrad: http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<_konrad> Nafallo: but it is too good to be true :)
<Keybuk> Mez: Bordesley Green
<Keybuk> not exactly the most fashionable area ;)
<Nafallo> _konrad: stuff might still get deferred.
<Mez> lol - Keybuk - sounds better than me
<Keybuk> where abouts are you?
<Mez> I'm living next to the spaghetti junction (literally)
<Mez> (aka erdongton)
<Mez> btwm, has the C+_+ transition been completed yet
<\sh> no
<Keybuk> ah right, I know Erdington
<AndyFitz> evening keybuk
<Keybuk> AndyFitz: eh-oh
<AndyFitz> how goes the UK morning ?
<jsgotangco> AndyFitz, hey
<AndyFitz> jsgotangco, hi mate
<jsgotangco> AndyFitz, how goes the weekend
<AndyFitz> long weekends are always good. ;)   I'm back from a friends 21st quite early actually.  so its a lazy one .   how's yours going?
<jsgotangco> not bad, i had a few pints with some friends i just logged in to reply to emails and svn
<jsgotangco> btw, are you still doing that icon set
<Nafallo> gaah
<Nafallo> my colume up/down buttons are screwed since yesterday.
<Nafallo> they seem to change style of the desktop instead :-/
<jsgotangco> heh
<jsgotangco> oh well good night all and enjoy the weekend
<AndyFitz> jsgotangco, yes.  and ciao!
<Keybuk> AndyFitz: is afternoon here now
<Keybuk> m4/libs.m4:47: error: m4_defn: undefined macro: _m4_divert_diversion
<Keybuk> autoconf/general.m4:1442: AC_ARG_VAR is expanded from...
<Keybuk> m4/libs.m4:47: the top level
<Keybuk> autom4te: /usr/bin/m4 failed with exit status: 1
<Keybuk> ...
* Keybuk looks that up in the translation
<Keybuk> ah yes "you forgot a [ at the start of a defun"
<Mez> lol - Keybuk, lucky you, I dont know Erdingotn and I live here
<Keybuk> sometimes I think tla got its error reporting from autoconf :p
<toresbe> Has anyone heard of Ubuntu CD's delaminating?
<toresbe> my Warty live is delaminating 
<Keybuk> AndyFitz: btw, I'm naming the next dpkg release after you :p
<AndyFitz> Scott,   there's a dodgy reason behind it I'm sure 
<Keybuk> not especially.  Jeff made me name 1.13.9 "In like Flynn", so the only logical name for 1.13.10 is "On like Donkey Kong" <g>
<Mez> lol
<lamont-away> cd ../../exports/lib && ln -s ../../lib/Xss/libXss.a .
<lamont-away> *** glibc detected *** corrupted double-linked list: 0x0006f948 ***
<lamont-away>  /bin/sh: line 1: 27741 Aborted                 make -C $i -w all
* lamont-away glares at daniels
<lamont> daniels: not because it's your fault, mind you
<Burgundavia> jdub, ping
<siretart> c++ gurus: is partial specialisation of function templates really not possible with g++?
<Mez> find: ./debian/konversation/usr/share/locale: No such file or directory
<Mez> dh_builddeb: command returned error code 256
<Mez> make: *** [binary-makedeb-IMPL/konversation]  Error 1
<Mez> ******************************************************************************
<Mez> Build finished at 20050611-1550
<Mez> FAILED [dpkg-buildpackage died] 
<Mez> GRR
<ogra> hmm, can someone xplain this ?
<ogra> ogra@honk:~ $ lsmod |grep nvidia
<ogra> ogra@honk:~ $ glxgears
<ogra> 1390 frames in 5.0 seconds = 278.000 FPS
<KaiL_> nvidia-driver not loaded?
<ogra> not even installed
<ogra> since i use breezy
<ogra> (there is no l-r-m package yet)
<KaiL_> that's why you get softare rendering
<KaiL_> so where's the problem?
<ogra> normally it shouldnt render at all....
<KaiL_> why?
<ogra> i never saw a nvidia card rendering any 3D stuff with the nv driver
<KaiL_> it doesn't
<KaiL_> the CPU does
<Lathiat> yeh you can do softwre gl
<ogra> argh, damned... sure....
<Lathiat> positive
<Lathiat> at 278 fps
<Lathiat> it so software gl
<Lathiat> :D
<ogra> nvidia-glx exchanges the mesa libs...
<Lathiat> dun matter
<Lathiat> it just works
<KaiL_> yes, and this exchanged file is, what breaky software render
<ogra> (in fact its the only content of this package)
<Lathiat> thats alli can tell you
<ogra> KaiL_, exactly :)
<ogra> i was just astonished to get no error abou missing glx... but normally i have the nvidia driver installed to be able to switch if needed :)
<KaiL_> we should provide 2.6.12 packages for hoary after it gets released, including new X drivers
<KaiL_> the 2.6.10 starts to become problematic, esp. the hd audio on Centrino2 Laptops
<ogra> huh ? why that ? did the HW change ?
<KaiL_> it's totally unsupported
<ogra> so it is brandnew ?
<KaiL_> yes
<ogra> then lets support it with the brandnew release ;)
<pitti> hi
<KaiL_> Centrino2 started to sell in April
<ogra> hey pitti 
<ogra> KaiL_, sure... and we will support it in oct...
<KaiL_> quite bad imho
<Mez> hey pitti
<ogra> not as bad as breaking a stable distribution :)
<zyga> centrino2? 
<zyga> what's that ;] 
<KaiL_> I only thought about an optional 2.6.12
<KaiL_> zyga: intel i915 Chipset, 533MHz FSB, HD Audio...
<zyga> googling
<ogra> KaiL_, and how do you make sure udev, HAL, hotplug, the soundserver, pcmcia ..... etc pp work safe with it ?
<KaiL_> ogra: that's why I said _optional_
<KaiL_> as the kde 3.4.1 on kubuntu.org
<KaiL_> and I already have the breezy kernel installed on several hoary systems - to fix kernel related problems
<ogra> KaiL_, thats like backporting glibc from breezy to hoary
* jbailey blinks.
<KaiL_> bad enough, that I don't have such a laptop to see, if the kernel alone is enough
* jbailey scrolls back and reads.
* Mithrandir tickles jbailey 
* siretart would be happy with a hoary kernel with updated ipw drivers for supporting wpa
<KaiL_> ipw2100 or 2200?
<siretart> KaiL_: ipw2100
<Lathiat> but isnt the 2100 802.11b which doesnt do wpa?
<Lathiat> i thought that was an 802.11g thing?
<siretart> Lathiat: wpa seems to work with newer ipw2100 drivers (according to the wpasupplicant readme)
<Lathiat> interesting
<siretart> I suspect that the firmware in hoarys kernel don't support wpa. but i'm not sure
<KaiL_> the ipw drivers in hoary are both very old
* #ubuntu-devel  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
<siretart> what kernel is currently (actually and targeted) in breezy?
<Burgundavia> siretart, 12 is targeted, if it releases in time
<siretart> Burgundavia: are you a member of the kernel team?
<Burgundavia> no
<Riddell> pitti: do you know what's happened with the build of konversation 0.18?  "pkgstriptranslations: processing control file.... find: ./debian/konversation/usr/share/locale: No such file or directory"
<pitti> Hi Riddell 
<pitti> hm, no, didn't see that
<Seveas> Quick question: where can i find the e-mailaddress of the us.archive.ubuntu.com maintainer? The server has been erroneous for more than a day now...
<Amaranth> it's a known problem
<Amaranth> meaning these guys know :)
<Seveas> Amaranth, i know :)
<Seveas> then why don't they fix it ;)
* Seveas runs & hides
<Mez> when it's being built does debian/konversation exist?
<pitti> Riddell: I think I know what's going on, I just wonder why it doesn't fail for other packages that don't come with translations...
<Mez> pitti: what do you think's up
<pitti> Mez: a bug in pkgstriptranslations
<pitti>     if [ "$dostrip" -a -z "$blacklisted" ] ; then
<pitti>         find "$PKGDIR/usr/share/locale" -type f -name "*.mo" -exec rm '{}' \;
<Mez> sounds.. fun
<Mez> sounds like it's going to be a pain in the ass to fix
<pitti> i. e. if $PKGDIR does not contain a locale directory, find exits with -1 and thus pkgstriptranslations (and the build) fails
<Mez> well, to get into the builder
<pitti> Mez: no, fixing is trivial
<Mez> but to get it into the builder?
<pitti> Mez: I upload a fixed pkgstriptranslations and as soon as it's in the dchroots, we give-back the konversation build
<pitti> Mez: the dchroots are updated automtatically daily
<pitti> oh, now, there already is a check
<pitti>     [ -d "$PKGDIR/usr/share/locale" ]  || continue
<pitti> that makes sense, otherwise the build would fail for hundreds of packages...
* pitti looks at stripped tarball
<Mez> so i didnt screw up in building it?
<Mez> making the package *
<pitti> Mez: no, I don't think so, but let's debug this first
<pitti> hm, eariler versions had plenty of *.po files
<pitti> or, rather *.mo in /usr/share/locale
<pitti> hrm - WTF???
<jdub> Keybuk: boggle, you called it "in like flynn"?!
<Riddell> pitti: my local chroot build of that konversation 0.18 package has lots of .mo file in /usr/share/locale
<Keybuk> jdub: yes
<jdub> ha ha
<Keybuk> s/jdub/daniels/
<Keybuk> think-o
<Keybuk> actually, no
<Keybuk> it was you :p
<Keybuk> Jun 10 07:30:57 jdub    Keybuk: release name "in like flynn"
<Keybuk> daniels just explained it <g>
<jdub> oh
* Mez pbuilt it so i didnt have a chroot
<pitti> Riddell: do you have a readily built version on your hd?
<Mez> I have .debs
<Mez> well a .deb for i386
<pitti> Riddell: if so, then it's quicker to debug
<pitti> Mez: well, for debugging we need a readily built tree
<Mez> ah 
<Mez> fair enough
<pitti> I can also build it myself, but if you already have it, it's faster
<Riddell> pitti: yes
<pitti> Riddell: can you please sudo apt-get install pkgstriptranslations
* Mez only has the backported version
<pitti> Riddell: and enable it in /etc/pkgstriptranslations.conf?
<Mez> nvm
<Riddell> pitti: done
<pitti> Riddell: now please go into the build directory
<pitti> Riddell: and do "sh -x /usr/bin/pkgstriptranslations 2>&1 > ~/strip.out
<seb128> hey pitti 
<pitti> Hi seb128 
<seb128> pitti: you broken language packs
<pitti> seb128: did you notice that some translations are now missing?
<pitti> seb128: hehe, same thought :-)
<pitti> seb128: I have some English menu entries
<Riddell> pitti: http://dev.kubuntu.org.uk/~jr/kubuntu/strip.out
<Riddell> there was a lot of output which wasn't caught with that command
<pitti> Riddell: d'oh, so that worked?
<pitti> Riddell: oops, right, the redirection commands need to be swapped
<seb128> pitti: gnome-panel has no .mo with your new language pack
<pitti> can you copy&paste the rest?
<Mez> 1>&2
<seb128> pitti: some french guys kicked me this morning :p
<pitti> seb128: this was the first time I built langpacks only out of stripped tarballs
<pitti> seb128: kick him back and yell "development version" :-)
<pitti> seb128: but they should now have evolution translations for exchange :-)
<seb128> yeah :)
<Riddell> pitti: http://muse.19inch.net/~jr/tmp/strip-output.text
<pitti> Riddell: did the command succeed?
<Riddell> pitti: it returned 0
<pitti> grumble
<pitti> Riddell: so it actually works, kthxbye :-)
<pitti> no, seriously, that puzzles me
<pitti> it explicitly checks that the directory is there
<Treenaks> any gpg gurus around?
<Treenaks> (or keyserver fanatics)
<Mez> Treenaks, #gnupg
<Treenaks> Mez: good one :)
<Mez> soo... any ideas pitti
* pitti stares at the build log and pkgstriptranslations source and has NFC
<Mez> pkgstriptranslations: processing control file: ./debian/konversation/DEBIAN/control, package konversation, directory ./debian/konversation
<Mez> /build/buildd/konversation-0.18/debian/konversation /build/buildd/konversation-0.18
<Mez> /build/buildd/konversation-0.18
<pitti> yeah, that's the pushd/popd
<Mez> yeah, bu why the same dir twice?
<jdub> daniels: ping
<pitti> Mez: hm?
<Mez> It lists /build/buildd/konversation-0.18 twice...
<Mez> si it meant to ?
<pitti> Mez: oh, pushd prints out the old and new dir (first line), popd only the old dir (2nd line)
<Mez> ah
<jdub> hrm, i guess it's unlikely that he's up
<Mez> could it be somehow that it's picking up the wrong variable somehow and installing to another dir rather than the local dir
<pitti> Mez: the first find command that puts the mo files into the tarball works fine
<Burgundavia> jdub, I pinged you eariler, but we had some network issues
<Mez> but ... ?
<pitti> Mez: it must be the second or third one that remove the mo files and directories from the package directory
<Mez> hmm/.... so how to fix?
<Burgundavia> jdub, I was asking regarding the new them from Andyfitz
<jdub> Burgundavia: mm?
<Mez> and i didnt think find actually... moved anything
<Burgundavia> jdub, had a user suggesting a theme, but I didn't know when the his new stuff was going to land
<Burgundavia> http://www.ubuntuforums.org/showthread.php?t=40947
<pitti> Mez: as long as we can't reproduce this, I can't fix it...
<pitti> Riddell, Mez: I try again to build in a breezy dchroot
<Mez> /usr/bin/install -c -p -m 644 konversation.gmo /build/buildd/konversation-0.18/debian/konversation//usr/share/locale/zh_CN/LC_MESSAGES/konversation.mo
<Mez> grr
<Mez> pitti - I built in  a breezy chroot, through pbuild, ridell built in just a general chroot.
<Mez> it must be something that our build scrits dont do that the server does
<pitti> Mez: most likely you don't have an activated pkgstriptranslations
<Mez> yes, but if riddell just tried with one
<pitti> Riddell, Mez: building the package now...
<pitti> Mez: I mean, I can just add a "|| true" after the find commands, but I'm more interested in the actual cause
<Mez> yeah i understand pitti
<Mez> am gonna save you a copy of my build log
<Mez> ;)
<zyga> how is X transition going on?
<Mez> pitti, do you want me to do a build with pkgdtriptranslations enabled?
<pitti> Mez: the build finished (and I'm back), lemme try
<Mez> so - if the build finsihed
<pitti> (build without stripping)
<Mez> was that with pkgstriptranslations?
<pitti> I'm doing that manually now
<Mez> ah fair enough
* Mez just tries a build
<Mez> a full build
<Mez> but i'm sure you know what you're doing more than me
<pitti> find: ./debian/konversation/usr/share/locale: No such file or directory
<pitti> aaaah
<Mez> lmao
<pitti> "lmao"?
<Mez> or not
<Mez> It's just annoying ... these things
* pitti does not know what "lmao" means
<Mez> laughing my ass off
<pitti> ah
<pitti> that's also interesting:
<pitti> "find: warning: you have specified the -depth option after a non-option argument -type, but options are not positional (-depth affects tests specified before it as well as those specified after it).  Please specify options before other arguments.
<pitti> "
<pitti> I didn't see that in the build log
<pitti> that might be the reason
<Mez> o_O
<Mez> fair enough
<zyga> "find: warning: today is a full moon, please wait till tommorow"
<Mez> yeah pitti
* pitti never saw that warning before
<Mez> I jsut ran with striptaslations enabled,
<Mez> and it cocked up
<tseng> zyga: yeah i swear somedays i can do find /path -name *.foo
<tseng> zyga: and other days i have to quote it
<tseng> '*.foo;
<tseng> '*.foo'
<Mez> http://www.sourceguru.net/ubuntu/build.out.txt
<zyga> why do we have find with that ackward syntax again?
<pitti> that feels sooo buggy...
<pitti> $ find ./debian/konversation/usr/share/locale -type d -empty; echo $?
<pitti> ./debian/konversation/usr/share/locale
<pitti> 0
<pitti> $ find ./debian/konversation/usr/share/locale -depth -type d -empty; echo $?
<pitti> find: ./debian/konversation/usr/share/locale: No such file or directory
<pitti> 1
<Mez> ouch
<pitti> so as soon as I specify -depth, it fails if the directory is empty
<Mez> what about
* pitti kicks find very hard
<Mez> ind ./debian/konversation/usr/share/locale -depth -type d -depth -empty; echo $?
<pitti> twice?
<Mez> I mean
<Mez> find ./debian/konversation/usr/share/locale -type d -depth -empty; echo $?
<Mez> after -type
<pitti> Mez: erm, that's what I did before, and find complained about the position of -depth
<Mez> ah
<pitti> <pitti> "find: warning: you have specified the -depth option after a non-option argument -type, but options are not positional (-depth affects tests specified before it as well as those specified after it).  Please specify options before other arguments.
<zyga> pitti: find: error, complaint not found
<Mez> pitti: sounds like a big
<Mez> bug ?
<pitti> indeed
<Mez> are you setting a maxdepth
<Mez> ?
<pitti> no
<pitti> the directory is *empty*
<Mez>        -depth Process each directorys contents before the directory itself.
<Mez> ah
<Mez> so it is the feckong thing
<Mez> its a find bug
<Mez> whee
<zyga> you've found a found bug
<zyga> amazing :-)
* zyga has a really good mood today
<Mez> grr
<chol> daniels, i've debootstrap'd an ubuntu and will try to build 6.8.99.10 using your scripts
<pitti> Mez: ok, I do the || true workaround and report it to Debian
<Mez> and whoever makes findutils?
<pitti> Mez: oddy enough that does not happen on my machine
<Mez> waht doesnt?
<Mez> the bug?
<pitti> yes
<pitti> and it works fine on Hoary
<pitti> just not in Breezy
<Mez> yeah, I think it's prob something to do with the unstable version of findutils
<Mez> (which is still in testing)
<jdub> the findutils changes are really annoying
<Mez> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=findutils
<pitti> jdub: are there more breakages?
<Mez> I guess it only happens on things with nothing in locale
<pitti> ah, that could be
<pitti> hm, no
<Mez> try dropping a fake file in there pitti, and see what happens with that find command
<Mez> ah you obv just did
<Mez> so findutils = broken :D whee
<pitti> Mez: I created an empty directory "x" on my machine
<pitti> LANG= LANGUAGE= find x -depth -type d -empty; echo $?
<pitti> x
<pitti> 0
<Mez> move a couple of dirs below that and try find it
<pitti> Mez: it doesn'T even happen for ~/x on the same machine that breaks the konversation build
<Mez> fined bla/bla/bla/bla/x etc
<jdub> pitti: my mutt configuration reloads the folder set using a find command... having lots of stderr spew when switching folders was really annoying ;)
<Mez> *shrugs*
<pitti> Mez: yep, that's it
<Mez> so it's finds with a / in
<Mez> well./... more than one dier
<Mez> as i said - possibly something to do with default maxdepth setting?
<pitti> doesn't make a difference
<pitti> mkdir -p ~/x/y
<pitti> $ find x/y -depth -maxdepth 10 -type d -empty; echo $?
<pitti> find: x/y: No such file or directory
<pitti> 1
<Mez> freaky?
<Mez> reckon it's debain- or upstream?
<pitti> annyoing
<Mez> god i cant type today
<Mez> lemme know when youfile a bug report pitti :D
<Mez> lol
<Mez> anyways
<Mez> gonna read
<Mez> this annoyed me
<Mez> need rest
<pitti> Mez: shall I put you in CC? which mail address?
<Mez> martin@sourceguru.net
<pitti> Mez, Riddell: new pkgstriptranslations uploaded
<pitti> Riddell: can you please ask infinity on Monday to give it back?
<pitti> Riddell: (it needs a while until it is intalled in the dchroots)
<Riddell> infinity is the new lamont?
<tseng> yes.
<pitti> yes :-)
<lamont> although I'm not completely gone yet...
<lamont> infinity is just present at more, and different times than me.
<pitti> Mez: filed, CC'ed you
<pitti> good evening everybody
<reb> hey... im having a problem with upgrading to breezy that im not able to fix on my own
* Keybuk points at the "breezy well broken" in the /topi
<Keybuk> +c
<reb> yes yes
<reb> i dont mind that it doesnt work, im just trying to fix and understand the problem
<Keybuk> what's the error?  bear in mind it may not actually be resolvable
<reb> i refer you to http://ubuntuforums.org/showthread.php?p=208694#post208694
<Keybuk> it's a known change
<Keybuk> upstream changed the way find works
<reb> how could i resolve it (could i?)
<Mez> wait is this the find thing again
<Mez> grr
<Keybuk> edit /var/lib/dpkg/info/mozilla-firefox.postrm and remove the offending find statement :p
<reb> ok!
* Mez rolls yes
<Mez> grr @ upstream
<Mez> ok so... I'm sorta glad I helped cause the first occurence :D
<reb> yay!
<Mez> Keybuk, how do i find details of when a package was last updated?
<Keybuk> download it and read the changelog ?
<Mez> am too lazy to do that
<Keybuk> what question did you mean to ask?
<Keybuk> when did the maintainer prepare the release?
<Keybuk> when did the maintainer build the release?
<Keybuk> when did the maintainer upload the release?
<Keybuk> when did the archive accept the release?
<Keybuk> when the the buildd accept that it needed to build it?
<crimsun> Mez: packages.ubuntu.com/changelogs/pool/$pool/$first_initial/$package/$version/changelog
<Keybuk> when did the buildd finish building it
<Keybuk> etc. etc.
<Mez> I'm just wonderin how long findutils has been broken
<Keybuk> could be anything up to ~4-5 months ago
<Keybuk> since hoary UVF
<Mez> so... why only picked up now
<Keybuk> UVF.
<Keybuk> we stop taking new upstream versions at a certain point in the release process
<Keybuk> and then concentrate on bug fixing, and taking only important changes, etc.
<Mez> yeah but i mean, it's been used for how long in breezy
<Mez> and breezy isnt locked yet is it?
<Keybuk> could've been waiting on a merge
<Keybuk> could've been held up by other breakage and only just built
<Keybuk> or it could've only just been uploaded to Debian
<Keybuk> I'd guess waiting on a merge, because we had 1ubuntu1 in hoary so it would've needed one
<Keybuk> merges are manual
<Mez> says was ubdasted o -2 on 9th june
<Mez> that may be why
<Mez> I need a pint?
<Mez> i need a pint *
<Mez> fancy meeting me for one keybuk?
<Mez> lol (nah i gots work to do)
<Keybuk> :)  sadly, I'm entertaining this evening
<Mez> can i come ? :P
<Keybuk> (when they turn up and drag me away from dpkg hacking)
<Mez> lol - fair enough
<Mez> I've got nothing to do till my gf comes tomrrow... lol... but really fancy a pint
<Mez> cept maybe sleep
<Mez> some other time eh Keybuk  ??? :P
<Keybuk> yup
<daniels> jdub: pong
<daniels> chol: i can guarantee you it will fail
<Mez> lol
<chol> daniels, sure did :)
<Mez> sounds fun
<chol> daniels, built it regularly on a debian.. got "loader failed".. whatever that means
<chol> so i'm having a hard time confirming the error
<chol> tried against solaris x 6.x.x and it works there
<chol> daniels, are you using brandens xfree build scripts originally?
<daniels> 'loader failed' where?  during the build process?  when you start?
<daniels> chol: not 'branden's', as such
<chol> at startup, some modules fails to load
<chol> seen the error on mailing lists but no direct answer
<daniels> chol: ishikawa mutsumi took branden's 4.1 packaging and made it into 4.2.  i took ishikawa's 4.2 packaging and made it into 4.3.  fabio and I took my 4.3 packaging and made it into xorg 6.8.  i've maintained it from then on in.
<daniels> chol: delete everything under /usr/X11R6/lib/X11/modules and start again
<chol> i'll try, even though projectroot is /usr/xorg this affects?
<daniels> ah, dunno
<Amaranth> does anyone know of a cd burning app that doesn't use cdrecord and isn't k3b?
<daniels> the module loader is complete crap, i think it searches /usr/X11R6 even when building with a different projectroot
<Amaranth> oh, and not that new one in ubuntu either, it doesn't blank cd-rws
<chol> daniels, i'll give it a try
<chol> daniels, with logverbose i see some unresolved symbols that probablys the culprit
<chol> i'll rebuild it all with the xfree install out of the way
<mdz> doko: http://people.ubuntu.com/~lamont/buildLogs/libj/libjessie-java/1.0.0-1ubuntu1/libjessie-java_1.0.0-1ubuntu1_20050610-2245-i386-failed.gz
<daniels> chol: awesome
* daniels goes to sleep.
<chol> daniels, sweet dreams :)
<Amaranth> Serpentine has some...issues
<Amaranth> "Do you want to record your musics?"
<Amaranth> "You are about to record a media disc. Canceling a writing operation will make your disc unusable."
<Amaranth> then it tells me canceling will ruin the disc but it asks if i want to cancel
<doko> mdz: I know. I would really like to have java-gcj-compat and ecj-bootstrap in universe for two days, until we have finished the things we need
<mdz> doko: how would this help?
<mdz> I cannot reproduce the failure here; seems like a missing dep
<jdub> mdz: (hadess was just asking me if you got his email)
<mdz> who is hadess?
<jdub> mdz: (sorry, bastien nocera)
<mdz> yes, I do have an email from him dated June 10th (yesterday)
<jdub> ok
<mdz> I also have email from June 7th, 8th and 9th that I haven't responded to yet
<jdub> same
<jdub> i hate email atm
<doko> mdz: buildable ecj-bootstrap, buildable java-gcj-compat
<Amaranth> serpentine has died :/
<doko> installable java-gcj-compat
<wasabi_> hi
<Keybuk> mdz: this is the trouble you get for having a reputation as someone who responds to e-mail
<Mez> whereas keybuk I think leans on the delete button for half an hour a day :P
<Keybuk> Mez: dude, I have scripts that do that for me :p
<Mez> oh yeah
<Mez> I forogt...
<Mez> Keybuk = geek
<Keybuk> "I sent you an HTML e-mail with a 200MB attachment, why didn't you get it?"
<Keybuk> "I sent an e-mail to every single e-mail address of yours I could find, why didn't you get it?"
<Keybuk> "I sent you the same e-mail 200 times, why didn't you get it?"
<Keybuk> etc.
* daniels ponders sending Keybuk the same email 200 times.
<daniels> (to every address, HTML-formatted, with uncompressed xorg build logs from every architecture attached.)
<Keybuk> daniels: after about the third, you get rejected at the SMTP level
<Keybuk> actually, _you_ wouldn't because you're in my address book
<Keybuk> so you can send me whatever you like
<daniels> \o/
* Mez is probably blocked then
<mdz> doko: they seem to be installable, as they are being used for build-deps
<mdz> doko: if they are not buildable, then we should just fix that
<mdz> doko: they were installable and buildable at the time I moved them into main
<doko> mdz: ok, think I found, it's libant1.6-java, which is broken. so, if a buildd admin is here (lamont?), then it should be fixable by building ant with a fixed libant1.6-java on the buildd.
<doko> lamont, infinity: ^^^
<Mez> o_O
<Mez> what the ****
<Mez> how can thingsget into the repository without having a signed .dsc
<Mez> any devs here want to sponsor my package for breezy? seeing as I cant upload myselg (gaim 1.3.1
<seb128> no
<seb128> I'm going to sync this one on Debian
<dogfoodbrain> Ubuntu es la mejor distribucin de Linux del mundo.
<Mez> :'(
<Mez> but thtas what i alreday did
<tseng> Mez: dud eI thought I told you
<Mez> told me what tseng?
<tseng> running uupdate doesnt help anyone that much
<Mez> tseng
<Mez> I just merged from debian :P
<tseng> Mez
<seb128> which is pretty useless
<Mez> so that isnt running uupdate now is it
<seb128> that's faster to merge than to get your package and review it
<Mez> lol
<tseng> no, its even less work
<tseng> we do it automatically
<Mez> *shrugs*
<Mez> fair enough
<tseng> if you want to help out maybe read up on the CXX transition
* Mez shudders
<tseng> or go through gnome bugs on bugzilla
* Mez is a KDEer
<tseng> then KDE bugs
<Mez> I just built gaim cause i backported it for hoary ...
<Mez> just as i backported konv 0.18 for hoary, then built for breezy
<seb128> thanks anyway
<tseng> why are you backporting things that arent in breezy?
<seb128> but that's not useful :)
<doko> Mez: k3b needs some love ...
<Mez> lol
<Mez> I'll remember that
<Choubaka> Would anyone here happen to know what's the support for suspending on those HP laptops that ship with the special HP Ubuntu? According to the forum it seems the changes would be incorporated to Ubuntu (breezy/hoary?) at some point. The wiki says suspending doesn't quite work, but that info may be outdated :/
<seb128> Mez: have you used a .orig.tar.gz or made it native debian as the Debian package?
<Mez> for what seb128 
<seb128> about what were we talking 2 min ago?
<Mez> gaim
<Mez> i used orig.tar.gz
<seb128> k, you have your answer
<seb128> so you diverge from Debian :/
<Mez> I use the orig.tar.gz and diff.gz from debian
<Mez> and then I rebuild .
<seb128> http://ftp.debian.org/debian/pool/main/g/gaim/
<seb128> 1.3.1 has no .orig.tar.gz
<seb128> they screwed somewhere
<Mez> oh
<seb128> that's a native debian package
<Mez> then i jsut go thte orgic.tar.gz and rebuilt
<Mez> I think
<seb128> k, so you don't even know what you did
<seb128> you didn't merge with Debian
<Mez> I cant remember
<seb128> I'll update, thanks anyway
<Mez> I think the orig.tar.gz included the debian/ dir
<Mez> so i just built once I downloaded it
<seb128> there is no .orig.tar.gz
<Mez> or whatever file it was on debian
<Mez> http://ftp.debian.org/debian/pool/main/g/gaim/gaim_1.3.1-1.tar.gz
<Mez> donwloaded that
<Mez> untarred
<Mez> changed the debian directory for changelog
<Mez> etc
<Mez> and pdebuild'd it
<Mez> ah yes
<Mez> seems to have made a native debian package for it on ubuntu too
<Mez> http://www.sourceguru.net/ubuntu/breezy/
<seb128> have you updated the translation.patch?
<Mez> er no...
<Mez> I knmwe I'd forgotten something
<seb128> k, so I'll upload your package next time, sorry for this one :)
<Mez> ??
<Mez> lol
<seb128> just wondering if I should upload your build or update
<Mez> *shrugs*
<Mez> i forgot that translation thing
<seb128> but since you seems to have forgotten some part I'll use my build
<seb128> yeah, that's why
<Mez> but it seems to work ok on hoary without it
<seb128> sure it works
<seb128> there is only less translations
<Mez> ah
<Mez> fair enough
<seb128> I'm building 1.3.1 with the translations so don't bother
<seb128> thanks anyway
<Mez> kk
<jdub> http://people.ubuntu.com/~jdub/breezy/
<jdub> ^ if anyone wants to try the latest clearlooks
<Mez> jdub - should e be scared
<Mez> s/e/we/
<tseng> jdub: hm
<tseng> jdub: gradients
<tseng> oh man that fucked my panel all up
<Lathiat> jdub: source package so i can rebuild for hoary?
<Mez> damn you lathiay
<Mez> I was gonna sk for that
<jdub> Lathiat: didn't bother uploading those
<Lathiat> jdub: i noticed, thats why im asking for it?:)
<whiprush> jdub: some friends and I are gonna work on fridge tonight. Is there anything we should do other than trying out different blocks and whatnot?
<tseng> whiprush: make it "chill"
* whiprush defrosts tseng 
<jdub> whiprush: lots of ideas for advocacy and interactive stuff
<whiprush> right
<whiprush> what about this civicspace shit?
<tseng> whiprush: are we going to rip off getfirefox?
<jdub> spreadfirefox has a lot of good starting ideas
<tseng> yeah, spread
<whiprush> tseng: not totally. It's a good place to start though
<tseng> and actually track 10x10
<whiprush> yup.
<tseng> <3
<jdub> whiprush: cool ideas for helping loco teams and software freedom day would be rad too
<whiprush> on it.
<tseng> whiprush: just tell me when i get my little web button
<jdub> whiprush: we already have lots of good ideas for content, i think it's that stuff above that are black holes atm
<whiprush> jdub: I really want to move to a working site soon. I'd like to hit low hanging fruit and stuff
<jdub> whiprush: you're welcome to do anything you want on the current one
<whiprush> ok.
<jdub> whiprush: i just don't want to put make it more public until we've nailed down a lot of it
<whiprush> will it be easy to migrate or are we just prototyping. I don't want to put too much effort into it if we're going to start over.
<whiprush> but I'll be more than happy to break it
<jdub> it'll be pretty easy to migrate
<whiprush> any word on artwork? I'd love a sneak peek.
<jdub> if you want to play with particular modules that need to be installed or anything, just ping
<jdub> only what andy's done so far, which you've sen
<jdub> haven't got any drops from him recently
<sivang> jdub: hey jeff, 'sup? would it be too rude if I asked what are you discussing? ;-)
<jdub> sivang: the fridge
<whiprush> k, we'll update the spec as we work tonite. off to the bar.
<jdub> whiprush: rawk :)
<jdub> whiprush: oh, and if you want more people added to the list before First Mail, let me know :)
<whiprush> I will
<sivang> jdub: who's fridge is it?
<jdub> soon, it will be the world's fridge
<sivang> jdub: will stuff related to the fridge be discussed on the locoteams mailing list?
<sivang> jdub: (I do keep reading it, if not keeping too current on -devel and others)
#ubuntu-devel 2005-06-19
<jdub> sivang: once the basics are together and we're up and running, i'm going to talk to other groups in the project to see how we can make the fridge useful for them
<sivang> jdub: way cool dude, nice to see all of these advancements.
<lamont> doko: what exactly needs to be done (and on which architecture(s))?
<Mez> did you have fun keybuk
<Keybuk> some beer was had
<Mez> aw and i wasnt invited
<Mez> :'(
<Mez> lol
<lsuactiafner> heh hey Mez 
<Mez> hey lsuactiafner 
<whiprush> thom: around?
<thom> whiprush: thinking about bed, but more or less
<thom> whiprush: how's it goin'?
<whiprush> just wanted to let you know I built NM with the dhcp thing you uploaded
<whiprush> and it's working pretty good.
<whiprush> I'm at a bar and NM just knew what to do when I resumed to join the network. It's pretty awesome.
<thom> rock on. i'm hoping to get the packaging for 0.4 done monday and get it uploaded. 
<thom> awesome! :-)
<whiprush> I have one hard crash so I'll report it if I see it with your package
<thom> did you build latest CVS?
<whiprush> yeah
<whiprush> plugging in a cable locks up the laptop about every 5th time.
<whiprush> when it doesn't lock up it switched to the wired network though, which is neat.
<thom> woah
<whiprush> when the cable unplugs it starts looking around for an AP.
<thom> (woah at the hardlock, that is)
<thom> yeah, when it works right NM is awesome
<whiprush> yeah the last thing in the log is something about ipv6. Haven't looked deeply at it yet though.
<doko> lamont: ping
* Mez yawns
<Mez> got damn findutils
<TerminX> anyone know when vlc will be fixed?
<Amaranth> next year :)
<Amaranth> after the cxx transition is finished for libraries
<Amaranth> all c++ apps are on restricted upload status until the libraries finish
<TerminX> I didn't even realize VLC was c++
<TerminX> :)
<Burgundavia> whiprush, ping, regarding the fridge
<whiprush> pong
<Amaranth> Burgundavia: where is this mysterious new icon theme from andy? :)
<Burgundavia> Amaranth, ask jdub and andy
<Amaranth> jdub: can i get a sneak peak at andy's new icons?
<Burgundavia> whiprush, basically, as soon as you are live, I am going to have content for you, but I am wondering what is the best way to get that to you.
<whiprush> Burgundavia: can you mail me your address (jorge@whiprush.org), I'll have jdub put you on the distro list for fridge.
<Burgundavia> also, regarding said content, it will involve images (screenshots), should those also come with?
<whiprush> Burgundavia: we haven't really decided on implementation details. Ideally, I would like to see articles put right into the wiki, and have fridge just point to them.
<Burgundavia> ugh
<Burgundavia> uploading images to the wiki sucks
<whiprush> that way we have content in the wiki where it Should Be(tm) instead of seperately on another cms.
<Burgundavia> yes
<whiprush> how that stuff will work is still TBD though.
<Burgundavia> well, screenshots should really be part of launchpad, so that the new app installer can use them also
<whiprush> in the meantime just hang onto your content, once we have a better idea of how things will work we'll talk those details.
<Burgundavia> cool
<lamont> doko: ack
<Amaranth> SloMoSnail: I merged in your translation work and made some changes to it.
<Amaranth> SloMoSnail: I'll be in string freeze mode when I get back next week, if you want to translate the new strings.
<Amaranth> AndyFitz: can i get a peek at your new icons?
<AndyFitz> Amaranth, sure thing.  just setting up a new box down the coast at the moment. so I won't have access to them until tomorrow
<Amaranth> that's cool
<AndyFitz> love how breezy now mounts ipods with the ipod icon :)
<jdub> AndyFitz: send me a new drop while you're at it (spank-spank-spank!)
<AndyFitz> arf-arf-arf
<AndyFitz> Amaranth, pm me your e-mail addy and I'll CC you in the next drop
<Amaranth> AndyFitz: thanks
<hondje> Hi. bugzilla isn't allowing me to post my two bugs, for some reason.  Is there a bot or something I can mail these to instead?
<hondje> Or someone who doesn't mind a little copy-paste?
<sladen> hondje: does Bugzilla give a reason
<sladen> hondje: if you get totally stuck, send them to the mailing-list
<hondje> sladen: it keeps telling me ' 'User' is not a valid bug number. It is neither a bug number nor an alias to a bug number. If you are trying to use QuickSearch, you need to enable JavaScript in your browser.'
<hondje> sladen: I don't see an option for bug number though...I'm trying to post in the Ubuntu section
<hondje> post to ubuntu-devel, or to the guy (thom@ubuntu.com) that bugzilla was going to assign it to?
<Amaranth> err, is everything failing?
<hondje> these aren't terribly urgent bugs, I'll wait a day or two and try again, if not then I'll drop it on ubuntu-devel
<sladen> hondje: what do you have in the 'Blocks:' and 'Depends:' fields.  make sure they are blank
<hondje> I had one in depends
<Amaranth> ah, thats why
<Amaranth> Depends: takes a bug number
<hondje> oh, I totally mis-rtfm'd that. Not unusual for me
<hondje> now it's in, yay for hondje
<hondje> Thanks a lot, sladen, Amaranth
<jdub> Burgundavia: .ogv, .oga and .spx already exist
<robitaille> jdub,  so why we don't use .ogv?
<daniels> who's 'we'?
<robitaille> by the way, finally watch your 10x10 guadec talk tonight (as a ".ogg" file".  Very interesting.
<robitaille> daniels,  guadec live video feed were .ogg files.  "we" as in "some site out there" use ogg files as video files.  Burgundavia  blog entry was talking that this create some  confusion
<jdub> robitaille: :)
<Zomb> BTS on launchpad says "Invalid value" and nothing more
<Zomb> fuck that
<doko> infinity, lamont: ping
<fabbione> hey doko
<doko> morning fabbione, or are you preparing lunch?
<fabbione> doko: no why?
<fabbione> doko: i was going to ask you if we could check what C++ applications i can build on sparc
<fabbione> given that you have all the lists and stuff
<fabbione> at least for main
* fabbione watches doko disappearing in a cloud of smoke
<doko> are all the libs done
<doko> ?
<fabbione> doko: that's what i would like to check with you :)
<fabbione> i think i did all the libs
<doko> so you have to make sure that all the packages in the the "New bin" column from the wiki list are available.
<fabbione> can you give me the URL again please?
<doko> be sure to have firefox-dev and festival-dev built as well.
<fabbione> i had to neglet sparc for a while
<doko> https://www.ubuntulinux.org/wiki/CxxLibraryList
<fabbione> doko: if there is no "New Bin" ??
<fabbione> oh they are apps
<doko> then it is not renamed and you can ignore it
<doko> and kdebase should be built before building the KDE apps
<fabbione> kdebase has been built heaps load of time
<fabbione> kde* has never been banned
<fabbione> + without kdebase you can't satisfy b-d for the other apps
<fabbione> doko: do you have this list in text format?
<doko> fabbione: chinstrap:~doko/wiki*
<fabbione> doko: thanks
<fabbione> doko: so given that i have all the libs in main builded, i can unleash the buildd on the apps
<fabbione> i am pretty sure i did build all of them
<fabbione> but i will check again.. thanks doko
<doko> fabbione: only the apps in main
<fabbione> doko: yeps of course
<LikesHisLunch> Does anyone here have experience building OpenOffice.org on Ubuntu with ooo-build?
<bob2> daniels: does ubuntu have http://www.gnome.org/~seth/xserver.patch merged yet?
<daniels> bob2: i assume the former prevents over-reporting of damage?
<bob2> daniels: I think so
<daniels> there's a different (vastly more correct) patch in HEAD that I might steal if it's an issue
<daniels> anyway, tart comes out of the oven now
<bob2> ah
<eruin> is there any chance of getting the via82cxxx kernel module loaded by default on computers with via82cxxx gear? - It allows useful things like setting dma om ide-cd's
<madduck> does ubuntu have a mailing list like debian-mentors
<madduck> i am looking for some co-maintainers and would like to send a note there...
<bob2> ubuntu-motu may be what you're looking for
<madduck> http://lists.ubuntu.com/mailman/listinfo/ has nothing on that.
<Nafallo> madduck: #ubuntu-motu
<madduck> not a mailing list... :/
<madduck> oh well, i sent the message to ubuntu-devel@l.u.o
<tseng> we arent big enough to split ubuntu-devel mailing list
<madduck> that'll do.
<tseng> we work mostly on irc.
<madduck> anyone here responsible for the zope/plone stuff?
<tseng> and the wiki
<madduck> other than doko
<madduck> ?
<tseng> i think there might be one other person, but i imagine doko would be happy to talk to you if you have some fixes
<madduck> i already talked to doko.
<tseng> then?
<madduck> it's not about fixes, it's about changing the way ubuntu and debian work together on zope/plone
<madduck> which will be started at the debconf
<madduck> and since i just saw the motu team for zope/plone
<madduck> i would think they should know.
<tseng> ah does the page list any nicks?
<tseng> one second
<madduck> herve...
<tseng> herve and ajmitch
<tseng> I can give you emails for them
<madduck> that would be nice.
<ogra> hey tseng 
<tseng> morning ogra 
<ogra> tseng, how was this funny javascrip driven wiki called `
<ogra> ?
<tseng> ogra: hm i dont remember
<tseng> its on tbermans blog one second
<ogra> thats enough info...
<tseng> http://shared.snapgrid.com/gtd_tiddlywiki.html
<tseng> i never ended up getting into it that much
<ogra> i just told some norway guy about it... he wanted to see it :)
<ogra> thanks
<tseng> np
<tseng> madduck: see msg if you havent
<hunger> LOL!
<hunger> Saw the debian sarge review on /.? "Only occasionally does this new release differ from Ubuntu."
<Simira> heh
<Simira> well, they obviously do have a lot in common
<Simira> and I guess the biggest difference is in philosophy around the distro... but I wouldn't even consider changing to Sarge :p
<hunger> Simira: I am wondering what to install on my new laptop... and still undecided.
<Simira> hunger: what have you used before?
<Simira> hunger: my laptop is kind of a developer/travelling tool, so I dualboot windows/Breezy on mine
<hunger> Simira: I am using debian and ubuntu.
<hunger> Simira: Well mine will get either debian/unstable or ubuntu/unstable.
<Simira> hunger: I'd suggest Breezy, if you're not very dependent on stability. It's exciting following it up. It is Debconf soon, though...
<Simira> hm, maybe I should consider putting up a sarge somehwere, just to have a look at Debian before going to Debconf... :p
<Simira> my laptop do have enough with those two, though.
<hunger> Simira: Well, there is some stuff in the BreezyGoals that I do not like... 
<Simira> hunger: like what?
<hunger> Simira: Maybe I should follow breezy then... and complain if things go wrong;-)
<Simira> hunger: it's up to you to do something about it, you know ;) That's what I like about Ubuntu.
<hunger> Simira: I am afraid that the network stuff is going to be very gnome-centric i.e. I am on kubuntu and want to see the improvements as well.
<bob2> presumably the kde people are doing the same thing
<Simira> hunger: ah, right. Are you "only" a user, or do you develop or do other work on Debian or Ubuntu?
<bob2> 4.0 can't be that far out
<hunger> Simira: I am only a user of ubuntu/debian.
<hunger> Simira: I do develop stuff, but that is unrelated.
<hunger> It would be really cool if breezy shipped with dmix set up....
<bob2> what a great idea
<bob2> why didn't anyone else think of that ;)
<daniels> we should just use polypaudio instead
<hunger> bob2: Dunno;-)
<daniels> i hear that rocks
<tseng> haha
<hunger> daniels: Well whatever... but having one sound channel only is so 1980s.
<bob2> so
<bob2> setup dmix
<bob2> enjoy!
<bob2> breezy is being worked on
<hunger> bob2: I know. But I do not remember readirg anything about sound in BreezyGoals.
<tseng> hunger: then you missed out, because we are already working on polypaudio, dmix, hotplug alsa magic
<hunger> tseng: Cool!
<hunger> tseng: So this will work in breezy? Wow, ubuntu rocks!
<tseng> of course it does.
<ogra> hunger, didnt you see the udu wiki ? 
<hunger> ogra: I did.
<ogra> http://udu.wiki.ubuntu.com/AudioInfrastructure (guessed)
<hunger> ogra: I must have missed that... stupid me.
<hunger> sorry for the noise!
<ogra> :)
<hunger> ogra: So basically I have to sit back and wait for someone to implement this? Or can I try to help?
<ogra> hunger, you can ask pitti how you can help testing etc
<tseng> hunger: the biggest thing we need afaik is this:
<tseng> testing dmix on as many sound cards as possible and filing alsa bugs for ones that dont work
<hunger> Wow, great, alsaplayer is not installable:-(
<tsume_> did somebody fix the hoary updates yet?
<tsume_> login and several others had a md5 mismatch
<bob2> us.archive.ubuntu.com is screwed
<bob2> which is in the #ubuntu topic
<tseng> daniels: so i got the muine ipod plugin working
<tseng> daniels: its hardcore.
<daniels> phat
<tseng> ill package it eventually
<tseng> it needs a little helper lib too
<tsume_> bob2: I haven't visited #ubuntu in a long while :)
<tsume_> bob2: why doesn't someone fix the problem?
<tseng> do we even control that mirror?
<daniels> we don't control us., no
<tseng> well there you go
<doko> infinity, lamont: ping
<infinity> doko : pong.
<doko> infinity: could you throw all *-java to the buildds again, plus jsch and jakarta-log4j1.2 ?
<\sh> re
<infinity> In a few mins, sure.
<doko> thanks
<tsume_> ...
<tsume_> what person screwed over the us mirror?
<daniels> try to be a little less harsh, maybe
<tsume_> daniels: I could think of far more. Point is, it should have been repaired immediately upon the finding of the mirror being broken
<daniels> tsume_: no, actually, point is, someone's providing a half-working mirror, that's generally been working in the past.  you're not providing any mirror at all.  so I suggest you be far less harsh towards the us. mirror operator.
<tsume_> its better providing no mirror than a broken mirror
<tsume_> daniels: it makes a person look like a dumb ass when the person is showing off ubuntu to a friend and then everything craps out when he tries to perform updates
<tsume_> daniels: so, no. I will not be less harsh
<jnc> tsume_: ...
<daniels> tsume_: i'm sure us.archive will get fixed eventually.  in the meantime, if you want to criticise someone for providing a service, feel free.  but don't expect any respect from my end, at least
<tsume_> daniels: perfectly fine. I'm not going to damn a project over another's screw up. 
<ogra> tsume_, btw, did you inform the person running the mirror ?
<tsume_> ogra: couldn't find his phone number
<Choubaka> You could save it by saying "Looks like the US mirror is having trouble. Let's try something else." and the swap the mirrors quickly with apt-setup. :P
<ogra> tsume_, there are such nice inventions like email nowadays, i guess you'll find out.... he probably doesnt even know his mirror isnt working
<tsume_> Choubaka: he isn't exactly linux-savy
<Choubaka> That doesn't matter.
<Choubaka> you'll just have to explain what a mirror is, and why it's not the fault of the distro if one is down temporarily, and that it's easy to change to a working one.
<tsume_> gee, and that would make it should like the distro is shoddy
<Choubaka> How?
<tsume_> "Something" doesn't work.
<daniels> i think this discussion has staggered way too off-topic
<Choubaka> Perhaps.
<ogra> daniels, yep, its absolutely not development related....
<Choubaka> Hm.
<zyga> anyone around who knows a bit about evolution?
<zyga> I'm trying to fix some i18n issues
<zyga> make -C po update-po fails miserably
<zyga> anyone interested in helping/
<Burgundavia> jdub, I have seen other sites use .ogg as well, because they can
<Q-FUNK> hi.  could you guys use the help of a really talented coder who specialized in hacking resource-efficient live CDs?
<Q-FUNK> I found this guy's live Cd rather amazing:  www.deadcd.org
<Q-FUNK> he's a young czech coder.  he would love to be hired by some OSS startup to further develop his live CD concepts.
<Q-FUNK> he was asking me for job leads and I figured that he would have potential for Canonical.
<zyga> could someone explain line 771 in intool-update from evolution source?
<zyga>     my $MSGMERGE = $ENV{"MSGMERGE"} || "/home/evolution-dist-21/bin/msgmerge";
<zyga> why the heck /home/evolution-dist-21/ ?
<zyga> evolution is pretty f*** up IMHO :/
<zyga> I mean package source 
<zul> zyga: patches welcome i suspect :)
<zyga> zul: even if
<zyga> zul: evoution is probably outdated now ;-)
<zyga> zul: hoary evolution that is
<tsume> hehe
* tsume pets breezy machine
<zyga> zul: I hope my patches will make any sense
<tsume> breezy rocks :)
* zyga killed his breezy box when he needed a *working* computer
<zyga> ;-)
<zyga> all I wanted to do was to fix a minor i18n issue
<tsume> My laptop works wonderfully
<zyga> tsume: is brezy usable now?
<tsume> zyga: I've been using breezy since it was created
<tsume> now I'm running kernel 2.6.12 :)
* tsume pets package
<tsume> running the most current software is the most important thing.
<zyga> tsume: I'm not that hardcore
<tsume> zyga: I'm a BSDer, I'm 100% hardcore :)
<zyga> tsume: I'm not good at sloving problems with everything
<tsume> zyga: I am :)
<zyga> tsume: I'm good at fixing stuff that almost works
<tsume> zyga: I like fixing 100% broken stuff ;)
<zyga> tsume: besides I need to work on my laptop from time to time :)
<tsume> zyga: my laptop works 100% ;)
<zyga> tsume: doing webdesign in the linux console is not useful ;>
<zyga> tsume: okay okay, I'll wait a week or three and give breezy a try
<tsume> zyga: use X
<tsume> zyga: I'm in Gnome right now
<tsume> everything wfm
<zyga> tsume: apt-get update && apt-get dist-upgrade and *nothing* elese?
<tsume> weeell.. you might need to rebuild your font dirs :)
<zyga> tsume: nah.. I'll wait :-)
<zyga> tsume: hehe - dont get me wrong I love hacking
<tsume> mkfontdir (about 6-8 different font dirs, depending on what you enable)
<zyga> tsume: but there are finite number of things one person should follow and understand IMHO :)
<tsume> then bada boom! everything boots :)
<zyga> I don't really want to know how font subsystem works
<siretart> hi
<siretart> is there really no g77-4.0?
<infinity> siretart : Nope, but there's a gfortran. (which isn't entirely compatible)
<mxpxpod> thom: ping
<siretart> infinity: i'm currently trying to cxx transition mpqc, which needs g77. 
<siretart> I assume its ok to just build depend on g77, which installs g77-3.4, yes?
<infinity> siretart : Yes.
<zyga> thom: is updating extensions in firefox broken? (hoary)
<zyga> thom: the scalpel cut that took out update feature left something behind: XML Parsing Error: no element found
<zyga> Location: jar:resource:///chrome/toolkit.jar!/content/mozapps/update/updates.xml
<zyga> Line Number 1, Column 1:
<zyga> thom: I've got a patch if you'd like
<siretart> gnarf. link errors :(
<zyga> thom: I revert that, I have no idea where that comes from, my patch does not seem to fix it
<zyga> thom: anyway it's at http://www.suxx.pl/patches/no-more-referenses-to-updates-xml.patch
<Nafallo> seb128: thanx! :-)
<seb128> for?
<Nafallo> seb128: that multimediakeys bug drives me nuts :-).
<seb128> oh, np
<dooglus> package libcurses-perl doesn't contain anything but documentation any more.  is that a bug?
<the--dud> hello there folks, I'd like to get more involved in the ubuntu development in some way or another... Just reading up on the ubuntu wiki now
<mdke> welcome the--dud 
<the--dud> where is there most use for some fresh blood?
<the--dud> mdke, thanks. how are you?
<mdke> the--dud, good thanks. You can ask on #ubuntu-motu, this is the place for new developers who work on Ubuntu's universe repositories
<the--dud> allright, they primarily work with packaging don't they?
<the--dud> at least that's my impression
<mdke> yes
<mdke> but you should ask them because i'm not qualified to say really../
<the--dud> hehe
<the--dud> I'd really be more interested to work with coding in a more direct way to the actual ubuntu distro
<the--dud> as I'm an IT consultant, I'd might be of some use? :)
<mdke> the--dud, see what other people in the chan recommend, i'm sure that fixing bugs is very helpful tho
<mdke> the--dud, also there are some bounties and target specifications for breezy development that you could get involved in
<the--dud> yeah...
<dooglus> mdke: it's hard to know which bugs are already being worked on.  it's a shame to duplicate effort
<mdke> true
<mdke> http://udu.wiki.ubuntu.com/ <-- the--dud 
<the--dud> already submitted some bug fixes through that online thingie
<mdke> cool
<the--dud> thanks
<Simira> mako: ping
<the--dud> mmk
<the--dud> came to think about something, is ubuntu in need of mirrors of any sorts?
<the--dud> nm, read the wiki page >_<
#ubuntu-devel 2006-06-12
<pvanhoof> about OLPC, "We have heard multiple people say that QEMU doesn't work with these images on the debian-derived distributions. We also haven't heard of any solutions to these problems. The symptom is that the kernel hangs during boot."
<pvanhoof> I'm experiencing the problem
<pvanhoof> does somebody know howcome this is happening?
<pvanhoof> I know it hangs while probing for the IDE busses (in the kernel being run on the emulated hardware)
<pvanhoof> http://wiki.laptop.org/index.php/OLPC_Software_Testing
<pvanhoof> It would be nice if I could do development for the OLPC device using ubuntu, which is why I ask 
<sladen> pvanhoof: it could be our IDE probing which is different in udev
<pvanhoof> does it affects ide probing in a qemu environment?
<mjg59> No
<pvanhoof> I think blizzard added the note after I reported this .. he added it to the wiki the same day I mailed
<pvanhoof> http://wiki.laptop.org/index.php?title=OLPC_Software_Testing&diff=5357&oldid=5356
<pvanhoof> so I don't know if a lot people are experiencing this
<pvanhoof> http://olpc.download.redhat.com/olpc/streams/development/latest/images/
<mjg59> Let me have a go
<pvanhoof> I'm going to test with the latest image once downloaded
<pvanhoof> I'm at 11%
<neuralis> the images hang at the IDE hard drive probe. not just OLPC image.s
<neuralis> *images.
<pvanhoof> so there's a defect in qemu in general?
<neuralis> i've actually built our qemu, stripped of all debian-specific patches (29 of them, i believe), and it still wouldn't run.
<neuralis> compiling the vanilla qemu from the qemu site works fine.
<pvanhoof> maybe a problem with the version of qemu?
<neuralis> i didn't do a diff between our orig tarball and the one i downloaded, though.
<mjg59> Compiled with the same options?
<pvanhoof> is there a reason not to bump the version of the package to the one on the website?
<mjg59> Other than dapper being frozen and edgy not being open?
<pvanhoof> hmm, good point
<pvanhoof> well, if you know why (in source differences) you could backport the fix, and claim it's an upgrade ? :)
<neuralis> pvanhoof: it's (generally) against policy if it's a functionality fix.
<pvanhoof> neuralis, is it? the software doesn't work atm (or does it for other operating systems?)
<pvanhoof> well, if I pass idex=noprobe, it boots
<pvanhoof> but then I don't have a root partition of course
<neuralis> pvanhoof: i understand it works for some images, and not for a bunch of others.
<sladen> pvanhoof: idex or ide0 ?
<pvanhoof> ide[nth] 
<pvanhoof> if you allow any ide to get probed, it will probably hang
<sladen> pvanhoof: so what did you actually type to get it to boot?
<pvanhoof> I got it to boot with probing once
<pvanhoof> qemu -monitor pty -hda ./olpc-2006_02_06_16_08.ext3 -net nic,vlan=0,macaddr=52:54:0:47:b:0 -net user,vlan=0 -serial null -parallel null -M pc -boot c -m 128 -smp 1
<sladen> pvanhoof: and there's no partition table at the front of those images?  They're just straight ext images?
<pvanhoof> you'll have to ask the olpc folks
<pvanhoof> how can I check?
<neuralis> sladen: qemu -hda <imgfile> is enough to boot those.
<pvanhoof> I can't (for example) mount them using loopback
<herzi> pvanhoof: file <image>
<pvanhoof> pvanhoof@lort:~/Temp$ file ./olpc-2006_02_06_16_08.ext3
<pvanhoof> ./olpc-2006_02_06_16_08.ext3: x86 boot sector, code offset 0x48
<pvanhoof> pvanhoof@lort:~/Temp$
<neuralis> pvanhoof: also, that image is *ancient*.
<sladen> pvanhoof: not  sudo mount -o loop -t ext3 *img /mnt ?
<pvanhoof> yes, I'm downloading a new one
<pvanhoof> root@lort:/home/pvanhoof/Temp# mount -o loop -t ext3 olpc-2006_02_06_16_08.ext3 /mnt
<pvanhoof> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
<pvanhoof> etc
<sladen> pvanhoof: oh, right, they're an ext3 image with a boot block on the front
<pvanhoof> hmm, I can't pass an offset to -o loop?
<pvanhoof> pity
<Fjodor> pvanhoof: You could dd to a new file?
<pvanhoof> right, but that's a new copy.. I'd have to cat after making adjustments
<pvanhoof> more work  :)
<pvanhoof> maybe with one of those reiserfs features ;)
<mjg59> pvanhoof: Not with -o loop, but you can with losetup
<Fjodor> Oh well, just a shot from the hip...
<sladen> pvanhoof: losetup -o 32768 foo.img /dev/loop0
<pvanhoof> never used losetup
<sladen> pvanhoof: then mount that
<pvanhoof> oh, trying
<pvanhoof> ioctl: LOOP_SET_FD: Inappropriate ioctl for device
<sladen> pvanhoof: actually, you can probably just do   mount -o loop,offset=32768 foo.img /mnt
<pvanhoof> doesn't work (maybe the offset is wrong?)
<bluefoxicy> ugh, I can link to a Gentoo bugzilla entry, but not to a bug in the Gentoo distribution.
<pvanhoof> I'll search myself soon .. if I get it to mount, I'll tell you
<sladen> pvanhoof: dd if=foo.img bs=1 skip=32768 | file   ?
<pvanhoof> you want the output of that? I don't think file reads stdin
<pvanhoof> dd if=olpc-2006_02_06_16_08.ext3 bs=1 skip=32768 of=test, I'll file test
<pvanhoof> ... :)
<pvanhoof> it's a gig, so .. it'll take a few seconds
<pvanhoof> # file test
<pvanhoof> test: data
<pvanhoof> I just removed the file, downloading a new version..
<mjg59> Yeah, the orig.tar.gz from Ubuntu is broken
<crimsun_> lovely :/
<mjg59> Let me try the upstream 0.8.0
<mjg59> Upstream 0.8.0 is broken
<netstar> root@snowdrop:/home# ps -e | grep gaim | wc -l
<netstar> 124
<netstar> not good
<netstar> I think there's a bug
<ajmitch> morning
<\sh> netstar: you have what? 124 gaim processes?
<netstar> yes!
<netstar> lol
<netstar> now 137
<netstar> PowerPC
<netstar> Dapper
<netstar> :/
<mjg59> Upstream 0.8.1 also appears broken for me
<\sh> netstar: quickfix? apt-get install gajim ;)
<netstar> every message I send, spawns a new process
<\sh> netstar: if you intend to use jabber only
<netstar> I hope other people don't have this problem, it's BAD
<pygi> mjg59, may I ask what is broken?
<mjg59> pygi: qemu with the olpc dev images
<mjg59> neuralis: How did you build the upstream version of qemu that worked?
<mjg59> I can't get 0.8.1 to run it either
<neuralis> mjg59: it hangs in the same place for you, or do you get a different error?
<mjg59> neuralis: Same place
<bluefoxicy> mjg59:  while on the subject of qemu, I can't seem to get ppc to boot in qemu from x86 or x86-64.  Just something for the back of your mind.
* bluefoxicy goes back to what he was doing.
<mjg59> That's with ./configure --prefix=/usr --cc=gcc-3.4
<neuralis> mjg59: i used identical options. 
<mjg59> Interesting
<neuralis> mjg59: as a sanity check, make sure you're invoking the newly-built binary if you kept the package aroudn
<neuralis> *around.
<mjg59> neuralis: I'm running it from the source tree
<mjg59> Yeah, hard hangs when it gets to IDE probing
<mjg59> Cursor stops blinking
<neuralis> mjg59: i'm happy to toss you this binary, but i'm not sure that'll get us anywhere
<mjg59> Probably not, yeah
<neuralis> yeah, just loaded the image again, works fine.
<neuralis> mjg59: by the way, did you sign up for one of the A-test boards with us? i know we wanted to get you one asap
<\sh> guys, regarding keybuks mail about bzr usage for edgy...who is entitled to use this sftp supermirror? every LP user with ssh pub key attached?
<mjg59> neuralis: Yup
<mjg59> neuralis: At least, I filled in the form - don't think I got any confirmation
<neuralis> okay, that's fine. i'll make sure one gets to you, just wanted a reminder.
<bluefoxicy> who maintains libgcj7/gcc
<bluefoxicy> because I need serious help test-hacking it.
<bluefoxicy> (in about half an hour, after my shower)
<\sh> bluefoxicy: I don't think doko is awake at this time of the day...it's 2am utc+2
<bluefoxicy> \sh:  it.
<bluefoxicy> \sh:  well if you see anyone else who knows htf I can get a command run immediately after all tarballs are done being unpacked.....
<bluefoxicy> bluefox@icebox:/tmp/x/gcj-4.1-4.1.0$ ls
<bluefoxicy> debian  gcc-4.1.0.tar.bz2
<bluefoxicy> (no I don't know why dapper has gcc 4.0.3 and gcj from 4.1.0)
<bddebian> Howdy
<Riddell> what provides the low disk indicator in gnome?
<crimsun_> Riddell: gnome-volume-manager
<Riddell> crimsun_: but of course :)
<bddebian> Heya crimsun_
<crimsun_> 'lo bddebian 
<bluefoxicy> is Edgy going to gcc 4.1.0 or 4.1.1?
<ajmitch> bluefoxicy: see edgy-changes.. 4.1.1 is there
<bluefoxicy> ajmitch:  edgy-changes ... mailing list, wiki, etc?
<ajmitch> mailing list
<bluefoxicy> thanks.
* bluefoxicy checks the source code for gcc 4.1.1 from mainline
<ajmitch> doko tracks the 4.1 branch in SVN, it seems
<bluefoxicy> ajmitch:  I'm trying to figure out why the heck we have executable stacks on libffi and libgcj
<doko> ajmitch: what's the problem?
<bluefoxicy> Gentoo doesn't have them, and I checked the code, it looks sane to turn the PT_GNU_STACK off
<ajmitch> doko: no problem :)
<bluefoxicy> the cause seems to be that a few .S files do not have .note.GNU-stack in them, so binutils goes "WTF?  I dunno I'll just assume tehy want an executable stack" when it sees the .o file during linking
<\sh> oh another one who can't sleep...moins doko :)
<bluefoxicy> but I don't see a patch for it in gentoo's CVS
<bluefoxicy> (not that fixing it is that hard..)
<bddebian> Heya Hobbsee
<Hobbsee> hey bddebian 
<\sh> moins Hobbsee
<bluefoxicy> ok guys I'm going to not pretend I understand wtf any of this says, since I don't know powerpc assembly.  x86 looks fine.
<Hobbsee> hey \sh 
<Hobbsee> anyone got a heater?
<\sh> Hobbsee: if a flat under the roof is passing as a heater, then yes ;)
<bluefoxicy> I have a small chihuahua, he's kind of warm, you can hold that.
<Hobbsee> hehe
<Hobbsee> oh thankyou
<bluefoxicy> weird.. hm.
* bluefoxicy does a ./configure to see if a GNU-stack section gets injected into any .S files.
<bluefoxicy> tseng:  OK I can't figure this out, the tree references .note.GNU-stack but doesn't seem to insert it anywhere useful.  My verdict is dump one into every .S file, but that's very unscientific...
<sladen> is it getting striped?
<bluefoxicy> sladen:  hmm?
<bluefoxicy> no, it's not strippable.
<bluefoxicy> It's just not getting added.
<bluefoxicy> bluefox@icebox:/tmp/x/gcj-4.1-4.1.0$ scanelf -qeRt . RWX --- ---   ./build/i486-linux-gnu/libjava/.libs/libgcj.so.7.0.0
<bluefoxicy> RWX --- ---   ./build/i486-linux-gnu/libffi/.libs/libffi.so.4.0.1
<bluefoxicy> err.
<bluefoxicy> that RWX should be on the next line... anyway, those are the two output files, the X there indicates they have PT_GNU_STACK marked to give an executable stack
<sladen> can you format/cut-that down and highlight what we're trying to look at?
<bluefoxicy> RWX --- ---   ./build/i486-linux-gnu/libffi/.libs/libffi.so.4.0.1
<bluefoxicy> Memory protections on the stack will be PROT_READ|PROT_WRITE|PROT_EXECUTE when this library is loaded.  This was scanelf'd after a dpkg-buildpackage in the source tree for libgcj; those two .so.* files become libraries that get packaged and later installed.
<bluefoxicy> !WX --- ---   ./build/i486-linux-gnu/libffi/src/x86/.libs/sysv.o  <---- There are four output files like this.  They are built from corresponding .S input files in libffi/src/x86/.  the "!" indicates that a .note.GNU-stack isn't in the object file
<bluefoxicy> the result f not having that section in the object file is that the linker (ld), when building the shared objects out of it, cannot determine if the objects need an executable stack or not.  it assumes that they want an executable stack, and marks the output file as such.
<bluefoxicy> https://wiki.ubuntu.com/HardenedHacking  <-- this brain dump has an example of me "fixing" gnupg, as per http://www.gentoo.org/proj/en/hardened/gnu-stack.xml ; I should probably note I didn't check the other architectures' assembly at all, I keep forgetting about that entirely
<bluefoxicy> (writing assembly to bounce off the stack is WEIRD anyway, and not normal; it's highly complex and in general just doesn't happen, but it's not IMPOSSIBLE so..)
<bluefoxicy> anyway
<bluefoxicy> What it comes down to is, I don't want stuff having an executable stack.
<bluefoxicy> If it just doesn't need it, get rid of it; if it needs it, then ... well, need to figure out WHY, fix it, and THEN get rid of it.
<bluefoxicy> ("Why" usually == gcc nested function, which requires code rewriting)
<\sh> first time usage of latest dapper firefox, and it connects to www.google-analytics.com?
<bluefoxicy> \sh: zomg spywarz!
<\sh> well, it's only for first time usage somehow...WTF
<jsgotangco> yeah WTF indeed
<\sh> I grep the source
<\sh> or whereever it hides
<dieman> yeah, weird
<jsgotangco> upstream firefox changes the frontpage for the first time for any update but since we backport fixes we should still get the welcome to ubuntu homepage
<\sh> jsgotangco: it comes
<Hobbsee> on kde, it doesnt show the standard gnome page for firefox anyway, does it?  doesnt it usually show another form of help page?
* Hobbsee is using the mozilla binaries, so cant test...
<\sh> jsgotangco: the problem is, when you want to connect to another website...for the first time. and I'm sure, that heise.de doesn't have any links or images or ads to www.google-analytics.com
<\sh> Hobbsee: it shows the kde page
<Hobbsee> oh right
<\sh> ok it's not firefox
<\sh> but I found this: http://www.managersim.com/blog/index.php/?p=3
<bluefoxicy> \sh:  how about package with Adblock, filterset.G updater, and a block on google-analytics in the default install ;)
<\sh> bluefoxicy: no...I'll set 127.0.0.1
<bluefoxicy> \sh:  I have an interesting question
<bluefoxicy> How many people actually realize that adblock + filters + etc actually undermine the economic model of various businesses?
<bluefoxicy> interestingly enough adblock doesn't kill google ads... even with filterset.G... and not because it "can't"
<Hobbsee> bluefoxicy: probably most of them, but dont really care.  it's kinda like junk mail - it costs them, and they get close to nothing out of it.'
<bluefoxicy> Hobbsee: nods.
* Hobbsee updates her filterset g
<\sh> bluefoxicy: google is a firefox sponsor, right? 
<Hobbsee> oh score!  you can append to the adblock filters, not overwrite them!
<bluefoxicy> \sh:  yeah, but I was more thinking google is the only one doing TEXT ads en masse, and the developers of adblock and adblock filter sets seem to be purposely ignoring these
<bluefoxicy> I've seen wide commentary that people find text ads unintrusive, they find pages with those instead of huge flash or rapid-transition gif ads (100mS cycling through 5 colors?!) more attractive, etc
<bluefoxicy> It makes me wonder, are we shaping the market? :)
<Hobbsee> bleck.  flashblock fixes that problem a bit
<bluefoxicy> Think about it.  First we killed pop-ups.  They keep trying but it just bugs people and most site owners got the hint.
<bluefoxicy> Now we block banner ads via any means necessary, even via things like dan's guardian, squidguard, etc; right down to firefox extensions or greasemonkey scripts
* bluefoxicy shrugs.
<bluefoxicy> In the end I wonder if the market will ditch advertisement revenue, or start focusing on unintrusive design, or what
<bluefoxicy> Ah well
<bluefoxicy> I'm probably the only person in the world that actually thinks on that scale :P
<\sh> bluefoxicy: well, if we take the whole web community, and let's say 5% of them are blocking ads, and the other 95% don't care at all...so there is still enough of revenue for the ad machine ;)
<\sh> I'm waiting for googles ads in rss feeds ;=
<\sh> and google ads in google talk voip streams...every minute "we stop your conversation to present to you the new product of 'Brain 2.0'"
<bluefoxicy> imagine google packing adblock with firefox, along with google toolbar
<bluefoxicy> the SEC would shit a brick.
<bluefoxicy> You'd see an army of lawyers in front of Google HQ with the Sherman Anti-Trust Act printed off a billion times
<\sh> Sherman Anti Trust Act? is it valid in china or germany?
<bluefoxicy> no it's the rockerfeller thing I think
<bluefoxicy> back in the day there were two guys who had big businesses.  Rockerfeller was a gigabillionare oil company owner and Sherman had a steel company, IIRC
<bluefoxicy> (sherman got $300 million over the life of his company)
<\sh> sherman as in tanks?
<bluefoxicy> Maybe.  I don't remember the exact details anymore.
<bluefoxicy> But the point is
<bluefoxicy> they had a nasty habit of buying both their competetors and their suppliers.
<bluefoxicy> SO picture an oil company.  They buy the company that makes the drills, the pumps, and the steel that's used to make them, and the mining company that mines the ore that it sells the steel co.
<bluefoxicy> Things become VERY cheap.
<bluefoxicy> The whole markup chain is gone.
<bluefoxicy> On the other side, you have people in your market compteing with you, who you simply either A) buy out; or B) make unprofitable, usually by fixing your prices far too low (via the vertical monopoly)
<\sh> ok..sorry to interrupt you, but I have to go to work...I think amu is waiting for me downstairs :)
<bluefoxicy> oh ok
<\sh> laters...so in 3-4 hours
<bluefoxicy> at any rate laws were made against establishing monopolies this way... blocking competetors' services fits into the mix :)
<bluefoxicy> (i.e. having an ad company and supplieng a product blocking others' ads)
<bluefoxicy> and I'm done
<bluefoxicy> doko:  ping
<crimsun_> (he's probably asleep)
<bluefoxicy> oh
<bluefoxicy> he was awake an hour ago :(
<bluefoxicy> or not.
* bluefoxicy was going to attempt to capitalize on the off chance that he happened to have a built openoffice.org tree hanging about his drive
<bluefoxicy>   RWX --- ---  /usr/lib/openoffice/program/libgcc3_uno.so  <-- this and libflac7 (...wtf?) are responsible for OpenOffice.org's executable stack (what the heck is libgcc3_uno.so by the by?)
<bddebian> Gnight folks
<pitti> Good morning
<pitti> hey ajmitch 
<ajmitch> hey pitti 
<ajmitch> how are you?
<pitti> ajmitch: pretty fine, and you?
<ajmitch> doing alright
<ajmitch> plenty to do :)
<dholbach> good morning
<dholbach> What are the uploads that need to happen to let the archive accept uploads again and get stuff built?
<fabbione> dholbach: there are still issues with souyz
<fabbione> dholbach: otherwise only gcc-default i think
<dholbach> go go go go go!
<dholbach> :-)
<pitti> iwj: funny, '$ yelp' crashes even in current breezy; no wonder it crashed in a chroot
<dholbach> urg
<dholbach> I suppose yelp, galeon, epiphany etc have to be rebuilt
<sivang> morning all
* sivang just watchd intresting pogram on 3sat regarding security, exploits, and CLam-AV  for windows ;-)
<sivang> they are now stressing how important it is to secure a WLAN 
<pitti> dholbach: I mean even before installing ffox 1.5
<pitti> sivang: the only reason for securing a wlan is access protection; depending on your quota/bandwidth it might not be that important :)
<dholbach> pitti: did we have other firefox update or security uploads before?
<pitti> dholbach: sure, from 1.0.7 to 1.0.8 in breezy
<azeem> pitti: well, legal issues might be involved, too, if somebody is doing something illegal while using your bandwidth
<pitti> dholbach: oh, the 'Help' entry in the System menu works fine, just 'yelp' in a shell crashes
<dholbach> pitti: might be that the exposed symbols changed in that release as well
<dholbach> pitti: could you have a look at the backtrace?
<dholbach> pitti: anything Firefox-related?
<pitti> dholbach: and pressing F1 in the terminal and on desktop works as well (with current breezy-security)
<pitti> dholbach: so it's not that important for the current version
<pitti> dholbach: hm; call me whatever, but now 'yelp' works in a shell as well
<pitti> dholbach: seems it started a daemon or whatnot
<dholbach> urg!
<dholbach> ... cosmic rays
<dholbach> or something
<sivang> pitti: they just showed how to someone uses aircrack over all his block neighbour  and then tells them how to secure it :)
* sivang notes the word Linux is repeated rather often  - wish this was the same for computer programs on TV In ,il :-)
* pitti takes the plunge and dpkg -i's ffox 1.5
* dholbach hugs and comforts pitti
<pvanhoof> mjg59, about the qemu problem and OLPC images: I still have the problem with non-ancient OLPC images
<mjg59> pvanhoof: Yes. I don't understand the problem
<mjg59> I can reproduce it with upstream source
<pvanhoof> ok
<mjg59> Which implies toolchain or something
<pvanhoof> lets talk with the author?
<pvanhoof> of qemu
<mjg59> I'm really lacking the time to right now, but feel free
<dholbach> does anybody know about the nature of the soyuz problems we're having?
<lifeless> mjg59: who is the right person to talk with about loading ac and battery earlier ?
<lifeless> mjg59: There is a bug they should be aware of.
<mjg59> Me
<mjg59> (probably)
<kagou> hi
<lifeless> mjg59: https://launchpad.net/distros/ubuntu/+source/powermgmt-base/+bug/49240
<Ubugtu> Malone bug 49240 in powermgmt-base "on_ac_power script returns 255 during boot" [Untriaged,Confirmed]  
<kagou> pitti, around ?
<pitti> kagou: yes
<kagou> pitti, there is a security issu in dovecot : http://www.dovecot.org/list/dovecot-news/2006-May/000006.html that is included in the debian package http://packages.debian.org/changelogs/pool/main/d/dovecot/dovecot_1.0.beta8-2/changelog
<kagou> pitti, i don't know if this is important so i just point you that
<pitti> kagou: I already fixed dapper a few weeks ago, and breezy/hoary are not affected
<pitti> kagou: but thanks for cross-checking :)
<kagou> pitti, np :)
<kagou> pitti, can we have changelog page like in debian http://packages.debian.org/changelogs/pool/main/d/dovecot/dovecot_1.0.beta8-2/changelog or may be i miss that
<pitti> kagou: changelogs.ubuntu.com
<pitti> kagou: btw, http://changelogs.debian.net/dovecot <= easier to type
<kagou> pitti, i mean integer in launchpad :)
<pitti> kagou: not yet AFAIK
<pygi> sivang, poke? :P
<kagou> ok :p
<kagou> pitti, may be i found a bug in dovecot, because /etc/init.d/dovecot require to test inetd.conf but this file is not installed in  default installation
<kagou> pitti, if you agree with me i open one
<iwj> pitti: Hi.  I've just been reading your messages ...
<pitti> iwj: good morning
<dholbach> fabbione: you said there was trouble with soyuz regarding "opening edgy for real usage" - do you happen to know what the problems are?
<pitti> dholbach: at first it was due to getting the toolchain debs as very first updates; no idea about recent problems
<fabbione> dholbach: i think that at the moment edgy is missing _all.deb packages. i *think* they are not published properly, but infinity knows the details
<fabbione> dholbach: you can see that today you can't install gcj
<dholbach> :-(
<fabbione> at least this morning..
<fabbione> i am syncing the mirror now
<dholbach> the gnome 2.15 releases are piling up, I'd love to get them in asap or else we'll have a badly tested gnome :-/
<dholbach> but I stop complaining
<tseng> dholbach: i thought the same
<sivang> dholbach: get them in for dapper?
<dholbach> sivang: 2.15???
<sivang> dholbach: oops sorry, no :-)
<dholbach> what I thought
<fabbione> dholbach: don't worry... you will have a lot of time for the entire edgy cycle...
<dholbach> fabbione: plus one week paris, then one week guadec -- i personally think ~8 weeks less testing will make a difference
<tseng> dholbach: we can do a hackerfest at guadec and get it in
<dholbach> plus whatever time it takes to make the archive happy and accepting+building stuff again
<tseng> dholbach: ill be your helper
<dholbach> tseng: sounds like a cool idea
* dholbach hugs tseng and dances happily around him
<tseng> woo!
<tseng> it can be like bootstrapping mono on amd64 from a udu bof
<dholbach> only 21 tarballs for dapper-updates and 56 for edgy left
<dholbach> ROCK ON
<dholbach> but seb128 has some of them pending, so it's actually not that bad
<dholbach> merging the debian changes and doing the splitting according to upstream changes takes quite some time
<tseng> ok i need to get to work
<tseng> bye dholbach 
<dholbach> have a nice day tseng!
<fabbione> dholbach: don't worry.. there is going to be a release schedule meeting in Paris, in which you can propose to split the 6 weeks delay of dapper into edgy and edgy+1
<fabbione> dholbach: giving us 3 weeks "extra" for edgy
<fabbione> if you and all the others there will do the same, it will happen
<dholbach> fabbione: if edgy is going to be the "it's broken" release, having 6 weeks less is fine for me, if we then can get back to our old rhythm
<dholbach> so it will be x.04 and x.10 again
<dholbach> and match gnome's release schedule too
* sladen is in two minds about that.  2 short release of hell is not necessaryily better than one release of hell and back to normal
<sladen> and by stealing that time from edgy+1 it's making edgy+1 into a worse release;  and without the excuse the "Dapper just released, with is exceptional"
* mvo goes for lunch
<fabbione> sladen: we still need to provide 18 months support on edgy
<sladen> where did the netinst CDs go
<sladen> fabbione: and 18months of support edgy+1
<fabbione> you don't want to endup having to fix edgy while doing edgy+1
<fabbione> sladen: right, splitting the 6 weeks into 2 is more even than killing one release for good
<fabbione> 3 weeks of less development are sustainable
<fabbione> 6, i doubt
<fabbione> sladen: netinst are on archive.u.com/ubuntu/dists/dapper/main/
<fabbione> install-$arch and follow the paths
<sladen> fabbione: thanks;  I'd been hunting cdimage.u.com
<sladen> those don't appear to be netinst ISO's.  rather the files needed for netbooting
<fabbione> sladen: what arch are you looking for?
<zul> heylo
<ajmitch> hey zul 
<zul> hey ajmitch how goes it?
<fabbione> sladen: http://archive.ubuntu.com/ubuntu/dists/dapper/main/installer-i386/current/images/netboot/mini.iso
<ajmitch> too cold here to do much this evening :)
<zul> heh
<ajmitch> well, it's not too bad actually
<fabbione> meh i wish somebody would like to change with me...
<fabbione> i hate this 26/28C
<fabbione> and i can't turn on my toys or they will melt down
<zul> thats not too bad.
<fabbione> zul: it is for me :(
<fabbione> i hate this warm weather
<fabbione> tho it lasts only a week or two here
<ajmitch> fabbione: I'd swap, but you'd hate the connectivity here
<zul> bloody third world ;)
<ajmitch> I reckon
<fabbione> ajmitch: "here" as in .au?
<ajmitch> .nz
<fabbione> oh the other side of the world.. it wouldn't work either.. last time i was there, i had issue to hold to the world with the hands and type with the feet
<ajmitch> you sure that wasn't just because of the local beer?
<fabbione> eheh
<Mithrandir> ajmitch: just hack harder and you'll generate heat. :-)
<ajmitch> heh
<hunger> When will the syncing with debian start for edgy?
<fabbione> hunger: once the toolchain is all in place
<fabbione> and soyuz proven to be stable enough
<triceratops> How will drivemount-applet show an icon for unmounted devices? Since Dapper only for mounted drives icons are shown. It's a bit anoying because there is nothing to see from drivemount-applet in the panel. I accidental / occassionally noticed this behaviour whilst I added three drivemount applets to the panel. And I would bet a lot of novice users will run into this...
<hunger> fabbione: Thanks for the info.
<fabbione> hunger: might be anytime soon tomorrow
<fabbione> tomorrow -> within the next 24/48 hours
<zul> *whine* but i want it now..
<Hobbsee> zul: what's this for?
<zul> i was being sarcastic
<fabbione> zul: do you realize that if you want to do -security you can't really run the latestest, but better to have N partitions with all the -stable -oldstable -veryoldstale releases?
<zul> fabbione: i realize that 
<zul> and i already have that 
<fabbione> so you don't need edgy till it's -stable or -oldstale
<janimo> is it expected that uploads to dapper-updates send Rejected mails? I know they need manual approval
<fabbione> janimo: did you coordinate the upload?
<fabbione> otherwise it might have been rejected manually
<fabbione> not all uploads are approved for -updates
<janimo> fabbione: yes mdz approved it
<jordi> mdz: time to revisit nano for dapper?
<Keybuk> "revisit" ?
<fabbione> dapper?
<fabbione> jordi: dapper has been released ;)
<fabbione> jordi: btw.. marga was looking for you around
<jordi> fabbione: I know. I need to have some private conversations about this in the evening
<jordi> Keybuk, fabbione there was some fixes to nano punted until the release was done as it would have meant a di rebuild
<fabbione> jordi: there will be relatively soon a d-i upload
<fabbione> jordi: so if there is something that needs to go in, you better hurry up 
<janimo> jordi, are rosetta translations going to be uploaded in dapper-updates in a few days?
<janimo> I sent carlos a .po file (thunar/romanian) a while ago, he said he had uploaded it but in rosetta I only see the state before that
<jordi> janimo: yes
<jordi> hmm
<jordi> janimo: can you upload it again?
<jordi> or send it to me
<zyga> hi
<zyga> does anyone know if SABDFL will sign gpg keys today in warsaw?
<tseng> the only people who know mark's schedule are probably himself and cvd
<Hobbsee> who's cvd?
<tseng> Claire Davis.. the only woman brave enough to tackle Mark's schedule
<ogra> Hobbsee, marks awesome schedule managing machine 
<Hobbsee> ah
<tseng> I heard she is being integrated with Launchpad
<Hobbsee> well, women are good at organisation, you know...
<lifeless> tseng: Mark probably doesn't know. All hail cvd.
<tseng> lifeless: true.
<Keybuk> ah yes, the legendary sabdfl "what am I talking about again?"
<lifeless> 'where am I' ?
<zyga> shees ;] 
<zyga> I want to know if it makes sense to print my gpg fingertpint a couple of times
<lifeless> it always makes sense to do that
<janimo> jordi, I just sent you the .po file
<jordi> janimo: ok
<highvoltage> where's marelize?
<highvoltage> it's her birthday today. i guess i'll have to walk over to her building to congratulate her then :)
<jsgotangco> whoa happy birthday miss shipit
<Hobbsee> jsgotangco: happy birthday to ajmitch too, even though he doesnt want to admit to it  (it still is, in most timezones)
<jsgotangco> whoa i didnt know that
* jsgotangco was ajmitch's roommate during UDU
<Hobbsee> i'm pretty sure it is - it's either the 10th or the 12th
<Hobbsee> and his jabber says the 12th, but also says the wrong year..
<G0SUB_> pitti: hello!
<pitti> hello G0SUB_ 
<G0SUB_> pitti: I have a bad Internet outage in my place :(
<G0SUB_> pitti: can we have the meeting tomorrow?
<pitti> G0SUB_: of course
<pitti> mvo: are you available tomorrow for a meeting with G0SUB_ ?
<G0SUB_> pitti: thanks a lot :) the specs are all done. I just need to update the wiki
<mvo> pitti: yes
<G0SUB_> fine, see you guys ... sorry for today :(
<highvoltage> someone should tell sabdfl that html pink backgrounds are not cool
<highvoltage> (me didn't say that, by the way)
<spacey> :p
<jsgotangco> HAHAHAA
<jsgotangco> highvoltage: think of it as him experimenting edgy backgrounds
<Hobbsee> we will *not* have a pink desktop!
<Hobbsee> pink is not a cool colour for a desktop.
<Mithrandir> Hobbsee: but it'll attract women!!1oneone
<Hobbsee> Mithrandir: let me tell you, that it wont :P  hehe
<Hobbsee> being one myself :D
<Hobbsee> Mithrandir: how about a lilac desktop?  *ducks*
<Mithrandir> Hobbsee: you're a statistical sample of one, and therefore not very interesting (statistically speaking)
<Hobbsee> heya bddebian 
* Hobbsee goes and sits in a corner and sulks
<Hobbsee> well thanks a lot Mithrandir :P
<bddebian> Hi folks
<bddebian> Hi Hobbsee
<Mithrandir> Hobbsee: I like lilacs.
<Hobbsee> Mithrandir: you know what lilac is?
<Mithrandir> Hobbsee: yes, we have a ton of them in the garden at my father's
<Hobbsee> oh wow!
<Mithrandir> their colour isn't always lilac, though.  We have a bunch of white-ish ones too.
<Hobbsee> the guys at school were most annoyed that they had to know what colour lilac was, and how it was different from violet - they thought that was most injust!
<Mithrandir> it was unjust?  I don't see why it'd be that..
<Hobbsee> that they'd be required to know so many colours - and they had to, for chem flame tests
<Hobbsee> anyway, i could be pretty sure that a pink desktop will send popularity way down hehe :P
<Mithrandir> lilacs remind me of Samuel Vimes.
<Mithrandir> so now I have to go hunt for a suitable background for my desktop.
<Hobbsee> hehe
<bddebian> Hey, I could go for a Hot Pink desktop ;-P
<Hobbsee> bddebian: hehe!  bring it to paris, and take lots of pictures to show us who stay behind
<bddebian> I'm not coming to Paris :-(
<Hobbsee> :( why not?
<Keybuk> bddebian: with all-leather cow interior?
<zul> with whale skin hubcaps
<bddebian> Keybuk: Yeah!
<bddebian> zul: No, baby seal ;-P
<bddebian> Hobbsee: Because I'm an ugly American ;-P
<Keybuk> clearly bddebian hasn't heard the same song zul and I have ;p
<Hobbsee> heh
<bddebian> Oh, hmm
<Hobbsee> bddebian: i would worry - i wouldnt think that anyone was actually pretty around here - it doesnt fit the linux stereotype, does it?
<bddebian> Hobbsee: I'm kidding.  I just don't have time/money to go
<Hobbsee> ah :P
<bddebian> And they don't want me there anyway :-)
<Hobbsee> hehe
<Hobbsee> only to tease
<bddebian> Oh yeah, like I need abuse in person :-)
<zul> oh you like the attention
<bddebian> Sure
* Keybuk tickles bddebian 
<bddebian> heh
<Hobbsee> well, as long as the attention is on you, and not on me, then i'm happy :P
<bddebian> Hmm, what to do
* Hobbsee offers her pitchfork to bddebian 
<Hobbsee> would this help?
<jsgotangco> hah japan is kicking au's butt in the world cup
* jsgotangco hides
<bddebian> :-)
<bddebian> Hobbsee: No, I am debating between wading through more Unconfirmed bugs or something else
<Hobbsee> jsgotangco: excellent :P
<Hobbsee> bddebian: fun.   do the bugwork
<zul> jsgotangco: whats the score?
<Riddell> Keybuk: are you able to see what's happened to qt-x11-free 3:3.3.6-1ubuntu4 in dapper-updates?
<Hobbsee> zul: who cares?  :P
<jsgotangco> wtf AU just scored 3 goals in the 2nd half
<Keybuk> Riddell: I am
<Keybuk> Riddell: who approved the upload?
<Riddell> Keybuk: mdz did
<Keybuk> it's still sitting in UNAPPROVED
<jsgotangco> zul: au won 3-1.. i think japan is a bit stunned
<zul> a bit...aus had 20 shots on goal
<Riddell> Keybuk: can you approve it or shall I wait for mdz to turn up?
<Keybuk> Riddell: I'm not sure I can approve it (I can from an archival point of view, I'm not sure I have the power from an authority point of view)
<bddebian> Damn I'm good
<Keybuk> will consult mdz when he's up
<bddebian> Gah, I hate it when RL work gets in the way of Ubuntu stuff :-)
<Riddell> Keybuk: and can you tell me the status of kubuntu-default-settings_6.06-22?
<Keybuk> that one is not unapproved
<Keybuk> when did you upload it?
<sbalneav> ogra: ping
<Riddell> Keybuk: 7 Jun.  launchpad says it needs build
<Keybuk> Riddell: then it needs building
<Keybuk> indeed, it is showing as published here
<Riddell> although launchpad also says the qt updates is needs build
<Keybuk> ubuntu4 vs. ubuntu5
<Keybuk> sorry
<Keybuk> ubuntu4 is indeed published
<Keybuk> ubuntu5 is unapproved
<Riddell> I don't remember uploading an ubuntu5
<Riddell> so I should poke infinity about getting qt ubuntu4 and kubuntu-default-settings_6.06-22 compiled I guess
<Keybuk> yup, buildds are on manual
<Keybuk> because people insist on uploading to edgy
* Keybuk looks at a suspicious qt-x11-free upload <g>
<Keybuk> Changed-By: Matthias Klose <doko@ubuntu.com>
<Keybuk>  qt-x11-free (3:3.3.6-1ubuntu5) dapper-updates; urgency=low
<Keybuk>  .
<Keybuk>    * Use ~/.qt-32 as user config directory, when running the i386
<Keybuk>      binaries on amd64.
<Keybuk>  .
<Keybuk> for qt-x11-free in dapper-updates
<doko> Keybuk: doesn't it work anymore? it's still working on my laptop ...
<Keybuk> doko: doesn't what work anymore?
<Riddell> doko: will that have overwitten my changes in ubuntu4?
<doko> Riddell: why should it?
<Keybuk> doko: who did you ask for approval before uploading that to dapper-updates ?
<Riddell> doko: my ubuntu4 had changes for arabic fonts, did you include that?
<doko> Keybuk: mdz and Kamion, will be followed by an upload of ia32-libs-kde
<Keybuk> meh, we so need a procedure here <g>
<doko> Keybuk: we have one, but you are not in the loop ...
<Riddell> I'm not entirely in the loop either, launchpad should have a nice big notice that says "buildds are on manual, poke infinity"
<Keybuk> Riddell: it does
<doko> Riddell: hmm, overwritten. didn't see that ubuntu4
<Keybuk> doko: that seems silly, given I'm the one who actually makes things appear in the archive atm :p
<Hobbsee> Keybuk: i'm starting to be of the opinion that you should have said "no, edgy is not open", and worked on the toolchain in almost-full secrecy
<Keybuk> though I mean a procedure for mdz and kamion to indicate that a future upload is approved, so that me or infinity know to actually approve it
<Keybuk> Hobbsee: we have said "no, edgy is not open"
<Hobbsee> oh
* Hobbsee wonders why she hasnt heard that somewhere else before this.
<doko> Keybuk: agreed, just announce it, that approval mails have to go to infinity and you as well
<Riddell> doko: if you send me what you uploaded for qt ubuntu5 I can put in my patch and make an ubuntu6
<Keybuk> Riddell: is there any particular reason you expect your patch to be missing?
<Riddell> Keybuk: doko just said it was overwritten
<Keybuk> http://people.ubuntu.com/~scott/dokos.patch
<doko> Riddell: could you send it me? or is -ubuntu4 in the archive ?
<Keybuk> I see your point
<Riddell> doko: it's in the archive
<Riddell> kubuntu_01_arabic_fonts.dpatch and 00list are the changed files
<doko> Riddell: ok, preparing an ubuntu6
<Riddell> thanks doko 
* Keybuk goes for lunch (really, this time)
<janimo> mdz: I have uploaded the fixes I mentioned to dapper-updates
* ..[topic/#ubuntu-devel:Riddell] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | Uploads on manual, don't upload to edgy yet
<mdke> Znarl: you were looking for me earlier? still around?
<neuralis> mjg59: ping
* pygi pokes sivang ;)
<ogra> sbalneav, latepong
<sbalneav> ogra: hey!  You ever use qemu for emulating a thin client?
<ogra> i often tried to, but i'm to impatient i guess and gave up after 30min watching usplash slowly scroll
<jsgotangco> lol
<sladen> 30minutes?!
<ogra> before i gave up, yes
<ogra> (runnong quemu on ppc emulating i386)
<sbalneav> Just trying to get my ducks in a row for Paris.  
<ogra> take vmware then 
<ogra> it should be reaqsonable fast
<Keybuk> mdz: heya, got a few minutes?
<pygi> ogra, how useful would it to be to make a small utility to generate VM machines for VMware player?
<ogra> pygi, no idea, i'm not a vmware user
<pygi> ogra, oki :)
<ogra> (is the one we ship in universe now the player ?)
<pygi> I think that player is in multiverse
<ogra> oh, right, it is ...
<mdz> Keybuk: sure
<Keybuk> mdz: there's a reasonably large stack of things in dapper/unapproved at the moment -- and no way to know whether you or Kamion have actually "approved" the upload
<Keybuk> also any accept at the moment requires a manual publisher run _and_ manually running through the buildds
<Keybuk> could the process be updated so that infinity and I are at least cc'd so we know to do the right things?
<bddebian> OK, what is this?  /usr/bin/ld: cannot find -lQtGui_debug
<bddebian> I'm missing libqt4-debug?
<bddebian> Holy crap, 51Mb
<mdz> Keybuk: yes, makes sense (more so if we had an email address for ubuntu-archive)
<Keybuk> jdub: ^ could we get one of those ? :)  (as a mailing list: mdz, kamion, infinity, I)
<mdz> Keybuk: <team name>@launchpad.net ought to be made to just work
<Keybuk> mdz: then mdz@launchpad.net would work too, no? :p
<ogra> doesnt <team name>@ubuntu.com work ?
<ogra> (isnt that how malone handles team subscriptions to bugs ?)
<dholbach> ogra: no, that doesn't work
<ogra> hmm, how does malone handle it then ? internally in LP ?
<Keybuk> mdz: until LP supports that, are you ok with a private mailing list (as with tb)
<Keybuk> ogra: ubuntu-bugs is a mailing list
<ogra> Keybuk, i'm talking about the teams like edubuntu-bugs etc
<ogra> that seems to work via malone without probs
<mdz> Keybuk: I don't specifically object, but it gets awkward to maintain so many small lists for teams
<Keybuk> oh, the bug subscription stuff just iterates the team, iirc
<Keybuk> mdz: the alternative is that we deal with it by asking for bugs to be subscribed and not via e-mail
<sbartleylinux> mjg59: ping
<bddebian>  /usr/lib/libQtGui_debug.so.4  has no symlink libQtGui_debug.so
<Keybuk> bddebian: do you have the -dev installed?
<bddebian> Oh, -debug-dev.. Sheesh
<bddebian> Oh, like 51Mb for libqt4-debug wasn't enough? :-)
<bddebian> bitchin', thanks Keybuk
<Riddell> Keybuk: is there a spec for network-manager plans in edgy?
<highvoltage> if i create an ubuntu dvd image, do i need to do anything different, as apposed to a cd?
<highvoltage> d-i doesn't seem to find the dvd :/
<msikma> Maybe your BIOS can't read DVDs from startup, while it can read CDs. You should ask at #ubuntu, though, this is a channel for development and not for support.
<highvoltage> msikma: ok.
<dholbach> TheMuso: hello! do you happen to know what lsr is?
<dholbach> TheMuso: I saw the release announce on gnome's ftp-release list today and somebody complained about it on ubuntu-accessibility@ - if it's a11y stuff - we maybe should look into getting it into edgy :-)
<Burgwork> dholbach, a linux screen reader, written in python, developed by IBM
<Burgwork> dholbach, upstream seems to liek Orca, another screen reader, written in python, developed by SUN
<Burgwork> dholbach, don't ask
<dholbach> ah, now I remember
<dholbach> well funny both turn up on ftp-release list then
<dholbach> :)
<jdub> dholbach: i've been talking to the LSR folks to see what we can do about the mess - unfortunately, licensing is involved
<Burgwork> jdub, LSR is CPL, no?
<jdub> yes
* dholbach has no idea about the licensing world
<Keybuk> Riddell: back
<Keybuk> quick trip to Wal-Mart there
<Keybuk> Riddell: there are no plans for network-manager in edgy
<Keybuk> I would really like to just "sit back and wait"
<mjg59> neuralis: Hi?
<mjg59> sbartleylinux: Hi?
<sbartleylinux> mjg59: Hi.  Can you tell me who I would talk to about gnome-power-manager?
<mjg59> In what respect?
<sbartleylinux> It seems that with Dapper, it is allowing remote users the selection of Hibernate on exit.  
<mjg59> That's not gnome-power-manager
<sbartleylinux> hm
<mjg59> That's gnome-session
<mjg59> It shouldn't actually /work/ in any case
<sbartleylinux> but it does.:)
<sbartleylinux> I spoke w/ lmanul this morning and was told that gnome-session is relying on gnome-power-manager now for this.
<sbartleylinux> I know that I can make it so on a per user basis, with gconf-editor, this can be turned off.  What I want though is for hibernate to be handled in the same way that restart and shutdown are.
<Riddell> Keybuk: ok, thanks
<sbartleylinux> If the user is remote, it will simply not appear.
<mjg59> sbartleylinux: So please file a bug
<Keybuk> Riddell: my vague hope is that it'll enter Debian unstable (if it hasn't already), we'll sync up and have identical (or near enough) packages, and then we can just keep track that way
<Keybuk> it's not something I think we should put any additional effort into, at least, not until it works better
<sbartleylinux> ok, but against which package?  I am unsure if it is truly gnome-session or g-p-m and dont know who to talk to and verify it.
<mjg59> sbartleylinux: I believe it to be gnome-session (as mentioned above)
<sbartleylinux> ok.  I will start there.  thx.
<mjg59> If that's wrong, it'll just be reassigned to the correct place
<neuralis> mjg59: hi. i can bring your pcb to paris with me. would you prefer that, or have it shipped to the address you gave?
<sbartleylinux> k. thx.
<mjg59> neuralis: I'm not going to be in paris, I'm afraid
<neuralis> mjg59: ah, okay. we'll get it mailed out, then.
<mjg59> neuralis: Thanks!
<neuralis> sure thing.
<mjg59> sbartleylinux: Anyway, if the hibernate button does appear remotely and works, that's certainly a bug
<mjg59> It's not meant to work unless you logged in at the console
<sbartleylinux> k. that is what I thought.  Filing bug now. thx.
<Keybuk> doko, Riddell: the ubuntu5 is a *bad* qt-x11-free, yes?
<Riddell> Keybuk: yes
<Keybuk> ok, rejected
<Keybuk> slomo: ping
<slomo> Keybuk: pong
<Keybuk> slomo: who approved your upload of xine-lib?
<slomo> Keybuk: mdz ~1 week ago... i already thought it disappeared ;) but now i have to upload a new version anyway because of the security update that pitti uploaded some days ago
<Keybuk> ok, shall I reject this one then?
<slomo> yes, i'll upload one with a correct version number later today or tomorrow... which version would that be btw? the security update is 1.1.1+ubuntu2-7.1... -7.2?
<Keybuk> 7.2 would work
<slomo> ok
<sbartleylinux> mjg59: Bug #49503 
<Ubugtu> Malone bug 49503 in gnome-session "Hibernate button being displayed and functions on remote connections" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49503
<Riddell> mjg59: /msg
<zul> heylo
<drt> hello! i hope this is the right channel to ask a question with regard to ubuntu-dapper-server and ubuntu-dapper-desktop. 
<drt> ubuntu-dapper-desktop has flex (lexical analyser) that i can install using apt-get. 
<drt> but flex is not available in ubuntu-dapper-server???
<crimsun_> drt: flex is in main and available via $apt
<drt> crimsun_, sorry...can you elaborate a little?
<crimsun_> drt: given a viable Internet connection, you should be able to ``sudo apt-get install flex''
<crimsun_> drt: your /etc/apt/sources.list needs to have the active (uncommented) line: deb http://archive.ubuntu.com/ubuntu dapper main restricted
<crimsun_> drt: if you need further assistance, I'm happy to assist you in #ubuntu
<drt> crimsun_: thank you. i will join #ubuntu
* mvo goes to bed
<vdepizzol> what do you think about this bountie in launchpad? https://launchpad.net/bounties/filechooser-thumbnails
<zyga> whoo :)
<zyga> mark is such a great guy :)
<Burgwork> zyga, oh?
<zyga> Burgwork: the meeting was so not linux-fanboy-like
<Burgwork> zyga, which meeting?
<zyga> Burgwork: the one in Poland, today
<zyga> 7pm local time
<zyga> +0200 UTC
<Burgwork> ah, cool
<zyga> hey pitti :)
<pitti> hi zyga 
<zyga> how are you?
<zyga> I've seen mark today :)
<pitti_> bah, NetworkManager and dhclient fighting each other
#ubuntu-devel 2006-06-13
<delire> hi, i'm helping someone remotely to capture information so that we can submit a bug. the person has very little linux ability. can i describe the bug here and ask what we should look at capturing?
<bddebian> Heya
<Burgwork> delire, what sort of bug?
<imbrandon> heya bddebian
<bddebian> Hi imbrandon
<delire> Burgwork: the user changes the panel size on a machine recently upgraded from Breezy to Dapper and cannot log in thereafter. i suggested mv'ing ~/.gconf, which did away with the problem. there's nothing conspicuous in ~/.xsession-errors. 
<delire> Burgwork: she's an older user, with troubles following commands to write in the terminal, so i want to know what to capture to reduce the load at her end. especially so as it doesn't end up "Unconfirmed" in malone.
<Burgwork> delire, hmm, sorry, I don't know off hand and don't have time to help you
<delire> Burgwork: no problem.
<delire> i look forward to an auto-bug-reporting mechanism for this reason ;)
<bddebian> Heya Keybuk
<Keybuk> heyho
<ajmitch> hello Keybuk 
<jsgotangco> good morning
<bddebian> Heya jsgotangco
<whiprush_> jdub: ping
<whiprush_> jdub: ping
<jsgotangco> whiprush_: !
<whiprush_> hi jerome.
<zul> make[5] : *** [sound/pci/cs46xx/cs46xx.o]  Error 1
<zul> make[4] : *** [sound/pci/cs46xx]  Error 2
<zul> make[3] : *** [sound/pci]  Error 2
<zul> make[2] : *** [sound]  Error 2
<crimsun_> jah, fun.
<infinity> You kinda missed the critical line from that:
<infinity> sound/pci/cs46xx/cs46xx.c:172: error: 'snd_cs46xx_resume' undeclared here (not in a function)
<crimsun_> yeah, already spotted in query, pushing brown paper bag typo fix now.
<crimsun_> interestingly enough I caught the "state" one but not that one :/
<bddebian> Doh
<rredd4> is it possible to add commands like apt-get install, apt-cache search, etc... to a console menu?  I am not a programmer or I would try myself.. 
<stuNNed> what is the one liner to install ndiswrapper-source in dapper?
<stuNNed> or rather can i use a .exe in ppc in ubuntu w/ndiswrapper?  i know this is a support question but not sure
<stuNNed> i found link, shut up
<Hobbsee> BenC: ping?
<desrt> BenC; pong.
<BenC> Hobbsee: pong
<Hobbsee> BenC: just wondering if https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/39315 is in the archive - got a user most desperate to have it :P
<Ubugtu> Malone bug 39315 in linux-source-2.6.17 "Keyboard random repeat " [High,Fix committed]  
<Hobbsee> had a look in dapper-changes, but couldnt see it there specifically in the changelog - i probably missed it.
<BenC> couldn't you just check the archive to find that out? :)
<BenC> no, it's not there yet, but will be soon
<Hobbsee> hehe meany - if  i could figure it out, then yeah, sure :P
<Hobbsee> okay, cool, thanks
<Hobbsee> if i could have figured it out, then i wouldnt have come askign :P
<dholbach> good morning
<desrt> good day
<janimo> can someone check if xfdesktop is in the upload queue?
<janimo> I got it rejected on Sunday with the following errot
<janimo> error
<janimo> Exception while accepting: type object 'DistroReleaseQueueStatus' has no attribute 'UNAPROVED'
<janimo> I am not sure if it's normal for the current way of handling uploads
<fabbione> jamesh: no, the world is falling apart..
<fabbione> janimo: ^^
<janimo> fabbione: it was for dapper-updates, forgot to mention
<janimo> same Q I asked yesterday btw :)
<fabbione> janimo: yes i got that.. i dunno. it looks like soyuz is on vac
<janimo> I saw there were some uploads let in today though, but the two I uploaded were not among them
<fabbione> janimo: i assume you did target the uploads to dapper-updates
<fabbione> in your changelog i mean
<janimo> fabbione: yes
<desrt> pitti; i have a question for you
<pitti> Good morning
<pitti> hello desrt 
<desrt> hello to you too :)
<desrt> did you buy your ibook in .de?
<pitti> desrt: yes, in June 2004
<desrt> it came with a power brick with a small 2-prong connector and also a longer power cord with a grounded plug on the end
<pitti> desrt: same here
<desrt> is the grounding on the power cord the universal sort of grounding that works in all european countries or is it the sort of one that will only work in germany?
<pitti> desrt: oh, unfortunately not; there are even more grounding formats than prong formats
<pitti> desrt: many plugs can cope with more than one format, though
<desrt> right.  but it's possible to make a sort of plug that works with all of the differnt weird formats
<desrt> so what i'm asking: does apple make that sort of plug?
<pitti> desrt: in .de, the grounding is on the plug's side, e. g. in .ch they have an additional prong
<pitti> desrt: yes, the apple plug has an additional hole for the countries that have a prong for grounding
<desrt> awesome.
<desrt> i think i'll just buy a power adapter at GUADEC then
<janimo> pitti, hi. Do you know how active gnome-cups-manager upstream is?
<pitti> janimo: yes, I know: zero
<janimo> do you know of the plans they may have for 2.16?
<janimo> :)
<pitti> janimo: it basically didn't change since hoary or so
<pitti> janimo: we have to find an alternative, eggcups or something
<janimo> pitti, I am thinking what the best way of having a printer add gui for xubuntu would be
<pitti> but still, printer configuration in gnone lacks love
<janimo> one is modifying g-c-m other to enhance xfprint
<Lathiat> one thign about kde, the printing stuff is quite nice
<pitti> at least printing should get much better, now that gtk itself handles it
<janimo> right, so most (all?) of libgnomeprint is no longer needed
<pitti> indeed
<pitti> and libgnomeprintui, and I hope libgnomecups, too
<pitti> I didn't look at it yet
<janimo> libgnomeprintui still has the samba detection code in it
<janimo> that was what kept it gnome dependent (use of gnome passwd dialog)
<janimo> otherwise it would have been easy to add support for it in xfprint
<bluefoxicy> pitti:  I removed a bunch of executable stacks on things, with a combination of stealing patches from Gentoo and doing my own investigation.
<pitti> good :)
<bluefoxicy> pitti:  there's bugs on it in Bugzilla.  The main one I'm concerned on is #49192, which is libgcrypt11
<bluefoxicy> it prevents logging in with a PaX kernel (since gcrypt11 can't get an executable stack, gnome decides it doesn't want to start, as glibc likes to _exit() because of this)
<bluefoxicy> but more importantly
<bluefoxicy> it causes Gaim, Firefox, Thunderbird, vino-server, and a few others to have an executable stack.
<bluefoxicy> those are particularly interesting because they're nice, network-facing targets, especially if code can be executed on the stack.
<bluefoxicy> the.. last comment tells how to patch the .S files (small shell script because I'm far too lazy to make a patch)
<bluefoxicy> If you patch them, you can build with assembly optimizations and it'll work.
<bluefoxicy> (my initial comment was to disable ASM)
<bluefoxicy> Anyway I am going to sleep.
<TheMuso> c
<\sh> moins
<ajmitch> hi \sh 
<pitti> hey \sh 
<ivoks> hi \sh 
<ivoks> \sh: what's better ejabberd or jabberd2? :)
<\sh> ivoks: ejabberd
<ivoks> \sh: can I integrate it with pam?
<ivoks> \sh: i didn't see it supports pam...
<sivang> morning all
<\sh> ivoks: there are possibilities to include them, as external authentication scripts
<ivoks> ok, thanks
<\sh> ivoks: check the docs and the actual development release
<pygi> mornin' sivang 
* hunger is happy to see the toolchain tickling into edgy.
* sivang thinks of snapshotting chroot's state with bzr
<crimsun_> pitti: ping, am I supposed to be uploading to a different upload queue? (I just got a REJECT from archive@)
<crimsun_> pitti: (sorry, missing context. RE: moodle)
<ajmitch> sivang: probably wouldn't work so well
<sivang> ajmitch: I won't know unless I try ;-)
<pitti> crimsun_: oh, yes, please upload to security.upload.ubuntu.com
<crimsun_> pitti: ah, ok, thanks.
<jono> hey
<sivang> hey jono , how's it going?
<jono> sivang: good thanks, you ?
<sivang> jono: cool , need to get to the last LUG radio 
<jono> :)
<sivang> jono: I've heared it's rather interesting ;-)
<jono> heh
<jono> sivang: well, it is the usual serious, sensible discussion
* jono sniggers
<sivang> hehe
<sivang> aien't it alwasy :p
<sivang> or , always (still in the process of getting used to the thinkpad kbd)
<lemsto> paudio
<lemsto> oops
<sivang> does specs that did not get accepted for Paris so far (status: proposed) mean that they will not get discussed in paris?
<jsgotangco> lol at sladen
<Riddell> doko: did you upload a new qt?
<doko> Riddell: yes
<doko> Riddell: got the accepted message
<Riddell> ok, we'll poke mdz when he's awake to publish it
<pitti> crimsun_: thanks for the moodle upload, publishing now
<zul> heylo
<ajmitch> hey zul 
<pitti> G0SUB: shall we meet today?
<zul> hey ajmitch 
<pitti> hi zul
<zul> hey pitti how goes the battle?
<pitti> zul: the dapper security update is a mess
<zul> pitti: is it? ben did that one
<pitti> zul: there are some problems with the abi checker, and so on; it requires another upload
<pitti> zul: however, Ben's fixes to the hoary and breezy kernel seems to have worked, there are amd64 binaries now
<pygi> hey hey ogra_ibook ;)
<zul> pitti: ok...well Ben took care of the dapper security update but i can take a look at it if you want
<pitti> zul: oh, nevermind; fabbione needs to send Ben some sparc patches anyway, and the powerpc abi failure shouln't be hard to fix
<\sh> tftpds written in ruby are crap...
<zul> pitti: heh...but hoary and breezy works..:)
<ogra> hi pygi 
<\sh> moins btw
<fabbione> pitti: yeah probably we have no patch.. or we are very close to it. i need to talk with mdz
<mdke> no Community Council today?
<mdke> elmo, mako ^
<elmo> no
<elmo> neither mark nor colin are available
<mdke> elmo: ok thanks, in 2 weeks then?
<elmo> that's after udp?  if so, yeah
<mdke> elmo: not sure
<elmo> it is
<mdke> ok
<zul> elmo: i was wondering if had a look at my email i sent you?
<mdke> elmo: do you think there is any possibility of discussing wiki licensing between now and then?
<elmo> zul: the keyring stuff?  I'll have a look when I can, but I'm afraid my time is mostly focused on prep work for paris right now
<zul> elmo: ok not a problem
<elmo> mdke: discuss with who?  
<mdke> elmo: well, with all of you
<elmo> well, Colin's on vacation for this week
<mdke> yeah
<elmo> anyway, not being funny, but I'm late and have to run, bbl
<mdke> elmo: ok
<doko> Unpacking python-subversion (from .../python-subversion_1.3.1-3ubuntu1_amd64.deb) ...
<doko> dpkg: ../../src/packages.c:191: process_queue: Assertion `dependtry <= 4' failed.
<doko> E: Sub-process /usr/bin/dpkg exited unexpectedly
<doko> Keybuk: ^^^
<jpatrick> heno: ping
<heno> jpatrick: hello
<jpatrick> heno: I'm the one about the kubuntu-es.org thing
<heno> jpatrick: yep, you still need space right?
<jpatrick> heno: I believe the only software needed is drupal
<heno> jpatrick: ok, and that needs PHP and MySQL?
<jpatrick> and Apache
<jpatrick> so yep
<heno> jpatrick: ok, I'll set up an account for you and email you some details
<jpatrick> ok
<jpatrick> heno: could I also have an account rouzic - he's the founder of kubuntu-es.org
<heno> jpatrick: yep, and yours would be 'jpatrick'?
<jpatrick> yes, please
<ivoks> um... why doesn't anything happen in dapper-changes?
<pitti> G0SUB: I'll return in about two hours and will be online for the rest of the day
<ivoks> i see lots of sources uploaded, and packages are in archive, but in edgy, not dapper-updates
<ivoks> i.e. https://lists.ubuntu.com/archives/dapper-changes/2006-June/011856.html
<ogra> ivoks, /topic ? 
<ivoks> oh, ok :)
<dholbach> I should have listened to seb128 and never uploaded those kde packages.  I got a mail about kdebindings, because I last touched the package :-)
<jpatrick> heno: is this ssh?
<ogra> dholbach, you are even the "creator" in LP ;)
<dholbach> hu?
<dholbach> i wonder how that happened
<ogra> its a bug in the wording :)
<ogra> it should be "uploader" or something like that instaed of creator 
<ogra> but until someone else touched it LP calls you the creator ... that can have funny side effects like users ranting at you ;)
<jpatrick> heno: nope I can't get in
<Keybuk> "How many gcc uploads does it take to bootstrap a distribution?" :)
<zul> 2
<zul> but not according to the ml
<heno> jpatrick: hm, that was odd. Works now. Perhaps I had capslock on when creating the pw :)
<jpatrick> heno: how do I log in exactly?
<janimo> Keybuk: do you know if xfdesktop ands xfce4-mixer are in the dapper-updates queue? I have uploaded them on Sunday
<Keybuk> they weren't yesterday
<Keybuk> janimo: check your inbox or spam folder
<Keybuk> iirc the uploader was an unhappy bunny on sunday and sending out rejects for everything
<janimo> Keybuk: I got Rejects for them, true but assumed it's part of the manual approval process
<Keybuk> no
<Keybuk> a reject means the archive software threw it away
<janimo> the reason was : Exception while accepting: type object 'DistroReleaseQueueStatus' has no attribute 'UNAPROVED'
<Keybuk> yes, "Exeception" is generally bad :p
<Keybuk> it means your upload got rejected because a screw inside LP went ping
<janimo> I'll reupload then
<Keybuk> who approved them?
<janimo> mdz
<janimo> on Saturday
<Keybuk> could you bounce a copy of his approval e-mail to ubuntu-archive@lists.ubuntu.com
<janimo> Keybuk: done
<Keybuk> thanks
<Keybuk> when cprov gets in, I'll see what the state of LP is
<Keybuk> actually, scratch that
<Keybuk> it's all on auto again
<janimo> Keybuk: I got an Accepted reply now for mixer, so  I uploaded xfdesktop as well. Both should be in the queue shortly
<Keybuk> janimo: heh, don't be too sure :)  for the last week infinity or I have been lifting things out of incoming and into the queue by hand <g>
<janimo> oh, forgot again that incoming != the queue :)
<janimo> or not that queue anyway
<Keybuk> I can never remember whether those accepted mails are generated by poppy or the queue processor
<Keybuk> ok, all approved
<Keybuk> publisher is about to run, so good timing <g>
<janimo> Keybuk: thanks
<Keybuk> buildds are still on manual, so it won't actually build yet
<janimo> I got two accepted  mails per upload. strange
<Keybuk> one is the accepted mail, one is the approved mail
<janimo> one as usual, and one from me to dapper-changes
<janimo> aha
<Keybuk> ie. one tells you it was accepted into the queue (and didn't have a problem)
<Keybuk> and the other tells you an admin approved it
<mantas_> Hi all
<mantas_> mvo, hi, do you have little time to talk about some pretty often packaging bugs (I just found this bug in one of your packages) - building scrollkeeper files in /var during dpkg-buildpackage ?
<mvo> mantas_: in a couple of minutes maybe?
<mvo> mantas_: which package is it?
<mantas_> packages.debian.org/gnome-commander
<dholbach> mvo: could be you have to use   --disable-scrollkeeper    in debian/rules
<mantas_> mvo, I found this problem in several packages, for example in http://packages.ubuntu.com/gnome-schedule
<mvo> mantas_: ok, thanks
<ogra> arent that both gnome1 packages ? 
<dholbach> ogra: gnome-commander isn't any more
<ogra> ah
<mantas_> I think lintian, linda or some other automatic tests should check for this bug automatically, because after installing or removing some packages, which have this bug, help in gnome applications becomes broken :(
<mantas_> ogra, both are gnome2 applications
<ogra> mantas_, they werent last time i looked, but thats some releases ago :)
<mantas_> I think Debian/Ubuntu policy should forbid putting /var/lib/scrollkeeper into deb packages
<mgalvin> is anyone aware that the dapper-updates from the other day did not get processed properly again (the source in the archive but the .deb's are not)? or is it just me?
<mgalvin> for example
<mgalvin> http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-screensaver/
<ogra> mgalvin, see the channel topic
<ogra> they all need manual love to get built
<mgalvin> for dapper too?
<mgalvin> ok
<ogra> for LP 
<mgalvin> ah i see
<mgalvin> ok thanks ogra
<mgalvin> sorry for the noise
<ogra> mgalvin, btw there was just the cool suggestion to call "UWN" the "ubuntu weekly newt" woul fit perfectly for edgy ;)
<ogra> *would even
<mantas_> dholbach, mvo: gnome-commander's debian/rules contains only 3 lines - include /usr/share/cdbs/1/rules/debhelper.mk
<mantas_> include /usr/share/cdbs/1/class/gnome.mk
<mantas_> include /usr/share/cdbs/1/rules/simple-patchsys.mk
<mantas_> where I should put --disable-scrollkeeper ?
<ivoks> only three powerfull lines :)
<dholbach> mantas_: I know - I just told mvo, where to look
<mgalvin> ogra: haha :) that would be cool
<ogra> mgalvin, rename it :)
<dholbach> mantas_: does ./configure offer --disable-scrollkeeper?
<mgalvin> ogra: i'll see what others think too but yea, that would be cool especially since as edgy ramps up it will be largely focused on its happenings anyway
<dholbach> mantas_: if so, just add      DEB_CONFIGURE_EXTRA_FLAGS += --disable-scrollkeeper
<mantas_> dholbach, yes, configure script from gnome-commander's sources folder has --disable-scrollkeeper
<mantas_> dholbach, in start of debian/rules ?
<dholbach> mantas_: no, after the include lines
<mantas_> dholbach, ok, thanks
<dholbach> de rien
<mantas_> dholbach, what you think about adding check for /var/lib/scrollkeeper in linda, lintian or similar automatic deb packages checking tools ?
<dholbach> mantas_: while I think it's an annoyance, it doesn't happen that often, I think
<dholbach> mantas_: you might want to ask the lintian/linda maintainers
<dholbach> StevenK: did you think about that already?
<mantas_> dholbach, maybe this happens not very often, but after installing or removing some packages, which have this bug, help in *all* gnome applications becomes broken, so this is important bug for users
<dholbach> mantas_: I understand the problem.
<mvo> sladen: around?
<sladen> mvo: yup
<tepsipakki> does the netboot-install know how to fetch packages from -security? it seems to be broken now
<tepsipakki> dapper-netboot, that is
<fabbione> tepsipakki: seems to be broken how? what arch? 
<fabbione> as usual these kind od reports are useless
<fabbione> can your install access security.ubuntu.com ?
<Arbiter> hm a guide to debconf?
<Arbiter> (can't find it anywhere)
<tepsipakki> fabbione: netboot fails when fetching packages, wget says that it can't find something
<tepsipakki> binutils has been updated recently
<Arbiter> np found it
<fabbione> tepsipakki: proxy? unsynced mirror?
<tepsipakki> I can't test it now if the machine has access to s.u.c
<tepsipakki> no, mirror has been synced
<fabbione> well access to security is foundamental
<fabbione> i am installing via netboot/netinstall as we speak (sparc) and it's working fine
<tepsipakki> ok, so it was temporary
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | Builds on manual, don't upload to edgy yet
<fabbione> Keybuk: topicdiff?
<tepsipakki> and the arch was i386
<Keybuk> fabbione: http://www.netsplit.com/software/topicdiff/
<fabbione> Keybuk: haha
<thom> fabbione: s/Uploads/Builds/
<fabbione> thom: thanks mate
<thom> topic-diff.pl++
<fabbione> whatever... till it works :)
<fabbione> Keybuk: thanks dude
<mvo> anyone here with "svn merge" experience? 
<pitti> mvo: I did it a couple of times, but svn's idea of branches and merging is quite ... basic
<mvo> pitti: I have a branch that I want to merge back into trunk/ and apparently svn does not add the files that where newly added in the branch. that looks ... wrong
<mvo> and I have no idea if it is me or svn being silly
<pitti> mvo: hm, no idea about such specialties; I just remember that I had to clean up after merging several times
<pitti> mvo: did you do an svn update in both branches afterwards?
<mvo> pitti: no, I will try that 
<mvo> pitti: ok, thanks! I think I found the problem. svn revert was not cleaning up properly
<mvo> at least that is my current theory
* mvo craves for bzr
<jsgotangco> mvo: your g-a-i bzr took almost an hour for me! heh
<mvo> jsgotangco: I'll update it to knits, then it will only take 20 minutes :P
<pitti> crimsun_: so, we do not need to fix the datadir for bug 43146? you spoke about a safer workaround AFAIR
<Ubugtu> Malone bug 43146 in alsa-lib "gnome-sound-properties generates broken alsa conf" [Medium,In progress]  http://launchpad.net/bugs/43146
<Lathiat> pitti: hrm, that dovecot security update has broken my dovecot sql stuff :\
<pitti> Lathiat: oh, how so?
<Lathiat> pitti: as in it segfualts :(
<pitti> Lathiat: it worked quite fine here, I  tested it with a local PostgreSQL db
<Lathiat> (the auth process)) and doesn tlogin
<Lathiat> im using mysql
<Lathiat> i'll do some more hunting and see if i can find th eexact problem
<Lathiat> just dumbing down my sql query atm its quite complex
<Lathiat> i spen tthe last hour hunting around for silly config issues heh
<Lathiat> was working fine on one box that was installed around 3 weeks ago, took me a whiel to check if there was a version change, bleh
<pitti> Lathiat: does downgrading to 1.0.beta3-3ubuntu5 help?
<pitti> Lathiat: if so, then I revert the dapper patch and replace it with a much less safe, but unintrusive one
<Lathiat> pitti: yeh that fixed it
<Lathiat> pitti: if you give me a test package i'll try it out with that patch?
<Lathiat> even with a simple sql query its still segfaulting
<Lathiat> pitti: were you using a combined passdb/userdb query or separate?
<pitti> Lathiat: separate
<pitti> but it shouldn't matter really
<Lathiat> yeh
<pitti> Lathiat: hm, I used a trivial patch for hoary and breezy, but it doesn't work for dapper due to the quite weird program structure
<pitti> Lathiat: gimme some 30 minutes to look into that; do you have that much time?
<Lathiat> pitti: mm its 11:40pm was going to goto bed shortly ;p
<Lathiat> pitti: can do it tomorrow morning? (9 hours?)
<pitti> Lathiat: then I'll be asleep :)
* Lathiat laughs
<pitti> Lathiat: can you please open a bug with some logs etc.?
<Lathiat> yeh
<pitti> Lathiat: then I'll put a test package as a followup and you can try it out
<Lathiat> pitti: ok cheers
<pitti> Lathiat: can you  build debs from a source package?
<pitti> Lathiat: I can only generate amd64 binaries here
<Lathiat> im running this on amd64
<Lathiat> but i can build debs from source thats fine
<Lathiat> either
<pitti> Lathiat: so much the better, I'll put the debs on people.u.c then and give you a pointer in the bug report
<Lathiat> pitti: ok cheers
<pitti> Lathiat: assign it to me, please (martin.pitt@ubuntu.com) with high importance
<Lathiat> pitti: nps
<Lathiat> cheers!
<Lathiat> https://launchpad.net/distros/ubuntu/+source/dovecot/+bug/49601
<Ubugtu> Malone bug 49601 in dovecot "dovecot security update (5.1) breaks mysql" [High,Unconfirmed]  
<Lathiat> night :)
<pitti> Lathiat: night! and thanks
<bddebian> Heya
<janimo> are the builds in dapper-updates blocked on something?
<pitti> janimo: my security uploads don't come through as well
<bddebian> They are being put through manually aren't they?
<pitti> janimo: elmo told me that the host who controls mirrors has some hardware problem, Znarl is working on it
<janimo> they're marked needs building in LP
<pitti> hm, no idea about that one
<Keybuk> janimo: as I said above, they won't be built
<janimo> Keybuk: today? or until something specific unblocks them?
<Keybuk> s/something/someone/
<janimo> ok
<Keybuk> infinity will need to wake up, and feel better
<bddebian> infinity is sick again? :-(
<Keybuk> infinity is always sick
<Keybuk> but today he is also unwell
<bddebian> Well twisted yes, but not ill :-)
<cf2> Hi, I noticed a problem with archive.ubuntu.com and just wanted to check that it was known
<cf2> I noticed that the two machines that resolve for *.archive.ubuntu.com have different content. Compare http://85.133.25.8/ (good) with http://85.133.25.7/ (bad)
<fabbione> yes we know
<fabbione> thanks
<cf2> Is there an eta on a fix ?
<fabbione> no, it's hw problem
<cf2> Perhaps the DNS could be modified in the mean time ?
<tseng> or you could make a host file
* tseng doesn't see an emergency
<fabbione> or you could wait tomorrow to upgrade your no-changes edgy
<cf2> While it's not an emergency, this is affecting users of all the dist's. 
* cf2 thought changing a DNS record was easy as pie
<fabbione> cf2: with all proxies and dns caches around, by the time it's propagated, they will solve the issue
<tseng> and propagating the dns entry takes 72 hours
<tseng> and it will already be fixed
<fabbione> not worth
<tseng> fabbione++ 
<cf2> ok
<bddebian> So Keybuk, is edy open yet?
* bddebian hides
<siretart> pitti: around?
<pitti> siretart: yes
<Keybuk> I can see with absolute assuredness that not only is edy not currently open, it never well be
<bddebian> No?
<siretart> pitti: I'd like to upload wpasupplicant to dapper-updates, but I'm not exactly sure about the version number, in order to not interfere with a possible security upload
<siretart> pitti: version in dapper is 0.4.8-3ubuntu1, I'd suggest uploaded to dapper-updates with 0.4.8-3ubuntu1.1
<siretart> pitti: is this okay?
<pitti> siretart: hm, ubuntu2 won't hurt
<pitti> siretart: but that depends
<Keybuk> not only will we not get around to another 'e' distribution for ~13 years, "edy" isn't a word anyway
<pitti> siretart: is the fix trivial enough to be included into the next potential security update?
<bddebian> Oh, I missed my typo smart-alec ;-)
<pitti> siretart: I usually do this to eliminate branches (one for -updates and one for -security)
<pitti> siretart: it should be appropriate, otherwise it would be nothing for dapper in the first place ;)
<siretart> pitti: yes. it replaces a awk call with something more sane and fixes some obvious typos. should be okay for an security update
<pitti> siretart: ok, use 1.1 then
<siretart> allright
<Keybuk> there's a wpasupplicant security problem?
<pitti> Keybuk: not so far
<Keybuk> I must admit to be confused about how security and updates interact
<fabbione> pitti: echo "$bug" | update2securty.py >> debian/changelog
<Keybuk> are we doing security updates on the versions in dapper, or the versions in dapper-updates ?
<siretart> Keybuk: no. I'm just preparing the upload of the patch I forwarded to you (and you ack'ed)
<fabbione> Keybuk: once you start forking you need to do it in both
<pitti> Keybuk: both
<pitti> Keybuk: that's why I would like to avoid two branches
<Keybuk> ah, I see
<ivoks> pitti: hi
<pitti> hi ivoks 
<ivoks> pitti: looks like 1.2.2 in on the way :)
<pitti> oh joy
<ivoks> eh, and changelog will be as big as it was with 1.2.1
<bddebian> Bah, still no Xorg 7.1 in Experimental eh? :-)
<tseng> tough crowd
<ivoks> pitti: there are some changes to pstops
<crimsun_> pitti: right, no need to poke the datadir. The definitions in /usr/share/alsa/alsa.conf (lines 78-87) could be set via asoundconf's convenience macro, too.
<shadeofgrey> pardon me everybody
<shadeofgrey> i know im not supposed to be here but i just had to stop by and givce props to all the folks that made dapper wjhat it is nlow...
<shadeofgrey> straight up, we finally have a full fledged pimped out OS...
<shadeofgrey> special thanks go out to all the people that sacrificed sleep and other thing just to make ther deadline
<LaserJock> shadeofgrey: you can be here, you just need to stay on topic
<LaserJock> and I'm sure all the devs appreciate your kind words
<shadeofgrey> well
<shadeofgrey> im not done yet if its okay
<shadeofgrey> i just wanted to say that when i finally make it, and im pulling a few million a yerar in book deals and advertising on all my blogs,....
<shadeofgrey> im going to fly to wherever the highest number of developers are located, and take themn all out for dinner
<shadeofgrey> ...and its on me
<shadeofgrey> 'id do it just to see how many bottles of $1000 bubbly 40-50 ubuntu developers can drink when provoked
<neuralis> shadeofgrey: that would be paris, in about a week.
<shadeofgrey> hmmm.
<shadeofgrey> well, i wont meeet that dfeadlione
<shadeofgrey> but some day im going to spend a small fortune and give back to the devs at least a little of what they've gibven me.
<shadeofgrey> ....juyst out of curiosity, are there any really really hot women developers on the team
<shadeofgrey> ?
<shadeofgrey> ...that also happen to be single?
<crimsun_> shadeofgrey: very much off-topic
<shadeofgrey> i dig a girl with a nice compiler
<shadeofgrey> yeah, okay, im gone...  
<HiddenWolf> crimsun_: he's high. ;)
<bddebian> Damn did I miss a troll? :-)
<stuNNed> yeah me
<stuNNed> i am under the bridge watching you :P
<HiddenWolf> bddebian: shadeofgrey, a very nice, very enthusiastic guy who is quite high due to medication, not a troll. :)
<bddebian> Ah :-)
<zul> irc and drugs doesnt usually mix
<stuNNed> i am smoking crack with pine oil under the bridge watching you :D
<bddebian> wow
<Keybuk> mdz: so what's the actual plan for spec-review/prioritising ?
<Keybuk> you said that the TB would do it this week ... but haven't actually told me or mjg59 when/where/how :p
<mdz> Keybuk: yeah, I wish TB fell on today rather than next week
<mdz> should we try to round up the gang to talk about it?
<Keybuk> mjg59: ping?
<mdz> I'm free now but it's getting late for the rest of you
<mjg59> Keybuk: Hi
<Keybuk> it's ok for me now, I started a little late today
<mjg59> I'm about to fall asleep, I'm afraid
<Keybuk> sabdfl is in Poland, no?
<mdz> yes, I don't think we can expect him to be able to do much until he arrives in Paris
<mdz> at which point he will summarily reprioritize everything ;-)
<Keybuk> cynical, much? :p
<mdz> Keybuk: let's go over it nowish and send mjg59 a transcript
<Keybuk> in #u-m ?
<mdz> ok
<bddebian> Hah, cynicism, I knew I liked mdz for some reason :-)
<dieman> grmbl, the network admins found me and seem to be wanting us to use less bandwidth
<dieman> i ask them how much is less, and they said they don't really know
<dieman> since its a policy issue then
<_ion> #define us \
<dieman> s/us/mirror.cs.umn.edu/
<dieman> one of the releases mirrors
<_ion> Ok.
<dieman> i tweaked it down a little
<dieman> for now until they get back to me
<blanky> hey guys
<blanky> where can I see what type of programs are in demand or what projects need help, preferably in python
<LaserJock> blanky: that's a pretty tall order
<blanky> LaserJock, lol, I just remember that they said that they'd like their programs in python
<LaserJock> I don't think it *has* to be in Python
<dieman> blanky: you can always poke through bugs on launchpad.net and add patches
<blanky> dieman, ah okay, cool
<blanky> launchpad.net then
<dieman> blanky: you may want to join ubuntu-motu, also
<dieman> (the channel #ubuntu-motu, rather)
<dieman> blanky: and the url in the topic, http://wiki.ubuntu.com/HelpingWithBugs
<blanky> been there, no one's there lol
<blanky> thanks dieman 
<Whoopie> pitti: you mentioned in bug #34112 that libgnomeprint2.2-0 is in the archives. But I didn't get an update. Is this also related to the mirroring issue?
<Ubugtu> Malone bug 34112 in libgnomeprint "gnome programs don't respect ~/.cups/lpoptions" [Unknown,Unknown]  http://launchpad.net/bugs/34112
<pitti> Whoopie: yes, it's in the archive for ages
<pitti> libgnomeprint | 2.12.1-3ubuntu2 | http://archive.ubuntu.com dapper-updates/main Sources
<bluefoxicy> has anyone else tried to boot dapper x86 desktop CD in qemu?
<Whoopie> pitti: ok, thanks. BTW, could you perhaps explain me shortly how the package build works in dapper-updates? I heard that it's not done automaticly.
<pitti> Whoopie: just dist-upgrade, you should get it
<Whoopie> no chance. it's not there. And I have enabled dapper-updates in sources.list.
<bluefoxicy> God that took forever and bootsplash died.
<pitti> Whoopie: what does 'dpkg -s libgnomeprint2.2-0|grep Version' say?
<Whoopie> pitti: Version: 2.12.1-3ubuntu1
<mdke> is there any way I can get information about the new mozilla-thunderbird that appears to be in the archive? I can't find anything on changelogs.u.c or dapper-changes
<pitti> Whoopie: then that's the old version, -3ubuntu2 has the fix
<pitti> mdke: in the USN I'm going to send out as soon as this damn enigmail appears on the mirror
<pitti> mdke: http://www.ubuntu.com/usn/usn-297-1 so far
<Whoopie> pitti: yes. But I can do as many "apt-get update", it will not appear.
<mdke> pitti: oh, I wondered why it wanted to remove enigmail. that's the only reason I wanted the changelog :)
<mdke> thanks
<pitti> Whoopie: apt-get dist-upgrade doesn't want to install it?
<Whoopie> pitti: yes.
<pitti> Whoopie: apt-cache madison libgnomeprint2.2-0
<Whoopie> libgnomeprint2.2-0 | 2.12.1-3ubuntu1 | http://archive.ubuntu.com dapper/main Packages
<Whoopie> libgnomeprint | 2.12.1-3ubuntu1 | http://archive.ubuntu.com dapper/main Sources
<Whoopie> libgnomeprint | 2.12.1-3ubuntu2 | http://archive.ubuntu.com dapper-updates/main Sources
<Whoopie> that's it.
<ogra> wsas it ever triggered to be built ? 
<ogra> *was
<ogra> (builds need manual love currently)
<ogra> pitti, ? ^^
<carlos> pitti: ping, do you have 5 minutes for me?
<pitti> ogra: sure, I uploaded it ages ago when the buildds were working
<pitti> ogra: oh, hm, it's indeed not htere
<pitti> Whoopie: so, I apologize, it's really not on the mirrors
<Whoopie> pitti: np
<pitti> darn, the current problem started this morning
<pitti> mdz: is it possible that 2.12.1-3ubuntu2 binaries are still in the to-be-approved queue for dapper-updates?
<ogra> pitti, there was a big lot approved yesterday from the -updates queue but i dont see any print stuff
<pitti> Keybuk: could you please check another thing for me on drescher? does it have pool/main/libg/libgnomeprint/*2.12.1-3ubuntu2*deb?
* Keybuk loves pitti's confidence in our archive management software
<Whoopie> pitti: I didn't see it at the dapper-changes mailing list. That was the reason I was really surprised it should be in dapper-updates.
<Keybuk> pitti: no it does not
<pitti> Keybuk: don't take it personally, but since recently it just falls apart underneath me
<Keybuk> pitti: where did you upload that?
<pitti> Whoopie: well, the *source* is on the mirror
<Keybuk> which buildds would that be built on?
<pitti> Keybuk: June 7th
<pitti> Keybuk: bah, it still says 'needs building' everywhere
<Keybuk> right, it's an upload to -updates, yes?
<Keybuk>    40759 | S- | libgnomeprint        | 2.12.1-3ubuntu2      | six days
<Keybuk>          | * libgnomeprint/2.12.1-3ubuntu2 Component: main Section: libs
<pitti> yes
<Keybuk> yes
<Keybuk> have you asked infinity about it?
<Keybuk> he's running all builds by hand
<pitti> Keybuk: not particularly, should I?
<pitti> ooooh
<pitti> Keybuk: does that affect other -updates uploads, too? I'm not sure that everyone asked infinity for every single upload
<pitti> Keybuk: ok, thanks for the hint. I'll ask him when he's alive again
<Keybuk> it depends whether he's looked or not
<Whoopie> BTW, other thundbird extensions like thunderbird-quickfile are also affected by the security update. Will they be rebuilt?
<Keybuk> chances are you just got caught in the weekend and early week illness
<pitti> Whoopie: yes, once the mirrors work again
<Whoopie> pitti: okay, sorry.
<Whoopie> pitti: I just mentioned it because e.g. firefox-dom-inspector wasn't rebuilt and is also in universe.
<pitti> Whoopie: yes, because that one is built from the firefox source itself
<mdz> infinity: around?
<sabdfl> howdy all
<sabdfl> greetings from warsaw
<pygi> hey hey mark
<Keybuk> dy well thankyou
<sabdfl> mdz, Keybuk: 134 specs for paris, and counting...
<Keybuk> 134 ?!
<Keybuk> it was 133 a moment ago
<sabdfl> that's headed for montreal figures
<Keybuk> have you been sneaking specs in under our nose?
<ogra> heh
* sladen has 8 more I didn't even submit...
<sabdfl> Keybuk: not a one, yet
<Keybuk> sabdfl:  lies ... https://launchpad.net/distros/ubuntu/+spec/tab-consistency
<sabdfl> i don't want to be accused of providing the straw to the camel
<sabdfl> this launchpad everything-is-visible thing is doggarn dangerous
<sabdfl> Keybuk: and https://launchpad.net/products/rosetta/+spec/rosetta-firefox-support
<sabdfl> so, two
<sabdfl> a remarkable discipline, considering ;-)
<ajmitch> hi sabdfl 
<sabdfl> hey ajmitch
<zul> hey sabdfl 
<jmg> morning all :)
<ajmitch> morning jmg 
<jmg> my spec has finally changed status :)
<jmg> pity i missed the meeting
<mdz> Keybuk: I added a new one a moment ago
#ubuntu-devel 2006-06-14
<Keybuk> IGNORING YOUR OWN DEADLINES, EH?! :)
<mdz> yes, low priority
<jmg> :-)
* jmg goes back to replying to all the recruiters that emailed him this morning
<mdz> Keybuk: besides, the point of the deadline was to give us a chance to look over what we have without it changing all the time
<Keybuk> hehe
<Keybuk> I know
<mdz> sabdfl: speaking of which, in case you're behind on mail, please don't accept any new stuff for paris for a bit; we're sorting through what we have
<mdz> sabdfl: and Keybuk and I are borrowing #ubuntu-meeting to coordinate that effort
<mdz> BenC: see my last comment on bug 43531, would like to hear back while I'm working on the agenda for paris
<Ubugtu> Malone bug 43531 in linux-source-2.6.15 "Kernel isn't very useful without a boot loader, but doesn't depend on one" [Medium,Confirmed]  http://launchpad.net/bugs/43531
<BenC> mdz: Ok
<mdz> BenC: I think there's probably stuff to talk about since the installer is involved
<sabdfl> mdz: i'm not accepting anything for paris for fear of being accused of setting edgy goals ;-)
<sabdfl> so far, so good
<Keybuk> sabdfl: does blueprint automatically set things to accepted?
<sabdfl> Keybuk: if you would have the right to accept it
<sabdfl> so, if a member of ubuntu-drivers nominates a spec, it will be accepted
<Keybuk> ah, so if anyone on ubuntu-drivers proposes a spec, it goes straight to accepted without collecting 200$ ?
<sabdfl> btw, ubuntu-drivers should not include core dev, if it still does
<sabdfl> the drivers really should be drivers
<sabdfl> can i fix that now?
<BenC> mdz: No sure if we need a talk, but if we make it low-priority, we can pick up discussion if there's time
<BenC> mdz: Just added my comment to the bug
<mdz> sabdfl: only if you fix "faster pussycat, kill kill kill" while you're there
<sabdfl> mdz?
<mdz> sabdfl: top of https://launchpad.net/people/ubuntu-drivers
<sabdfl> wow
<sabdfl> no idea where that came from
<sabdfl> very non-CoC
<mdz> sabdfl: h4x0rz
<Keybuk> sabdfl: you're the only person who can edit that
<Keybuk> did someone hack you with alcohol?
<sivang> was this text added intentionally ? :p
<pygi> hey hey simira 
<pygi> erggh, sivang*
<sabdfl> weird
<sabdfl> i can't see where to edit that text
<Keybuk> it's probably the team's homepage
<sabdfl> right - done
<sabdfl> this page is seriously lacking a nice title/context
<mdz> sabdfl: do we really need ubuntu-drivers at all?  shouldn't that just be TB?
<mdz> it's basically TB + people who were added because they were helping with the schedule at UBZ
<sabdfl> mdz: useful to be able to add people here when its needed without affecting TB
<sabdfl> i'll take the janes off the list
<Keybuk> should the TB be the owner/administrator?
<sabdfl> can do, too
<mdz> that'd be slightly less cabalistic
<sabdfl> done
<mdz> sabdfl: my basic rule of thumb for accepting things for the paris agenda is that one of the attendees is interested
<mdz> sabdfl: maybe for the next one we could have LP do that calculation for us?
<sabdfl> mdz: could do... but we could also just show the people (or the number of people) associated with it that are also registered for the sprint, on the accept/decline page
<mdz> I have a list of spec tracker ideas and needs resulting from working with it a bunch recently
<sabdfl> so its still a manual process, just better informed
<mdz> sabdfl: that's what I was suggesting
<sabdfl> mdz: cool, suggestions welcome
<mdz> that gives us a chance to scare up some interest about it
<sabdfl> main thing on my todo is to move everything to blueprint.launchpad.net/ so you stay in a specs view while jumping from upstream to the distro and to people
<mdz> though when it's proposed, LP should probably say "there's no one attending the sprint who's interested in it; it's unlikely to be accepted unless someone signs up to talk about it"
<mdz> sabdfl: my stuff is so much more useful than that though ;-)
<sabdfl> we should also ask people to note their attendance in LP rather than the wiki
<sivang> mdz , sabdfl : maybe "My interest in this spec is [1.....x.10] " tick box for sub'ers ?
<sabdfl> mdz: useful to... you?
<sabdfl> ;-)
<sivang> sort of a poll style..
<sabdfl> i primarily want to use blueprint to lead the other apps
<mdz> sabdfl: correct
<mdz> me being someone who uses the spec tracker a lot ;-)
<mdz> Keybuk: why are you trying to join motu?
<sivang> hehe
<Keybuk> mdz: s/motu/core-dev/ ... was just testing something and needed a team where it was a no-op to join
<Keybuk> ie. one I was already a member of by inferance
<BenC> I've been deactivated from Ubuntu Drivers!
<mdz> Keybuk: why is mjg59 whining about the mailbombing when he was supposed to go to sleep?
<sabdfl> BenC: we took the u-core-dev team out of drivers
<Keybuk> sabdfl: bug!  I got a mail saying I was deactived from Ubuntu Drivers ... yet I'm still a member via a different team
<BenC> it's ok, I'm on too many teams as it is :)
<sabdfl> Keybuk: file it, assign to salgado
<Keybuk> mdz: because the tech-board is marked as an approved for all the specs ... so his mail box is full of e-mail about every change we made :p
<sabdfl> Keybuk: good catch ;-)
<mdz> Keybuk: but he said he was going to sleep before we did that
<sabdfl> Keybuk: why did you mark the tech-board an approver?
<Keybuk> mdz: he woke up again
<mdz> Keybuk: that was his excuse for ditching out on the discussion
<mdz> I see
<Keybuk> sabdfl: so we'd get e-mail about all the changes
<mdz> mjg59: you're not coming to paris?
<sabdfl> hmm... reduces the value of the approver slot, though
<mjg59> mdz: Correct
<mjg59> (And I'm supposed to be sleeping, damnit)
<sabdfl> Keybuk: the scheduler will try to make sure the approver is in an early discussion session, to get things off on the right foot
* mjg59 curses his sleep cycle
<sabdfl> for edgy, since specs are sort of "self lead", folks will generally want to be their own approvers
<Keybuk> sabdfl: right, the theory is to change that before the meeting when we assign real approvers
<sabdfl> ok
<sabdfl> jus' checkin'
<sabdfl> night all. morning mjg59.
<mdz> Keybuk: they all start as tech board and will get delegated from there as appropriate
<Keybuk> mjg59: why aren't you coming? :(
<mdz> but I appreciate getting mail about the changes
<mdz> mjg59: yeah, shame on you
<mjg59> Keybuk: Work
<Keybuk> 135 specs ?!
<Keybuk> they're going up!
<mdz> I didn't add one
<mdz> not since the one I admitted to
<Keybuk> drive-backports ?
<Keybuk> uh, driver-backports
<mdz> that's the one
<Keybuk> hmm, then another one got added between me counting 133 and sabdfl counting 134
<sabdfl> aiiieee... it's too many, we'll need to do good prioritisation, try give everyone at least one essential, a couple of high, etc
<Keybuk> stat: if each spec requires 3 sessions, and we have 6 sessions a day ... then we need 14 concurrent sessions to fit them all in
<sabdfl> good specs require 6-9 sessions, from experience
<sabdfl> edgy might be less, since it's self-inspired
<sabdfl> the guy writing it up is the guy who dreamed it up, in more cases
<sabdfl> so mostly, he gets to call for comments and feedback, and check interactions with other devs
<sabdfl> but still
<sabdfl> we could easily end up with lots of half-done or badly-done specs, if we try take on too much
<sabdfl> it's a very tight cycle
<sabdfl> mdz: do you want to ask guys to estimate dev time, for specs they are dreaming up?
<mdz> sabdfl: I don't think we can reasonably expect that until the spec is fleshed out
<Keybuk> ah, #134 was ltsp-dhcpd-autogeneration
<sabdfl> ok, night all, really
<bluefoxicy> ah, good.
* bluefoxicy takes screen shots of the dapper loading process, from install to boot.
<HiddenWolf> bluefoxicy: osnews/osdir has them for you.
<sivang> Keybuk: I'm actually erroring at trying to understand the meaning of the software appliance term, they were not using it a year a go IIRC
<Keybuk> "our primary business plan failed, here's plan B"
<sivang> hehe 
<sivang> anyway, I'm way past my bed time. laters all, night Keybuk 
<neuralis> mako: ping
<bluefoxicy> Keybuk:  I'm just picking up major highlights on the install process.  I'm planning on boot screen, live desktop, live desktop + firefox, install (with a GNU/FreeDOS partition resize), booting (skip G/FD in grub), and at the desktop.
<Keybuk> bluefoxicy: hmm?
<bluefoxicy> er.
<bluefoxicy> I meant HiddenWolf
<Keybuk> did you mean HiddenWolf ? :)
<bluefoxicy> I mean the keys are practically the same
<bluefoxicy> Key<tab>, Hid<tab>, you know.
<HiddenWolf> bluefoxicy: ah, ok.
<Keybuk> bluefoxicy: yes, I can see that
<bddebian> Heya
<LaserJock> anybody know what the default debconf interface is, Dialog?
<LaserJock> and do individual package managers (like synaptic) override that?
<LaserJock> infinity: ping?
<Keybuk> ajmitch: my approach for that is to do rm -rf *; tar xf ../new-tar.tar.gz --strip-components=1
<Keybuk> bzr add
<Keybuk> (bzr notices the removed files automatically)
<ajmitch> right
<Keybuk> basically the same as "moving the .bzr" yes
<Keybuk> it does work particularly well
<ajmitch> so far most of mine just have debian/ in bzr
<ajmitch> I did experiment awhile with keeping various branches, including upstream, around also
<Keybuk> I've not really been enamoured about debian/ in bzr
<Keybuk> it's handy for collaboration though I guess
<ajmitch> I didn't really have useful tools for getting all the patch branches together, keeping everything in sync
<ajmitch> it seemed like more work for less gain
<Keybuk> I decided to drop debian/patches entirely
<Keybuk> "emulating revision control" again
<Keybuk> so I have a "release branch"/"integration branch" which I make releases from
<sladen> Keybuk: how do you cope with rediffing your changes against a fresh upstream?
<Keybuk> and I do feature work on separate branches (the old patches)
<Keybuk> sladen: I have an excellent example right here
<Keybuk> $ cd upstream
<Keybuk> $ rm -rf *
<Keybuk> $ tar xf ../udev-094.tar.gz --strip-components=1
<Keybuk> $ bzr add
<Keybuk> $ bzr commit -m "import udev 094"
<Keybuk> $ cd ../ubuntu
<Keybuk> $ bzr merge ../upstream
<Keybuk> (no conflicts this time)
<Keybuk> $ bzr commit -m "update to udev 094"
<Keybuk> $ uch -v094-0ubuntu1
<Keybuk> $ dpkg-buildpackage -rfakeroot -S
<sladen> I see
* ajmitch might as well try it out again
<Keybuk> (the top lot is just one shell script I have, btw)
<Keybuk> so I really just do
<sladen> and presumely if launchpad is automatically pulling in upstream into bzr then the above means you can just merge from the launchpad copy
<Keybuk> ubuntu$ new-upstream ../udev-094.tar.gz
<Keybuk> sladen: exactly
* sladen has forgotten what part of launchpad was doing this 
<ajmitch> sladen: harder when there's no tags 
<Keybuk> importd
<Keybuk> ajmitch: just create branches where you would have created tags
<Keybuk> main$ bzr push sftp://ajmitch@bazaar.launchpad.net/~ajmitch/foo/TAG
<ajmitch> sure, I mean that launchpad doesn't have any tags or similar on the imported products
<Keybuk> launchpad doesn't really _do_ imported products yet
<ajmitch> it has the 0.1 branch of f-spot, for example
<ajmitch> right
<Keybuk> it's still alpha code
<ajmitch> once all the relevant upstream products are imported, it will be quite useful
<sladen> Keybuk: so once it's in that state, what's the easiest way of backing out individual patches that were applied several revisions back
<Keybuk> sladen: well, what I do for patches is
<Keybuk> (creating one)
<Keybuk> $ cp upstream ubuntu.iftab
<Keybuk> $ cd ubuntu.iftab
<Keybuk> $ vi ...
<Keybuk> $ bzr commit
<Keybuk> $ cd ../ubuntu
<Keybuk> $ bzr merge ../ubuntu.iftab
<Keybuk> $ bzr commit -m "merge iftab patch"
<jmg> was there a UTB meeting this morning?
<Keybuk> so that's a patch _in_
<Keybuk> to update the patch is
<Keybuk> $ cd ../ubuntu.iftab
<Keybuk> $ bzr pull ../upstream
<Keybuk> (or merge)
<Keybuk> so the patch is actually based on upstream
<Keybuk> to back out the patch is easy
<jmg> hmm
<Keybuk> $ bzr merge -r $(bzr revno ../ubuntu.iftab)..1 ../ubuntu.iftab
<Keybuk> (ie merge it in reverse)
<Keybuk> jmg: there was an extraordinary meeting of the Ubuntu Technical Board to discuss spec priorities -- the ordinary meeting was last week and will be again next week
<jmg> Keybuk: ah ok, yes some of my specs were accepted
<Keybuk> were some declined?
<jmg> Keybuk: but there are no logs online yet
<Keybuk> the log should in the usual ubuntu-meeting irclogs place
<jmg> Keybuk: no
<Keybuk> it's not very interesting reading
<jmg> Keybuk: hasnt shown up yet
* jmg wonders how he can word his ubuntu stuff for his CV
<ajmitch> jmg: still doing the job hunt? :)
<jmg> ajmitch: interview tomorrow, phone interview this afternoon
<jmg> ajmitch: i've been relaxing :)
<ajmitch> heh, good
<ajmitch> potential job might still be using ubuntu?
<jmg> debian
<jmg> i'll convince them to switch to ubuntu-server :)
<jmg> i think they would like to have an ubuntu contributor on board, even if he isnt a warthog
* zul is the proccess of converting servers at work to ubuntu-server
<jmg> yet :)
<jmg> this meeting is confusing
<Keybuk> which meeting?
<sladen> Keybuk: so this means that you have to keep each of that branch directories around indefinately?
<Keybuk> sladen: push them onto the supermirror and it can do that for you
<jmg> ah ok, it was for paris
<sladen> Keybuk: oh boy, that's alot of diskspace/bandwidth
<ajmitch> sladen: not so bad with repositories
<Keybuk> sladen: not really, just one revision
<jmg> Keybuk: this morning, my specs were approved without discussion
<sladen> for some definition of "so bad"
<Keybuk> sladen: another option is just to bzr log -v and grab the revision ids
<jmg> Keybuk: what is Paris? is that the edgy planning event?
<Keybuk> jmg: yes
<jmg> hopefully i can attend via IRC :-)
<sladen> Keybuk: then reverse-merge from the current directory?
<Keybuk> right
<Keybuk> I can grep "bzr log -v" for "branch nick: ubuntu.iftab"
<sladen> Keybuk: eg.  bzr merge -r x..x+1 . ?
<Keybuk> and get the "merged: id" from it
<sladen> that's a much better solution, as long as you don't want to keep modifying the patches
<Keybuk> even if you modify the patches, you can just do it repeatedly for each one with that branch nick
<ajmitch> all these neat little features that snuck into bzr when I wasn't watching
<sladen> Keybuk: so if you're editing  foo.patch  you do  mv ./packagename packagename.foo ; cd packagename.foo ... merge ; cd .. ; mv packagename{.foo,}
<sladen> just to set the branch nick?
<Keybuk> no, I'd cheat and do "bzr nick iftab"
<sladen> this is starting to make more senes
<sladen> (even if I'm not making senes)
<Keybuk> admittedly, the "decide not to include a patch anymore" case is slightly harder with bzr
<Keybuk> but I don't think that's a very common case
<Keybuk> the common case is simply that the patch is merged upstream -- with bzr that's a no-op
<Keybuk> very rarely is a patch abaonded
<Keybuk> (I could be wrong)
<sladen> it can happen when upstream won't take a patch and you decide it's just not worth carrying the delta
<Keybuk> that would assume that the delta is expensive to maintain
<sladen> so more likely to be the case in Universe
<Keybuk> the theory of bzr says that deltas become cheap to maintain
<sladen> yes
<Lathiat> that could easily not be the case especially in rapidly changing projects, no?
<Keybuk> true
<sladen> a sync from Debian is the fast path;  a scripted solution that attempted the import+merge would in theory be just as easy
<sladen> it moment it fails to merge, you're back to a human though
<Keybuk> that's always going to be the case
<Keybuk> if two people change the same code in two different ways
<Keybuk> only a human can resolve it
<Keybuk> a revision control system at least gives you "A", "B" and "BASE"
<Keybuk> rather than just A and B
<stuNNed> ok so esd should be disabled by default and just rely on hw system beep and raw alsa support imho
<stuNNed> threw crappy imitation flash at esd and it fried alsa
<stuNNed> compiling gnash can't find X
<stuNNed> or xlibs
<stuNNed> one sec let me try the dev packages maybe
<stuNNed> thn x
<stuNNed> 18.4mb isn't too bad, crap 
<stuNNed> another 20mb of -dev packages to get gnash going :D
<infinity> Ahh, it's nice when I wake up to an internet connection that doesn't suck...
<infinity> Fetched 121MB in 2m0s (1005kB/s)
* Hobbsee glares at the injustice of that.  where are you, infinity?
<dholbach> good morning
<tepsipakki> fabbione: about the netboot failing here yesterday.. it still does, and the reason is that the installer is trying "http://localmirror/ubuntu dapper-security" which is quite impossible to create
<fabbione> tepsipakki: dapper-security is also on the normal mirrors
<fabbione> i have it on my localmirror as well
<tepsipakki> it is? ok.. will try
<fabbione> so probably you are victim of a wrong mirror pulse
<fabbione> there have been mirroring issues yesterday
<tepsipakki> well, it isn't mirrored here, yet :/
<fabbione> i don't know if they have been fixed
<fabbione> it is here
<tepsipakki> but I think it should use s.u.c if a local mirror doesn't exitst
<tepsipakki> exist
<tepsipakki> but hold on
<fabbione> tepsipakki: i am not going anywhere for the next 10 minutes at least
<pitti> Good morning
<fabbione> hey pitti
<tepsipakki> 195189630 bytes will be downloaded into archive.
<dholbach> hi pitti
<tepsipakki> fabbione: I'll report in a minute if that was it :)
<tepsipakki> bah, forgot to mirror main/debian-installer
<tepsipakki> hmm no, I'm lost now.. it didn't mirror the udeb, and I don't know what repo to use for that
<tepsipakki> oh wait..
<tepsipakki> trial-and-error, that's me
<tepsipakki> fabbione: it works now
<pitti> hi ivoks
<ivoks> hi pitti 
<ivoks> pitti: that patch for sharing printer should be droped :)
<pitti> ivoks: which one?
<ivoks> since it doesn't share printer, but printers... and cups can share single printer
<ivoks> pitti: the one that didn't get into dapper
<pitti> ivoks: oh, the g-cups-mgr UI one
<ivoks> yes
<pitti> ivoks: for edgy we need a completely new UI infrastructure anyway (eggcups?), so we need a new patch
<pitti> ivoks: so we should extend enable_sharing to specify a printer name, too?
<ivoks> right, but we should look how to implement "share this printer"
<ivoks> yes
<pitti> ivoks: it would still open the port, and then set an ACL on the partiuclar printer
<ivoks> cups 1.2 supports that
<ivoks> right
<ivoks> it just needs additional instructions...
<ivoks> pitti: looks like fedora has some development around eggcups
<pitti> ivoks: yes, I think they wrote it in the first place
<ivoks> oh...
<pitti> ivoks: however, last update was Februrary 2004
<pitti> not exactly up to date either
<ivoks> um...
<ivoks> not quite
<ivoks> http://rpmfind.net/linux/RPM/fedora/devel/ppc/desktop-printing-0.19-6.ppc.html
<ivoks> it's quite newer
<ivoks> actully, it's never than dapper :)
<pitti> that url doesn't quite seem to work
<ivoks> ok, almost :)
<ivoks> pitti: ok, check this out ftp://download.fedora.redhat.com/pub/fedora/linux/core/development/source/SRPMS/desktop-printing-0.19-9.src.rpm
<pitti> ivoks: however, eggcups is just a gnome-cups-icon replacement
<pitti> ivoks: this one is a g-cups-mgr equivalent?
<ivoks> pitti: i see only eggcups in that archive
<ivoks> but version 0.19
<ivoks> yup... last release in 2005.
<pitti> jdub: ping
<ivoks> pitti: yes, this is only icon, they use system-config-printer for printer managment
<pitti> ivoks: what's that?
<pitti> hey seb128!
<seb128> hello pitti
<ivoks> pitti: redhat's tool
<ivoks> pitti: py program
<pitti> there's really no current gnome-native printer management tool?
<ivoks> i searched and searched... but...
<ivoks> didn't find anything _recent_
<seb128> gnome-cups-manager?
<ivoks> :D
<ivoks> seb128: recent :)
<seb128> ivoks: it's recent
<pitti> seb128: something that sucks less
<seb128> or do you want to start a new software from scratch every months to get something "recent"?
<pitti> seb128: no, but something that provides better hotplug support and dbus integration :)
<pitti> seb128: and g-c-m is dead upstream
<seb128> I think some Novell guys worked on thaty
<seb128> CVS has probably some new feature over current tarball
<pitti> oh, cool
* pitti looks
<desrt> seb128; how was the vacation?
<pitti> seb128: it seems we should at least use eggcups instead of g-c-icon to get rid of the polling and 100% cpu usage problems, right?
<seb128> desrt: really good ;) 
<seb128> pitti: yeah, I think so
<seb128> desrt: nice to do something totally different and to enjoy the nice weather for a week ;)
<pitti> seb128: at least we finally have nice weather here, too :)
<seb128> now I've to catch up with mails and that's not going to be a lot of fun :p
<desrt> seb128; lots of launchpad backlog, i'd imagine
<desrt> i just had a friend leave my house.  he's not a hacker, by far
<desrt> but he's been using ubuntu for a bit over a year and gentoo before that
<desrt> he stated something that he has observed --
<seb128> around 800 bug mails yep
<desrt> in open source, nobody is really doing integration
<seb128> and around 400 mails to my debian or ubuntu email (ie: not counting the mailing-list I'm subscribed to)
<desrt> you get someone writing gnome power manager, and this other guy writing networkmanager
<desrt> but nobody really makes sure that they work together properly
<seb128> not always true
<desrt> the only time people actually do this is when someone notices a problem, files a bug and makes the "other" maintainer aware of the issues
<seb128> GNOME does try to do integration
<desrt> i don't think we do very much
<seb128> that's one of the reason why g-p-m didn't get accepted for desktop previous cycle no?
<fabbione> i'd say it can be done better
<desrt> there were a lot of reasons for that
<seb128> right, it can
<desrt> g-p-m, wrt the rest of the desktop is pretty much a mess right now
<fabbione> our major problem, but also power is that our API's keep changing very very fast
<desrt> but so is, say, networkmanager
<desrt> they each have these wonderful (and sometimes overlapping) APIs/capabilities _that nobody uses_
<desrt> fabbione; own any apple laptop hardware?
<fabbione> desrt: ?
<desrt> ibook, powerbook, macbook, anything?
<fabbione> desrt: i have a PB g4 now...
<fabbione> the latest one before Apple become an Intel company
<desrt> the power brick came with a little plug that attaches directly to it and also came with a cord
<fabbione> s/company/reseller
<desrt> does the cord feature a 2 or 3 prong plug?
<pitti> desrt: still have problems with that? :)
<desrt> pitti; i want to know if apple sells a 2-prong cord in any country on earth :)
<fabbione> desrt: the brick has 2 "holes" so even if the plug has ground, it's totally useless
<pitti> desrt: yes, here in .de 
<desrt> pitti; fact of the matter is that 2-prong cords in europe are very universal but not 3-prong is
<desrt> fabbione; wrong.
<fabbione> desrt: but dk has different standards, so i get both the dk one and the eu one
<desrt> fabbione; the brick has a little metal stud on it that the ground connects to
<fabbione> desrt: oh right.. i thought that was just to make it more solid
<fabbione> desrt: but well yeah i get both 2 and 3 pins
<desrt> fabbione; nope.  subtle but functional :)
<fabbione> the latter is dk standard
<desrt> fabbione; you have a 2-pin europlug for your apple brick?!
<fabbione> yeps
<fabbione> want a pic?
<desrt> please.
<desrt> (just to clarify... we're talking about the cord, not the direct-attachment)
<fabbione> desrt: yeah
<fabbione> desrt: http://people.ubuntu.com/~fabbione/IMG_3294.JPG
<desrt> (just to clarify... we're talking about the cord, not the direct-attachment)
<fabbione> dude
<desrt> :)
<fabbione> the cord has the DK standard
<desrt> 3 prong
<fabbione> 3 pins
<desrt> BAH
<desrt> apple, why must you be evil?
<desrt> i think all the cords have 3 pins, alas.
<desrt> thanks for the pic :)
<desrt> ((are those two pins bent together or is it an optical illusion of the photograph?))
<fabbione> desrt: the latter..
<fabbione> actually.. they are bent
* fabbione fixes
<desrt> :)
<desrt> i read somewhere that the pins on plugs in europe often converge
<desrt> but i'd never seen an example of it before until now
<ivoks> pitti: fwiw, eggcups compiles and works
<desrt> k.  bed.
<desrt> fabbione; thanks again.  nite :)
<fabbione> desrt: no problem.. nite
<ispiked> fabbione: ping
<fabbione> pong
<ispiked> fabbione: was wondering how/when the fix for this bug will get into my dapper system: https://bugs.freedesktop.org/show_bug.cgi?id=6827
<Ubugtu> Freedesktop bug 6827 in * Other "[patch]  crash in fb" [Critical,Resolved: fixed]  
<fabbione> ispiked: no idea. i am not doing X anylonger
<ispiked> fabbione: :(
<ispiked> fabbione: who is?
<fabbione> probably infinity
<ispiked> infinity: ping
* pygi pokes someone who has debian maintainer powers
<infinity> ispiked: ?
<ispiked> infinity: see what I asked fabbione.
<ispiked> infinity: please. :)
<infinity> ispiked: Is there a bug in Malone, does it have a sane patch attached, etc, etc?
<ispiked> infinity: uhm... dunno. I don't do malone.
<infinity> ispiked: I'm not psychic, and we're certainly not updating dapper with random new upstream releases.
<ispiked> infinity: could you at least include the patch?
<infinity> ispiked: Seriously, file an Ubuntu bug.  I will have forgotten that this conversation even happened in about 5 minutes, and I don't have the time right now to evaluate the fix.
<Hobbsee> oh yeah, and link it to the upstream bug :P
<ispiked> infinity: ok. 
<ispiked> should it be a "we need to port these changes" bug?
<ispiked> or a "this is what I'm seeing; it sucks; let's port the upstream patch that fixes it" bug?
<crimsun_> ispiked: just file a bug, link to the fd.o bugtracker, and sub me
<crimsun_> please allow our archive team to move edgy along.
<sivang> morning all
<sivang> Znarl: ping, around?
<infinity> crimsun_: Thanks, dude. :/
<pygi> sivang, mornin' :)
<sivang> morning pygi , how's it going?
<pygi> great, what about you? :)
<Mithrandir> mako: "meteoronome[r] "?  Not to be confused with metronome.
<Hobbsee> hey sivang 
<sivang> Fine, trying to sort some administrative stuff ;-)
<pygi> nice :)
<ispiked> infinity: you would be as annoying as me if you were experiencing this bug.
<seb128> pitti: nice that bug #34112 got fixed
<Ubugtu> Malone bug 34112 in libgnomeprint "gnome programs don't respect ~/.cups/lpoptions" [Unknown,Unknown]  http://launchpad.net/bugs/34112
<pitti> seb128: unfortunately I noticed yesterday that the packages aren't yet built (I mailed infinity already, this needs to be done manually apparently)
<pitti> seb128: but yes, this one was a PITA :)
<seb128> the number of dups for it is impressive
<pitti> seb128: add six or seven more, yesterday I stumbled over another bug with dups which is likely the same
<seb128> it was already impression without those :p
<pygi> pitti, you have a sec?
<pitti> pygi: hi! yes
<pygi> pitti, you have debian maintainer powers, right? 
<pitti> pygi: yes, I have
<pygi> pitti, nice, any chance you could sponsor one package for me?
<pitti> pygi: depends, which package?
<pygi> this one: http://www.gnomefiles.org/app.php?soft_id=1158
<pitti> pygi: just a bug fix, or a completely new one?
<pygi> completely new one
<pitti> pygi: oh, it's not in Ubuntu yet either
<pygi> pitti, I know :P
<pitti> pygi: I don't sponsor sutff without auditing the packaging first, so this will take me a while
<pygi> same with diva (diva-project.org)
<pitti> pygi: ok, please mail me the URL to source package to mpitt@debian.org
<pygi> oki, as soon as it's ready :)
<pygi> Thanks
<pitti> pygi: oh, so this replaces serpentine and n-cd-burner?
<pygi> pitti, what do you mean by "replace" ? 
<pitti> pygi: well, functionality-wise
<pygi> well, one of it's functions is to record audio, right :)
<pygi> and video as well, ofcourse
<pygi> pitti, some stuff like "burning over network" is also there
<Lathiat> pitti: (not that it matters now, but) should http://www.ubuntu.com/usn/usn-288-4 have listed dovecot-pop3d as well?
<pitti> Lathiat: hm, actually yes; let me fix it, thanks
<pitti> Lathiat: done
<pitti> Lathiat: does it work now for you?
<Lathiat> pitti: yeh, i commented on thebug earlier
<Lathiat> including with my original real sql queries
<pitti> great
<Lathiat> nps, thanks for fixing it :)
<slomo_> pygi: dia already has an ITP in debian and there already exists a working package... it's only not uploaded yet because diva is not really stable enough for debian yet
<slomo_> pygi: s/dia/diva/
<pygi> slomo_, It actually isnt uploaded because it require CVS dependencies :P
<pygi> But that is change with the 0.0.3 release that we are probably to do this or next week
<pygi> s/is/is going to
<slomo_> pygi: are you working on it with michael? :)
<pygi> yup, along with two more people :)
<pygi> he just merged the gdv branch which doesn't require patching
<pygi> joy :)
<slomo_> pygi: cool :) then i bet pitti won't have anything to say against the packaging, it was almost perfect last time i saw it :)
<pygi> slomo_, well, I won't send the package if there's someone already working on it :P
<slomo_> pygi: i'm not working on it, i was just curious to try it some time ago :)
<pygi> slomo_, I know you are not, but someone obviously is when it's in ITP :P
<pygi> slomo_, is Diva any good? :)
<seb128> pitti: bug #49192 might be something you want to subscribe to
<Ubugtu> Malone bug 49192 in libgcrypt11 "libgcrypt11 has an executable stack" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49192
<slomo_> pygi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359753
<pitti> seb128: oh, indeed; bluefoxicy mentioned it yesterday AFAIK
<Ubugtu> Debian bug 359753 in wnpp "Subject: ITP: diva -- Easy to use, scalable video editing software for Gnome." [Wishlist,Open]  
* pygi looks ;)
<pygi> slomo_, Biebl, right :)
<pygi> slomo_, I thought you were reffering to Michael Dominik, with who I work on Diva :P
<pygi> But right, was talking to Michael Biebl as well :P
<pygi> "I'm currently waiting on diva 0.0.3 which is due the next
<pygi> days, it's planned for this version to work with an unpatched gstreamer.
<pygi>  So this will be the first version that is uploaded to unstable."
<pygi> nice :)
<slomo_> pygi: yes :) i wonder whether pitivi or diva is faster in a usuable state ;)
<pygi> slomo_, Diva ofcourse ;)
<mjr> ooh, working with an _unpatched_ gstreamer :] 
<pygi> how can you wonder such a thing :P
<seaLne> anyone else running popcon? i got a user unknown this morning for popcon@ubuntu.com
<Mithrandir> seaLne: you're supposed to be submitting via http.
<seaLne> and if you can't because of proxy?
<Mithrandir> then we need to fix email submits. :-P
<seaLne> :)
<Mithrandir> I've been meaning to for a while, but haven't gotten around to it yet.
<Mithrandir> I probably should
<kane_> what does it take for a bug to get "confirmed" on launchpad ?
<seaLne> Mithrandir: so its been like this for awhile and its only because its me reading mail bounces that i noticed? /me slaps colleagues
<seaLne> kane_: someone else to be able to reproduce it
<Mithrandir> seaLne: it's been like that for a loooong time.  I've noticed it too, but that doesn't mean I've found time to fix it.
<seaLne> Mithrandir: np
<kane_> seaLne: well, Scott Robinson and me both have the same problem (I got it on 2 machines) ... so does the bug get confirmed ? and do confirmed bugs get more attention ? (or is it just a state ?)
<seaLne> kane_: change the state then, confirmed bugs are probably more likely to get looked at
<seaLne> kane_: dosen't mean unconfirmed get ignored tho
<kane_> seaLne: how do I change the state ?
<kane_> seaLne: i just see "edit description" ... but that doesnt change the state ..
<kane_> seaLne: https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/48164/+index
<Ubugtu> Malone bug 48164 in xorg "Video corruption at installation of xserver-xorg" [Medium,Unconfirmed]  
<seaLne> kane_: click on the package name under the affects column near the top
<kane_> seaLne: aah ok :)
<seaLne> no amazingly obvious IMHO :)
* kane_ hates "webapps"
<seaLne> i think there is an attempt to write a desktop app to talk to LP
<kane_> seaLne: it isn't assigned to anyone ... does that happen automatically ?
<Mithrandir> kane_: does it work if you start the installer with debian-installer/framebuffer=false as a boot parameter?
<kane_> Mithrandir: i havent tried that ... i can try it and report it at the launchpad
<Mithrandir> kane_: please do.
<kane_> Mithrandir: ok
<seaLne> kane_: someone will asign it to themselves (possibly) or just work on it
<kane_> seaLne: aha ok
<seaLne> don't assume its being ignored just because it isn't assigned
<kane_> seaLne: hehe ... i promise, i won't assume ;)
<janimo> Mithrandir: do you know if squashfs-lzma is still considered for the future?
<Mithrandir> janimo: argh, I knew there was a spec I'd forgotten. :-(
<infinity> Mithrandir: Assuming it Just Works, it won't need much of a spec.
<infinity> Mithrandir: Of course, if it doesn't...
<Mithrandir> infinity: it'll still take me a few days to implement, test and debug.
<dhonn> Will new releases of ubuntu 6.06 be named for example ubuntu 6.06 Service Pack 1?
<pitti> carlos: BTW, "Replaces:" was specifically meant for updating single files of other packages :)
<fabbione> dhonn: there is no such thing as Service Pack
<dhonn> Serial Key?
<dhonn> j/p
<dhonn> i mean eventually will have to roll out rehashed updated versions of 6.06 
<carlos> pitti: I didn't finish my NM process, do you remember? ;-)
<dhonn> when there will be tons of updates years later
<carlos> and seems like I didn't get that concept
<pitti> carlos: heh, but it was close enough :)
<stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downime is 15 minutes
<fabbione> dhonn: we haven't decided a name yet.
<fabbione> dhonn: probably 6.06a/b/c .. but don't quote me on that
<dhonn> oh not sp1
<dhonn> not bad
<infinity> I like 6.06.1, 6.06.2, but I suppose this will be a point of contention and much opinion until someone just picks a scheme and uses it.
<fabbione> infinity: yeah whatever.. .1 .2 is fine with me too
<fabbione> but sp1 is so mircosoftish
<infinity> Yeah, I can do without "Service Packs".
<dhonn> it sounds familiar though does it not
<infinity> Only to Windows users.
* infinity shrugs.
<Hobbsee> argh.  the idea of callign them service packs makes me cringe.
<Hobbsee> the first thing i think of w.r.t "service packs" is "how much stuff will get broken as a result of this big and bloated thing"
<Hobbsee> and that's coming from a not-really-that-long-ago XP user.
<dhonn> how about "dapper drake 2"
<Hobbsee> dapper drake update 1?  /me shrugs
<rodarvus> meeting time
<fabbione> dhonn: we will look at that when the problem will arise
<fabbione> no need to call a doctor before you get ill
<dhonn> i was just reading some ubuntu materials and came across it
<zul> hey fabbione 
<fabbione> hey zul
* fabbione -> offline
<fabbione> later
<zul> toodles
<pitti> infinity: did you already get an ok for mysql 5.0.22?
<jbailey> pitti: moin, Martin.
<pitti> jbailey: salut
<jbailey> pitti: Does SSP apply to libraries, or just the master application?
<pitti> jbailey: it applies to libs as well
<pitti> jbailey: it's a per-function modification
<jbailey> pitti: Ah, 'kay.  I wonder if it's been tested with glibc?   I'd suspect that it has been, given Fedora's work in this area.
<pitti> jbailey: btw, I'm just trying to build various apps with SSP and track the result on https://wiki.ubuntu.com/GccSsp
<pitti> jbailey: that was also on my list of things to check :)
<jbailey> Yes, the WikiMonster kindly emailed me your update. =)
<pitti> oh
* pitti currently tests php5 and mysql
<jbailey> I wasn't sure, though, because all the things you have listed there are apps not libraries.
<pitti> jbailey: but glibc would indeed be interesting, but it has a high potential for breakage, of course
<elmo> don't fedora enable SSP by default?
<jbailey> It also has a very high likelyhood of upstream caring.
<pitti> jbailey: yes, as a first start I use 'leaf' packages without many rdepends
<pitti> elmo: yes, they do
<pitti> elmo: but they certainly have a blacklist; at least xfree86 doesn't work with it, not sure about x.org
<elmo> pitti: why the enable bitwise approach then for us?
<pitti> elmo: well, just cautiousness; I thought I try a few packages locally before proposing anything :)
<pitti> elmo: and e. g. firefox and postgresql already gave problems (2 out of 7 samples), so I think some field tests are appropriate
<elmo> failing to build is one thing
<pitti> elmo: as noted in the spec, I think we can play around it in edgy and selectively enable it, and if it works well, use it by default in edgy+1 right from the start
<elmo> I'd be much more concerned if stuff broke obscurely at run time
<pitti> elmo: right, the initial packages I picked are those with big test suites, and packages I use myself
<mdke> Znarl: around today?
<shawarma> does anyone know if Dapper CD's will be available at UDS?
<elmo> mdke: his network at home is down, so probably not
<elmo> shawarma: yes, they will
<shawarma> elmo: Cool. Thanks.
<shawarma> elmo: About "the other thing"... We'll just have a chat in Paris, I suppose?
<elmo> shawarma: yes
<shawarma> elmo: Great stuff.
<mdke> elmo: ah, ouch. Thanks
<mjg59> mdz: Why am I getting notifications for every specification change on the wiki?
<ogra> mjg59, because TB is subscribed to all of them ? 
<mjg59> ogra: That's a very technical answer to the question
<ogra> :)
<jbailey> mjg59: All signs were that your schoolwork was getting too much attention.  This had to be fixed. ;)
<LaserJock> heh
<zul> heh...hey jbailey 
<jbailey> Heya Chuck
<ogra> seb128, would you mind attendint7subscribing to that spec/BOF ? https://launchpad.net/distros/ubuntu/+spec/edubuntu-dynamic-menus
<ogra> would be great to have someone with more insight attending
<seb128> ogra: not at all, I've just started reading the list of specs and subscribing to some
<ogra> cool ! :)
<seb128> ogra: that looks like a "use sabayon and do a profile by class of user" case
<ogra> seb128, sabayon is broken ...
<ogra> at least for ltsp
<ogra> additionally we thought that enhancing the sudo stuff in the menus should be possible ...
<seb128> not really scalable
<ogra> so .desktop files could get another category field 
<seb128> it would force to edit every .desktop
<LaserJock> seb128: heh, give it do bddebian, he'll fix 'em up ;-)
<seb128> LaserJock: I don't want somebody to create extra divergence from upstream or Debian for that
<ogra> yeah, lets see what we can come up with in the BOF ...
<bddebian> Howdy
<mvo> Keybuk: what is the policy to get a spec from "Informational" back to "normal" (langpack-on-cd spec)? Can I just set it back myself if I feel I have adressed the comments?
<ogra> mvo, there is a way to switch it back ? 
<Keybuk> mvo: the summary in LP still hasn't changed
<Keybuk> there's no scope to the spec, it doesn't list source packages that need changing, etc.
<Keybuk> it reads as "this is something we should do" (informational) not "this is how we should do this"
<mvo> ogra: yes, in "Edit details"
* mvo updates again
<ogra> mvo, i meant rather "there is a way to get switching back approved ?" 
<looksaus> hi, I'm trying to use launchpad's malone as a bug tracking system for a project
<looksaus> how exactly do I enable that?
<jbailey> looksaus: Best to try #launchpad
<Lathiat> looksaus: try #laucnhpad
<Lathiat> err, #launchpad, or what jbailey said :)
<looksaus> ok, thx
<jbailey> Lathiat: It's like #laucnhpad, but different ;)
<LaserJock> I thought it was lunchpad ;-)
<Lathiat> hehe
<looksaus> hm, I tried #daphcnual , just like you said, but noone answers there :p
<looksaus> no, sorry, should let you work
<looksaus> thx for your great work on ubuntu!
<pitti> Riddell: do you run dapper or edgy? if dapper, can you please dist-upgrade to today's daily dapper langpacks and tell me about any problem?
<sivang> re all
<sivang> is there a SoC to make pptp connection establishment (ADSL/Cable) ootb operational ?
<infinity> pitti: No, I'll get on that when I wake up tomorrow and push the upload when it's okayed (I want to pull an RC packaging fix from sid while I'm at it)
<bddebian> Heya sivang
<bddebian> jbailey!  Wow :-)
<jbailey> bddebian: Hmm?
<pitti> infinity: I mean, did mdz approve it UVF-wise?
<bddebian> jbailey: Just a hello and nice to see you :-)
<infinity> pitti: No, that was the "I'll get on it" bit (as in, I'll okay it with him, etc)
<pitti> ah, thanks
<infinity> I should get off to bed so I can wake up early enough to catch mdz in the morning.
<jbailey> bddebian: Ah, and hello to you too.
<hunger> How is the toolchain comming along?
<Riddell> pitti: dapper, upgrading
<Riddell> pitti: is deb http://people.ubuntu.com/~pitti/langpacks/daily/ ./  right?
<pitti> Riddell: correct
<pitti> oh, no
<pitti> Riddell: http://people.ubuntu.com/~pitti/langpacks/daily/dapper-updates ./
<pitti> Riddell: since we also have {hoary,breezy}-updates now
<Riddell> pitti: bengali and english both working fine in daily/dapper-updates
<pitti> Riddell: great, thank you
<Riddell> infinity: can you set qt-x11-free/3:3.3.6-1ubuntu6 to compile?
<Riddell> infinity: and kubuntu-default-settings/1:6.06-22
<infinity> Riddell: Those are both in -updates?
<infinity> Riddell: -updates will be back on full-auto tomorrow.  I'll make sure they get through.
<Riddell> infinity: yes, both in dapper-updates
<wasabi_> lvm2 package. lvm2.preinst. Appears to 'exit 1' if the kernel version is less than 2.6.12?
<wasabi_> Sort of breaks upgrades.
<wasabi_> Hoary->Dapper upgrade issue, basically.
<ogra> thats unsupported anyway iirc
<infinity> We don't support hoary->dapper direct.
<infinity> And "breaks upgrades" isn't really the term you're looking for.  You want "halts uprades until you install a newer kernel, reboot, and re-run the upgrade".
<wasabi_> Yeah. ;)
<pygi> jdub, poke? :)
<desrt> BenC; ping
<BenC> desrt: pong
<desrt> BenC; can you please edit hid-core.c and go down to the powerbook Fn device ID quirks list
<desrt> i just got an email from a guy
<desrt> as it turns out, 0x217 is the ID only for the white macbook keyboards
<desrt> the black models have id 0x218
<desrt> so i imagine just copy the 0x217 line and add a 218
<BenC> so add 218?
<thom> crack!
<desrt> ya
<ogra> there are black macbooks ?
<desrt> yup.
<desrt> they cost $200 more than the white ones
<desrt> for no obvious reason
<ogra> you dont have to clean them as often :)
<desrt> fair
<desrt> but i wash my hands pretty frequently
<desrt> so my white one stays pretty clean
<thom> they're trying to convince people they're as cool as thinkpads ;-0
<desrt> they look cool and all
<desrt> but they're matte finish
<mgalvin> a sleek black case makes it faster ;)
<jjesse> especially if you paint flames on it
<desrt> if you want a matte black laptop (instead of shiny white) then why not just buy a PC?
<jjesse> flames always speed things up
<mgalvin> hehe :)
<jono> hey ho
<jono> Keybuk, ping
<Keybuk> jono: heyhey
<jono> Keybuk, I need a talk title from you for LRL06
<jono> and not, Scott James Remnant r0x0r
<Keybuk> "Edgy"
<jono> cool
<bddebian> I like SJR r0xx0rz ! :)
<thom> bddebian: but it's lies!
<bddebian> thom: sshhh, I'm trying to kiss ass ;-)
<jono> heh
<jono> Keybuk has been upgraded from "mic boy" at LRL05 to "speaker" :)
<Keybuk> pun intended?
<jono> eh?>
<Keybuk> "microphone" to "speaker"
<jono> oh, heh
<jono> not intended, but ahha!
<Keybuk> but yeah, edgy is going to be my topic
<Keybuk> all the shiny things to come
<Keybuk> or all the bad things
<Keybuk> btw, is it lug tonight or next week?
<jono> Keybuk, next week, although I won't be there
<Keybuk> me neither
<Keybuk> (Paris)
<jono> ahhh cool
<jono> Keybuk, you at guadec this year?
<sfllaw> Can someone add ubuntu-qa as a member to ubuntu-bugs?
<Keybuk> jono: when is guadec this year?
<Keybuk> (that probably counts as a "no")
<sfllaw> I think bradb pushed a change in access restrictions.
<jono> Keybuk, heh
<jono> can't remember, in a week or so
<jono> maybe two weeks
<Keybuk> lol
<Keybuk> probably not then
<Keybuk> where is it?
<sfllaw> Keybuk: Could you help?  You're on the TB.
<Keybuk> sfllaw: err, what is it that you want?
<Keybuk> try that
<sfllaw> Keybuk: Merci bien!
<highvoltage> sfllaw: you've been learning french too? ;)
<Keybuk> pas problem
<mgalvin> sfllaw: ping?
<sfllaw> mgalvin: Pong.
<mgalvin> howdy
<sfllaw> mgalvin: How can I help you?
<mgalvin> sfllaw: i don't always have time to hang around for the meetings, what type of bug reports do you give that might be useful for UWN?
<sfllaw> mgalvin: I just give a brief overview of stats.
<jdong|coreduo> sfllaw: like what gentoo weekly news does?
<sfllaw> Sadly, LP doesn't give those to us right now.
<mgalvin> sfllaw: would it be possible for you to file me in as well each week?
<sfllaw> jdong|coreduo: Hmm.  Basically.
<mgalvin> or possible just add the notes yourself if you wish
<jdong|coreduo> alright, interesting idea
<jdong|coreduo> though that might look depressing right now!
<sfllaw> mgalvin: If you ping me, then I surely will.  Or if you grep for my name in the irclogs for the dev meeting.
<sfllaw> It is depressing.
<mgalvin> jdong|coreduo: +1 to announcing -backports updates in UWN
<mgalvin> sfllaw: ok cool, thanks
<jdong|coreduo> mgalvin: cool :)
<jdong|coreduo> great job on the newsletter, btw. I really appreciate it
<mgalvin> thanks, glad to work on it :)
<jdong|coreduo> mgalvin: how about a little status update or something on edgy development status?
<mgalvin> for sure...
<jdong|coreduo> backports requesters have been wondering where all the updated packages are, and I don't have an answer to that :)
<mgalvin> UWN will cover all kinds of edgy stuff
<mgalvin> which packages?, just for backports?
<jdong|coreduo> well, just new upstream versions in Edgy in general
<jdong|coreduo> there hasn't been much in that regard
<mgalvin> b/c the dapper-updates are manual atm, and edgy is having its toolchain fixed
<jdong|coreduo> ok, toolchain fixed, I see
<jdong|coreduo> that was the explanation I was looking for
<mgalvin> once the toolchain and X are working in edgy, the flood gates will open
<mgalvin> cool :)
<jdong|coreduo> lol, then my fun starts :)
<mgalvin> :_
<mgalvin> :)
<jpatrick> heno: ping
<heno> jpatrick: hi
<jpatrick> heno: I'm wondering about the host, how do we set up the site?
<desrt> so uhm.  neat story
<desrt> the tech support page on ubuntu.com says "if you're very new to ubuntu, go applications->internet->xchat"
<desrt> xchat is no longer part of the default install
<jdong|coreduo> hah, someone forgot to update the site to reflect Dapper :)
<desrt> that would appear to be the case.
<desrt> what would be nice is a javascript/forms-based web irc client (obviously no flash or java) that takes users directly to #ubuntu
<jdong|coreduo> that would be cool
<jdong|coreduo> wonder if AJAX can do irc
<desrt> i've seen it pre-"ajax"
<jdong|coreduo> I've seen chat apps done in ASP.NET before ajax
<jdong|coreduo> so it's definitely possible
<jdong|coreduo> then again, asp.net was kind of "magical" in that respect...
<desrt> http://webchat.xs4all.nl/cgi-bin/ircnet/irc.cgi
<desrt> something like this
<desrt> it's not bad
<_ion> AFAIK it isn't possible to connect to an arbitrary service using plain ECMAscript. One would need a HTTP wrapper even if she used BORAX.
<desrt> ion; the webserver does the connection for you
<_ion> ChatZilla uses Mozilla's internal API (which isn't available for BORAX) to connect to IRC.
<desrt> ion; and you interact with the webesrver
<_ion> Yes, in that case BORAX doesn't "do IRC".
<_ion> Or at least i consider it that way.
<_ion> The web application "does IRC", and BORAX is just a method of doing things in the UI.
<desrt> is borax some other word for ajax?
<ogra> sounds like a poison 
<desrt> sounds like a cleaning agent
<jdong|coreduo> desrt: both do :)
<jdong|coreduo> borax is fun as a cleaning agent
<_ion> Ajax and Borax are cleaners. I use the term somewhat humorously instead of AJAX because i hate the term "AJAX". :-)
<_ion> For instance, AJAX doesn't really have anything to do with XML.
<jdong|coreduo> ever put glue in a borax solution before?
<jdong|coreduo> lol
<_ion> XML _might_ be used with AJAX, but the programmer might choose e.g. plain text or JSON instead.
<desrt> ajax is like web 2.0
<desrt> it doesn't actually exist
* _ion is already using Web 3.0
<desrt> i'm glad that everyone has realised that web2.0 is a joke :)
* desrt was seriously starting to get concerned there
<Jhair> [I've sent this to #ubuntu too, sorry for the duplicates]  Changelog for recent mozilla security update is not accessible from aptitude (see http://mandala.no-ip.info/~jtocancipa/mozilla_changelog_aptitude.jpg). Are in general Changelogs for security updates accessible through aptitude?
<kagou> hey seb128 :) hi everybody
<seb128> lu kagou
<desrt> Jhair; i've never known a changelog to be accessible :p
<ogra> desrt, thats because youre not in the a11y team ;P
<desrt> ogra; not that sort of acccessible :p
<ogra> the others are at changelogs.ubuntu.com :)
<BenC> 2.6.17-1.1 is showing up in lp now, but everything is listed as Needs Build
<BenC> if I upload -2.2, will it supercede -1.1, leaving it unbuilt?
<BenC> this is edgy kernel
<seb128> do other people have the option to change a bug importance?
<dieman> dont think so
<seb128> is there some team membership required for that?
<dieman> i can't at least
<dieman> im guessing o
<dieman> so
<seb128> ok, thank you
<seb128> anybody from the distro team? :)
<seb128> pitti, mvo?
<pitti> seb128: no idea, sorry
<seb128> pitti: open any bug, click on the task, look if you can ...? :)
<pitti> seb128: oh, you mean ubuntu-core-dev members :)
<seb128> it's displayed as a label here, it used to be a list of options to pick
<seb128> pitti: as said, I've no idea if a team membership is required
<pitti> seb128: no, I can't
<seb128> I'm trying to understand why I'm not authorized to set bug importance :p
<pitti> seb128: might be due to today's LP rollout
<seb128> ok, so I'm not alone, good ;)
<seb128> I'll go ping #launchpad guys then
<mvo> seb128: hello
<seb128> mvo: that's fine, thank you ;)
<chantra> can someone tell me why a package didn't make its way through revu.tauware pls
<ogra> chantra, wrong channel
<chantra> ogra: #ubuntu-motu?
<ogra> yep
<chantra> okie, sorry for the troubles ;)
<Riddell> infinity: what's happening with qt in dapper-updates?
<LaserJock> doko: ping?
<mdz> doko: do we still need gcj-4.1?
<mdz> doko: I thought the only reason was to get gcj 4.1 in main while gcc-4.1 stayed in universe
<mjg59> mdz: Is there any way that I can stop getting updates every time a spec is edited in the wiki?
<mdz> mjg59: procmail?
<mdz> I'm not particularly keen on that feature myself
<mdz> mjg59: (discussing on #launchpad)
<Keybuk> mdz: did you approve seb's upload of gnome-doc-utils?
<Keybuk> (or is it granted under gnome +1)
<Keybuk> likewise pango-1.0
<Tonio_> 'evening
<Tonio_> lodlu
<bddebian> Heya Tonio_
<Tonio_> hey bddebian
<mdz> Keybuk: if they're part of the gnome point release, yes
<bddebian> Damnit, how can I test interdependent packages locally?
<Keybuk> mdz: I have a hard job telling what is and isn't part of a gnome point release
<Keybuk> hmm
<Keybuk> the version of pango he uploaded _is_ in ftp://ftp.gnome.org/pub/gnome/platform/2.14/2.14.2/sources/
<Keybuk> but the version of gnome-doc-utils he uploaded is newer
<mdz> Keybuk: is the changelog enlightening?
<Keybuk> mdz: translation fixes it appears
<Keybuk>    * New upstream version:
<Keybuk>      - Fixed plurals for fr, wa, nso; bug #338641
<Keybuk>      - Updated translations:
<Keybuk> (list of languages)
<mdz> if it's only translations, those were blanket accepted
<Keybuk> ok, I'll accept both of those then
<m0Zzg> http://linuxff.org.ru
<_ion> A spambot.
<Keybuk> he used the wrong colours
<Keybuk> http://launchpad.net/
<Keybuk> that's what he should have done :p
<dieman> rock, got my own archive setup and changed the key in the installer so i can get my own copy of base-passwd in the debootstrap
<dieman> so many contortions for crazily allocated uid's
<dieman> (on my end for the crazy uids, not ubuntu)
<ProN00b> does ubuntu set any iptables by default ?
<sladen> ProN00b: no and -> #ubuntu please
<ProN00b> sladen, i already asked there, no answer, there are only like users in there, they don't know shit or get distracted by the mass spam and don't bother to answer
<rpedro> hello
<Fjodor> ProN00b: I think the message was "you're offtopic in here, so don't ask. It's #ubuntu or elsewhere, not here"
<ProN00b> Fjodor, i got that message, but thats not an answer
* mode/#ubuntu-devel [+o Keybuk]  by ChanServ
<Keybuk> ProN00b: this is not a support channel.  it does not become a support channel if you are unable to find the answer elsewhere either
<rpedro> found a problem with the xubuntu .jigdo file at cdimage.ubuntu.com
<ProN00b> i am not asking for support but only for an answer to an yes/no question
<tseng> that falls under the "support" umbrella
* pygi nods
<tseng> and arguing it doesnt help
<rpedro> I had to modified it , otherwise it wont find the .template file :-/
<thom> ProN00b: and sladen already said "no" anyway
<ProN00b> no, it doesn't, tseng, so stop it ! ^^
<ProN00b> thom, oh, yeah, thanks for notifying me
<tseng> thanks for paying attention
<tseng> thom: should we put mongrel in edgy? :)
<thom> definitely mate
<thom> i'm on the currentest pre-release and it works really well
<tseng> i am seeing more people using it now
<thom> yep yep
<thom> hrm, pub
<Kaloz> .oO(who had that braindead idea to ship hostap without firmware upgrade support?)
<cyanescent> Does anyone "get" launchpad
<Keybuk> cyanescent: ?
<cyanescent> Keybuk: can't add any feature specs on the ubuntu-art page
<Keybuk> "the ubuntu-art page" ?
<Keybuk> URLs would help at this point
<cyanescent> keybuk: https://launchpad.net/people/ubuntu-art/+specs
<Keybuk> that's because ubuntu-art is a person
<Keybuk> you can't file a spec against a person
<cyanescent> or am I being lame ?
<Keybuk> https://launchpad.net/distros/ubuntu/+specs
<cyanescent> ok so I login, and click on my name
<cyanescent> but I still can't add any
<cyanescent> + add myself to the list ;/
<Keybuk> why did you click your name?
<Keybuk> login, then from the /distros/ubuntu/+specs page, you can click "+ New Specification"
<Keybuk> or you can click a spec and subscribe to it
<cyanescent> well, I thought it might do something interesting
<cyanescent> oh
<cyanescent> k
<cyanescent> but then its listed with non-relevant stuff 
<cyanescent> ok thanks that now appears
<cyanescent> hmm... a little steep the learning curve on this proggy
<evilrabbi> i need help
<evilrabbi> xine wont install and i cant look at my porn
<mdke> evilrabbi: #ubuntu
<evilrabbi> HWY
<evilrabbi> k
<evilrabbi> is it true that ubuntu developers are pedos ?
* bddebian wonders what a pedo is but doesn't want to feed the troll
<_ion> evilrabbi: You really have to work on your troll routine.
<evilrabbi> bddebian pedophile
<_ion> evilrabbi: I have seen some good trolls; frankly you're not one of them.
<mdke> _ion: no need to talk to it
<evilrabbi> in other words ubuntu is a way for them to trick kids in to /msging them for "help"
<_ion> mdke: Yeah, i'll ignore it from now on.
<evilrabbi> _ion was on mdke was on "To Catch A Predator"
<evilrabbi> he was chasing a cat around naked
<mdke> Keybuk: if you're still around
<Keybuk> mdke: I am
<Keybuk> ?
<Keybuk> oh ^
<mdke> can you bitchslap this guy
<evilrabbi> =(
<evilrabbi> i'm not 10
* evilrabbi was kicked off #ubuntu-devel by Keybuk (Please read the Ubuntu Code of Conduct before rejoining)
<evilrabbi> =(
* evilrabbi hugs Keybuk
* mode/#ubuntu-devel [+b *!*evilrabb@*.onlineok.com]  by Keybuk
* evilrabbi was kicked off #ubuntu-devel by Keybuk (Please read the Ubuntu Code of Conduct before rejoining AGAIN)
* _ion counts seconds until it joins using another host.
* Keybuk glares at mdz
<Keybuk> STOP FILLING UP MY INBOX!
* mdz hands the concept of mail filtering to Keybuk
<bddebian> heh
<Keybuk> mdz: I do filter e-mail
<Keybuk> Launchpad just defeats that by sending everything to one address
<Keybuk> I'm clearly going to have to make a special case for wiki changes
<mdz> I already filter wiki changes to a separate folder
<bluefoxicy> <3 thunderbird filters
<Seveas> Keybuk, doesn't blueprint add nice flterable headers?
<Keybuk> Seveas: no, they're just x-generated-by: launchpad ones
<Seveas> bah
<Seveas> file a bug 
#ubuntu-devel 2006-06-15
<bddebian> Heya
<Keybuk> heyheyhey
<bddebian> Hi Keybuk
<Keybuk> how goes?
<bddebian> You are speaking to me? :-)
<Keybuk> why should I not?
<bddebian> Because I am a pain in the butt? :-)
<whiprush_> keeeeeeeybuk!
<bddebian> Anyways, OK, thanks.  You?
<bddebian> Hello whiprush_
<whiprush_> hi bddebian 
<Keybuk> *shrug* I've never noticed if you are :p
<Keybuk> I'm a pain in the neck, myself
<bddebian> heh
<Keybuk> or possibly a pain in the testicles
<bddebian> hmm
<dieman> bah, bastards.
<dieman> some company is renting gps units in paris for walking tours now
<dieman> figures i finally break down and get a gps
<zul> hmm...lets go break grub
<Keybuk> I've still yet to succum
<dieman> heh
<dieman> picked up an etrex vista
<dieman> it also works on the bicycle
<whiprush_> jdub: any word on that ubucon thing post-LWE? the wiki/list are dead.
<jdub> i subbed
<jdub> totally quiet
<jdub> i think i will contact the dude, see what i can help with, before saying anything on list
<BenC> so when will the edgy buildd's start actually building stuff?
<bddebian> Uh oh
<bddebian> You just delayed it another 2 weeks :-)
<BenC> heh
<Keybuk> woohoo!
<Keybuk> this actually does something when I ring it
<bddebian> ??
<whiprush_> jdub: fyi, I sent him a few mails, no response. One of my friends in the googleplex is asking on their internal list about what the deal with the event is.
<jdub> whiprush_: hrm, ok
<whiprush_> jdub: I am bringing lots of people from my lug, and some other ubuntu guys from ars are planning to attend, so if google is willing to host, we could probably do something sweet.
<jsgotangco> good morning
<Keybuk> bddebian: trying to get VoIP working
<Keybuk> so Asterisk playing nice with a SIP provider
<bddebian> Cool
<bddebian> Heya jsgotangco
<whiprush_> jdub: mostly, I'm concerned that if google is going to commit to hosting the thing, that we can get a good amount of community folks involved. (I'm worried about it because some of us need to get employers to sponsor us, buy plane tickets, etc.)
<Keybuk> jdub: 4,000 dollars, eh?
<Keybuk> oh, you didn't get cc'd on that one
<jsgotangco> whiprush_: ubuntucon?
<ajmitch> whiprush_: sneak in a plane ticket for me, will you?
<whiprush_> jsgotangco: http://www.linuxpip.org/ubuconwiki
<jsgotangco> 18-19
<LaserJock> whiprush_: I was planing to go, but I email the list and never saw my email
<LaserJock> whiprush_: I'm still interested if something turns out
<whiprush_> LaserJock: you seem to be in the same boat as the rest of us. :D
<LaserJock> whiprush_: where are you located?
<whiprush_> LaserJock: Michigan
<LaserJock> oh, that's some distance to go, I'm only 4 hrs drive away in NV
<whiprush_> LaserJock: can't afford to go to paris, so I do what I can. :)
<LaserJock> whiprush_: yeah, that's pretty good coming from Michigan
<ajmitch> whiprush_: unless there's some miracle, I doubt I can make it either :)
<stuNNed> is there way to install glibc 2.4 alongside ubuntu glib2 2.3 so that i can get the latest gnomad2 working with this blasted zen microphoto?
<whiprush_> ajmitch: we need to win our respective lotteries...
<stuNNed> :D
<stuNNed> i'll pay very large bounty :D
<ajmitch> whiprush_: yeah, but that means I need to buy a ticket or something
<whiprush_> ajmitch: funny, I have the same problem
<bddebian> Haha, take that Attal,  you POS
<stuNNed> so there is no way to congruently run glibc2.4 alongside 2.3 so that i can install this dastardly bleeding edge package for my creative zen to work?  i lost the receipt
<stuNNed> :D
<Lathiat> ajmitch, whiprush_: i got a winnign notification in my e-mail just now, would you like some? :)
<bddebian> hehe
<bddebian> stuNNed: I don't know, sorry :-(
<jsgotangco> haha
<ajmitch> Lathiat: sure, send me your bank account details
<Lathiat> only one catch you need to put $1500 up front so they can ship the money to you..
<bddebian> Oh, you won the Nigerian Lottery? ;-)
<Lathiat> howd you know!
<jsgotangco> he won too
<stuNNed> bddebian: that is ok, i'll figure it out :)
<ajmitch> stuNNed: are you sure you're not mixing up glibc & glib?
<bddebian> Oh, hmm
<Keybuk> bleh, now it's stopped working again
<bddebian> ajmitch: Wanna look at some packages for me? :-)
<ajmitch> bddebian: not really, I'm doing stuff :)
<bddebian> What a surprise
<ajmitch> yes, some things have to be worked on now, rather than next week
<bddebian> Hi Hobbsee
<ajmitch> Hobbsee will do it for you
<Hobbsee> heya
<Hobbsee> what's this/
<ajmitch> bddebian wants me to look at packages he's working on
<bddebian> Hobbsee: I have packaged Attal 0.10 and I want it as clean as possible before sending over to Debian BTS :_)
<Hobbsee> ah, i see..
<bddebian> And ajmitch doesn't love me anymore
<Hobbsee> poor bddebian :P
<Hobbsee> bddebian: do you really expect me to be able to clean it up?
<LaserJock> he expects perfection Hobbsee, nothing less :-)
<Hobbsee> LaserJock: well, i'm far from perfect :P
<bddebian> Hobbsee: No, but thanks
<Hobbsee> :)
* Keybuk beats his head against asterisk for a bit
<Keybuk> I can get it to accept calls and route them to the demo thing
<Keybuk> I can register a softphone with it, and make outgoing calls from that
<Keybuk> but if I try to connect the incoming calls to the softphone, *bam*
<Keybuk> oh, and if I try and have the config that works for accepting calls, and the config that works for outgoing calls, at the same time *bam*
<Keybuk> la la la
<bddebian> You must enable bi-directional.. ;-P
<Keybuk> I think I need to enable "read the docs and stop cargo-culting" :p
<Hobbsee> Keybuk: reading documentation?  surely not!
* Hobbsee thought that was illegal.
<Keybuk> it does appear that the authentication options that allow incoming prevent outgoing
<Keybuk> and vice-versa
<Hobbsee> very useufl
<bddebian> "Your lack of faith disturbs me.." :-)
<dieman> heh
<dieman> theres a whole bunch of us at the comfort inn
<dieman> down the street from the radisson
<dieman> that will be a ragtag group on the street walking over
<Keybuk> woohoo, I now have dialling in and dialling out allllmost working
<Keybuk> just the sound is a bit one-way
<Hobbsee> Keybuk: yay!
<Keybuk> and I'm sure I've seen that in the tech-support area
<wasabi_> Wonder what ever happened to dpkg file class support
<womble> What packages need to be installed to verify Release signatures?  I've got a custom Dapper installer that's pitching a fit about unverified packages.
<pitti> Good morning
<jsgotangco> good morning pitti
<Hobbsee> hey pitti 
<jsgotangco> the teamspeak server is smoking hah
<crimsun_> 'morning, pitti 
<Keybuk> woohoo!  I rock
<zyga> hello
<zyga> :)
<mvo> Keybuk: wooohhoooo! you rock!
<pitti> hey crimsun_ 
* pitti bows to Keybuk :)
* Keybuk now has a working VoIP setup
<pitti> jsgotangco: oh, how many people have played with it by now? :)
<jsgotangco> pitti: 4
<zyga> Keybuk: whoa! :)
<pitti> Keybuk: did you get a proper voip phone?
<Keybuk> and there's only one "remove this and the magic goes away" config option
<jsgotangco> at the moment, me, imbrandon_ and TheMuso are in
<Keybuk> pitti: no, that's the next step
<Keybuk> pitti: for now I have ekiga on the laptop
<imbrandon_> very nice
<pitti> jsgotangco: yesterday it was quite fun
<Keybuk> but I do have a proper UK phone number for it <g>
<pitti> Keybuk: ever looked at http://www.sipgate.co.uk?
<Keybuk> pitti: I tried sipgate, but didn't have much luck with them
<pitti> Keybuk: I registered at sipgate.de the other day and now have a free .de number
<Keybuk> so I was pointed at http://www.voip.co.uk/ which seems to work rather better
<pitti> great
<imbrandon_> vent is nice too for group 
<imbrandon_> VoIP
<Hobbsee> jsgotangco: pitti:  jsgotangco cant count - at least 5, so far
<Hobbsee> this is fun :)
<Keybuk> I guess the next step as well is to figure out how to support IP dialling
<sivang> morning all
<imbrandon_> moins
<crimsun_> pitti: I have a quick question RE: mozilla-thunderbird's effect on thunderbird-quickfile (bug 49707). I wasn't sure whether a simple rebuild, which is confirmed to resolve the dependency issue, should be targetted for -security, but following the example for mozilla-thunderbird-enigmail, it seemed logical. Is that reasoning sound?
<Ubugtu> Malone bug 49707 in thunderbird-quickfile "Latest Thunderbird update in dapper-security forces deinstallation of thunderbird-quickfile" [Medium,In progress]  http://launchpad.net/bugs/49707
<Hobbsee> hey sivang 
<pitti> crimsun_: yes, now that the archive is working again, I'll care for the extensions today
<crimsun_> pitti: ah, ok. Thanks much.
<pitti> crimsun_: enigmail is done, the rest is universe and thus doesn't need USNs
<crimsun_> was just trawling LP and spotted that one
* sivang notices elmo 's message and goes to install TeamSpeak
<sivang> hey Hobbsee 
<Hobbsee> heya
<imbrandon_> come join the party 
<imbrandon_> lol
<sivang> party?
<imbrandon_> was a /bad/ joke about TS
<TheMuso> heh
<pitti> jsgotangco: whoa, yesterday teamspeak.uds.ubuntu.com still worked, now it says 'host not found'
<sivang> that's our teamspeak server to connect to?
<sivang> (Doh)
<TheMuso> People are still on here.
<imbrandon_> i'm connected to teamspeak.uds.canonical.com
<pitti> $ host teamspeak.uds.ubuntu.com
<pitti> Host teamspeak.uds.ubuntu.com not found: 3(NXDOMAIN)
<pitti> WTF???
<imbrandon_> not ubuntu.com
<imbrandon_>  teamspeak.uds.canonical.com
<pitti> ah
<pitti> yesterday it was u.c., thanks
<imbrandon_> ;)
<pitti> still doesn't work, the woman's voice shouts 'Error' into my ears
<imbrandon_> ouch
<imbrandon_> me and TheMuso are connected atm
<imbrandon_> and jsgotangco
<pitti> ah, now it works
* Hobbsee never got "error" - got plenty of other interesting things though
<imbrandon_> ;)
<imbrandon_> he go on
<mvo> doko: around?
* sivang notes teamspeak's installer looks like windows installaer on linux ;-)
<jsgotangco> yeah
<Hobbsee> sivang: it does.  ick
<sivang> Hobbsee: porbably using installshield or something, they try to maintain consistant look
<Hobbsee> must be
<sivang> hmm, what do I run after installation?
* sivang notes to better read elmo's instructions next time
<Hobbsee> sivang: cd TeamSpeak2RC2/ && ./TeamSpeak
<sivang> Hobbsee: yep, was in elmo 's instructions :p
<Hobbsee> ah okay
<infinity> wasabi_: Around?
<jsgotangco> "German Ubuntu Mafia"
<sivang> hrm, my teamspeak insists on retreiving a server list from the web and does not let me add canonical's one
<TheMuso> sivang: Are you using the address book?
<sivang> TheMuso: ah, thanks. terrible , terrible UI
<sivang> seems I am connected, but why does that computer lady needs to shout in my ear "connection established" or something :p
<jsgotangco> well its a game thing
<TheMuso> I turned all sounds off.
<Hobbsee> sivang: going to talk to us?
<sivang> erm, I'm a bit shy ;-)
<Hobbsee> sivang: arent we all?
<sivang> we probably need to have a channel dedicated for text convo betwen the voip participants
<kane_> Mithrandir: hello ... are you around ?
<Hobbsee> sivang: that's true...
<sivang> let's move over to #uds-paris-voip
<imbrandon_>  /join #ubuntu-ts
<imbrandon_> err ok
<sivang> imbrandon_: you'd rather that one?
<imbrandon_> dosent matter
<imbrandon_> ;)
<TheMuso> What is the channel?
<Hobbsee> TheMuso: #uds-paris-voip
<TheMuso> Thanks.
<Mithrandir> kane_: hi
<sivang> pitti: so don't use push to talk key? :)
<pitti> sivang: I do use it
<kane_> Mithrandir: i did what you suggested ... i.e., using debian-installer/framebuffer=false (if you don't remember this was for bug #48164)
<Ubugtu> Malone bug 48164 in xorg "Video corruption at installation of xserver-xorg" [Medium,Confirmed]  http://launchpad.net/bugs/48164
<Mithrandir> kane_: did it help?
<kane_> Mithrandir: the installation works now, without any video corruption ... however, there is no boot splash with the new installation ... i'm guessing this is because the framebuffer is disabled ?
<sivang> pitti: ah, so what were you proposing to me to do in order to make my stream sound better?
<Mithrandir> kane_: probably, yes.
<sivang> pitti: (I couldn't hear it well)
<pitti> sivang: use PTT
<kane_> Mithrandir: pity ... but atleast it works now
<Mithrandir> kane_: what does "cat /proc/cmdline" give you?
<kane_> one second ... the problem is on another machine, in another room ...
<kane_> Mithrandir: root=/dev/hda2 ro quiet
<Mithrandir> kane_: if you add "splash" to that list, you should get the bootsplash.  That you don't have it is a feature.
<kane_> Mithrandir: how do I add splash to that list ?
<kane_> Mithrandir: modify menu.lst ?
<Mithrandir> yes
<Mithrandir> change the defoptions line
<kane_> Mithrandir: the fact that it isn't there is a good thing right ?
<Mithrandir> yes, it's correct.  I was just thinking if you actually want usplash. :-)
<kane_> Mithrandir: my users might find it more comforting if the usplash was actually working ... but in this case, wouldn't it cause video corruption ?
<Mithrandir> kane_: maybe.  Which is why it's not there by default.  It might just be the Xorg probe function which messes it up and if so, it might work fine.
<Mithrandir> we disable it to be on the safe side when you're using d-i/fb=false.
<kane_> Mithrandir: ok ... so where does the Xorg probe function get called ?
<Mithrandir> when Xorg is reconfigured.
<Mithrandir> so not on normal boots.
<kane_> aha ..
<pitti> crimsun_: ping
<kane_> so, if I do ... dpkg-reconfigure xserver-xorg ... then it should cause video corruption ?
<Mithrandir> kane_: maybe, yes.  If you're using a framebuffer and not a text console.
<kane_> hmm ok ..
<kane_> Mithrandir: funny thing is, i tried pretty much all the kubuntu dapper flight versions (except 7) ... and they all worked
<kane_> Mithrandir: ok, thanks a lot ... i've added the comment to the bug ... hopefully someone will notice and fix the probe function
<kane_> Mithrandir: ciao
<michele> hello
<michele> I think I have this problem: https://launchpad.net/distros/ubuntu/+bug/22336/
<Ubugtu> Malone bug 22336 in Ubuntu "laptop overheats when performing CPU intensive tasks." [High,Needs info]  
<michele> and I think Dapper just fried my CPU
<fabbione> if the CPU fried, you better change laptop brands. The CPU is supposed to go in protection if it overheats and shut down everything automatically
<imbrandon> ^^ no matter the OS ( its a hardware thing )
<michele> yes, I supposed that, I'm waiting for it to cool down and see if it powers on again
<michele> it's a desktop, by the way
<michele> a P4
<michele> oh well... I'll wait for an answer to the bug by mdz...
<Keybuk> why would mdz answer the bug?
<Keybuk> it's assigned to mjg59 
<michele> oh, didn't notice that, the last comment was from mdz
<michele> well, somebody will answer, I guess and hopt :)
<HiddenWolf> Is something wrong with dapper-security?
<fabbione> HiddenWolf: why?
<pitti> HiddenWolf: what?
<HiddenWolf> I haven't seen any updates this week, while there have been quite a lot.
<pitti> HiddenWolf: hm, works here
<lifeless> cvd: you found it
<HiddenWolf> pitti: I have dapper-updates and dapper-security enabled, yet gdm for instance is at 2.14.6-0ubuntu2.1, while 2.14.7-0ubuntu1 was uploaded to dapper june 6th
<pitti>        gdm | 2.14.6-0ubuntu2.1 | http://security.ubuntu.com dapper-security/main Sources
<pitti>        gdm | 2.14.7-0ubuntu1 | http://archive.ubuntu.com dapper-updates/main Sources
<pitti> HiddenWolf: so you have the -security version
<HiddenWolf> ah
<HiddenWolf> then excuse me. :)
<pitti> HiddenWolf: -updates are not built automatically; I guess seb128 didn't poke infinity hard enough
<pitti> infinity: btw, what's the reason that every -updates upload needs to be built manually?
<seb128> pitti: actually dholbach did that one while I was on VAC, but I didn't know we need manual pocking for every upload we do
<seb128> I don't get the use for that
<seb128> infinity: please build everything dholbach and I uploaded, thank you :
<seb128> :p
<pitti> infinity: please build libgnomeprint as well
<pitti> brb, testing kernel security updates
<infinity> pitti: How do you feel about caring about cdbs?
<pitti> infinity: I would, what in particular?
<infinity> pitti: I'm watching the build in progress right now, and it looks like the whole testsuite is failing.
<pitti> infinity: uh, I'll have a look at the buildd output
<pitti> infinity: I tested it carefully locally and it worked fine
<infinity> pitti: Do you have an edgy choot (or a dapper chroot you can upgrade to edgy)?
<pitti> infinity: my desktop runs latest edgy
<infinity> pitti: Note that we now have a new debhelper and dpkg (as of a few hours ago), so the world may have broken for cdbs..
<pitti> infinity: alright, I'll have a look as soon as this kernel security update is settled
<fabbione> infinity, pitti: do we have an ETA for it?
<fabbione> -security that's it)
<pitti> fabbione: yes; current kernels will go into archive in 65 minutes, then l-r-m should build
<pitti> fabbione: ideally, I can push l-r-m by the lp_archive run in 90 minutes
<infinity> pitti: Oh, unless you really have to do staggered -security uploads, due toa bit of a bug in soyuz's handling of binary uploads from security, can you try to release source+allarches at the same time for a bit?
<pitti> fabbione: then everything should be ready in 2 hours
<infinity> pitti: Oh, or never mind.. :)
<fabbione> pitti: that would be great.
<infinity> (Since ia64's kernel still needs NEW... Feh)
<pitti> infinity: oh, right
<fabbione> oh meh. didn't elmo fix that yesterday?
<pitti> infinity: can anyone NEW the ia64 kernel?
<pitti> fabbione: ia64 wasn't yet built when elmo NEWed
<infinity> pitti: Kamion (on VAC), mdz (asleep), and elmo.
<fabbione> mdz/Kamion/elmo afaik
<pitti> right
<infinity> No other ftpmasters on jackass.
<pitti> infinity: however, pushing ia64-only uploads out with amber seemed to have worked yesterday (I didn't check the archive, though)
<fabbione> we will also need to new LRM once it's built
<infinity> pitti: It broke soyuz's build queues, but nothing we can't beg cprov and Kinnison to work around.
<pitti> so, ok for me to push all but ia64 out now?
<fabbione> Kinnison: ping?
<seb128> do we need approval before uploading to dapper-updates? Who need to be pinged for that?
<Kinnison> fabbione: yes?
<pitti> seb128: mdz
<seb128> ok
<infinity> pitti: Yeah, go ahead.  If we need it, we need it.
<fabbione> Kinnison: are you still in charge of soyuz/publisher?
<Kinnison> fabbione: Depends what you mean
<infinity> pitti: I told the soyuz posse that we'd TRY to do releases of all arches at once, but -security on primary arches takes precedence sometimes (like now)
<fabbione> Kinnison: after this kernel -security will go in, there will be a d-i upload to dapper-updates. We need to make sure that one is published properly
<infinity> Kinnison: We're about to break ia64/security build records again, BTW.
<fabbione> Kinnison: but afaik we did never tested d-i on a pocket that's not main distro
<Kinnison> fabbione: Let me see if my patch is live on drescher
<Kinnison> infinity: urgh
<infinity> Kinnison: Can't really be helped. :/
<infinity> Kinnison: At least I can tell you which build will break. :P
<infinity> Kinnison: (linux-source-2.6.15 in dapper-security)
<Kinnison> infinity: *nod* We need DB superpowah-man to clean up :-(
<infinity> Kinnison: Really?  Mistress Fiera isn't l33t enough to clean up?
<fabbione> Kinnison: while we publish -security please make sure that what you need is there because we will need to start preparing dapper sparc iso immediatly after d-i is tehre
<Kinnison> infinity: Noone but the postgres superuser can DELETE FROM Build
<infinity> Kinnison: She had enough access to change distro details, BTW (the -changes mailing list, specifically, though she had write access to that whole table)... I suspect that's a mistake, if you want to make a note of it.
<Kinnison> fabbione: Erm if the code isn't there you're going to have to wait. Kiko won't let us have unreviewed code in the codeline
<infinity> Kinnison: Though it was handy in a pinch when we needed to fix it. ;)
<fabbione> Kinnison: i will take care of that.
<ivoks> pitti: hplip is broken, not cups :)
<pitti> ivoks: :/
<Kinnison> fabbione: Right, my code fix is not live currently, so an upload of d-i to dapper-security would break horribly an I'd prefer you didn't do it yet
<fabbione> Kinnison: dapper-updates
<fabbione> Kinnison: not security
<infinity> pitti: I'll pay you to look at cdbs and fix it for me, so the buildds can happily go back into full-auto mode (which will make -updates much happier..)
<Kinnison> fabbione: dapper-updates, dapper-security, whatever, it's not dapper
<ivoks> pitti: i can't print from fresh dapper install on HPLIP, and I can't print from breezy->dapper upgrade on HPLIP (but i can't print on USB either here)
<fabbione> Kinnison: ok. can you please mail me the details about it and CC kiko, stevea and sab ?
<fabbione> (and mdz please)
<pitti> infinity: no need to pay me, I like it enough to care for it :)
<Kinnison> fabbione: yep, give me a few mins
<fabbione> Kinnison: thanks
<infinity> pitti: That's perverse.
<doko> pitti: GssSsp, firefox should build with the recent gcc-4.1 version in edgy
<infinity> pitti: https://launchpad.net/+builds/+build/202163
<pitti> fabbione, infinity: linux-source-* uploaded to drescher
<infinity> pitti: Keep in mind that gcc-opt is dead (yay), so to reproduce the chroot exactly, just make sure it's up to date and make sure pkgstriptranslations is installed and enabled.
<infinity> (Perhaps you missed that bit before?)
<pitti> infinity: indeed I didn't try with pkgstriptranslations
<fabbione> pitti: thanks
<infinity> pitti: Could just be that a big NO_PKG_MANGLE around the testsuite will make it happy.
<pitti> infinity: yep, will try in a minute
<infinity> pitti: But I didn't actually look at it, just watched the log as it failed.
<Harti> hello
<Harti> https://launchpad.net/distros/ubuntu/+source/firefox/+bug/49832
<Ubugtu> Malone bug 49832 in firefox "firefox doesnt show website correctly" [Untriaged,Unconfirmed]  
<fabbione> Harti: wrong channel #ubuntu-bugs please
<Harti> fabbione: oh sorry
<pitti> ok, so cdbs tests all pass right now, dist-upgrading to latest dpkg/gcc crack
<pitti> doko: great, will try again
<infinity> pitti: default gcc isn't changed yet (will in an hour).
<infinity> pitti: So it's probably just dpkg/debhelper/perl.
<infinity> (and most likely just debhelper that's breaking it..)
<pitti> yes, I also revert to the archive perl, instead of my SSP-enabled crack
<pitti> give my download pipe some minutes to finish the dist-upgrade
<ivoks> pitti: ummm... i just did upgrade from breezy to dapper, and hplip package conflicts with hplip-base, but hplip-base stayed installed on the system
<pitti> infinity: still works with latest edgy packages
* pitti enables pkgstriptranslations
<jeroenvrp> https://launchpad.net/distros/ubuntu/+bug/49779
<pitti> still works - WTF???
<Ubugtu> Malone bug 49779 in Ubuntu "Keyboard locks up" [Untriaged,Unconfirmed]  
<infinity> pitti: Ergh.  That's not what I wanted to hear...
* infinity tests locally.
<infinity> pitti: When you enabled it, you also enabled "fail on invalid CB", right?
<pitti> oops
<pitti> infinity: since I don't have that file, it shouldn't matter
<pitti> trying again, though
<pitti> infinity: seems to work (first four tests passed)
<infinity> pitti: I'm dist-upgrading to test here, but I assume that if you have a /CurrentlyBuilding that claims to be building Package: cdbs / Component: main, the world may explode...?
<pitti> infinity: yes, indeed; trying that now
<pitti> FAIL: autotools-1.sh
<pitti> \o/
<pitti> infinity: I wonder why we didn't have a problem with this in dapper
<infinity> I think I may have added some NO_PKG_MANGLEs in the testsuite in dapper...
<infinity> Maybe they fell out of your merge?
<infinity> (base)adconrad@cthulhu:~/cdbs/cdbs-0.4.34ubuntu4$ rgrep NO_PKG *
<infinity> debian/changelog:  * Set NO_PKG_MANGLE during the testsuite run, so we don't fail when
<infinity> test/testsuite_functions:export NO_PKG_MANGLE=1
* fabbione -> food
<pitti> probably, yes
<pitti> infinity: sorry for that
<pitti> infinity: that was it, thanks
* \sh curses suses RPM build environment...where is the rpm mode for emacs
<pitti> infinity: uploading a fixed version, maybe it'll still catch this cron.daily
<infinity> pitti: I'm publishing manually right now.  It'll make it. :)
<pitti> All 21 tests passed \o/
<infinity> Huzzah.
<infinity> pitti: You have the honour of being the very last package I'm building manually before I turn the buildds back on.  Aren't you lucky? :)
* pitti wipes away the tears for so much infinity love
<HiddenWolf> pitti is a package?
<HiddenWolf> ;)
<pitti> HiddenWolf: sometimes I feel like it
<infinity> pitti's one hot package indeed, yes.
<pitti> configure: error: installation or configuration problem: C++ compiler cannot create executables.
* pitti looks at doko
<infinity> pitti: You realise that if you want to collect the binaries from jackass and upload to drescher later, you could have just ambered to jackass, then answered "no" to "upload to main archive"?
<infinity> pitti: Since the -security buildds pull from jackass's archive, not from drescher.
<pitti> infinity: oh, I thought they use the main archive
<infinity> pitti: (A neat trick to remember if you need to do a staged release, but don't want to release stuff silently to the world)
<pitti> infinity: then that's indeed a nice trick
<pitti> thanks
<pitti> /tmp/ccmU1H83.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
* doko watches pitti looking into the config.log
<pitti> doko: ^ hmm? g++-4.1
<pitti> strange
<pitti> doko: ^ that's from firefox build
* pitti fixes a typo in debian/rules and fetches the brown paperbag
* pitti hugs doko
<doko> :)
<pitti> doko: 'CXX=gcc-4.1' ... 
<doko> pitti: this is not #ubuntu ;-)
<\sh> ok...today is bank holiday...we are sitting in the office, preparing a braai now...what a life
<pitti> \sh: what is a braai?
<pitti> \sh: and which bank holiday?
<pitti> \sh: today is "Corpus Christi" (Fronleichnam)
<Hobbsee> If there's a bug of a keyboard locking up on starting a DM, where should it be assigned to?
<Mithrandir> as in, the keyboard stops working when a kdm/gdm starts?
<Mithrandir> does it happen if you start X with startx?
<pitti> infinity: so is l-r-m building already?
<\sh> pitti: braai is a barbecue
<\sh> pitti: ZA english
<pitti> ah
<\sh> pitti: and for us it's a bank holiday, no one is catholic ;)
<Hobbsee> Mithrandir: i dont know - it only happens randomly, that's the trouble.
<zul> heylo
<Hobbsee> Mithrandir: and i couldnt get to a VT to try it out, as i didnt remember that that was possible with a mouse.
<Mithrandir> Hobbsee: I'd probably say it's and xorg bug, but it's hard to say.
<Hobbsee> Mithrandir: okay, thanks
<pitti> fabbione, infinity: l-r-m is there, now we need elmo to NEW the stuff
<fabbione> pitti: thanks
<pitti> doko, iwj: yay, firefox builds with latest gcc-4.1 (even with ssp)
* pitti hugs doko
<HiddenWolf> pitti: you're already working on proactive security for edgy?
<pitti> HiddenWolf: I tested a couple of packages with SSP, yes
<HiddenWolf> sweet
<RicardoPerez> pitti: hi, martin, i would like to ask you something: i just uploaded an updated .po file into Rosetta. this template generates a .mo file which is in a -base langpack. will this update be applied into the langpacks?
<pitti> RicardoPerez: the -base langpacks won't change any more
<pitti> RicardoPerez: but if the po file changed since the dapper release, it'll go into the update pack
<pitti> RicardoPerez: i. e. language-pack-[gnome-] es
<RicardoPerez> pitti: ok, so the .po updates will go into langpacks, right? although the -base langpacks don't changes, but this is not a problem
<pitti> RicardoPerez: yes, to keep the update packs small, they contain only actual changes
<RicardoPerez> pitti: how can a package replace a file which is into another package?
<pitti> RicardoPerez:
<pitti> Package: foo
<RicardoPerez> pitti: if a .mo file is in -base, and the updated .mo file is in -es... how can it?
<pitti> Replaces: bar
<RicardoPerez> pitti: oh, ok. and dpkg doesn't complains about that?
<pitti> Kinnison: new dapper kernel source is on the archive, but not the binaries; does this need another NEW step?
<pitti> RicardoPerez: no, Replaces: is for exactly this purpose
<Hobbsee> pitti: that's a package replacing another package isnt it?  not a file in a package being replaced by another package
<RicardoPerez> Hobbsee: yes, this is exactly my question
<Kinnison> pitti: probably. check with keybuk or someone with archive admin powers
<Kinnison> pitti: remember, I'm not actually an ubuntu ftpmaster
<pitti> Hobbsee: not exactly; Replaces:/Conflicts: is for replacing a whole package
<pitti> Keybuk: can you please invoke your megapowers to new the linux-source-2.6.15 binaries in dapper-security?
<Hobbsee> pitti: yes, that's what i thought.  but what do you do if file in package A needs to be updated by file in package B?
<pitti> Hobbsee: then B Replaces: A
<\sh> Hobbsee: you need Replaces: 
<RicardoPerez> and then A is removed?
<\sh> Hobbsee: you do think about this strange kopete package?
<pitti> Hobbsee, RicardoPerez: http://www.de.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
<Hobbsee> mmm okay, i wasnt sure you would do it that way
<Hobbsee> *if you could
<Hobbsee> \sh: i'm not really thinking much at all really, but yeah
<RicardoPerez> if package B replaces A, then A is removed when B is installed?
<RicardoPerez> pitti: oh, ok, I see in the URL you post
<Seveas> pitti, SuperKeybuk, in blue tights with a big K on his chest :) 
<\sh> Seveas: no, SuperKeybuk can't wear the same clothes as SuperSabdfl
<Hobbsee> Superkeybuk will have to wear red tights with the big K on his chest then?
<RicardoPerez> pitti: thanks a lot :)
<Seveas> \sh, SuperSabdfl has orange-beown-ish tights with the ubuntu logo :) 
<\sh> Seveas: not when he is on KDE business tour ;)
<Seveas> true
<Seveas> then he has a blue mask and a dragon tail 
<\sh> Seveas: hmmm..a very difficult situation
<Seveas> \sh, heh, you're picturing it?
<\sh> Seveas: yes ... but I found something better then that....testing linux kernel EDAC functionality ...http://bluesmoke.sourceforge.net/heat_gun.html 
<Seveas> \sh, omfg
<Keybuk> pitti: ABI change in -updates?! :p
<pitti> Keybuk: in -security
<pitti> Keybuk: yes, it happens
<Keybuk> I can't see what's new?
<infinity> The NEWness is on jackass.
<Keybuk> I don't have access to jackass
<infinity> Exactly.
<fabbione> infinity:
<Keybuk> there's nothing I can do here then, right?
<fabbione> no
<fabbione> nevermind
<infinity> Oh, wait.  It's NEW on drescher too.
<fabbione> yeah
<infinity> queue -R dapper info
<fabbione> that's what pitti meant
<fabbione> 2 NEW queue?
<Keybuk> right
<infinity> want me to NEW it?  I'm in there anyway.
<Keybuk> but there's nothing obviously new there
<Keybuk> the overrides are all correct
<pitti> Keybuk: no, I mean NEW on drescher
<infinity> It's all new, it's a new ABI.
<infinity> And the components aren't right.
<pitti> Keybuk: it already passed through NEW on jackass (all but ia64, that is
<pitti> )
<Keybuk> infinity: I'll let you do it :p
<Keybuk> you know the kernel components better than I
<fabbione> can't we disable the NEW check on jackass?
<fabbione> i see very very little point of 2 NEW queue
<infinity> fabbione: The archive on jackass is a real, live, in use archive, so it needs the protection.
<fabbione> infinity: is use for what?
<infinity> fabbione: The security buildds build from jackass, not from drescher.  It's the authoritiative archive for security internally until we move to soyuz.
<fabbione> ahh ok
<Keybuk> infinity: so, what pressure do you think we can get through the firehose?
<pitti> WOOO, firefox with ssp
<Keybuk> pitti: so, I'm curious
<Keybuk> does gdb work with ssp binaries?
<pitti> Keybuk: seems so
<pitti> *** stack smashing detected ***: /home/martin/download/ssp-test-0.2/cmd-safe terminated
<pitti> 
<pitti> #2  0x00002aaaaac2eea6 in __fsetlocking () from /lib/libc.so.6
<pitti> #3  0x00002aaaaaca901f in __stack_chk_fail () from /lib/libc.so.6
<pitti> #4  0x0000000000400628 in badFunction ()
<Keybuk> pitti: even the wacky function and expression injection stuff?
<pitti> Keybuk: right now I only activated -fstack-protector, which just inserts canaries
<pitti> and reorders stack variables
<Keybuk> *nods*
<pitti> Keybuk: function injection?
<pitti> Keybuk: you mean replacing malloc() calls and such?
<Keybuk> yeah, that kind of thing
<pitti> that's heap protection, not sure whether it is in gcc
<Keybuk> or running random functions in the code
<infinity> Keybuk: Any particular reason you're +o?
<Keybuk> infinity: oh, was kicking idiots earlier
<pitti> -fstack-protection is very limited, but relatively unintrusive
* mode/#ubuntu-devel [-o Keybuk]  by Keybuk
<Keybuk> (I don't get to be on top that often)
<infinity> TMFI.
<infinity> pitti: binaries overridden and NEWed.
<pitti> doko: the stack trace above also explains why stuff is not linked to /usr/lib/libssp.so in edgy
<pitti> infinity: rock
<pitti> Kinnison: so, will anything break if I release only the missing ia64 kernel debs without source?
<Kinnison> I don't know. I don't think so
<asac> iwj: ping
<iwj> asac: Hello.
<pitti> hello asac, welcome in #u-d
<iwj> Ah, hi Alexander.
<asac> iwj: hi
<asac> I just sent a mail
<asac> for me the assertion disappears with your patch
<asac> no crash
<asac> looks indeed good
<asac> iwj: do you have a trace?
<iwj> Yes, it's in nsHTMLSelectElement::DoneAddingChildren, RestoreFormControlState, ..., ContainsOption.
<iwj> The crash happens when you leave the test page.
<asac> iwj: ok ... I will try again
<asac> iwj: how do you leave?
<asac> back button?
<iwj> Yes.
<iwj> Start, visit bug report, left-click on `testcase', back button.
<iwj> I was going to eyeball the whole patch to see if I could spot a mistake.
<asac> iwj: so you have all other patches applied too?
<asac> s/so/do/
<Keybuk> http://www.flickr.com/photos/23558147@N00/110129102/
<iwj> asac: No.
<iwj> Are they supposed to be relevant to this one ?
<iwj> They're in my other build.  I was doing them in parallel to try to spend less time waiting for the computer.
<pitti> Keybuk: cuddly
<asac> hmmm ... maybe do a quick check if this bug is still there if you add just your patch
<pitti> Keybuk: from your activity report it seems that the debian/edgy MoM will work soon?
<iwj> It could be something else in our build that makes it different.
<Keybuk> yes
<asac> iwj ... i am patching against vanilla 1.0.8
<pitti> \o/
<iwj> asac: Ah.
<Keybuk> there will be a boat load of syncs for everyone after Paris
<Keybuk> and as it assigns to the last person who touched the package now, NO ESCAPING THEM!
<Keybuk> HAHAHAHAHA AMAUAHAHAHAHAHA
<iwj> asac: I'm starting with the version of 1.0.8 in Breezy.
<pitti> Keybuk: oh god, I touched loads of packages for .pot file stuff *arrgh*
<pitti> Keybuk: at least this makes it easy to retitle the bug and cc ubuntu-archve for syncs
<Keybuk> heh
<asac> iwj: ok ... I can reproduce with leaving page :/
<Keybuk> talking of syncs
<Keybuk> where are they?
<Keybuk> ...f...
<Keybuk> MORE PONIES ON THE FIRE!
<iwj> asac: Ah.  Right.  On the build you had with all the patches ?
* HiddenWolf gives Keybuk a mild sedative
<asac> asac: yes
* StevenK notes Keybuk may need to cut down on his sugar intake.
<asac> iwj: yes
<iwj> asac: You're talking to yourself :-).
<Keybuk> StevenK: I had to eat the sugar
<Keybuk> the ants were after it
<iwj> asac: Why don't you leave this one with me and I'll stare hard at this diff for a while.
<asac> iwj: ok :) ... feel free to ping me
<iwj> Willdo.
<iwj> I'm assuming you don't know how this code is supposed to work any better than I do.  If you do then say so now :-).
<asac> guess you are right ... though, I have looked at mozilla code so much for the last few security updates, that I finally begin to understand :). Anyway, I have to do some suite backporting too. So go ahead :)
<iwj> Have fun.
<fabbione> Keybuk: i will make sure you get all my merges if all of a sudden i will become father :)
<zul> heh
<Keybuk> fabbione: and how are the twins doing? :)
<fabbione> Keybuk: fine thanks :)))
<doko> Kamion: is there something like a spec/session for reducing the size of CD images, i.e. finding duplicates and other stuff?
<Mithrandir> doko: Kamion's on vac.
<doko> ahh, remember that now ...
<Mithrandir> so unless you want to wait three or four days for your answer.. :-P
<Keybuk> there is a spec for that
<Keybuk> though there's not much to gain from reducing duplicate files in a squashfs
<Keybuk> as they only take up the space of one anyway
<ogra> just drop firefox :)
<ogra> and its langpacks
<Keybuk> and openoffice
<_ion> And GNU
<Keybuk> _ion: no, we need gcc
<ogra> (in fact we'll likely do that for edubuntu)
<_ion> keybuk: Well, perhaps we also need GNU core utils. ;-)
<Keybuk> _ion: we could use the BSD ones
<doko> Keybuk: still makes sense for the alternate CD's?
<ogra> doko, using BSD utils o_O
<Keybuk> WE'RE INTO L!!
<zul> Keybuk: lay off the crack :)
<siretart> L?
<Keybuk> siretart: a lot of packages in L...
<siretart> any chances that edgy will be ready for buisness before paris?
<ogra> like the L-kernel :)
<Keybuk> no, no
<Keybuk> dapper is the one for business
<Keybuk> edgy is the one for play
<siretart> err, open for play as in uploading latest crack and starting with merging from sid
<infinity> siretart: You can do that now.
<Keybuk> starting merging from sid?
<Keybuk> DIDN'T YOU HEAR, MAN?
<Keybuk> we're up to l!!
<infinity> *L*
<zul> ahhhh....duh...
<pitti_laptop> infinity: now, cdbs build log looks just fine now
* Keybuk wonders why there isn't a libazy
<siretart> Keybuk: I didn't really get what you are meaning with l. you started the mom machinery?
<Keybuk> siretart: sync machinery
<seb128> infinity: I though Keybuk was rejecting uploads when you do that though :p
<siretart> Keybuk: great news! I assume I must have missed some announcement about that..
<seb128> infinity: that's what dholbach told me yesterday ;)
<Keybuk> seb128: not now
<Keybuk> siretart: no, there's no announcement yet
<Keybuk> infinity: is the gatekeeper
<Keybuk> he's still floating above his sheets though
<infinity> seb128: I just installed the final buildd chroots, the world is open for business.
<seb128> infinity: ah ok, nice
<Keybuk> infinity: you have to un-click the "MANUAL" bit :p
<infinity> Well, it'll be open for business after we handhold a security build through, but shhh.
<infinity> Keybuk: Yeah, queue-builder isn't running until I'm sure I didn't just break soyuz with the ia64 kernel. :)
* siretart wonders why there isn't a libido
<Keybuk> bah, Soyuz is a resilient piece of software
<Keybuk> it can cope with anything with through at it
<seb128> infinity: BTW should I ping you to get GNOME 2.14.n uploads to dapper-updates built or are you in some automatic mode and notice them? :)
<seb128> siretart: there is a lib named like that
<siretart> seb128: hrhr
<Keybuk> -larry -Wall
<Keybuk> or is it -Larry -Wall ?
<siretart> lol
<ogra> the big -L
<infinity> seb128: They'll get build later today magically.
<seb128> infinity: ok, thank you
<mdke> is henrik on hols today?
<bddebian> Heya folks
<lamont__> Keybuk: ping
<pitti_laptop> hi lamont__ 
<lamont__> hi pitti_laptop 
<lamont__> breaking ones router is fun
<ogra> hey lamont__ 
<Keybuk> lamont__: 
<lamont__> Keybuk: I was grumbling at udev, but it appears that it may just be missing modules in the initramfs, my bad...  but I do have a question...
<Keybuk> what is your question?
<bddebian> What is the velocity of an unladen swallow? ;-)
* lamont__ asks it in /query lest he show off his ignorance in public. :-)
<bddebian> lamont__: Bah, come on, I do it constantly :-)
<lifeless> eurpoean or african ?
<ogra> flying forwards or backwards ?
<bddebian> Uh, I don't know.. aaaaaaahhhh
<_ion> I'm not a pean, you're a pean.
* lamont__ hugs "Execute a shell"
<lifeless> http://arago4.tnw.utwente.nl/stonedead/movies/holy-grail/scene-01.html
<bddebian> _ion: :-)
<lifeless> and then
<lifeless> http://arago4.tnw.utwente.nl/stonedead/movies/holy-grail/scene-23.html
<Keybuk> lifeless: it worries me that you clearly had those bookmarked
<bddebian> Real audio?  Ugh
<bddebian> hehe
<lifeless> Keybuk: nah, just good google foo
<Keybuk> holy christ, that was a musical jar
<Keybuk> in alphabetical order, what comes immediately after Marilyn Manson is not of the same genre
<siretart> This upload awaits approval by a distro manager
<siretart> do I need to ping someone, or will the 'distro manager' notice this himself?
<Keybuk> siretart: who approved the upload?
<siretart> Keybuk: you (and mdz)
<Keybuk> I did?
<Keybuk> oh, right
<siretart> jupp
<Keybuk> wpasuppository
<Keybuk> seb128: would you like miscellaneous gnome stuff approved too
<seb128> Keybuk: yeah, everything that got uploaded to dapper-updates by example ;)
<Keybuk> was libsoup yours?
<seb128> yep
<siretart> Keybuk: thnx
* lamont__ cries.
<lamont__> found the cdrom this time... still have to find /dev/sda
<seb128> Keybuk: http://people.ubuntu.com/~seb128/desktop-file-utils.debdiff too (I didn't upload that one yet)
<bddebian> wpasuppository? Haha
<Keybuk> seb128: ok
<Keybuk> bddebian: yeah, it's a pain in the arse
<seb128> Keybuk: thank you ;)
<bddebian> hehe
<ogra> lamont__, modprobe sg ? 
<Keybuk> ogra: that would be sd_mod not sg
<ogra> why not sg ? 
<ogra> (usually works for me)
<Keybuk> sg is the scsi generic devices
<Keybuk> lamont wants a scsi disk device
<Keybuk> (that won't help him either ... his problem is the scsi driver itself is missing from the initramfs)
<ogra> ah
<ogra> ok
<bddebian> modprobe wpasuppository sounds too darn funny :-)
* bddebian shuts up now
<jsgotangco> wahahaha
<Keybuk> ... r ...
<lamont__> Keybuk: actually, it doesn't seem to be... sigh
<lamont__> lrwxrwxrwx 1 root root 0 Jun 15 08:25 ./parisc/8/8:0/pci0000:00/0000:00:13.0/driver -> ../../../../../../bus/pci/drivers/sym53c8xx
<lamont__> (that's not in the ramfs)
<lamont__> rather, not booted there
<Keybuk> check /etc/mkinitramfs/initramfs.conf
<lamont__> lib/modules/2.6.15-23-hppa32/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko
<lamont__> is in the initramfs
<Keybuk> oh, that's kinda interesting then
* lamont__ goes back to the booted initramfs to play
<Keybuk> modinfo sym53c8xx
<Keybuk> compare with the modalias attribute in /sys/blah/blah
<lamont__> in the booted system, or in the b0rked system?
<Keybuk> uh, which is the booted and which is the b0rked?
<lamont__> choices are a d-i boot to partitioning, then chroot into /target, or boot like it should work, and stop in busybox in the initramfs.
<lamont__> == "booted", "b0rked"
<lamont__> how long does it wait for the root filesystem before it bails out to the shell, I wonder
<Keybuk> 3 minutes
<Keybuk> boot with break=mount
<Keybuk> then you can look yourself :p
* lamont__ continues waiting for the moment
<lamont__> it's continuing from the busybox prompt that currently stumps me
* pitti grumbles about a failing mysql test suite
<Keybuk> lamont: continuing from?
* lamont__ assumes that initramfs's /init isn't idempotent
<Keybuk> "exit" :p
<lamont__> doh
<Keybuk> the shell is a spawned copy, so you can fix things, and resume the boot
<Keybuk> it's amazing just how neat initramfs-tools is
<Keybuk> mostly because of the things we needed to debug the bugger
<lamont__> modinfo sym58cxx
<lamont__> /bin/sh: modinfo: not found
<Keybuk> oh, yeah, you can't do that in initramfs
<Keybuk> grep sym58cxx /lib/modules/*/modules.alias
<lamont__> grep sym58cxx /lib/modules/*/modules.alias
<lamont__> #
<Keybuk> hmm
<lamont__> that looks kinda like a winner, no?
<Keybuk> it does
<Keybuk> (I don't even have that module on amd64)
<Keybuk> oh
<Keybuk> duh
<lamont__> grep sym53c8xx /lib/modules/*/modules.alias
<lamont__> alias pci:v00001000d0000008Fsv*sd*bc*sc*i* sym53c8xx
<lamont__> ...
<Keybuk> grep sym53c8xx /lib/modules/*/modules.alias
<Keybuk> :p
<lamont__> having the right module name helps...
<lamont__> alias pci:v00001000d00000013sv*sd*bc*sc*i* sym53c8xx
<lamont__> that's the one we care abou8t
<Keybuk> ok, find the device, should be: cat /sys/bus/pci/devices/0000:00:13.0/modalias
<lamont__> pci:v00001000d0000000Fsv00000000sd00000000bc01sc00i00
<Keybuk> alias:          pci:v00001000d0000000Fsv*sd*bc*sc*i*
<Keybuk> those would appaer to match
<Keybuk> where did you break in the initramfs, btw?
<lamont__> after the mount failed
<Keybuk> ok
<lamont__> want me to wind it back up, or are we good?
<Keybuk> grep sym /proc/modules
<Keybuk> see if the module actually got loaded
<lamont__> nope
<Keybuk> right
<pitti> infinity: you already NEWed all the l-r-m stuff, right?
<Keybuk> /sbin/udevplug -v -s -Bpci -Iclass=0x01*
<Keybuk> what output does that print?
<lamont__>  /bin/sh: /sbin/udevplug: not found
<Keybuk> oh, sweet
<lamont__> ls /sbin
<lamont__> modprobe  depmod    rmmod
<lamont__> # 
<Keybuk> well, at least I know what the problem is
<Keybuk> ok
<lamont__> oh, do share, do share...
<Keybuk> modprobe sym53c8xx
<Keybuk> modprobe sd_mod
<Keybuk> you may need to mknod /dev/sda? as well
<Keybuk> then exit -- that should get you into the root filesystem
<infinity> pitti: Yes.
<Keybuk> did you actually finish the upgrade?
<lamont__> b 8 $partition, yes?
<lamont__> I _thought_ I did...
<Keybuk> lamont: yup
<doko> infinity: should we start with db4.4 in edgy from the start?
<Keybuk> once booted, check that udev is installed and is the latest version (079-0ubuntuXX)
<Keybuk> and update-initramfs -u
<lamont__>   * Checking root file system...
<lamont__> /dev/sda5 was not cleanly unmounted, check forced.
<Keybuk> yeah, this boot won't be "clean"
<infinity> doko: I'd like to, but it can wait for a few days. :)
<lamont__> firecall
* iwj resorts to valgrind :-/
<Keybuk> you're going to valgrind firefox ?!?!
<bddebian> eeks
<iwj> Keybuk: it's not as bad as you would think.  But it is _extremely slow_.
<iwj> It's the UMR in ld.so that's really annoying.
<mdke> jdub: whiprush_: the fridge has the docteam meeting down one day early, if you can fix that
<iwj> Come back, my 1200/75 modem.  All is forgiven.
<bddebian> hehe
<iwj> not as bad> I've obviously never tried it with SSL before.  Never trust code written by a cryptographer.
<iwj> Hmm, that's wholly impractical.  I'll have to copy the page to a non-SSL location.
<iwj> Excellent, lovely controlled conditions and of course the bug disappears !
<lamont__> Keybuk: for the next question...  how do I force particular interfaces to have particular names now?
* iwj decides a cup of tea might help.
<lamont__> Keybuk: ubuntu-standard (or equiv) wasn't installed before --> no udev on upgrade.
* lamont__ fix0rs
<Keybuk> /etc/iftab
<Keybuk> eth0 mac xx:xx:xx:xx:xx:xx arp 1
<Keybuk> eth1 mac xx:xx:xx:xx:xx:xx arp 1
<Keybuk> etc.
<lamont__> ah, that's alive again? cool
<Keybuk> yeah, it's handled by udev itself now
<Keybuk> Up-to-date:               150 (1.33%)
<Keybuk> holy crap
<fabbione> Keybuk: sit back and relax :)
<bddebian> heh
<fabbione> tomorrow's update to edgy will be fun :)
<Keybuk> hmmm
<Keybuk> I can't get these into the sync directory :p
<bddebian> Hmm, still no Xorg 7.1 in Experimental eh..
<ogra> bddebian, pfft, fabbione will package it ahead of debain for us 
* ogra runs and hides
<zul> ogra: hehe
<bddebian> ogra: fabbione said he wasn't going near X this go-round?? ;-)
* fabbione powers on the sodomotron and points it in ogra's direction
<bddebian> hahaha
<ogra> LOL
<seb128> apparently ogra likes it
<lamont__> what is it about X people and sodomizers?
<seb128> fabbione: you will need something else to point on him
<ogra> bddebian, i know why do you think i'm hiding behind this concrete block
<zul> lamont__: its the in thing
<bddebian> ogra: :-)
<fabbione> lamont__: maintain X for a while and you will understand
* lamont__ watches his router boot
<lamont__>  * Starting kernel event manager...
<lamont__> udevd[1908] : nss_ldap: could not connect to any LDAP server as cn=admin,dc=mmjgroup,dc=com - Can't contact LDAP server
<lamont__> hrm... clearly there are ordering issues there...
<lamont__> ip6tables v1.3.3: can't initialize ip6tables table `nat': Table does not exist (do you need to insmod?)
<lamont__> hehe
* lamont__ pokes fabbione 
<fabbione> lamont__: check dmesg?
<fabbione> are we hitting the usual 17bit thingy there?
<lamont__> 'twas more the whole ipv6 nat thing...
<fabbione> i didn't do it..
<fabbione> i swear..
<Keybuk> lamont: you should at least have the users and groups < 1000 in files, right? :p
<lamont__> no, my iptables rules do...
<lamont__> apparently
<fabbione> hmmm
<lamont__> Keybuk: yes
<lamont__> actually, they're duplicated in ldap, which makes things occasionally interesting...
<lamont__> (that is, the groups that users >=1000 are in leads to some humor)
<lamont__> and that led to a script to validate the stupid lists against each other
* Keybuk checks
* Keybuk double checks
<Keybuk> BOMBS AWAY!
<fabbione> FIRE IN THE HOLE!
* bddebian ducks for cover
<ogra> COVER !
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | Sync in progress
<_ion>  Duck and Cover
<ogra> :)
<mdke> i love that the check and double checks took between 8 and 20 seconds
<HiddenWolf> Keybuk: Happy dapper day?
<fabbione> Keybuk: did you remember to switch malone to readonly?
<fabbione> Keybuk: before we will get 103283984 duplicates of edgy being uninstallable
<Keybuk> fabbione: I couldn't do that even if we had to <g>
<Keybuk> mdke: the checking was mostly "makesureIput-MmakesureIput-MmakesureIput-M"
<fabbione> Keybuk: you are becoming too soft :)
<HiddenWolf> fabbione: "we have already recieved the maximum number of bugs, please try to file one again when the current batch is fixed" ;)
<fabbione> HiddenWolf: that sounds list a good excuse
<ogra> yeah
<bddebian> HiddenWolf: :-)
<bddebian> Keybuk: Would there be any point in me trying to help with/look at merges for main?
<Keybuk> bddebian: in which sense?
<lamont__> Error 101: maximum error count exceeded
<Keybuk> Error 666: file has bad magic
<lamont__> Driver 'sd' needs updating - please use bus_type methods
<lamont__> SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB)
<lamont__> SCSI device sda: drive cache: write back
<lamont__> SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB)
<lamont__> SCSI device sda: drive cache: write back
<lamont__>  sda: sda1 sda2 sda3 < sda5 sda6 >
<lamont__> why does it print that twice???
<Keybuk> to scare you
* lamont__ looks for /dev/sdaa and /dev/sdA, and is happy to find neither
<bddebian> Keybuk: Well since I couldn't upload them anyway would there even be any point?
<lamont__> Starting Name Service Cache Daemon: nscdnscd: 3873 /var/run/nscd/nscd.pid: No such file or directory
* lamont__ wonders if dapper's nscd is any better (which doesn't matter since it won't load on hppa)
<Keybuk> bddebian: you can upload to universe?
<Keybuk> oh "for main"
<Keybuk> there's always help -- when they get filed, if you prepare the packages and check the diffs, it's useful work :)
<bddebian> Keybuk: OK, will do, thanks
<dieman> lamont__: heh, im not using it right now, but i could load it up and see
<dieman> lamont__: it definately starts right up on amd64
<lamont__> dieman: it has an illegal fixup in dapper/hppa, so I still have breezy's loaded on that machine
<dieman> nice
<dieman> i think i still ahve an hppa machine
<dieman> in the basement
<dieman> somewhere
<dieman> i also recently got a newer one out of someone but disposed of it
<lamont__> the current issue of import is that I can't get the aironet card to sync with the hilltop
<dieman> suck
<dieman> is it dead?
<dieman> you getting those exciting rid errors or whatever they are when the MAC layer of that card goes out to lunch?
<lamont__> nah - it helps when all the cables are connected... :0(
<lamont__> brb
<dieman> haha
<lamont> much better
<dieman> heh
<dieman> at least it wasn't a kinked cable
<dieman> or something like outdoor pests eating it
<dieman> im guessing its some form of lrm?
<dieman> lmr?
<fabbione> lamont: got time now?
<bddebian> Keybuk: You act surprised that they even trust me with Universe??? :-)
<lamont> fabbione: sure
<KaiL> hmm... vmware-player-kernel-modules-2.6.15-23... I guess, there's no -25 Version of that?
* bddebian guesses he should subscribe to edgy-changes
<fabbione> KaiL: good point...
<KaiL> just found that while installing the player ;)
<fabbione> KaiL: yes.. agreed..
<fabbione> BenC: ^^
<fabbione> BenC: i guess we need to add vmware-player-kernel-modules-2.6.15-23 to the ABI bump list of pkgs that needs love
<fabbione> and i am already on edgy here
<KaiL> btw. there was some patch for forcedeth to make that working if you directly boot from windows to ubun tu, is that in the -25 image?
* ogra wonders what everybody is talking about with -25, none of the machines here have updates available
<fabbione> ogra: dapper-security
<KaiL> installing updates could sometimes be a good idea
<ogra> hmm, shouldnt that be enabled by default on fresh installs ? 
<BenC> I think in breezy it was a question
<fabbione> KaiL: bug number?
<BenC> so if you updated from breezy, it may not be
<KaiL> fabbione, don't know, if there is one...
<KaiL> found that in the nvidia support forum
<fabbione> KaiL: no bug number, no patch..
<BenC> no patch, no answer :)
<ogra> hmm, i have 2 updtaed systems and on new installed around me currently ... none has a update-manager notification
<BenC> KaiL: forcedeth is pretty close to the newest version, so maybe it does
* ogra digs
<BenC> KaiL: if -23 didn't have it, then -25 doesn't either
<KaiL> http://www.nvnews.net/vbulletin/showthread.php?t=71148&highlight=forcedeth
<KaiL> there we have more than enough details..
<fabbione> KaiL: if you don't file a bug it might never happen
<KaiL> as always, people cry everywhere, but file no bugs..
<KaiL> I guess, you also have no bug for some Marvell gbit eth controller? ;)
<ogra> if you dont file it ...
<bddebian> "If you file it, they will come.."
<KaiL> they are not my bugs, only found them in the forum...
<fabbione> KaiL: forum is not a bug tracking system
<fabbione> if forum users don't report bug they can go to complain to /dev/null if they are not fixed
<KaiL> I know, but looks like many problem don't :(
<fabbione> after a certain level it becomes (and i am sorry to say) their problem
<KaiL> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/49870
<Ubugtu> Malone bug 49870 in linux-source-2.6.15 "forcedeth dislikes dualboot systems" [Untriaged,Unconfirmed]  
<KaiL> ..now we have a bug ;)
<zul> yay!
<fabbione> KaiL: now take it to the right forum -> #ubuntu-bugs or #ubuntu-kernel , kthxbye
* fabbione wins again :)
<zul> you  almost always win
<AlinuxOS> pitti, hello, have 2 minutes for me ?
<iwj> OK, the crash is heap corruption.  Niiice.
<mdz> pitti: is the ia64 kernel taken care of?
<pitti_laptop> mdz: should all be well now
<siretart> Keybuk: syncs are at the same place as for dapper, right?
<mdz> ok
<Keybuk> "at the same place" ?
<siretart> http://people.ubuntu.com/~scott/ongoing-merge/, I persume
<Keybuk> those would be "merges"
<Keybuk> these are syncs
<Keybuk> syncs = updating packages we didn't change
<siretart> aah. ok. how can I confuse this?
<Keybuk> merges = updating packages we changed
<siretart> right.. 
<siretart> are syncs announced somewhere? is there perhaps even an rss feed for that?
<pitti> AlinuxOS: yes
<pitti> so, can we upload to edgy now?
<pitti> it seems like the toolchain is settled and buildds working
<fabbione> pitti: yes, it's green light
<pitti> yay
<ogra> YAY
<bddebian> Bunch of children waiting for Santa.. ;)
<Keybuk> heh
<Keybuk> publisher is off atm though :p
* Keybuk didn't want to break Soyuz
<fabbione> Keybuk: what have you done? ;)
<bddebian> How long before merges start?
<Keybuk> bddebian: merges will be timed to start in the week back from Paris
<fabbione> bddebian: merges are manual. you can start now
<Keybuk> (the auto-generated ones, that is)
<bddebian> fabbione: Well I can't since I can't upload to main :-)
<fabbione> bddebian: you can still merge and get a sponsor to upload.. also merges apply to universe too
<bddebian> Though maybe I'll look at some old ones hanging around there
<Keybuk> fabbione: nothing, we didn't know what launchpad would do if packages were being force-sync'd into edgy while the publisher was running
<Keybuk> it's safer to just not run it while the sync runs :p
<fabbione> oh ok :)
<fabbione> Keybuk: wise choise
<bddebian> fabbione: Oh I know about Universe, I did a lot of merges for Breezy
<bddebian> So Universe will open too or will that come after Paris?
<Keybuk> universe is just as open as main
<fabbione> bddebian: you can start taking over all the X ones that i got *erroneously* assigned by Keybuk script
<Keybuk> fabbione: I don't touch X :p
<Keybuk> I'd be forced to nih it, or something
<fabbione> Keybuk: you sync it and i don't touch it :)
<bddebian> fabbione: X what, merges?
<Keybuk> if we want to sync X from Debian, we can do that
<Keybuk> but after the big sync, please :)
<fabbione> Keybuk: this merge is too small for both of us.. since i am a gentlemen, you can have it :P
<bddebian> heh
<fabbione> Keybuk: i dunno really.. 
<pitti> Keybuk: do you want bugs for sync requests, or will an IRC note work as well?
* bddebian waits for Xorg 7.1 from Debian ;-P
<Keybuk> pitti: bugs with ubuntu-arch subscribed will suffice
<pitti> ok
<fabbione> Keybuk: wouldn't be easier to reassing the merge requests to something you can parse almost automatically?
<fabbione> Keybuk: we get rid of the bug and you take the sync request
<fabbione> (at least from the merging stage)
<mxpxpod> is there a place I can go to see what is in the buildd's cache?
<Keybuk> fabbione: can we not confuse merge and sync requests here
<fabbione> Keybuk: ok
<Keybuk> which do you mean?
<Keybuk> if you mean sync requests (overriding ubuntu changes) just use pitti's script
<fabbione> Keybuk: i mean. we get bugs to do merges.. right? let's assume one of this can be a straight sync from Debian.. what do you prefer us to do? make a duplicate asking for a sync?
<Keybuk> if there's a group of syncs, put them in the same bug
<fabbione> pitti's script where teh what?
<bddebian> Change descript, request sync and subscribe archive-team?
<pitti> fabbione: http://people.ubuntu.com/~pitti/scripts/requestsync
<Keybuk> merge bugs => if it needs syncing, subscribe ubuntu-archive
<bddebian> s/descript/description/
<fabbione> pitti: ok!
<pitti> fabbione: it's as easy as 'requestsync foo edgy' and it'll create a bug for you
<Keybuk>  subscribe ubuntu-archive
<pitti> fabbione: it uses debsign, so gnome-gpg etc. will work
<Keybuk> Please sync this from debian, overriding Ubuntu changes.
<Keybuk> etc.
<fabbione> oh i see
<fabbione> nice
<bddebian> I asked this of elmo before but why is it bad if say I am building foo that has a depends on bar and I know I can sync from Debian.  Why not just pull it, and upload rather than bugging the archive admins?
<fabbione> pitti: time to add these scripts to ubuntu-utils? ;)
<pitti> fabbione: I have tons of scripts like that :)
<fabbione> pitti: and why don't you make a deb for them?
<pitti> fabbione: in fact I also have a 'syncpackage' script :)
* fabbione reassigns all his bugs to pitti
<pitti> fabbione: I put them on people, that has to suffice
<ogra> fabbione, oh, thats a new fashion ? 
* ogra goes to his bug page and does the same :)
<fabbione> ;)
* pitti writes a script to bounce off reassigns
<Keybuk> bddebian: because it wouldn't be identical to the debian source package
<pitti> fabbione: for every bug I get from you you'll get three back!!!11!!one!!1!
<fabbione> pitti: :)
* pitti hugs fabbione 
* fabbione hugs pitti
<bddebian> Keybuk: OK, thanks
<pitti> fabbione: I regret that you won't be in Paris, dude
<fabbione> pitti:  i am going to miss all of you guys
* bddebian sees pitti is busy already :-)
<fabbione> but i will be there with VoIP.. probably
<pitti> bddebian: did I miss a ping from you?
<bddebian> pitti: No, the edgy-changes post already :-)
<pitti> ah
<Keybuk> pitti: we both got LWN'd
<pitti> Keybuk: I don't have an account, what does it say?
<Keybuk> pitti: just links to your langpacks u-d-a point
<pitti> one of my 9243409234320 security updates from last week?
<pitti> ah
<pitti> nice
<bddebian> Gads, there are soo many freakin bugs already
<Keybuk> woohoo!
<Keybuk> pitti has to merge dhcdbd
<Keybuk> he too can learn how to say it!
<pitti> dhcdbdbdbd
<pitti> Keybuk: I don't mind merging things I can test myself
<fabbione> Keybuk: where have you been Lwn'ed?
* fabbione can't find
<Keybuk> fabbione: distro page
<mxpxpod> I just downloaded the latest kernel and vmware-player hasn't been rebuilt for it... how would I go about requesting that build?
<bluefoxicy> You know what would be awesome?
<Keybuk> grr. I've been reading this u-d-a announce of Ben's all frakking afternoon
<fabbione> mxpxpod: it will be addressed later today or tomorrow
<pitti> and since n-m is finally working quite well for me, chdbdh, erm, dhchdnbd, no, bddbecd, this bloody dhcp daemon is fine
<siretart> pitti: care to put http://people.ubuntu.com/~pitti/scripts/ into a bzr archive? 
<bluefoxicy> If the dapper installer was able to install security updates during install
<mxpxpod> fabbione: ok, so I don't need to report a bug
<fabbione> mxpxpod: no
<mxpxpod> fabbione: thanks
<pitti> siretart: oh dear
<Keybuk> bluefoxicy: it does
<bluefoxicy> like set sources.list to be cd + http:// ... then again I haven't really tried ;)
<fabbione> mxpxpod: also because it is in multiverse and not supported anyway
<bluefoxicy> Keybuk:  it does that now?
<pitti> siretart: yes, at one point I shall collect, clean up and revisit my heap of tool scripts
<Keybuk> (at least, the text-mode one does -- it always has)
<mxpxpod> fabbione: any way to see if it's in the build queue yet?
<Keybuk> not sure whether the Live one does, even if it doesn't, they'll get prompted within a day anyway
<bluefoxicy> Keybuk:  it didn't in breezy, I brought it up and someone said if I wanted it I'd have to code it :P
<fabbione> mxpxpod: it has not been done yet. the real kernal has precedence
<mxpxpod> fabbione: ah, ok
<fabbione> mxpxpod: as i said it will be addressed today or tomorrow.
<mxpxpod> fabbione: ok, thanks
<ogra> bluefoxicy, that must have been a heavy regression against warty and hoary then, it always did that
<bluefoxicy> ogra:  I never noticed it.
<ogra> it explicitly tells you that it scans the security server even
<bluefoxicy> ogra:  I always noticed it installing PURELY from CD, then when you boot you have the security updates repo in sources.list
<bluefoxicy> and update-manager goes "HI HEY LOOK CLICK ME"
<bddebian> How do the Debian bugs get auto-imported to LP?
<fabbione> bddebian: manually. that's why elmo is always so busy
<bddebian> Well a lot of them appear to be "fixed" and never get closed
<fabbione> bddebian: that's why we are looking for another sysadmin on our hiring page..
<bddebian> Oh, hmm
* bddebian puts in an application ;-P
<LaserJock> fabbione: we can't automatically track the status?
<lifeless> LaserJock: YHBTHANDHTH
<bluefoxicy> Keybuk:  trying in qemu
<jbailey> lifeless: Congrats.  A string of letters that google doesn't match ;)
<jbailey> Pretty hard to do, really./
<lifeless> lol
<LaserJock> lifeless: hmm, can I get that in english?
<LaserJock> ;-)
<lifeless> YHBT HAND HTH might match better
<bluefoxicy> does that involve some kind of jelly?
<_ion> bluefoxicy: Yes.
<jjesse> am i allowed to google that at work?
<jbailey> lifeless: Much better ;)
<Keybuk> lifeless: you forgot "kthxbye"
<Keybuk> HTH HAND KTHXBYE
<bddebian> Am I going to get yelled at for closing them?
<jbailey> lifeless: Brad and I were talking about an hour ago about your collecting of acronyms.
<bddebian> heh
<jbailey> lifeless: I appliede YAGNI to someone here for something, and was trying to remember some of your other favourites.
<jbailey> s/collecting/collection/
<lifeless> jbailey: why thanks, I think.
* LaserJock goes back to work, is to tired to think in acronyms
<pitti> mdz: would you violently object if we reenable the web interface by default for cups in edgy? we get tons of complaints about this...
<fabbione> pitti: isn't against policy to have open ports?
<pitti> fabbione: that's not the issue here
<pitti> fabbione: it is about putting the cupsys user into the 'shadow' group so that it can verify passwords with PAM
<fabbione> oh i see
<pitti> shadow allows you to read /etc/shadow, nothing else
<fabbione> yeps
<jbailey> pitti: I thought the cups web interface required root to do anything significant?  Can it be hacked to do a sudo-type trick?
<pitti> so potentially you can get encrypted passwords through cups vulns
<pitti> jbailey: LIES
<pitti> jbailey: no, it just requires the privilege to read /etc/shadow
<fabbione> i think you can still manage the queue
<pitti> jbailey: the rest is configuration rewriting with works perfectly as normal user cupsys
<pitti> fabbione: yes, you can do normal user stuff, but no printer administration
<fabbione> yeah that would do
<bluefoxicy> <pitti> fabbione: it is about putting the cupsys user into the 'shadow' group so that it can verify passwords with PAM
<bluefoxicy> wtf?
<pitti> bluefoxicy: so?
<bluefoxicy> pitti:  isn't there another way?
<pitti> bluefoxicy: you can set a parallel user database of course
<bluefoxicy> <pitti> mdz: would you violently object if we reenable the web interface by default for cups in edgy? we get tons of complaints about this...
<pitti> but what would that change?
<fabbione> bluefoxicy: yeah sure.. you can cups as root and allow it to do everything.. so there is no need to add it to the shadow group...
<bluefoxicy> pitti:  does cups have to verify passwords?
<bluefoxicy> pitti:  err. sorry.  Does it have to change its privilege level?
<pitti> bluefoxicy: yes, for the web interface, if you want to do administrattive stuff
<pitti> bluefoxicy: in ubuntu it already has no unnecessary privileges, no need to change anything
<bluefoxicy> ok
<pitti> bluefoxicy: and 'changing privilege level' can only happen downwards, and that doesn't work with the web interface
<bluefoxicy> pitti:  is there any way to check passwords?
<iwj> asac: ping
<pitti> of course it could read /etc/shadow into memory and then drop shadow, but that's even more evil
<iwj> I think I have found the (a?) problem.
<bluefoxicy> pitti:  if [ su USER -c 'true' ] ; then echo Good password; fi
<pitti> bluefoxicy: hahahahaha
<bluefoxicy> err, () not [] 
<bluefoxicy> pitti:  I know :)
<pitti> shadow group membership is the least evil way of checking passwords IMHO
<pitti> but how it's done is unimportant
<Chipzz_> bluefoxicy: actually, no () either
<bluefoxicy> pitti:  If you use a suid wrapper that ONLY checks passwords and tells you if your test is good or not (i.e. my idiotic script above), then an attacker can theoretically break cups and proceed to use the wrapper to test passwords..... .... which is a brute force attack, he could throw that straight at ssh or something anyway
<bluefoxicy> pitti:  if you give cups shadow access, then someone exploiting cups can read the encrypted passwords, run john against them, and... well, john breaks my password in about 3.2 seconds.
* pitti radiates two tons of hate to svn merge
<bluefoxicy> (I've been meaning to fix that)
<pitti> bluefoxicy: right, that would be slightly better
<bluefoxicy> slightly, yes.
<bluefoxicy> they'd have to break the wrapper password checker to get shadow access
<pitti> bluefoxicy: I was more interested in the general yay or nay from mdz
<bluefoxicy> which is a tiny, tiny codebase that can be severely audited
<Keybuk> whhhhhhhhhhhhhhhhhhhhhheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
<pitti> Keybuk: at z?
<bluefoxicy> pitti:  nods.  I'd like the administration interface too, it's a little more full featured than the current crap we have for gnome-cups-thingy, but a typical user won't be able to find it.
<bluefoxicy> pitti:  (unless you add it to the firefox bookmarks toolbar or something)
<pitti> bluefoxicy: enough people and especially admins do know where to look
<Keybuk> pitti: publishing
<pitti> is anyone familiar with svn merge?
<iwj> We should have a userv service to do this kind of password checking.  It's not performance critical and the service could rate-limit it trivially.
<Keybuk> sources are in
<jjesse> a little, you use it to merge a trunk into branch for exampel
<Keybuk> pitti: it's just CVS merge, no?  -rX..Y branch
<pitti> jjesse: so, we have a Debian and an ubuntu branch in cups svn on alioth
<pitti> u$ svn merge ../cups-1.2@HEAD ../cups-1.2-ubuntu@HEAD .
<pitti> is what I tried
<pitti> in the ubuntu work dir
<pitti> that merged some stuff, but skipped new files
<jjesse> hmm try to remember when we merged ubuntu-docs from trunk to branch
<pitti> Skipped missing target: 'debian/patches/00_r5643.dpatch'
<pitti> Skipped missing target: 'debian/patches/56_dirsvc.dpatch'
<pitti> A    debian/patches/svn5527_str1689_printeroptions.dpatch
<pitti> and so on
<pitti> Skipped missing target: 'debian/po/it.po'
<pitti> ^ that file was added in Debian recently
<pitti> and it's not in my ubuntu branch now
<jjesse> i'm thinking as i don't remember how we merged in ubuntu-doc
<crimsun_> pitti: pong (thanks for the correct thunderbird-quickfile fix!)
<jjesse> hold on checking
<pitti> hm, in fact nothing is changed at all
<fabbione> pitti: i used to do svn merge -r$rev1:rev2 from to
<pitti> crimsun_: oh, unping, I wanted to ask you if you are fine with doing a more general fix
<pitti> fabbione: so svn can't figure out the common base version on its own?
<fabbione> pitti: or something very similar to that
<fabbione> pitti: not that i know off
* pitti wants bzr
<jjesse> pitti: i ca't remember but i know mdke did the merge
<Keybuk> pitti: absolutely not!
<Keybuk> pitti: svn has no history of merges
<Keybuk> svn merge is basically svn diff | patch
<pitti> Keybuk: and it has a very weird idea of branches, too
<pitti> fabbione: that worked, thanks mate
<Keybuk> ok, accepted is processed
<fabbione> pitti: no problem
* fabbione -> offline for a few hours
* pitti starts to fix conflicts
<Keybuk> now publishing the distro
<bddebian> w00t, go Keybuk
<Keybuk> judgejudy = Dominator(logging.getLogger("Dominator"))
* Keybuk looks at Kinnison meaningfully
<jbailey> Keybuk: I can't see judgejudy as a logger.
<zul> shes hilarious
<jbailey> Or does that make her the dominator over the logger?
<bddebian> heh
<Keybuk> Domination commencing
<highvoltage> there's really a judgejudy user?
<Keybuk> s/user/variable/
<Keybuk> well, object
<Keybuk> Generating overrides...
<Keybuk> and now the file lists...
<mdz> pitti: we disabled it because it required granting cups (which sometimes listens on the network) privileges to read /etc/shadow, no?
<pitti> grrrrrrr @ svn
<pitti> mdz: right
<pitti> svn: Commit item '/home/martin/debian/cupsys/branches/cups-1.2-ubuntu/debian/patches/55_ppd_okidata_name.dpatch' has copy flag but no copyfrom URL
<pitti> THANKS, subversion!
<mdz> pitti: perhaps we could work around that
<Keybuk> pitti: how, err, Arch-like of it
<Keybuk> ...apt-ftparchive now
<mdz> pitti: client cert authentication?  a unix_chkpw sort of helper?
<pitti> Keybuk: now I finally managed to merge everything and resolve conflicts ...
<pitti> mdz: certificates work on the command line, but not through http
<pitti> mdz: yes, bluefoxicy and I already discussed a suid password helper
<mdz> pitti: is there a fundamental reason why certificates can't work through http?
<mdz> it seems like we should be able to arrange for firefox to see the cert somehow
<pitti> mdz: you have to teach the browser to read /var/run/cups/certs/ and submit it through http
<pitti> mdz: oh, cups has its own idea and implementation of certificates
<pitti> totally different from SSL ones
<mdz> oh, I thought they were standard certs for some reason
<pitti> it's basically just a file with a long random number, and if you have the file system privilege to read it, you have proved that you are in lpadmin
<pitti> mdz: it offers other auth systems, too, but PAM is just easy because it avoids a second password database
<pitti> mdz: if people should set up that, then they will likely use their normal login password anyway
<pitti> so it doesn't help much
<mdz> right
<mdz> and it doesn't really help to restrict which users' passwords it will allow cups to check
<mdz> because in almost every case it will be a user in both lpadmin and admin
<mdz> i.e. root equivalent
<pitti> at least an attacker has a good chance for that, right
<mdz> this is why web authentication sucks
<pitti> mdz: so, implementing something like, or even using unix_chkpwd doesn't seem bad for me
<mdz> web authentication for system administration anyway
<pitti> mdz: yes, it's just that the series of complaint emails and bug reports about it never stops
<mdz> pitti: I don't think we can use unix_chkpwd; won't it only check the current user's password?
<pitti> mdz: and indeed I must agree that gnome-cups-mgr is not the end of wisdom
<pitti> mdz: yes
<pitti> mdz: I mean a suid helper which just answers 'yes' or 'no', but this needs to be implemented carefully
<mdz> we could disable authentication and allow anyone on localhost to administer cups :-D
<bddebian> Best idea yet :)
<mdz> security through insecurity
<pitti> :)
<pitti> security by redefinition
<bluefoxicy> actually mdz
<bluefoxicy> that can be done
<mdz> pitti: perhaps we could create a way to launch the web interface from the menu which would authenticate with a cert or similar
<bluefoxicy> iptables can drop packets based on the user or group the process they originate from is in
<mdz> pitti: launching the browser with a special URL or something
<mdz> pitti: then we could configure the web interface to tell the user to go there instead
<pitti> mdz: hm, that wouldn't quite work for remote administration, though
<ivoks> we should fix cups :/
<mdz> bluefoxicy: I don't think it can distinguish between cups administration requests and ipp printig requests however
<pitti> mdz: sure, submitting the certificate value through http post should work
<ivoks> it's apache ripoff anyway :)
<pitti> I'm not sure whether it's a good idea, though
<bluefoxicy> mdz:  ah
<mdz> pitti: but people who want remote administration must manually configure anyway, right?
<pitti> ivoks: btw, I'm just merging to Debian, 1.2.1 will be in edgy soon
<mdz> it doesn't listen remotely by default
<pitti> mdz: right, they have to open the port
<ivoks> pitti: nice, but we should do something about it in dapper too 
<pitti> ivoks: yeah
<mdz> pitti: I saw a message from michael sweet about this
<mdz> pitti: debbugs #369015
<ivoks> pitti: i packaged gutenprint rc3 for dapper, i'm waiting lexmark users to test it
<pitti> debian bug 369015
* pitti pokes Ubugtu
<mdz> Ubugtu: smarten up
<pitti> mdz: ah, that one; yes, I answered
<mdz> pitti: what does he have to say about our security concerns?
<pitti> oh, door bell, brb
<mdz> I suppose that it isn't much of a concern since the default config is to run as root
<pitti> mdz: I'm still angry about him for removing RunAsUser
<pitti> mdz: and he doesn't seem to care
<pitti> I have to help my gf carry some stuff upstairs, brb
<bluefoxicy> pitti:  this is why the security team needs to be a core and authorative part of distro management 8)
<bluefoxicy> when people go "Uh whatever I don't care if it's root now it works" you need to be able to SMITE THEM
<Keybuk> death row time
<bluefoxicy> nah
<bluefoxicy> I'm just more used to seeing the security teams on distros fight with the main distro maintainers
<Keybuk> no, I mean the publisher's doing the death row
<bluefoxicy> the mentality that "well we have a bug XXXX, we should fix it so it works; it opens a HUGE hole but nobody is going to exploit that right away so we can worry about that secondarily" seems semi-common to me
<pitti> re
<bluefoxicy> i.e. running random things as root
<bluefoxicy> mdz:  is Xorg 7.1 going into dapper-backports in the future or is it reserved for edgy?
<bluefoxicy> (I have a legitimately broken driver that Xorg 7.1 relnotes claim is FULLY SUPPORTED now)
<mdz> that depends on the changes, but in general I wouldn't expect it to be a good backport candidate
<mdz> it's infrastructure, and backporting such things complicates upgrades
<bluefoxicy> mdz:  nods.  I'll probably steal it from edgy then.
<Keybuk> and we're done
* pitti cheers Keybuk 
<Keybuk> a few minutes for a.u.c to catch up
* iwj resorts to killall -9 valgrind.bin
<mdz> Keybuk: what's in this publisher run? first batch of syncs?
<Keybuk> mdz: yup
<mdz> Keybuk: how big is it?
<Keybuk> about 3,500 sources
<Keybuk> edgy will basically have to be entirely rebuilt once the merges are in too
<Keybuk> there are about 150 "unchanged" packages
<Keybuk> that should keep the buildds warm over the weekend
<AlinuxOS> doko, ping
<doko> AlinuxOS: pong
* Keybuk updates mom's pool
<fabbione> mdz: U60/T1K/2xT2K/NetraT1 netboot/netinstall all GO. not a glitch.. all in different configs/setups/foos/bars
<fabbione> i guess we only need the cdimages now
<fabbione> (and d-i in)
<fabbione> anyway i am going to take a nap
<fabbione> and be back around 0 UTC in 6 hours
<fabbione> make that 5
<mdz> fabbione: hi-5
<mdz> fabbione: get some rest and we will roll CD images once the soyuz fix lands
<fabbione> mdz: the soyuz fix is already there. We need infinity to manual build d-i (hence we can't upload and test the fix without him)
<fabbione> anyway..
* fabbione -> bed
<AlinuxOS> fabbione, buona notte.
<fabbione> mdz: "everything will be fine"
<fabbione> AlinuxOS: notte
<bddebian> Heh
<bddebian> Gnight fabbione
<bluefoxicy> keyboard layout?  wtf?
* bluefoxicy already answered this question at the boot screen.
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | Edgy is Open
<bluefoxicy> Keybuk:  if edgy is open does that mean #ubuntu+1 is back?
<bluefoxicy> also why does the installer ask me keyboard layout?
<bluefoxicy> And language!
<bluefoxicy> The boot screen lets me adjust language and keymap, can't those be used to intuit language and keymap in the installer?
<bluefoxicy> (I know this is a ridiculous prospect)
<Keybuk> "#ubuntu+1" ?
<ogra> edgy+1 ;)
<Keybuk> it never left?
<bluefoxicy> seveas cleared and closed it on June 1
<Keybuk> eh?
<zul> so i should be able to do a dist-upgrade?
<Keybuk> if you were really silly
<Keybuk> it's mostly just new source at this point
<zul> but i am..:)
<Keybuk> with some binaries that will stop your machine from booting
<zul> ok maybe im not that silly
<pitti> zul: I have up to date edgy, and the only breakage I noticed are locales
<pitti> they don't work at all
<pitti> rest is fine
<Keybuk> pitti: did you reboot yet? :p
<pitti> Keybuk: yes, several times (I always shutdown when I'm not on the box)
<asac> iwj: pong
<Keybuk> pitti: since the buildds were back on auto?
<iwj> asac: Hi.  See email.
<pitti> Keybuk: dunno, my last dist-upgrade was around 1400 UTC
<Keybuk> do another <g>
<pitti> Keybuk: what's breaking?
<bddebian> pitti: You are running Edgy or do you mean a chroot?
<pitti> bddebian: I run edgy
<bddebian> Wow
<pitti> I have stable chroots and crack of the day main system
<bddebian> heh
<pitti> I wanted to play with gcc 4.1 and ssp, and new glibc :)
<Keybuk> pitti: new udev will cause excitement
<Keybuk> at least, until the new kernel is in
<Keybuk> which will also cause excitement
<pitti> Keybuk: oh, I still have the dapper one
<jbailey> bddebian: I suspect that those of us who play with core infrastrucutre are probably all running edgy already.
<Keybuk> I like you like to live dangerously
<bddebian> Seriously, what are "we" doing for X?  Is the intention to grab 7.1 from Debian when it comes in?
<Keybuk> I have a stable machine on the end of an ssh seession with various chroots
<Keybuk> my laptop I run on the bleeding edgy
<bddebian> jbailey: Well you rock anywayz so.. :-)
<jbailey> My wife's machine runs the current release until somewhat after feature freeze, usually.
<jbailey> The rest of my machines all run current-development plus my testing glibc.
<Keybuk> anyhoo, I'm gonna go crash
<Keybuk> nite all
<ogra> ciao Keybuk 
<ogra> :)
<bluefoxicy> <pitti> I wanted to play with gcc 4.1 and ssp, and new glibc :)
<asac> iwj: what type is state ?
<bluefoxicy> pitti:  did tseng tell you I'm prone to test any silly thing you throw at me, like i.e. fully built SSP bases with position independent executables and experimental hardened kernels and Xorg 7 security policies that force half of the desktop to cease function etc?  :>
<iwj> nsSelectState*, ie not an nsRefPtr.
<pitti> bluefoxicy: :)
<pitti> bluefoxicy: crack away
<iwj> asac: It's new'd, fiddled a bit, then shoved into a hash table with SetStatePropertyAsSupports, but none of these things add a ref.
<bluefoxicy> pitti:  the gentoo guys did a pretty good job of getting me to run severely broken ebuilds on my production desktop :)
<iwj> And then at the end of the function it's unconditionally RELEASE'd.
<asac> iwj thats wrong
<asac> apparently you missed it
<asac> I found another
<iwj> Another similar bug ?
<asac> iwj:  its now: nsRefPtr<nsSelectState> state = new nsSelectState(); 
<asac> iwj: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/content/html/content/src&command=DIFF_FRAMESET&file=nsHTMLSelectElement.cpp&rev1=1.232.2.2.2.1&rev2=1.232.2.2.2.2&root=/cvsroot
<iwj> nsRefPtr> I considered doing that.
<asac> iwj: thats what got checked in on MOZILLA_1_8_0 branch
<asac> iwj: further you removed or kept?? NS_RELEASE(mRestoreState);
<asac> iwj: this should be mRestoreState = nsnull;
<iwj> I have no NS_RELEASE on mRestoreState.
<asac> yes
<asac> you removed it
<asac> but did not add the
<asac> mRestoreState = nsnull;
<asac> iirc
<iwj> That's in the destructor, right ?
<asac> wait a second
<asac> I will look
<iwj> in nsHTMLSelectElement::~nsHTMLSelectElement
<iwj> Oh, no, you mean in nsHTMLSelectElement::DoneAddingChildren
<asac> yes you just removed it
<asac> do you see?
<asac> hunk 1773
<iwj> Yes.
<iwj> RestoreStateTo doesn't always add a reference.  Oh, just a mo, it does.
<iwj> Sorry, I misread that.
<bddebian> BenC: ping?
<iwj> asac: How did you find that cvsweb diff, OOI ?  I mean, the version numbers.  Did you trawl the logs looking for mentions of 324918 ?
<asac> iwj: and remove mRestoreState=nsnull in constructor ... its not needed anymore
<asac> no its easy
<iwj> asac: The patch I was working from was the one from the attachment in the 324918 report, which I had naively assumed was largely correct.
<asac> i searched bonsai for all changes of nsHTMLSelectElement.cpp on MOZILLA_1_8_0_BRANCH
<asac> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_0_BRANCH&branchtype=match&dir=&file=nsHTMLSelectElement.cpp&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
<asac> iwj: I verify ... wait a second
<iwj> The two attachments are the 2006-02-16 and 2006-03-01 ones.
<asac> iwj: yes you are right
<asac> iwj: apparently they really messed it up
<iwj> Hrmf.
<asac> iwj: other patches where quite right though ... so its just an accident I guess
<asac> iwj: take the first patch for nsHTMLSelectElement.cpp too??
<iwj> I'm not sure now whether to throw away the stuff from those attachments and start again with your actual cvs checkin.
<asac> yes
<asac> take both from bonsai
<iwj> 2006-04-21 16:14, you mean ?
<asac> there are two checkins
<asac> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_0_BRANCH&branchtype=match&dir=&file=nsHTMLSelectElement.cpp&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
<asac> they where even on the same day
<asac> first sounds interesting
<asac> Make elements deal better with various evil DOM mutations. Fixes bugs 325730, 330084, and 330925. Patches by me and bz. r/sr=me,bz,jst a=jst
<asac> :)
<iwj> asac: That other patch seems sensible, yes.
<asac> and the second is our real checkin
<neutrinomass> Is it a bad idea to write .desktops that put stuff under System->Administration instead of Applications->System ? Because I've heard that Ubuntu is moving away from the latter ...
<iwj> Right.  I think we want both.
<asac> iwj: but none of the bugs in the checkin are listed in any mfsa
<asac> neither are dependents and blocked bugs
<iwj> Yes, but we already know that they're not 100% at putting security stuff in mfsa's.
<asac> please keep them separated
<asac> maybe the first is part of adifferent, larger checkin we do no yet have
<asac> maybe they forgot to issue an advisory or something
<iwj> That's possible but it looks good in isolation to me.
<asac> look here two then
<asac> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_0_BRANCH&branchtype=match&dir=mozilla%2Fcontent%2Fhtml%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
<iwj> That just shows no other bits of that checkin in that directory.
<asac> hmmm
<asac> there are three bugs in the comment
<iwj> asac: 325730 is definitely security sensitive.
<iwj> I think 330084 probably is but none of the commenters actually say so.
<bluefoxicy> which bugzilla
<iwj> Mozilla.
<asac> iwj: I will clarify if they missed an advisory
<iwj> Right, thanks.
<iwj> I'm going to go off and have dinner now.  Good luck with things and maybe talk to you tomorrow.
<iwj> Thanks a million for your effort.
<asac> iwj: cu
<bluefoxicy> iwj:  sometimes things don't get marked security sensitive by the reporter
<bluefoxicy> I did that with mozilla's /tmp thing, I showed how to find out what another user was looking at by watching files owned by them appear in /tmp and googling the file name
<asac> iwj: if you have the new patch, please send them. I would like to file it as done here in my TODO list :)
<bluefoxicy> (they did tell me to mark it security sensitive, I just didn't)
<bluefoxicy> (I never do{
<asac> bluefoxicy: in this case the bug was security sensitive
<bluefoxicy> asac:  yeah, I'm just saying, sometimes the reporter doesn't mark it that way.
<asac> bluefoxicy: sure.
<bluefoxicy> asac:  I never do because if I ever find anything it's either A) minor; or B) something I'm blogging about 2 minutes after the bug is posted.
<bluefoxicy> asac:  it'd be neat to be able to see all the secret security issues in bugzillas ;)
<bluefoxicy> asac:  For me that's recreational reading
<BenC> bddebian: pong
<bddebian> BenC: It looks like Bug #39315 is closeable.  Could you confirm?
<Ubugtu> Malone bug 39315 in linux-source-2.6.15 "Keyboard random repeat " [High,Fix released]  http://launchpad.net/bugs/39315
<BenC> bddebian: Yes, it is
<JanC> hm, anybody know when vmware-player kernel modules will be updated to work with the new kernel ?
<BenC> that's why it is closed :)
<bluefoxicy> BenC:  oracle is doing things with ubuntu's patches
<bddebian> BenC: No, it's Fix Commited, not released
<ogra> JanC, likely tomorrow
<BenC> bluefoxicy: Yeah, Randy emailed me that he was doing that
<BenC> bddebian:  [High,Fix released] 
<bddebian> BenC: For .17?
<JanC> ogra: thanks, will answer that to the user who asked me that  :)
<BenC> bddebian: It's not released for .17 yet
<BenC> I need to upload .17-2
<bddebian> OK, thanks, sorry to bug ya
<BenC> np
<bddebian> mdz: You around?
<mdz> bddebian: yes
<bddebian> mdz: Do you have any thoughts on bugs against Universe packages on older distros?
<mdz> bddebian: packages which have since been removed, you mean?
<bddebian> mdz: No.  Say bug was filed on foo in Warty or Breezy but was fixed in Dapper.  Close them?
<mdz> bddebian: example?
<bddebian> barring security and crash fixes of course
<bddebian> Bug #1767
<Ubugtu> Malone bug 1767 in gimp-print "Upgrades from gimp-print to to gutenprint" [Medium,Unconfirmed]  http://launchpad.net/bugs/1767
<bddebian> Oh bad one, that's main, hang on
<bddebian> Bug #1669
<Ubugtu> Malone bug 1669 in gxmms "gxmms doesn't display the title of the song in the tooltip" [Medium,Unconfirmed]  http://launchpad.net/bugs/1669
<RQ> Hi, could anyone help me with compiling alsa a bit?
<RQ> i'm getting a bunch of errors while trying to make a deb with 1.0.11
<bddebian> Damn upgrading to Edgy is puking on locales and locale-gen isn't fixing it?? :-(
<RQ> there it is: http://pastebin.com/711459
<BenC> so has hppa been dropped, or is it just not boot-strapped for edgy yet?
<jbailey> BenC: hppa is broken for glibc in some fundamental ways.
<jbailey> (no NPTL)
<jbailey> Carlos has some stuff working, he needs to get another LWS integrated into their kernel.
<jbailey> After that, remember all of the *really* ugly hacks that would never be integrated into LinuxThreads upstream?  All gone.  They'll get in perfectly.
<bddebian> Anyone have a clue what I do about this locale issue when upgrading to Edgy?  http://pastebin.us/489   locale-gen isn't doing it :-(
<bluefoxicy> Ran into a bump on dapper install.
<bluefoxicy> FAT32 partition has a /!\ next to it, umounting it says "no such file or directory"
<bluefoxicy> more importantly
<bluefoxicy> I can't say, "Shrink existing partition"  "C: (guessed)"  "Allocate 3GiB for Ubuntu and autopartition"
<bluefoxicy> I think
<bluefoxicy> if anyone tries to install dapper on a machine with pre-existing Windows
<bluefoxicy> they're going to have to jump through hoops.
<bddebian> If they are installing Windows, what the hell would they need Windows for anymore? ;-)
<bddebian> s/Windows/Dapper/
<mdke> bluefoxicy: check the bug tracker
<bddebian> Later folks
<bluefoxicy> mdke:  this install app is written in python isn't it -.-
<mdke> bluefoxicy: no idea, probably
* bluefoxicy notices it's never really idle.. qemu is doing 80% CPU usage when let alone long enough for the app to settle down.
<mdke> bluefoxicy: the bug tracker
<bluefoxicy> nothing I can see
<bluefoxicy> wtcrap
<bluefoxicy> hda1 isn't mounted
<tseng> bluefoxicy: you really don't need to spam your random thoughts to this channel
<bluefoxicy> tseng:  sorry, trying to figure out htf to tell dapper's installer to resize a vfat partition to make room for ubuntu.  Right now it seems to be "I can't do that," although on Breezy I had the d-i resize WinXP safely.
<bluefoxicy> tseng:  i thought that was supposed to be something it did.. I'll just bug on it when done.
<tseng> ok comeon
<mdke> bluefoxicy: immagine if everyone talked about their bugs in the channel. There are a lot of bugs
<bluefoxicy> mdke:  ok true :)
<mdke> and anyway, the installer maintainer is away
<tseng> mdke: its worse when you blurt out random ideas with no context
<KaiL_> would it be possible to write a (userspace?) tool, which sends everything accessing /dev/dsp to esddsp or aoss..?
<tseng> not that I would prefer him to spell it out, either
<mdke> tseng: :)
<bluefoxicy> tseng has heard me talk far too much in his lifetime
<tseng> i think it is maybe 4 years now?
<tseng> or 5
<KaiL_> ..just to have dmix support also for oss apps
<givre> Hi guys, don't know if it the good canal t ask this, but we need a new vmware-player-kernel-module to match the new kernel.
<givre> Is it plan?
<zul> givre: its in the works
<givre> ok, thanks
#ubuntu-devel 2006-06-16
<zul> infinity: ping
<infinity> zul: pong.
<zul> infinity: i tried to do an dapper-security upload and it guess it failed so Ben uploaded can you confirm my suspisions for me?
<crimsun_> zul: a reject? if so, are you using the correct host?
<zul> yeah i am
<infinity> zul: Let me check quickly.
<infinity> zul: What did you upload?
<zul> vmware-player-kernel
<infinity> Rejected: The key (0x207677DEFA14013B) used to sign vmware-player-kernel-2.6.15_2.6.15.10-7.dsc wasn't found in the keyring(s).
<infinity> Rejected: vmware-player-kernel-2.6.15_2.6.15.10-7.dsc: md5sum check failed.
<zul> ok thats what i thought
<zul> thank you
<infinity> Not sure what's up the the failed md5sum check...
<infinity> I also don't see an accepted upload from Ben.
<infinity> Was it just an upload to bump the ABI?  I can do that for you.
<fabbione> don't sweat about it
<fabbione> we will get mvo to do it and test it before
<fabbione> infinity: let's get d-i first. the vmware player is less urgent (multiverse)
<infinity> I need to do some vmware-player* uploads to dapper-updates anyway.  There are a few bugs to iron out, due to it being rushed so late in the release.
<infinity> fabbione: Yes, very true.
* jdub installs nexenta on vmware.
* fabbione larts jdub 
<fabbione> jdub: i guess they didn't port to sparc yet, but only to i386
<ogra> infinity, seen bug 49900 ?
<Ubugtu> Malone bug 49900 in linux-restricted-modules-2.6.15 "Driver installed in a wrong location" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49900
<infinity> ogra: Rejected.
<ogra> oh, the guy was so enthusiastic :)
<fabbione> even my mommy was enthusiastic when she figured i have been interviewed in an Italian magazine.. that doesn't make her understand what i said in the interview
<ogra> indeed :)
<HrdwrBoB> the main problem in that bug is that he bought a radeon 9000
<LaserJock> heh
<fabbione> HrdwrBoB: the main problem in that bug is that somebody did allow me close to a computer
<bddebian> Heya
<TheMuso> mdz: Requesting approval for the final debdiff in Malone #49780. MOTUs weren't sure as to what version increment this should take, so if it needs changing, I can re-upload with different version. Thanks in advance.
<Ubugtu> Malone bug 49780 in gobby "Gobby crashes upon load when GNOME accessibility options are turned on." [Untriaged,Confirmed]  http://launchpad.net/bugs/49780
<mdz> bddebian: sorry, missed your answer
<bddebian> s'ok, I'm used to it ;-)
<mdz> bddebian: in your example, you've done the right thing (ask for confirmation, close as unreproducible if it isn't received)
<bddebian> After talking with crimsun_ I have just started marking the old bugs as Need Info... Ah, OK, thanks
<mdz> bddebian: I miss things that don't have my name in them
<bddebian> OK, sorry
<mdz> TheMuso: looks fine, go ahead
<mdz> I hope gobby is working better than it was for us in montreal ;-)
<TheMuso> ok thanks.
<ogra> mdz, it should :)
<TheMuso> Well I have been playing with a patched gobby and it seems to be fine now with a11y which is great.
<bddebian> Heya LaserJock
<mako> Burgwork: around?
<jdub> BenC: haha
<jdub> "Obvious sync to upstream-linux git."
<desrt> woh.
<desrt> that's a lot of updates.
<bddebian> Gnight folks
<jsgotangco> good afternoon
<Hobbsee> hey jsgotangco 
<sivang> morning
<G0SUB> sivang: hello :)
<sivang> hi G0SUB , how you bee?
<G0SUB> sivang: pretty bad :( Internet outage for 4 days here 
<G0SUB> sivang: see this ``Punish your M$ devel'' http://www.youtube.com/watch?v=ry7u6JF_B1c
<G0SUB> awefully funny
<pitti> Good morning
<ajmitch> morning pitti 
<fabbione> morning pitti
<Hobbsee> hi pitti 
<pitti> hey Hobbsee 
<pitti> moin ajmitch, hi fabbione 
<crimsun_> 'morning, pitti 
<pitti> hey crimsun_ 
<sivang> morning pitti ,fabbione 
<fabbione> Mr. Sivang
* pitti waves to sivang 
* sivang high fives pi	
<sivang> err
* sivang high fives pitti 
* sivang bows to the god father and asks him how to make people offers they can't refuse :p
<pitti> infinity: 'mktemp' now has a separate package? what happened/will happen to debianutils?
<infinity> pitti: debianutils pre-denends on mktemp.
<infinity> depends, too.
<infinity> mktemp is from a different upstream, so keeping it in debianutils isn't sane.
<pitti> oh, in 2.16
<pitti> G0SUB: ah, you are already here?
<Fjodor> Would there be any sense in making a small init script to run depmod -ae on system startup? It doesn't seem to be run on installing own builds of e.g. nvidia-kernel...
<Fjodor> Running it at boot is done in LFS, dunno about others, hence the idea
<infinity> Fjodor: We don't run it on boot intentionally.
<infinity> Fjodor: It should be run when kernels and modules are installed, not at every boot.
<Fjodor> Well, it isn't run on installing own builds of nvidia-kernel from ubuntu sources
<infinity> Can you file a bug for me about that?
<infinity> The nvidia-kernel-source package needs a lot of love. :/
<Fjodor> infinity: Certainly. What is the url again?
<infinity> More bugs would be helpful.
<infinity> https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.15/+filebug
<Fjodor> https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.15/+bug/49955
<Ubugtu> Malone bug 49955 in linux-restricted-modules-2.6.15 "depmod -ae isn't run on user built install" [Untriaged,Unconfirmed]  
<Fjodor> My initial idea of running depmod on boot would help me since I use madwifi-ng, but I can see the idea behind the current practice. Running it with a version argument is just something I have to remember then
<mdke> morning
<pitti> hi md
<pitti> hi mdke 
<siretart> buildds again on manual?
<fabbione> yes
<fabbione> and they will stay that way for a little while
* mdke pokes Znarl 
<pitti> infinity: I assume python-minimal is not available in the buildd chroots?
<infinity> pitti: I would assume it is..
<infinity> Priority: required
<pitti> infinity: but not essential
<infinity> Let me go look to be sure.
<pitti> infinity: it's for the question whether I implement our super-power dh_strip with debug symbol extraction in python or good ol' shell
<pitti> shell should be good enough, though
<infinity> root@sejong:~# dpkg -l python\* | grep ^i
<infinity> ii  python-minimal    2.4.2-0ubuntu3 A minimal subset of the Python language (def
<infinity> ii  python2.4-minimal 2.4.3-0ubuntu4 A minimal subset of the Python language (ver
<pitti> oh, yay
<infinity> apt screams if I try to remove it.  I'm pretty sure "Required" means "required". :)
* pitti remembers bug reports complaining about missing build-deps which were required, but not essential
<pitti> infinity: anyway, thanks
<infinity> Note that libc6 isn't Essential either. :)
<\sh> hmm...autosyncs are started? if so, is there something wrong with auto-changes ml?
<pitti> infinity: that's a dependency :)
<infinity> Shh. :)
<pitti> \sh: oh, are they?
<\sh> pitti: that's the reason I ask ;)
<infinity> pitti: Hrm, I'd read policy the same way you did, actually.
<infinity> pitti: But I never remove Required packages from the chroots.
<infinity> pitti: So, up to you...
<pitti> infinity: right, procps was the case I got a bug report for
<infinity> pitti: Of course, the fact that you said this was a dh_ thing leads to believe it should be in perl anyway. :)
<pitti> infinity: hm, but there was a reason why we didn't implement pkgstriptranslations in perl
<infinity> pitti: Oh, hrm.  Good point.  procps didn't used to be in my chroots, and now it is...
<infinity> pitti: I wonder if something's gone odd here.
<pitti> infinity: AFAIR we did it for packages which did not use debhelper
<infinity> pitti: Yeah, pkgstrip should ideally be in shell, but if you're writing dh_ helpers, they should be in Perl, IMO.
<pitti> infinity: it's a dh_strip wrapper, similar to dpkg-deb
<pitti> infinity: so, if our pkgbinarymangler can depend on debhelper, I don't have a problem with it
<pitti> in fact it would make things much easier
<infinity> Oh, wait, no, procps isn't meant to be there, I'm in dirty chroot.
<infinity> python-minimal is.
<infinity> Package: python-minimal
<infinity> Essential: yes
<pitti> ^ oops, right
<infinity> I missed the Essential flag, cause I was looking at python2.4-minimal
<pitti> infinity: ok, so unless you see a reason to not depend on dehelper in pkgbinarymangler, I'll use Perl
* pitti hopes that the sabdfl isn't listening
<infinity> pitti: Er, I don't think it's a good ideal to have the mangler depend on debhelper, no.
<infinity> pitti: That just pulled in a mess of stuff into every chroot, even for non-dh builds.
<pitti> do we care?
<pitti> for the < 5% non-dh packages?
<infinity> I care, because debhelper gets stuck in bootstrap loops.
<pitti> ah, ok
<infinity> Which are a pain to break when it must be installed all the time.
<pitti> so, python shall it be then, ok?
<infinity> If you'd rather do that than shell, sure. :)
<infinity> I prefer shell, but I'm insane.
<infinity> If you asked jbailey, he'd tell you to do it in make.
<pitti> prolog!
<infinity> If you intend for this to ever be used in Debian, use shell or perl-base.
<infinity> If it's only for us, shell, perl-base, or python-minimal are all fine.
<pitti> ok
<pitti> well, shell should work
<pitti> bit messy, though
<infinity> Yoy really fear perl-base, don't you? :)
<infinity> s/Yoy/You/
<pitti> actually not
<pitti> postgresql-common :)
<infinity> (I find shell quite readable as long as we're not dealing with millions of lines, so I'm fine with that... initramfs-tools, for instance, all makes sense to me and is simple to work with)
<ivoks> pitti: let's backport cups 1.2.1 to dapper and offer it for testing, what do you say?
<pitti> ivoks: I'd remove the ssl cert magic from the current edgy version
<pitti> ivoks: (for dapper-updates)
<ivoks> pitti: and gutenprint 5rc3 solves some lexmark issues
<ivoks> pitti: nod
<pitti> ivoks: and, didn't you tell me about a new ps2ps or so?
<ivoks> pitti: alternate ps2ps :)
<pitti> ivoks: I can easily cherrypick with subversion
<ivoks> pitti: it's been there for a while, but i don't think we need it
<ivoks> pitti: well, if we backport some issues to rc2, would it be ok to put 5.0 (final release) in -updates, once it goes out?
<ivoks> pitti: dapper had some edgy printing technology :)
<pitti> ivoks: depends on the amount of changes
<ivoks> pitti: of course
<ivoks> rc3 had some _major_ changes
<ivoks> pitti: All printers supported by Gutenprint are now listed explicitly 
<ivoks> rather than via the compatibility list. As a result, CUPS PPD 
<ivoks> files and Foomatic are now generated for each supported printer.
<ivoks> ups, sorry... linebreak...
<ivoks> pitti: http://cups.org/newsgroups.php?s1791+gcups.commit+v1797+T0
<ivoks> pitti: there are some bugs fixed in svn, regarind pstops
<pitti> ivoks: that patch is simple enough
<ivoks> pitti: there is one more... i'm trying to find it
<ivoks> pitti: http://cups.org/newsgroups.php?s1771+gcups.commit+v1774+T0
<ivoks> pitti: this solves some backend issues
<ivoks> pitti: this one isn't quite trivial :)
<pygi> pitti, just found bonfire being in ITP
<pitti> ivoks: urgh
<pygi> I am trying to find the guy that submited it
<pitti> ivoks: this is a merge commit, maybe you can find the split-out patches in trunk?
<ivoks> pitti: http://cups.org/newsgroups.php?s1771+gcups.commit+v1773+T0 ? :)
<pitti> ivoks: that patch sounds like 'rewrite the way we handle stuff'
<ivoks> yes
<ivoks> pitti: part II is about serial backend
<ivoks> pitti: bottom line, all backends are affected
<pitti> doesn't sound particularly appealing...
<ivoks> i know
<ivoks> this is why 1.2.2 was started...
<ivoks> we can leave it out
<pitti> ivoks: hm, let's put 1.2.1 into dapper then and wait until 1.2.2 is finished and saw some testing
<ivoks> and package 1.2.2 for edgy, when it comes out
<pitti> ritht
<ivoks> pitti: lol nod
<ivoks> pitti: w or w/o pstops patch?
<pitti> ivoks: that one is fine
<ivoks> ok
<ivoks> pitti: btw, cherrypicking lexmark fixes for ~rc2 gutenprint is hell
<ivoks> pitti: i've tried that, but gave up... :)
<ivoks> btw, vmware-player-kernel needs rebuild :)
<pitti> mvo: do you have some time to fix dapper's vmware-player-kernel for the current dapper-security kernel?
<mvo> pitti: is a rebuild not enough?
<pitti> mvo: well, should, but it could use some testing
<fabbione> mvo: please coordinate with infinity 
<mvo> pitti: sure, lets do it
* pitti hugs mvo
<pitti> mvo: did you read G0SUB's meeting proposal? are you fine with 15:00 CEST?
<mvo> pitti: yes, I replied a couple of minutes ago 
<ivoks> rebuild is fine
<ivoks> i'm using my own rebuild and works ok
<fabbione> pitti, mvo: please coordinate with infinity .. he has other fixes too fo rit
<infinity> mvo: A rebuild for -kernel is fine, the fixes I need to make are in -player.
<mvo> infinity: ok, thanks
<mvo> pitti: I'm on it, I do the testing now
* pitti yays at his first successful run of a package build with super-power-debug-symbol-extract-fu dh_strip
<zul> yay!
<fabbione> sparc iso image is out :)
<fabbione> WWOWOWOOWOWOW
<zul> yay
<fabbione> now.. an announce
<zul> cdimage.ubuntu.com?
<fabbione> releases.ubuntu.com/dapper/
<zul> getting now
<zul> :)
<ogra> pfft, no server-live-sparc images ? thats lame  
* ogra hides
* Mithrandir twaps ogra 
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* ogra was kicked off #ubuntu-devel by fabbione (YOU DESERVED IT)
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<pitti> ogra_: harsh, isn't it? :)
<KaiL_> ..who killed udev for edgy? ;)
<Keybuk> "killed" ?
<KaiL_> doesn't install clean
<fabbione> KaiL_: it will in few hours.. now sit back and relax please
<Keybuk> KaiL_: edit /var/lib/dpkg/info/udev.postinst and change my_per... to mv_per...
<Keybuk> (and get me new glasses :p)
<ogra> *giggle*
<KaiL_> lol
<Keybuk> it won't work after reboot anyway
* fabbione hugs ogra 
* ogra hugs fabbione 
<Keybuk> so I wouldn't hurry too much
* _ion hugs lilypond
<KaiL_> means "don't even thing about rebooting that system"? ;)
<pitti> grrrr @ dpkg-genchanges
<pitti> iwj: do you have a minute?
<pitti> or Keybuk?
<Keybuk> 'sup?
<pitti> Keybuk: I'm currently hacking on a dh_strip wrapper which will automatically create -dbgsym packages (external debug symbols) at build
<pitti> Keybuk: of course they do not appear in debian/control
<Keybuk> is that different to -dbg ?
<pitti> Keybuk: not very, but I did not want to clash with the namespace
<pitti> Keybuk: just as initial test for now
<pitti> Keybuk: i. e. I create a ../cdbstest2-dbgsym_2.3-1_amd64.deb
<Keybuk> right, they won't appear in debian/control
<pitti> Keybuk: which does not appear in d/control
<Keybuk> not unless you add them
<pitti> so, dpkg-genchanges barfs:
<pitti> dpkg-genchanges: error: package cdbstest2-dbgsym amd64 has section utils in control file but raw-debug in files list
<pitti> Keybuk: i. e. it takes the 'default' Section: from the Source stanza
<pitti> Keybuk: instead of actually looking into the .deb
<pitti> Keybuk: would it be possible/wise to modify dpkg-genchanges to not do this?
<Keybuk> I think it would be unwise
<Keybuk> that's a reasonable sanity check
<Keybuk> usually you want it to error if an unexpected deb gets produced
<pitti> Keybuk: that already happens
<pitti> dpkg-genchanges: warning: package cdbstest2-dbgsym listed in files list but not in control info
<pitti> and so on
<pitti> Keybuk: but this particular Section: error makes no sense to me
<Keybuk> *shrug* ask Ian on that one
<pitti> ok, I will
<infinity> pitti: Why are you doing it as a deb anyway?
<pitti> thanks so far
<pitti> infinity: https://wiki.ubuntu.com/AutomatedProblemReports
<infinity> pitti: If it wasn't, then dpkg-genchanges wouldn't care about it at all.
* Keybuk goes back to trying not to screw up edgy :p
<pitti> We will use deb files as container for debug symbols. Compared to flat files, they offer the following advantages:
<pitti>     *
<pitti>       They can be arranged in a proper pool structure with a Packages file etc., so that existing tools to mirror, download, and ship debs can be reused. (However, we will not put them into the regular distribution. They should either live on a separate server (debug.ubuntu.com) or at least in a different suite (like "breezy-debug").
<pitti>     *
<pitti>       Users can actually install them if they want to.
<pitti> infinity: when I wrote that spec, this seemed like a good idea to me
<pitti> infinity: similar to language packs
<infinity> Hrm, yes, the second point makes it make sense to have them be debs.
<pitti> infinity: I wouldn't deny the advantage of easy cd-rom builds, mirroring, etc. either
<infinity> You could work around dpkg-genchanges by tossing all the debug debs for a source package into one big tarball, but that feels icky.
<infinity> (Very icky)
<Keybuk> comm -23 <(comm -23 <(sed -n -e "/^Package:/s/.*: //p" Debian_unstable_main_Sources | sort) <(cat ../ubuntu/dists/edgy/main/source/Sources.gz ../ubuntu/dists/edgy/universe/source/Sources.gz | gunzip -c | sed -n -e "/^Package:/s/.*: //p" | sort)) <(sed -e "s/ *#.*//;/^ *$/d" /srv/launchpad.net/dak/sync-blacklist.txt | sort)
<Keybuk> woohoo!  fear my shell!
<Kinnison> comm?
<infinity> comm == the bomb.
* Keybuk gasps at Kinnison  ...  you don't know about comm?
<pitti> infinity: if I use normal tarballs, then I can still create them per-deb; that seems orthogonal to me
<Keybuk> comm is what people should be using when they use diff and grep out the + or - lines :)
<Kinnison> keybuk: My unix-fu is surprisingly weak in places
<infinity> pitti: No, I was saying you could create foo_debug.deb, libfoo_debug.deb, foo-tools_debug.deb, and put them all in foosrc_debug.tar.gz
<ogra> comm == mom ??
<pitti> infinity: oh
<Kinnison> Keybuk: I see, I'll read the manpage
<infinity> pitti: So the archive can untar it and deal with them in a special way, but the package builds seem them as opaque by-hand crap.
<pitti> infinity: that's a lot of unpacking and repackaging
<Keybuk> Kinnison: don't worry ... I just showed that to another friend, and his comment was "you can cat gzipped files together?!" :p
<pitti> infinity: I'll talk with Ian then; if he thinks modifying dpkg-genchanges is a bad idea, I'll consider this workaround
<infinity> pitti: Well, your other really perverse option is to concatenate your stuff on the end of debian/control on the fly. ;)
<Kinnison> Keybuk: heh
<pitti> infinity: I feared to speak it out
<pitti> infinity: that would even work on the buildds, but would horribly break on local builds
<infinity> Yes, hence why it's wrong.
<infinity> Pretty much non-reversible with a clean.
<infinity> So, a non-option.
<pitti> infinity: yet another 3v1l idea:
<infinity> But the "big by-hand tarball" thing would work fine.
<pitti> infinity: since I already divert dh_strip, I could divert dpkg-genchanges as well, and have it process a temporary debian/control with the -dbgsym stuff added
<pitti> infinity: at least initially for my local testing, until we agree to a better solution
<infinity> Are we going to divert all of dpkg/dpkg-dev in edgy? :)
<pitti> right now it sucks to not be able to continue
<infinity> I've created a monster.
<pitti> infinity: we'll find more :)
<Keybuk> bugger, sync-source can't infer requestor
<infinity> infer it from what?
<Treenaks> Where can I translate (or fix translations of) the localised browser "homepages"?
<infinity> Random guesses?
<Treenaks> The Dutch translation is bad.. and the translations aren't in the ubuntu-artwork package, it seems
<logan77666>  got a queation - on Dapper Drake I have raise_on_click option in gconf for metacity disabled but it still raises my windows - can anyone confirm ?
<mdke> Treenaks: they are in ubuntu-docs. Send me a corrected html file if you want
<pitti> infinity: ok, my private dpkg-genchanges approach worked fine so far :) so I can continue with the actual guts of debug symbols
<thom> logan77666: not the right channel
<Treenaks> mdke: ok, will do
<Keybuk> hmm, where's path_id gone?
<mdke> mdz: would it be ok to upload a new ubuntu-docs for dapper-updates, no changes except for translation updates?
<Keybuk> almost certainly
<Keybuk> \sh: I couldn't find any way of persuading Launchpad to send the sync mails there instead
<Keybuk> and I was tired, so couldn't be bothered anymore :p
<Keybuk> Kinnison: actually, for future reference, how does one do that?
<\sh> Keybuk: no problem
<Keybuk> and there were over 3,000 of them -- it seemed better to just not send then :p
<ogra> Keybuk, hehe, BzrMaintainedPackages shows student-control-panel moved secretly to main :)
* ogra just was about to add it to the universe section ...
<Keybuk> ogra: meh, put it in the right place then
* Keybuk clearly wasn't paying attention
<ogra> it will move to main in edgy ... mdz made it a high prio spec
<Keybuk> ok
<Kinnison> Keybuk: Erm, you can set the changes list on the commandline IIRC
<ogra> btw, could somebody NEW ltsp-manager ?
<Keybuk>   -a ANNOUNCELIST, --announce=ANNOUNCELIST
<Keybuk>                         Override the announcement list with ANNOUNCELIST
<Keybuk> oh yeah
<Keybuk> meh
<\sh> Keybuk: btw, now you are here...the bzr maintainer howto, did I understand it correctly, that I only need to push an ssh pubkey to launchpad and I can publish via bzr to launchpad?
<Keybuk> you need to register your ssh public key in Launchpad, not "push" it :)
<Keybuk> but yes
<G0SUB> pitti: 13:00 UTC now :)
<pitti> oh, indeed
<pitti> G0SUB: hello!
<G0SUB> pitti: #synaptic :)
<\sh> Keybuk: cool..thx
<Keybuk> \sh: https://launchpad.net/people/shermann/+editsshkeys
<pitti> G0SUB: noone there
<G0SUB> pitti: strange, mvo & me are already talking
<G0SUB> pitti: we saw you come in
<ogra> wheee, a small openoffice replacement !
<ogra> http://www.faber-castell.de/docs/index-news.asp?id=14507&sp=E&m1=10329&m2=20551&m3=24486&m4=14507&m5=&domid=1010
<_ion> ogra: Vim + LaTeXsuite? :-)
<ogra> _ion, see the link :)
<ogra> sasdly it doesnt integrate well with latex
<_ion> It's still loading.
<ogra> (they even point it out in the drawbacks section ;) )
* _ion hopes someone makes an "easy" word processor that does _not_ allow the user to modify text style arbitrarily, but instead forces the user to choose semantic properties for blocks of text (level 1 header, body text, quote etc.) and then let the user modify the style for them. (Reference: CSS)
<HiddenWolf> _ion: amen
<hunger> _ion: IIRC that is called TeX.
<hunger> _ion: Even though the "easy" part of TeX is debateable:-)
<_ion> hunger: IIRC i said "easy". :-) The grandmother isn't going to use TeX.
<_ion> s/The/The hypothetical/
<_ion> Personally i use and love TeX.
<ogra> the grandmother is more likely to use the above i linked ;)
<hunger> _ion: TeX was written for a secretary... so it was supposed to be easy... and I actually think it is. Maybe a stripped down  LyX or something would be better for your hypothetical grandmother:-)
<_ion> Ok, the page loaded. Hehe, funny.
<ogra> YAY
<ogra> Keybuk, THANKS !
<bddebian> Heya folks
<Keybuk> no worries
<ivoks> pitti: so, 1.2.1 for dapper will have ssl support or not?
<pitti> ivoks: yes, it's a simple matter of creating /etc/cups/ssl
<ivoks> pitti: i'm not sure that's enough
<ivoks> pitti: iirc, there was something missing in configure
<pitti> ivoks: WFM here
<pitti> ivoks: it's already built with gnutls and everything
<ivoks> ok then
<ivoks> pitti: i was just looking at diff beetwen 09_runasuser_autoconf.dpatch
<ivoks> pitti: 1.20 doesn't have LIBGNUTLS, ans 1.21 has :)
<pitti> ivoks: oh, hm, I did the tests with 1.2.1
<kagou> hi
<pitti> ivoks: but since we want this version anyway, I don't see a problem
<pitti> hi kagou 
<ivoks> ah, right :)
<ivoks> sorry, i had wine for lunch :)
<\sh> Mithrandir / fabbione / infinity: Congratulations for Ubuntu Sparc :) 
<iwj> `The configuration of this system is obtuse, even by djb-style standards' ROTFL  (https://wiki.ubuntu.com/ReplacementInit of runit)
<mvo> iwj: do you think your automaticTesting work (xen
<mvo> iwj: do you think your automaticTesting work (xen+lvm) can be re-used for the distupgradetesting as well?
<iwj> mvo: Yes, the Xen parts of it (which are the least well-developed but which I really want to work on in Edgy).
<Keybuk> iwj: I was feeling charitable :p
<zul> iwj: i was going to try to get the kenerl patches in edgy's kernel this weekend
<iwj> zul: Cool.
<iwj> How are they ?  When I installed Xen here it was still a case of needing a particular kernel version and ramming it all together.
<iwj> SudoAdminAtspi> `[name-deleted-to-protect-the-guilty] : just an idea, try executing xhost + as user before starting the admin tool'   Wow, it's like it's 1989 again.
<Keybuk> iwj: btw I do somewhat agree with your comment that daemons should give the option to stay in the foreground, etc.
<Keybuk> but when they don't, there is usually a way (pid file, or just executable name) to know which pid file to look for
<Keybuk> so there is definitely an advantage to being pid#1
<iwj> Yes, but also a disadvantage in that you can't transition so easily.
<Keybuk> transition?
<iwj> You have to reimplement all of the init stuff before you get anywhere.
<iwj> And your reimplementation might not be quite right at first, etc.
<Keybuk> init is easy to reimplement, it's probably the smallest process in the known universe
<iwj> Heh.  Weird shit with signal handlers and fds and process groups and ...
<iwj> Anyway, I'm not sure I have a clear opinion yet but I think we should argue it out in Paris.
<Keybuk> indeed
<Keybuk> when do you get there, btw?
<iwj> Recently I've invented a few daemons which need controlling ttys and they turn out to be really really convenient despite having to run them with screen -x tty31 out of init in a barking kind of way.
<HiddenWolf> keybuk is just looking forward to making edgy unbootable. ;)
<iwj> I'll be at the hotel for dinner on Sunday; I'm spending the weekend in Paris with Clare (Boothy).
<Keybuk> ah, fair enough; jbailey was looking for people this weekend -- he flew in early
<iwj> In fact, I should stop faffing with specs soon and start packing.
<Keybuk> heh, initNG scares the shit out of me ... I made a mistake and read its code
<lifeless> has the bleeding stopped ?
<Keybuk> yes, but I'm on the bleeding edgy now
<ogra> haha
<Hobbsee> haha...hope you fix it soon Keybuk :P
<thom> poor pun #3397
<Hobbsee> bit hard to develop if it wont boot
<Keybuk> thom: it actually started off as a typo, but I kept it
<Keybuk> it's slightly hard to type "edge" at the moment
<_ion> hobbsee: Use a chroot. :-)
<pitti> Keybuk: autofingers already? after just a week? :)
<Keybuk> pitti: I've been replying "edgy" to things for months!
<Hobbsee> _ion: could do that :P
<Hobbsee> _ion: in fact, i did that for breezy
<Hobbsee> er, dapper
<Hobbsee> whatever is the current stable
<_ion> "How are you?"  "Edgy."
<iwj> Keybuk: code is complicated, or code is bad ?
<_ion> "What's for dinner?"  "Edgy."
<iwj> Time to pack, definitely.
<Keybuk> iwj: *bad*
<doko> you're leaving today?
<Keybuk> like "check the end of the buffer?  nah"
<Keybuk> "check the file we've been asked to dlopen?  nah"
* pitti smells keybukinit in pure python
<Keybuk> PYTHON IS LOVE
<Keybuk> we needed python in / anyway
<Keybuk> actually, did you see that the FCNewInit _is_ written in Python?
<Keybuk> and is fully dbus compliant
<pitti> Keybuk: that wasn't meant sarcastic :) in fact, it's why we put p-minimal into essential
<Keybuk> (everything is a dbus service)
<iwj> doko: Yes, I'm having the weekend in Paris.
<pitti> iwj: enjoy, and have a good trip
<doko> iwj: enjoy!
<Keybuk> pitti: yes, but you forgot to put it on the root filesystem <g>
<pitti> Keybuk: dbus> that's a little more scary
<pitti> Keybuk: oh, true
<Keybuk> it's not called keybukinit anyway
<Keybuk> I thought of a much cooler name
<Keybuk> and it begins with "u" too :)
<doko> Keybuk: we can change that ...
<pitti> Keybuk: uberinit?
<Keybuk> no, but that's cool :p
<ivoks> it's called u
<ivoks> :)
<jdub> yay, i have flights that won't leave me stranded in europe for a month!
<Keybuk> this does nothing for my nih reputation though :-/
<Keybuk> which is ironic, because I really really did look at everything in an attempt not to
<thom> Keybuk: sure sure
<mdke> jdub: that would be bad?
<Keybuk> jdub: bah; what's wrong with Europe?
<Keybuk> I'm sure silbs would LOVE to have you at the London office every day
<Seveas> who to poke for sparc bugs?
<jsgotangco> hi!
<Keybuk> fabbione 
<Seveas> ok, will subscribe him to the bugs 
<fabbione> Keybuk: no.. -> distro
<fabbione> Keybuk: for server software
<fabbione> for non-server -> me
<Keybuk> fabbione: do we have a sparc porting box in the DC? :)
<fabbione> Keybuk: yes, 3
<fabbione> + 3 buildd
<Keybuk> ooh, what hostnames?
<fabbione> Keybuk: see the machine list.. faure
<Seveas> fabbione, bug 49994, who to subscribe to that one?
<Ubugtu> Malone bug 49994 in Ubuntu "Ubuntu 6.06 LTS Sparc Installation Fails with Illegal Instruction on Sun Blade 100" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49994
<Keybuk> cute
<fabbione> Keybuk: the other 2 will be available once i am done on monday
<jdub> Keybuk: it would actually be quite good to spend some time at the office, but i can't just do it on a whim
<Keybuk> jdub: even a whim of Qantas? :)
<jdub> Keybuk: thai / air france this time
<fabbione> Seveas: it depends..
<zul> thai airways is good
<Keybuk> ah, thai ... the airline where you really _can't_ tell the sex of the air stewards
<jdub> yeah, which is nice
<jsgotangco> lol
<jsgotangco> jdub: are you still in au?
<jdub> jsgotangco: yeah
<Keybuk> no, seriously, I know a guygirl who's a thai air steward
<Keybuk> or stewardess
<fabbione> Seveas: that machine is known to work with netboot.. it has been tested and there is already a bug for silo for that
<zul> Keybuk: i think the term is stewardperson
<jsgotangco> jdub: i'm flying 10 hours from now
<seb128> Keybuk: have you planned to look on the dapper-updates waiting packages today? :)
<jdub> jsgotangco: oh rad, will be good to see you :)
<Seveas> fabbione, thanks, will try and find that bug and tell the user
<rpedro> hello
<fabbione> Seveas: bug #40119
<Ubugtu> Malone bug 40119 in silo "SPARC boot failed: Illegal Instruction" [Medium,Confirmed]  http://launchpad.net/bugs/40119
<Keybuk> seb128: nope
<seb128> Keybuk: ok
<Keybuk> seb128: should I?
<rpedro> just had the strangest crash/kernel panic while using nautilus
<fabbione> Seveas: the difference between i386 and sparc is that the BIOS (OBP) on sparc either works or doesn't. There is no gray area like broken acpi...
<Keybuk> seb128: I'm doing Debian new sources at the moment; will look into it afterwards
<seb128> Keybuk: up to you, the new gdm uploaded some days ago by dholbach has a regression fixed by the new gdm waiting but no hurry
<rpedro> I had just finished rebooting after updating kernel etc in dapper, and was using firefox
<Seveas> fabbione, sounds like fun
<Keybuk> seb128: accepted
<seb128> Keybuk: thank you
<fabbione> Seveas: you want to start teaching people to ask for OBP verrsions and prtconf -p -v output on sparc
<rpedro> and then when i called nautilus and started using it, when opening a folder the screen just froze for a second, then went blank
<fabbione> Seveas: that's more or less the equivalent of lspci and dmidecode :)
<Seveas> will do some magic in blousey
<HiddenWolf> rpedro: please file a bug, it is noise here that is impossible to respond correctly to.
<Seveas> hope it gets in the archive soon 
<Keybuk> ooops
<rpedro> HiddenWolf: I just wanted to know what files I need to see to figure out what happened to cause the crash
<rpedro> HiddenWolf: then I can file a bug if something turns up, and I also goinng to see if it's reproduceable
<HiddenWolf> rpedro: best see in #ubuntu-bugs, I think.
<rpedro> HiddenWolf: ok thx
<bgertzfield> Grumble, grumble...
<pitti> Keybuk: can you please NEW vmware-player-kernel-modules-2.6.15 in dapper-security?
<fabbione> pitti: are they already out of jackass?
<phanatic> mdz: ping
<pitti> fabbione: yes
<pitti> fabbione: I just got the LP archive upload mail with the NEW messages
<Keybuk> pitti: I only see two architectures
<Keybuk> is that normal?
<pitti> yes
<pitti> i386 and amd64
<Keybuk> ok
<Keybuk> NEW'd
<highvoltage> jdub: ubuntu planet seems to be showing very old posts
<jdub> ploum spammed it
<fabbione> jdub: !
<jsgotangco> planet ploum heh
<highvoltage> just blame it on ploum :)
* mdke wonders whether the past tense of "spam" is "spome"
<jdub> i deleted the cache file, so it'll be gone on next update
<jsgotangco> jdub: how long is your flight?
<Hobbsee> hehe.  i liked that spam thing :P
<jdub> jsgotangco: 9:25 and 12:00
<jsgotangco> 17 hours?
<jdub> (the planet conspires against me)
<Keybuk> only 2 and a half hours?
<Keybuk> you guys complain over nothing! :D
<jdub> at least i'll have the mental satisfaction of being in a proper tomorrow when i get there
<jdub> unlike going to the USA
<Keybuk> actually, how _do_ those times work?
<Keybuk> I can't figure out the math
<Keybuk> you leave at 0925 Sydney (0825 Paris) and arrive at 1200 Paris the next day?
<Keybuk> uh, 0125 Paris
<fabbione> Keybuk: 9:25 h to Singapore -> 12:00 to Paris
<Keybuk> ahhh
<Keybuk> duh
<fabbione> it's 21:25 minutes of flight at least
<Keybuk> that's why the math doesn't work :p
<fabbione> + 30 minutes stop in Singapore
<fabbione> ehehe
<jsgotangco> hehehe
* jdub smacks Keybuk 
<jdub> see, he's having trouble
<jdub> because he's thinking in parallel
<fabbione> add one hour to checkin in .au
<fabbione> and 4 hours to get out of CDG
<jdub> Keybuk: i told you not to muck with those kiddieinit systems!
<jsgotangco> 4 hours???
<jdub> fabbione: an hour in bangkok
<Keybuk> I have some baht you could spend
<Keybuk> 200 baht, I think
<Keybuk> so about 20 UK pence ... or 80 AU$ :p
<jdub> i have some too, luckily ;)
<highvoltage> 20 uk pence = 80 UA$ !?
<fabbione> jdub: have fun..
<fabbione> i am off for the weekend
<Keybuk> highvoltage: given the amount of complaining they do about the prices, it must be
<pitti> fabbione: enjoy the weekend
<highvoltage> fabbione: enjoy
<highvoltage> Keybuk: heh
<fabbione> thanks guys
<zul> c ya fabbione 
<Keybuk> it's like to translate any currency into Norwegian Kroner, always raise by a power of 2
<jdub> i spend at least 100 pounds on sushi last time i was at the office
<ogra> TheMuso, did you ping pkern about your gobby fixes ? he'll likely be intrested
<jdub> i could've fed myself and most of my apartment building for a month on that
<Keybuk> jdub: where you buying entire whales?
* Kinnison can easily spend a tenner at Itsu
<mdke> jdub: it's kept at a high price to persuade more decent people to buy fish and chips
<Keybuk> I've yet to find a fish and chips shop within a mile of the London office :-/
<mdke> sushi is low in the essential oils that you can only get from fish and chips
<Keybuk> I did find a *GREAT* noodle shop down in Chelsea though
<highvoltage> Keybuk: i regret that i didn't get some authentic fish & chips when i were in london :(
<hunger> highvoltage: fish and chips is severly overrated.
<jdub> Keybuk: itsu.
<Hobbsee> hunger: never!
<jsgotangco> fugu
<mdke> yeah, it's not overrated
<hunger> highvoltage: I went to a really good place in london (according to the locals) and it still wasn't something I need to eat again.
<ogra> hunger, because you are german
<hunger> ogra: What does that have to do with it? My tastebuds were killed over sauerkraut and schweinshaxe?
<ogra> yeah :)
<hunger> Bye, have to run...
<highvoltage> hunger: i like cape town fish and chips, and londonners say theirs are better, while capetonians say that cape town fish and chips are better. so it's a bit controversial, hence the reason why i want to see for myself :)
<hunger> ogra: sauerkraut and schweinshaxe is way more overrated than fish and chips by the way.
<hunger> See you around.
<ogra> hunger, ich weiss ;)
<jdub> Keybuk, lifeless: try feeling lucky for "hoverbook" :-)
<jsgotangco> oxford heh
<lifeless> jdub: awesome. Boy am I glad I have been dieting...
<jdub> lifeless: :-)
<jdub> lifeless: satisfying to see old pictures
<lifeless> getting to be
<jdub> all you need now is a haircut and you'll be HAWT
* jdub runs!
<bddebian> heh
<lifeless> jdub: 10kg to go..
<lifeless> jdub: THEN I think about a haircut
<sladen> lifeless: I think a haircut would only make a few hundred grammes difference.  (Unless it was *really* greasy).
<lifeless> sladen: lol.
<lifeless> sladen: for my hair now, not even that
* mvo is away for a bit
<doko> Keybuk: is there a blacklist for package, which we do not want to sync?
<Keybuk> yes
<Keybuk> ish
<doko> Keybuk: how do I add something to it?
<Keybuk> tell me
<doko> python2.3-doc, python2.4-doc
<doko> must go in unstable to non-free (b-d on latex2html), but has in edgy the preprocessed docs included
<Keybuk> you know we don't sync from non-free right?
<doko> hmm, ok, fine :-)
<doko> but maybe we should for some ... bison-doc, and all the GFDL -doc packages
<Keybuk> we can do if you like
<Keybuk> so the reason to not sync python*-doc is we put more in our packages?
<Keybuk> Source: python2.4
<Keybuk> uh, dude
<Keybuk> you know we sync _SOURCES_ right? :p
<Keybuk> oh, those are new sources
<Keybuk> ignore me
<Keybuk> la la la
<ogra> heh
<doko> Keybuk: ...
<doko> Keybuk: right, the preprocessed docs are included in the dapper package
<Keybuk> I need to ask the X SWAT TEAM what to do about these X syncs
<Keybuk> fabbione: are you there?
<fabbione> Keybuk: no. ask infinity in Paris directly. He has plans. i am not on X for all of edgy.
<ogra> Keybuk, didnt he refuse to touch it in edgy ? 
<fabbione> no as i am not here
<fabbione> personally edgy can be on framebuffer-gl
<ogra> heh
<highvoltage> there is such a thing!?
<fabbione> highvoltage: dunno... do i sound like one that cares? :)
<highvoltage> heh :)
<mdz> mdke: an ubuntu-docs upload with translation updates is perfectly ok for dapper-updates
<mdz> Keybuk: does that missing path_id business mean that my system isn't bootable now?
<ogra> ha !
* ogra did his first push to the supermirror
<Keybuk> mdz: were you using /dev/disk/by-path for anything?
<mdz> Keybuk: nope
<Keybuk> then, no
<mdz> nothing uses it by default, right?
<mdz> ok
<Keybuk> right
<LaserJock> ogra: \o/
<ogra> :)
<sladen> mdke: what happened to the Laptop Testing Template.  It appears to have no history anymore.  Did it get deleted?
<sladen> mdke: (the same happened at the Montreal conference)
<jjesse> sladen: there was some discusion on #ubuntu-doc about it, somehow it got all messed up?
<sladen> 00
<sladen> oops
<mdz> is anyone working on the intltool-debian merge to unblock The World?
<Keybuk> I think everybody's asleep
<dieman> im not sleeping
<dieman> but im without power
<ivoks> ok, i did some work on redhat's GUI printer managment tool
<ivoks> if anyone is interested...
<ivoks> (in screenshots :)
<Gloubiboulga> ivoks, does it depend on GNOME libs?
<ivoks> Gloubiboulga: it's python
<ivoks> so, pygtk :)
<Gloubiboulga> cool, we need a tool like this in Xubuntu :)
<ivoks> Gloubiboulga: we need it in ubuntu too :)
<ivoks> Gloubiboulga: http://www.grad.hr/~ivoks/ubuntu/g-c-m-replace/
<ivoks> Gloubiboulga: don't be harsh to UI, it needs some love :)
<ogra> a lot :)
<ivoks> :)
<ogra> i wouldnt give it to my mom as is :)
<_ion> Looks promising.
<Gloubiboulga> I agree with _ion :)
<_ion> Albeit written in python. ;-)
<ivoks> that's it for today
<ivoks> maybe i'll create some packages by the end of the week
<ivoks> see you
<\sh> can someone explain, why an initial release just hit dapper-updates? (multiverse)?
<\sh> speaking of desktop-multiplier
<LaserJock> because it didn't make it in before release
<bluefoxicy> somebody uploaded one?  (I was going to ask the same wtf? about dapper-updates, some of the language-pack-* changelogs say "initial release")
<\sh> ugh
<_ion> bluefoxicy: I think the language-pack-* changelogs have said "initial release" for each new release since day -42.
<bluefoxicy> I know :P
<LaserJock> langpacks are being updated once a month, as I understand it
<\sh> well, it scared me ;)
<bluefoxicy> I know, what else did we get today, a whole new Gnome release?
<\sh> bluefoxicy: that was planned
<bluefoxicy> the version numbers on some of these things scare me more though
<bluefoxicy> one of them was like 1:1.2.8.is.2.7.0
<LaserJock> desktop-multiplier was supposed to go in before release but it couldn't get reviewed in time
<bluefoxicy> I guess that's oneo f the nuances of debian package management
<bluefoxicy> Gentoo had this lovely system to deal with that
<\sh> LaserJock: wouldn't it be better, to push those things as dapper-backports? (ok, it's in multiverse...so likley not installed by the masses ;))
<bluefoxicy> if a version of a package suddenly was gone, or marked unstable ("we figured out this breaks stuff, you shouldn't use it")
<bluefoxicy> then portage would try to "upgrade" to the next lower version, if there were no stable marked higher versions :>
<LaserJock> \sh: perhaps, it wasn't exactly up to me though ;-)
<bluefoxicy> apt-get just flat refuses to downgrade
<bluefoxicy> "repo has 0.1 but I have 0.1.1, so 0.1.1 I'll call 'local or obsolete' and make you uninstall it before upgrading to the repo one"
<bluefoxicy> but anyway, enough of this.
<mdke> sladen: I moved it
<\sh> ok..now where is my phone..I'm hungry
<ogra> dont eat phones
<mdke> sladen: if you want a template to appear in the "template" column when you create a new page, it has to be named "BlahTemplate", so I moved it there, and made the old page a redirect
<ogra> they are to heavy for your stomach
<ogra> and may have sharp edges
<\sh> ogra: right, but it's good for phoning a pizza taxi
<ogra> :)
<sladen> mdke: yes, and if you look at that page, you'll see it's not a Template.  Which is the reason that the name doesn't end in "Template" but in "/Template"
<mdke> sladen: right. However, many people get confused because when they click on the laptop testing template, they don't get one
<mdke> sladen: so I decided it would be better to provide a template
<sladen> mdke: I did originally make it a Template about a year ago;  but then that page got deleted and elmo/heno weren't able to get the backup of that Template back;  so we reverted to the out-of-date non-Template version
<mdke> sladen: now there is a template, and it looks like someone has updated it
<sladen> mdke: Rename ; Edit  will do that without blowing away the revision history
<mdke> sladen: sorry, can you explain what you mean?
<mdke> I didn't rename anything. I simply edited the two pages
<HiddenWolf> mdke: do you have any idea when documentation will move to the new wiki?
<sladen> mdke: it would be handy to have the revision history for pages when changes happen;  rather than deleteing and loosing the meta-data
<mdke> sladen: dude. I didn't delete anything, I edited the two pages. Don't dump on me for the wiki software
<mdke> HiddenWolf: it's waiting on the admins
<sladen> mdke: if it's just edits;  what caused the history to disappear.  Do you know if moinmion was updated?
<sladen> HiddenWolf: "new wiki"?  Wiki take #5 is this?
<HiddenWolf> sladen: I was referring to moving docs to help.ubuntu.com
<mdke> sladen: it wasn't updated. And the revision history is still there, now that I've just looked
<mdke> sladen: https://wiki.ubuntu.com/LaptopTestingTeam/Template?action=info and https://wiki.ubuntu.com/LaptopTestingTeamTemplate?action=info
<sladen> mdke: the revision history had approximately 100+ edits...
<mdke> sladen: well, as you can see, my edits did not change the revision history
<mdke> probably someone renamed the page or something a few revisions back
<mdke> I'm not clear on why you dumped that on me, to be honest
<mdke> Treenaks: any luck with that translation?
<sladen> mdke: you are da man for things related to the wiki and generally have a hold on the situation
<sladen> mdke: (as well as being the last person to edit both pages)
<mdke> sladen: ah, i see. I misunderstood then: I thought you were suggesting that my edits had nuked the revision history.
<mdke> no probs
<mdke> sladen: btw, I have an idea, hang on a tic
<ogra> Keybuk, is your mom spamming my inbox ? 
<ogra> or is that actually you ? 
<jpatrick> ogra: both
<ogra> oh, no, its all NEW stuff i see ...
<\sh> I want to see MoM too ;)
<Keybuk> hmm, is queue ignoreing my -A ?
<\sh> ok..changing places...brb
<Keybuk> grr
* Keybuk kills it and uses -M instead
<mdke> sladen: have a look at https://wiki.ubuntu.com/LaptopTesting?action=show and see what you think of that idea
<Keybuk> those were _supposed_ to go to the autosync list
<sladen> mdke: oooh.  groovy.
<sladen> mdke: does that automatically take them to the page if it exists already?
<mdke> sladen: yeah, it will open it for editing whether it exists or not, I think
<mdke> sladen: oh shit, actually it will give them a new template. Lemme rethink that...
* ogra wonders why iwj included the gpl in the changelog of chiark-tcl
<\sh> re
<_ion> ogra: Perhaps the changelog itself is licensed under GPL. ;-)
<ogra> heh
<Keybuk> if iwj did it, he probably had a very good reason
<Keybuk> mdz: bah, you did intltool-debian?
<\sh> oh wow...edgy is really open for business ;)
<sladen> mdke: could it be a custom Function, eg.  NewPageFromTemplateIfDoesntExist()
<mdke> sladen: probably there is a way to fix the macro yeah, maybe there is a newer version around that is a bit cleverer, I will look
<mdke> sladen: yeah, there is a patch. I'll poke henrik
<Symmetria> hrm, lo all
<Symmetria> question for the developers, anyone here hit major bugs with 2.6.16? I think there is a major memory leak in the networking code
<crimsun_> specifically 2.6.16 from upstream (kernel.org)? The majority of the network code is from .15
<Symmetria> crimsun_, I aint tested back with .15, Im trying to figure out when the code changed so I can roll back to that kernel if the support for the stuff I need exists in the old kernels
<Symmetria> but very basically: http://pastebin.com/711927
<Symmetria> if you adjust your tcp window sizes, and push heavy traffic (200mbit+) 
<Symmetria> especially on tg3 and e1000 gig nics 
<Symmetria> you're gonna hit major problems
<Symmetria> I aint tested on other gig nics, but I know on that specific hardware it dies
<Symmetria> and the patch that I did test off the net didnt fix the problem at all
<crimsun_> Symmetria: better addressed in #ubuntu-kernel
<Symmetria> crimsun thanks, was looking for a channel I could address it in
<jbailey> mdz: Hey - did you get any further than underscores burning a hole in your retina?
<jbailey> mdz: I just want to check before I dive in.
<mdz> jbailey: no, sorry.  I got caught up in other things
<jbailey> mdz: All good, thanks!
<mdke> damn, I miss the old days where it was possible to raise severity of your own bug
<LaserJock> mdke: you just need to become a core-dev and you wouldn't have to worry about it ;-)
<mdke> LaserJock: good plan.
<bradb> mdke: i was just talking to jbailey about bug anger meters. i need one too: https://launchpad.net/bugs/50039
<Ubugtu> Malone bug 50039 in kmail "[Data Loss]  KMail mysteriously changes messages to "No Subject", "Unknown" sender" [Untriaged,Unconfirmed]  
<mdke> bradb: I don't think a bug in kmail can be anything more than "wishlist"
<mdke> bradb: but surely being the author of the bug tracking system you can find some loophole to get access to the importance
<jbailey> mdke: Err.  Dataloss is a pretty serious event, whether we're lkely to care about it or not.
<mdke> ah didn't read that. Joke was in poor taste then
<mdke> sorry bradb 
<mdz> mdke,LaserJock: no, you need to join the QA team
<bradb> mdke: no worries :)
<bradb> mdke: just curious: what are your reasons for wanting to change the severity of bugs you report?
<mdke> bradb: regression since release
<mdke> seems to be quite common
<hunger> mdke: How about regressions between releases?
<mdke> hunger: that isn't my case
<mdke> mdz: I can't join the team just to triage my own bugs, and I'm unlikely to find time to triage too many other people's, except for ubuntu-docs bugs
<mdz> mdke: you should be able to triage ubuntu-docs bugs; is that not working?
<mdke> mdz: actually, I haven't checked. If I can, even less justification
<mdke> mdz: no, I can't.
<mdz> mdke: bradb ^^^
<mdke> these are ubuntu-docs bugs in the distro I'm talking about though
<mdke> not upstream ones
<mdz> right
<mdz> but you're a bug contact for the ubuntu-docs source package
<mdz> so you should be able to triage the bugs
<mdke> right, ok.
<mdke> well, sounds like I should file a bug
* mdke grins
<bradb> mdz: the Importance perms consider only distro.bugcontact currently, not package bug contacts. if package contacts could edit them, then effectively anyone can edit importance.
<bradb> of course, if that doesn't bother you, i more than happy to change it
<mdz> bradb: package bug contacts should be able to change importance for bugs on their packages
<mdz> (and yes, I realize they could move the bug to a different package, but I'm really not concerned)
<bradb> or they could just become a package contact for that package and change the importance
<mdz> bradb: do you have a better proposal?
<mdz> the idea of restricting importance is to prevent people from frivolously changing it; I think it's OK if it isn't airtight
<mdz> but I'll think about it a bit
<mdz> mdke: how many other people do you expect are in the same position?
<bradb> mdz: i don't have a better proposal, i'm just pointing out the side effects so you're aware of them
<mdz> bradb: how about the Maintainer and Creator?
<mdke> mdz: you mean people who take an active interest in specific packages without uploading them, and don't have time for general triaging? Probably not many - I would have thought joining ubuntu-qa is a reasonable solution
<mdz> mdke is both of those for ubuntu-docs
<mdz> I have no idea where Creator comes from
<mdz> but surely the maintainer should be able to triage bugs?
<mdke> me neither, I think both those fields change on a regular basis
<ogra> there is a bug open about it
* mdke chuckles
<ogra> should be renamed to "uploader"
* bradb thought the Maintainer field wasn't very useful, for those reasons
<ogra> yes, but Creator is a very confusing naming scheme
<Keybuk> we should drop the Maintainer: field from all packages in the ubuntu archive
<ogra> that too
<johanbr> Hi. I have some wishes/thoughts/ideas regarding PAM, but I couldn't find an appropriate spec or wiki page and I'm not sure that my ideas are coherent enough to merit a page of their own. What do you suggest?
<TheMuso> ogra: I will now that the changes have been published.
<ogra> great :)
<tseng> BenC: woo regparm!
<tseng> BenC: i can use dell openmanage now
<tseng> BenC: thanks
<Keybuk> gnargh, I hate how much setting up X-Chat takes
<Keybuk> better
<NickGarvey> gaim and me get along pretty well..
<ogra> just copy your old config over
* ogra is still using his warty xchat config
<Keybuk> ogra: I like to at least be vaguely aware of any new useful defaults
<jdub> Keybuk: tried xchat-gnome? like / don't like? i haven't tried it for a while, probably should.
<Keybuk> jdub: tried briefly enough to not like it
<ogra> jdub, can i put the userlist on the right side finally ? 
<jdub> i dunno
<jdub> i don't use it
<Keybuk> jdub: nope, still don't like it
<Chipzz> Keybuk: I know why I'm using irssi ;)
<Keybuk> jdub: I actually use X-Chat because it reminds me of AmIRC
<_ion> Ah, good ol' AmIRC.
<Keybuk> ya know, it's _really_ bad that I have to use "xlogo" as part of my "setup a new desktop" procedure
* Keybuk blames havoc
<Chipzz> Keybuk: xlogo??
<Keybuk> yes
<Keybuk> Mr Havoc Pennington decided that window managers don't need to tell you how large a window is while you resize it
<Chipzz> c'est quoi? :)
<Keybuk> so the only way I can get firefox to be 800x600 is to fireup xlogo -geometry 800x600 and measure firefox over the top of it
<Keybuk> :p
<Chipzz> lol :)
<_ion> :-D
<ogra> Keybuk, doesnz devilspie add such a feature ? 
<Chipzz> why use 800x600 anyway?
<tseng> Keybuk: or start firefox with -geometry
<tseng> Chipzz: uh
<ogra> *doesnt
<jdub> Keybuk: "sick"
<Keybuk> tseng: but then firefox doesn't remember it!
<tseng> Chipzz: to judge pages on lower resolution?
<Keybuk> Chipzz: because then the browser feels a nice size on the screen
<Chipzz> tseng: I've used 800x600 for a long time, but even I moved off it
<_ion> keybuk: Sounds like a bug.
<Chipzz> it's just not in common use anymore
<tseng> Chipzz: not the guy in the cube across from me
<tseng> whatever, way ot
<Chipzz> idd
#ubuntu-devel 2006-06-17
<ploum> good night everyone
<ploum> I'm sorry for the planet flood...
<Anarchy> can someone point me to the documentation you all used for reversing the key press on laptop with vol up/down keys ... I know these keys are not handled by acpi 
<Keybuk> Keyboard Shortcut references in GNOME
<Anarchy> After clearing out the Gnome key config and running xev, I have discovered that in Ubuntu, the key events are sent in the proper order! 
<zul> Keybuk: there is a rgression in the latest dapper upload for the kernel. #50031
<mdke> zul: crimsun_ said that he'd nailed it down and had got a fix
<zul> yeah i know
<mdke> ah
<zul> i been talking to him ;)
<dem> out of curioustity what language is lauchpad/roseta writen in?
<mdke> dem: python. Find out more at #launchpad 
<theine> Sorry for triple posting on bug #50031. As much as I enjoy spamming people -- this was not intended. I just hit "Reload" a couple of times.
<Ubugtu> Malone bug 50031 in linux-source-2.6.15 "[regression]  Resume is broken with 2.6.15-25" [Critical,Confirmed]  http://launchpad.net/bugs/50031
<crimsun_> known, compiling to test a fix
<dem> i can conform that for a z61t
<dAndy> does anyone know anything about Bug #48918? This is a big bug for my organization, we want to load about 40 boxes next week, and we would like them to have root passwords
<Ubugtu> Malone bug 48918 in kickseed "shadow passwords not enabled (no rootpw)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/48918
<theine> dAndy: If it isn't fixed until next week, may I suggest to run a script that runs shadowconfig on all boxes via ssh?
<stuNNed> i need newer glibc for gnomad2 project is this possible w/dapper or do i *have* to run unstable?
<tseng> i have never heard of a simple user land app that requires a newer glibc
<tseng> and "no"
<stuNNed> tseng: let me check, maybe i'm wrong.  and doesn't mono rely on esd?  if it does.  that's really stupid imho.  i've killed esd and muine freezes sometimes.  you might want to disable esd code in muine and steal from mpg321 or something, i dont' know.
<tseng> ...?
<tseng> muine uses gstreamer
<tseng> gstreamer can use esd, oss, also
<tseng> *alsa
<tseng> polyp
<tseng> whatever.
<jdub> pulse!
<tseng> are you sure you mean glibc and not glib?
<stuNNed> well why when i disable esd mono fannooks?
<stuNNed> i mean muine...
<Keybuk> jdong: what's pulse?
<tseng> because you have gstreamer setup to play to esd
<Keybuk> meh
<Keybuk> jdub: what's pulse?
<tseng> Keybuk: polypaudio
<Keybuk> new name?
<Keybuk> or fork?
<tseng> new name
<Keybuk> ahh
<jdub> much better new name :)
<makko> what is the url to the gmane newsgroup which anounce updates and their reasons (i want to use is instead of update-manager, which almost never shows anything)?
<makko> anounces
<_ion> You can use apt-listchanges
<jdub> Keybuk: hey, got any gnome issues you want seb, daniel and i to touch on at guadec?
<jdub> Keybuk: gathering a list for us to work on
<Keybuk> I'd like session management to not suck
<jdub> adding
<Keybuk> I still think Log out/Switch user/etc. should all be replaced by one thing that lets you log on as another user
<Keybuk> it may choose to save your session and end your apps after a while, or immediately, depending on resources
<jdub> Keybuk: anythign else?
<jdub> hold on, i'll save this page os you can see what i have
<jdub> Keybuk: https://wiki.ubuntu.com/JeffWaugh/Guadec2006
<Keybuk> I'd still like to see Applets and NIcons become one
<Keybuk> with the panel as one bit NTray
<_ion> "telepathy/galago: Ready for desktop use in edgy timeframe?"
<Keybuk> - state of evolution; is anyone going to bother maintaining it?
<_ion> That would rule.
<jdub> Keybuk: evo - good
<Keybuk> you already have epiphany on there -- my one ffox killer feature btw, is being able to bookmark a set of web pages and open them all at once
<jdub> yeah
<Keybuk> not to mention various extensions
<Keybuk> LP would be unusable if it weren't for linky and stylish
<jdub> oh, reminds me - bug-buddy/launchpad/etc
<Keybuk> more avahi!
<Keybuk> "Share this folder" => some kind of avahi share, not samba
<Keybuk> "Share this calendar"
<Keybuk> "Share this document"
<Keybuk> "Share this playlist" (I think this works now, no?)
<Keybuk> avahi chat sessions
<Keybuk> avahi tomboy!
* jdub adds 'Avahi Everywhere'
<Keybuk> guadec is after ufk, right?
<ajmitch> 'share these photos' => f-spot & DPAP support hacked in
<Keybuk> ship some bloody mono apps in gnome desktop
<Keybuk> (like tomboy) :p
* ajmitch pushed f-spot bzr branches to lp yesterday
<ajmitch> must get it in desktop seed
<jdub> i've added a suggestions section
<jdub> please add
<NthDegree> will reiser4 go in edgy?
<Lathiat> woo avahi :)
<ajmitch> Lathiat: smelly thing, who would ever want to use it? :)
<Lathiat> you!
<ajmitch> well, yes
* jdong considers changing nick so as not to be confused with jdub :)
<LaserJock> why not make jdub switch ;-)
<LaserJock> or rock-paper-scissors for it
<jdong> I figure he has seniority around here :)
<jdong> lol
<Hobbsee> haha.  rock paper scissors for it could be fun
<stuNNed> ok what's this: ****** glibc detected *** corrupted double-linked list: 0x103bf268 ***
<stuNNed> debian mess?
<tadpole> stuNNed: where do you see it?
<stuNNed> starting latest stable gnomad2
<stuNNed> marked by gnomad2 devs
<stuNNed> is there a quick fix?  as i'm at a coffee shop and they are about to close and there is no network at my apartment
<tadpole> probably not without re-compiling.
<tadpole> does a backtrace tell you anything useful?
<stuNNed> welp, malone's search feature and algorithm could be simplified and improved...
<stuNNed> use gdb?  i've been out of it for a few...
<tadpole> yeah. but it will probably be useless unless you re-compile gnomad2 with debugging symbols.
<stuNNed> ok so that i will do tonight i will recompile gnomad2 w/debugging turned on and report back tomorrow, that fine?
<stuNNed> i gotta go they are closing
<tadpole> sure.
<stuNNed> i will see you asap
<tadpole> good luck.
<stuNNed> thanks hopefully will get this creative zen microphoto working w/mp3 support have to use libmtp for it, so revenge it is! see you guys, be good.
<asac> iwj: you found time to redo the patch from the real checkins? I have finished extracting suite patches, so I can invest some time on this issue again.
<sivang> morning all
<stc> hello
<Toma-> Would this be considered a worthy bug? http://paste.ubuntu-nl.org/15853
<stc> i have this bug: Xgl http://pastebin.com/714455
<siretart> morning.
<Hobbsee> hey siretart 
<siretart> stc: Toma-: please read the topic. please use https://launchpad.net/distros/ubuntu/+filebug for reporting bugs
<siretart> huhu Hobbsee 
<Toma-> doing so now... just dont like fileing bugs that arnt really bugs :(
<Toma-> and wether it should be filed under sane or udev
<siretart> Toma-: then use https://launchpad.net/distros/ubuntu/+addticket to file a support request. it can be upgraded as a bug if necessary
<Toma-> ahhh thanks ;)
<Toma-> filed and waiting. thanks again!
<nomed> hi all
<nomed> Mithrandir, around ?
<imbrandon> most are probbly on flights on preparing for flights to paris
<nomed> ops true
<imbrandon> ;)
<highvoltage> mdz: hi there, are you around?
<rddp> are the voip sessions at Paris going to be recorded and availiable later, or only in real time?
<\sh> voip sessions?
<\sh> there is _no_ video casting? ;)
<Keybuk> rddp: both
<Keybuk> they will be available realtime and recorded
<rddp> Keybuk,  great, thanks
<\sh> Keybuk: tell me more about it...voip? ekiga, or something else?
<Keybuk> \sh: we'll be using TeamSpeak
<\sh> Keybuk: not really, no?
<Keybuk> \sh: yes
<\sh> then I need to install teamspeak...oh joy :)
<Keybuk> yeah
<Keybuk> easy enough, just download the tarball from their website
<Hobbsee> and mangle your sound settings a bit, usually
<\sh> Keybuk: I was using it in the past with windows..and it was difficult to understand the people when 5 people are breathing and didn't adjust their mics
<Hobbsee> \sh: it's not so bad when people use push to talk - some of us were testing it out earlier
<\sh> Hobbsee: push to talk is quite useless, when you are playing mmorpg ;) and there is no key combination left to use ;)
<Hobbsee> \sh: well, that's true :P  but you're hardly playing mmorpg in meetings, now are you \sh?  actually, dont answer that :P
<\sh> Hobbsee: well...I used gobby and kate during the bofs at ubz..no mmorpg though ;)
<Hobbsee> heh
<Keybuk> hey sab
* \sh needs new server hardware
<Chipzz> hrrrrm
<Chipzz> edgy libc6 appears to break locales...
<Chipzz> Traceback (most recent call last):
<Chipzz>   File "/usr/bin/apt-listchanges", line 35, in ?
<Chipzz>     import apt_listchanges
<Chipzz>   File "/usr/lib/site-python/apt_listchanges.py", line 25, in ?
<Chipzz>     locale.setlocale(locale.LC_ALL,'')
<Chipzz>   File "/usr/lib/python2.4/locale.py", line 381, in setlocale
<Chipzz>     return _setlocale(category, locale)
<Chipzz> locale.Error: unsupported locale setting
<fabbione> Chipzz: thanks for reporting another duplicate :)
<fabbione> that was known even before uploading the new glibc to edgy 
<mdz> fabbione: then why was it uploaded?
<fabbione> mdz: required to bootstrap the toolchain for edgy
<fabbione> it's not a critical bug even tho very annoying
<mdz> fabbione: what I meant was, why wasn't the bug fixed first if it was known?
<mdz> it breaks the installation of some other packages
<mdz> it causes a number of programs to fail to run
<fabbione> mdz: I think Jeff didn't manage to find the problem
<Chipzz> fabbione: that's just apt-listchanges; perl also borks out
<fabbione> Chipzz: they are warnings, not fatal errors
<mdz> python programs in general are broken by this
<fabbione> atleast for perl
<Chipzz> fabbione: they most definately are fatal
<mdz> perl only warns
<Chipzz> for python that is
<mdz> postgresql explodes
<fabbione> well don't run python apps :P
<fabbione> it's edgy
<fabbione> it's meant to be broken at the very first opening
<Chipzz> I wasn't expecting a fix or anything; just reporting
<mdz> fabbione: there is a difference between finding bugs and uploading known broken packages
<Chipzz> I know not to expect support for edgy
<Chipzz> :)
<fabbione> Chipzz: then please do it properly via malone :)
<Chipzz> I *do* suspect my system not to be booting at the next reboot though :P
<fabbione> mdz: yes i am aware of that. There is also the balance between being able to open a new release or stall it 100%.
<Chipzz> udev postinst borked out too :P
<phanatic> mdz: i have uploaded a debdiff for a bug (sysinfo in universe). i was told to ping you about -updates upload... (bug 47671)
<Ubugtu> Malone bug 47671 in sysinfo "Data in Hardware and USB tab truncated" [Medium,In progress]  http://launchpad.net/bugs/47671
<mdz> phanatic: the changelog needs s/dapper/dapper-updates/
<phanatic> mdz: okay, i'll upload a new debdiff then. shall i assign the bug to you?
<mdz> phanatic: and please describe your changes in the changelog; not only "fix another issue"
<phanatic> mdz: thanks, i'll do it
<mdz> phanatic: code changes look fine, just update the changelog and go ahead
<phanatic> mdz: i don't have upload rights. shall i ask a motu to do that for me?
<Chipzz> hrrrrm
<mdz> phanatic: yes
<phanatic> mdz: thanks for your help
<mdz> phanatic: np
<Chipzz> launchpad reports latest version of udev as 093-0ubuntu2
<\sh> it's FTB...because of broken deps
<Chipzz> just did an apt-get update ; apt-get install udev 1 minute ago; I'm still getting 093-0ubuntu1 ?
<\sh> debhelper, po-debconf and further down the road of deps
<fabbione> Chipzz: yes, that's supposed to fix the postinst, but it might not be wise to reboot ... just yet ;)
<Chipzz> and yes, I *am* using the main mirror so I should be getting it...
<Chipzz> ?
<\sh> it's just not build, that's why a debootstrap or pbuilder run for creating edgy chroots just breaks right now
<Chipzz> \sh: hrrm didn't read your comment about FTB
<Chipzz> :P
<\sh> Chipzz: Builds of udev - 093-0ubuntu2: all failed
<mdz> I uploaded an intltool-debian yesterday which should have unblocked that chain
<\sh> so there is a source package but no binary
<mdz> at the time, the publisher was on manual due to keybuk doing synsc
<mdz> syncs
<Chipzz> hrrrm :P
<Keybuk> mdz: yes, but your upload failed to build
<Chipzz> this could get nasty due to this being a laptop and not being able to suspend ;P
<Keybuk> mdz: http://librarian.launchpad.net/3080430/buildlog_ubuntu-edgy-i386.intltool-debian_0.34.2%2B20060512ubuntu1_FAILEDTOBUILD.txt.gz
<Keybuk> amusingly it failed to build because of the bug the upload was supposed to fix
<dem> anyone here from the kernel team?
<Chipzz> dem: try #ubuntu-kernel ?
<fabbione> dem: -> #ubuntu-kernel
<dem> okay thx bro
<mdz> Keybuk: sweet
<Keybuk> mdz: TEAM INFINITY will deal with that
* Chipzz opens /etc/environment and kills LANG*
<Chipzz> who needs translations anyway :P
<\sh> sounds like "we install this package into chroot to fix bug" 
<ogra> Keybuk, is that the new name of the X SWAT ?
<siretart> Keybuk: can you approve uploads to dapper-updates, or does every upload has to go via mdz?
<siretart> ah, mdz is around as well
<mdz> s/mdz/ubuntu-release/
<ogra> ubuntu-release isnt around, no
<ogra> :P
<siretart> oh. I see
<Keybuk> ubuntu-release have to approve uploads and cc ubuntu-archive to actually process them
<siretart> anyway, may I upload this patch: http://librarian.launchpad.net/3084606/a ? it for fixing malone #40613
<Ubugtu> Malone bug 40613 in pbuilder "pbuilder expects debootstrap, gets cdebootstrap" [Medium,Fix committed]  http://launchpad.net/bugs/40613
<siretart> fixed in edgy, btw
<desrt> i am weak.
* desrt looks into edgy.....
<Keybuk> bit late aren't you?
<Keybuk> some of us have been using it for a week!
<desrt> i was trying to not do it
<desrt> saying "oh... it'll only be 4 short months"
<desrt> but seriously... when you're sitting at home on a saturday morning with nothing better to do, ...
<Keybuk> plenty of things for a boy to do on a saturday morning when all alone
<Keybuk> children's TV, for example
* desrt is picking up the kernel only
<Keybuk> there's no lrm for the new kernel yet
<desrt> eeg.
<desrt> my laptop = madwifi-ng
<desrt> my desktop = nvidia
* desrt is a closed-source pawn :(
<desrt> dapper itself has been sort of upgrade-happy....
<sbalneav> ogra: ping
<ogra> sbalneav, pong
<ogra> sbalneav, i just bought a 19" LCD ;)
<ogra> i'll bring it 
<sbalneav> Hey, just sitting in the airport in minneapolis, getting ready for the overnight flight to Paris.
<sbalneav> Cool.
<sbalneav> Made a couple of changes to the thin client spec.
<sbalneav> Added in the avahi, and a couple of other notes.
<ogra> great
<sbalneav> Guess you're just hopping a train?
<ogra> nope, i go by car
<sbalneav> Ah, nice!  How long's the drive?
<ogra> i'll start tomorrow around 8
<ogra> 4-5h drive
<sbalneav> sweet.
<ogra> so i should be there around noon
<ogra> its 500km only but france has speed limits :) else i'd be much faster 
<sbalneav> We thought about driving, but couldn't get a snorkel long enough for my toyota :)
<ogra> loool
<ogra> just get some monster tires :)
<sbalneav> heh
<ogra> just like the stnt trucks :)
<ogra> *stunt
<sbalneav> Cool.  We'll be in the country by about 8:30.  We'll proabably spend the day in Paris, then make it back for the 7:00 meeting.  Should be a blast.  Got a cell phone with you?  If you'd like, maybe we can head down to downtown together?
<ogra> sbalneav, got the PM ?
<sbalneav> err, no
<ogra> sbalneav, +49 177 784 74 66
<sbalneav> ah, yes I did, sorry
<sbalneav> I usually use xchat, but I'm making an effort to use Gaim under dapper.   Tab popped up and I didnt notice. :)
<ogra> heh, gaim
<sbalneav> jammcq asks if you're bringing the porsche
<\sh> lol
<ogra> no
<ogra> it brings me :)
<\sh> ogra: didn't you say at LT you have to fix it, this porsche?
<sbalneav> Both jammcq and I are loling
<ogra> \sh, sure, but its good enough to drive to paris before
<\sh> ogra: hehe...well, I think it's the same driving experience as with amus spider ;)
<ogra> \sh, currently i have to concentrate on moving houses after that i can think about disassembling cars ;)
<ogra> \sh, not even near, its a hauswife porsche ... not a 400 horsepower monster
<\sh> ogra: btw..when you and suse are setteled in the new house, give me a ping, I will do some travelings after the 12th of July
<ogra> (but it also doesnt take 25l on 100km)
<ogra> \sh, great 
<ogra> \sh, our move has to be done by 1st of augunst
<\sh> ogra: hmmm... 70 cologne <-> karlsruhe
<sbalneav> jammcq and I will give you a call when we arrive.
<ogra> sbalneav, great ... i'll likely be just hitting the motorway at that time ...
<\sh> ogra: cool...if you need some help, over the weekend I can help you ...:)
<ogra> \sh, i'll come back to you with that :)
<\sh> ogra: please do :)
<sbalneav> We can all hop the train, and go see the eiffel tower, and have a glass of vin on the champ's d'lysee
<\sh> lol...and use the stairs to climb up the eiffel tower ,)
<sbalneav> err, elysee
<\sh> but this we had already ;)
<sbalneav> I think I'll take the elevator, thanks :)
<ogra> sbalneav, yeah, lets do that :)
<ogra> sbalneav, mdz is already there, you might run into him in the hotel
<sbalneav> Oh, cool.  sabdfl as well, I assume?  Wonder if he flew or took the chunnel?  We're staying on one extra day (saturday) and taking the chunnel to london for the day! 
<ogra> sabdfl was in russia one hour ago ... no idea if he'll be there already tomorrow
<ogra> i bet he'll fly canonical 1 tomorrow
<\sh> brb
<Eleaf> yay~!!~
<Eleaf> ;[
<\sh> re
<stuNNed> hello good folks
<stuNNed> at work now but will help debug glibc and latest gnomad2 later today
<stuNNed> with latest stable libmtp (not the one mentioned on the gnomad sf.net site) i get an execution error (i think) with gnomad2 and ubuntu stable glibc (dapper)
<stuNNed> *** glibc detected *** corrupted double-linked list: 0x103de1c0 ***
<fabbione> that's not a bug in glibc
<stuNNed> maybe i should try the libmtp that the gnomad site recommends, doh :)
<stuNNed> ok so what might it be? :)
<fabbione> glibc is telling you debugging info on the app you are running
<fabbione> the app is using a double-linked list
<stuNNed> ah i got it
<fabbione> and it gets corrupted
<fabbione> so glibc, instead of allowing the app to destroy data, it kills the app and tells you what is wrong
<stuNNed> i'll try downgrading libmtp and see what happens.  right now i'm working at the local grocer and need to fix a deli sheet
<fabbione> what you want to do instead is to gdb the apps with debugging libs
<stuNNed> well that is pretty smart :)
<fabbione> and see why/where it fails
<stuNNed> so ./configure --enable-debbugging will do for prep?
<ogra> fabbione, probably it should just pay some money to the app if its corrupt :)
<stuNNed> (sp)
<fabbione> stuNNed: you want to make sure to build with -ggdb and -O0
<fabbione> stuNNed: also for the library
<fabbione> and make sure not to strip them
<stuNNed> fabbione: right on.  
<fabbione> so you can see where it breaks
<stuNNed> what i did as per tseng's suggestions was install the deps with apt (apt-get build-src) or something (i don't know the debian system that well) then downloaded gnomad2 from the their dev site and compiled and installed that, is that the right way?
<stuNNed> or should i build gnomad2 from a debian repository and not use the source from their dev site.  it probably doesn't matter but i don't know what tweaks might have been thrown in.
<stuNNed> i'm sorry an ubuntu one
<stuNNed> reading manpage now
<stuNNed> a way to build from source with the package manager would be nice imho
<stuNNed> not a gcc optimizer but if need be or something
<stuNNed> i'm meek so you might now hear my words :D
<\sh> stuNNed: pbuilder and chroot are your friends...but this is more a #ubuntu issue
<ogra> apt-emerge !
<stuNNed> hey!  i give good advice and am a good writer! :D
<\sh> apt-emerge _world_
<stuNNed> i applied but haven't had time to get the resume together yet :(  just resigned from tulane university new orleans louisiana united states (too much of the *other*)
<stuNNed> they put me in policy setting for future computing but their ms future plans were and i think still are too great.  it's a real shame as it's a very high calibre university but i guess we just don't have the local technical expertise to run massive amounts of linux :(
<stuNNed> enough of my rant :)
<stuNNed> apt-emerge multilateral
<stuNNed> when we get *one* which i am trying to expedite it should be `apt-get dist-update multilateral` :D
<stuNNed> apt-emerge dist-upgrade multilateral
<stuNNed> or whatever :\
<stuNNed> 1st for binary, 2nd for source
<stuNNed> now let's see those aholes steal that one. do it so we can run the tab up some more :D
<stuNNed> fucking bomber ahole
<stuNNed> scuze me
<stuNNed> sry for foulnesss
<sivang> ogra: any idea what sort of plug adaptor we need to france?
<desrt> sivang; europlug
<sivang> desrt: could toss me a link to how this looks like?
<desrt> sivang; for grounding you need the plug that accepts the pin which pokes out
<desrt> http://en.wikipedia.org/wiki/Europlug
<stuNNed> french on the corner last night they were silly like stuck on a dang street corner
<Chipzz> yay
<Chipzz> firefox in ubuntu--
<Chipzz> grmbl
<desrt> grounded version: http://en.wikipedia.org/wiki/Domestic_AC_power_plugs_and_sockets#Type_E_.28French_2-pin.2C_female_earth.29 
<Chipzz> just fucked over my session saved by session saver
<stuNNed> yeah this deal where canadians don't believe in grounded wires well let me tell ya where i'm at now eh, i need one :D
<desrt> ...
<sivang> desrt: thanks
<stuNNed> desrt: not all canadians just one gentoo dev i know on freenode
<stuNNed> sry again but it's saturday :D
<desrt> well, as it is
<desrt> i am searching high and low for a cord which has a europlug on one end and an apple power adaptor interface on the other
<sivang> desrt: the israeli one is just like Type C
<\sh> well, what we need is a standard for power plugs somehow...;)
<sivang> \sh: indeed
<desrt> sivang; not true
<desrt> sivang; israel is quite odd
<sivang> desrt: you have knowledge of it? do you know where I can get such adaptors ? :)
<desrt> "type H" -- This plug, defined in SI 32 (IS16A-R), is unique to Israel and is incompatible with all other sockets.
<desrt> you can stick europlugs in some of them though
<sivang> desrt: so I can stick the .IL one into the europlug one? :)
<desrt> no
<desrt> the grounding pin on the israel one gets in the way
<jpatrick> because they have 3 pins
<desrt> but you can stick europlugs into israeli sockets
<sivang> crap :)
<raphink> hello there :)
<sivang> hey raphink ! 
<raphink> we've got a problem with intltool-debian in edgy
<raphink> it build-depends on po-debconf, which itself depends on the new intltool-debian to install
<raphink> which obviously can't be installed since we want to build it ;)
<raphink> so all packages depending on intltool-debian FTBFS
<raphink> is someone working on this already?
<\sh> raphink: as keybuck already said: TEAM Infinity has to deal with it ;)
<raphink> hi sivang
<raphink> team infinity?
<raphink> :?
<raphink> hi sivang btw :)
<\sh> raphink: well the problem is known and someone will work on it, let's say on monday 
<raphink> ok :)
<raphink> looking forward to it :)
<\sh> raphink: enjoy the weather :) 
<raphink> hehe
<\sh> raphink: some beer some wine
<raphink> yeah 
<raphink> I should do that
<raphink> or try to see if there's something to merge that I can do
<desrt> sivang; if in your travels to find powercords you should happen upon something....
<desrt> sivang; i basically want this: http://eshop.macsales.com/item/Other%20World%20Computing/MNEPWREU/
<desrt> sivang; but with one of these on the other end: http://desrt.mcmaster.ca/random/apple-connect.jpeg
<Keybuk> desrt: you can get them from Apple stores, no?
<Keybuk> or, at least, from Apple
<sivang> desrt: The requested URL /item/Other World Computing/MNEPWREU was not found on this server.
<desrt> works for me?
<sivang> Keybuk: do you happen to accidently have a outlet -> AC adaptor chord that is Type E compatible? 
<sivang> Keybuk: (the plug in to the AC adaptor is universal , the chord to the outlet not)
<Seveas> For the conference people: please poke me when you know the IP address(es) you'll get so I can poke freenode staff and you won't get K-lined for having a shitload of connections 
<Keybuk> sivang: whuh?
<Keybuk> I don't have any Europlug cords, if that's what you mean
<Keybuk> we use different sockets here
<sivang> Keybuk: ah, never mind. Hopefully I'll be able to get an adaptor on the airport :)
<KaiL_> hmm, no edgy updates since 2 days?
<zul> KaiL_: i think most people are flying to paris right now
<KaiL_> ah, yes, forgot 
* dieman waits at the airport.
<dieman> I brought a universal electric adpapter and a power strip for us US types
<dieman> or people who have US plugs but not euro plugs
<dieman> theres a ton of people here tyring to get on this flight though
<dieman> i guess another flight to detroit is delayed 2 hours
<dieman> or more
<desrt> crimsun; ping
<crimsun> desrt: pong
<desrt> crimsun; hda_intel: azx_get_response timeout, switching to single_cmd mode...
<desrt> (after stalling for about 24 seconds)
<desrt> on resume from sleep
<crimsun> desrt: with -23.39 or -25.43?
<desrt> just wondering if you know anything
<desrt> -25
<crimsun> ok, -25.43 is all kinds of broken
<desrt> seems like a new problem, too
<desrt> eep
<desrt> anything i can do to help you fix it?
<crimsun> I cannot isolate the interaction between ACPI and [just about everything] , so unless you can reproduce it with -23.39 + the sigmatel diff, it will be awkward to troubleshoot
<desrt> oh.  acpi is being evil in -25?
<crimsun> which is of course problematic, since I think you need a couple patches that are in -25.43 to resume properly?
<desrt> well.. i sent those patches
<crimsun> right
<desrt> i have a patched up -23 for myself
<desrt> i think this is a new problem with -25 though
<crimsun> does your local -23.desrt exhibit the symptoms?
<desrt> no.  don't think so.
<desrt> it's only started happening since the upgrade
<desrt> it delays my resume by a good 20 seconds so i think i'd have noticed before :)
<crimsun> right, a lot of things have become ... interesting as of -25.43
<desrt> were there any other patches to hda or only mine?
<crimsun> I should add that of course -25.43 isn't broken for everyone; it fixes quite a few issues for a significant number of users
<ajmitch> where 'interesting' means broken, i guess
<desrt> well, not mine.  but the one you pointed me to and i've been using for ages
<\sh> where is -25 anyways...all my repos don't show anything
<crimsun> desrt: there was a fix for a race condition, but it wouldn't break your hardware
<zul> dapper-security
<desrt> \sh; are you sure you have -secuirt and -updates enabled?
<\sh> desrt: yes
<desrt> do you have linux-686 installed?
<\sh> no
<\sh> i386
<desrt> if you only have linux-image-2.6.15-23-386 installed then it wont be upgraded
<\sh> ah ok..
<\sh> I just wondered
<desrt> you need the actual linux-386 package to pull the version up
<\sh> desrt: well, linux-386 is installed, but with version 2.6.15-22, but my boot kernel is 2.6.15-23
<desrt> \sh; i've no idea.
<desrt> \sh; -23 shipped with dapper
<\sh> desrt: on this laptop it's a dist-upgrade from flight 6?
<\sh> i think it wasflight 6
<\sh> so something is going wrong with the updates of the linux kernel? it looks like 
#ubuntu-devel 2006-06-18
* desrt needs a book for the plane
<HiddenWolf> desrt: social skills for dummies? 
<tseng> ouch
<HiddenWolf> desrt: it might be a shock, meeting the people behind the nicks. :)
<desrt> HiddenWolf; nah.  i've done these conferences and stuff before
<tseng> HiddenWolf: hell, he is rooming with me
<desrt> HiddenWolf; but by the sounds of it, you could use the book :)
<tseng> HiddenWolf: there's the shock
<tseng> (you are, arent you? pisano said it was good)
<HiddenWolf> desrt: no offense ment, obviously
<desrt> HiddenWolf; social skills for dummies said you shouldn't randomly insult people you don't know :p
<HiddenWolf> desrt: it probably does, but where is  the fun in that?
<HiddenWolf> Anyway, I should be off to bed.
<HiddenWolf> Good night everyone.
* dieman is in detroit now
<ProN00b> quite some people say 6.06 was a bad release, comments plx
<sladen> ProN00b: {{needs citation}}
<tseng> quite a few people say that ad hominem if a falacious argument
<tseng> </irony>
<sladen> ProN00b: quite a few people say 6.06 was a good release, comments please
<tseng> I will admit that I see alot of people who didnt test the beta make a big fuss about their pet bugs
<sladen> ProN00b: I think if you can ask a more useful question, you'll likely get more useful answers
<ProN00b> tseng, well, the number of bugs people just run across are more than in the last release, i have heard and encountered this
<ProN00b> sladen, i just wanna get an overview of what you think about that issue
<tseng> we can't respond to such a vague generalization
<tseng> vaguely generalized, we disagree
<ProN00b> its not vague
<tseng> its very vague, what bugs?
<ProN00b> people are feeling like there are more bugs in this release than the last
<sladen> people (who?) ... bugs (which?)
<ProN00b> do you expect me to analyze the forums and compare it with the forums after the last release and correct those values with ubuntu usernumbers ?
<tseng> jeez
<tseng> yes, since you posed the question
<tseng> not that i expect the forums to provide valuable first source data anyway
<tseng> its an informal discussion
<sladen> ProN00b: one of us is going to have to analyse the forums and find the usernames and bug numbers;  since you're the one asking the question and the one already with the information it would be useful if you could do that;  since there is a lot of data, it would take me a long time and I'm still unclear what sort of answer to what sort of question you'd be happy with
<tseng> I have ... 5 pc's running dapper
<tseng> no nagging bugs
<tseng> about 4 more servers
<tseng> no, 6
<ProN00b> its just that i heard people saying things like "<iXXXXXXy> ubuntu dapper drake is half almost baked.    they tried to make it 'idiot proof'  but only proved them selves better idiots." (actual quote from today) and this is maybe second or third time i have heard people expressing it so extreme... and i also feel the same way
<tseng> that doesnt even sound like a bug
<tseng> it sounds like you aren't a fan of certain intentional features
<tseng> I would have agreed with you if that was your premise at the begining
<tseng> hacking up gnome in the way we have is Not Cool in my book
<ProN00b> no, not really
<tseng> it takes me under 5 minutes to work around all that
<ProN00b> second quote from the same person (i was talking to him about something like a maybe-bug, maybe behavior change (report filled by random person on forum)) "<iXXXXXXy> pXXXXXu the above is one of at least 30 'that i know of' issues that should not be in any 'stable' release.   that is a bug in the base system.   you don't release things like that and proclaim it to be  'linux for human being'  implying that other linux's are not for humans.
<ProN00b>    and you don't release a system and call it stable that every one that installes it finds bugs...  like ubuntu dapper."
<tseng> I am very glad he knows them
<ProN00b> tseng, what do you mean, what problems do you have with gnome ?
<tseng> not helping
<tseng> the logout dialog is attrocious
<tseng> the default themes likewise
<tseng> i turn them off and go on with my life
<tseng> if I have a bug I report it to launchpad or just fix it, instead of sansationalizing it on the forums
<ProN00b> who did that on the forums ?
<tseng> your last quote
<tseng> I am tiring of this
<ProN00b> oh, thats from irc
<tseng> if you are serious about this, can you please compile a list of real data
<ProN00b> hmm, do you have any idea where i can find gnome themes ? (icons and windows and stuff)
<tseng> not something $joerandomuser threw out there
<tseng> w/o no citation
<tseng> and post it to ubuntu-sounder mailing list
<ProN00b> whats that ubuntu-sounder thing for ?
<tseng> its general ubuntu discussion
<tseng> anything goes
<tseng> but its very community-meta oriented
<tseng> going to watch a movie, have a nice night
<ProN00b> nn
<Tonio_> hi all
<Tonio_> hey
<_ion> Bono estente.
<hunger> hi there
<dm> sladen: Hello, I'm new to ubuntu and just faced a bug that you filed to launchpad -- nbd-server and accept(). Who is now responsible for uploading the fixed package to dapper-updates?
* dieman is in paris now
<\sh> dieman: welcome to the city of love 
* \sh wishes he could be in paris as well, but this time, the job is more important
<Hobbsee> uh oh, glad i'm not there then :P
<\sh> Hobbsee: lol...
<Hobbsee> unless there are interesting people ther
<Hobbsee> e
<\sh> Hobbsee: there are.. so hurry :)
<Hobbsee> hah
* Hobbsee has no passport.  and a lack of money.
<sladen> dm: I've filed a sync request
<knopper> Hi everyone. Question (I know I should try this on my own, but unfortunately, not enough bandwidth for even downloading a CD): Does the Ubunu Live CD/DVD come with an installer, and what does it do exactly?
<HiddenWolf> knopper: it comes with an installer, which installs the system when you want it to.
<HiddenWolf> knopper: #ubuntu is more appropriate for this question.
<knopper> HiddenWolf: Srry, you may have mistaken this for a beginenr question. ;-) I actually meant "what does it do", i.e., are you using apt-get/dpkg for a package-wise installation, or are you doing an rsync of the live system to harddisk?
<mjg59> knopper: The live system is somewhat copied in place
<mjg59> It doesn't use packages, so it's not suitable for upgrades
<knopper> mjg59: That's what I thought, so it actually does what the older version of knoppix-installer did, format a harddisk partition and copy / from the live system to the harddisk, then creating a fstab and lilo.conf (or grub menu), right?
<knopper> mjg59: So, do you know if anybody is working on a package-wise installer for the Ubuntu Live DVD? This would eliminate the need for separate Live vs. Installer DVDs.
<knopper> mjg59: I have a proof-of-concept that shows it's working fine. You can update Debian from a Knoppix 5.0.1 DVD, package-wise including resolving of package dependencies.
<\sh> hmm..has someone an IBM T43 laptop at hand?
<knopper> \sh: Sorry, just a few old IBM Thinkpads here.
<\sh> I wonder if it's just me and my installation or it's a bug that sometimes it's not halting correctly...
<knopper> Btw, which would be the right channel to talk to a few people who are at the meeting in paris next week?
<mjg59> knopper: No idea, I'm afraid
<mjg59> knopper: The right person to talk to about this is Colin Watson (kamion)
<knopper> mjg59: He's idle for 15 hours, so I guess I'll have to try later. Btw, he is the one working on the ubuntu installer, right?
<mjg59> Yup
<mjg59> He's probably on his way to Paris at the moment
<knopper> mjg59: Oh, already. Unfortunately, I can travel on Tuesday first, and will miss the first two days. But good to know he's there, too.
<Mithrandir> knopper: the live DVD has both live and installer on it.
<knopper> Mithrandir: Right, but can the live CD be installed _package-wise_, was my question.
<knopper> Mithrandir: Or do you mean, the DVD can be booted in installer- and live-mode, with a different image?
<Mithrandir> knopper: the latter is correct.
<Mithrandir> knopper: the live installer always just copies the read-only file system.
<Mithrandir> (and then munges it a little bit)
<knopper> Mithrandir: My idea was to have a single-image live DVD (consiting of unpacked .deb packages) which can still be installed package-wise.
<Mithrandir> knopper: uh, how would you do that?  dpkg-repack hacks?
<knopper> Mithrandir: I see, that's what I guessed. So, if the installer could just handle _unpacked_ .debs from the livs system, we could have a simgle-image live+install system that can be used for both.
<knopper> Mithrandir: Kind of. It already works on KNoppix 5.0.1.
<knopper> Mithrandir: I.e. you can update packages on an installed system, from the live DVD, including dependencies.
<Mithrandir> it sounds brittle and slow at first thought.
<Mithrandir> but being able to upgrade off a live cd would be sweet
<knopper> Mithrandir: There is just an intermediate dpkg-repack for each chosen/dependent package that I deen to get rid of, and I thought, this may be a nice proposal for a BOF session at the meeting next week.
<Mithrandir> I think we might be short on time, but please do jump onto IRC and remind us.
<knopper> Mithrandir: Not only that, but in both cases, the installer and the live image, you share about 99% of the same data (except for configuration files), so it is a big waste of space to duplicate everything.
<Mithrandir> they're differently compressed, though
<knopper> Mithrandir: I'll try to get ahold of Colin later, since he is working on ubiquity and could maybe add that feature for generic live DVD support.
<Mithrandir> I wonder if it'd be feasible to do something like compute a delta between what you'd get from dpkg-repack and the original .deb and ship that somewhere..
<Mithrandir> which would give you trusted installs too.
<Mithrandir> he's not the only one working on the installer. :-P
<knopper> Mithrandir: .debs are basically zipped, tarred, and ar'ed files, and the live CD consists f a blockwise (or filewise) compressed filesystem, so, about 1:3 compressin for both cases.
<Mithrandir> (I've hacked a bit on ubiquity and am responsible for the live cd, fyi)
<knopper> Mithrandir: Oh, perfect. :-)
<knopper> Mithrandir: So, is there already a BOF planned for stuff like this, where I could just drop in?
<Hobbsee> Mithrandir: so we blame you for breaking it!
<Mithrandir> yes, but differently compressed.  squashfs compresses the image a directory at a time, .debs are a package at a time.
<Mithrandir> Hobbsee: what's broken?
<knopper> I was just in the progress of adding a proposal, which is a little late now since the deadline was 12th of june, but anyways.
<Mithrandir> knopper: I'm not sure, there's a bunch of live cd discussions where we could possibly fit it in.
<Mithrandir> knopper: you're planning on attending?
<Hobbsee> Mithrandir: well, i discovered that the italian stuff wasnt auto-installed when it was picked as a language, i think
<Hobbsee> let me find which bug it was
<knopper> Mithrandir: I already checked, but nothing yet that would really fit that idea of merging the installer and live parts.
<Hobbsee> Mithrandir: https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/39483
<Ubugtu> Malone bug 39483 in debian-installer "Kubuntu 6.06 final dvd doesn't install italian language for kde and other packages" [Medium,Confirmed]  
<Mithrandir> Hobbsee: I mainly did the keyboard thingy, not langpacks.
<Hobbsee> Mithrandir: ah okay
<Hobbsee> he was just whinging that it hadnt been fixed even though it was there for 2 months, etc...when it was still set to need info
<Mithrandir> Hobbsee: I noticed you changed the state of that bug earlier today, yes.  I think Colin's going to be busy with ubiquity bugs this cycle.
<Mithrandir> there's this "too many bugs, too few developers" problem we're having..
<Hobbsee> Mithrandir: hah, yeah, i know
<Hobbsee> oh i dont blame you guys at all - i know you do a great job.  some users though...
<knopper> Mithrandir: Sorry, missed yur earlier question. I'm arriving Tuesday afternoon, so, probably really there from Wednesday till Saturday.
<Mithrandir> knopper: https://launchpad.net/distros/ubuntu/+spec/larger-livefs touches on it, so I might be able to squeeze it in there, for instance.
<Mithrandir> knopper: oh, cool
<knopper> Mithrandir: https://launchpad.net/distros/ubuntu/+spec/obsolete-installer-part (maybe someone wants to join in).
<Mithrandir> knopper: it's not added to the Paris meeting, so it won't be considered.
<rubso> hi :0
<rubso> :)
<rubso> what is the system installer you use for Ubuntu/Kubuntu ? :)
<Mithrandir> rubso: debian-installer (the graphical installer uses it in the backend)
<\sh> live-cd: ubiquity / plain installation system (aka alternate): d-i
<knopper> Mithrandir: I know, but it's a long-term project anyways, and I expect no solution quickly. ;-)
<knopper> Mithrandir: There are enough other sessions to keep me busy for 3 days. :-)
<Mithrandir> :-)
<rubso> then Ubuntu is using an Improved debian-installer version, right?
<knopper> Mithrandir: On the other hand... Ok, I found the "Add to meeting" button. ;-)
<knopper> rubso: It would be the first real Debian-installer that actually works. ;-)
<Mithrandir> knopper: uh.  d-i works quite well and has for a long time.
<rubso> knopper: can you give me debian-installer source code to build it for a LiveCD? :)
<\sh> knopper: plan to attend froscon on saturday/sunday, too? :)
<\sh> rubso: it's konversation..
<rubso> i know !
* fabbione is almost tempt to drive to Paris this night
<\sh> fabbione: you are not flying?
<fabbione> \sh: i am not going
<fabbione> but i miss the guys
<\sh> fabbione: why not? 
<fabbione> a lot
<fabbione> \sh: because my wife is too close to deliver our baby
<fabbione> and i am not comnfortable to leave her alone
<\sh> fabbione: oh wow...congratulation..
* Mithrandir hugs fabbione 
* fabbione hugs Mithrandir 
<\sh> Og Maciel will have another baby in couple of months time, too...
<fabbione> Maciel?
* fabbione doesn't know her
<\sh> fabbione: http://www.ogmaciel.com/?p=275
<\sh> fabbione: she is a he ;) and father ;) so his wife will give birth...;)
<fabbione> \sh: in this world.. you may never know!
<\sh> fabbione: that's right :)
<\sh> oh btw...is there already a plan, where the next summit will be? I need to know it at least a couple of months before, to plan my holiday and to save money for this happening
<Hobbsee> (and when?)
<tseng> Hobbsee: a few weeks after the egdy+1 opens
<tseng> Hobbsee: as usual
<\sh> Hobbsee: most likely oktober/november like last year
<tseng> the is a launchpad and distro team sprint in between
<Hobbsee> bleh, okay
<tseng> which no one else normally attends
* Hobbsee doubts that she'll be at any of them then
<Hobbsee> too bad :P
<\sh> Hobbsee: you never know :)
<Hobbsee> \sh: that's AU uni term time...
<Hobbsee> so i do know that it wont be happening, at least for another couple of years :P
<tseng> what year are you in now?
<Hobbsee> 1st
<knopper> Mithrandir: (sorry for the delay, was writing another proposal), it's just me, I'm too much end-user to be able to use the regular debian-installer or synaptic. I think it's not suited for beginners. I'd rather use debootstrap and apt-get manually instead of any existing "graphical" installer for Debian yet. The only way I manage to install Debian with a graphical interface is booting KNoppix and running the knoppix-installer yet.
<\sh> Hobbsee: honestly, if I hadn't this personal break down in the last months, I would give everything to go to paris this month...
<knopper> Mithrandir: But you can still convince me it's possible. ;-)
<Hobbsee> \sh: um, i never said anything about that...
<mgalvin> jdub, jdub_: around?
<knopper> rubso: You mean, of the knoppix-installer? It's a shell script on Knoppix, and I hate it, it's really awful and I would like to replace it by something better.
<\sh> Hobbsee: so...you should give it a try and leave uni for at least one week for this event ;)
<Mez> i think next event i'm gonna go to is (other than LRL) aKademy
<fabbione> \sh: time is usually 2/3 weeks after the release.. release schedule will be done in Paris.. where... that's really up to how the sab wakes up in the morning
<\sh> fabbione: yeah :) I hope it's not too far away...let's say sweden, denmark or norway would be cold enough ;)
<Hobbsee> \sh: let me tell you, it *wouldnt* be worth coming home to, i assure you, if i were to miss a week of uni...
<tseng> \sh: hah ubz2
<fabbione> \sh: unlikely to be north EU.. too expensive
<\sh> Hobbsee: with approval of your profs and parents, of course
<fabbione> \sh: but i was hoping for dk at least once
<Hobbsee> \sh: yeah, the latter would be the issue :P  and wouldnt happen.  "you're a foolish girl" would be minor in comparison to what mum'd say....oh well.
<Mithrandir> knopper: synaptic has nothing to do with d-i.
<knopper> \sh: Sorry, I won't make it for froscon. I have two exams to prepare till 26th. :-(
<\sh> Hobbsee: let riddell convince sabdfl to talk to your parents in person ;)
<Hobbsee> \sh: which would then scare the hell out of them.  i havent dared tell them that riddell has my number :P
<Mez> Hobbsee - lol :D
<Hobbsee> i know even that would send them thru the roof :P
<knopper> Mithrandir: d-i is the thing that used to ask me if I want to install pcmcia support, and then fails the installation because of wrong dependencies (at least that was the case tw years ago, when I tried last, pardon my ignorance. ;-)
<\sh> knopper: I just asked, I missed your name on the agenda :)
<knopper> \sh: My name is on the list that Claire sent by mail, it's not in the web yet. Probably because I said I wuld add me and Adriane in the wiky by myself, and then forgot about it...
<\sh> knopper: no...FrOSCon Agenda :) 
<knopper> \sh: r did you mean froscon?
<Mithrandir> knopper: I doubt you used d-i two years ago.
<knopper> \sh: Yes, sorry, I got an email from the Froscon organizers and had no time to reply. For about a month now. :-(
<knopper> Mithrandir: I tried to install Debian with the supplied installer, honestly!
<Mithrandir> knopper: did you try to install Sarge or Woody?
<knopper> Mithrandir: Woody, I think.
<sladen> fabione and fabitwo </groan>
<Mithrandir> knopper: then you used boot-floppies, not d-i.
<sladen> fabbione and fabbitwo </groan>  even
<fabbione> sladen:  ?
<fabbione> sladen: you mean fabbitwo = fork(fabbione); ;)
<sladen> fabbione: babies!  and mini-fabbiones!
<fabbione> oh yeah
<sladen> fabbione: yup :)
<fabbione> we need a new X maintainer :P
<\sh> lol
<knopper> Mithrandir: I used a "Rescue-Floppy" (!) to load the kernel, and then an installer popped up and asked me some questions that I answered honestly. I had to copy a new kernel in the midst of everything, though, because the included one didn't work.
<sladen> :)
<fabbione> i already have a thin client as present for him/her
<\sh> fabbione: edubuntu rocks ;)
<sladen> fabbione: get one of those micro Japanese keyboards and the fingers should fit from day one
* _ion would have many suitable computers for a thin client, but no adequate server for them. ;-)
<Mithrandir> knopper: that's totally irrelevant, the b-f codebase has been scrapped and d-i is designed in a wholly different way.
<fabbione> sladen: nah.. better they start to stretch the fingers :)
<_ion> sladen: And additionally {,s}he would learn Japanese! :-)
<\sh> fabbione: use old big heavy ibm keyboards ;)
<knopper> Mithrandir: But the d-i is still looking like ncurses/dialog, right? Alexander Schmehl is frequently showing Debian installatins with this at Linux expos. Sometimes it works for him.
<Mithrandir> knopper: that depends on what frontend you use.
<Mithrandir> knopper: but yeah, slang is the default frontend.
<\sh> knopper: ubuntus d-i installation always worked without problems...(stable releases)
<Mithrandir> anyway, I'll see if I can find some coke here to stop my blood sugar falling completely through the floor.
<knopper> \sh: Question: Would you let a person who has no computer skills whatsoever, use this installer?
<\sh> knopper: yes..I did already many times :)
<\sh> knopper: and we did it during linuxtag 2006 at our kubuntu booth :)
<\sh> knopper: less then 20 minutes including downloading updates and security packages
<\sh> knopper: breezy that was
<knopper> \sh: So, chances are that we have met there in May. But I have seen people failing at the tast to just hit return on any question. The partitioner is probably the hardest part. What about that?
<\sh> knopper: well, that's the worst part...but we have a "resize windows partittion and partition automagically your hd" option, which is enough for people with no computer skills
<knopper> \sh: I must admit that I mostly use Knoppix for Debian-installation, or plain debootstrap, as said before, so, I didn't take notice of any important d-i changes yet. I would like d-i to be able to install from an already installed partition rather than from a repository, then it would be worth considering an inclusion in KNoppix.
<knopper> \sh: Automatically resizing Windows partitions, very adventurous... :-)
<\sh> knopper: with "already installed partition" you mean the live dvd?
<\sh> knopper: it works :) I promise..I did it many times :)
<Mez> Kamion, ping
<\sh> Mez: he is on his way to paris I think :)
<knopper> \sh: For example, but more generic. Let's say you have installed a quite complete (12GB) Debian system on /dev/hda1, and now you want to use this installation, to install a small subset of it (a thin-client configuration, for example) on hda2. But, you do not have any .deb packages, just the hda1 installation. YOu have te data and the package lists in /var/lib/dpkg, so, why should the installer not be able to do that, instead of
<knopper> \sh: building a repository first?
<\sh> knopper: but I can show you during essener linuxtage or linuxexpo in cologne...or you come to the LinuxHotel from the 21st to 23rd July to our FAI developer meeting ;) 
<carlospc> hi, anybody at paris?
<knopper> \sh: Alexander Schmehl always tried to convince me that the Debian installer works, but everytime he tried to show me, it failed. Must be me. ;-)
<\sh> knopper: hmm...you could do that, no doubt, but thinking of installing an unclean chroot (e.g. thin client). It's something which I wouldn't prefer as installation candidate
<carlospc> i've just arrived to Paris to go to the Ubuntu Developer Summit, i don't know if there is already somebody at the hotel, help!
<Mez> carlospc, there are people there :D - just head to the hotel :D
<\sh> carlospc: dieman is in paris (actually I don't know if he is in the same hotel), ogra should be there as well (or I hope so)
<Mez> and Riddell is there
<\sh> can someone switch of the sun, thx
<Mez> \sh - I'll do it later on tonight ;)
<carlospc> I'm in Kyriad Paris Nord II
<\sh> carlospc: the others are at http://www.radissonsas.com/cs/Satellite?cid=1053502953893&pagename=RadissonSAS%2FPage%2FrsasHotelDescription&language=en&hotelCode=parzq (canonical staff and sponsored people)
<carlospc> thanks \sh
<\sh> carlospc: but you can try to ping Tonio_ and ask him where to go :)
<\sh> or Lure
<\sh> not lure
<carlospc> oups 
<\sh> but Tonio_try him :)
<Lure> carlospc: Tonio_ is from Paris... 
<carlospc> i'm waiting his response
<carlospc> ok
<carlospc> i'm looking how to go to radisson sas hotel
<\sh> hmm...join #ubuntu-fr
<carlospc> many people are there right now
<\sh> carlospc: it's near the charles de gaulle airport
<\sh> carlospc: outside of paris
<carlospc> I'm in Parq d'Exposicion
<phanatic> carlospc: for public transport info, try www.ratp.fr
<Lure> carlospc: I susepect they have hotel shuttle bus
<carlospc> very near
<phanatic> carlospc: you can find the route between your hotel and radisson sas
<Lure> carlospc: "The hotel offers a free shuttle service to and from the airport"
<carlospc> do you know if i have to stop in Charles de Gaulle 1 or Charles de Gaulle 2?
<carlospc> let's see
<phanatic> i think 2
<\sh> at least you are in paris, france, europe ;) You can visit the graveyard where Jim Morrison is burried, or visit the eiffel tower or the moulin rouge ;)
<\sh> or just drink a very good cafe au lait 
<\sh> I'm so sad that I can't go there...grmpf
<phanatic> me too :(
<\sh> we could ubuntufy the centre pompidou (http://www.centrepompidou.fr/)
<\sh> carlospc: goldenear can help you too :)
<goldenear> what's the problem ?
<carlospc> I'm in avenue des Nations and i don't know how to get into Radisson SAS Hotel
<jpatrick> maps.google.com
<goldenear> carlospc: are you in paris ?
<carlospc> yes, at Parq d'Exposicions
<goldenear> Radisson is not in Paris but in a city around
<goldenear> carlospc: I'm try to see how you are
<carlospc> Well
<goldenear> carlospc: are you near te Trocadero ?
<carlospc> wait, i'm going to ask
<goldenear> ok
<goldenear> carlospc: you can try mappy.com
<goldenear> http://www1.mappy.com/?lang=en
<\sh> goldenear: you can meet him, too :) and show him some nice places ;) from tomorrow on there is no time for that ;)
<goldenear> sure
<goldenear> If he tells me exactly where he is I can meet him
<\sh> [18:13]  <carlospc> I'm in Kyriad Paris Nord II
<goldenear> Ok I see where he's
<goldenear> that's not in Paris but in Roissy
<goldenear> It's pretty close to the hotel
<\sh> this one? http://www.undercovertourist.com/france/paris/hotels/k/kyriad-
<carlospc> \sh, page not found...
<\sh> http://www.undercovertourist.com/france/paris/hotels/k/kyriad-paris-la-villette.html
<carlospc> i've asked here, at kyrad hotel and the have tell me how to get Radisson :D
<jpatrick> remove the "-"
<\sh> http://www.undercovertourist.com/france/paris/hotels/k/ here are all kyriad hotels in paris I think
<goldenear> carlospc: you are very close to the Radisson :)
<carlospc> yes, i just have to take the train to the airport
<carlospc> there, there is a free bus to go to the Radisson hotel
<goldenear> carlospc: how did you go there ?
<goldenear> by airplane ?
<carlospc> yes
<carlospc> i took a plain from Madrid this morning
<goldenear> carlospc: If you want to come here in Paris after puting your stuffs at Raddison, I can meet you :)
<carlospc> thanks a lot for your help, i'm going to the hotel right now
<goldenear> ok
<mjg59> What's the dapper-updates procedure?
<goldenear> I'm staying here
<carlospc> today is going to be difficult, tomorrow after the spec day, i'm sure i will go to paris
<carlospc> see you!
<\sh> carlospc / goldenear: exchange mobile numbers ,)
<goldenear> too late :)
<\sh> mjg59: mdz/kamion approval? and bug report, debdiff...the usual
<goldenear> \sh: if somebody else is in paris and need help or simply want to meet me in a Caf no pb :)
<goldenear> just ask
<\sh> goldenear: we will manage all thatremotely ;)
<goldenear> I know a very nice caf with wifi, if we meet there and somebody has a laptop with a webcam we could broascast the meeting :)
<goldenear> but the technology is not yet advanced enough to share drink remotly :/
<goldenear> I hope this feature will be in edgy+1
<goldenear> lol
<\sh> heh
<\sh> brb 
<mjg59> mdz: Hi - the kernel update has (by fixing one bug) resulted in machines with nsc irda chipsets failing to suspend
<mjg59> That can be worked around in acpi-support
<desrt> mjg59; some weird acpi bugs have snuck into -25 that are causing all hell to break loose?
<mjg59> No
<mjg59> Not that I know of, anyway
<desrt> crimsun was mentioning that there is some grand-screwage
* mjg59 shrugs
<desrt> in any case, i have a few more resume bugs that have popped up since the upgrade
<mjg59> As I said, machines with nsc irda chipsets won't currently suspend
<desrt> one usb-related and one hda-intel related
<desrt> they're not fatal.  they just make resume take a long time
<Whoopie> mjg59: could you point to a bug report? I'm interested in this because I also have a nsc irda chipset.
* mjg59 fixes suspend on the craptop
<siretart> how to I learn if I have an nsc irda chipset?
<Whoopie> siretart: "grep NSC /sys/bus/pnp/devices/*/id" or "grep IBM0071 /sys/bus/pnp/devices/*/id"
<siretart> first doesn't match, 2nd does match
<siretart> thanks Whoopie 
<Whoopie> siretart: then you have  thinkpad?
<siretart> Whoopie: I have an R40
<Whoopie> siretart: could you sponsor upload for #38272?
<siretart> Whoopie: for edgy, sure. for dapper-updates: get permission from ubuntu-release first
<Whoopie> siretart: how do I do this? Who have I to contact?
<siretart> Whoopie: https://launchpad.net/people/ubuntu-release, read: email matt and colin
<Whoopie> siretart: ok, thanks. Can I write that you would sponsor upload if they permit it?
<siretart> Whoopie: I don't think that would change their decision
<Whoopie> ok
<jsgotangco> new player
<highvoltage> jsgotangco: hehe
<\sh> ok..it's working with windows...now it's time to switch back to linux...I can't even use a real irc client on this OS...
<\sh> brb
<TheMuso> Anybody in here from the summit proper can tell me how to use the wifi down stairs that people seem to be using?
<Riddell-awa> TheMuso: we're using wired downstairs in the conference room
<TheMuso> ah ok
<TheMuso> Anyways, won't be there tonight. Better get to bed, after a 28 hour journey. :)
<Riddell-awa> sleep well
<Riddell-awa> 09:00 start
<TheMuso> I know. :)
<TheMuso> What is the story with breakfast btw? Like what time etc?
<\sh> before 9 :)
<\sh> and smoking bof around 8:45 ;)
<TheMuso> heh
<TheMuso> and hope someone has got some ethernet I can borrow, as I didn't bring any. :)
<TheMuso> Anyway guys, cya
<\sh> btw....I know it's a strange question, but has anyone a cd of "warhorse" (1970er progressive rock group)..I'm searching one song named "I (Who have Nothing)" from the "Red Sea" album...
#ubuntu-devel 2007-06-11
<spasticteapot> I've got a somewhat snaggeltoothed Ubuntu problem, and I figure I should bring it up here, since I've tried asking just about everywhere else on Freenode.
<spasticteapot> I've even offered free beer to whoever can help me fix it on the LUG chatroom. (Admittedly, I myself cannot buy said beer, but I can pay for it at least.)
<spasticteapot> Under Ubuntu, as a default, the Gnome applet Network-Monitor has some nifty features relating to wifi - it has the "5 bars" when you're connected, and when you click on it, a drop-down menu appears of various wifi connections. However, after accidentally removing the applet and adding another network-manager applet to my panel, my wifi connection (eth1) is treated as an ethernet connection. Perhaps I could rename eth1 to wlan0
<spasticteapot> ? Or fix the applet?
<spasticteapot> Also, why is IFrename not in Ubuntu?
<wasabi> Believe udev deals with renaming hte interfaces.
<wasabi> Also, sound slike a bug. File it.
<spasticteapot> udev?
<spasticteapot> How do I file it?
<spasticteapot> And, more importantly, how do I FIX it?
<wasabi> https://launchpad.net/malone/+filebug
<wasabi> and I have no idea how to fix it. sounds like a bug.
<spasticteapot> I was told to try this for renaming my wireless card:  ifrename - -i eth1 -n wlan0 < /dev/null
<spasticteapot> How do I do that with udev?
<wasabi> Hurm. I don't think that's related.
<wasabi> Also, this isn't the appropiate place to ask, as the topic states.
<Amaranth> wasabi: actually his probably was he replaced NetworkManager with network-monitor, from what i can tell :)
<wasabi> oh?
<wasabi> Oh yeah I see.
<spasticteapot> Does anyone know where the list of default applets in the dock in Ubuntu is?
<fabbione> morning
<pitti> Good morning
<Burgundavia> hey pitti
<Burgundavia> congrats on getting tribe 1 out
<pygi> morning pitti, Burgundavia 
<pitti> hi Burgundavia 
<pitti> hey pygi
<pitti> thanks
<StevenK> pitti: Do you know anything about packages not registering builds?
<StevenK> pitti: Hi, by the way. :-)
<pitti> StevenK: no, I don't; when was it uploaded?
<StevenK> pitti: There are three; the oldest was uploaded just over 24 hours ago.
<pitti> StevenK: and published?
<StevenK> pitti: All three are published, yes.
<pitti> StevenK: hm, you should ask cprov once he gets online
<pitti> StevenK: can you tell me an example package?
<StevenK> pitti: It appears to be a wider problem with crimsun also just mentioning in -motu
<StevenK> pitti: Take your pick of python-qt4, scim-qtimm or libwibble.
<crimsun> (yes, was asked about ruby-gnome2)
<pitti> at least all buildds are busy
<StevenK> pitti: From what I saw, they *look* to be busy, but they aren't updating the logs that show where the build is up to on LP.
* Hobbsee pokes ShinyPointyStick 
<pitti> StevenK: oh, hmm; can you please drop by #canonical-sysadmin and ask there? they might know something
<StevenK> pitti: About both issues or just the latter?
<pitti> StevenK: they might be related
* Hobbsee demands that at least some form of PointyStick stays on the network.
<superm1> mdke, ping
<mdke> superm1: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
<Hobbsee> yay, contentlessping.pl - the modified version
<superm1> mdke, I wanted to poke about our mailing list, we still haven't heard anything more about it from rt or anything
<superm1> Hobbsee,  rather than contentless pongs version?
<Hobbsee> superm1: sorry?
<superm1> Hobbsee, the one that responds something like "You've sent me a contentless ping and this is a contentless pong"
<superm1> or something to that effect?
<Hobbsee> that's the original contentlessping.pl, iirc
<Hobbsee> You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around. 
<superm1> ah
<Hobbsee> ^ almost that
<mdke> superm1: hi. I'll try chasing by email. What's your mailing list?
<superm1> mdke, ubuntu-mythtv was what we were looking to get setup
<superm1> mdke, do you want the rt # that we had opened up back in april?
<superm1> to include
<mdke> yeah, thanks
<mdke> email me the details
<superm1> okay will do
<superm1> thanks mdke 
<mdke> superm1: got it, thanks
<dholbach> good morning
<Fujitsu> Hi dholbach.
<dholbach> heya Fujitsu
<pygi> morning dholbach 
<dholbach> heya pygi
<pygi> dholbach, wanna try something? :)
<pygi> (if you have time ofcourse ^_^)
<dholbach> what is it?
<pygi> that telepathy ncurses IM client? :)
<cjwatson_> persia: I put rather a lot of work into reducing the number of questions asked by default way back in Warty, as it happens.
<cjwatson> shawarma: I don't think it's written down anywhere. It was one of Mark's mandates right at the start.
<persia> cjwatson: My apologies.  I wasn't following the lists as closely then, and missed the changes.
<shawarma> cjwatson: Alright, thanks. I was considering deviating from it and was hoping the policy's wording or rationale would provide justification for that, but I may have worked around it now.
<cjwatson> persia: (though it's true that the introduction of ubiquity made a big dent)
<persia> cjwatson: That's the one I remember :)
<cjwatson> yeah, it wasn't a new policy then though
<Burgundavia> shawarma: for the server installer, we can treat things a bit differently
<Burgundavia> we are targetting a different audience, one that probably knows a bit more
<shawarma> Burgundavia: That's what I was thinking, too.
<shawarma> Burgundavia: I just need to test this a little bit more. Launchpad says it's a 25 minute build, so it's not that bad.
<Fjodor> Does anyone know if Bug #110585 is caused by something in kernels > 2.6.18 and that's why we hit it?
<ubotu> Launchpad bug 110585 in debian-installer "7.04 Server install fails on Compaq Proliant DL360" [Undecided,Unconfirmed]  https://launchpad.net/bugs/110585
<cjwatson> well, our parted is essentially the same as Debian's
<Fjodor> cjwatson: I think the raid controller driver spits some nasty things in dmesg and that's why we can't see anything on it
<cjwatson> that should be easy to verify by checking the logs from a second console
<cjwatson> parted> (there are differences, but not relevant ones here)
<cjwatson> which basically leaves either udev (seems unlikely, as apparently the device node does exist) or the kernel
<Keybuk> the power management in gutsy is definitely futzed
<cjwatson> Fjodor: you can copy /var/log/syslog to another machine by doing 'anna-install openssh-client-udeb' and then you'll have scp
<Keybuk> laptop usually crashes when AC power is disconnected or reconnnected
<cjwatson> then please attach it to the bug
<Keybuk> and laptop goes to standby when the lid is closed for a while, even though that's marked as "Never" in prefs
<Burgundavia> Keybuk: some of it might be related to the new code for profiling batteries
<Keybuk> Burgundavia: that code and I are not friends; it decided my battery only lasted for 20mins and shut down my computer!
<Fjodor> cjwatson: Actually, the problem is described on the forums (only saw that now). Have a look at http://ubuntuforums.org/showthread.php?t=384319&highlight=dl360 and http://ubuntuforums.org/showthread.php?t=384319&page=2
<Burgundavia> Keybuk: tell me about it
<Burgundavia> anyway, is 2am here, time to sleep
<shawarma> Burgundavia: right, but your battery actually does only last for 20 minutes.. There's a difference.
<shawarma> Burgundavia: :-P
<Keybuk> oh, and something about NM/dchdbdbdbdbdbd/ipw3945 is broken too
<Keybuk> it won't associate with any network until I toggle the hardware switch
<Keybuk> (wonder if this is something to do with HAL gaining knowledge of these)
<fabbione> Keybuk: you are not the only one that reported this hw switch issue with some wireless cards.. IIRC they were mentioning something in the kernel
<Keybuk> could be kernelish, though running dhclient itself just works
<Keybuk> (but then that doesn't check such things)
<pygi> hey Zdra 
<cjwatson> Fjodor: thanks; I've added a pointer to the relevant post to the bug
<Zdra> hello pygi
<pygi> Zdra, have time for trying things? :)
<Zdra> not really right now, maybe this evening ;)
<Zdra> sorry
<pygi> Zdra, evil you :P Oki doki :)
<hunger> Are there freenx debs in ubuntu?
<pitti> hi thekorn_ 
<thekorn_> hi pitti
<pitti> thekorn_: curious, is there an API for deleting attachments in p-lp-bugs now?
<thekorn_> pitti: sorry, not now, you need that as soon as possible, right?
<pitti> thekorn_: before we can enable apport again for gutsy, yes (and to clean up the existing core dumps)
<pitti> thekorn_: is it hard to do? it's just another page scraping/button click, I figure?
<thekorn_> pitti: my problem is, that I'm stilll working on changing the API, I started with other parts
<pitti> thekorn_: ah, I see; well, then rather do it right, and I'll use a temporary hack if I need it before
<thekorn_> pitti: ok cool, thanks
<Fujitsu> pitti: What magical stuff is apport going to do this cycle?
<fabbione> StevenK: i am looking at your sparc buildd hangs....
<pitti> Fujitsu: I finished https://wiki.ubuntu.com/ApportBetterRetracing except for the wine stuff; currently working on https://wiki.ubuntu.com/ApportCrashDuplicates
<pitti> Fujitsu: and we urgently need to do https://wiki.ubuntu.com/CrashReporting
<pitti> Fujitsu: the approved gutsy specs list has some more apport stuff
<Fujitsu> pitti: Looks pretty good; a lot more manageable for triagers.
<pitti> Fujitsu: right, that was the idea
<Fujitsu> I don't like the working around the lack of version tracking in Malone, though. Why doesn't Malone grow that feature like it should have ages ago?
<pitti> Fujitsu: I don't know
<Fujitsu> It's more than a bit annoying
<StevenK> fabbione: Ahhhh, great. Thanks. You got me there for a moment, I couldn't recall what you were refering to. :-)
<fabbione> StevenK: tig builds fine.. i am somewhere in lyx
<StevenK> fabbione: I'm not so sure it's a sparc-only problem, to be honest.
<fabbione> StevenK: i suggest you talk to one of our sysadmins to get a manual build of tig (since it's small)
<StevenK> fabbione: Couldn't we first just requeue it?
<fabbione> i don't think the problem is tig.. it might be that the build exercises some very well hidden bug somewhere
<fabbione> StevenK: yes.. that's a possibility, but if it hangs forever, it means killing a buildd
<fabbione> StevenK: requeue -> manual build -> build test with a different kernel
<fabbione> that's the sequence i would do for testing
<StevenK> fabbione: Surely it also allows us/you to keep a close eye on the requeued build?
<fabbione> me? no.. i don't have access to the buildd.. it needs to be somebody like infinity2 or one of our admins
<fabbione> if it hangs, grab some info... what the hell the machine is doing.. etc..
<jmg> anyone know about acpi here?
<jmg> i managed to boot windows and reenable wireless after gutsy broke it, but i really really want to fix this bug.
<fabbione> StevenK: i am going to finish the lyx build, but it's going fine so far
<pitti> StevenK: btw, buildd congestion should be fixed now
<StevenK> pitti: Yay! What was the problem, in small words?
<pitti> StevenK: <elmo> meh
* StevenK chuckles.
<supervillain> hi, anyone knows what 09_double_text.patch does to slab?
<Hobbsee> supervillain: did the changelog say?
<supervillain> no..
<supervillain> it's just right in there
<supervillain> but it cannot be applied
<supervillain> seems it's for libslab, not slab
<supervillain> I get it, slab and libslab are different package now..
<Hobbsee> try asking the person who's done the last few updates of slab, i guess.
<Hobbsee> pitti: are you on archive duty today?
<pitti> Hobbsee: no, Mithrandir would be, but he's on vac
<Hobbsee> pitti: i'm wondering how to tell who's done a reject
<Hobbsee> or, alternatively, whether b5i2iso is still in the NEW queue
<Hobbsee> (uploaded twice, got one reject ~20 mins ago)
<pitti> http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/new/
<Hobbsee> and i was under the impression that launchpad discarded the old version silently, if it had the same version number.
<pitti> it's there
<Hobbsee> ....
<bhale> https://launchpad.net/ubuntu/gutsy/+queue
* Hobbsee thumps self with a hammer.
<bhale> i like this page better.
<pitti> Hobbsee: no, it'll be in the NEW queue twice
<Hobbsee> pitti: ah right.  cool.  that was the answer to the non-stupid part of the question, then :)
<Hobbsee> thankyou
<pitti> Hobbsee: ISTR cleaning up the NEW duplicates this morning
<Hobbsee> ISTR == i seem to remember?
<Hobbsee> pitti: fair enough.
<pitti> Hobbsee: that's how you got the reject mail
<Hobbsee> yep
<pitti> Hobbsee: so if the versions were exactly identical, that's fine
<Hobbsee> my brain was working along the lines of "so, if i've got a reject, how do i find out what the problem was?"  But as for forgetting to check the NEW queue...i'll blame work for that one.
<Hobbsee> or impending exams
<Hobbsee> versions were identical, yes
<liri> I've migrated to use Ubuntu Dapper LTS from old Debian Sarge and I'm getting errors to compile my code: In function LKb_RETURN OS_MutexInit(LK_MUTEX*): error: union pthread_mutexattr_t has no member named __mutexkind     The makefile is running with: -D_LINUX -D_REENTRANT -march=i586 -I/usr/include -Wall -pipe -DPTHREADS_SUPPORTED -D_UNIX_THREADS_SUPPORTED -O3 -fforce-addr
<liri> and my kernel is 2.6.17-11-generic #2 SMP
<pitti> Hobbsee: ok, so all is fine now
<Hobbsee> pitti: yeah, thanks
<liri> any clues on these libraries? could it be that some functions got deprecated?
<shawarma> liri: If your kernel is 2.6.17, you're not running Sarge nor Dapper.
<ogra> pitti, ltsp-client was split into ltsp-client and ltsp-client-core, the latter will show up in NEW soon, can you wave it through ?
<pitti> ogra: can do; please ping me when you uploaded it
<ogra> just did :)
<pitti> nothing yet, apparently it missed the :10 run
<pitti> in 5 minutes then
<ogra> ah
<ogra> should be 5.0.11
<mvo> racarr: do you have some minutes to help me with https://bugs.launchpad.net/compiz/+bug/119199 ? it seems to be a bug in the gconf plugin of compiz, but I need some hints how to debug it efficiently 
<ubotu> Launchpad bug 119199 in compiz "[gutsy] latest compiz update causes sytem to lockup when enabling compiz" [High,Confirmed]  
<pitti> ogra: still nothing
<ogra> hmm, i got the mail from drescher
<ogra> its on -changes as well
<pitti>   225575 | S- | ltsp                 | 5.0.11               | nine minutes
<pitti> ^ in accepted
<ogra> ah, indeed, its a new binary
<pitti> ogra: oh, you mean there's just a new binary package, no new source
<StevenK> The source isn't NEW, the binaries are.
<StevenK> ogra: Snap.
<pitti> ogra: so, it needs to get built first
<ogra> :)
<pitti> thekorn: hmm, p-lp-bugs doesn't support marking a bug as dup of another one? or is there a trick to it?
<liri> shawarma: true, I was trying it on both dapper and feisty 
<StevenK> liri: 2.6.17 isn't the kernel version from Feisty either.
<pitti> liri: 2.6.17 is the edgy kernel
<liri> shawarma: anyway I solved the problem by using pthread_mutexattr_settype(&MutexAttr, PTHREAD_MUTEX_RECURSIVE_NP);
* liri now wonders if he unintentionally upgraded without noticing :p
<thekorn> pitti: I'm sorry, that's still not supported,
<thekorn> and I don't know odf any trick
<pitti> thekorn: ok, so my preliminary implementation of close_duplicate() will be to just add a comment which points to the master bug
<pitti> thekorn: sorry, yet another question: if I get a list of all bugs with a certain tag, does this traverse through all batch pages or just the first one?
<dholbach> pitti: all of them
<pitti> dholbach: cool, thanks
<hunger> Why does "mount -o remount,rw /usr" no longer work on gutsy?
<hunger> Reports that /usr is already mounted...
<mathiaz> I was going through UbuntuMainInclusionQueue wiki page. I was wondering what is the state of libnss-ldap, libpam-ldap and libpam-mount reports ?
<pitti> mathiaz: it didn't get much attention since noone prodded us for them so far
<mathiaz> It is stated that they should be rewritten first.
<mathiaz> what's wrong with the current reports ?
<pitti> mathiaz: they do not match the template and thus are lacking some information
<mathiaz> pitti: they seem to follow the template.
<cjwatson> they follow the template a little too exactly, IIRC ;-)
<cjwatson> unless I misremember
<ogra> yeah
<ogra> i wanted to rewrite the reports if i need them ... feel free to take them :)
<Hobbsee> twitch.  i should write a couple.
* Hobbsee ponders writing them for the entire kde4.
<ogra> uh
<ogra> Hobbsee, have fun :)
<Hobbsee> ogra: i believe "delegation" is the term that applies.
<pitti> Hobbsee: erk, two KDEs in main? fun
<Hobbsee> ogra: but then again...as for how much of it would be new upstream versions of the same apps...
<ogra> since we cant script them anymore thats a lot of work ....
<pitti> Hobbsee: I'm fine with replacing kdexxx with kde4xxx without an MIR
<pitti> Hobbsee: however, having both in main at the same time is a question that deserves to be discussed at least in the distro team meeting
<hunger> mathiaz: libpam-mount basically works for me, but it lost some functionality in feisty (for encrypted partitions).
<Hobbsee> pitti: you couldnt promote dolphin then, without a MIR, then, i assume?  *g*
<Hobbsee> pitti: yeah, true that
<Hobbsee> pitti: that's a later discussion - including the one about LTS's and such.
<Riddell> no need for kde4 in main any time soon
<Riddell> but a main inclusion review of strigi and clicene-libs would be lovely if pitti is looking to do some
<Hobbsee> morning Riddell 
<mathiaz> I guess that libpam-mount is heavily used in edubuntu.
<pitti> dholbach, thekorn: hmm, so the BugList ctor takes all those attributes, but if I set the status field to 'Needs Info' I still get all bugs rather than just the needsinfo bugs
<pitti> i. e. BugList(Struct(url = 'https://launchpad.net/ubuntu/+source/apport/+bugs', upstream = None, minbug = None, filterbug = None, status = 'Needs Info', importance = '', lastcomment=''))
<dholbach> pitti: can you file a bug with a small test case?
<pitti> oh, this is only done for 'if opt.upstream and opt.sourcepackage:'; hmm
<pitti> I don't want just upstream bugs
<pitti> dholbach: can do
<dholbach> pitti: rock on - thanks a lot
<pitti> dholbach: done; I'll just go ahead and file bugs for the other stuff I need for apport
<dholbach> pitti: thanks a lot
<pitti> dholbach: hm, noone is subscribed to python-launchpad-bugs
<pitti> thekorn: ^ maybe you want to subscribe to that package?
<dholbach> bughelper-dev is subscribed to upstream bugs
<dholbach> I'll make them subscribed for ubuntu packages too
<dholbach> pitti: done
<pitti> cool, thanks
<pitti> dholbach: so you guys probably just missed my three bug reports, but maybe someone looks at the bug page occasionally :)
<dholbach> pitti: will look at them
<afflux> hunger: I suppose it's a spelling mistake that your crypttab contains a reference to /dev/vg0/ub_tmp_c and you create the cryptdevice in /dev/vg0-ub_tmp_c? (see your latest cryptsetup bug)
<hunger> afflux: That does not matter. both are a symlink to the same /dev/dm-XX
<afflux> eh. does dmsetup support mapping a mapped device?
<hunger> afflux: I have 7 crypted partitions on that VG, all using the same syntax to address it.
<afflux> ah. okay.
<hunger> afflux: The other 6 are luks ones and work fine.
<afflux> do you get any error messages from cryptsetup?
<hunger> afflux: the cryptdisks init script fails... that's all.
<afflux> cool. :/
<ogra> pitti, ltsp-client-core should be there now
<ogra> (at least it built on all arches)
<wasabi> Keybuk: you once said this: "Any filesystem that processes file operations out of order is BUGGY!"   In regards to XFS. Do you still consider that true?
<pitti> ogra: sparc build is still missing; also, this has some lintian warnings/errors
<ogra> oh ?
<mikmorg>  /where mdomsch
<ogra> pitti, ?
<ogra> ogra@laptop:~/devel$ lintian -I ltsp_5.0.11_source.changes
<ogra> W: ltsp source: changelog-should-mention-nmu
<ogra> W: ltsp source: source-nmu-has-incorrect-version-number 5.0.11
<pitti> ogra: check the binaries :)
* ogra checks
<ogra> gah, pbuilder outdated ... that will take a moment
<Keybuk> wasabi: I still think it's stupid for a filesystem to do, yes
<wasabi> Why? Doesn't ZFS do the same thing?
<Keybuk> wasabi: operations on a given file should be processed in sequence
<wasabi> On a given file, sure, but on two different files?
<wasabi> Oh I see what you're saying.
<Keybuk> two different files - who cares
<wasabi> I think I finally realized where I was hung up.
<ogra> pitti, hrm, it needs the xfonts-base dep ...
<wasabi> The conversation was about ... XFS not working right during crashes of update-alternatives because it doesn't flush the file before proceeding
<Keybuk> right
<pitti> ogra: oh, that might be unjustified; I was more concerned about the dependencies/debconf stuff
<wasabi> trying to reparse it.
<Keybuk> what XFS does is process a rename() call on a given file before all queued write()s on that file have been processed
<Keybuk> so you do
<Keybuk> open (file, O_RDWR)
<Keybuk> write (...)
<Keybuk> write (...)
<Keybuk> close (...)
<Keybuk> rename (...)
<Keybuk> and you end up with something on disk that isn't fully written
<wasabi> So the writes don't go through, but the rename does.
<ogra> pitti, right, inputattach is a bug
<Keybuk> yeah
<wasabi> But still, shouldn't you be forced to fsync the file if you want to be sure that the contents are on disk, irregardless of order of operations?
<Keybuk> I don't think so
<wasabi> Does a rename guarentee an implicite sync?
<pitti> ogra: nothing too serious, if you fix them in the next version, that's fine
<wasabi> Who says that?
<ogra> pitti, the debconf stuff must come from a debian merge, we dont use debcof in ltsp-server ... checking where that comes from
<Keybuk> I think that certain operations should be guaranteed
<pitti> ogra: I just want to wait for sparc
<Keybuk> nobody says that
<ogra> pitti, ok
<Keybuk> it's just the way everything behaved until XFS came along :p
<wasabi> Heh.
<ogra> i have a 0.12 here anyway already, i'll add the fixes
<wasabi> But still, an app that DOESN"T rename, would still have to fsync before moving on.
<Keybuk> theoretically that app doesn't care whether it's on the disk or not
<wasabi> Depending on the app, it might.
<Keybuk> the rename() case is special, since the app is clearly trying to do something atomic
<wasabi> u-a seems to be an appropiate situation for that. Since it is basically part of the dpkg transaction.
<wasabi> dpkg can't consider the package really completely installed until it's sure all the files are commited.
<wasabi> If ti does, then you're talking about corrupt/missing metadata between files (dpkg's database and the installed files themselves)
<Keybuk> actually, fsync() doesn't guarantee that either
<Keybuk> it just guarantees that the kernel filesystem is in sync
<wasabi> It guarentees as much as the kernel can know.
<Keybuk> it's an interesting point
<wasabi> Anyways, it seems wrong that a crash after dpkg says a package is installed could result in corrupt files being installed because they weren't flushed.
<wasabi> At least, it seems as if we're not doing what we can do about it, regardless of hardware caches.
<Keybuk> a crash?
<wasabi> power failure.
<Keybuk> power failure has the same problem though
<Keybuk> because of the hardware
<wasabi> Yes, but sme people can guarentee the hardware does not cache.
<wasabi> For good reason they buy hardware like that.
<Keybuk> dpkg could say the status is installed, because that reached the hardware, but the files themselves might not have
<wasabi> Or, they can guarentee the hardware is battery backed.
<iwj> IMO all of these cases are bugs in the filesystem.
<wasabi> If their software is undermining that.
<Keybuk> wasabi: if they can guarantee that, they can guarantee the same things from the filesystem, no?
<wasabi> Hmm. Thinkging. One sec. ;0
<iwj> You use fsync if you mean `this data needs to hit the disk because I am about to promise someone else that we're not going to forget it'.
<iwj> That's quite different from the general requirement of the filesystem not to fuck up.
<wasabi> No... because we're still talking about, two different files.
<iwj> Saying `you must fsync if you want the fs not to fuck up' will just lead to every application having to fsync which is obviously daft.
<Keybuk> wasabi: if you can guarantee that writes always reach the hardware ...
<wasabi> iwj: Never said that.
<Keybuk> wasabi: ... then you can guarantee that they always reach the filesystem ...
<wasabi> And how can you do that?
<Keybuk> "sync"
<wasabi> u-a doesn't sync it though.
<Keybuk> reaching the filesystem is intrinsically uninteresting, except for the case of file handover
<wasabi> You want me to manually type sink between running u-a?
<Keybuk> no, I mean mount the filesystem with "sync" as the option!
<wasabi> Oh. Hah.
<wasabi> Do you really consider taht the solution?
<Keybuk> power outage => you care about writes reaching the hardware
<Keybuk> which means that you need them to reach the filesystem *and* hardware
<wasabi> Destroy all performance improvements of your hardware and file system when there are other appropiate solutions?
<Keybuk> since we can only guarantee the later in special cases where the user has made attempt to secure that, it is not unreasonable to expect them to make attempts to secure the same for the intermediate filesystem
<wasabi> If you want to ensure a file is written, you call fsync. That is the convention, no?
<Keybuk> no
<wasabi> That exists for a reason, no?
<iwj> I think it's a bug if after a power outage the filesystem has left the disk in a state that doesn't correspond to any of the states which would have been visible to a user process before the crash.
<Keybuk> if you want to ensure that the file is available for other processes to read, you call fsync()
<iwj> Keybuk: What ?
<Keybuk> it does not guarantee that it is written
<wasabi> Eh?
<iwj> Other processes are supposed to see the file straight away regardless of any fsync.
<Keybuk> iwj: then what's the XFS bug?
<mjg59> Keybuk: It guarantees it's hit disk. It doesn't guarantee it's hit the filesystem.
<iwj> The XFS bug ?  You mean the one where you get a file full of zeroes ?
<Keybuk> there's a write()/close()/rename() bug with XFS
<wasabi> Keybuk: It happens when there is a power failure after writing two files and renaming.
<Keybuk> due to a missing fsync()
<wasabi> Because nobody calls fsync.
<iwj> Err, earlier you said ZFS.
<wasabi> write(); write(); rename(); crash.
<Keybuk> ok, well clearly I'm even more confused about all of this than I thought :-)
<iwj> Oh, no, I misread.
* Keybuk bows out of the discussion with a "if you have a patch for any software I've written, mail it to me" disclaimer
<wasabi> Heh.
<wasabi> I just wanted to question what you said in the bug report a year ago... because I find it fundamentally contrary to everything I've been taught. :0
<Keybuk> wasabi: I now don't understand why this doesn't work on XFS
<iwj> wasabi: It is my view that dpkg does the right thing and if the filesystem causes what dpkg does not to work properly (including in the case of a crash during package installation) then that's a bug in the filesystem.
<wasabi> Which is that fsync is to be used to guarentee that at a given point in time something has or has not been commited to the best of the knoweldge of the kernel 
<wasabi> Keybuk: u-a writes a file, then renames the old file to the new, but nothing ever calls fsync to ensure the first write happend.
<iwj> Keybuk: There are bugs in many journalling filesystems which have a tendency to write out the metadata to disk before the data.  The result is that if you crash at an unfortunate moment, the file you renamed over the top of the old data turns out to contain zeroes (or even garbage).
<wasabi> But the renames DOES go through.
<Keybuk> wasabi: but why does that matter?
<wasabi> So you have a properly named file pointing at invalid data.
<Keybuk> any application reading the file would get it from the cache, no?
<iwj> Keybuk: No, after a crash.
<Keybuk> (assuming no intermediate power outage)
<Keybuk> right
<wasabi> We're talking about power outages.
<Keybuk> so that's just a bug in the filesystem
<wasabi> Haha.
<Keybuk> stupid filesystem, etc.
<wasabi> Why do you think that? That's what boggles my mind.
<Keybuk> application did a perfectly reasonable set of syscalls
<Keybuk> write(), write(), close(), rename()
<Keybuk> it's up to the filesystem to ensure record of those aren't lost
<Keybuk> and record them in the journal
<mjg59> Why would you then expect the data to be on disk?
<mjg59> We don't journal data
<mjg59> Because otherwise performance is dreadful
<iwj> mjg59: We don't care whether the data are on disk or not.
<wasabi> Keybuk: The thing is dpkg moves on, and writes in it's status file that the installation is done.
<Keybuk> mjg59: the alternative is to fsync() everything on close though, no?
<mjg59> Keybuk: If you want to guarantee that something is on disk, yes
<wasabi> Keybuk: So when recovering from the crash, dpkg says it's "done".
<iwj> What we care about is that after a crash (or other problem) _either_ the situation is as was before, or as it was after.
<wasabi> But in realitity, a few files are corrupt.
<iwj> Ie, either the writes should have taken effect or the rename shouldn't.
<Keybuk> mjg59: in what circumstances would I want to guarantee that something is on disk?
<wasabi> Before dpkg registers that it's done, it should fsync the files it just modified.
<wasabi> That's common transactional programming.
<iwj> No, fsync is not for making transactions.
<Keybuk> wasabi: so we should fsync() everything?
<Keybuk> why don't we patch the kernel to fsync() on close() ?
<Keybuk> (I'm not being annoying, I seriously do not understand)
<wasabi> No, not everything. Only things that form some sort of transactional isolation.
<mjg59> Keybuk: Because that would also suck
<Keybuk> why is this a special case?
<wasabi> a) do file modifications b) record that we did file modifications
<pitti> Keybuk: that has acttually been proposed
<Keybuk> wasabi: so make close fsync?
<wasabi> Do you not think something should happen before b?
<mjg59> iwj: Is that assumption codified anywhere?
<pitti> Keybuk: http://www.ussg.iu.edu/hypermail/linux/kernel/0512.3/0050.html
<wasabi> Keybuk: No, again, only for things which are transactional. dpkg is that.
<Keybuk> wasabi: why is dpkg transactional?
<pitti> Keybuk: that was for an entirely different context, though (more sane handling of removable devices)
<mjg59> iwj: If you're journalling metadata, it's unsurprising that a crash will result in your metadata/data being out of sync
<iwj> mjg59: It's an assumption inherent in the way that EVERY PROPER PROGRAM SINCE THE DAWN OF TIME HAS UPDATED A FILE.
<wasabi> Keybuk: It's a good question, and the only answer I have is because that's how people expect it to be. It tells the user "yes, you're install is done."
<iwj> The _standard official approach_ is open(".tmp") write rename
<Keybuk> wasabi: so should all instances of write()/close()/rename() be transactional?
<Keybuk> if so, maybe rename needs to sync the files?
<iwj> You use fsync if you want to synchronise with some real-world thing outside the computer.
<mjg59> No, nothing should implicitly sync the files
<wasabi> Maybe it does. Except I don't think that guarentee is codified anywhere is it
<iwj> Like if you're receiving mail.
<wasabi> iwj: You mean like a user? heh
<wasabi> APPLICATION USAGE    The fsync() function should be used by programs which require modifications to a file to be completed before continuing; for example, a program which contains a simple transaction facility might use it to ensure that all modifications to a file or files caused by a transaction are recorded.
<Keybuk> except it doesn't
<Keybuk> it just ensures that the kernel has finished with it, and it's heading somewhere near the hardware
<wasabi> yes yes yes, we know, hardware will subvert it Sometime.
<mjg59> Keybuk: No, fsync() guarantees that it's hit hardware 
<mjg59> Whether it's hit platters may be another issue
<Keybuk> NOTES
<Keybuk>        If the underlying hard disk has write caching enabled,  then  the  data
<Keybuk>        may  not  really  be  on  permanent  storage when fsync() / fdatasync()
<Keybuk>        return.
<Keybuk> right, hit platters
<wasabi> Yes, we know that. Hardware will subvert it.
<Keybuk> so we're all doomed anyway
<wasabi> No, we're not.
<Keybuk> let's go shopping instead
<wasabi> None of my hardware does that.
<wasabi> Because I have battery backed write caches. ;0
<Keybuk> wasabi: none of my filesystems fuck up either ;P
<Keybuk> because I use sensible ones
<wasabi> Heh.
<iwj> Keybuk: Nonsense.  There is a right answer here and it's that fsync should guarantee that everything relevant to that file up to that point will survive future crashes etc.
<iwj> And if it fails to guarantee that it's a bug.  Consumer hardware in buggy shocker.
<wasabi> iwj: "as best it can"
<iwj> But that's not relevant.
<iwj> wasabi: No, _guarantee_.  But if the hardware is buggy then the machine is buggy.  But this is all irrelevant.
<wasabi> Sure. But we fail on non-buggy hardware. The only question is whether the FS is buggy.
<iwj> Because dpkg doesn't need to know that the changes it makes with write have it the disk before it calls rename.
<wasabi> dpkg should know that before it records in it's status file that they did.
<iwj> It doesn't mind at all if the machine crashes and everything is as if the writes and rename never happened.
<wasabi> So that upon resuming the machine, the user can identify which packages might be in an inconsistant state.
<iwj> No, because that's all internal to the machine.
<iwj> dpkg doesn't mind if the whole machine is rewound.
<wasabi> Oh, sure. But the thing is dpkg is never marking what needs to happen in what order. =/
<iwj> And indeed allowing that possibility makes it possible for dpkg to run much faster because it doesn't need to constantly stop and prat about with fsync.
<wasabi> So it can't be rewound. It just gets scrambled.
<iwj> wasabi: Yes it is, it makes system calls in that order.
<wasabi> And all file operations should happen in order, always?
<iwj> A filesystem is buggy if any sequence of system calls results in scrambled data.
<wasabi> Even for independent files?
<iwj> wasabi: Yes.  That's the whole point of the unix file api.
<wasabi> So why are we mounting things async?
<wasabi> In fact who invented that?
<iwj> I don't know.  The fs authors seem to have made it the default because it goes faster.
<iwj> Who cares if it breaks, eh ?
<mjg59> We mount thinks async because the alternative is stupid
<wasabi> Double infact, how does dpkg know if it's using two file systems?
<wasabi> And how does it know they are both in order? heh
<iwj> mjg59: We should write data and metadata together rather than deliberately writing one and not the other.
<iwj> wasabi: 
<mjg59> iwj: ext3 optionally has that behaviour, but it kills performance
<iwj> If you like, mount everything sync and see how long your installs take.
<wasabi> I think at some point we introduced "points of atomicity", and that's worked great. Except when people forget to mark their points.
<iwj> wasabi: That's not what fsync ever did and furthermore what you're doing is not introducing "points of atomicity" but removing them.
<Keybuk> wasabi: I suspect it's more that people forget to tell anybody they introduced the requirement to mark their points in the first place, and what kinds of places they should
<mjg59> iwj: I think an argument that does make sense is that metadata in the journal should be flagged as to whether it refers to changes that haven't hit disk
<iwj> mjg59: I don't care how it's implemented.  I just care that after a crash I see a filesystem that looks vaguely like something reasonable.
<Keybuk> I do tend to agree with Ian here
<Keybuk> if a filesystem has been told to do A, B and then C
<mjg59> Well, the argument is that it's reasonable (ie, consistent)
<Keybuk> and does C, without even recording that A and B haven't happened and need to, then that's a filesystem issue
<wasabi> Alright. I agree now. Ya'll win.
<mjg59> I suspect the XFS authors have different ideas about what "reasonable" means
<Keybuk> it's reasonable for it to process things out of order *if* there's a filesystem transaction API
<iwj> Keybuk: Right.  And you'd have to ask applications to turn it on explicitly.
<Keybuk> which guarantees that all or none of the transaction hits disk
<iwj> And applications which didn't say "I'm using the new transaction api" would get the original semantics.
<iwj> Or even just an explicit sequence points API.  I don't have objections to that.
<Keybuk> for example
<Keybuk> how do I fsync() a rename? :p
<iwj> I do object to changing the meaning of the existing calls so as to break every previously-reliable program.
<Keybuk> or an unlink? 
<iwj> But I have to go and have dinner.
<iwj> Keybuk: Keep up the good fight :-).
<wasabi> iwj: thanks for setting me straight. :0
<iwj> Any time :-).
<desrt> Keybuk; sup?
<Keybuk> desrt: hey
<desrt> wasabi; word
<wasabi> desrt: sentence
<desrt> iwj; goodday :)
<desrt> mjg59; if my ata_piix module has usecount 4 and my ahci module has usecount 0 does that mean that linux is ignoring my bios setting of "ahci mode"?
<mjg59> Yes
<mjg59> dmesg?
<desrt> hold on a sec.
<desrt> i can't do too much for you right now since it's my home machine and i'm at work, but i can ssh
<desrt> what part of dmesg do you need?
<mjg59> /var/log/dmesg
<desrt> oh.  whole thing.  k :)
<desrt> http://desrt.mcmaster.ca/random/dmesg
<Hobbsee> hiya desrt 
<desrt> Hobbsee; hello.  what's up?
<Hobbsee> desrt: i'm pondering uploading to main.
<desrt> if you're looking for something to do, acpi-support could use a NMU
<Hobbsee> i wasnt....neither can i upload to debian.
<desrt> i mean ubuntu's :)
<geser> are new source packages still pulled regularly from Debian?
<Hobbsee> desrt: that means i'd have to understand what's going on with it
<desrt> Hobbsee; it was a joke :)
<Hobbsee> :P
<mjg59> desrt: Can I have an lspci?
<desrt> mjg59; of course
<desrt> http://desrt.mcmaster.ca/random/lspci-for-mjg59
* Hobbsee takes mjg59
* Hobbsee takes mjg59's lspci, and raises him a syslog
<Hobbsee> (damn the ' and enter being so close)
<thekorn> pitti:  I just added a patch to fix bug 119872
<ubotu> Launchpad bug 119872 in python-launchpad-bugs "BugList's filters do not work" [Undecided,Fix committed]  https://launchpad.net/bugs/119872
<pitti> thekorn: ooh, rock
<mjg59> desrt: Your BIOS isn't setting your chipset to AHCI mode
<desrt> mjg59; silly bios.
<desrt> mjg59; it has an option for it and i've selected AHCI
<mjg59> Well, your jmicron controller is set to AHCI
<mjg59> Maybe it's only doing it for that
<cjwatson> geser: yes, up to Debian import freeze == 21 June (GutsyReleaseSchedule)
<desrt> hmm.  that seems likely
<desrt> ich8 is ahci capable with a few bits flipped, i suppose?
<mjg59> Yes
<cjwatson> though apparently nobody's done it for a few days, so I will
<mjg59> Try the patch I posted
<desrt> (see your blog for the appropriate patch)
<desrt> nod.
* desrt was hoping to dodge kernelpain until gutsy was a bit further along, but oh well :)
* desrt jumps in
* pitti commits the last piece of code to make initial apport-crash-duplicates work \o/
<desrt> (having a 100%-lrm-free machine reduces the pain quite a lot...)
<desrt> mjg59; a rather direct indication of workingness of ahci vs. piix mode is that in ahci hotswap will work and in piix it will not?
* desrt will try various plugs on the board to see if he finds the jmicron one first...
<mjg59> desrt: Just check dmesg and see if your drives are coming up on ata_piix or not
* desrt is starting to loathe bios
<desrt> (again)
<mjg59> Or just make sure the drives are on the jmicron
* ogra grumbles about gcc holding up the world on sparc ...
<cjwatson>   * Handle architectures in all dependency fields in debian/control,
<cjwatson>     even those of binary packages. Closes: #252657, #324741, #347819
<cjwatson> whoa, I never knew that had been done in dpkg
<thom> oh, nice
<thom> no more arch: any insanity just to get platform deps
<cjwatson> well
<cjwatson> no, it's done in dpkg-gencontrol
<cjwatson> so only applies to architecture: any
<nomeata> hi. Has anyone tried to use upstart initscripts to create standard sys-V-init-script from them?
<nomeata> Keybuk: Hi. Are you coming to debconf?
<Keybuk> nomeata: no, why?
<nomeata> Keybuk: Id like to abuse the upstart init script file format :-)
<nomeata> Keybuk: I just wrote a mail to upstart-devel
<Keybuk> nomeata: the main difference between upstart and Debian's init script format is what will bite you
<Keybuk> upstart you specify the daemon to exec, that remains in the foreground
<Keybuk> Debian init scripts run the daemon in the background, then return, with some other way of finding the daemon again
<nomeata> That is true.
<nomeata> Maybe the generated init script could still use a foreground daemon, and handle it through start-stop-daemon
<Keybuk> the other problem is that the "when the init script is run" stuff varies so wildly, there's no way to make it common
<Keybuk> e.g. Debian uses numbered runlevels, with numbered sequences
<Keybuk> others use comments in the generated init script to seed those
<Keybuk> other things like initNG use "dependencies"
<Keybuk> Upstart uses eventgs
<Keybuk> etc.
<nomeata> But dont 90% of the daemon have non-specific requirement?
<nomeata> ok, the number is just a rough guess.
<nomeata> And the solution is not intended to work for every single daemon, just those where init scripts are just repetition.
<Keybuk> no idea
<nomeata> The big plus would be of course that those daemons would suddently have a real upstart script shipped.
<Keybuk> in theory, anyway, in "start" you'd the pre-start script, fork the daemon, then run the post-start script
<Keybuk> and in "stop" would run the pre-stop script, kill the daemon, then run the post-stop script
<nomeata> right
<Keybuk> and then just shim for things like env/umask/chdir/etc.
<nomeata> tomorrow well have a BOF on the idea. Do you want to be kept in the loop? 
* nomeata got go to. talk to you later, and thanks for the input.
<pygi> Zdra, poke
<TheMuso> doko: Just replied to your email with the state of espeak. I'm happy for you to do the merge, but I also don't mind doing it, with your work as a basis. I meant to push my changes to Debian very soon anyway, as I am working with him on other projects.
<doko> TheMuso: cool, I wouldn't mind if you go ahead with the upload
<TheMuso> doko: Ok. I'll get to it later today. Thanks again
<doko> not that urgent ...
<TheMuso> Yep I know.
<TheMuso> I'm assuming portaudio19 has made its way to main by now?
<crimsun> portaudio19 | 19+svn20070125-1ubuntu1 | gutsy/universe | source
<TheMuso> crimsun: Yeah I saw that yesterday, which is why I am wondering, as I saw arequest to move it to main the other day...
<TheMuso> Haven't had time yet to update my gutsy chroot and look myself.
<crimsun> ogra: do you mind if I handle alsa-plugins (after alsa-lib 1.0.14-1ubuntu1 builds)?
<geser> TheMuso: have you tried rmadison from devscripts? (rmadison -u ubuntu portaudio19)
#ubuntu-devel 2007-06-12
<pygi> hey mdz_ 
<mdz_> hi
<LordLimecat> is there a known bug whereby if ubuntu crashes, theres a chance syslog will have a line filled with "^@" on it, causing gnome-system-log to crash?
<LordLimecat> its happened twice, and removing the offendign line (thru nano, since gedit is also unable to read the file) seems to fix the issue
<LordLimecat> if its of any help, its writing 1745 or 1746 bytes worth of 0x0s to the following logs: /var/log/messages    /var/log/syslog     /var/log/kern.log
<mdz> LordLimecat: I have never seen such behaviour; it could be caused by filesystem corruption
<LordLimecat> yea, well, its possibly because upon returning to comp (both times) it wasnt responding, so i tried alt+sysrq+x, no response....
<LordLimecat> so i did alt+sysrq+b
<LordLimecat> .,....and rebooted
<elmo> it's fairly common on a system crash, unless you use data=journal
<elmo> and if you use xfs, it's basically a given
<LordLimecat> but the exact same thing, same data written, same quantity
<LordLimecat> 1745 bytes worth of 0s
<LordLimecat> cant be random
<LordLimecat> ...can it?
<elmo> (it == the 0x0's in files that are open and being written to at time of crash)
<LordLimecat> well, there was data written RIGHT before system went down, after the 0s--
<LordLimecat> noting that a reboot was requested
<mjg59> Which filesystem do you use?
<LordLimecat> ext3
<LordLimecat> i MAY have changed its writeback
<LordLimecat> possibly
<LordLimecat> how do i check quickly
<mjg59> Eh. Data is certainly not guaranteed to be there if you don't reboot cleanly
<mjg59> Before doing sysrq+b, do sysrq+s
<LordLimecat> couldnt :( couldnt get to terminal
<LordLimecat> oh, i generally do that
<LordLimecat> ...but didnt this time
<LordLimecat> is there a way to...like..bump it to init 1 with a system call?
<kylem> the problem is likely that the oops output you see is being written
<LordLimecat> so this isnt really a bug?
<kylem> and since it's the same oops, will always be the same length...
<kylem> it's a bug that gnome-system-log is crashing.
<LordLimecat> lol, yea, it was a PITA to track it down
<LordLimecat> luckily, gedit also refuses to open the files
<LordLimecat> makes it easy to find
<LordLimecat> ...is it a bad idea to make a script that finds and removes 1745 0s from those 3  logs?
<LordLimecat> could that cause any damage?
<thully> hi - I'm a MacBook user and wondered who I would get in contact with about getting some of the bugs relating to it fixed in Gutsy...
<jml> thully: your best starting place is searching Launchpad's Ubuntu section for the specific bugs you've encountered.
<thully> I've looked at the bugs, and responded, and heard nothing in months
<thully> One bug is 92635 (MacBook doesn't sleep) - I've got a temporary kernel fix,  and it seems like something could be done for Gutsy
<superm1> BenC, ping
<thully> does anyone know how I can get in touch with the Ubuntu kernel/laptop team about getting the issues with macBooks - many of which I know the issue and have some ideas about solutions - fixed in Gutsy
<thully> the bugs have all been reported long ago
<mneptok> thully: LP is the mechanism by whcih such things are done
<mneptok> *which
<thully> I haven't managed to get any response via that channel...
<mneptok> bug #?
<persia> thully: If you have a solution, try attaching a patch against the ubuntu git repository to the bug, and adding the patch tag.
<thully> well, the solution is kind of hackish at this point 
<thully> 92635 is the bug # - me and some others have used the mentioned workaround patch to get suspend on first-generation MacBooks
<thully> For some reason, 1g MacBooks are funky with their suspend...
<thully> I also was going to comment on - but I can't find the bug # off hand, though it has been reported - the absolutely craptastic state of the appletouch driver
<mneptok> that's not a bug, though
<mneptok> that's a feature request
<thully> it is a bug, as it is SO craptastic that you can't change the mouse pointer acceleration - something you can do even with dumb old usbhid
<mneptok> upstream has acknowledged this as a bug?
<thully> I haven't contacted upstream - all I know is that appletouch as shipped w/ Feisty doesn't let you change pointer acceleration
<thully> right now, I'm actually running in VMware as I got sick of the issues - figure I may download gutsy and install on the bare metal tonight to check on these issues
<mneptok> does it have the cntrols to do so, but just doesn't do it?
<thully> yes - if you go into GNOME's mouse control panel - or Xorg.conf - and change the acceleration, nothing happens
<mneptok> are you on the Macbook now?
<thully> yes - I don't have a raw install right now, though, as I just got it back from repairs and it was wiped by Apple
<thully> I could install Feisty now, or I could get a Gutsy ISO (would have to be later - am on satellite with strict bandwidth caps) and try that
<thully> BTW, just reported the trackpad issue - 119964
<mneptok> sudo rmmod appletouch && sudo modprobe appletouch
<mneptok> that may clear up some Appletouch woes. try it next time you're in Ubuntu.
<thully> I could try the Feisty live CD in a few minutes if that would help...
<mneptok> up to you. i'm not a maintainer for any of that stuff. ;)
<thully> OK
<mneptok> just something to try.
<mneptok> and if you narrow it to the kernel module, you're making progress.
<thully> OK - I figure I can find out some from the Feisty live CD - I'll get the Gutsy one if it seems I may be able to learn more that way
<johanbr> thully: It's possible you'll have more luck in #ubuntu-kernel .
<thully> OK - wondered if there was a "kernel" channel...
<thully> Also, on a (somewhat-unrelated) note, is VMware considered a supported configuration for running/testing Ubuntu in general?  I'm using it ATM because my hardware works better and I can switch OSes fast (still use OS X a lot - I like both OSes)
<thully> obviously not for testing issues w/ MacBook hardware (like the aforementioned appletouch issues) but just in general
<johanbr> thully: I don't know. My guess is that it would depend on the sort of bug you encounter. For higher-level bugs I'd think it'd be okay, but as you say not for kernel/hardware things.
<thully> well, it does seem like kernel/hardware issues would be valid - though my hardware would basically be a VMware VM instead of the actual machine I'm running on
<mneptok> thully: the kernel speaks to hardware. VMWare is not hardware.
<mneptok> thully: an abstraction layer between the kernel and metal is nothing but a DIStraction layer when reporting bugs.
<johanbr> Right. My guess would be that the kernel developers might just say "vmware is closed source, we have no way of knowing which bugs the virtualization introduces". If you really want to know, you should ask them, though.
<mneptok> VMWare cannot keep accurate time. even with ntpd installed.
<mneptok> let that inform your thinking about VMWare's relationship to hardware.
<johanbr> If you really want to view vmware as hardware, it's not on the list of supported architectures, in any case.
<mneptok> VMWare *is* hardware when it comes to its interactions with the kernel.
<thully> I see, I knew that would come up.  
<mneptok> (gross oversimplification, but the sentiment is valid)
<thully> I wouldn't be filing many kernel bugs in any case - most of them I'd test would be bare metal bugs (like appletouch)
<mneptok> thully: VMWare can't keep its clock straight. you want to report issues with input device timings?
<mneptok> thully: Appletouch is hardware. the kernel talks to hardware. VMWare stands between the kernel and hardware ....
<thully> appletouch isn't in vmware - those were two totally separate issues
<thully> sorry for confusing everyone
<thully> I just meant in general if I were to use VMware at some point and file bugs - not using vmware to test macbook hardware bugs
<mneptok> eh, if everyone apologised every time i didn't understand coherent English, IRC would be nothing but "sorry, mnep"
<mneptok> just be sure to mention VMWare's place in the recipe when appropriate. :)
<thully> I realized that it was pretty much like its own hardware
<thully> OK - thanks - figure I'll reboot onto bare metal Ubuntu and try some things with appletouch
<desrt> http://mcmaster.facebook.com/group.php?gid=2207033242
<thully> for those of you who were on when I was discussing my appletouch problem - I've discovered that an rmmod and modprobe of the module fixes the issue until X is restarted
<thully> after X is restarted, you have to do it again if you want proper acceleration
<fabbione> morning guys
<pygi> morning fabbione 
* StevenK waves to fabbione
<fabbione> hi pygi 
<fabbione> StevenK: you got mail
<StevenK> fabbione: I'm not not so sure that tig and lyx are too blame.
<fabbione> nope.. they are not
<fabbione> you will have to ask sysadmin help here to see what's happening in the buildds
<fabbione> and unfortunately i can't help you there
* StevenK nods.
<StevenK> I saw this problem a few days ago, with all buildds doing the same thing, spinning with no logs and not changing state. I'm suspecting a LP bug.
<fabbione> oh well just ask for rescheduling
<fabbione> it might have been the congestion thingy on LP
<fabbione> anyway you know they build
<StevenK> Okay, so bug $BUILDD_PERSON for a requeue of lyx and tig on sparc. That's fine.
<Hobbsee> morning all!
<desrt> word.
<Hobbsee> hrm?
<pygi> heya Hobbsee :)
* desrt is desperately trying to get from manchester to nijmegen without spending a fortune
<Hobbsee> good luck with that.  walk? swim?
<desrt> i wanted to take the train, but that's just ridiculous.
<desrt> and i'll have some luggage.... so swimming is probably a bad idea.
<Hobbsee> awww
* pygi eats Hobbsee 
* Hobbsee is not worth eating.
<Hobbsee> pygi: mpt is probably better to eat.
<pygi> Hobbsee, but no!
<Hobbsee> pygi: why no?
<pygi> no idea, just because =)
* Hobbsee is too thin to eat.
* Hobbsee has very little body fat, therefore would nto roast up well
<pygi> your point? :P
<Hobbsee> unless you're into bones, of course.
<pygi> lol
* Hobbsee glances over in Mithrandir's direction
* Hobbsee hides from Mithrandir 
<pygi> I'll be back
<pygi> math exam
<Hobbsee> pygi: have fun.  make up lots of rubbish
<mpt> Hobbsee, are you calling me fat?
<Hobbsee> mpt: no, i'm calling you bigger than me.
<Hobbsee> mpt: which, seeing as racarr was the only one smaller than me, isnt hard.
<Hobbsee> (at UDS)
<Hobbsee> there's a difference.
<fabbione> on the node.. it's not difficult to be bigger than Hobbsee :)))
<fabbione> the problem is if you are more thin than she is... you might consider a doctor appointment ;)
<StevenK> Or a career as a supermodel.
<Hobbsee> haha
* StevenK hides.
<Hobbsee> StevenK: i'm not pretty enough to do that :P
<mpt> I wasn't at UDS, but I'm pretty small
<fabbione> mpt: still slightly larger than Hobbsee :)
<fabbione> mpt: i met both of you...
<mpt> We shall find out for sure at the next UDS :-)
<fabbione> mpt: you could probably handle my weight on you...
<fabbione> she would crack :P
<Hobbsee> mpt: not in boston
* mpt flees
<mpt> fabbione, not a chance
<fabbione> ahha
<Hobbsee> mpt: i'm thin enough that a person like seveas could easily break my wrist, if he tried hard enough
<fabbione> mpt: i lost since last we met :)
<mpt> Fatherhood is hard work?
<fabbione> mpt: and another bunch of reasons
<mpt> ah
<fabbione> mpt: remember i haven't been feeling very well recently.. so that adds up
<shawarma> I'm looking at the squid merge. Apart from the stuff that's mentioned in the last changelog, the patch that MoM has created also contains a bunch of translation releated stuff. Now, since the last patch (the one between our previous version and the debian version on which it's based) did not contain any of that stuff, I don't quite get where it came from? It may just be because I have absolutely no idea how all our translation stuff is handled.
<Hobbsee> shawarma: i believe that launchpad automaticlaly updates the translations on build, or something.  it's thru launchpad, regardless.
<shawarma> Hobbsee: But that does not interfere with source packages in any way, I suppose?
<Hobbsee> i'm not sure
<shawarma> I don't see how it could since they're signed and all that.
<Burgundavia> shawarma: talk to pitti, he set up the language pack stuff
<shawarma> Burgundavia: Right.
<shawarma> Burgundavia: How's it going? New job yet?
<Burgundavia> not yet
<shawarma> Burgundavia: On purpose?
<Burgundavia> sadly, not
<Burgundavia> although quitting was very much "on purpose"
<shawarma> Yes, my keen jedi senses told me that, too.
<xipietotec_> are there any plans in ubuntu+x releases to use suspend2?
<Hobbsee> xipietotec_: not unless it gets into the main kernel, iirc.
<Hobbsee> check what the mailing lists say on it (ubuntu-devel, ubuntu-devel-discuss) - the archives are tehre
<xipietotec_> ah, gotcha. duh, that makes sense. </me hopes it gets in...because I'm not really looking at running a patched kernel, pfft>
<Burgundavia> xipietotec_: it is the kind of thing that needs to get upstream, unless it provided such amazing functionality as to require the huge delta
<xipietotec_> Well, evidently it works *better* than normal hibernate
<Burgundavia> given how much laptop support has been a priority for Ubuntu and the fact that it isn't in basically means it ain't comin' until upstream gets it
* xipietotec_ caresses his new dell with ubuntu preinstalled
<dholbach> good morning
<Burgundavia> hey dholbach
<dholbach> hiya Burgundavia
<pygi> hey folks
<Hobbsee> hiya pygi, how was maths?
<pygi> Hobbsee, easy, but I won't pass sadly
<pygi> I blame my complete of interest in the subject
<pygi> Hobbsee, want to upload a debdiff so I don't have to bug mvo when he's around? ;)
<Hobbsee> awww.  it's useful to pass
<pygi> it is ofcourse completely acceptable and working :)
<Hobbsee> and a debdiff for what?
<pygi> no kidding :P
<pygi> brasero package
<Hobbsee> oh ick.
* Hobbsee should go study
<pygi> Hobbsee, then go ^_^
<pygi> and pass things, unlike me :)
<dholbach> hey mvo
<mvo> hey dholbach
<Hobbsee> hiya mvo 
<Hobbsee> ooh, if mvo is here, i can ask him about my plans for dput.
<StevenK> You have plans for dput?
* StevenK has patches in dput.
<mvo> hey Hobbsee!
<Hobbsee> StevenK: i know, i saw :)
* StevenK grins.
* mvo wonders what kind of plans
<Hobbsee> mvo: it seems that no ubuntu system, including upload.ubuntu.com and revu, allow you to use dcut
<pygi> dput*
<Hobbsee> mvo: so siretart and myself are thinking of putting in a message saying that "this does not apply to ubuntu systems" or something
<StevenK> That's do-able.
<Hobbsee> that's what i thought
<Hobbsee> some o fit's in bzr too, not the latest version though.  no idea why.
<shawarma> Hobbsee: No ubuntu system allows you to use dput? Um... WhaT?
<StevenK> shawarma: Not dput, *dcut*
<Hobbsee> shawarma: dcut.
* Hobbsee checks that she wrote dcut.
<Hobbsee> oh yes, i did.
<shawarma> StevenK: Ah, I just saw the "dput*" thing, and didn't notice it wasnt' Hobbsee saying it. :)
<Hobbsee> hehe
* Hobbsee blames pygi 
<Hobbsee> shawarma: i'm not *usually* an idiot.
<pygi> Hobbsee, what did I do this time?!?!
<Hobbsee> shawarma: so i wont usually say stupid stuff like that
<shawarma> Hobbsee: I *was* kind of puzzled.
<pygi> oh!
<pygi> Hobbsee, nop, your fault
<Hobbsee> shawarma: then again, i did ask "is a package still in the new queue" without just looking it up.
<shawarma> Hobbsee: That's not stupid. That's just lazy, which is entirely different and entirely alright.
<Hobbsee> shawarma: what's stupid about it is that i didnt even think of it.
<Hobbsee> getting the rejected mail was a red herring, so confused me :P
<Hobbsee> (and the powers that be say "we gave her core because...?")
<shawarma> :)
<pygi> hey giskard :0
<giskard> hello pygi  :)
<pygi> giskard, how is it going?
<giskard> bad, in 10 days i have my final school exam
<pygi> meh, I just had math exam
<pygi> was bad :p
<Keybuk> I am absolutely delighted with my discovery that there is such a thing as the "International Standard Atmosphere"
<Hobbsee> the what?
<cjwatson> shawarma: merge-o-matic does some translation merging with specialised tools, which is nice if you actually changed the translations but an interference if you didn't; if those diffs are pointless, ditch them
<Hobbsee> haha, cool
<seb128> hey Keybuk
<cjwatson> mneptok: we use VMware fairly extensively internally for testing, so on a practical level it's a good idea for us to accept at least some number of bugs about it
<shawarma> cjwatson: Cool. Thanks.
<seb128> Keybuk: so you gave compiz to mvo? ;)
<Keybuk> heh, was just /msg'ing you about that :p
<Keybuk> Hobbsee: it's to do with how plane altimeters work
<Hobbsee> yeah, i wikipedia'd.
<Hobbsee> eventually
<cjwatson> Hobbsee: in an ideal world, a reject would always be accompanied by a mail
<cjwatson> an explanatory one rather than the LP standard "kthxbye" one
<Hobbsee> cjwatson: indeed.
<Hobbsee> cjwatson: but it makes enough sense, as is.  unless you screw it up originally
<cjwatson> Hobbsee: unfortunately, there's a long-standing bug in soyuz noting that the reject interface doesn't let us give a reason, so it relies on the rejecting archive admin remembering to fish out all the e-mail addresses and send mails by hand
<cjwatson> which, in the case of bulk things like de-duplication, is less likely
<Hobbsee> cjwatson: ahhh, okay.  fair enough
<tepsipakki> keyutils is in universe, is that why krb5 doesn't build?
<Hobbsee> tepsipakki: yes
<tepsipakki> Hobbsee: okay, I'll file a MIR
<siretart> Hobbsee: I'd have no problems with removing that message completely
* Hobbsee nods
<siretart> Hobbsee: because the set of people who would be using an ubuntu dput to upload to debian normally would know about dcut, I think
<siretart> Hobbsee: but changing it is fine to me as well
<Hobbsee> right....that's a point
<Hobbsee> siretart: um, about REVU - what's the "official" way to get something out of the rejected queue?
<Hobbsee> i've just been moving the changes file up a directory, but i've got no idea what's supposed to happen
<dholbach> Keybuk: "Ow! You broke my nose!" - very funny :)
<crimsun> I'll reprocess it
<Hobbsee> siretart: seems to work, at least some of the time.
<siretart> Hobbsee: the script who processes the incoming directory is /srv/revu1-production/scripts/process_uploads.sh. it is run from revu1's crontab every 5 minutes
<Hobbsee> siretart: right
<Keybuk> dholbach: I wasn't going to even start on the fact that using 1024 multiples for disk or storage devices is wrong anyway, and disks are measured in thousands, millions & billions of bytes
<Hobbsee> siretart: persia probably wants/needs access to resync the keyring, etc, too - he's diong a lot of reviewing.
<Hobbsee> siretart: i dont think you and him have actually been around at the same time, though
<dholbach> Keybuk: seems like a good move as the topic is quite suitable for flame wars
<Keybuk> it's cold today <g>
<dholbach> right
<dholbach> Keybuk: my dog love you for that, if it was true
<cjwatson> Keybuk: you'd get on well with the partman author
<Keybuk> cjwatson: heh
<cjwatson> there's a special note in the ubiquity partman frontend that has to say "this is measured in 1000000, not 1048576" or words to that effect
<Keybuk> it's true, disk manufactures do actually use 1000 byte multiple, not 1024
<cjwatson> indeed
<cjwatson> except sometimes they use a mix
<cjwatson> 1024000 and that sort of thing
<Keybuk> heh, yeah, sometimes they like to use thousands and millions of 1024 bytes
<Keybuk> personally I think that kilo, mega, giga are the only way forward
<Hobbsee> Keybuk: and rid the world of crappy imperial measurements, and timezones, while you're at it, please.
<Keybuk> because they by saying "this drive has a capacity of 100GB (100 billion bytes)", you're guaranteeing the minimum number of bytes it is likely to have :p
<Keybuk> trying to be more specific is just guess-work
<hunger> Keybuk: KB is defined as 1000Byte (MB as 1000KB, and so forth).
<hunger> Keybuk: No guesswork required.
<hunger> Keybuk: 1024Bytes are a KiB.
<cjwatson> that's a retcon though
<hunger> There actually is a international standard about that stuff...
<cjwatson> it is unarguably not what KB has always meant, and thus guesswork is required.
<Keybuk> hunger: there's an international standard cup of tea, that doesn't mean you can't drink coffee
<hunger> Keybuk: Of course not. But then you as the distribution guys need to fix it;-)
<Keybuk> yeah, I think we should put this to the technical board ...
<Keybuk> I vote for "use KB and MB and GB everywhere, and eradicate all uses of KiB, MiB and GiB because they cause confusion"
<mpt> because we have nothing better to do?
<hunger> Keybuk: Yes, rage against the standards!
<Keybuk> hunger: stupid standards, yes
<Keybuk> just because someone wrote a "standard", doesn't mean it's right
<hunger> Keybuk: Well, it tries to end the confusion you complained about. Just sticking to "we always did it that way" will not do it.
<Keybuk> especially when the person wrote a standard didn't reference the current practice
<cjwatson> the "KiB" standard has caused more confusion than the prior practice did
<Keybuk> that's like "I have a better idea how to do this, if I write a standard, then people will obey me!  muahahaha!"
<Keybuk> a bit like the IRC standard, actually
<Keybuk> <g>
<hunger> Well, do whatever you want. You'll do so anyway;-)
<Keybuk> hunger: in general, I've found that places that refer to things as KiB are using the wrong unit anyway
<Keybuk> worst offenders using it to refer to disk space, or bandwidth, etc.
<hunger> Keybuk: I have not made that experience yet.
<Keybuk> the primary advantage to KB is that, in the worst case, it slightly under-estimates
<Keybuk> hunger: the main place I see it is in ifconfig
<hunger> Keybuk: Diskspace is traditionally in MB/GB... which started the whole mess.
<Keybuk> to measure bandwidth
<Keybuk> which is so utterly bogus, it's funny
<Keybuk> bandwidth should be measured in thousands, millions, etc. of bytes
<Burgundavia> what shocks me is just how much effort people have put into this whole thing
<Burgundavia> there are huge threads on both ubuntu and debian-devel
<hunger> Keybuk: Why is it bogus? If it is the proper unit for the thing they measure it is fine.
<Keybuk> hunger: that's the point, it isn;t
<seb128> Burgundavia: "huge"? you don't read debian-devel often, do you? ;)
<Burgundavia> seb128: right, moderately large :)
<Burgundavia> huge would be an Ubuntu flamewar
<Burgundavia> anti-ubuntu, that is
<hunger> Keybuk: Yes. I don't care how it is measured, as long as the proper unit of measurement is given.
<Keybuk> hunger: and in this case, the wrong unit of measurement is given
<Keybuk> hunger: which is the case with every instance of Ki I've ever seen
<hunger> Keybuk: So far I had no trouble with that. All Ki I noticed so far (and that does *not* include ifconfig;-) seemed to be properly 1024 based.
<Keybuk> hunger: inappropriately 1024 basde
<Keybuk> hunger: ie. using multiples of 1024 for things that should be multiples of 1000
<hunger> Keybuk: This discussion is a bit like using inches or centimeters.
<Keybuk> exactly ;)  let's standardise on centimetres!
<Keybuk> (and spell it right :p)
<hunger> Keybuk: As long as the proper unit is attached I do not really care. I just don't like the KiB on 1000 based values (never encountered those) or KB being based on 1024 (happens a lot).
<Keybuk> it shouldn't be KiB anyway
<Keybuk> it should by kiB
<hunger> Keybuk: right.
<Keybuk> we could solve this with Unicode!
<Keybuk> B!
<hunger> Actually I usually do not even care wether 1000 or 1024 is the base... as long as enough free space is available to store my stuff;-)
<Keybuk> hunger: right, in which case you should always use 1000 as the base, because then in the worst case you have more space than quoted
* hunger sighs. Unicode rocks.
<Keybuk> using 1024 or 1024000 means you could have less space than quoted
<Keybuk> :p
<xipietotec_> !seveas
<xipietotec_> oops
<ubotu> Seveas has a popular 3rd party repository for several packages. More info (and mirrors) on http://wiki.ubuntu.com/SeveasPackages
<hunger> Only ignorant US citizens speak up against unicode;-)
<shawarma> hunger: You'd be surprised..
<Keybuk> I never said anything bad about Univode
<Keybuk> uh, code
<shawarma> hunger: I know a handful of {free,open}bsd people who absolutely refuse to use anything but iso-8859-*
<Keybuk> shawarma: well, they use BSD, they're already swimming against the tides of inevitability ;)
<hunger> shawarma: ignarant bastards... "I do not need more than 256letters, why should anybody else?"
<cjwatson> easy
<shawarma> hunger: It's a *very* frustrating discussion. I've had it with them many times now. Their argument always goes something like "Whaaaa! I once saw one of my 's that didn't look right because someone used utf-8.. Whaaa!"
<hunger> shawarma: I can imagine:-(
<tepsipakki> then there are applications that don't work with utf.. like Tectia ssh-client for windows
<tepsipakki> which is maybe the biggest obstacle for utf adoption here
<mjr> There's putty...
<tepsipakki> mjr: true, it works
<pitti> Good morning
<Hobbsee> copy/pasting is just weird in it, though
<Hobbsee> hiya pitti!
<hunger> tepsipakki: Yes, let's head back to stoneage... at least everything worked back then.
<tepsipakki> now, it has to be decided do we change tectia to putty&winscp and modify all the documentation there is
<cjwatson> copy/pasting in putty is X normal
* pitti hugs Hobbsee 
<tepsipakki> hunger: rather, stay there :)
* Hobbsee hugs pitti :)
<cjwatson> there's a configuration option to switch it to a more Windows-ish behaviour if you prefer that
<Hobbsee> cjwatson: ahhh.  i must find that.  actually, i tihnk i did, one day
<tepsipakki> cjwatson: yep
<fabbione> mvo: ping?
<tepsipakki> tectia will be fixed early next year, but it's too late if we are to adopt nfsv4
<tepsipakki> anyway, offtopic :)
<tepsipakki> mvo: I just confirmed the app-install-data install failure bug
<mvo> hello fabbione
<mvo> tepsipakki: what bugnumber?
<fabbione> mvo: hey dude..
<fabbione> mvo: Accepted redhat-cluster-suite 2.20070503-0ubuntu3 (source)
<fabbione> mvo:    * Kill libccs-dev binary package. Nothing B-D on it anymore and it will be
<fabbione>      killed upstream too at somepoint.
<tepsipakki> mvo: a sec, didn't subscribe to it :P
<fabbione> mvo: have fun :)
<fabbione> mvo: just give it time to build and you should be good
<tepsipakki> mvo: bug 118740
<ubotu> Launchpad bug 118740 in app-install-data-ubuntu "app-install-data :  Can't import AppInstall.CoreMenu, aborting" [Medium,Confirmed]  https://launchpad.net/bugs/118740
<mvo> fabbione: cool! my upstream change the name for libccs as well :) 
<fabbione> mvo: perfect...
<mvo> tepsipakki: you get a postinst failure ?
<mvo> tepsipakki: can you please put the exact error output from dpkg into the bugreport
<tepsipakki> mvo: that's all I see (netboot)
<tepsipakki> the same message, that is
<tepsipakki> mvo: um, actually the package apparently installs fine, but pkgsel fails
<mvo> tepsipakki: so this happens when you try to install a fresh gutsy? ok, I will try to reproduce
<cjwatson> why would pkgsel be involved in an upgrade?
<tepsipakki> cjwatson: this was a fresh install
<cjwatson> you said "During the upgrade process" in the bug report
<tepsipakki> but the original reporter had an upgrade
<cjwatson> ok, sounds like your problem is different then
<cjwatson> can you put the syslog somewhere I can see it?
<tepsipakki> cjwatson: yes, a sec
<tepsipakki> ah, found it
<tepsipakki> a traceback from app-install-data
<tepsipakki> but the syslog is here: http://users.tkk.fi/~tjaalton/dpkg/syslog
<cjwatson> app-install-data probably needs to Depends: gnome-app-install if it uses python modules from there
<tepsipakki> yep, "No module named xdg.DesktopEntry"
<cjwatson> which of course means a circular dependency so that's tricky
<mvo> tepsipakki: I wonder how that triggers a failure to install, the postinst should run fine and g-a-i works even when the data is not cached, this is really just a optimization
* mvo scratches his head
<cjwatson> tepsipakki: http://users.tkk.fi/~tjaalton/dpkg/syslog is 403
<tepsipakki> uh
<tepsipakki> try now
<cjwatson> ok
<cjwatson> ok, definitely mvo's problem :)
<cjwatson> mvo: there's no try/except around import xdg.DesktopEntry
<pitti> heno: https://wiki.ubuntu.com/UbuntuBugDay/20070613 says that the lists were generated by bughelper; are we supposed to add some bite-sized bugs there manually or will that be clobbered?
<cjwatson> if you just want to ignore all errors from update-app-install, maybe just put || true after it in the postinst?
<heno> pitti: if they are generated by bughelper I'm sure they are still manually pasted in, so I don't think anything will be clobbered
<heno> pitti: yo might want to use a separate heading or something
<heno> I'll coordinate more with Brian when he wakes up
<Hobbsee> pitti: did you have plans to give some love to https://bugs.launchpad.net/ubuntu/+source/ia32-libs/ ? it's broken in various areas, including updates, and you appear to be the last uploader
<pitti> Hobbsee: oh, right; siretart wanted to send me his patch
<siretart> pitti: oh, I didn't? damn
<mvo> cjwatson: indeed, that one if for me 
<siretart> pitti: but I can explain it it you, might be more easy than the patch itself: I moved the commented out packages in the list and added the packages from ia32-libs-sdl
<Hobbsee> pitti: siretart ditto https://bugs.launchpad.net/ubuntu/+source/ia32-libs-gtk
<Hobbsee> (more file conflicts)
<Hobbsee> it's been left unfixed for a month or so - presumably us mere mortals dont know how this stuff is supposed to work. 
<siretart> yes, we should merge them all in one package
<Hobbsee> siretart: that'd be cool.  various stuff is failing to build due to this lot, etc.
<Hobbsee> so fixing is good, if youv'e got the wish & required skills
<pitti> Hobbsee: 'k, I have them open in ffox tabs now (my short-term todo list)
<Hobbsee> pitti: woo :)
<pitti> heno: btw, the third column on the hug day wiki page says 'hugger', but is supposed to be used by the one working on the bug; shoulnd't that be 'huggee' then? :)
<pitti> I wonder what would happen if I marked an ia32-libs bug (324 MB orig.tar.gz) as 'bitesize'
<Hobbsee> hahahhaa
<Hobbsee> you'd get shot.
<Hobbsee> pitti: the original tarball isnt seriously that big, is it?
<Keybuk> wasabi, iwj: so today I learned that fsync() doesn't actually have to sync ...
<Keybuk> int fsync (int fd) { return 0; } is a valid implementation according to POSIX
<pitti> Hobbsee: sure it is
<heno> pitti: yes, probably. sounds a bit like a brand of underwear though :)
<Hobbsee> pitti: twitch.
<pitti> -rw-r--r-- 1 pitti warthogs 324361425 2007-05-22 17:05 ia32-libs_1.19ubuntu1.tar.gz
<pitti> Hobbsee: after all, it's much like a complete debootstrap including sources
<pitti> and tons of desktop libs, too
<Hobbsee> pitti: true that
<ogra> pitti, ltsp seems to be done o sparc as well now :)
<ogra> *on
<pitti> ogra: ah, cool
<pitti> ogra: NEWed (assuming that you'll clean up the lintian bits somewhat)
<ogra> willdo ...
<ogra> btw, the debconf template is for a question asked in the preinst on debian it seems 
<ogra> i'll ping them to fix it
<glatzor> mvo: bryyce: hello, I just pushed some unittests for displayconfig
<mvo> glatzor: cool, that is great news!
<iwj> Keybuk: fsync> Nice.
<pygi> Zdra, wake up ^_^
<siretart> pygi: do you manage your changes to libisofs and libburn in a bzr branch?
<pygi> siretart, nop, but I could if I'd register ssh keys with LP :)
<pygi> (I know you're interested in bzr-builddeb, yes)
<pygi> I could commit changes if we really have to keep that bzr branch
* pygi is not used to that, but could do it if necessary
<siretart> oh, I'm rather curious, if you are not comfortable with it, I'd be interested in knowing why
<siretart> for all fans of patch systems, please have a look at http://wiki.tauware.de/misc:vcs-packaging2
<siretart> pitti: I've seen that ecryptfs is in source NEW for quite some time now. Do you happen to know if there's a problem with the package?
<pitti> siretart: no, there's just a lack of people doing source NEW :/
<siretart> ah
<pygi> siretart, it's not that I'm not comfortable, it's just the time it would take me for it to become routine task would better be spent fixing other things :)
<pitti> siretart: tomorrow it's seb128's day, friday is mine; I'll coordinate with Seb to get to it eventually
<siretart> pygi: oh, sure
<pygi> siretart, mvo has one debdiff for me to upload, and then brasero will be in pretty good shape
<pygi> need to find a fix for ppc & sparc build fail, but that's low priority right now
<siretart> pitti: its just because it is a package of xxxxx1, which I'm mentoring. he was asking me yesterday about it
<mjg59> Keybuk: ?
<mjg59> Keybuk: "The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes. The nature of the transfer is implementation-defined. The fsync() function shall not return until the system has completed that action or until an error is detected."
<cjwatson> mjg59: read the rationale too
<cjwatson> "If _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on the conformance document to tell the user what can be expected from the system. It is explicitly intended that a null implementation is permitted."
<cjwatson> (I don't know whether we define _POSIX_SYNCHRONIZED_IO)
<pygi> siretart, did you manage to think up of a sane solution for cdrecord/wodim/cdrskin whatever mess?
<pygi> I mean how will we solve it
<pygi> (update-alternatives, or just link wodim/cdrecord against cdrskin (the solution which I prefer))
<mjg59> cjwatson: That seems to effectively state that the null implementation would only be valid in the case where there's no way to guarantee persistant storage anyway
<mjg59> (Or where write() is synchronous)
<cjwatson> "file system is on a network" is a not-wholly-unreasonable case where that is true
<cjwatson> and where locking is interesting
<Keybuk> mjg59: Mac OS X is the interesting case here; it's fsync doesn't
<mjg59> cjwatson: Well, _POSIX_SYNCHRONIZED_IO is defined on Linux, so it's not an issue for us
<mjg59> So (assuming we conform...) it can't be an issue for any of the network filesystems supported on Linux :)
<mjg59> Keybuk: It looks like MacOS fsync() transfers it to the storage device, but doesn't ensure that it's hit the platters
<ogra> pitti, are you sure you NEWed the ltsp stuff ? there is still no trace ... 
* ogra needs the ltsp-client-core package in the archive to go on with his work
<pitti> ogra: yes, but I NEWed it at 12:04, so it missed the 12:03 cron.daily by one minute
<pitti> ogra: it should be published right now (check in about 10 minutes)
<ogra> ah, k 
<ogra> i thought they run in 30min frequency
<pitti> no, it's still too slow for that
<ogra> sorry for being pushy
<pitti> np
<Hobbsee> mvo: got any qualms about me fixing some of the bugs in ubuntu-restricted-manager?  
<pitti> Hobbsee: you mean restricted-manager? or ubuntu-restricted-extras?
<Hobbsee> sorry, extras
<pitti> Hobbsee: I would have been glad about r-m bug fixes from you :)
<Hobbsee> pitti: haha, good luck with that
<Hobbsee> pitti: but there's talk of a kubuntu version
<pitti> yes, I discussed it with Riddell on UDS
<pitti> AFAIR there's a SoC project?
<Riddell> pitti: yes
<Riddell> if he gets gdebi done in time
<Keybuk> siretart: that's cool
<Keybuk> someone should write a plugin to do that for bzr ;)
<Keybuk> lifeless: ^ :p
* nougad hugs all
<Hobbsee> pitti: wow.  i underestimated the amount of gstreamer0.10 plugins there were here.
<pygi> :)
<Hobbsee> oh impressive.  and adding all of -bad* and -ugly* still wouldnt catch them all
<pygi> :)
<pitti> siretart: re ia32-libs-gtk merge> so everything else except for the fetch-and-build list can be dropped? like the file shuffling in debian/rules?
<pitti> siretart: or the separation of -dev bits
<pitti> siretart: oh, hmm, -gtk is still in Debian
<racarr> mvo__: Ping
<mvo__> racarr: hello! 
<Hobbsee> mvo: ping
<racarr> mvo: Did you see what I posted on the compiz bug you asked about yesterday?
<racarr> Nevermind, just saw your PM
<mvo> racarr: yes, thanks again for the help!
<mvo> hello Hobbsee
<Hobbsee> mvo: i warn you now, i'm doing nasty things to a package of yours.
<mvo> Hobbsee: you did already, no? I just got a changes mail
<Hobbsee> mvo: okay, *more* nasty things than that :)
<Hobbsee> mvo: "so, uh, why would we be distribuitng a separate kubuntu-restricted-extras source for this, when it's almost hte same?"
<mvo> Hobbsee: hm, kubuntu-r-e would need the xine extra codecs?
<Hobbsee> mvo: yes
<Hobbsee> mvo: it's got them
<Hobbsee> that package got renamed, etc.
<pitti> mvo: (note that Hobbsee questions the existence of a separate *source*; separate binaries are fine and necessary)
<mvo> pitti: aha, thanks. I was confused for a moment
<Hobbsee> :)
<pitti> Hobbsee: so, tell me if/when I should kill the source again; I won't NEW the binaries for nwo
<mvo> I had no idea there was a seperate kubuntu-r-e package so unifring them into the same source sounds like a good plan
<pitti> now, too
<Hobbsee> pitti: please go ahead and kill the source.
<Hobbsee> pitti: i'm getting help with some bash-foo, and then i'll upload
<Hobbsee> of k-r-e
<Hobbsee> mvo: there wasnt, until a copule of days ago
<pitti> Hobbsee: *flush*
<pitti> Hobbsee: I wonder whether this was the shortest lifetime of a source package *ever*
<Hobbsee> haha, sorry
* Hobbsee hugs pitti again
<mvo> pitti: I can think of one ..
<wasabi> Keybuk: Makes me wonder what the real chances of having transations in our file systmes in the next few years are.
<pitti> mvo: which?
<Hobbsee> pitti: at least it was small, and didnt require you to check licencing :P
<mvo> pitti: ccs-settings, hasen't seen the light of the archive at all
<pitti> mvo: it's in NEW; I thought you wanted to disambiguate the name?
<seb128> pitti: I'm rejecting it
<pitti> mvo: oh, I mean 'in the archive'
<pitti> mvo: now the '<mvo> pitti: I can think of one ..' becomes clear; I thought you refered to reasons to keep k-r-e as separate source :)
<mvo> pitti: sorry, misunderstanding
<heno> how well do we support USB microphones generally?
<heno> (they tend to be better for voice recognition use)
<Treenaks> heno: USB soundcards tend to work OK
<Treenaks> (and most USB headsets are USB soundcards)
<Treenaks> (at least, the ones I've seen)
<heno> Treenaks: great, thanks!
<pitti> heno: not sure in general, but my logitech USB headset "just works"
<Treenaks> pitti: USB Audio is a "standard" profile, lots of devices support it (unlike, say, video/webcams, where every device has its own vendor-specific interface)
<broonie> There's a well-defined and generally well implemented generic USB audio class.
<heno> pitti: ok, as long as we have a few types we can recommend we are in good shape
<Treenaks> we use them for VoIP stuff here at work
<Treenaks> the Logitechs
<pitti> siretart: ok, I have the package merged; I want to sort out the gnutls13 FTBFS first, otherwise we cannot update to gutsy debs
<indraveni> hi al
<indraveni> hi all
<indraveni> could someone please let me know, where is the coding or designing of ubutnu shutdown/logout image is present
<indraveni> is it i gnome-human-themes
<cjwatson> indraveni: usplash-theme-ubuntu
<cjwatson> shutdown != logout, BTW; those are two separate themes
<siretart> pitti: great! ok
<indraveni> cjwatson, the image which is appeared when we click on system -> Quit
<indraveni> cjwatson, is that the one done in usplash-theme-ubuntu?
<indraveni> cjwatson, I want to know, where the gui part of the image which is appeared when we click on System -> quit
<pitti> doko: can I remind you about the zope3 merge? it's still assigned to me, but we traded it
<cjwatson> indraveni: oh, ok, no, I think that's in gnome-session
<indraveni> cjwatson, oh
<indraveni> cjwatson, is the desining of the image is done in C language?
<indraveni> cjwatson, what does this uue file mean?
<cjwatson> indraveni: language> no idea
<cjwatson> indraveni: uue sounds like something that's been run through uuencode; you can use uudecode to reverse that
<seb128> indraveni: what image?
<seb128> there is no image when you click there, it's a dialog with button and fading around it
<indraveni> seb128, yes a dialog window which has, shutdown, logout, hibernate and other options with respective icons in it
<seb128> that's an application dialog, not a image
<Hobbsee> pitti: yay, uploaded :)
<indraveni> seb128, how is the desining of that is done in ubuntu? in debian we dont have any such dislog window 
* mvo hugs Hobbsee
* Hobbsee hugs mvo :D
<indraveni> seb128, how that dialog is invoked, what is the desktop file responsible for this System -> Quit
<seb128> indraveni: it's debian/patches/11_session_dialog.patch and there has been discussion in the Debian gnome-pkg team but no consensus to use it
<seb128> indraveni: it's the logout dialog, it's coded and not used a desktop
<seb128> s/used/using
<seb128> indraveni: what are you trying to do?
<indraveni> seb128, I am tring to create a debian based distro on my own
<indraveni> seb128, and I am seeing that the debian shutdown and logout images are not very good to see 
<indraveni> seb128, where as ubutnu has a good look and feel for this
<seb128> maybe base it on Ubuntu if you like the desktop changes there ;)
<indraveni> seb128, I am trying to do a similar kind of images for my distro
<seb128> have a look to the patch I mentioned then
<indraveni> seb128, ha, that will be next option, initially I want to learn how the things have been changed from debian to ubutnu
<indraveni> s/ubutnu/ubuntu
<seb128> good luck then
<seb128> brb, restarting to try some change
<shawarma> I'm looking at https://bugs.launchpad.net/ubuntu/+source/sysklogd/+bug/19889 which looks like a strong candidate for an SRU. However, as well documented the issue *and* the fix seems to be, it feels funny to file an SRU without properly testing it first, but I don't have the hardware to do that.. Does anyone have a Dapper machine with a few GB (or GiB or whatever) space in /var/log that they would consider testing this on?
<ubotu> Launchpad bug 19889 in sysklogd "sysklogd: Large file support is broken in dapper" [High,Confirmed]  
<shawarma> Hmm.. tough room.
<Keybuk> shawarma: actually, it's neither 2GB or 2GiB
<Keybuk> the maximum size of the file is 2^9-1 :p
* Keybuk invents a new "GoB" SI prefix to describe integer limits
<shawarma> Keybuk: 511 bytes? wow
<Keybuk> uh, 2^31-1 :p
<shawarma> Keybuk: Well, yes, so I need 2 GiB in order to make sure it's not just because I *actually* have run out of space. :)
<elmo> shawarma: I have an in use package that I know fixes the problem
<shawarma> elmo: Just with the shell bits added?
<shawarma> elmo: I'll just refer to you then, shall I?
<Keybuk> debdiff showdown? :p
<elmo> shawarma: yes, let me just find the source for  package I'm using
<elmo> oh right, that'd be the 'HATEYOUALL' directory on ronne
<Hobbsee> ...that exists?
<Hobbsee> that's pure awesomeness.
<Keybuk> I think that's unfair
<Keybuk> HATECHMJ would be better
<shawarma> elmo: http://www.linux2go.dk/19889.diff <-- the proposed patch.
<elmo> shawarma: ronne:~james/HATEYOUALL - give it 5-10 minutes for your account to propagate
<shawarma> Alright, then.
<StevenK> He's a sysadmin, he's *supposed* to hate everyone.
<Hobbsee> Keybuk: what's CHMJ?
<lousygarua> /joing #ubuntu-bugs
<lousygarua> oops
<Keybuk> Hobbsee: who-touched-it-alst
<Keybuk> last too
<Hobbsee> ahhhh
<seb128> Hobbsee: bug #119842, could you describe the Ubuntu changes and why they can be dropped?
<ubotu> Launchpad bug 119842 in shntool "Please sync shntool (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/119842
<Hobbsee> seb128: mumble mumble thought i did...
<seb128> ;)
* Hobbsee looks
<Hobbsee> seb128: -ENOUBUNTUCHANGES,THOUGHTTHEAUTOSYNCWASOFFNOW
<seb128> k, that's what I was wondering
<Hobbsee> i know it's close to off - thought it went off a copule of days ago
<persia> Autosync is one more week, right?
<Hobbsee> (btw, what was the result on getting the universe autosync to run later?)
<cjwatson> we discuss this every release
<seb128> persia: schedule is on the wiki ;)
<pitti> until June 21st
<cjwatson> every release the answer is the same: it's risky because Debian don't honour our main/universe separation when making complicated changes
<persia> seb128: Just checking validity :)
<Hobbsee> cjwatson: apologies, i'm not sure i ever saw that discussion - or at least the outcome
<Hobbsee> oh right, that, yes.
<pitti>    * Added myself to Uploaders, as i'm maintaining the Kubuntu side
<pitti> Hobbsee: ^ nevermind about Uploaders: in Ubuntu
<Hobbsee> pitti: i know.  i just wanted to be there.  *shrugs*
<Hobbsee> and apparently one cant have multiple maintainers.
* persia recommends teams
<Hobbsee> figured that they might figure to ask me for the kubuntu side, seeing as it has the kubuntu address in there and all, isntead of going to mvo for all of it.
<pitti> Hobbsee: right, as a hint about whom to contact that's fine
<Hobbsee> :)
<asac> if i am in debian Uploader for a package that is ment to go into main, should I use my address as Maintainer or Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com> ?
<asac> s/if i am in/if i am a/
<Hobbsee> asac: i believe the answer is "whichever"
<asac> :9
<asac> ok
<Hobbsee> asac: as it was only to stop annoying the debian developers who were getting ubuntu bugs
<Hobbsee> but clearly you wont be annoyued, as you're also the ubuntu maintainer
<asac> ;)
<geser> seb128: could you run the script that fetches NEW source packages from Debian on your next archive day? it would be good if we get claws-mail as we already have claws-mail-extra-plugins but are missing the main package
<pitti> BenC, keescook: did you see the latest response in bug 117314 wrt. 'nvidia'? did the recent -security upload change the ABI unnoticed?
<ubotu> Launchpad bug 117314 in linux-source-2.6.20 "latest kernel(2.6.20-16.28) update gives boot problems" [Critical,In progress]  https://launchpad.net/bugs/117314
<seb128> geser: hum, will try
<asac> geser: you did the xulrunner python2.5 patch at some point, right?
<BenC> pitti: sounds less like a ABI change, and more like a failure somehow for nvidia.ko to be linked
<BenC> pitti: considering the guy could not boot the first -16 kernel because of the device name changes, it's more likely that something just didn't complete in his update (depmod maybe?)
<geser> asac: no, that was \sh, I only merged xulrunner
<pitti> ah
<asac> geser: we have to do it differently ... it might cause access of uninitialised memory
<BenC> pitti: also, we had quite a few people complain about nvidia breaking, mainly because they had their own locally compiled version
* Hobbsee is sure she requested a sync of claws-mail, geser 
<pitti> Hobbsee: IIRC I rejected it because we'll auto-import it anyway
<Hobbsee> pitti: and you removed it from the blacklist, too?
<Hobbsee> i believe someone mentioned that it was on there
<pitti> Hobbsee: I did
<seb128> BenC: somebody I know complained to me this morning that the linux update broke his nvidia and he said he only used restricted-manager to install the driver
<Hobbsee> cool.  i thought so.  just i would have expected it to be synced by now, in which case geser wouldnt be asking.  whether it actually *has* or not, i've not checked.
<BenC> seb128: If running "sudo /etc/init.d/linux-restricted-modules-common" fixes it, then it's something in the install scripts
<seb128> BenC: I'll ask him later when he'll be around and let you know
<pitti> seb128: see above bug (117314)
<seb128> pitti: yeah, I added that a piece of information because BenC was saying breakage are mainly due to compiled versions
<geser> asac: if you have a better patch for the FTBFS let's use it
<asac> geser: no ... wanted to help developing it :) ... haven't looked into it in detail so far :)
<asac> geser: its on my TODO list though :)
<doko> pitti: thanks for the reminder, but still waiting for the package in debian NEW to be synced
<pitti> doko: oh, we can sync zope3 from Debian's NEW?
<doko> pitti: try it, I'm not an archive admin ;-P
<pitti> doko: can == we can ditch the ubuntu changes, not how to technically do it
<seb128> BenC, pittiit looks like the linux security update also reintroduced bug #109762
<ubotu> Launchpad bug 109762 in linux-source-2.6.20 "resume from suspend to Ram only works once - I/O error the second time (Samsung X20 and IBM T40p - feisty)" [Wishlist,Fix released]  https://launchpad.net/bugs/109762
<doko> pitti: yes, the changes can be dropped with 3.3.1-3
<pitti> doko: cool
<pitti> doko: unfortunately Debian's NEW queue doesn't provide the packages in it
<pitti> doko: if you can put the .dsc and diff.gz somewhere, we can manually sync it
<doko> pitti: well, we should not do that ...
<shawarma> If someone with stronger perl-fu than me could take a peek at (and possibly upload the patch) https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/120040 it would be much appreciated.
<ubotu> Launchpad bug 120040 in lintian "Should not accept debian distros for ubuntu packages and vice versa" [Undecided,Unconfirmed]  
* shawarma runs off for a few hours.
<BenC> seb128: lesser of two evils...the revert of that allowed people to actually boot :)
<seb128> BenC: ah, k
<seb128> BenC: thank you for the information ;)
<asac> how can i find-out if gstreamer0.10-plugins-base is currently shipped on CD (e.g. without downloading an iso)?
<Hobbsee> asac: check if it's in the seeds
<cjwatson> asac: (http://wiki.ubuntu.com/SeedManagement)
<Hobbsee> asac: and apt-cache show ubuntu-desktop | grep gstreamer0.10-plugins-base will also tell you, as a starting point
<cjwatson> the seeds aren't dependency-expanded, though, so it may be easier to check the .list/.manifest files on http://releases.ubuntu.com/
<asac> cjwatson: cool thanks a lot ... looking at .list files is a nice trick
<pitti> thekorn: I created a Bug.mark_duplicate() function (branched off 'main'); will this disrupt your work on the api.changes.gsoc branch in any way?
<thekorn> pitti: no, i don't think so
<pitti> thekorn: ok, thanks; I'll finish and test it and put it into my own branch on LP, and then ask dholbach to merge to main
<seb128> can anybody confirm bug #119528
<ubotu> Launchpad bug 119528 in laptop-mode "Please remove laptop-mode from the Ubuntu archives" [Wishlist,Confirmed]  https://launchpad.net/bugs/119528
<seb128> that looks correct to me but I would like an another opinion just to be sure ;)
<thekorn> pitti: ok, cool; other question: How are you testing your code in launchpad? did you open bugs for testing or is there a kind of sandbox?
* persia is all for 119528, but my confirmation doesn't mean anything :)
<pitti> thekorn: I usually just test them on the live LP on an old test bug of mine
<pitti> thekorn: but if you want to do large-scale or even automated testing (yummy), then https://dogfood.launchpad.net/ might be better
<seb128> persia: heh ;)
<desrt> seb128; why are there no internation airports in the north of france?
<seb128> desrt: because France is not big enough to justify it? ;)
<thekorn> pitti: ok, thanks, will have a look at it
<desrt> seb128; there are tonnes in the south
<johanbr> Everybody wants to go to the Riviera. :)
<persia> seb128: You might also be interested in bug 6676, which was a previous attempt to do the same thing.
<ubotu> Launchpad bug 6676 in laptop-mode "Laptop-mode should be replace by laptop-mode-tools" [Wishlist,Rejected]  https://launchpad.net/bugs/6676
<seb128> persia: ok
<desrt> seb128; how far are you from lens?
<seb128> desrt: ~400km
<desrt> holy crap
<seb128> what?
<desrt> farther than i'd have guessed :)
<desrt> i'm trying very hard to visit vimy
<seb128> desrt: going to enjoy Europe again? ;)
<desrt> well
<desrt> if possible
<desrt> but it's looking pretty impossible right now
<desrt> i plan to fly into manchester before guadec and take the train (8) to birmingham and then back to manchester to leave.  looks cheapest.
<desrt> but... instead of taking a train from manchester to birmingham i was thinking maybe a flight to paris then various trains to work my way north to nijmegen and eventually leave via schiphol
<pbn> Hi there... when I got a bug number, how can I find out to what release of ubuntu it applies ?
<pbn> For instance bug 6655
<ubotu> Launchpad bug 6655 in rgl "rgl: merge new debian version" [Medium,Fix released]  https://launchpad.net/bugs/6655
<pbn> oops
<desrt> :)
<pbn> For instance bug 36655
<ubotu> Launchpad bug 36655 in kdenetwork "pppd dies on connection" [High,Confirmed]  https://launchpad.net/bugs/36655
<desrt> Kubuntu Flight 5 == before dapper
<desrt> but it's still open so it probably affects dapper, edgy, feisty, gutsy...
<pbn> desrt: thank you
<pbn> desrt: well I just installed kubuntu 6.06 on my neighbour's computer, and it's two days I see pppd crash just after kppp has completed the connection
<pitti> dholbach: would you mind merging (or just pulling) my p-lp-bugs branch to fix bug 119874? (I attached the branch there)
<pbn> I guess this might be another case of a bug in Ubuntu 6.06 that the ubuntu teams will not fix :(
<ubotu> Launchpad bug 119874 in python-launchpad-bugs "please support marking a bug as duplicate" [Wishlist,Fix committed]  https://launchpad.net/bugs/119874
<pitti> dholbach: NB that the package version number in my branch is not yet suitable for upload
<dholbach> pitti: yep, will do
<pitti> dholbach: *hug*, thanks
<dholbach> np
<pbn> Is there some way to tell kppp to start pppd with strace ?
<pbn> I'd like to do that 
<pbn> after that I guess I'll file a bug report with that information
<desrt> no... but you can attach strace after the fact,  using -p
<desrt> and if it's the same bug, just attach the information rather than filing a new one
<desrt> have you tried using feisty?
<pbn> desrt: well no... 
<desrt> that should be your first stop :)
<pbn> desrt: sorry but I suppose this is gonna be again the very same debate
* desrt isn't really interested in a debate :)
<pbn> I already had the same kind of problem with kvpnc
<pbn> A bug which is "as huge as a barn"
<pbn> bug number 77950
<pbn> bug 77950
<ubotu> Launchpad bug 77950 in kvpnc "kvpnc crashes with SIGSEGV when trying to import a Cisco .pcf file" [Undecided,Fix released]  https://launchpad.net/bugs/77950
<pbn> I opened that bug in january 2007
<pbn> on ubuntu 6.06
<pbn> the bug is supposedly fixed in edgy and feisty
<pbn> but not in 6.06 LTS
<pbn> Now I guess it's gonna be the same thing again
<pbn> That you folks won't fix it in 6.06 LTS and just say "Use feisty"
<pbn> sorry to tell you that but LTS means Long Term Support, not No Support, sorry
<pbn> I'm using 6.06 LTS for "average users" in a corporate environment, or some "newcomers" who have never had a computer
<pbn> I can't just go to eeach of these machines every six months to do apt-get dist-upgrade and pray that nothing breaks
<pbn> That's why I'm installing 6.06 LTS for those people 
<seb128> StevenK: is something in main using python-qt4-dbus or should it go to universe?
<pbn> In my case I'm using Debian GNU/Linux, but I will not bring Debian in the debate...
<seb128> pbn: dapper is supported, we can't fix every single bug there though
<seb128> pbn: Debian stable doesn't do that neither nor any other distro
<pbn> seb128: well the solution to that kind of problem was to switch *my* machines to Debian
<pbn> seb128: sorry but Debian DOES fix bugs in the stable release
<seb128> we do too
<seb128> we can't fix every bug though
<seb128> there is lot of bugs and limited manpower, stable updates takes quite some ressources for regressing testing, etc
<pitti> (Debian does much fewer bug fixes to stables than we do, FWIW)
<pbn> seb128: yes, I understand it can be difficult to fix every single bug, especially in "old" releases like 6.06
<seb128> bug #77950 you pointed has no duplicate and few comments and almost no subscriber
<ubotu> Launchpad bug 77950 in kvpnc "kvpnc crashes with SIGSEGV when trying to import a Cisco .pcf file" [Undecided,Fix released]  https://launchpad.net/bugs/77950
<pbn> seb128: but I find it counter-productive to have release 6.06 LTS which is supposed to have LTS .... and when there's a bug in 6.06 LTS, the only solution is to upgrade to 7.0.x !
<seb128> doesn't look something that needs to be fixed to stable
<pbn> well right now I'm adding comments to 36655
<seb128> not to mention it's an universe package
<pbn> uhhh did someone say something about how to run pppd with strace from kppp ?
<pbn> seb128: which one is an universe package ? kpvnc or kppp ?
<pitti> pbn: another option is to just use one or two backports on dapper
<seb128> the other one has 2 duplicates and few comments, doesn't look like something blocker many users neither
<seb128> pbn: kpvnc
<Hobbsee> pbn: did you ever find the particular patches that fixed the issue?
<pbn> seb128: well I found a workaround to the kvpnc issue
<pbn> Hobbsee: alas, no
<Hobbsee> i seem to remember that was the outcome last time
<dholbach> pitti: http://daniel.holba.ch/temp/pylpbugs.error
<pbn> Hobbsee: for kvpnc, I tried looking into whte source of Debian packages
<pitti> pbn: and yet another option, if you want to drive a stable release update for this bug, you are most welcome to :)
<pbn> Hobbsee: but the version of kvpnc in Debian is much too new compared to the one in 6.06
<Hobbsee> tbh, i wouldnt mind just backporting the entire source package.
<Hobbsee> pbn: exactly
<Hobbsee> which is why no one's done the work.
<pbn> pitti: yes, it's always good if the person reporting the bug can fix it :)
<pitti> dholbach: oh, that's a Python 2.5ism, sorry
<Hobbsee> pbn: LTS or no, unless someone does the work, it will not happen.
<Hobbsee> seb128: StevenK has gone to bed, FYI
<pitti> dholbach: let me fix this quickly
<pbn> Hobbsee: I know...
<pbn> So there might be a backport of kppp for 6.06 somewhere ?
<Hobbsee> if someone requests one, and it actually builds.
<seb128> Hobbsee: do you know if the package is required to main? otherwise I'll direct it to universe, we can still change that later if required ...
<Hobbsee> hang on, are you talking kppp or kvpnc?
<pbn> Hobbsee: kppp, sorry
<Hobbsee> seb128: i'm not positive, but it looks like a kde4-necessary thing
<Hobbsee> seb128: so main eventually, if not now
* Hobbsee isnt familiar with the kppp bug
<seb128> Hobbsee: I'll direct it to universe, if anything starts depending on it we will promote it then
<iwj> Yay!
<seb128> otherwise it'll be on the "demote list"
<Hobbsee> seb128: cool.  it'll be with the whole "promote kde4 to main" which is a later thing.
<iwj> gcc-4.1 -fno-stack-protector [... 2000 characters more of command line] 
<iwj> collect2: ld returned 1 exit status
<iwj> And that's it.
<Hobbsee> pbn: bug #?
<pbn> Hobbsee: I'd be happy to find a backport of kppp ( bug 36655 ) :)
<ubotu> Launchpad bug 36655 in kdenetwork "pppd dies on connection" [High,Confirmed]  https://launchpad.net/bugs/36655
<pitti> dholbach: pushed
* Hobbsee looks
<dholbach> pitti: rock
<Hobbsee> anyone found a solution to it yet?
<Riddell> pbn: what do you have in /etc/ppp/peers/kppp-options ?
<pitti> dholbach: the ternary operator is such a nice thing :)
<iwj> [pid  5017]  write(2, " ", 1)            = -1 ENOSPC (No space left on device)
<iwj> Aha!"
<iwj> And there's me trying to do disk-full debugging ...
<pitti> iwj: with hacked preload lib wrapping write(2) or so? :)
<cjwatson> ooh, looks like openssh upstream now puts non-standard port numbers in known_hosts
<tepsipakki> are packages allowed to install stuff in /home?
<iwj> pitti: No, this is while I'm trying to build the lib wrapping write ...
<pitti> tepsipakki: absolutely not
<persia> tepsipakki: No.
<pbn> Riddell: don't know, it's my neighbours computer... is that information important ?
<iwj> As in, my disk randomly filled up so I can't build my disk full debugger.
<iwj> And I find a bug in the linker where it doesn't say why.
<tepsipakki> ok, kubuntu-default-settings is buggy, then
<pitti> iwj: heh; nice cycle
<cjwatson> iwj: I think that's *some* kind of result
<pbn> Riddell: /etc/ppp/options is untouched for sure, that I have checked
<Riddell> pbn: it should have "noauth", if it has "#noauth" then it won't work.  not sure which dapper had
<tepsipakki> it creates a symlink /home/.directory -> /etc/kubuntu-default-settings/directory-home
<tepsipakki> and this in feisty
<cjwatson> tepsipakki: some systems have /home NFS-mounted and that will break on such systems
<tepsipakki> cjwatson: you don't say ;)
<Hobbsee> tepsipakki: i believe that's in edgy too :S
<pbn> Riddell: hmmm thanks I'll check that. You said in /etc/ppp/peers/kppp-options there must be noauth and sure not #noauth
<tepsipakki> Hobbsee: could be, we didn't use edgy
<cjwatson> tepsipakki: I thought you'd probably know that ;)
<Hobbsee> it was supposed to be gone on feisty
<Hobbsee> iirc
<Riddell> Hobbsee: it's the / one we got rid of, /home is there for a nice icon
<Hobbsee> Riddell: ahhh....right.  i thought they were both there for the same thing
<tepsipakki> cjwatson: yeah, well.. usually /home is not used here, but the math department has used it so that's why it has gone unnoticed until now
<cjwatson>  * These macros demonstrate the property of C whereby it can be
<cjwatson>  * portable or it can be elegant but rarely both.
<cjwatson> (openssh/openbsd-compat/getrrsetbyname.c)
<dholbach> pitti: rock on
<pitti> dholbach: works now? (it builds here)
<dholbach> yep
<dholbach> uploaded
<tepsipakki> Riddell: so, shouldn't this be fixed with an update?
<pitti> dholbach: danke sehr
<pitti> dholbach: I'll close the bug once I see the -changes mail
<Riddell> tepsipakki: if we can find a suitable "fix"
<cjwatson> efforts to munge /home like that should be done in the postinst with a version guard and || true
<cjwatson> Riddell: ^--
<tepsipakki> it is in the postinst
<tepsipakki> but /home is a normal directory during install
<Riddell> cjwatson: it is actually
<tepsipakki> so I'm not sure there is a way to go around that
<Riddell> I'm sure I consulted on this when adding it to the package, although I can't remember who with now
<pbn> okay folks when I'll have time tomorrow or later I'll go check my neighbour's computer and try that trick Riddell told me ... thank you, Riddell :)
<cjwatson> Riddell: ok ...
<superm1_> any archive admins about?  it appears that libpostproc0d is no longer in the archive, but several apps (vlc-nox & transcode come to mind) depended on it.  It appears to be superseeded by libpostproc1d.  Should a bug just be filed across any app that comes up like that to rebuild it?
<pygi> how do I kick upstream's ass if they play with endians too much? :P
<persia> superm1: Yep, and a -build1 uploaded.  It's nice to have all the relevant packages as separate tasks in a single bug.
<superm1_> persia, any easy way to find all the ones that need a rebuild?  apt-cache rdepends isn't handling it
<seb128> superm1_: use grep-dctrl
<superm1_> k thx seb128 
<seb128> dholbach: is there some recipes for that on the wiki?
<dholbach> seb128: unfortunately not
<persia> seb128: They disappeared in the UDS WIki cleanup.
<dholbach> http://wiki.ubuntu.com/MOTU/Recipes
<seb128> dholbach: I'll write one if nobody does it first then ;)
<pbn> also, where should I search for a possible backport of a "working" kppp for Ubuntu 6.06 ?
<dholbach> seb128, persia: https://wiki.ubuntu.com/UbuntuDevelopment?action=fullsearch&context=180&value=grep-dctrl&fullsearch=Text
<dholbach> that's all I can find
<dholbach> seb128: that's very nice of you
* seb128 hugs dholbach
* dholbach hugs seb128 back
<pitti> superm1_, persia: apt-cache unmet perhaps?
<pygi> seb128  is alive, seb128 is alive :)
<seb128> hey pygi
<pygi> hey seb128 ^_^
<pygi> how are you doing?
<seb128> pbn: maybe open a bug on https://launchpad.net/dapper-backports
<seb128> pygi: good, thanks, catching up with everything which happened while I was on holidays ;)
<superm1_> persia, who should i subscribe after I make the bug? u-u-s?
<persia> dholbach: Thanks.
<pygi> seb128, ok, I uploaded new libisofs, libburn, and brasero packages
<persia> superm1: U-U-S should only be subscribed once there are debdiffs for each package.  I'll get an example in a moment.
<superm1_> just a debdiff bumping the version number with a build1 applied to the end?
<pygi> seb128, ^_^
<pygi> seb128, now brasero actually works =)
<seb128> ah, nice
<pygi> with libburn & libisofs even :)
<seb128> I'll try that then ;)
<seb128> waouh
<pygi> newest versions of both ofcourse
<geser> superm1: yes (if there is no ubuntuX already), but please check if it builds
<pygi> gotta bug upstream to fix src/scsi tho as I can't build on ppc & sparc because of that, and patching would be big probably
<superm1_> geser, ok thanks
<Keybuk> ooh
<Keybuk> seb128: we patched gnome-system-tools to avoid using GiB? :p
<superm1_> geser if there is already an ubuntuX, should it be ubuntuXbuild1 still then?
<seb128> Keybuk: gnome-system-monitor you mean? yes
<geser> superm1: ubuntu(X+1)
<superm1_> k
<Keybuk> \o/
<Keybuk> wonder if I can get away with patching ifconfig? :p
<Keybuk> seb128: does it divide by 1024 or 1000? :p
<seb128> Keybuk: 1024
<ion_> The ugliest thing is that the Finnish locales use Mt, which is of course totally wrong. Its just something Windows and Finnish computer magazines have been using for years, so many think its a correct way to put it, as if standard units were somehow translatable.
<Hobbsee> sigh.  why do people *always* end up attacking launchpad when the admins arent around to deal with it?
<Keybuk> Hobbsee: verbally or physically? :p
<Hobbsee> Keybuk: er, physically
<Keybuk> Hobbsee: WFM?
<Hobbsee> Keybuk: https://bugs.launchpad.net/bugs/119467
<ubotu> Launchpad bug 119467 in kubuntu-meta "make non-essential packages Recommends and not Depends" [Undecided,Unconfirmed]  
* Hobbsee thought her inbox was on crack, for a minute there - it even came up with a spamassassin rating.
<thully> hi - I've identified an issue with the MacBook trackpad on feisty and gutsy tribe 1 - you can't change pointer acceleration *at all*
<Keybuk> thully: please use launchpad.net to file a bug
<thully> however, doing rmmod appletouch and modprobe appletouch fixes it until the next time you restart X
<persia> thully: DId you comment on the relevant bug after the last time this was discussed?
<thully> I did that - wondering if anyone may have a clue where this issue is...
<cjwatson> thully: (FWIW, you asked about whether there was a team concentrating on MacBook issues; I think that MacBooks are sufficiently mainstream now and well enough supported by stuff like the installer that they don't urgently need a separate team)
<Keybuk> thully: those people are more likely to respond to your bug report than answer questions here, this is not a support channel
<persia> thully: Wait then.  Someone will look at it as soon as they have time.
<thully> I just came here to confirm that doing an rmmod and modprobe of the appletouch module resolves the problem until X is restarted
<thully> which would seem to narrow things down a bit
<pygi> seb128, let me know if you got any troubles ^_^ I've fixed that libisofs error you reported
<Keybuk> thully: please add that information to the bug report
<thully> OK - is there anything else that may help to test in order to narrow down the issue?
<thully> I realize this is not a support channel - I actually wanted to help get this resolved (though diving TOO deep into the kernel source may be above me)
<bryyce> glatzor, excellent, I'll check them out
<seb128> pygi: k, will do
<thully> in general I'd just like to find a way to help fix these issues besides just filing the report - I can do a lot of experimenting here
<persia> thully: Also note that in the bug report - the developers may contact you to help test.
<thully> thanks - I figure I'll load up the gutsy tribe 1 iso I just downloaded and try a few things...
<mneptok> cjwatson: understood (re: VMWare). my concern is kernel/module questions as filtered through VMWare.
<thully> I'm not using VMware to test this one...
<thully> that was talking about general use - as I had resorted to VMware to AVOID issues like the aforementioned appletouch issue
<keescook> pitti: have others confirmed nvidia breakage with the kernel update?
<pitti> keescook: someone seb128 talked to apparently
<seb128> keescook: somebody I know mentioned it this morning, I'm not sure if he had to reboot a new kernel because the new was not booting though
<seb128> keescook: would it work in this case, or did the ABI or something changed which means the new restricted module would not work with the previous linux?
<keescook> seb128: afaiu, the ABI was bumped with 16.28 (two updates ago).  current update is 16.29 and didn't bump the ABI
<seb128> I'll ask for details and let you know
<keescook> I tested it with fglrx and it was okay -- I didn't have a feisty nvidia machine.
<seb128> he has an nvidia
<seb128> and the bug happened this week while I was on holiday, dunno when
<seb128> he told me he had to switch to nv to have xorg working again after the linux update
<mjg59> bryyce: Any objection to me uploading libpciaccess?
<bryyce> mjg59: not offhand - what's it for?
<mjg59> bryyce: Not at liberty to say yet :)
<jdong> can I get a core-dev sponsor for bug 110881?
<ubotu> Launchpad bug 110881 in ktorrent "[SRU]  Citical bug cherrypicks from SVN" [Undecided,In progress]  https://launchpad.net/bugs/110881
<jdong> u-m-s has been subscribed for almost two weeks to no avail
<bryyce> mjg59: is that a new package or does it go by a different name in launchpad?
<mjg59> New package
<mjg59> X is moving towards using it rather than hand-rolled PCI access
<mjg59> Since it has an API that doesn't suck
<bryyce> mjg59: cool, sounds good to me.  Thanks for letting me know about it :-)
<tepsipakki> mjg59: you'll grab it from master?
<mjg59> tepsipakki: Yeah
<mjg59> tepsipakki: ABI is supposed to be pretty much stable now
<tepsipakki> mjg59: ok, good
<seb128> keescook: I've asked him, -15 didn't boot and -16 doesn't work with nvidia, restricted-manager says there is no driver for the card
* pitti yays at Bug.delete_attachment(self, title_re, all=False), which is the last thing he needs from python-launchpad-bugs to implement the apport stuff
<pitti> dholbach: ^ I might require your pull/upload service again
<keescook> seb128: if he went from -15.27 to -16.29 he'll need to update l-r-m too.
<dholbach> pitti: rock and roll
<dholbach> pitti: looking in a bit
<pitti> dholbach: sorry, originally I thought it was too complicated and thus already asked you for the previous upload
<dholbach> pitti: no problem
<dholbach> is any work being done to get the new network-manager in? :)
<dholbach> pitti: did you push already?
<pitti> dholbach: pushed now
<pitti> yay, that paves the way for mass-deleting CoreDump.gz attachments
<dholbach> pitti: got it
<giskard> dholbach, how much new?
<dholbach> hey giskard - how's it going?
<giskard> dholbach, bad, in 1 week i will start exams
<dholbach> giskard: oh man - I wish you all the best with those!
<giskard> and i don't know something 
* giskard hugs dholbach 
* dholbach hugs giskard back
<giskard> http://www4.autistici.org/giskard/file/tesina/mappa_concettuale_tesina.html
<giskard> ops wrong paste but maybe you can understand what is this
<dholbach> looks like you have a bunch of things to do :)
<Hobbsee> erk.  dont mention exams.
<dholbach> pitti: uploaded
<dholbach> pitti: thanks a lot
<pitti> dholbach: thanks to you
<seb128> keescook: no, he went from 15.27 to 16.28 which didn't boot, kept using -15 then until the updates some days ago
<seb128> keescook: the new 16.29 boots fine again for him
<seb128> but then there is no nvidia working
<seb128> so it's using 16.29 with nv now
<pitti> yay stables :(
<cjwatson> pitti: interesting - what's the security on delete_attachment?
<seb128> pitti: I've just read the changelog quickly, I'm surprised by the number of changes going to security updates
<pitti> cjwatson: no idea really
<pitti> seb128: so was I
<keescook> seb128: I'm upgrading an nvidia feisty machine I found.
<cjwatson> seb128: see distro-team@ ..
<pbn> do you people know if there is  a non-broken pppd and/or kppp for 6.06 on this site: http://be.archive.ubuntu.com/ubuntu/dists/dapper-backports/
<pbn> I cannot add that line to sources.list and apt-get upgrade because obviously the machine cannot connect to the Internet ...
<pitti> pbn: neither ppp nor kppp have been put into any backports
<pbn> pitti: ouch, then it's a pain 
<pitti> pbn: it's easy to create one once it gets tested
<pbn> pitti: easy ? ah ?
<pitti> pbn: https://wiki.ubuntu.com/BackportRequestProcess
<Hobbsee> kppp is in main
<Hobbsee> there's a reason why noauth is usually commented though, in debian.README.
<Hobbsee> or was last i checked
<pbn> https://bugs.launchpad.net/dapper-backports/+bug/120054
<ubotu> Launchpad bug 120054 in dapper-backports "kppp: pppd crashes with return value 1 when called by kppp" [Undecided,Unconfirmed]  
<pbn> with that bug 120054 ... will someone make a backport of kppp to 6.06 ?
<ubotu> Launchpad bug 120054 in dapper-backports "kppp: pppd crashes with return value 1 when called by kppp" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120054
<pitti> pbn: now you need to test whether the gutsy, feisty, and/or edgy version fixes the bug, and confirm that the package works on dapper
<Hobbsee> it's fixed in gutsy
<pitti> pbn: and write the test results into those bugs
<Hobbsee> at least the noauth part is
<Hobbsee> touching /etc/resolv.conf is trivial, also
<pitti> pbn: after that's done, siretart or jdong will need to approve the backport (test it themselves)
<Hobbsee> pitti: if it's just uncommenting noauth, that's a SRU candidate
<pbn> yes but... if I install the gutsy or feisty version of kppp on 6.06 ... won't stuff break ? You know, different versions of many packages ?
<Hobbsee> no need to backport entire kde for it.
<pitti> Hobbsee: right
<Hobbsee> but there's a reason it's not done by default
<Hobbsee> or didnt used to be
<pitti> pbn: you need to build the source package on dapper, not install the feisty deb
<Hobbsee> i looked at this bug ages and ages ago
<pbn> pitti: ah. and where do I get the sources ? apt-get source ?
<pitti> pbn: apt-get source works if you have deb-src lines for feisty
<pitti> pbn: otherwise you just download it from archive.ubuntu.com (orig.tar.gz, diff.gz, and dsc)
<pbn> pitti: ... from a machine which does not have an internet connection ?
<Hobbsee> ah, here it is
<pitti> pbn: tricky :)
<Hobbsee> pitti: pbn http://rafb.net/p/MXHXgT95.html
<Hobbsee> for "security reasons"
<pbn> Hobbsee: thank you
<pbn> Hobbsee: ok so the "quick fix" is to uncomment noauth in /etc/ppp/kppp-options ?
<keescook> pitti, seb128: I'm not able to reproduce the nvidia problems locally.  -16.29 + nvidia binary driver works fine for me.
<Hobbsee> yeah
<Hobbsee> well, seems to be
<Hobbsee> read the entire readme for more info
<jdong> Hobbsee: how are you feeling to sponsor a ktorrent SRU today? :)
<Hobbsee> jdong: er...i'm not?
<jdong> lol
* Hobbsee doesnt do SRU's.
<heno> Where can I find a list of packages that have been removed completely from the archive?
<Hobbsee> heno: http://people.ubuntu.com/~ubuntu-archive/removals.txt
<Hobbsee> :D
<Hobbsee> (yay, i knew the answer to something) 
<heno> Hobbsee: thanks!
<Hobbsee> no problem
<pygi> Hobbsee, meh, stop that :p
<Hobbsee> pygi: stop what?  *looks around innocently*
* cjwatson fixes the rmadison backend to work with multiple packages
<Hobbsee> rmadison's...seriously cool.
<Hobbsee> cant decide whiihc i prefer -that, or madison-lite
<Skynet1984> clear
<JanC> I think it might be a good idea to put a warning in fstab in gutsy, that tells people to use UUID or LABEL, and not device names...
<pbn> you mean gutsy will no longer support device names ?
<slomo_> pitti: anything we can do about gs? :)
<Hobbsee> JanC: i hope grub2 handles UUIDS and such then
<pitti> slomo_: no idea really; I forwarded the mail to Till
<geser> pbn: they are still used in the background but it's not guaranteed that they stay stable across reboots
<slomo_> pitti: interesting that it built fine locally for me... let me retry with a clean source tree :)
<pitti> slomo_: ugh, indeed
<pitti> slomo_: it attempted to build three times today
<pitti> (on the buildd)
<slomo_> pitti: i saw it :) i got a mail for each try :P
<doko> pitti: the ia32-libs merge sounds like a pain ... any reason that you did merge the gtk bits?
<pitti> doko: some people asked for it, and having it in one package is much easier to maintain and keep in sync
<pitti> doko: the most painful part was to compare the horribly old rules from -sdl and -gtk against the current rules from ia32-libs
<doko> pitti: then why not kde as well?
<pitti> doko: OMG, there's yet another one?
<pitti> doko: yeah, we can merge that as well
<doko> yes, and then the source really gets a bit unmanagable ...
<doko> and you have to update the resulting source more often
<doko> I don't like it
<pitti> doko: -kde is not even in Debian, so it is like -sdl
<doko> anyway, leaving now ...
<pitti> doko: as if we had updated -kde and -gtk that often... once or twice per release should be enough, though (in any case)
<slomo_> pitti: still builds with everything up to date :)
<pitti> slomo_: weird
<slomo_> pitti: does gs require some fonts or whatever that might be missing in the buildds chroots but not on my system?
<pitti> anyway, dinner, bbl
<pitti> slomo_: does it work in a pbuilder?
<slomo_> no idea yet
<shawarma> I still need a core-dev with perl skills to check out https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/120040
<ubotu> Launchpad bug 120040 in lintian "Should not accept debian distros for ubuntu packages and vice versa" [Undecided,Unconfirmed]  
<geser> shawarma: I'm no core-dev but I looked at the patch
<shawarma> geser: Alright. I'm ready for the shouting. Let me have it. :)
<geser> if I'm not mistaken you broke some valid Debian distributions
<shawarma> Entirely possible. Which?
<cjwatson> shawarma: yeah, it's not quite right, although the Perl is fine
<elmo> you realise there are a bunch of packages in debian with ubuntu in the version string right?
<shawarma> Alright then. Well, my Debian-fu is not very strong either :)
<cjwatson> shawarma: -proposed-updates shouldn't be allowed for Ubuntu (just -proposed and the rest), but -proposed-updates, -updates, -backports, -security are fine for Debian
<shawarma> elmo: No, I didn't.
<geser> shawarma: stable-proposed-updates
<cjwatson> elmo: this is just Ubuntu's lintian though. (There is a bug somewhere about having it have two modes)
<shawarma> cjwatson: I just closed that one, actually.
<cjwatson> shawarma: haven't looked at your closing message, but I sort of think that should stay open
<shawarma> cjwatson: It suggested to do that in order to remove nmu warnings for Ubuntu packages, but that was fixed in some other way.
<cjwatson> it would be nice to get it properly merged upstream
<shawarma> elmo: I remember someone (in Debian) felt really offended that he had an package in his Debian system with "ubuntu" in the version string. I just assumed they "took care of it" after that.
<shawarma> elmo: I can't find any in unstable main..
<elmo> shawarma: I looked at rejecting the packages in dak, but there was too many examples already in the archive, and it seemed pointlessly harsh, esp. since Debian started treating Ubuntu as the upstream for some packages
<elmo> shawarma: update-manager
<shawarma> elmo: Yes. I'm an idiot.
<shawarma> elmo: That seems to be the only one, though. At least in main.
<iwj> Hah!  It built!
<shawarma> elmo: Anyhow, do you have any good ideas on how to detect it otherwise?
<iwj> Finally, after only fourteen zillion hours!
<shawarma> iwj: What did?
<iwj> My glibc hack for disk full testing logging.
<iwj> Who knows whether it'll actually work.
<elmo> shawarma: it's the only one now, there use to be more
<elmo> shawarma: I'm not sure there is a 'better' way to detect it - I don't have any solutions and also don't care what you end up doing to ubuntu's lintian - just pointing out it may be a problem
<ogra> shawarma, ltsp 
<shawarma> ogra: No.
<shawarma> ogra: It contains "debian", though.
<geser> shawarma: what about doing something similar to dpkg-buildpackage? it checks with lsb_release if it runs on Debian and Ubuntu (can be overwritten with a commandline option)
<ogra> oh, right, its the other way round tere
<shawarma> geser: The trouble is that there a many DD's that run Ubuntu. I want to acommodate their needs as well..
<shawarma> geser: automatically, that is.
<shawarma> geser: I thought this was sufficient, but once again, I'm back at square one. 
<geser> shawarma: don't forget that Ubuntu has also packages which are specific to Ubuntu and doesn't have a ubuntu in the version
<shawarma> cjwatson: My closing message just reads "it was fixed in version blah". The changelog of said version says (among other things) "checks/nmu: Don't set nmu flag if version has "ubuntu"".
<shawarma> geser: Really? Like what?
<cjwatson> shawarma: I think the version check is perfectly good, TBH
<cjwatson> shawarma: (random example) ubiquity
* shawarma lets out a deep sigh
<shawarma> cjwatson: Ok.
<cjwatson> lintian doesn't have to be utterly perfect here ...
<shawarma> cjwatson: Well, it's not like a warning from lintian makes anything fail..
<shawarma> Ok, so the ubuntu distro-regex is fine, agreed?
<shawarma> then I'll just use whatever's in Debian's lintian for the debian checks.
<cjwatson> shawarma: it's not ideal, but I think it'll be an improveent
<cjwatson> s/ee/eme/
<shawarma> cjwatson: Indeed. I've just uploaded a new patch to the bug report http://launchpadlibrarian.net/8068335/split_ubuntu_debian.diff
<slomo_> pitti: fails in pbuilder :) so it's a build dependency
<slomo_> pitti: damn
<pitti> slomo_: weird, only on i386?
<slomo_> pitti: the doc package is arch all
<pitti> slomo_: ah, -doc package
<geser> shawarma: more examples: ubuntu-calendar-*, ubuntu-{desktop,standard}
<shawarma> cjwatson: It looks weird, because it's the previous ubuntu version mixed the ubuntu and debian checks, and I'm now splitting them entirely again.
<shawarma> geser: Yes, and the kernel packages..
<slomo_> pitti: any idea what it could be? i don't feel like testing every single of my packages that i have installed :)
<pitti> slomo_: still, unless it's some really exotic font, shouldn't gs itself depend on fonts?
<cjwatson> shawarma: still looks wrong; -updates and -security should be allowed for Debian
<cjwatson> shawarma: hmm, not -updates apparently, sorry
<cjwatson> Debian's lintian has:
<cjwatson>                        or ($data->{distribution} =~ /\w+-proposed-updates/)
<cjwatson>                        or ($data->{distribution} =~ /\w+-security/))
<cjwatson> shawarma: so I'm on crack and you can ignore me :)
<shawarma> cjwatson: Feel like uploading it?
<cjwatson> sure, give me a minute
<shawarma> Super. Thanks!
<slomo_> pitti: probably :) and i don't think it's exotic... at least it worked with older gs :)
<geser> shawarma: there is no -proposed-updates in Ubuntu, only -proposed or -updates
<pitti> slomo_: that should be fixed in gs itself then; if you find out the package, please file a bug against ghostscript and milestone it
<shawarma> cjwatson: Did you upload it yet?
<carlos> Riddell: hi, around?
<Riddell> hi carlos 
<slomo_> pitti: is something frozen or why can't i just upload the fix? :)
<carlos> Riddell: I wonder whether there is any problem with digikam translations
<carlos> Riddell: we got .pot updates for Gutsy but no translation updates
<pitti> slomo_: oh, sure you can :)
<carlos> for Feisty, I think I had to do a manual upload
<cjwatson> shawarma: not yet?
<cjwatson> shawarma: fixing in place
<carlos> Riddell: forget that
<carlos> we got them and we imported them too
<cjwatson> +                   if ( $data->{distribution} !~ /^(gutsy|feisty|edgy|dapper|breezy|hoary|warty)(-(proposed|updates|backports|security))?$/ ) {
<slomo_> pitti: hah! gsfonts could be it... it's only recommended now :) let's test
<pitti> cjwatson: is that for something like dpkg-source, or vim?
<cjwatson> pitti: lintian
<Riddell> carlos: all sorted?
<cjwatson> shawarma: uploaded now with that change
<pitti> cjwatson: ah, ok; for vim I'd like to have UNRELEASED, too
<cjwatson> vim already does AFAIK
<shawarma> cjwatson: excellent. thanks.
<cjwatson> ICBW
<carlos> Riddell: not exactly, Jannick Kuhr says that we have old translations for it
<carlos> Riddell: and I thought we didn't import any .po file for gutsy
<pitti> cjwatson: UNRELEASED always appears in inverted red in vim, so I guess not
<cjwatson> looks like I am wrong
<pitti> (but *shrug*, not a biggie at all)
<carlos> Riddell: but I just checked our logs and found that we indeed imported the files for Gutsy
<pitti> cjwatson: let's just call that a feature then :)
<shawarma> pitti: Do we really not want it highlighted that way?
<shawarma> pitti: Exactly. I'd rather consider it a feature, actually.
<carlos> Riddell: so maybe we imported old files. Is that possible? that we didn't take latest KDE version for the source code in Gutsy?
<pitti> shawarma: it could be ... green!
<slomo_> pitti: if it is gsfonts shall i really depend on it in gs? :)
<cjwatson> pitti: I sort of like it that way. It helps me to remember to un-UNRELEASED it
<pitti> slomo_: in earlier days, gs-common pulled it in, so I guess that the lack of a direct depends is just an inadvertent side effect
<slomo_> pitti: ok... if it is gsfonts' fault i'll readd it :)
<pitti> slomo_: thanks muchly
<pitti> slomo_: I'll give back gstreamer tomorrow morning when the new gs is in the archive
<slomo_> pitti: thanks
<shawarma> pitti: *g* Yes, it could.
<cjwatson> iwj: did you ever get anywhere with getting debug output for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393704 ?
<ubotu> Debian bug 393704 in openssh-client "interactive client dies on ill-timed SIGWINCH" [Normal,Open]  
<slomo_> pitti: yep, works :)
<pitti> slomo_: awesome
<slomo_> pitti: i love it when guessing works that good ;)
<Riddell> carlos: digikam source package seems to contain all the .po files
<Riddell> carlos: 0.9.2 was only uploaded at the end of may
<Lure> carlos: digikamimageplugins were merged into digikam with 0.9.2 - this means that also translations are now in single file
<slomo_> pitti: uploaded :) maybe you can give back gstreamer later today already? :) or are you going to bed soon?
<Lure> carlos: digikamimageplugins (0.9.1) was recently removed from archive
<carlos> Riddell: yeah, my question is just whether it's up to date or not
<pitti> slomo_: binaries will need 2 hours 15 minutes to get into the archive
<carlos> Lure: oh, thanks for telling me it that way I don't approve the missing .pot files
<slomo_> pitti: ok, then tomorrow :)
<pitti> slomo_: at that time I'm probably already asleep, but you can also ask infinity 
<Lure> carlos: for refence (if needed): http://mail.kde.org/pipermail/digikam-devel/2007-March/011383.html
<carlos> Lure: well, the complain was more related to out dated .po files based on the .pot file that we have imported
<Riddell> pitti: is there a way to fix https://bugs.launchpad.net/ubuntu/+source/kde-i18n-nds/+bug/54581
<ubotu> Launchpad bug 54581 in kde-i18n-nds "missing language-pack-kde-nds for kde-i18n-nds_4:3.5.4-0ubuntu1" [Undecided,Confirmed]  
<Riddell> language-support-nds needs creating, or the recommends removing
<pitti> Riddell: hm, it's a valid locale, I wonder why it doesn't exist yet
<pitti> Riddell: please assign it to me and milestone it for tribe-2, I'll have a look later
<pitti> Riddell: only reason that I can see is that there are no po files for that package
<pitti> so it doesn't get created
<tepsipakki> mjg59: does xf86-video-avivo use libpciaccess? :)
<mjg59> tepsipakki: No comment :)
<tepsipakki> mjg59: hey, it was announced already :)
<mjg59> Oh, so it was
<mjg59> Heh. In that case, yes
<mjg59> It's in NEW
<tepsipakki> excellent
<mjg59> Unaccelerated right now
<agoliveira> Is someone there who can give me hand with d-bus? We're trying to figure out a problem here at Montain View.
<seb128> agoliveira: you have better chances to get a reply if you actually ask your question
<agoliveira> seb128: Sorry, I forgot to send the question itself but I think I got it.
<pygi> siretart, I'm back when you're around :)
<tepsipakki> mjg59: can't find it from the queue..
<mjg59> tepsipakki: Hm.
<cjwatson> mjg59: you forgot -sa
<mjg59> D'oh.
<tepsipakki> :)
<mjg59> Probably noobed that with pciaccess as well
<mjg59> I'll fix later
<cjwatson> looks like it mailed Matthew Garrett <mjg59@codon.org.uk> about it
<mjg59> Yeah, got the mail
<cjwatson> yes, same problem with libpciaccess
<mjg59> Ok. I suck :)
<tepsipakki> mjg59: I could push the packaging to git.d.o
<tepsipakki> ..tomorrow
<tepsipakki> bryyce: did you read the announcement on xorg@l.fd.o? :)
<bryyce> no (dealing with a raid failure this morning) which one?
<bryyce> ah, the r500 announcement
<bryyce> tepsipakkii, very cool :-)
<tepsipakki> yeah
* pitti bounces
* desrt directs pitti's energy to power the builders
<pitti> seb128: apport-retrace just closed its very first bug as duplicate automatically
<pitti> desrt: bah, I want to get this finished
<seb128> pitti: waouh ;)
<seb128> pitti: which one?
<pitti> seb128: just a test bug, nothing interesting yet
<seb128> k
* seb128 hugs pitti
<pitti> seb128: gutsy doesn't give us crashes, so I have to file my own :)
* mneptok closes the duplicate pitti hug from yesterday
<pitti> and the dup detection will only automatically work for newly filed crashes
<pitti> mneptok: :(
<pbn> heh duplicate hugs
<pbn> not bugs, hugs
<seb128> pitti: rock on ;)
<mneptok> pitti: the LTS hug from last June still gets critical updates
* pitti ponders how to interpret mneptok's last comment
<mneptok> you and me both.
<pitti> lol
* mneptok hugs pitti slighlty differently than the way seb128 hugged pitti
<mneptok> not a dupe!
<pitti> yay!
* pitti huggs mneptok 
<mneptok> 2 g's! not a dupe!
<pygi> seb128, are you around?
<seb128> pygi: sort of, going to stop the computer soon, why?
<pygi> seb128, just wanted to discuss one tiny thing
<seb128> sure ;)
<pygi> seb128, I think we should open iso files with nautilus-cd-burner by default instead of file-roller
<pygi> imho it's completely weird and unexpected behaviour
<seb128> good idea
<xhaker> crimsun, you there?
<pygi> seb128, what exactly do we need to patch to do that?
<seb128> pygi: need to change the defaults.list, I've just uploaded a new desktop-file-utils with the change
<gnomefreak> is Ubuntu Installer an automatic accept/decline for NEW packages?
<crimsun> xhaker: yes
<xhaker> ati sb450 regression from feisty 15 -> 16
<crimsun> xhaker: I need your alsa-info.sh url/output
<crimsun> (http://www.linux-sound.info/alsa/index.php?task=scripts)
<pygi> seb128, ok, thank you :)
<seb128> pygi: you're welcome
<xhaker> will do crimsun.. 
<pygi> seb128, imho much better now, and sorry for bugging ;)
<crimsun> xhaker: this belongs in #ubuntu, or open a query, please
<seb128> pygi: no problem, thank you for pointing it, it's better this way indeed :)
<pygi> seb128, ^_^
<mikmorg> does anyone know where i can find the Casper project source?
<pitti> mikmorg: 'apt-cache show-src casper' claims Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk
<mikmorg> pitti: Thanks a million :)
<pitti> which should really be https://code.launchpad.net/casper/trunk nowadays
<mikmorg> seems there is an issue with my driver update deb not loading
<mikmorg> from the wiki, i assume the loader is part of casper itself, not ubiquity
<mikmorg> \
<mikmorg> does ubiquity lay on top of casper, or vice versa?
<mikmorg> i'm very confused by some of the things i'm seeing :/
<evand> mikmorg: casper sets up the environment for ubiquity
<mikmorg> evand: ok, that helps. thanks.
<superm1_> evand, jetsradiem had been talking to you about a possible merge up of mythbuntu ubiquity changes if we cleaned them up to be more modular.  I havent spoken to him in a few days, what eventually came of that?
<evand> superm1_: Ubiquity isn't really set up for accepting such merges (that is, items that are not going to be the default), but I told him I'd look over the mythbuntu code
<superm1_> evand, Well my thought was having a third UI for us available, mythbuntu-ui that was a child based upon gtk-ui so as to not break things.  if the main ubiquity start script received something like ubiquity --mythbuntu then we could be started, otherwise follow as normal
<superm1_> and then we could use our own glade file and still be able to source all normal functions that are part of gtk-ui and still get all the partitioning changes that are going in
<superm1_> and override as necessary for our things
<evand> hrmm, you still have the problem of keeping things in sync, but that might be easier now that everything is built off of BaseFrontend.
<evand> cjwatson: thoughts?
<evand> erm, ignore most of what I just said.  I wasn't thinking.  It's still an interesting idea though.
<superm1_> evand, there are a few items that would still need to be sorted out if we did it that way (install.py has a few changes specific to us)
<superm1_> I'm a bit new to inheritance in python, but if its like C, I would imagine that the derived class would be able to override the base class functions (and hence override things like say a run() function that would normally be in gtkui.py.  things wouldn't be too bad to keep in sync then I dont think)
<pitti> superm1_: sure, you can override methods in Python classes
<evand> superm1_: take a look at frontend/base.py in Ubiquity for a rough idea.
<mikmorg> ok, after reading source for a while.. i'm officially stumped with my driver update deb
<superm1_> evand, ah then this would be a functional way for us to do things that are overridden in gtk-ui.py.  If we followed the same methodology with overriding the Install class in install.py, this could be feasible
<superm1_> evand, have you looked over the types of changes that we have yet in a debdiff or no?
<evand> superm1_: I glanced over the code briefly.  I'll take a much more thorough look tomorrow, though.
<evand> hopefully
<mikmorg> i have a disk with /ubuntu-drivers/2.6.20/tg3_i386.deb which i need to use with Feisty. If I insert the disk when told, and enter the live environment, and type dpkg -i /var/cache/driver-updates/tg3_i386.deb, it installs perfectly. However, casper is not installing it automatically as it is supposed to..
<superm1_> evand, i'll make a clean debdiff ( I just merged to your 1.5.3 release yesterday
<mikmorg> Is anyone familiar enough with casper to help me with this issue?
<superm1_> i'll give you a link in a few minutes 
<evand> superm1_: thanks
#ubuntu-devel 2007-06-13
<superm1_> evand, http://www.mythbuntu.org/~supermario/mythbuntu/ubiquity-mythbuntu.debdiff  (Note that doesn't have any of my ideas of modularization off gtk-ui.py implemented.  If you like the idea of doing that, I'll be glad to give it a shot)
<evand> superm1_: thanks, I'll let you know
<superm1_> thanks evand 
<cjwatson> superm1_: that's possible but I'm really more worried about the glade file
<cjwatson> merging that will be a right mess
<superm1_> cjwatson, indeed
<cjwatson> I'd like there to be a way to split the glade file up into one file per page somehow without affecting the actual layout of the UI, and that way merging would be more sensible
<superm1_> cjwatson, is there a way around that that you thinkg can work?
<cjwatson> but I have never got anywhere with actually doing that
<superm1_> is it on your ubiquity roadmap though?
<cjwatson> until that happens, I don't want radical UI changes to be merged into core
<cjwatson> not at present, but contributions welcome
<cjwatson> mikmorg: I am, but it's late; will you be available tomorrow?
<superm1_> after getting the rest of our changes in, I'll see how much work that would be.
<superm1_> cjwatson, would you be alright if we committed our package as ubiquity-mythbuntu to universe then until things are ready enough to merge to core?
<cjwatson> superm1_: I think the rest of your changes ought to be contingent on this
<cjwatson> superm1_: I guess so, provided package names don't clash and it's maintained as a bzr branch
<superm1_> yes its in our bzr branch atm.
<superm1_> for this release cycle, do you anticipate a lot of changes to the glade file?
<cjwatson> always
<cjwatson> my worry about ubiquity-mythbuntu (and, btw, have you run that by trademarks@ubuntu.com?) would be that it would be hard to keep it in sync with the core in the ubiquity package if packaged normally
<cjwatson> it might be best to include the whole thing in the ubiquity-mythbuntu binary package and conflict with all the ubiquity* packages rather than doing the frontend separation thing
<superm1_> I did a merge last night from 1.4.2 to 1.5.3 ubiquity + our changes, and it indeed was very messy
<mikmorg> cjwatson: hi
<superm1_> sabdfl_ gave us the ok on the mythbuntu name at the last CC meeting
<cjwatson> ok
<superm1_> but i haven't directly ran it by trademarks@
<cjwatson> if sabdfl says it's ok, I doubt there's a need :)
<mikmorg> cjwatson: sorry i was afk for a bit, i think i may have found an issue in casper, with 40install_driver_updates
<cjwatson> mikmorg: it would not surprise me; that feature wasn't fully tested :-/
<mikmorg> he
<mikmorg> cjwatson: thanks.
<cjwatson> mikmorg: place to start would be to boot with break=top, then run:
<superm1_> cjwatson, i'll set our packaging up then to conflict with all ubiquity-* packages and provide our own ubiquity-mythbuntu-* for now
<mikmorg> cjwatson: I'm not sure if my co. wants me to pursue this, as it wouldn't help us directly if I did.. but I may take a look off-hours
<cjwatson> sed -i 's,/bin/sh,/bin/sh -x,' /scripts/casper-premount/10driver_updates
<cjwatson> exit
<cjwatson> then get hold of /var/log/casper.log after boot
<superm1_> cjwatson, in migrating to a glade file per page, your thinking of moving away from GTKNotebook then?
<cjwatson> superm1_: we've separately thought about moving to GtkAssistant, but I'm not sure it needs to be tied to that
<cjwatson> superm1_: the per-page glade files could just have some kind of toplevel thing that gets stripped off at run-time
<cjwatson> just for the sake of the interface builder
<superm1_> ah that can make sense
<superm1_> and then merge them all back in
<cjwatson> right
<superm1_> o
<superm1_> can you put them back into a notebook that way too then?
<cjwatson> mikmorg: failing that, if you could share the .deb you've been using to test it, we could take it from there
<superm1_> as in copy a pygtk gtknotebook page from one glade to another
<cjwatson> superm1_: I don't see why not; after all glade builds the notebook at run-time anyway
<cjwatson> you take a widget and add it as a page
<superm1_> i'll investigate this soon then.  it should be fairly feasible in this thought process
* macd foo
<mikmorg> cjwatson: sorry for being afk, i was discussing the possibility of getting around it in feisty :/
<mikmorg> unfortunately, doesn't seem like we can
<mikmorg> not without too much pain, anyway
<cjwatson> mikmorg: hard to say without having got far enough to know what the problem is
<cjwatson> mikmorg: if it turns out to be a casper bug, chances are you could just build an updated initrd with a casper patch applied and remaster the CD with that
<mikmorg> cjwatson: understood. In any case, I think I may need to file a bug
<cjwatson> certainly
<cjwatson> please let me know the bug number
<mikmorg> cjwatson: respinning costs too much at this point
<mikmorg> cjwatson: I definitely will.
<mikmorg> cjwatson: I will also include a link to the driver disk iso
<cjwatson> thanks, that would be perfect
<cjwatson> sorry about this, I very much want to get it working PROPERLY for gutsy
<mikmorg> cjwatson: So do we (dell)
<cjwatson> aha
<cjwatson> doubly so then :)
<cjwatson> we can talk about solutions once we've investigated; with luck it'll be something workaroundable
<txwikinger> Has the hugging started?
<mikmorg> cjwatson: Thank you for your assistance.
<cjwatson> mikmorg: no problem
<cjwatson> Tim was actually due to come up with a test case so we could do a proper end-to-end on this
<cjwatson> no harm in shortcutting ...
<mikmorg> cjwatson: Where does Casper track its bugs?
<cjwatson> mikmorg: https://bugs.launchpad.net/ubuntu/+source/casper
<mikmorg> Thanks.
<pygi> siretart, around?
<siretart> pygi: yes, but not for that long
<pygi> siretart, oki, you needed me for something while I was away
<pygi> siretart, so fire away
<cjwatson> txwikinger: might be a bit quiet until Europe wakes back up
<pygi> cjwatson, but europe is awake =)
<cjwatson> I mean without quite so much assistance from coffee
<pygi> cjwatson, I never drink coffee? :P
<cjwatson> it may not be Ubuntu, but in my off hours I'm making a reasonable dent in both Debian bug 18452 and Debian bug 29448
<ubotu> Debian bug 18452 in man-db "man-db: save cat pages in background?" [Wishlist,Open]  http://bugs.debian.org/18452
<ubotu> Debian bug 29448 in man-db "man-db: No databases for non-English man hierarchies" [Wishlist,Open]  http://bugs.debian.org/29448
<cjwatson> maybe I will nail 18452 before its tenth birthday!
<pygi> haha :)
<pygi> cjwatson, it took you for years to respond to a comment :p
<cjwatson> pygi: what, on 18452?
<pygi> yup
<pygi> s/for/four
<cjwatson> pygi: in my defence, I wasn't the maintainer until 2001
<cjwatson> and the package was in a horrible state when I took it on :P
<pygi> cjwatson, haha :)
<StevenK> Ahh, 2001. Back when we would upload to Debian by pushing the package uphill. Both ways. In the snow!
<pygi> cjwatson, but 4 (!) years :P
* pygi quickly hides =)
<txwikinger> cjwatson: I am in Europe :D
<pygi> txwikinger, same :P
<pygi> 1:37AM
* pygi goes back to fixing stuff
<cjwatson> hah, and we can now close Debian bug 50612 as well, a mere 7.5 years on
<pygi> cjwatson, that's nothing :)
<pygi> If it ain't more then 10 years, it's not worth the effort to close it :p
<cjwatson> Ubuntu hasn't had time to accumulate *really* crusty bugs yet
<pygi> then we shouldn't close any bug :P
<pygi> good night
<Hobbsee> wtf was uploaded???
<mjg59> ?
<ajmitch> hi to you too, Hobbsee 
<Hobbsee> hi ajmitch 
<ajmitch> what was that outburst over?
<Hobbsee> my system is at 100% CPU on both cores, fan on, when usually it would be doing 2% or something
<Hobbsee> and it's very very laggy
<ajmitch> ah
<mjg59> Hobbsee: top?
<Hobbsee> cant see what it is yet
<Hobbsee> it's normal processes - bzip2, kopete, konversatino
<Hobbsee> but they never urn this high
<StevenK> No DMA?
<Hobbsee> not sure.  i didnt change it
<Hobbsee> wow, even dpkg is at 100%
<Hobbsee> (it's behaving like ti's got 128mb of ram or something!)
<mjg59> Is the load being accounted to processes or to the system?
<Hobbsee> as in, is it at CPU% or teh entire system load?
<Hobbsee> ti's both
<mjg59> In top, does the CPU line have high %us or high %sy?
<mjg59> That tells you whether it's time spend in the kernel or time spent in userland
<Hobbsee> mjg59: Cpu(s): 59.5%us, 11.8%sy,  0.0%ni, 26.1%id,  0.2%wa,  2.1%hi,  0.3%si,  0.0%st
<mjg59> Hm. Hard to tell, then.
<Hobbsee> impressive load averages.  top - 11:19:40 up 15 min,  1 user,  load average: 3.11, 3.92, 2.77
<Hobbsee> i couldnt even get brandon's that high when it was building multiple blocks of kde
<StevenK> Turn off DMA and then try it. :-P
* Hobbsee --> brb
<Hobbsee> oookay, that's better.
<Hobbsee> mjg59: i dont know *what* that was, but that was weird.
<Hobbsee> doesnt take 3 seconds for any screen redraw to take place, fan isnt constantly on, and entire system isnt behaving as if it's on 128mb of ram.     yay!
<StevenK> Hobbsee: You rebooted?
<Hobbsee> yeah
<Hobbsee> tried the windows solution, when nothing else became obvious
<mikmorg_> does anyone know why apt-cdrom would hang in casper when booting? Granted, this is not on any gold CD, but I remastered Ubuntu, and added 'piix' to the initrd module loader.. as that is a CD-ROM driver, it could have something to do with it.
<mjg59> Does it work if you don't do that?
<mikmorg_> It seems apt-cdrom hangs as it requests a name for the CD
<mikmorg_> the Please provide a name for this Disc prompt gets put into the casper.log file,
<mikmorg_> mjg59: I haven't tried remastering another disk with taking my change out.. its my next step, assuming i feel like wasting another CD.
<mjg59> If you can reproduce it without hacking the image, that's probably interesting
<mikmorg_> hmm
<mikmorg_> I have a golden CD that works fine
<mikmorg_> so I'm not sure where the problem is, but I think it has something to do w/ piix being loaded.
<mikmorg_> Which begs the question - why did they stop loading the piix driver in Feisty?
<mikmorg_> Edgy loaded it :p
<mikmorg_> not forcibly, albiet
<mjg59> Because it's driven by ata_piix now
<mikmorg_> mjg59: the answer I suspected..
<mikmorg_> mjg59: However, I have an IDE CD-ROM that won't load in ata_piix
<mjg59> Sounds like a kernel bug
<mikmorg_> true, but it gets fixed again in 2.6.20-16
<mikmorg_> of course, working with gold, i want 2.6.20-15 to work (which is why i'm attempting to backport the changes by loading the old piix).
<mikmorg_> anyway, its messy. I was just curious if there were any undocumented concerns with apt-cdrom
<Amaranth> mikmorg_: wouldn't it be easier to add 2.6.20-16 to your cd?
<mikmorg_> Amaranth: yes :)
<mikmorg_> .. but thats too easy.
<mikmorg_> so, it seems apt-cdrom isn't stopped from potentially requesting user input in casper-bottom/41apt_cdrom
<mikmorg_> i wonder why it asked me this time, but not on gold...
<mikmorg_> very odd :/
<mikmorg_> nevermind.. found it
<mikmorg_> apparently you have to have a '.disk' directory in the root, and since its hidden, my copy must not have included that.. forcing apt-cdrom to request information it didn't get automatically :
<mikmorg_> thanks for the tips though
<fabbione> morning
<Hobbsee> morning fabbione!
* fabbione yawns
<pitti> Good morning
* StevenK waves to pitti
<shawarma> morning, pitti
<pitti> hey shawarma, moin StevenK 
<Hobbsee> morning pitti!
<Hobbsee> morning shawarma 
* pitti hugs Hobbsee 
* Hobbsee hugs pitti 
<Hobbsee> pitti: save me from the crazy people tomorrow!
<pitti> slomo: I just kicked gstreamer, ghostscript looks good
<pitti> Hobbsee: context?
<Hobbsee> pitti: i have to work tomorrow.  http://community.livejournal.com/customers_suck/22067011.html
<Hobbsee> after my exam
<slomo> pitti: thanks
<pitti> Hobbsee: if it comforts you, I work with crazy people every day :)
<Hobbsee> not that type of crazy
<crimsun> pitti is slyly implying his own sanity.
<coNP> Hey, where is the hug day? Here or in #ubuntu-bugs? Neither topic contains this, however this topic says bug triaging in #ubuntu-bugs, whereas mailing lists say HUG day is held here...
<pitti> coNP: here AFAIR
<Hobbsee> either/both
<Hobbsee> here was the new plan, iirc
<coNP> ... seems as an endless recursion :)
<Hobbsee> most people are in both channels
<persia> coNP: Basically, working on bugs during hug day gets you hugs.  Talk about triage in -bugs and fixes in -devel.
<coNP> persia: okay, thanks
<Hobbsee> it's dholbach!  look busy, everyone!
<dholbach> good morning
<dholbach> HAPPY HUG DAY
* dholbach hugs Hobbsee
* Hobbsee hugs dholbach back :D
<encompass> Happy Hug Day!
<pygi> Hobbsee, :P
<dholbach> encompass: and the same to you!
* Hobbsee demands pygi fix all the bugs.
<pygi> Hobbsee, I am fixing all the bugs
<Hobbsee> good :)
<gnomefreak> if we get hugs for triaging what do we get when reporting bugs ;)
<pygi> Hobbsee, triage k3b if you've got time then
<Hobbsee> gnomefreak: a boot in the rear.
<pygi> too many bugs
<Hobbsee> gnomefreak: for every bug you file, you need to traiage at least 2.
<persia> gnomefreak: Um.  You're going to fix it right after, right?
<Hobbsee> pygi: i dont - exam tomorrow
<gnomefreak> persia: sadly yes i will b working on it today
<encompass> dholbach: thanks
<encompass> how do I get started?
<Hobbsee> hiya mvo 
<mvo> hey Hobbsee
<encompass> where can I help?
<pygi> Hobbsee, ah, oki, exam every day here
<dholbach> encompass: https://wiki.ubuntu.com/UbuntuBugDay/20070613 might be a good start
<slomo> pitti: built fine :)
<pitti> yay
<pitti> Hobbsee: customers suck> argh
<StevenK> Heh heh
<Hobbsee> pitti: yep
<Hobbsee> ah there we go.  LJ cuts done.
<Hobbsee> pitti: it keeps me sane.  at least a bit.
* Hobbsee blames StevenK's wife for that one.
* mdke_ mornings
<Hobbsee> morning mdke_!
<jamesh> pitti: ping?
<coNP> dholbach: should I edit the wikipage above if I started to triage a bug / marked package? Or only if it is donw?
<dholbach> jamesh: good work on gnome-vfs-obexftp!
<dholbach> jamesh: I just uploaded it to gutsy
<jamesh> dholbach: cool!
<dholbach> I thought it didn't work, but then I found out that I hadn't paired my mobile phone with my laptop :)
* pygi got his CLI IM telepathy client working ^_^
<jamesh> dholbach: the README file now contains useful information about that, btw :)
<pitti> jamesh: hi
<dholbach> jamesh: ah nice ... of course I didn't read the README in advance :)
<jamesh> pitti: does your dbgsym repository contain debug symbol packages for stuff released through feisty-security?
<pitti> jamesh: it should now
<jamesh> pitti: I looked in http://people.ubuntu.com/~pitti/ddebs/pool/main/p/postgresql-8.2/, but didn't see anything for 8.2.4-0ubuntu0.7.04
<pitti> jamesh: http://people.ubuntu.com/~pitti/ddebs/dists/feisty-security/main/binary-i386/Packages.gz has a bunch of stuff, but apparently it's not complete
<pitti> jamesh: I only fixed the treatment of pockets and multiple releases about two weeks ago; before that, some stuff did get lost unfortunately
<jamesh> pitti: ah.
<jamesh> pitti: I guess I can try temporarily downgrading libpq5 then
<jamesh> pitti: or wait til the next Postgres security vulnerability :)
<pitti> jamesh: if you only need dbg symbols for the library, that works well, yes (the client lib wasn't affected by security updates)
* varka hugs dholbach for remembering bug #1 on the list 8)
<ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
<dholbach> varka: oh, I didn't write that list initially - I think bdmurray was that
<dholbach> varka: but thanks for the hug :)
* dholbach hugs varka back
* varka hugs bdmurray also .oO(every hug is sacred every hug is good..) ;)
<jamesh> pitti: that's useful to know.  The problem I'm tracking is just on the client side
* Hobbsee gets no hugs.
* Hobbsee hasnt triaged any bugs today
<pygi> Hobbsee, you evil thing! :)
<Hobbsee> i closed 6+ yesterday
<coNP> "What bug do you want to triage today?" 
<Hobbsee> that's not good neough?
<pygi> Hobbsee, nop
<Hobbsee> there was one even milestoned.
<pygi> so? :P
<Hobbsee> (mind you, i milestoned it :P)
<pygi> nop,not good
<Hobbsee> awww
<dholbach> pitti: is there a bug open about apport (or something having to do with it) leaving ~/core files lying around?
<pitti> dholbach: 0-byte files?
<dholbach> yes
<dholbach> good, just wanted to make sure you knew about it already
<pitti> dholbach: that's with 2.6.22-6.13, right?
<dholbach> pitti: yes
<pitti> dholbach: it might be a fallout from bug 119267
<ubotu> Launchpad bug 119267 in linux-source-2.6.22 "apport patches for CORE_REAL_RLIM and limit overriding do not work any more" [High,In progress]  https://launchpad.net/bugs/119267
<dholbach> ah ok
<pitti> dholbach: I noticed it myself, though, and it made apport's test suite fail
<dholbach> ah ok
* dholbach hugs pitti
<pitti> dholbach: if we get a kernel with a fix, I'll test it again and see what produces them
<dholbach> ok super
<bryce_> pitti, ever been to Palazzo Pitti in Florence?
<pitti> bryce_: I don't think so :)
<bryce_> I'm reading a history of the medici, and keep running into references to pitti palace, so I keep wondering.  ;-)
<dholbach> pitti: but Pitt street in Sydney :)
<bryce_> you should do what I do, when asked about any relationship to 'Bryce Canyon'.  
<bryce_> "Yes, it's named after me, of course."
<pitti> bryce_: heh, indeed; and I *have* been in Bryce Canyon, and it was one of my two favourites (besides Yellowstone)
<pitti> bryce_: I liked this place in Sydney, though: http://people.ubuntu.com/~pitti/tmp/martinplace-pittstreet.jpg
<bryce_> hehe
* varka hugs Hobbsee for the 6+ yesterday and especially for that funny - i know it wasnt meant as such - livejournal-article ;)
<Hobbsee> :)
<Hobbsee> oh it was :)
<Hobbsee> varka: http://community.livejournal.com/metaquotes/5833841.html is great oo
* bryce_ waves to seb128
<pygi> hey seb128 
<dholbach> hey seb128! HAPPY HUG DAY!
<Hobbsee> hiya seb128 
* dholbach hugs seb128 ecstatically
<Hobbsee> HAPPY FREEZING DAY
<seb128> morning bryce_ pygi dholbach Hobbsee
<seb128> Hobbsee: my weather applet indicates 19C, it's not freezing ;)
<varka> Hobbsee: oh, i think my english is quite to poor to understand that article completely but thanks anyway
<dholbach> 18C here
<Hobbsee> seb128: it's 10C here, or there abouts
<Hobbsee> seb128: i dont do cold weather.
<varka> 23 degrees already here
<`23meg> hi all
<Hobbsee> nice...i'll swap
<`23meg> 35C here
<Hobbsee> hiya `23meg 
<Hobbsee> `23meg: i'm jealous.
<seb128> Hobbsee: there is no freeze starting today, is it?
<`23meg> hi Hobbsee 
<Hobbsee> seb128: no - just temperature
<`23meg> Hobbsee, do you say "g'day mate"?
<Hobbsee> seb128: unless you count Hobbsee --> FrozenHobbsee
<seb128> :)
<Hobbsee> `23meg: not usually together.  i'll sometimes call people mate though
<Hobbsee> then remember that its' an aussie thing
<bryce_> it is??
<Hobbsee> i believe so
<`23meg> it's the most common greeting in Australia
<Hobbsee> of course.  we're teaching our pet kangaroos to say it, too.
<`23meg> everyone says it all the time
<bryce_> ah, I must just irc with too many aussies then ;-)
<`23meg> maybe the cockatoos
<Hobbsee> heh
<bryce_> obviously just a consequence of staying up too late in the PST timezone ;-)
<Hobbsee> timezones are stuffed.
* Hobbsee seems to be living part of au day, and then most of european day too.
<Hobbsee> bryce_: wha'ts the current PST time?
* Hobbsee doesnt do PST either.
* Hobbsee does AEST, any other australian time, and UTC.
<Hobbsee> er, and london and german
<Hobbsee> occasionally
<Hobbsee> where they're listed on kclock
<bryce_> Hobbsee: 1am
<bryce_> hacker hour!
<Hobbsee> yep
<Hobbsee> ahhh.  US-type time.
<bryce_> time to get all that funky code checked in
<pitti> infinity: do you have an idea why http://yellow.buildd/~buildd/ddebs/20070609/ does not have the libc6 dbgsyms? (it only has one package at all); https://launchpad.net/+builds/+build/346590 shows that glibc was built at that day on yellow
<Hobbsee> hrm.  perhaps i am colder than i realised.
<gnomefreak> Hobbsee: is there a way to view sparc query for a package (it seems to have issue building)?
<Hobbsee> i cant actually write a SMS
<pitti> gnomefreak: 'view sparc query'?
<Hobbsee> gnomefreak: as in, the sparc biuld log?
<gnomefreak> yes
<pitti> gnomefreak: the build logs are public, and you can even watch the builds live
<gnomefreak> where do i find that?
<gnomefreak> im on the source page atm
<pitti> gnomefreak: https://launchpad.net/ubuntu/+source/<sourcepackage>
<Hobbsee> click on the version that you want to view - the number
<pitti> gnomefreak: click on the version you are interested in, then on the build architecture
<gnomefreak> yeah im there it doesnt give really anything
<pitti> gnomefreak: which package?
<asac> pitti: i think gnomefreak wonders about the sparc backlog 
<Hobbsee> it gives you a sparc link, click on that
<gnomefreak> maybe because its needs building
<Hobbsee> ahhh
<asac> is sparc fully utilized? have there been issues?
<pitti> gnomefreak: so, please reformulate your question to be something concrete
<asac> e.g. gnash hasn't even been touched
<pitti> gnomefreak: you need the sparc build log of a particular package?
<pitti> gnomefreak: or need to know which packages need to be built on sparc?
<gnomefreak> it needs to be built for iceape
<gnomefreak> i thought it failed but seems it just hasnt been tried
<pitti> gnomefreak: https://launchpad.net/+builds
<pitti> gnomefreak: both sparc buildds are just busy
<gnomefreak> ah ok i see now
<asac> ... building glibc :)
<gnomefreak> yep
* gnomefreak saves that page :)
<gnomefreak> ty pitti 
<pitti> gnomefreak: you're welcome
* txwikinger2 is looking for Bugs to hug
<pitti> hi txwikinger
<txwikinger2> hi pitti
<fabbione> Keybuk: got a minute? i am having a very stupid issue with multipath-tools not loading dm-mod at boot time and failing to do it's job.... what's the best place now to trick these kind of things?
<pitti> txwikinger: https://wiki.ubuntu.com/UbuntuBugDay/20070613 has some
<txwikinger2> Yep pitti.. already there ;)
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Tribe-1 released | Hug Day! https://wiki.ubuntu.com/UbuntuBugDay/20070613
<Keybuk> fabbione: to load at boot time?  force_load_modules in the initramfs hook is the usual way
<fabbione> Keybuk: hmmm ok... thanks
<fabbione> Keybuk: oh... right... nevermind.. found it..
<fabbione> it used to be done by the initscript we killed
<fabbione> oh feh....
* fabbione HEAD -> WALL
<Keybuk> fabbione | head | wall? :p
<fabbione> Keybuk: yeah kind.. i think i just found a frigging annoying bug....
<fabbione> the old init script took care of modprobing.. and it was ok
<fabbione> now that we moved to udev, there is nothing modprobing it directly
<fabbione> if not because there is other stuff loaded, like lvm2
<fabbione> the problem shows only when you install plain multipath-tools
<Keybuk> ahh
<Keybuk> yeah
<Keybuk> the whole loading of modules with unattached hardware issue is an interesting one
<fabbione> i guess i could just load it from the udev rule...
<fabbione> and prepare a feisty SRU... *srhug*
<fabbione> mp-tools are not initramfs.. and they don't need to be
<Keybuk> how would loading it from the udev rule help?
<Keybuk> usually the udev rules don't happen until the module has been loaded
<fabbione> the udev rules is executed each time there is a real device showing up .. like sda...
<Keybuk> ahh
<Keybuk> yes, that would make a lot of sense
<fabbione> basically something like:
<Keybuk> I've been thinking about extending 90-modprobe.rules for this case
<fabbione> - real device appear
<fabbione> - add it to the multipath pool
<Keybuk> since we have sufficient vol_id information, we could optimistically load dm-mod, dm-snapshot, dm-crypt, etc.
<Keybuk> does loading the module cause something to be created that you can hook a udev rule off?
<fabbione> nope...
<Keybuk> ah, so that needs working out
<fabbione> dm-multipath is a plugin 
<fabbione> there is no extra device
<Keybuk> because otherwise you do the modprobe, and you can't guarantee that the next command will be able to use the module yet
<fabbione> and the devices that appear are in /dev/mapper...
<Keybuk> is there a next command?
<Keybuk> (to set up the devicemapper stuff)
<fabbione> Keybuk: see /msh
<fabbione> msg even
<fabbione> the lines before that are irrelevant for this case (so you don't ask why there is a label ;))
<North>  /msh
* heno goes off looking for some interesting bugs
<heno> erk, the wiki is slow and error prone for tracking bug day activity
<heno> we need a bugday tracker ...
<fabbione> dear world, thanks for exploding right in my face...
<popey> I have a machine that kernel panics when I modprobe a particular module, i cant see the whole panic message because it goes off the top of the screen. i tried using "vga=ask" on boot to set mode to something higher, but part way through the boot process it gets reverted back to 80x25! Anyone know what does that and why? and more importantly how else I can capture a kernel panic message?
<azeem> popey: serial console
<popey> azeem: it's a laptop, there is no serial console
<azeem> oh, wrong channel anyway
<popey> what? me?
<popey> azeem: so tell me, where should I ask that question?
<pygi> siretart, morning
<siretart> hey pygi 
<fabbione> Keybuk: it looks like that modprobing in the udev rule is fine as timing goes.
<fabbione> now the worst thing to check... does it affect feisty too..?
<fabbione> or this is due to a kernel behaviour change...
* fabbione rolls the dices
<pygi> siretart, how are you doing?
<siretart> pygi: oh, fine
<Keybuk> fabbione: it's interesting that libdevmapper doesn't modprobe itself
<cjwatson> pitti: I'm trying to figure out what's going on with the retrace of bug 113033
<ubotu> Launchpad bug 113033 in openssh "[apport]  ssh crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/113033
<cjwatson> pitti: the top frame of the broken retrace has the same address as the top frame of the original stacktrace, which is in the dynamic linker
<cjwatson> pitti: I don't understand how it could be going wrong inside the dynamic linker like that
<cjwatson> pitti: unless the fact that ssh is built with -fPIE in feisty is breaking retracing?
<fabbione> Keybuk: might be a change in gutsy.. i don't remember feisty being affected by this problem.. but i am checking now
<pygi> siretart, nice
<pitti> cjwatson: looking
<pitti> cjwatson: according to ProcMaps.txt, the crash is actually in /lib/ld-2.5.so
<pochu> Happy Hug Day!!
<pitti> cjwatson: darn, my amd64 retracer log only starts at May 21, so it's not there; I'll retrace it manually
<pitti> cjwatson: and we lost the libc6 debug symbols for feisty unfortunately
<cjwatson> pitti: well, /lib64/ld-linux-x86-64.so.2 -> /lib/ld-2.5.so
<pitti> cjwatson: I made ddeb-retriever smart enough to really work with multiple releases now, before there was a race condition and manual switching involved
<pitti> ah, right
<cjwatson> some of the addresses in the trace are on the stack, which is weird
<cjwatson> I wonder if it's just jumped off into oblivion
* fabbione sighs
<cjwatson> pitti: I tried retracing on ronne and got the same result
<fabbione> Keybuk: feisty is the same.... it doesn't autoload the module...
<pitti> WARNING: libc6-dbgsym is not available
<pitti> whine
* fabbione grrrrrrrrs
<pitti> cjwatson: how much work should we invest into that crash? we could attempt to rebuild glibc in a feisty chroot to get dbgsyms which might or might not match
<cjwatson> pitti: *shrug* it's just another on the list, nothing massively special
<cjwatson> only reason to rebuild glibc would be if you think it might be useful for other packages
<pitti> cjwatson: but if it is that broken anyway (IP in .stack) then it won't give us much, I guess
<pygi> dholbach, thanks
<cjwatson> I'll ask for reproduction on gutsy
<shawarma> pitti: Have you asked around if someone perhaps has it cached?
<dholbach> pygi: brasero upload?
<pygi> dholbach, yup
<pitti> cjwatson: desktop team isn't terribly interested in feisty crashes any more, so I didn't do anything about it so far
<pitti> shawarma: no, I didn't
<dholbach> pygi: no problem
<pitti> shawarma: will do, good idea
<pygi> dholbach, I wanted to look after it today, but since you did ... ^_^
<pygi> dholbach, anything I could do for you?
<cjwatson> openssh just jumped forward three upstream versions, so I guess I won't be interested for long either, but I was just going through the bug list
<dholbach> pygi: join the HUG DAY
<pygi> dholbach, hardly. exam soon :) But I fix bugs everyday ^_^
<dholbach> rock
<dholbach> :-)
<pygi> dholbach, ^_^
<pygi> dholbach, gabble 0.5.5 (in feisty) is pretty unstable :(
<pygi> same with that telepathy-glib in there :(
<dholbach> pygi: if somebody steps up to extract small and focused patches from new upstream releases, we can go through the stable release updates procedure
<dholbach> pygi: we can't just backport all of it
<pygi> dholbach, I understand, yea
<pitti> shawarma: sent
<pitti> cjwatson: so, let's wait a few days whether the dbgsyms turn up again, and then we can reattempt it
<cjwatson> pitti: ok
<pygi> dholbach, lemme look up malone's bug list on gabble
<pygi> meh, one bug reported
<pygi> I guess people file bugs against applications that use it then
<fabbione> can somebody please add feisty-updates as milestone in LP?
<Keybuk> fabbione: no
<Keybuk> the bug should have a feisty task added
<Keybuk> edit the url to include /feisty/ and click the button that appears
<pygi> dholbach, mind re-enabling me in telepathy team pls?
<dholbach> pygi: will you re-subscribe to the mailing list?
<pygi> dholbach, sure, if you gimme the url to it :)
<dholbach> http://groups.google.com/group/ubuntu-telepathy
<dholbach> pygi: done
<pygi> dholbach, thanks
* pygi thought he never unsubscribed out of that list
* pygi looks it up
<pygi> dholbach, yup, I never un-subscribed
<dholbach> ok good
<pygi> dholbach, I hope to have an initial Fama IM release in a week or so as well
<pygi> but we need tapioca-glib at least for that o.O
<dholbach> there you have something to do :)
<pygi> :P
<pygi> law exam, that's what I have to do today :p
<pygi> (exam in 2 hours, hehe :))
<fabbione> hmm something is changed .. i can only nominate SRU.. before i used to be able to add Tasks directly
<pitti> fabbione: right, weeks-old bug now
<seb128> fabbione: yes, that has been discussed on the distro team list some weeks ago
<sheikh> HI
<pitti> fabbione: you need to modify the url to say ubuntu/gutsy/foo... instead of ubuntu/foo
<fabbione> pitti: feh ok..
<sheikh> can ne one help me to start learning ubuntu devel
<seb128> pitti: can you accept a task this way? I though that was restricted to drivers
<fabbione> seb128: thanks
<pitti> seb128: yes, you can create a task with that
<fabbione> pitti: with no rush... #120177
<sheikh> some one out there
<sheikh> I need a lil help regarding ubunut
<pitti> fabbione: that looks weird; you attempt a modprobe on each and every block device addition/change? that's going to be a lot
<pygi> dholbach, we can't yet build wilde? (or can it be built with free java stack?)
<Keybuk> cjwatson: random Q ...
<Keybuk> cjwatson: don't suppose you know exactly what utmp is for? :p
<pygi> Keybuk, to find out users currently using the system?
* pygi hides
<dholbach> pygi: we'd need 4 java modules packaged for that
<Keybuk> so what's wtmp for? :p
<dholbach> pygi: you could start with java-dbus which ftbfs currently
<Chipzz> Keybuk: utmp is log of logins, wtmp of failed logins (IIRC)
<shawarma> Keybuk: man 5 utmp ?
<Keybuk> shawarma: this manpage isn't helping
<Keybuk> see ... things like w and last still seem to work
<dholbach> pygi: and afaik telepathy-wilde has been abandoned after the SoC project
<pygi> Keybuk, Chipzz, wtmp is a log of all login's and logout's, regardless
<pygi> dholbach, meh, ok then :(
<dholbach> pygi: I think that once there is a telepathy-purple we'll be better off
<pygi> dholbach, yup
<shawarma> Keybuk: ..yet they shouldn't , because... ?
<Keybuk> shawarma: because I don't know what's supposed to go into utmp, so never write anything there
<pygi> Keybuk, you aren't really supposed to leave utmp writeable
<Keybuk> according to the utmp(5) manpage, init is supposed to be quite active in writing things there :p
<pygi> Keybuk, mhm ... seriously, you should forbid writing there
<pygi> a security risk
<Keybuk> pygi: so if nothing writes to it, what's it for? :p
<cjwatson> pygi: I think you're confusing matters; it's group-utmp-writable
<cjwatson> obviously it shouldn't be world-writable
<pygi> Keybuk, problem is that it's very error prone, and a lot of system programs depend on it's integrity
<cjwatson> Keybuk: login and sshd and stuff write there
<shawarma> Keybuk: We write to it from an init script, I think..
<pygi> cjwatson, meh, you're right
<Chipzz> heh ok, wtmp is all logins, btmp is bad logins
<cjwatson> Keybuk: which is why w and last and such work
<pygi> cjwatson, my bad
<shawarma> Keybuk: bootmisc.sh
<Keybuk> cjwatson: right, but what writes the logout bit?
<shawarma> Keybuk: That script is probably doing what init used to do.
<pygi> dholbach, no point in packaging then
<shawarma> Keybuk: Ask inotify?
* pygi will be back after exam
<cjwatson> Keybuk: don't know offhand, I assumed it was done when the relevant login process exited
<shawarma> Keybuk: Or does inotify only tell that "something" is accessing a file.
<cjwatson> certainly sshd records logouts itself
<cjwatson> (see loginrec.c)
<Keybuk> yeah, I don't think login/getty do
<cjwatson> that I don't know
<Keybuk> if I do "last -f /var/run/utmp", gettys show up as "tty1 ... gone - no logout"
<Keybuk> likewise for wtmp
<cjwatson> maybe that's what init is supposed to do
<cjwatson> seems obvious for it to do cleanup from processes that failed to exit properly
<shawarma> Keybuk: login(1) mentions it.. 
<cjwatson> login isn't responsible for clearing up
<cjwatson> nor apparently is getty. I think init's meant to do that.
<shawarma> cjwatson: Precisely. That's what the man page says. :)
<Keybuk> the confusing bit about this manpage is that it lies anyway
<Keybuk> The first entries ever created result from init(8) processing inittab(5). Before an entry is processed, though, init(8) cleans up utmp by setting ut_type to DEAD_PROCESS, clearing ut_user, ut_host, and ut_time with null bytes for each record which ut_type is not DEAD_PROCESS or RUN_LVL and where no process with PID ut_pid exists. If no empty record with the needed ut_id can be found, init creates a new one. It sets ut_id from the inittab, ut_pid 
<Keybuk> and ut_time to the current values, and ut_type to INIT_PROCESS.
<cjwatson> shawarma: ah yes
<Keybuk> -- 
<Keybuk> sysvinit doesn't do that
<cjwatson> sysvinit appears to do the DEAD_PROCESS thing after reading inittab but before actually executing things from there
<Keybuk> it does DEAD_PROCESS when things die
<pitti> hi juliux 
<cjwatson> mm, right
<juliux> hi pitti 
<cjwatson> ./debian/changelog:1061:  * Do not try to clean up utmp in init itself (Bug#9022)
<cjwatson> (unfortunately that bug is lost)
* pitti chuckles at the subject of bug 40908
<ubotu> Launchpad bug 40908 in gnome-power-manager "Sleep button puts computer to sleep" [Medium,Needs info]  https://launchpad.net/bugs/40908
<pitti> "Unexpected error: success"
<cjwatson> like shawarma says, I think the bootmisc.c thing supersedes what init used to do
<Keybuk> yeah, it wipes utmp on boot
<Keybuk> but one surely needs to attack wtmp still, otherwise there will be obsolete entries from before the reboot?
<shawarma> Keybuk: Note that the utmp man page explicitly says it's likely to be outdated.
<shawarma> Keybuk: BUGS section at the end.
<shawarma> Keybuk: So you should (as you've clearly discovered) take anything in it with a grain of salt.
<cjwatson> if there's no logout record, then things like last(1) basically look for the next reboot record and say "down" or "crash" as appropriate
* Keybuk wonders whether upstart should write those :p
<cjwatson> that is, if there's no logout record and the entry in question predates a shutdown/reboot record
<cjwatson> ./debian/changelog:1061:  * Do not try to clean up utmp in init itself (Bug#9022)
<cjwatson> damn
<cjwatson> $ last | grep reboot | head -n1
<cjwatson> reboot   system boot  2.6.22-6-powerpc Wed Jun 13 09:56 - 12:08  (02:12)
<Chipzz> Keybuk: last uses wtmp; if you wipe that, you can only see logins since the last reboot?
<cjwatson> you might not be writing them, but something is ...
<Chipzz> Keybuk: I really think you're wrong there
<Keybuk> Chipzz: wrong where?
<cjwatson> Chipzz: he means set them to DEAD_PROCESS not actually wipe the file
<Keybuk> I can't be wrong, I don't know what I'm talking about
<cjwatson> but I don't think that's necessary
<Chipzz> Keybuk: wiping wtmp at boot
<Keybuk> Chipzz: utmp, not wtmp
<Chipzz> 13:06 < Keybuk> but one surely needs to attack wtmp still, otherwise there will be obsolete entries from before the reboot?
<cjwatson> obsolete entries in wtmp from before the reboot are useful information
<Chipzz> attack != wipe ?
<cjwatson> they tell you that somebody was logged in when the system went down
<Keybuk> cjwatson: good point
<Keybuk> so, err, what writes the reboot record in the sysv wold?
<Keybuk> world?
<Chipzz> cjwatson: which is exactly what I was pointing out ;)
<cjwatson> ./src/init.c:2179:                      write_utmp_wtmp("reboot", "~~", 0, BOOT_TIME, "~");
<Keybuk> cjwatson: that happens way before any useful filesystem is writable
<cjwatson> there's another bit that accounts for that
<cjwatson> see src/utmp.c
<cjwatson> also halt and shutdown write shutdown records
<shawarma> Keybuk: Which part of reboot are you talking about? The shutting down bit, or the starting up again bit?
<shawarma> Keybuk: Starting up is bootmisc.sh it seems. Shutting down should (hopefully) be after the filesystems are writable. :)
<cjwatson> upstart appears to write reboot records but not shutdown records
<cjwatson> shawarma: it's more than bootmisc.sh
<Keybuk> cjwatson: ah, it repeatedly tries to write the reboot record every time it tries to write anything
<cjwatson> correct
<Keybuk> cjwatson: yeah, upstart is largely sloppy at writing anything into utmp or wtmp
<Keybuk> the only exceptions are the runlevel and a reboot record when we switch into rc2
<shawarma> cjwatson: Yes, I see. My bad.
<cjwatson> damnit, having trouble finding a Debian box that has rebooted recently
<Keybuk> (the fact that nobody's actually noticed that it's pretty bad at it makes me think that nobody *really* uses (or trusts) this stuff :p)
<Keybuk> cjwatson: I'm comparing with a dapper box
* coNP announces gladly: no untriaged bugs in inkscape in this very moment
<Keybuk> coNP: s/no/no known/
<coNP> no untriaged = no reported AND untriaged, of course, unreported bugs cannot be triaged at all :)
<Keybuk> cjwatson: it strikes me that, at the least, upstart should have the ability to maintain a utmp record for a job
<cjwatson> yeah, clean reboots in sysvinit-land seem to have a shutdown record followed by a reboot record
<cjwatson> unclean reboots just have a reboot record
<Keybuk> ie. "utmp 1" in the job file means you'll get INIT_PROCESS when that job is spawned and DEAD_PROCESS when it dies
<Keybuk> (for a ut_id of "1")
<fabbione> pitti: only the first time is "slow".. once the module is loaded, it's not an issue.
<cjwatson> and last(1) tells the difference between "down" and "crash" by looking for shutdown records
<fabbione> pitti: and you don't know if the module has been unloaded when you get the "next" block device
<cjwatson> so the visible difference in Ubuntu is likely that you'll never see last(1) saying "crash"
<fabbione> pitti: so no matter.. you need to make sure it's there for multipath to work
<Keybuk> pitti: *shrug* we attempt a modprobe on each and every device change, pretty much <g>
<pitti> fabbione: (see my comment in the bug)
<fabbione> pitti: doing so
<pitti> fabbione: why do we need to be concerned about module unloading? that doesn't ever happen automatically AFAIK
<Keybuk> cjwatson: but it does :-/
<fabbione> pitti: no it does not happen automatically but let say that you do something manually and you replug a SAN (hotswappable disks) you want to make sure it's loaded and working properly
<Keybuk> cjwatson: you mean last should always say "crash" and not "down", no?
<Keybuk> since we never have a shutdown record
<cjwatson> sorry, yeah, that's what I meant. but that appears not to be the case
<pitti> fabbione: but if someone manually rmmods, then he certainly has a reason to?
<fabbione> pitti: i also don't want to use /etc/modules.. see /etc/udev/rules.d/90-*
<cjwatson> ah
<cjwatson> last also interprets recorded transitions to runlevels 0 and 6 as indicating clean shutdowns
<pitti> fabbione: so, if Keybuk as our udev expert is happy with the modprobe hammering, I'm good; but I at least want to understand it :)
<fabbione> pitti: that happens no matter what.. like Keybuk says.. we do it for other stuff too and it seems to be ok
<Keybuk> cjwatson: it does, where do you see that?
<Keybuk> pitti: modprobe is cheap in the already loaded case - since it checks whether it's already loaded - same cost as doing the same check in udev
<cjwatson> Keybuk: search for SHUTDOWN_TIME, third occurrence
<fabbione> pitti: i did try a boot with sd[a-z]  and root on sdr to test this... no matter how fast i could login there were no modprobe processes hanging around
<cjwatson> so 'last -x' on Debian goes:
<cjwatson> runlevel (to lvl 2)   2.6.18-4-amd64   Tue Jun  5 10:53 - 10:15 (1+23:22)
<cjwatson> reboot   system boot  2.6.18-4-amd64   Tue Jun  5 10:53 - 10:15 (1+23:22)
<cjwatson> shutdown system down  2.6.18-4-amd64   Mon Jun  4 15:45 - 10:53  (19:07)
<cjwatson> runlevel (to lvl 6)   2.6.18-4-amd64   Mon Jun  4 15:45 - 15:45  (00:00)
<cjwatson> while 'last -x' with upstart goes:
<Keybuk> cjwatson: in last.c ?
<cjwatson> runlevel (to lvl 2)   2.6.22-6-powerpc Wed Jun 13 09:56 - 12:23  (02:27)
<cjwatson> reboot   system boot  2.6.22-6-powerpc Wed Jun 13 09:56 - 12:23  (02:27)
<cjwatson> runlevel (to lvl 0)   2.6.22-6-powerpc Wed Jun 13 04:41 - 09:56  (05:14)
<cjwatson> Keybuk: yeah
<Keybuk> cjwatson: which last.c? :p
* Keybuk doesn't have SHUTDOWN_TIME at all
<cjwatson> Keybuk: sorry, I mean fifth occurrence. sysvinit/src/last.c c line 783
<cjwatson> s/c line/c. line/
<Keybuk> ohh, I was looking at the one in util-linux
<Keybuk> d'oh
* iwj looks at IRC.  Oh, err, you want to know about wtmp/utmp ?
<iwj> It's been slightly broken at least since pam because the pam people didn't know either.
<pitti> fabbione: ok, bug updated
<cjwatson> I'm not sure util-linux's version is complete
<fabbione> pitti: ehhe ok thanks :)
<cjwatson> it's certainly a lot less readable :)
<iwj> You should definitely write a dead record when a getty/login ends.
<iwj> And NB that utmp is a weird fixed-record concurrent-access database.
<iwj> You must never change what a particular slot in utmp refers to.
* varka hugs txwikinger for fixing several bugs :)
<txwikinger2> thanks varka :)
* ReALITY5 hugs all
<cjwatson> hmm, whoops, creating /dev/loop1 as a character device doesn't work so well
* WB|Diego hugs all Developers
<WB|Diego> ^^
* benben hugs Frank Schoep
<WB|Diego> All developers were great, I love you all
<WB|Diego> Good work
<WB|Diego> Further so !
<WB|Diego> THX
* benben hugs Mark S.
<seb128> fabbione: why did you subscribe ubuntu-archive to bug #120177?
<ubotu> Launchpad bug 120177 in multipath-tools "dm-multipath not autoloaded causes multipath to fail" [Undecided,In progress]  https://launchpad.net/bugs/120177
<seb128> fabbione: do you want ubuntu-sru?
<fabbione> seb128: there is already ubuntu-sru...
<pitti> seb128: he does, yes
<fabbione> he upload will be reviewed by the SRU archive administrators during regularly scheduled processing, and approved if it meets the above criteria. Archive administrators should verify that the package delta matches the debdiff attached to the bug report.
<fabbione> The ubuntu-archive team member who accepts the package into -proposed should: 
<fabbione> this is from SRU...
<fabbione> it mentions ubuntu-archive specifically
* backfisc1 hugs budubuntu
<pitti> fabbione: for subscription it only mentions -sru
<pitti> but no big deal
<fabbione> ok...
<seb128> right, just wondering because usually ubuntu-archive is not subscribed and I'm not sure of what I was supposed to do on the bug
<seb128> I'll let it to pitti
* Hobbsee_ stomps on her ISP
<fabbione> seb128: ok.. i thought i had to sub it.. 
<fabbione> seb128: my bad..
<seb128> fabbione: that's alright ;)
<pitti> heno: the list of possible actions on the wiki page should include searching for and marking as dup
<heno> pitti: you mean on the hug day page?
<pitti> yes
<heno> pitti: The idea is to just present a subset of possible triage activities to start with. The theme might change for next time
<fabbione> later guys
<heno> pitti: Brian has been selecting these themes
<Hobbsee> evening calc 
<pitti> heno: I mean the "To mark it off the list you should:" list
<heno> I happen do be doing something completely different today; closing 'fixed elsewhere bugs'
<heno> pitti: ok, I'll look
<heno> pitti: got you now. fixed, thanks
<pitti> heno: thanks
<pitti> heno: erk, sorry, I broke your lock
<pitti> heno: I added the dup marking to the second list, too
<Hobbsee> superm1_: cjwatson: what does mythtv-ubiquity bugs get filed under?
<evand> hrm/t
<evand> whoops
<calc> Hobbsee: good morning ;)
<dholbach> keescook, seb128, doko: ok if I make somebody of you admin of ubuntu-main-sponsors?
<seb128> dholbach: what is the job about? ;)
<ogra> hmm, no seveas
<dholbach> seb128: approving ubuntu-core-dev members who apply
<ogra> dholbach, you are CC as well ?
<dholbach> ogra: yes
<ogra> dholbach, can i kindly ask for renewal of my membership before it expires ? 
<seb128> dholbach: isn't that TB job? ;)
<dholbach> seb128: ubuntu-core-dev is a requirement, before somebody wants to join ubuntu-main-sponsors
<seb128> dholbach: ah, alright
<seb128> dholbach: you can make me admin if you want
<dholbach> seb128: it's just that pitti left the team and we should have backup admins
<seb128> dholbach: alright
<dholbach> seb128: thanks seb128
<seb128> you're welcome
<pitti> dholbach: sorry for that, but I haven't been active in that team for months; ENOTIME :/
<dholbach> pitti: that's what I guessed - no problem
<emanuel__> hi
<calc> dholbach: happen to know when the next CC meeting will be?
<evand> Hobbsee: as there's no source package for mythbuntu, perhaps just tag it and we'll deal with it when there is one.
<superm1_> Hobbsee, atm the Mythbuntu project on launchpad
<Hobbsee> evand: i stuck it under ubiquity
<evand> ok
<StevenK> calc: Does http://fridge.ubuntu.com tell you?
<dholbach> calc: no, to be honest - I'll mail community-council and ask for a new date
<pitti> shawarma: bug 19889 approved for SRU, please upload
<ubotu> Launchpad bug 19889 in sysklogd "sysklogd: Large file support is broken in dapper" [Medium,In progress]  https://launchpad.net/bugs/19889
<dholbach> calc: I'll let you know
<calc> dholbach: ok thanks :)
<calc> StevenK: no that was the problem ;) it has been over 2 weeks since the last one and no date is set yet
<StevenK> Ahh, right
<shawarma> pitti: Which version should I give it? The wiki page is a little vague with regard to that.
<shawarma> pitti: It's currently 1.4.1-17ubuntu7.
<shawarma> pitti: There's not 1.4.1-17ubuntu8.. Should I make it 1.4.1-17ubuntu7.1 for -proposed and bump it to ubuntu8 for -updates (when the time comes) ?
<superm1_> cjwatson, I toyed with separating the glade file into multiple parts yesterday, and almost have it done - but is there a cleaner way of copying a widget over to the notebook than using unparent()?
<cjwatson> superm1: not sure, not an expert
<superm1> cjwatson, okay i'll continue to poke around then.
<Chipzz> superm1: also not an expert but I think not
<reic> i wanna hug some1, is there anything solved yet? ^^
<superm1> Chipzz, there was a warning in the API saying that the function is only intended for use in child classes that redefine the parent, so wanted to make sure
<dholbach> ogra: new gnome-power-manager
<pitti> shawarma: ubuntu8 or 7.1 is both fine
<pitti> shawarma: and we don't do -updates uploads any more, so it won't change there
<shawarma> pitti: Huh? Where does it get uploaded to ten?
<shawarma> then*
<pitti> shawarma: it doesn't, it's copied verbatim from -proposed
<pitti> shawarma: new soyuz tool 'copy-package'; I announced that the other day on u-d-a
<shawarma> pitti: Where? Can't find it in the ml archive..
<pitti> shawarma: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-May/000288.html
<shawarma> pitti: got it.
<pitti> shawarma: the wiki page is also updated, so above mail is not that important
<shawarma> pitti: Well, if you (like me) thought we still did the no-change re-upload dance, it's vital information. :)
<shawarma> pitti: Otherwise I'd just think the wiki page was missing that bit of info.
<pitti> shawarma: hm, which part do you think is unclear? I'm all for deconfusing it
<shawarma> pitti: I'm not sure. Maybe I'm just trying to do too many things at once..
<shawarma> pitti: How about DebianMaintainerField? Should I implement that in this package?
* CRaMLiNG hugs all developers in the channel
<pitti> shawarma: not for dapper, only for feisty and upwards
<pitti> CRaMLiNG: *hug*
<Hobbsee> hiya CRaMLiNG  :)
<CRaMLiNG> thanks for that great OS =)
<shawarma> pitti: Alright. Wasn't sure if it was distro specific or "time of upload" specific.
<pitti> shawarma: we didn't test the dapper package tools with XSBC-, and in fact there is one known bug in dpkg, so we mustn't take the risk
<shawarma> pitti: Alright.
<racarr> Err. I forget
<racarr> what is the option to make focus not follow mouse?
<mvo> racarr: in metacity? or compiz :) ?
<racarr> oh
<racarr> wrong channel -_-
<racarr> I thought I was in #opencompositing-dev :P
<mvo> heh :)
<pitti> mvo: hmm @ bug 107431: I thought this was already handled in some SRU?
<ubotu> Launchpad bug 107431 in update-manager "cdromupgrade calls gksu" [High,Fix committed]  https://launchpad.net/bugs/107431
<mvo> pitti: yes, I close it
<mvo> pitti: well, it is fixed in gutsy at least.
<mikmorg> hello.
<bdmurray> mikmorg: hello
<boenki> hello! If someone really wants to get hugged, can you fix this anyoing bug finally!? https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/85216
<ubotu> Launchpad bug 85216 in gnome-panel "gnome-desktop-item-edit should change the Name= key" [High,Confirmed]  
<zasf> hi all
<mikmorg> does anyone know where the /target path in casper/ubiquity gets created/mounted?
<zasf> pitti:Hi Martin
<boenki> or could someone just assign the above mentioned bug to the right people!?
<seb128> heno: I have dropped 34_at_properties_onboard_and_new_interface.patch and 81_get_rid_of_orca_main_window.patch from the gnome-control-center 2.19.3 update, upstream changed quite some code and nothing apply. Could anybody from a11y look if they are still required and should be rewritten or something?
<boenki> I wonder if they know about it at all, cause it doesn't seem to be to difficult to fix
<pitti> zasf: hi
<iwj> Seen elsewhere:
<iwj> 16:17 <iwj> 16:17 <steph> Hm.  This atomic force microscope controller has Kubuntu embedded in it.
<zasf> pitti: are you busy? I'd like to chat a bit about r-d-m
<heno> seb128: I'll have a look
<pitti> zasf: reasonably; what's r-d-m?
<seb128> heno: thank you
<seb128> desrt: around?
<zasf> pitti: restricted drivers manager
<zasf> pitti: I did some coding for fun, I'd like to know what you think
<zasf> pitti: I wrote you an email and got no feedback
<pitti> zasf: oh, weird, when?
<seb128> pitti: if you have a minute could you look at compizconfig-binding in NEW? I've packaged it so I would prefer having somebody else doing the NEWing
<seb128> pitti: it's a small an easy one
<zasf> pitti: last week
<pitti> seb128: right, will do
<seb128> danke
<mikmorg> Has anyone here done any testing/writing of the driver update system in casper?
<evand> mikmorg: cjwatson wrote it.  I don't think anyone's tested it yet :)
<mikmorg> evand: ok, thanks
<mikmorg> seems i am the first :p
<pitti> seb128: indeed, small and nice; accepted
<seb128> pitti: danke
<keescook> dholbach: if you don't already have enough ubuntu-main-sponsors admins, feel free to add me.  :)
<pitti> seb128: are you doing some other source NEW today? I'll do some on Friday, but the current queue is so long, I won't manage this alone
<pitti> morning keescook 
<seb128> pitti: yes, will do some now
<keescook> hiya pitti
* keescook is looking forward to the sprint.  :)
<seb128> pitti: I wanted to get GTK+2.11 uploaded first, which is done now ;)
<Riddell> iwj: wow
<seb128> hey keescook
<dholbach> keescook: done :)
<keescook> hiya seb128 :)
<keescook> dholbach: so to approve folks, it's just a matter of    if user in ubuntu-core-dev: approve   ?
<iwj> Riddell: Thought you might like to hear that one :-).
<keescook> bdmurray: so, we're hanging out in here or u-bugs for hug day?
<dholbach> keescook: yes
<bdmurray> keescook: that is correct
<dholbach> keescook: being ubuntu-core-dev means that they should roughly know what they do, so it should be fine, if they propose themselves :)
<evand> mikmorg: what's the problem?
<mikmorg> evand: actually there are 2 
<bdmurray> seb128: could you look at the valgrind log in bug 114678?
<ubotu> Launchpad bug 114678 in Ubuntu "memory corruption on ubuntu 7.04" [Undecided,Needs info]  https://launchpad.net/bugs/114678
<mikmorg> evand: casper and ubiquity both make the mistake of not installing the deb packages which are imported into /var/cache
<seb128> bdmurray: looking
<mikmorg> the code is there, but its broken
<mikmorg> seems that chroot is misused in both cases, although i've only really looked at casper
<mikmorg> evand: I'll let you know the bug # when I'm done w/ the writeup
<cjwatson> mikmorg: /target is mounted by the partitioning in ubiquity
<cjwatson> s/partitioning/partitioner/
<seb128> bdmurray: the log is a debug one and shows an error
<evand> mikmorg: I was just going to ask :)
<seb128> bdmurray: but "/usr/local/bin/mu-mh/folders" is not an Ubuntu package, it's a local build
<mikmorg> cjwatson: good morning, and thanks.
<cjwatson> mikmorg: I'm not seeing what's wrong with casper's use of chroot, but maybe I'm blind
<boenki> I'll just ask again if someone can have a look in https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/85216
<ubotu> Launchpad bug 85216 in gnome-panel "gnome-desktop-item-edit should change the Name= key" [High,Confirmed]  
<seb128> bdmurray: I'll comment on it
<bdmurray> seb128: okay, thanks
<seb128> you're welcome
<mikmorg> cjwatson: it has me looking hard, too.. the paths are definitely messed up though.
<cjwatson> mikmorg: how so?
<mikmorg> cjwatson: It is looking for /var/cache/driver-updates//root/var/cache/driver-updates/tg3_i386.deb, on line 35 of 40install_driver_updates in casper-bottom
<mikmorg> (where obviously, the file resides as /var/cache/driver-updates/tg3_i386.deb)
<cjwatson> oh!
<cjwatson> argh, good catch
<evand> heh
<mikmorg> thank you.
<cjwatson> I can fix that
<mikmorg> I'll go ahead and report the bug - however,
<mikmorg> I believe the bug is two-headed
<cjwatson> sure, it may well have a couple of bits
<mikmorg> Ubiquity doesn't seem to install it either
<cjwatson> yes, the code in casper/ubiquity-hooks/40install_driver_updates is nearly identical and needs the same fix
<mikmorg> i was just investigating that part of it
<mikmorg> yes, i assumed that was the case
<mikmorg> so i'll report the bug immediately, seeing as how not much more needs said.
<cjwatson> mikmorg: do you have a bzr checkout of casper there?
<mikmorg> bug #120217
<ubotu> Launchpad bug 120217 in casper "Driver Updates not being installed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120217
<mikmorg> cjwatson: yes
<cjwatson> I'll check in a proposed fix in just a minute or two, then
<mikmorg> great, thank you.
<mikmorg> I'll test it for you, however, i will just quickly remaster an already exploded iso instead of rebuilding casper
<cjwatson> mikmorg: even better
<seb128> ogra: there is a new gnome-power-manager available
<ogra> seb128, yes, thanks dholbach already pinged
<seb128> k
<seb128> you're welcome ;)
<seb128> I forgot that dholbach is polling on the update list quite often ;)
<cjwatson> mikmorg: ok, committed, revision 386
<cjwatson> mikmorg: greatly appreciate you testing it out
<cjwatson> mount: Mounting /cdrom on /root/cdrom failed: Invalid argument
<cjwatson> that's odd
<cjwatson> though actually it's probably because we already did mount -o move earlier
<mikmorg> cjwatson: great, I'll get testing.. it'll take a while for me to transfer files to my network though.
<mikmorg> cjwatson: i am not familiar with bzr... could you tell me how i can diff head to last?
<mikmorg> nevermind.. i think i got it
<bdmurray> cjwatson: I noticed that the initramfs doesn't include fdisk yesterday is there a reason?
<seb128> mjg59: xserver-xorg-video-avivo include/radeon_reg.h is "Copyright 2000 ATI Technologies Inc., Markham, Ontario, and VA Linux Systems Inc., Fremont, California." but that's not mentioned in debian/copyright
<seb128> mjg59: "avivotool/xf86i2c.c: * Copyright (C) 1998 Itai Nahshon, Michael Schimek" also
<desrt> seb128; hey.  what's up?
<seb128> desrt: hey, is the gdk compositing example supposed to work correctly on gutsy with GTK 2.11.2 or does it need some xorg patching?
<mikmorg> cjwatson: I also have a couple enhancement requests from my team.. I will be posting them on launchpad today. Thanks for all of your help.
<desrt> seb128; xorg patching
<desrt> seb128; and some cairo patching, probably :)
<seb128> desrt: it displays a red border and the content of the bottom layer on my desktop
<seb128> but not on a button, and it's not refreshed correctly
<desrt> can you get me a screenshot, maybe?
<desrt> i'd expect it to simply display one of those regions that looks like the app died
<desrt> like a non-refreshing show-what-was-there-before thing
<desrt> if that's the case then you're dealing with an X server that needs to be patched
<seb128> desrt: alright, your description matches the behaviour
<seb128> desrt: do you have a pointer to the xorg upstream patch maybe? ;)
<seb128> and to the cairo changes we need
<desrt> keith wrote xorg-list saying he was merging the patch
<desrt> but then he didn't
<desrt> and then he disappeared
<seb128> ah, k
<seb128> I read that he was going to merge it
<desrt> cairo changes are trivial.  one moment.
<seb128> and I though it was done
<seb128> thanks
<desrt> i think behdad might have even merged the cairo changes last night
<desrt> http://bugs.freedesktop.org/show_bug.cgi?id=10329  <-- cairo
<ubotu> Freedesktop bug 10329 in xlib backend "add support for "recursive" xlib surfaces" [Normal,New]  
<cjwatson> mikmorg: head to last?
<desrt> http://lists.freedesktop.org/archives/xorg/2007-March/022423.html  <-- xorg
<cjwatson> bdmurray: probably just nobody came up with a good use for it yet. I think rescue mode and/or the live CD is better than trying to do that in the initramfs, TBH
<cjwatson> mikmorg: 'bzr diff -r385..386' gives you just that revision, though
<mikmorg> cjwatson: thanks.
<desrt> seb128; that previous patch was for 7.1
<desrt> an improved (ie: bigger?) patch for 7.2 is here: http://lists.freedesktop.org/archives/xorg/2007-March/022668.html
<seb128> desrt: ok, thanks
<desrt> http://lists.freedesktop.org/archives/xorg/2007-April/024218.html
<desrt> ^ keith saying he's merging it (???)
<mikmorg> cjwatson: maybe you could tell me what you think of these ideas before i post them
<bdmurray> cjwatson: What happened to me was my md arrays were not all started and I wasn't positive which partitions needed to be added.
<mikmorg> cjwatson: (even though I probably still will ;)
<mikmorg> We also should file a new launchpad bug, enhancement request, to allow updated installer files to come from that same driver CD.  That way, we can patch the gold CDs at runtime with the driver CD.  Red Hat does this with their anaconda updates.img media.
<mikmorg> and my favorite..
<mikmorg> We also should file yet another new launchpad bug, enhancement request, to allow that driver/updates CD to be a USB key. :-)
<cjwatson> mikmorg: first scares the willies out of me but I can see how it'd be useful
<calc> what is the status of the hardware database getting a frontend, etc?
<cjwatson> mikmorg: second seems entirely sensible
<mikmorg> cjwatson: yes, the first would have been useful in cases such as this one
<mikmorg> cjwatson: the idea of being able to manually overcome any problem in the installation process
<pygi> hey
<mikmorg> (without remastering)
<cjwatson> mikmorg: yeah, though updating casper on the fly from inside casper could be tricky
<cjwatson> in excelsis
<mikmorg> cjwatson: agreed
<mikmorg> cjwatson: how about adding a scripts/casper-hooks folder, which a 3rdparty could install debs into
<mikmorg> that would be run right before casper-bottom
<mikmorg> the driver disk could be checked for a 'casper-hooks' folder 
<cjwatson> so, ideally there'd be something run before *sourcing* casper-bottom
<cjwatson> then scripts in there could sed -i /scripts/casper-bottom/blah on the fly
<mikmorg> exactly
<cjwatson> and yes, maybe have /scripts/casper-premount/10driver_updates copy scripts over from a defined directory on the update image
<mikmorg> as long as casper-bottom is read OTF, after casper-hooks runs, there shouldn't be any problem
<cjwatson> and .debs
<cjwatson> it is
<cjwatson> sorry, I thought they were sourced for some reason, but they're not, they're just called. so that's ok
<mikmorg> cjwatson: great. I'll post them in a bit. I'm burning the remastered Feisty right now
<cjwatson> mikmorg: would supplying updated .debs be a reasonable approach for you, in general?
<mikmorg> cjwatson: what kind of .deb are you suggesting?
<cjwatson> mikmorg: in this case, say, a fixed version of ubiquity-casper
<mikmorg> cjwatson: I'm not sure what "ubiquity-casper" encompases
<cjwatson> anaconda's updates.img apparently just has you supply *.py files in a flat directory structure, but our installer is a bit more modular than that
<cjwatson> mikmorg: ubiquity-casper is where the ubiquity-hooks scripts go; it's installation hooks for ubiquity supplied by casper
<mikmorg> cjwatson: Ok, I thought that might be true. The only issue is, the hooks I'm suggesting would possibly require running before casper-bottom
<cjwatson> (the concept is that if you were running ubiquity on top of a different live CD infrastructure, you could theoretically have that infrastructure provide hooks to repeat the appropriate bits of hardware configuration in the installed system; not that anyone's done this with anything other than casper AFAIK)
<cjwatson> mikmorg: yeah, I think we have to supply more than one set of hooks
<cjwatson> because anything running before casper-bottom can't get at /root
<cjwatson> actually, hmm, that's not quite true is it
<mikmorg> cjwatson: Exactly. If we had one set of hooks that ran before casper-bottom, we could use that set of hooks to install another set of hooks (ie. ubiquity-casper.deb)
<mikmorg> So I think the most important modification would be to allow hooks prior to casper-bottom.
<cjwatson> yeah, I think that's probably the common case though and that we ought to supply something special for that rather than asking people to roll it for themselves
<mikmorg> thats fine, too.
<cjwatson> I certainly don't disagree that that is necessary and (logically) sufficient
<cjwatson> just trying to explore what's reasonable as syntactic sugar, if you see what I mean
<mikmorg> thats fine
<mikmorg> i'm just trying to reduce the work
<mikmorg> :)
<cjwatson> *shrug* it's either wodge of code or wodge of documentation ;-)
<mikmorg> tuche
<mikmorg> ok, i'm heading out to lunch
<bdmurray> bryyce: what would need for bug 96213?
<ubotu> Launchpad bug 96213 in Ubuntu "won't install on Dell 640m with 1400x900 screen" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96213
<karloo> why
<brycerr> hm
<brycerr> well, we need to know what graphics card and driver he's using, so need xorg.conf and/or Xorg.0.log
<karloo> why
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* karloo was kicked off #ubuntu-devel by Hobbsee (dont start...)
<brycerr> also, if it is an intel graphics then whether or not 915resolution is installed
<bdmurray> okay, Xorg.0.log will contain chipset information for the graphics card then?
<brycerr> he says he does know how to make it install, so it would be nice for him to outline the steps; that should make it clearer what change is needed
<brycerr> I suspect it's a dupe of 3731
<brycerr> (or one of its variants
<brycerr> Hobbsee, but whhhyyyy??  ;-)
* brycerr was kicked off #ubuntu-devel by Hobbsee (BECAUSE!!!!!!!!!!!!!!!!!!!!!!!!!!!  :p)
<brycerr> lol :-)
* Hobbsee attacks brycerr with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!!! 
<brycerr> bdmurray, I need to spend like a good week of quality time with 3731.  *sigh*
<mjg59_> seb128: Hm. Are you able to send me a copy of the packages again?
<seb128> mjg59: http://people.ubuntu.com/~seb128/xserver-xorg-video-avivo/
<mjg59> seb128: Thanks
<seb128> np
<mikmorg> cjwatson: Hello again.
<gerundium> /gerundium hugs all_you_great_developers_working_for_ubuntu
<CMooney> I have beer and want to learn to hunt bugs.
<persia> CMooney: There's a lot of action in #ubuntu-bugs right now, despite the published documentation :)
<CMooney> ah right, thanks.
* daren hugs entwickler
<brycerr> huh...  could someone do a ls -lh ~/.xsession-errors ?
<elmo> -rw-r--r-- 1 james james 60K 2007-06-13 21:16 /home/james/.xsession-errors
<brycerr> hmm, mine is 1.6G.
<brycerr> looks like mostly due to "alarm-queue"
<seb128> for how long is your session running?
<seb128> and what desktop do you use?
<seb128> gdm cleans the file on login and it has a limit
<brycerr> seb128, less than a day (this is the dell 1505n laptop)
<brycerr> I'm using stock gnome ubuntu, running gutsy
<seb128> brycerr: that is weird
<seb128> you use gdm to log in?
<brycerr> yup
<brycerr> this is running compiz too btw, if that matters
<seb128> no, should not
<brycerr> I haven't installed the latest updates for evolution, maybe that'd fix it?
<seb128> the messages are "normal"
<seb128> what is not is that the error log takes 1.6G
<seb128> it used to stop logging after a limit which was like 1M
<seb128> maybe it's broken on gutsy
<seb128> the amount of message is not normal though
<brycerr> hmm, gdm appears not to be running
<brycerr> l# /etc/init.d/gdm start
<brycerr>  * Not starting GNOME Display Manager (gdm); it is not the default display manager.
<seb128> ah
<seb128> there you go
<brycerr> ok cool
<brycerr> I probably turned it off to muss with bulletproof x stuff and forgot
<seb128> so you are not using a stock install ;)
<brycerr> heh, guess not ;-)
<brycerr> how quickly things diverge
<seb128> I'll have a look at stopping evolution to print all those debug lines
<seb128> usually that's not really an issue since gdm clean things and there is a log limit
* brycerr nods
<brycerr> btw, I'm poking around with the Wacom entries that are put into xorg.conf by default even when wacom's are not present
<brycerr> seb128 (or anyone), do you have any idea why those are there?  I'm wondering if we just took them out, if it'd hurt anyone
<brycerr> s/anyone/very many people/
<sparkiegeek> is this the right place to ask about problems building a binary package from an "apt-get source <package>" ?
<sparkiegeek> more specifically building meld and having issues with make and .po files
<seb128> brycerr: no idea about the watcom thing
<tepsipakki> brycerr: mjg59 seems to be the one who did it :)
<brycerr> tepsipakki, really?  interesting -- do you know of a debian bug id for it?
<mjg59_> brycerr: Yes, it means tablets work
<brycerr> mjg59, can we conditionalize it so it only gets added to xorg.conf if a tablet is actually present?
<tepsipakki> brycerr: there was no mention of one, and it's one of our changes
<mjg59> brycerr: Not trivially, no
<mjg59> brycerr: Given that it doesn't break anything (or if it does, then it's something that's broken already...)
<tepsipakki> kde programs complain something, but that's harmless
<mjg59> When we move over to hotplugged input devices, it's not as much of a problem
<tepsipakki> true
<brycerr> will the input hotplug allow us to safely drop it at that point?
<mjg59> Not immediately
<tepsipakki> maybe, if the driver supports input hotplug
<mjg59> Hal would need to be taught about them
<tepsipakki> so it is going to use hal after all :)
<mjg59> Any policy manager that's sane for us is probably going to be hal-based, I suspect
<mjg59> This may not be true of everyone
<tepsipakki> brycerr: magnus vigerlof should know how wacom is doing hotplug-wise
<brycerr> tepsipakki, ok
<brycerr> tepsipakki, which package provides dexconf?  I see it's present in xorg-7.2/debian/local/, but that doesn't appear to contain the wacom changes
<tepsipakki> brycerr: doesn't? It should
<tepsipakki> is it the vanilla debian version you are looking at?
<brycerr> hmm
<brycerr> ahh, yeah, I get it
<sn0> \bitchx/
<brycerr> I'd added debian experimental to my sources so I could track the stuff in experimental with my current versions page
<brycerr> but that screws up pulling source
<tepsipakki> yes, and you can't tell apt-get where to pull sources
<tepsipakki> since that doesn't work for source packages
<brycerr> yup, lil' bugger
<brycerr> fortunately I have more ubuntu machines on hand ;-)
<tepsipakki> just do a grab-merge.sh xorg :)
<brycerr> speaking of which...  have you looked at fglrx?  I gather we probalby shouldn't merge xorg until we've upgraded fglrx
<tepsipakki> no I haven't, but now that you mentioned it.. there are some drivers which Provides: xserver-xorg-video
<tepsipakki> but it should be x-x-v-1.0
<tepsipakki> then that change to xorg could be dropped
<tepsipakki> but sure, the newest fglrx should work with 1.3
<tepsipakki> mjg59: are you going to maintain the -avivo driver, or do you mind if the package is adopted by debian XSF?
<mjg59> tepsipakki: No objection to that
<mjg59> I just wanted it packaged so I could stop building it from source :)
<mjg59> tepsipakki: Note that it only contains a couple of PCI IDs right now
<tepsipakki> mjg59: ok, I'll pass that forward (same applies to libpciaccess)
<mjg59> Should be safe to add more with some testing
<mjg59> But r580 is still unhappy
<bdmurray> mjg59: I was looking at bug 119826 regarding Fn keys on a laptop.  Would that belong in hotkey-setup or acpi?
<ubotu> Launchpad bug 119826 in acpi-support "Fn key doen not work on compaq presario laptop in Xubuntu feisty" [Wishlist,Confirmed]  https://launchpad.net/bugs/119826
<bdmurray> I swear it didn't used to have a package
<mjg59> bdmurray: Doesn't look like either
<mjg59> bdmurray: For some reason, any time anything mentions acpi it gets assigned to acpi-support
<mjg59> Despite it basically never being an acpi-support problem
<mjg59> bdmurray: Arguably a hal issue, partially a kernel issue
<bdmurray> mjg59: Could you elaborate a bit or point me at something to read?
<mjg59> bdmurray: Something needs to send those events to userspace - it /could/ be done in acpi-support, but it makes more sense for the kernel to generate KEY_BRIGHTNESSUP and KEY_BRIGHTNESSDOWN (since that's all acpi-support oculd do)
<mjg59> Then something needs support for editing the brightness via the acpi interface
<mjg59> And then something needs to handle policy
<keescook> mjg59: how are most brightness buttons handled currently?
<peanutb_> 20000 hugs to whoever closes bug 1
<ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
<mjg59> keescook: Either in hardware or via gnome-power-manager
<keescook> mjg59: so it seems that "my brightness keys don't work" bugs are best filed against gnome-power-manager than acpi-support?
<mjg59> keescook: acpi-support is always the wrong answer
<keescook> hah.  :)
<mjg59> It's either a hal issue or a kernel issue
<mjg59> g-p-m ought to deal with any case that can be handled
<mjg59> It just says "Oh, here's a backlight hal can control" and "Oh, I just got a keypress telling me to change the brightness"
<keescook> is g-p-m running for folks with xubuntu?
<mjg59> Dunno
<mjg59> I have too little time to examine varient distros :)
<keescook> heh
<brycerr> xubuntu needs no stinkin' backlighting!
<brycerr> (sorry, couldn't resist)
<calc> mjg59: hmm maintainer of acpi-support probably knows where to reassign the bug? ;)
<calc> throw the hot potato to acpi-support and it will bounce it to the right location, heh
* peanutb_ can run gnome with no backlighting , its just not so fun
<cjwatson> calc: I get the impression mjg59 has got fed up of doing that ;-)
* calc ducks and runs
<mjg59> calc: Right now I've got no time to handle any bugmail, let alone stuff that's been assigned to me because people have an insufficient understanding of how stuff works to assign it to the proper place in the first place...
<calc> i assigned some today to acpi-support, but at least one of them i think really belonged to it, unless hal is supposed to do it
<calc> wrt potentially unmounting filesystems on hibernate
<calc> mjg59: ok
<calc> iirc it got marked wishlist in any case
<mjg59> acpi-support is probably right in that case, though it'll be rejected as not being a bug :)
<calc> mjg59: for that one in particular user hibernates ubuntu boots into windows changes files and resumes linux and doesn't see files
<Chenson> damn, bug #1 is still in progress. https://bugs.launchpad.net/ubuntu/+bug/1  *hehe*
<calc> mostly user error since the vast majority of the time a file will be open somewhere on the fs so that it can't be unmounted anyway
<ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
<mjg59> Yes. Don't do that :)
<mjg59> Well, really the issue is that our entire approach to hibernation is broken
<mjg59> I plan to fix that
<calc> mjg59: eh?
<mjg59> If anyone else can touch the filesystem, we shouldn't be keeping the file cache
<calc> to force the user to boot back into ubuntu on power on? ;)
<mjg59> Alternatively, we could make it impossible for anyone else to touch the filesystem. But that one might suck a bit.
<calc> yea
<mjg59> So I prefer the first
<calc> i didn't realize you could dump the file cache, that sounds like it could work out well
#ubuntu-devel 2007-06-14
<mjg59> calc: Yeah, you can't with the current approach
<mikmorg> the driver disk could be checked for a 'casper-hooks' folder 
<mikmorg> mt
<mikmorg> cjwatson: I just tested your patch, and it works in casper at least
<mikmorg> cjwatson: I have not tried ubiquity yet, however.
<cjwatson> mikmorg: great
* cjwatson munges sync-source to generate Launchpad-Bugs-Fixed fields in .changes if it happens that the Debian maintainer used the LP: syntax
<mikmorg> cjwatson: I'm installing as we speak, to test ubiquity.
<calc> heh looks like i should be shooting for half hour ooo builds ;)
<mikmorg> cjwatson: ubiquity works as well. Job well done!
<calc> hot compile using ccache of openoffice.org in 42m5s 8)
<calc> not too shabby with my little system
<calc> c2d 6300, 2gb ram
<minghua> calc: 42m5s is supposed to be a fast number, right?
<calc> considering it can take some systems upwards of 8h yea
<calc> ooo has ~ 200MB just of object files
<calc> after compilation
<minghua> no wonder not many people compile OO.o themselves :-)
<calc> i think it has somewhere around 3GB of source
<calc> hmm maybe only 2gb after all
* Hobbsee eeks
<ajmitch> hello Hobbsee 
<Burgundavia> hey Hobbsee, ajmitch
<Hobbsee> hiya
<ajmitch> hi Burgundavia, how goes unemployment?
<Hobbsee> better than exams, i'll guess
<ajmitch> exams aren't too bad
<Hobbsee> ajmitch: physics exams where i missed a lot of the content are!
<ajmitch> true
<ajmitch> but I know you've been busy studying
<minghua> hmm, physics exams, fond memories
<Hobbsee> ajmitch: of *course*.
<Hobbsee> not.
<mneptok> pop quiz!
<Hobbsee> hiya mneptok!
* mneptok is wearing pants : [ ]  TRUE   []  FALSE
* Hobbsee pops mneptok with a pin, and watches him burst over the top of the uni
* mneptok is filled with confetti!
<Hobbsee> let's hope the answer to that is true
<StevenK> mneptok: True
<mneptok> you people need more study time
<StevenK> But we don't want to study your pants.
<mneptok> no one does. :(
<mneptok> sanity, my old nemesis.
<ajmitch> hello mneptok 
<ajmitch> I never thought you had a problem with sanity?
<Hobbsee> ajmitch: no, that's you, being the crotchety old man and all :)
<ajmitch> right
* Hobbsee glances at her bugmail implosion again
<Hobbsee> awww, we never got below 30K open bugs.
<Hobbsee> makes me wonder where the heck they all are, though
<mneptok> ajmitch: i have no problem with sanity. mostly as i relegate to a small shed in the backyard.
<Burgundavia> ajmitch: it goes
<pygi> good morning folks
<brycerr> heya pygi 
<pygi> hello brycerr 
<StevenK> It is just me, or should artigas have actually finished building glibc by now?
<fabbione> StevenK: yes.. and it's hanging on an old version too
<fabbione> infinity: ^^^^ could you please take a look?
<StevenK> fabbione: Ta.
<mvo> keescook: hey! just read in your report that you investiage the SHA* usage in apt
<dholbach> good morning
<pitti> Good morning
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Tribe-1 released
* StevenK waves to pitti
<StevenK> pitti: topic diff?
<pitti> StevenK: removed hug day
<StevenK> Ah
<shawarma> StevenK: IRC client?
<shawarma> StevenK: irrsi-scripts has /usr/share/irssi/scripts/topic-diff.pl which tells you exactly what was changed when someone changes the topic of a channel.
<shawarma> StevenK: Very handy.
<StevenK> I've been meaning to update my irssi scripts.
<StevenK> I've been told autorealname and lightbar are both crap.
<shawarma> I'm not familiar with those.
<StevenK> They are both *old*
<StevenK> I need to fix my theme, too. The blue is a little too dark for black text.
<shawarma> StevenK: I found a bug in linda, by the way.
<shawarma> StevenK: It breaks when there are man pages with "::" in the filename.
<StevenK> Known.
<dholbach> can a build admin give back at-spi on all architectures?
<StevenK> I need to get around to uploading 0.3.25
<dholbach> same for gnome-vfs-obexftp on sparc please
<pitti> mvo: good morning
<pitti> mvo: HAPPY BIRTHDAY!!!
<dholbach> mvo: HAPPY BIRTHDAY!!! :-)
* dholbach hugs mvo ecstatically
<highvoltage> mvo: happy birthday :)
<stgraber> any idea who shall I ping to have post right on ubuntu-devel ? I received a : "Post by non-developer to moderated list." when I wanted to answer to the guy asking about the testing tracker DNS problem
<tepsipakki> could the automatic-bug-closing-feature be modified so that it doesn't spam bugs which are already closed?
<tepsipakki> and where to file a bug if it isn't already?
<pochu> tepsipakki: I filed one. Bug 118671
<ubotu> Launchpad bug 118671 in soyuz "Changelog-Close feature tries to close already-closed bugs." [Undecided,Unconfirmed]  https://launchpad.net/bugs/118671
<tepsipakki> pochu: nice
<pitti> stgraber: new iso tracker is great!
<Lure> pitti: re source NEW: do we need to do something special (like open bug in LP/MIR-like request) to get packages through source NEW? khalki and kde-tweak are there for weeks now...
<pitti> Lure: no, we just need more archive team power
<seb128> I'm doing some source NEW atm
<pitti> Lure: I'll try to do more tomorrow, but due to seb128's and now Mithrandir's vac it is understaffed
<Lure> pitti, seb128: ok, I just though that we did not do something right
<pitti> Lure: no, don't worry, we'll get to it; sorry for the delay
<Lure> pitti: no problem at all, I just want to understand the process
* pitti hugs seb128
<seb128> Lure: if somebody is not right you get a rejection mail
* seb128 hugs pitti back
<seb128> s/somebody/something
* Lure hugs pitti and seb128
<dholbach> pitti: does iwj do MIRs now? or who apart from you is it? (I'm asking because of libgda3)
<pitti> dholbach: iwj and me
<dholbach> ah ok - thanks
<pitti> dholbach: isn't it only a new upstream version of libgda2?
<dholbach> yes
<dholbach> python-gnome-extras will build-depends on it
<dholbach> and if we do something about planner, we can have the supported gda3 in main and dump gda2 to universe
<pitti> right, I'm worried about the duplication, not a soname change
<dholbach> it's not just a soname change, but a separate maintained branch (gda3 more than gda2) - hopefully all upstream projects will soon switch to it
<pitti> Riddell: FYI, strigi needs libextractor, which in turn needs mpeg2dec; these either need MIRs or get dropped
<seb128> Lure: khalkhi accepted
* Lure hugs seb128
<asac> doko: cjwatson: if you have a minute, please push the button to retry gnash on sparc :).
<cjwatson> asac: (I do not have access to do that)
<asac> cjwatson: who has?
<seb128> ups, I though you had
<seb128> asac: infinity and doko then I guess
<cjwatson> asac: anyone in the launchpad-buildd-admins team
<doko> asac: was gtk updated in the meantime?
<seb128> doko: I've uploaded a fixed gtk+ yesterday evening
<asac> doko: yes
<doko> ok, given back
<asac> doko: thanks!
<seb128> doko: can you also give back vlc on sparc?
<seb128> and dasher everywhere
<doko> seb128: for the same reason?
<seb128> yes
<dholbach> same for gnome-vfs-obexftp on spar
<dholbach> and at-spi on all archs
<doko> the interface sucks for mass retries
<asac> doko: do you know why openoffice shows up as an rdepend for firefox in dapper?
<doko> seb128, dholbach: all done
<seb128> danke
<dholbach> doko: thanks a lot
<doko> asac: AFAICR it did buidl a plugin to show documents directly in the browser
<doko> should be possible to reenable that for gutsy
<asac> hmmm but i don't see a plugin package?
<asac> doko: in gutsy there is mozilla-openoffice.org package in rdepends ... but in dapper there is just openoffice.org
<doko> openoffice.org is a pure dependency package
<asac> doko: ah ok ... its just a suggests ... which probably makes not much sense in dapper
<asac> cool
<iwj> doko: Can I ask you a question about weird compiler behaviour ?
<doko> iwj: asking is free =)
<iwj> This is in glibc.
<Robot101> therefore it costs extra? :)
<iwj> :-).
<seb128> Bixente: around?
<iwj> I have an object file compiled from a .c file I added.  The build system generates various object files using different compiler flags.
<iwj> In the case of the *.os file, one of the aliases I put in the source seems to have been randomly removed.
<seb128> Bixente: you packaged xfce4-time-out-plugin right? Could you fix debian/copyright to mention "Copyright (c) 2007 Jannis Pohlmann <jannis@xfce.org>" as copyright holder for panel-plugin/time-out-fadeout.c?
<iwj> Compiler command line is at http://paste.ubuntu-nl.org/25509/
<iwj> The compiler generates a file enospck.so which doesn't contain a weak alias __open (although it has invented __GI___open), despite me requesting it with strong_alias (which is glibc's macro for generating aliases).
<tepsipakki> does someone know if the ubuntu apache has some trickery to make it work with utf8 filenames?
<tepsipakki> or is it a feature of apache 2.x
<iwj> (What are these __GI_* aliases for, anyway?)
<thom> tepsipakki: feature
<tepsipakki> thom: excellent
<Bixente> seb128: ok i'll fix it
<seb128> Bixente: I've just rejected the package and mailed you
<seb128> Bixente: sources are un LGPL but COPYING and debian/copyright claim it's GPL
<seb128> s/un/under
<iwj> doko: ^
<doko> iwj: sorry for the delay. but haven't worked with the __GI_* aliases yet
<iwj> Right.
<iwj> I'm not sure if my problem is anything to do with them.
<iwj> What's going wrong is that the compiler is randomly not generating the alias __open (and a couple of others which are similar).
<iwj> And only with certain compiler flags.
<iwj> The other versions of enospck.*o have it just fine.
<doko> do you see the same behaviour with other compiler versions?
<iwj> I haven't tried any.
<iwj> It takes about 4 hours to build so I'm not keen on that plan :-).
<iwj> ISTR reading something about these __GI_* symbols being something to stop the compiler removing things.  But I wasn't able to find anything resembling a coherent explanation.
<doko> try to build on ronne, with gcc-4.2 and gcc-snapshot installed; that should cut down the build times with a parallel build
<iwj> You really think it might be a bug just in this version ?
<iwj> It seems too clean a fault for that somehow.
<doko> the alias doesn't show up in the assembler file when building with -save-temps?
<iwj> Oh, I didn't try that.  Let me see ...
<iwj> I see  .weak __GI___open  but no  .weak __open
<iwj> It's truly bizarre.  It generates the weak alias `open' but not `__open' and they're specified identically in the source.
<iwj> doko: Err, it turns out that the difference is already in the -E output so it's the glibc build system that's doing it.
<doko> fun :-/
<iwj> I hadn't previously looked at the -E output _for the .os build_.
<StevenK> iwj: There still appears to be a warning from update-alternatives. I'll investigate a little further and let you know anything more I stumble over.
<iwj> StevenK: Just a verbatim copy of the warning message would be sufficient.
<iwj> It's probably something upstream did.  They've reorganised it completely and turned on perl -w.
<StevenK> iwj: Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 602.
<StevenK> iwj: It looks like a typo/thinko from my glance at the code.
<iwj> This is with 1.14.4+svn20070602r802-0ubuntu1 ?
<StevenK> iwj: That's right.
<iwj> It's not a trivial thinko.  I'll go back to my libc problems so I don't get distracted.  Could you file a bug and assign it to me ?
<iwj> Does it happen every time ?  A bit of contextual transcript would be ideal.
<StevenK> iwj: Ahh. I can reproduce it in a clean gutsy chroot by installing fakeroot.
<StevenK> iwj: I'm happy to debug it and file a bug with a patch if you like.
<iwj> StevenK: Whatever you prefer but it might be easier for me as I've been more or less following what upstream have been doing.
<iwj> StevenK: But helpful would be a tarball of your /var/lib/dpkg/alternatives from before the run that produces the warning.
<StevenK> iwj: The bug is already filed and assigned to you. Bug 118246
<ubotu> Launchpad bug 118246 in dpkg "update-alternatives warnings" [Medium,Confirmed]  https://launchpad.net/bugs/118246
<iwj> StevenK: Ah, excellent.
* iwj goes out to bring old computer junk to Cambridge Computer Recycling.
<cjwatson> DAMN, I hate having a slightly sticky . key
<cjwatson> mv <glob that expands to two files> <tried to press . but it didn't quite work>
<ogra> just remove the sesame seed :)
* ogra wonders why g-p-m introduces at least one new dependency every update :/ grmbl
* Keybuk wonders why g-p-m is so fucking stupid
<Keybuk> "Your battery has only 2m left!"
<ogra> heh
<Keybuk> ...no it doesn't!
<ogra> mine dies at 37% atm
<pitti> Keybuk: two meters?
<Keybuk> afaict, what happened was the first time I ran the new g-p-m, it profiled the period when it was on battery as I walked down the stairs
<ogra> and it tells me my battery is bad every boot 
<Keybuk> so now it is convinced that I only have 2 min of battery power, because that's the longest it's ever seen on battery
<Keybuk> of course, if I could run for longer on battery, it could re-profile
<Keybuk> except I can't, because g-p-m takes immediate action and shuts down my machine
<ogra> can you define "profile" ? 
<Keybuk> ogra: dunno, seems to be some new bullshit thing g-p-m does
<ogra> afaik it just gets live values from hal now
<ogra> g-p-m is dumb nowadays
<Keybuk> rather than just get the current time left from the battery, it profiles it
<ogra> hmm, weird
<mjg59> It's not dumb, just (currently) trying to be too smart
<Keybuk> mjg59: I assume it's so it tells you how much time your battery really has left, based on real measurements
<mjg59> Yes
<mjg59> I need to speak to Richard about it
<ogra> well, hughsie likes to experiment at the beginning of a cycle ...
<Keybuk> what I don't understand is why it doesn't use the time the battery thinks until it has seen at least one full charge/discharge cycle
<ogra> usually he gets it right along the way
<mjg59> Keybuk: Right, unless it has evidence that the battery deviates from what it reports it ought to trust the battery
* ogra stopped complaining at hime before mid cycle
<Keybuk> yeah, it bites me really bad because it's coupled with two other major bugs
<mjg59> I'll be chatting to him at guadec
<Keybuk> 1) full computer hang when you plug in the AC cord
<pitti> mjg59: will you do the laptop-mode-tools merge, or shall I try it myself? (can't test it, though)
<Keybuk> 2) Network Manager is unable to associate with the wireless on a fresh boot
<ogra> Keybuk, that sounds rather like hal or kernel 
<mjg59> pitti: Sorry, I'll get to it
<mjg59> Full computer hang = kernel bug
<Keybuk> yeah, both seem to be kernel bugs
<Keybuk> the NM one is weird, since dhclient itself just works
<mjg59> Keybuk: Which driver?
<Keybuk> it looks like the kernel isn't giving the right info to HAL which isn't giving the right info to NM
<Keybuk> mjg59: ipw3945
<StevenK> Keybuk: Does it happen if you boot with the AC plugged in?
<Keybuk> StevenK: yes
<mjg59> Keybuk: ipw3945 or iwlwifi?
<StevenK> Keybuk: Neat.
<Keybuk> mjg59: ipw
<mjg59> Ok
<mjg59> I blame softmac
<Keybuk> I wondered whether it has anything to do with HAL gaining software-control support for the hardware kill switch on the Dells
<mjg59> Doubt it
<Keybuk> because toggling the kill switch cures the problem
<mjg59> I suspect it'd also work fine if you force a reassociation
<Keybuk> mjg59: that doesn't seem to work
<Keybuk> though not sure how to force one
<ogra> Keybuk, what about reloading the module ? 
<mjg59> Keybuk: While n-m is in the broken state (no green circles), select your network again
<ogra> thats what helps me on my broadcom
<Keybuk> mjg59: yeah, tried that, that doesn't fix it
<Keybuk> ogra: doesn't fix NM
<mjg59> ogra: He's already got a workaround, the aim is to try to work out what the problem actually is
<mjg59> Keybuk: Ok. Just to check that the symptoms are what I think they are - n-m never associates (draws the first green circle)?
<pygi> hey folks
<Keybuk> mjg59: NM never draws any green circles
<Keybuk> mjg59: it sticks at two empty circles
<mjg59> Keybuk: Right.
<mjg59> Keybuk: So n-m is never getting the association event. It's basically impossible for it to get that wrong, which means softmac is never sending it properly
<Keybuk> toggling the hardware kill switch on and off makes NM draw the first circle, then the next
<Keybuk> right
<mjg59> Toggling the hardware kill switch makes the interface reassociate without actually taking it down
<mjg59> So it sends another event, which /does/ get through softmac this time
<Keybuk> which explains why dhclient works, since that doesn't bother checking ;)
<mjg59> Yes
<Keybuk> that sounds like an entirely reasonable description of a bug which would cause my symptoms
<pitti> gnomefreak: iceape-calendar binary is empty; I'll accept it for now, but I guess it should be fixed
<mjg59> You want to talk to Tim about that. He managed to track down the issue, though in 2.6.20 it only seemed to hit bcm43xx and zd1211rw
<gnomefreak> pitti: ok thank you ill look at it today
<mjg59> pitti: Sorry, things have just been hectic. I'm planning on blitzing all of this stuff during Debconf
<pitti> mjg59: no problem, I just wanted to confirm that someone is at it
<pygi> Keybuk: mhm ... since when it doesn't draw green circles?
* pygi remembers he saw them
* ogra wonders for the reason for g-p-m to depend on gstreamer ...
<mjg59> pygi: When it's broken
<pygi> mjg59: oh, that's possible
<pygi> sorry
<Keybuk> pygi: "gutsy"
<pygi> Keybuk: yea, didn't use that for wireless yet :-/
<mjg59> Keybuk: We should actually fix that - replacing grey circles with green ones is an accessibility nightmare
<Keybuk> mjg59: nice weather for Debconf; I always think Edinburgh looks at its best in rain and thunderstorms
<Keybuk> it has the architecture and geography to carry it off with style
<mjg59> Keybuk: Oh yes
<ogra> seb128, is gnome_sound_play still not switched to gstreamer ? it seems a but odd if apps start to introduce their own gstreamer dep to play one ping sound
<ogra> s/but/bit/
<seb128> ogra: no, it's not, and they don't intend to I think
<ogra> gah
<ogra> so we'll have esd eternally ?
<ogra> thats bad
<asac> pitti: thanks for letting iceape in ... gnomefreak will take care for -calendar
<gnomefreak> :)
<seb128> ogra: no sure of what the plans are, but I think somebody said they don't want to make every app link to gst only for that
<ogra> well, adding gst to gnome_sound_play would make the apps depend on gnomenot on gst ...
<cjwatson> would probably still affect desktop memory use a bit
<ogra> having a centralized function instead of loading the libs for every single app ?  i dont think that will make a *big* difference
<ogra> the thing is that most apps have the gnome dep anyway
<seb128> they are trying to deprecated libgnome and libgnomeui
<ogra> nw they get an additional one instead of fixing the actual problem
<seb128> deprecate
<ogra> ah, that would work as well indeed
<ogra> anything that lets us drop esd is fine ... ;)
<Riddell> dholbach: human-icon-theme seems good to sync from debian, they've done some fancy packaging to include the appropriate distro specific bits.  shall I file a sync request?
<Riddell> dholbach: it would mean losing our changelog is the only issue
<Hobbsee> hey everyone
<zul> hey Hobbsee 
<cjwatson> stgraber: you should be able to post unmoderated to ubuntu-devel now
<Hobbsee> :)
<stgraber> cjwatson: thank you
<cjwatson> speaking of which, if anyone would like to get involved with ubuntu-devel moderation, I'd welcome community folks to help take care of that - please let me know
* Hobbsee declares that exams need to die.
<xxxxx1> hello Hobbsee 
* Hobbsee ponders that for exactly 1.5 seconds.
<pygi> hi
<Hobbsee> hiya pygi 
<Hobbsee> cjwatson: out of curiousity - what's the S/N ratio on ubuntu-devel, pre-filtering?
<cjwatson> Hobbsee: counting or discounting spam?
<Hobbsee> cjwatson: um...perhaps both. 
<Hobbsee> cjwatson: what are the stats, when counting spam, or when not counting spam?
<Hobbsee> i was originally thinking with it - but both stats are useful
<cjwatson> Hobbsee: counting spam it's like 40 or 50/1
<cjwatson> Hobbsee: discounting it, it's hard to say accurately because I tend to let whole threads through once they've started, but maybe 4/1
<cjwatson> err, you said S/N, so 1/4
<Hobbsee> as in, you're only letting thru 25% of non-spam mail.  wow
<cjwatson> Hobbsee: it's really hard to say, and it might be better than that
<cjwatson> actually, it probably is better than that, because I only see the stuff that's held for moderation
<cjwatson> a lot of people's addresses are whitelisted
<Hobbsee> point
<cjwatson> http://wiki.ubuntu.com/UbuntuDevelModeration has some guidelines I've been trying to establish
<Hobbsee> cjwatson: looks sane
<Hobbsee> except maybe the "Point of contact for upstream developers to reach Ubuntu developers" - thoought that was -discuss
* Hobbsee chops off mvo__'s tail.
<Hobbsee> there can only be one mvo!
* StevenK hums the theme to Highlander.
<seb128> mvo: cursing your provider again? ;)
<mvo> seb128: oh yes
<pygi> mvo: why is your provider always so bad :P
* mvo looks up in the CoC if cursing is allowed
<mvo> I think my ISP hates me
<StevenK> mvo: "Oh T-Online, how I loathe and desipe thee?"
<pygi> meh, T-* sucks very much
<Hobbsee> mvo: against ISP's?  yes.
<Hobbsee> mvo: even defenestration is allowed, in some circumstances
<StevenK> I'm curious how you plan to defenestrate Telstra.
<Hobbsee> i'll find a way
<StevenK> Heh
* Hobbsee might just defenestrate pygi instead.
<pygi> you cannot touch me
<pitti> (funny word)
<cjwatson> Hobbsee: oh, that part is just a quote from the original charter ...
<Hobbsee> ah right
<pbn> Goddamnit, this machine is always being rebooted
<seb128> Riddell: when you open a sync request and a patch can be dropped could you mention which one or what it was doing and why it can be dropped?
<Riddell> seb128: sure, let me add a comment
<pitti> BenC: FYI, kexec-tools MIR approved, promoted
<BenC> pitti: thanks
<Riddell> seb128: done
<seb128> Riddell: thanks
<BenC> pitti: patch commited for typo in coredump handler
<pitti> BenC: just saw it, thanks
<BenC> pitti: Current gutsy is an ABI bump, but if you want to test the tree, it should be good (sans lum/lrm)
<dholbach> Riddell: I think they drop the distro icon
<dholbach> Riddell: that was last time I checked and I didn't just sync it
<dholbach> Riddell: I don't care about the changelog, so if that's the only thing, .... :)
<seb128> dholbach, Riddell: I did sync it sync there was a sync bug open
<dholbach> Riddell, seb128: ok, I'll check it once again
<seb128> dholbach: though I didn't flush the sync queue yet so I can undo, let me know
<Riddell> dholbach: distributor-logo.png is still there, with build system stuff to work out which one to put there
<dholbach> Riddell: ok, sounds good
<dholbach> let's do it then
<Riddell> I think seb128 is ahead of us :)
<pygi> hey dholbach 
<Riddell> dholbach: are you going to look at tangerine-icon-theme?  I suspect it's in a similar position
<dholbach> i'll look at it in a bit
* Hobbsee hugs dholbach 
* dholbach hugs Hobbsee back
<Hobbsee> :)
* pygi in turn kicks Hobbsee :)
* Hobbsee gives pygi a BOOT TO THE HEAD.
<pygi> Hobbsee: sorry, you know you can't do me anything
<elkbuntu> Hobbsee, is the stick in for repairs?
<pygi> elkbuntu: nah, she knows she can't touch me
<elkbuntu> pygi, well of course, she wasnt going to... that's the whole point of the stick ;)
<Hobbsee> hehe
<Hobbsee> nope
<pygi> elkbuntu: no, no. I mean she can't do anything to me
* Hobbsee just has multiple weapons
<pitti> doko: ufsparse moved to main
<pitti> doko: lp-solve as well, so happy OO.o building :)
<wasabi> scarey. latest upgrade... or something... broke /var/lib/dpkg/available
<wasabi> EOF after field name Original-Maintainer
<wasabi> Sure enough, it was an empty field.
<wasabi> Filled it in with "foo" and it works now.
<wasabi> Original-Maintainer something new and perhaps busted?
<StevenK> Which package?
<pitti> wasabi: that field exists for over a year, probalby just a particular package where it's broken
<doko> pitti: thanks, will enable it
<wasabi> libnss3-0d
<wasabi> Sure, but that package broke dpkg.
<wasabi> That's not really... good.
<pitti> $ acsh libnss3-0d|grep Original
<pitti> Original-Maintainer: Maintainers of Mozilla-related packages <pkg-mozilla-maintainers@lists.alioth.debian.org>
<pitti> hmm, looks fine here
<wasabi> Mine was empty.
<wasabi> In fact, that was the last field in my available file.
<fabbione> wasabi: i have seen stuff like that happening at random with fs corruption or bad ram
<pitti> wasabi: which version?
<wasabi> Which makes me wonder if something ... was torn off the end.
<fabbione> i would rather spend time checking that than a broken package
<seb128> looks like a local corruption indeed
<wasabi> bah.
<wasabi> [51806.444903]  Call Trace:[51806.444925]   [<ffffffff802948ca>]  get_slab+0x1ca/0x260[51806.444931]   [<ffffffff80294a1d>]  __kmalloc+0xd/0x80
<wasabi> There's a stack trace in my dmesg. =0  And "nvidia" is in it!
<fabbione> wasabi: before you do anything bad with available.. there are backup copies of that file
<fabbione> make sure to reboot, check the fs extensively and in case roll back the file to a copy
<fabbione> and then re-update the machine
<fabbione> that should fix
<cjwatson> wasabi: you use XFS, don't you?
<cjwatson> wasabi: anyway, 'sudo dselect update' will refresh /var/lib/dpkg/available
<cjwatson> fabbione: available is entirely downloaded from the net, so who cares
<fabbione> cjwatson: ehr.. of course you are right.. confused with another file in there
<StevenK> status
<StevenK> Which is a little more important.
<StevenK> I've seen filesystem corruption that managed to swap the contents of available and status. dpkg was quite confused by that.
<pitti> Riddell: dolphin approved+promoted
<soc> hi
<soc> does someone know the status/progress of upstart?
<soc> what is expected to be released with gutsy?
<pitti> Keybuk for sure
<Riddell> pitti: woo, thanks
<Riddell> pitti: also I uploaded a copy of strigiapplet removing the build-depends on libextractor, it isn't actually used
<Keybuk> soc: hi, how can I help?
<pitti> Riddell: did you see my strigi IRC msg from this morning?
<pitti> Riddell: heh, snap; great
<soc> i wonder what's the status of upstart ...
<Keybuk> soc: from a strictly upstream POV, edgy shipped with 0.2.x, feisty with 0.3.x and gutsy will ship with 0.5.x
<soc> so what can we expect?
<Keybuk> the principal thing we're working towards is being able to have sufficient flexibility to define when all the services should be running
<Keybuk> and have a consistency of operation as a result
<Keybuk> if we achieve that, then we'll begin the process of migrating to using it natively
<soc> ah thx
<Keybuk> in hindsight, the version shipped with edgy was an interesting technology essay
<Keybuk> and wasn't actually ready to build on
<soc> so the guideline that only packages which were adapted to upstart are allowed to enter the repos isn't in effect yet?
<Keybuk> the version we shipped with feisty was much, much better (over 70% of the code was changed)
<pitti> Riddell: hm, no strigiapplet upload visible yet
<Keybuk> correct, we're about a release behind where we expected
<soc> ah ok
<superm1> Keybuk, will you also be writing a guide on properly migrating a package's init script to take advantage of upstart more appropriately?
<Keybuk> superm1: yes
<soc> but even edgy worked without problems, seemed to be very good work
<Riddell> pitti: my fault, one second
<soc> so will tracker some time use upstart, too or is this a per-user setting?
<Keybuk> soc: it was certainly very reliable
<soc> ^yes
<Keybuk> what's tracker?
<soc> never failed to work
* ogra wonders which calendars Keybuk was referring to in his mail
<soc> http://www.gnome.org/projects/tracker/
<Keybuk> the version in feisty was much more consistent, however.  especially with regards to how events and jobs behaved together
<pitti> ogra: the two that appear in my evo that say 8:00 and 18:00? :) (fridge + distroteam)
<soc> like beagle, but without mono
<soc> (and quite a bit faster)
<Keybuk> soc: to start, you mean?
<soc> yes
<Keybuk> not for gutsy
<soc> ah ok
<seb128> the indexing is by user
<seb128> no?
<seb128> it's using a .desktop autostart which works correctly
<seb128> why do you want to change to upstart?
<ogra> pitti, well, isnt 18:00 CEST 16:00 UTC ?
<seb128> ogra: 16utc is wrong time, meeting is 15utc
<soc> i didn't want to change it, i was just curious ...
<ogra> seb128, i know, i wa just asking which calendars was referred to
<soc> i'm trying to understand things a bit better
<pitti> ogra: right, meeting is at 1500 UTC/1700 CEST though
<ogra> seb128, since fridge says 16:00 UTC :)
<soc> can somebody able to tell me, what is upstart's relation to dbus?
<ogra> (and did so since yesterday)
<ogra> so i was wondering if i miss a new calendar
<Keybuk> soc: dbus is a messaging bus, upstart is a service manager
<Keybuk> soc: dbus is used to pass messages between applications
<soc> will they be able to communicate or are they a completely different osi-layer?
<Keybuk> soc: upstart is used to start and stop applications
<soc> yes, but is it possible to pass events through dbus to upstart?
<Keybuk> soc: it is entirely reasonable that you would be able to communicate with upstart via dbus
<Keybuk> soc: that is planned
<soc> ah ok, sorry, if i sound a bit helpless ...
<Keybuk> that's ok
<soc> i'm currently trying to learn proper debian packaging
<Keybuk> there are some interesting overlaps between upstart, dbus and HAL
<pitti> heno: colorblind approved+promoted
<soc> the guys over at motu are really friendly and helpfull ...
<Keybuk> in particular, dbus "service bus activation" and HAL's add-ons/helpers
<soc> i hope that gets sorted out
<Keybuk> we'll tackle those as and when we meet them
<heno> pitti: thanks
<soc> but packaging something with checkinstall versus packaging with debuild/pbuilder is quite a difference as i experienced :-)
<superm1> cjwatson, you got my mail with the patch that you had asked for the modularized glade?  You probably haven't looked through it thoroughly yet, but is that the general idea you were looking for? (I'd like to proceed with moving mythbuntu changes around that, so if it looks basically right I can continue)
<soc> does someone know when fglrx will be updated to work with xserver 1.3 again?
<ogra> ... mailto:support@ati.com ?
<soc> no, a working fglrx was released some weeks ago, bit in gutsy there is a old version which doesn't work with xserver 1.3
<ogra> ah
<ogra> sorry then :)
<soc> no problem :-)
<soc> hate this laptop ...
<soc> it's just not nice having to block 16 packages because of this damned ati driver
<Hobbsee> soc: pin?
<superm1> soc, or just disable the one in l-r-m for now, and use the package generation script in the .run file shipped by ATI
<soc> yes, i did pin it ... wasn't sure of the right term ...
<soc> but no problem, i'll wait for it ...
<soc> the ubuntu developers do a really great job transforming this trash into an usable form ...
<pygi> soc: ^_^
<johanbr> soc: A driver (alpha quality, probably) for the R500 ATI cards was just packaged for Gutsy. If that's what you have, you may want to try it out.
<soc> ok i'm on it!!!
<Riddell> pitti: Accepted strigiapplet
<soc> read about it, but didn't know that it was in gutsy already!!!!!!
<soc> i have an ati x14000
<johanbr> That must be a new card. :)
<soc> s/14000/1400
<soc> i thought so too
<soc> but in fact wouldn't be faster than a geforce 2
<soc> :-)
<soc> crappy binary drivers
<soc> johanbr: where do i get that driver?
<johanbr> xserver-xorg-video-avivo in the standard repo.
<soc> weird name ...
<soc> mhh didn't see that ...
<soc> don't see that
<soc> is it in main?
<soc> johanbr: i don't find it ...
<johanbr> So it's probably not on your mirror yet.
<seb128> it's not in main, no
<seb128> and it's on gutsy only
<seb128> it failed to build in fact, so no binaries yet
<soc> it's not on archive.ubuntu.com too ...
<soc> ahok
<soc> that explains it
<soc> btw, why are there some xserver-xorg-video packages and some xserver-xorg-driver?
<soc> when can we expect a working build?
<cjwatson> superm1: I did, it looks pretty good actually
<soc> ah thx
<superm1> cjwatson, great.  I'll proceed with getting our glade stuff to fit in with it then
<pygi> hey mvo :)
<mardi_soir> hello 
<mardi_soir> i d like to say that an upgrade yesterday with a kernel image update made  a bad thing to grub .. grub.conf or menu.lst have been replace by a grub.conf without any windows Xp reference 
<mardi_soir> on feisty linux .
<mardi_soir> hop i will not happen on the futur :)
<mardi_soir> and another thing i notice
<Hobbsee> er, that's because you modified your grub list, and stuck XP in the autoupdated section, i expect.
<mardi_soir> on a read only partion . nautilus do not allow to create a symbolic link (in order for exemple to make a link on  the desktop=
<mardi_soir>  (with right clic )
<mardi_soir> send link to desktop could be apreciate 
<pitti> Hobbsee: can bug 108870 actually be closed? It has a changelog which seems to indicate that
<ubotu> Launchpad bug 108870 in kubuntu-default-settings "[Feisty regression]  install two or more debian files with right click on them and install doesn't work" [Low,Fix committed]  https://launchpad.net/bugs/108870
<Tonio_> pitti: hi :) Was about to drop the pmount dep for kdebase, but looking at the debian/changelod, I must say I don't know what to do
<Hobbsee> pitti: see -meeting.
<Tonio_> pitti: it's bin removed by debian some time ago and they re-added it since it seemed to cause issues with HAL
<pitti> Hobbsee: ah, I see
<Hobbsee> pitti: i'm typing slowly today - i'm cold.  and i'm looking thse bugs up, and waiting on LP each time.  this takes time, from an au connection, so please be patient with me.
<pitti> Tonio_: the dependency is not necessary any more since edgy
<pitti> Tonio_: we tested that already
<Tonio_> hum, okay, let's upload a fix version then, I have a couple of other fixes to commit
<pitti> Hobbsee: oh, I wasn't hurrying; IRC is horribly lagging for me, so I didn't see your replies fast enough
<pitti> Tonio_: great, thanks
<Hobbsee> pitti: fair enough.  18 second lag on each launchpad page here...
<mardi_soir> Hobbsee,  yes i guess but it a problem 
<mardi_soir> it is 
<pitti> seb128: btw, please give me some gutsy crashers and dups of them, I wanna test my new toys :-)
<Hobbsee> mardi_soir: you wanted to make XP boot by default, or change the boot order?
<Hobbsee> and so moved the XP block into the autogenerated kernel list?
<seb128> pitti: maybe it's time to enable apport again ;)
<pitti> seb128: nah, I really want to get the private bug filing sorted out first
<pitti> seb128: the malone fix for that is in review now
<mardi_soir> Hobbsee, the problem is solved .. but i have modified the grub.conf for my sister's computer .. . (to make menu looks good with a custom string instaead of "ubuntu version" who looks bad for her .. and after a update windows was not present .. 
<pitti> seb128: btw, I'll clean up the existing CoreDump.gz attachments soon
<seb128> good idea
<pitti> seb128: the rejected/duplicate/fixreleased ones don't need discussion
<bddebian> Heya
<seb128> pitti: I've to run after the meeting but I can send you some crashes and dups tonight or tomorrow morning
<pitti> seb128: WDYT about the ones on open bugs which have a broken retrace?
<Hobbsee> mardi_soir: but did you move the windows section inside the autogenerated list?
<mardi_soir> Hobbsee, yes
<pitti> seb128: btw, you can re-tag existing bugs to have them retraced again, then they will get into the dup db
<Hobbsee> right.  then there's your problem.  you can modify the strings and such fine
<seb128> pitti:  broken retrace because of the retracer or because the crash file is outdate or b0rked?
<seb128> pitti: k
<pitti> seb128: hard to tell automatically
<mardi_soir> Hobbsee, yes this is the reason of my presence here .. to notify develloper about this . :)
<seb128> pitti: that them so we can review the list easily?
<seb128> s/that/tag
<mardi_soir> Hobbsee,  a set of sed instruction could easyly solve this i guess 
* Hobbsee isnt quite sure that it's a bug, but sure.
* Hobbsee doesnt work on grub.
<pitti> seb128: I actually have another idea
<pitti> seb128: ok, I'll leave the core for open non-dup bugs for now and think about it some more
<seb128> pitti: ok
<pitti> mardi_soir: btw, there is a bug about that, let me look
<pitti> mardi_soir: bug 21412
<ubotu> Launchpad bug 21412 in grub "Default update-grub behaviour is not intuitive with respect to user modifications" [Medium,Confirmed]  https://launchpad.net/bugs/21412
<mardi_soir> ok pitti thank 
<pitti> ubotu: mdz recently said that we shuold really aim for a solution for this in gutsy, so there's some hope :)
<pitti> erm, mardi_soir ^
<pitti> what made me type ubotu??
<Tonio_> pitti: talking about the upload queue, can you confirm me if kio-umounwrapper is still in NEW please ?
<seb128> Tonio_: it's not good to be accepted
<Tonio_> seb128: ah ?
<seb128> I switched to somethijng else this morning but I think there was problems with it
<seb128> let me look quickly
<Tonio_> thanks
<Tonio_> seb128: I noticed an issue in the postrm file after uploading, I wanted to fix once accepted
<seb128> ah right, I think that was the one call debconf to an install script but which is not using debconf in fact
<seb128> s/call/calling
<seb128> and do you need all those comments?
<seb128> Tonio_: please fix the debconf use, out of that it looks ok
<seb128> I've to run, later
<iwj> pitti: So what's this about apport and a separate place where crash reports get filed ?
<Tonio_> seb128: debconf ?
<Tonio_> seb128: I didn't notice debconf stuff in it.... talking about dpkg-divert usage maybe ?
<pitti> iwj: (CC: asac) the immediate solution which will give us 90% of the desired effect is https://wiki.ubuntu.com/CrashReporting
<seb128> Tonio_: grep for debconf in the prerm
* iwj looks.
<Tonio_> seb128: ho indeed, evil.....
<pitti> iwj: in short: file bugs privately, have the retracer do its job, delete the core dump, and then subscribe the triaging teams
<seb128> later
<pitti> iwj: longer-term solution is to introduce a proper 'crash table' concept into Launchpad
<iwj> pitti: Oh, yes, that sounds very sensible.
<pitti> iwj: kiko and Bjorn have some concrete ideas about that, and we had a ~ 90 minute discussion about the behaviour
<iwj> Sorry, I should have read it before asking.
<pitti> iwj: that approach will avoid bug spam and a totally public data exposure, but it intrinsically limits the number of people who can take a look at the crashes, of course
<pitti> np
<iwj> Indeed.
<asac> pitti: good is that we get access-control 
<asac> pitti: from launchpad.
<pitti> right, and we never expose core dumps to humans at all
<asac> pitti: but i still have a bad feeling about using bugs to process crashes at all
<pitti> asac: why?
<Tonio_> hum is that necessary to increment the version number f a package still in NEW ?
<pitti> oh, crud -- it just occurs to me that dup detection of Python crashes doesn't work ATM
<asac> i mean ... it somehow heavy weight imo
<pitti> Tonio_: no, it isn't
<asac> and not really flexible
<Tonio_> pitti: thanks
<asac> e.g. i think we get a crash db anyways?
<pitti> Tonio_: please ask seb128 or me to reject the old one though, so that we don't get confused about which one to accept and which to reject
<pitti> asac: we will, right
<asac> for duplicate matching ... why not contain info in that
<pitti> asac: but the 'master' crash will be escalated as a bug anyway
<asac> yes right
<pitti> so whether the place where we store it has a 'crash' or a 'bug' label doesn't really matter
<asac> i would open a master crash when i see a crash that happens multiple times
<pitti> in terms of storage space or workflow
<pitti> you have to review the crashes in both cases
<Tonio_> pitti: you can reject the old one now, I'm about to upload the fixed package
<Tonio_> pitti: in fact I already uploaded it :)
<pitti> I haven't found an use case so far that showed me how a separate crash table that humans interact with makes things any eaier
<pitti> easier
<asac> pitti: i don't know ... if they are one time crashes i usually don't want to look at them
<pitti> Tonio_: great, thanks
<asac> pitti: at least if there is no good testcase
<pitti> asac: so don't :)
<pitti> asac: so, the separate crash table would be easier for prioritizing etc.
<asac> and having all these wierd crashes associated with a bug id, sounds heavyweight
<asac> e.g. all get backups ... stays available forever et al
<pitti> asac: NB that we *will* get it; what I'm saying is that private bugs are 'almost' as good for now
<asac> ah ok :)
<asac> pitti: if its an intermediate solution then its pretty elegant
<pitti> so, I'll see to making this dup stuff work for python crashes, too, to make cjwatson and evand happy :)
<pitti> Tonio_: oh, what was the pacakge name?
<pitti> Tonio_: ah, kio-umount wrapper?
<Tonio_> kio-umountwrapper
<Tonio_> pitti: true
<pitti> Tonio_: ok, I killed the old one
<pitti> Tonio_: oh, there are more; killing the middle-aged one, too
<Tonio_> pitti: there was 3 uploads ???????
<pitti> Tonio_: yes, apparently so
* evand hugs pitti 
<Tonio_> hum lure probably uploaded after me in fact...
<Hobbsee> Is any member of management of Canonical going to comment on http://www.linspire.com/linspire_letter.php anywhere public?
<pygi> Hobbsee: wasn't that already commented on?
<elkbuntu> pygi, by who? where?
<pygi> elkbuntu: oh, that's new
<pygi> I saw the last letter I think
<Hobbsee> pygi: not by a person from Canonical, i believe
<pygi> Hobbsee: indeed, sorry. I was refering to the old letter.
<Hobbsee> pygi: it's hit planet and such, and is getting responded to.
<Hobbsee> ahh
<pygi> Hobbsee: great, double bed :-/
<Hobbsee> s/bed/bad/?
<pygi> Hobbsee: no, the bed :P
<pygi> because they have pact with two completely opposite sides
<Hobbsee> oh right
<pygi> Hobbsee: ^_^
<Hobbsee> hm?
<pygi> Hobbsee: just read the letter. He's trying to say he's not doing anything bad, and we should all follow his way :P
<elkbuntu> aka 'come to the dark side'
<Hobbsee> heh
<pitti> *shrug* apt-get install microsoft-office would certainly be good for improving the chance of Linux to get adopted widely
<pitti> so, as much as I love free software, that guy has a certain point
<Hobbsee> commercial repo's presumably the solution to that
<pitti> Hobbsee: well, commercial repo is the vehicle
<pitti> but you need something to put into it :)
<evand> it struck me that he was using the lure of microsoft software to mask the fact that he was really making a deal over patents.
<pitti> M$ did a really good job of nailing people tightly to their products once they started using it
<Hobbsee> yeah, true that
<pitti> evand: right, that's the bit that is frightening me (just as with the Novell deal)
<pitti> but some people I know are mainly nailed to things like their extensive collection of Excel spreadsheets and scripts, etc.
<pitti> they don't actually need the Windows beneath it, but they do need e. g. office
<pitti> so, we can only hope that there's something in for the free software world as well, and that all those Novell/Linspire deals aren't just a Trojan for more patent wars
<evand> indeed
<Amaranth> I'm actually leaning toward the theory eben moglen had
<Amaranth> at least i think it was him
<Amaranth> microsoft doesn't want to piss off businesses by threatening to sue them but it does want to stop the developers
<Amaranth> these deals give them a way out of the problem, the businesses will be safe
<pitti> Amaranth: interesting, how so/
<pitti> ?
<pitti> door bell -> brb
<Amaranth> http://youtube.com/watch?v=6YExl9ojclo&v3
<wasabi> So does Debian or us have any policy about generating debsums for each package?
<the_dark_lord> hello
<rohan> is there any way to disable libata in feisty, without rebuilding the kernel ? e.g. by blacklisting a module or so ?
<pitti> yay, python crash dup detection works now
<rohan> btw, this is strange .. first with the stock feisty kernel, libata was enabled .. then in build .16-23 it was disabled.. and now again in .16-29 it is enabled .. why are so 'major' changes taking place in a _Stable_ release ?
<pitti> rohan: that change was a major fault in -16.28 and thus was reverted again in -16.29
<rohan> pitti: oh .. that was the best thing that had happened to me :(
<pitti> rohan: we will make sure to avoid such things in the future, we had a big discussion about it
<rohan> libata works really horribly here, causing cd drive timeouts every now and then
<pochu> pitti: that's great :)
<mathiaz> What is the role of linux-backports-modules package ?
<pitti> mathiaz: AFAIUI, it's for post-release updates which we do not want to force upon a default install
<mathiaz> pitti: thks. What are the solutions to provide a module that is not included in the kernel ?
<pitti> mathiaz: that's quite tricky; common practice for now is to provide a -source package and use module-assistant
<mathiaz> pitti: hum. That's how things are done for apparmor now.
<pitti> mathiaz: but I thought the modules were supposed to get into the proper kernel package?
<mathiaz> pitti: is there a way/common practice that avoid end users compiling the module ?
<pitti> mathiaz: not really; we either put it into linux-ubuntu-modules, or provide a source
<pitti> maintaining a separate package and follow the ABIs is way too much effort
<mathiaz> pitti: well. I misunderstood that part. What goes into the kernel is a small patch that make it possible to compile the module
<pitti> mathiaz: OIC; it won't go into l-ubuntu-modules then?
<mathiaz> pitti: NAFAIK
<mathiaz> pitti: for now, it's just the 2 line patch that goes into the kernel.
<mathiaz> pitti: I misunderstood that part. I thought it would be the whole module.
<pitti> mathiaz: we should discuss that on the ML
<pitti> mathiaz: also in conjuntion with the apparmor MIR
<pitti> mathiaz: even if the kernel would provide the modules by default, I have the feeling that apparmor is just not mature enough yet to be put into main now; even less so if there are no kernel modules available
<mathiaz> pitti: ok. I'll send an email to ubuntu-devel.
<mathiaz> BTW, what's the difference between linux-ubuntu-modules and linux-image ?
<wasabi> ENV{FOO} in a udev rule. What does this refer to?
<wasabi> ENV{ID_FS_TYPE} actually.
<shawarma> wasabi: by the looks of it, it checks the value of an environment variable by the name of "ID_FS_TYPE". Just a guess. 
<DexterF> hi
<pitti> mathiaz: linux-image is by and large upstream kernel, and -ubuntu-modules are 3rd party drivers (e. g. linux-wlan-ng, external wifi drivers, etc.)
<DexterF> nfs issue: got an nfs v3 server, have some shares in fstab here on 7.04, and tho I can access them they don't show up in "mount" or "df". how come?
<DGMurdockIII> hi
<DGMurdockIII> has then been any work dose on making the sound better in ubuntu
<DGMurdockIII> work done*
<crimsun> what do you mean by "making the sound better"?
<crimsun> driver? audio theme(s)?
<DGMurdockIII> drivers
<crimsun> sure, there's ongoing work.  Do you have something specific in mind?
* Starting logfile irclogs/ubuntu-devel.log
<cjwatson> turk_: why do you need to?
<cjwatson> it goes in the parent of wherever you're building. if you want it somewhere else, build somewhere else or else move it afterwards. :)
<turk_> yeah; i'm looking for a way to automate something and i was just wondering why it wasn't an option
<cjwatson> it's also not just dpkg-buildpackage involved, it's scripts called by debian/rules
<cjwatson> (e.g. dh_builddeb but not quite everything uses that)
<cjwatson> so it's much more reliable to just have it be fixed
<turk_> ok, thanks for the info
<siretart> asac: new python-debian in debian now, which should fix your problem. please report if it doesn't
<asac> siretart: ok cool. thanks!
<pkern> Is Henrik Nilsen Omma here?
<mc44> pkern: heno, he is offline now by the looks of it
<pkern> mc44: Thanks.
<mc44> pkern: try in european working hours :)
<pkern> Well I just received a mail from him.
<pkern> An hour ago.
#ubuntu-devel 2007-06-15
<wasabi> iwj: Curious about the state of mdadm in the initramfs. I'm personally have some issues (won't work) on feisty with it. Fixed them up by removing most of the code in local-top/mdadm and replacing it with a procedure that always does a full scan to build a config file, and assembles everything. Do you have any plans with regards to this?
<owh> I'm trying to fix a bug in gphpedit. I think that the problem is that a parameter being passed is defined as a gint, but expected to be a glong. There are over 300 parameters to check. I'm using dpkg-buildpackage -rfakeroot -uc -b to build the package. How do I get the compiler to tell me of these mismatches?
<Burgundavia> owh: try in -motu
<owh> Heh, I just came from ubuntu-bugs, but I'll ask. Tah.
<Viper550> hello!
<jsgotangco> Viper550: wow long time no see
<Viper550> Unfortunately, I'm not using any Linux anymore, the hard drive in one of my older computers died, and we had to use my Linux hard drive to get it back up and running
<Viper550> Speaking of getting things back up and running, I heard Dell has Ubuntu now. It's old news, but still
<Viper550> You know how most newer systems have those recovery partitions and all that jazz?
<jsgotangco> yes
<jsgotangco> even the dells with ubuntu have those
<Viper550> really?
<Viper550> But, how does it work? Is it a *ironically* Norton Ghost image or something?
<jsgotangco> not sure can't remember, it has does files though
<jsgotangco> s/does/dos
<Viper550> But, anyway, here's my idea: we should code a system recovery system, a full-featured recovery for Linux system builders, open-source
<pitti> Good morning
* StevenK waves to pitti
<Hobbsee> hi all
<pygi> morning
<pitti> Hobbsee: was bug 108870 verified now?
<ubotu> Launchpad bug 108870 in kubuntu-default-settings "[Feisty regression]  install two or more debian files with right click on them and install doesn't work" [Low,Fix committed]  https://launchpad.net/bugs/108870
<Hobbsee> pitti: not yet.
<pitti> Hobbsee: so I assign this to you if you don't mind?
<Hobbsee> pitti: herd 2's...when?
<Hobbsee> no, that's fine
* Hobbsee cant do any RE atm - need to leave for work in ~10 mins, and find a good book first.
<Hobbsee> oh, and breakfast
<pitti> great, so all tribe-2 bugs have assignees now
<pitti> Hobbsee: June 28th
<Hobbsee> i dont consider kubuntu-team to be an assignee
<Hobbsee> right
<pitti> Hobbsee: sorry, June 19th
<Hobbsee> what???
<Hobbsee> oh fudge, i thought it was later
<pitti> no, bogus
<Hobbsee> okay, will look when i get home.
<pitti> June 28th is right
<Hobbsee> good.
<pitti> July 19th was tribe-3 already
<Hobbsee> hehe
* pitti <= needs more tea
<Hobbsee> clearly
* Hobbsee hands you a cup of tea
* Hobbsee needs a lassoo, a cattle prod, and maybe a taser too.
<shawarma> In theory, if someone were to upload a package with this copyright/license (last three lines): http://search.cpan.org/src/CFRANKS/Perl6-Junction-1.30000/README    What would happen?
<shawarma> Good morning, by the way :)
* Hobbsee calls upon mneptok 
* pygi doesn't see any problem
<pygi> shawarma, I do believe however that you're supposed to add COPYING and stuff then
<shawarma> pygi: It's mostly to do with the "All rights reserved" bit.
<pygi> shawarma, meh, yea, he claims authorship rights
<pygi> every author claims that
<pygi> whetever you have that written or not
<pygi> (/me has law, had his exam few days ago :P)
<Hobbsee> haha
<Hobbsee> poor pygi 
<pygi> Hobbsee, I'll pass with A even :P
<Hobbsee> woo!
<Hobbsee> do the rest of my exams then.
<pygi> Hobbsee, nah, I'll fail some :P
<pygi> Like informatics :p
<shawarma> pygi: I see. I was under the impression that that particular statement Conflicts: GPL..
<pygi> Hobbsee, but I'll get A from organization :p
<pygi> shawarma, IMHO it doesn't.
<Hobbsee> heh
<pygi> shawarma, I do however think that the package must have COPYING and stuff, otherwise you need to add it
<pygi> shawarma, is perl under gpl?
<shawarma> pygi: Hm. Yes, I see what you mean.
<pygi> shawarma, if possible, just mail the author and tell hjm to remove the line. But what we're talking here are authorship rights, and GPL grants other types of rights:
<pygi> material ones, which would be: distribute, say about it (advocate), reproduce (use, whatever), and modify
<shawarma> pygi: Ok. Interesting.
<pygi> shawarma, what licence is perl?
* pygi wonders when did he start turning into a lawyer :P
<pygi> Hobbsee, which exams do you have left?
<shawarma> pygi: See /usr/share/doc/perl/copyright :)
<shawarma> pygi: It's GPL-1 and Artistic.
<shawarma> pygi: AFAIR
<pygi> GPL1 or later, and Artistic
<pygi> got it ^_^
<Hobbsee> pygi: maths, electronics
<pygi> Hobbsee, I can pass the second one for you ^_^
<Hobbsee> oh good
* Hobbsee doesnt grok electronics *at all*
<pygi> with pretty good grade I think as well =)
<pygi> math I have as well
<pygi> shawarma, any more questions? :)
<pygi> hey Zdra 
<shawarma> pygi: I just took a peek at some existing packages. libtext-format-perl, for instance, has a "all rights reserved" bit in there, and also does not contain a COPYING nor LICENCE file.
<Zdra> hello pygi
<pygi> shawarma, I really think *every* package has to have that
<pygi> shawarma, it isn't connected to that particular bits
<shawarma> pygi: I know. I'm just saying. :)
<shawarma> pitti: Archive admin question for you:
<shawarma> 08:47 < shawarma> In theory, if someone were to upload a package with this copyright/license (last three lines):  http://search.cpan.org/src/CFRANKS/Perl6-Junction-1.30000/README    What would happen?
<shawarma> pitti: Also, the package (like many other perl packages, it seems) does not have a LICENSE or COPYING file or anything to that effect.
<pygi> Zdra, If I manage to get around this segfault I'll show you something ^_^
<pitti> shawarma: that's indeed invalid, and I reject such pacakges
<pitti> shawarma: there must be a verbatim copyright text in the orig.tar.gz, and debian/copyright must either point to common-licenses, or also have a verbatim copy, or at least have a pointer to perl's installed copyright file
<Zdra> pygi: I'm curious :)
<pygi> shawarma, told ya ^_^
<lifeless> have a good weekend
<pygi> lifeless, same ^_^
<pitti> mvo: erk, why does gksu rely on the password prompt for determining whether the password was wrong; shouldn't it be enough to look for 'Sorry, try again.'?
<mvo> pitti: it probably should
<shawarma> pitti: Ok, thanks.
* pitti boggles
<mvo> pitti: is there a bug open for this already?
<pygi> mvo, he's gone :P
<dholbach> good morning
<pygi> hey daniel
<dholbach> hey Mario
<pitti> hi Tonio_ 
<pitti> Tonio_: do you know how kdesu works? I just found out that it never forgets my password (bug 88580)
<ubotu> Launchpad bug 88580 in kdebase "kdesu accept any password" [Critical,Confirmed]  https://launchpad.net/bugs/88580
<Tonio_> pitti: yes, kdesu is a mess
<pitti> I already grepped my ~ and /tmp, and cannot find my password; where the heck is it stored?
<Tonio_> pitti: in fact it doesn't remember the password so asks for it everytime
<pitti> Tonio_: well, it asks every time, but it accepts any password
<Tonio_> but if you already gave the good password a few minutes ago, a bad password will be accepted
<pitti> Tonio_: but if I quit the desktop session, kill -15 -1, and log in again, it should be gone for good
<pitti> and it isn't
<Tonio_> pitti: I wouldn't consider this a security issue as a bad password is accepted when it shouldn't ask for a password
<Tonio_> pitti: here is the point : http://www.launchpad.net/kdesudo
<pitti> Tonio_: right, but the point is, it should ask for a password if I never entered it at all
<Tonio_> pitti: a project I and other guys are working on to replace kdesu for gutsy
<pitti> and after sudo -K and everything
<Tonio_> pitti: that works better but needs improvement to replace kdesu fully (kcontrol etc...)
<Tonio_> pitti: if we succeed, there is a plan to make a class for kdelibs to make it to work correctly with sudo
<shawarma> pitti: Perhaps kdesu doesn't use sudo as a backend, but implements it itself?
* shawarma has no idea, though.
<Tonio_> pitti: but that'll take time..... kdesu is very complex, there is no easy way to fix it, except replace the code
<Tonio_> pitti: so the current plan is to replace kdesu in gutsy, hope we succeed
<Tonio_> pitti: kdesudo already works correctly, just has problems when called within a kcm module, since it misses a few command line options
<pitti> Tonio_: ah, I see, I still had a sudo stamp for it, so sorry for panicking; that apparently survives logout
<Tonio_> pitti: well yes, the way kdesu works with sudo is a bit hackish....
<Tonio_> pitti: if you're interested in kdesudo, I'd appreciate your opinion reguarding the code concerning the security, as it'll have to go through the MIR process :)
<pitti> at least I'm calmed down now again, seems it doesn't store my password anywhere :)
<Tonio_> pitti: hehe :)
<Tonio_> pitti: kdesu doesn't, indeed
<Tonio_> it just asks for your passwords, then calls for sudo that doesn't require your password, so the bad password succeeds
<Tonio_> evil isn't it ? ;)
<Tonio_> pitti: btw kedsu will of course fail with any kind of custom sudoers file, for example if you want to give a simple user a "nopasswd" access to one command only
<Tonio_> pitti: that's one of the many problems we have with it...
<Tonio_> Lure: hey ;)
<Tonio_> Lure: you know c++ right ? ;)
<Lure> Tonio_: right
<shawarma> pitti: It's amazing. I've pulled out 10 lib*-perl packages at random to see how they've done their COPYING or LICENSE or whatever they'd felt like calling it.. *None* of them had one.
<shawarma> pitti: It seems libgnome2-perl has one, but that's only GPL-2 (not the usual "same terms as perl itself").
<Tonio_> Lure: we need people to help on the kdesudo part, which is important for gutsy :)
<Tonio_> Lure: interested joining the team ?
<Lure> Tonio_: I can look into this, but has very limited time in next couple of weeks
<Tonio_> Lure: sure :)
<Tonio_> Lure: well it is pretty advanced now, the currently point is to add all the command line options kdesu has, to make the replacement easy
<Tonio_> Lure: you should joint the team on the launchpad project page :)
<Lure> Tonio_: can you write down in e-mail what is there and what is to be done?
<Tonio_> Lure: will do thanks
<pitti> shawarma: yeah, that stuff is a mess; I wonder how all that passed Debian NEW
* shawarma boggles
<shawarma> pitti: No idea. 
<Mirv> mdke_: hi, what about ubuntu-docs updates for Ubuntu 7.04? (https://lists.ubuntu.com/archives/ubuntu-translators/2007-March/001039.html)
<Mirv> ("we will ensure that we do translation updates during the life of Ubuntu 7.04)
<pitti> mvo: hm, I just looked into libgsku, doesn't seem to be that easy; do you know that code?
<mvo> pitti: a bit
<pitti> mvo: I'd like to upload http://people.ubuntu.com/~pitti/tmp/sudo.8556.debdiff, but that currently breaks gksu (it doesn't notice wrong passwords and just exists)
<mvo> pitti: out of curiosity, does it work when you give it a message without a space in it?
<pitti> mvo: oh, I don't know, let me try
<pitti> mvo: hmm, there's a g_strsplit() in the su handler, but not in the sudo one
<pitti> mvo: indeed, that works
<pitti> mvo: [sudo] _password_for_martin:  -> that works
<pitti> mvo: [sudo]  password for martin:  -> breaks
* mvo nods
<mvo> pitti: I do not have the code in front of me currently, but I do remember that there is a lot of parsing and ugliness. I wish there was a simple protocol to talk to sudo
<mvo> pitti: the trouble is that the current approach does e.g. not work with callange-response authentication methods in gksu
<cjwatson> pitti: err, practically every perl module in existence has that boilerplate licence statement
<cjwatson> pitti: are you going to reject several hundred packages from the archive?
<cjwatson> pitti: it's entirely standard and well-understood in the Perl world
<pitti> cjwatson: not from the archive of course, but I do reject such packages from NEW
<cjwatson> shawarma: I would accept that provided that debian/copyright clarifies
<cjwatson> that is standard practice
<shawarma> cjwatson: Remind me to upload on you archive-admin day, then :)
<pitti> cjwatson: we essentially distribute orig.tar.gz's without any license at all
<cjwatson> pitti: we really don't, it's completely clear
<cjwatson> "under the same terms as Perl itself" is a licence
<pitti> 'the perl license' is not a license, and it's not even a fully qualified pointer to a license
<cjwatson> it may be a licence by reference, but it is a licence
<cjwatson> it says that if the licensing of Perl changes then the licensing of this package does too *shrug*
<pitti> it's not even clear that it is "perl, the programming language" instead of "perl, the hackish scirpt that pitti distributes on his homepage
<cjwatson> oh, come on
<pitti> cjwatson: right, but we are talking legalese here...
<shawarma> It's quite amazing. Out of 122 packages whose README has "same terms as" somewhere in it, only 10 packages have either a COPYING or LICENSE file.
<cjwatson> it's totally obvious in the field, and I claim that any judge would agree with me
<cjwatson> legalese does not have to be code
<pitti> cjwatson: with common sense I agree to you, but with common sense we wouldn't need to be so picky about all the source new checking
<pitti> cjwatson: so, of course I won't make a fuss about all the existing perl modules
<cjwatson> we have so many examples of this that it should be grandfathered anyway
<pitti> cjwatson: but there has been stuff in source new which was similar and refered to less prominent projects
<pitti> and for new Ubuntu specific packages I just don't accept it
<cjwatson> if you go and ask a Perl module upstream to change this they'll look at you like you were insane
<cjwatson> because it is *not* *unclear*
<cjwatson> I agree it needs to be clarified in debian/copyright, but really, that's all it should take
<pitti> cjwatson: IMHO debian/copyright is much less important
<pitti> we need to have a license for distributing the tar.gz; a pointer to perl in debian/copyright is fine since within a distro we know what perl is
<cjwatson> within the IT industry we know what perl is
<cjwatson> I think it is specious to claim otherwise, honestly
<pitti> cjwatson: I already said that I won't make a fuss about perl
<cjwatson> particularly since there is no other consistent referent; it is obvious that the software is designed to work with Perl, the programming language
<pitti> but I did reject stuff that refered to less common projects and which was ubuntu specific
<pitti> zakame: xmms2 FTBFSed on amd64, can you please have a look? I let it sit in the NEW queue for now
<Tonio_> seb128: ping ?
<seb128> Tonio_: hi
<Tonio_> seb128: hi ;)
<Tonio_> seb128: I'm attempting to package nm 0.6.5, we need it for kubuntu/knetworkmanager
<pitti> Tonio_: great!
<Tonio_> seb128: the gnome applet has been splitted from the source code, which means new package, revu process etc...
<seb128> Tonio_: I'm happy to do it
* Riddell wonders how much seb128 uses revu :)
<Tonio_> seb128, pitti: is the complete process required, cause that'll take a lot of time to get the new package in
<seb128> Riddell: I don't, I've no account there and I don't intend to create one
<Riddell> although I can NEW it now :)
<pitti> Tonio_: *shrug* for my sake just upload it, and we'll review it in NEW
<seb128> I get dholbach usually to add comments for me there :p
<seb128> well
<Tonio_> pitti: okay
<ogra> does anyone know from the top of his head where i can adjust the keepalive time for tcpd ?
<seb128> don't upload a n-m which drops the applet before packaging the new one
<pitti> Tonio_: as long as it's a standard /usr/share/cdbs/1/class/gnome.mk package without much fuss and works, it shouldn't be too bad
<Tonio_> seb128: of course, I'm not that stupid hehe ;)
<Tonio_> I'll upload them at the same time
<Tonio_> probably with the new knetworkmanager too
<Tonio_> pitti: okay same process than with kde packaging in fact
<pitti> seb128: why, the deb won't disappear automatically
<Tonio_> pitti: the applet might not be compatible, 0.6.5 is a major change
<pitti> Tonio_: ^ you can upload them independenty *as long* as they do not break the nm-applet <-> n-m daemon ABI
<seb128> pitti: does the old applet work with the new version?
<pitti> Tonio_: right, that's what I was aiming at
<pitti> seb128: nevermind, see above
<seb128> right
<Tonio_> seb128: adunno at the moment
<Tonio_> seb128: what I know is that the new applet won't work with the old backend
<pitti> Tonio_: ok, so please uplaod the new gnome pkg first, with a strict enough dependency to network-manager
<Tonio_> but as ascending and descending compatiblity are not the same problem, that might work, indeed
<Tonio_> pitti: okay
<pitti> if old applet works with new daemon, that's good
<Tonio_> pitti: well I may have the new daemon package available soon, I might ping here for people to test
<pitti> I'm glad to help with testing
<seb128> I can do testing as well
<Tonio_> great, thanks ;) I'll test the kde part
<Tonio_> it's also important to test the vpn plugins....
<Tonio_> I don't have any sisco router to test vpnc, but I can test the openvpn part
<pitti> can't help with that, sorry
<seb128> me neither
* cjwatson scratches his head over a reported crash due to the g_slice vs. g_thread_init thing in ubiquity, which is supposed to be non-threaded
<shawarma> cjwatson: The error message says that g_thread_init should be called before *any* other glib call..
<cjwatson> am I supposed to add gobject.threads_init() to the top of my program?
<cjwatson> shawarma: it does, but the documentation says "Before you use a thread related function in GLib"
<pitti> that's what I see for gksu as well
* shawarma shrugs
<pitti> but it seems to only be a warning and relevant if you use it at all
<shawarma> seb128: You seemed to know somethings about that? (the g_thread_init error thing)
<cjwatson> pitti: well, ubiquity's segfaulting, which is kinda hard for a python program, so *something's* wrong :)
<pitti> cjwatson: some gtk library probably uses it?
<slomo> cjwatson: even import gtk; or import pygtk; will call glib functions so you can't call it as first glib function in python
<shawarma> slomo: Then *they* should call it.
<seb128> there is some discussions upstream
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=331853
<ubotu> Gnome bug 331853 in general "Handle using gslice before g_thread_init() better" [Normal,Reopened]  
<slomo> shawarma: see the comments on the upstream bugreport and the list discussion :)
<seb128> you can call g_thread_init() as a workaround for now
<seb128> http://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00005.html also
<cjwatson> so, that's from January and reportedly breaking our installer in June, so I need to consider whether a workaround is available
<seb128> cjwatson: yeah, we just upgraded to glib 2.13 some weeks ago
<seb128> call g_thread_init() at the start of your program to fix it
* shawarma -> breakfast
<cjwatson> seb128: sadly, http://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00035.html indicates that I cannot, because I call setlocale at various points through the program
<pkern> Any Ubuntu sysadmin in here, familiar with the Sobby instance Ubuntu hosts?
<cjwatson> though I guess if I never *create* threads ...
<Tonio_> seb128: there is a fixed kio-umountwrapper waiting for you in new, if you have a moment
<Tonio_> seb128: we need a MIR fo this for kubuntu, so it'd be nice to have people testing this in universe a bit before ^^
<blackskad> cjwatson: don't you create a new thread every time you call gtk.main? (just a guess...)
<seb128> Tonio_: will look into it
<Riddell> pkern: #canonical-sysadmin
<pkern> Riddell: Thanks.
<Tonio_> seb128: many thanks
<seb128> you're welcome
<cjwatson> blackskad: my understanding may be lacking, but I didn't think so. For example, the documentation of g_main_depth says "The main loop recursion level in the current thread" which implies that main loop recursion doesn't create threads
<pygi> cjwatson, it shouldn't
<cjwatson> slomo: 'import gobject; gobject.threads_init(); import pygtk' would be fine though, wouldn't it?
<slomo> cjwatson: no idea
<cjwatson> slomo: actually, pygtk is fine; look at the module, it doesn't import gtik
<cjwatson> gtk
<seb128> cjwatson: do you use gnome-vfs or something that could make use of it like gtk fileselector?
<seb128> because it's multi-threaded
<seb128> cjwatson: I'm not sure that setlocale is really a problem
<pitti> seb128: bug 106350 was handled in an SRU, but the gutsy task is still open; can that be closed?
<ubotu> Launchpad bug 106350 in metacity "Metacity crash corrupts future Gnome sessions" [High,Confirmed]  https://launchpad.net/bugs/106350
<seb128> pitti: closed
<pitti> seb128: likewise for bug 107484
<ubotu> Launchpad bug 107484 in control-center "Launch Music Player should be mapped to KEY_MEDIA (0xed in X)" [Low,Confirmed]  https://launchpad.net/bugs/107484
<pitti> siretart: can bug 104332 be closed in gutsy? (I think so, but I'd like to make sure)
<ubotu> Launchpad bug 104332 in rdesktop "Segmentation Fault (core dumped)" [Undecided,Fix committed]  https://launchpad.net/bugs/104332
<pitti> siretart: it was fixed in an SRU for feisty already
<seb128> pitti: closed as well
<pitti> thanks Seb!
<seb128> you're welcome
<pygi> seb128, you're getting a lot of thanks today :p
<seb128> ;)
<Tonio_> pitti, seb128: http://tonio.homelinux.org/temp
<pygi> seb128, mhm, let me ask you one question, so you can earn one more :)
<Tonio_> pitti: new NM packages, untested, so if you want to check the old applet compatibility..... it's there
<pygi> seb128, how sane is it to patch brasero so we'd update language pack for baltix folks?
<seb128> pygi: what do you mean?
<pygi> seb128, well, baltix folks contacted me that translation to lithuanian (fix my spelling pls!) is a bit broken, and wondered whetever I could introduce a patch in the package
<seb128> Tonio_: no new kio-umountwrapper in the queue
<pygi> jdong, poke
* pygi is out for some time ^_^
<Tonio_> seb128: hu ? pitti removed the old ones yesterday
<seb128> the only one in the queue is 7 days old
<ompaul> orga got a momemnt?
<pitti>   225218 | S- | kio-umountwrapper    | 0.3-0ubuntu1         | seven days
<ompaul> moment even 
<pitti> Tonio_: that's the most recent one
<Tonio_> seb128: okay can you drop that all ? I'll upload the new one after that
<pitti> Tonio_: done
<seb128> no need to drop anything you can just upload
<Tonio_> pitti: maybe my yesterday's upload didn't reach NEW
<Tonio_> seb128: uploaded, should be in NEW
<seb128> Tonio_: no
<pitti> not yet, in 2 minutes
<pitti> (packages are accepted every five minutes)
<Tonio_> oki
<pitti> seb128: xdg-user-dirs binary-NEWed
<seb128> pitti: danke
<seb128> pitti: you will get a MIR for it soon ;)
<shawarma> ompaul: You may have more luck if you also spell "ogra" correctly :)
<ompaul> shawarma: there is that ;-) there is always that 
<ompaul> ogra got a momemnt?
<ompaul> hahaa
* ompaul head desks
* ompaul sends a memo to self to remove multiple typos in one go, it should not be an iterative process  
<cjwatson> seb128: gnome-vfs> no
<seb128> Tonio_: kio-umountwrapper accepted
<cjwatson> pitti: bug 114296 is an interesting point. Does restricted-manager write out a list of the packages it installs anywhere?
<ubotu> Launchpad bug 114296 in ubiquity "running restricted-manager before installation can break system" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114296
<cjwatson> note that ubiquity copies the live session's xorg.conf to the installed system
<pitti> cjwatson: right, I was just going to ask you about that
<pitti> ATM it doesn't write out a list, it has those hardcoded in the per-module handlers
<pitti> cjwatson: if we want to make this work, I could add a small script that prints out that list
<pitti> cjwatson: it's easy to write, it's just hackish and doesn't fit into the main restricted-manager binary
<Tonio_> seb128: super, merci !
<seb128> de rien
<pitti> cjwatson: right, or just put the list of installed packages in some log file if you prefer that
<cjwatson> pitti: maybe something that prints out the list of packages that would need to be installed in order to fit the current configuration (disclaimer: I have never looked at restricted-manager)
<cjwatson> pitti: a log file could be trickier if restricted-manager were run multiple times
<pitti> cjwatson: right, let's call it 'status file'
<pitti> cjwatson: but that's specific to X.org drivers anyway, right?
<pitti> since we don't copy other files, such as installed firmware bits
<cjwatson> no, though we should carry over the list of packages you requested in restricted-manager anyway
<cjwatson> and what we copy now isn't necessarily exactly what we ought to copy ...
<cjwatson> pitti: I've created a bug task on r-m
<pitti> cjwatson: ATM, writing the list of installed packages is identical to list of installed X.org driver packages, but that will change soon
<pitti> an interesting use case is e. g. installing the vmware guest tools into a running live system in vmware
<pitti> (we don't have them yet, but that was the idea)
<pitti> cjwatson: so, that's easy to maintain as well, just a different function in the code
<pitti> cjwatson: something like /var/cache/restricted-manager/installed-packages ?
<pitti> cjwatson: bug updated and milestoned
<cjwatson> pitti: in fact, there's an even neater option
<cjwatson> pitti: restricted-manager could ship a hook script in /usr/lib/ubiquity/target-config/ that just does whatever's necessary
<pitti> cjwatson: indeed
<cjwatson> pitti: it can call 'apt-install <package>' (note: *not* a typo for 'apt-get install') to ensure that <package> remains installed
<cjwatson> or is installed off the CD
<pitti> cjwatson: I like that, avoids special-casing ubiquity for r-m
<cjwatson> yeah, and avoids needing to create another interface
<pitti> cjwatson: files in there are just executables? or are there any other form requirements?
<pitti> cjwatson: i. e. could it be a Python script? 
<cjwatson> pitti: arbitrary executables; you can query the debconf database, but please don't use INPUT or GO; it doesn't check exit code at the moment, but please exit 0 on success obviously
<pitti> right, no need for debconf for me
<cjwatson> oh and since it's connected to debconf please don't output stuff to stdout
<pitti> good point, thanks
<ompaul> 3
<cjwatson> stderr is fine and will end up in syslog
<cjwatson> I'll update the bug
<pitti> (already doing so)
<cjwatson> pitti: go ahead then, please reject the ubiquity task
<pitti> done; I think I noted everything important
<pitti> cjwatson: apt-install is just in $PATH in the context of those scripts?
<cjwatson> pitti: yeah
<cjwatson> it's in /usr/lib/ubiquity/compat but that's an internal detail
<siretart> pitti: oh, you're right. closing it now!
<dholbach> doko: do you have any idea about  http://daniel.holba.ch/temp/glom.ftbfs ?
<pitti> siretart: thanks
<cjwatson> pitti: note that it won't be able to install packages from the network, though
<cjwatson> just stuff on the livefs or on the apt archive on the CD
<StevenK> % grep -c '====' debian/patches/99-update-autoconf.dpatch
<StevenK> 540
* StevenK sobs
<pitti> cjwatson: hm, good point; I just call synaptics ATM
<shawarma> StevenK: Which package?
<pitti> cjwatson: however, it shouldn't matter, I think; you cannot activate e. g. fglrx on the live system for the same reason
<dholbach> StevenK: what's the problem with the patch?
<pitti> cjwatson: I'll look at that
<StevenK> shawarma: cyrus-imapd-2.2
<StevenK> dholbach: It's from a MoM-merge. Evidently, Debian changed it again.
<dholbach> StevenK: if those patches break, it's usually a matter of     rm debian/patches/99-update-autoconf.dpatch; cdbs-edit-patch 99-update-autoconf ... autoconf; rm -r autom4te.cache ... - so not that bad, no?
<StevenK> dholbach: I think this patch actually updates configure.in as well, so it gets a little painful.
<dholbach> hrm
<dholbach> that's why we usually split those patches
<StevenK> Actually, it doesn't. Excellent.
<pitti> mvo!
<pitti> mvo: can you please upload a new compizconfig-settings-manager with Arch: s/any/all/?
<mvo> pitti: *cough* sure
<pitti> mvo: 'k, rejecting the current one then; it's fine otherwise
<pitti> mvo: (so please reuse the version number)
<mvo_> pitti: thanks, new version uploaded
* StevenK glares at dpatch-edit-patch. *Why* are you running debian/rules configure?
<pitti> mvo_: it doesn't, usually that's a horribly broken debian/rules clean
<pitti> I saw packages which need some five minutes to clean just because they think they need to run configure for that
<StevenK> pitti: I'm over here. :-P Yeah, I found it. clean-patched depends on configure for some screwed reason.
<pitti> whoops, sorry :)
<doko> dholbach: not at first sight
<shawarma> Um, how does the new ifrenaming stuff work? I've a machine whose only interface comes up as eth1, but since we don't use /etc/iftab anymore, I'm a bit lost.
<fabbione> shawarma: /etc/udev/rules.d
<fabbione> grap there for the mac address
<fabbione> there are autogenerated rules for that
<shawarma> fabbione: Aw, crap.
<shawarma> fabbione: Thanks, though!
<fabbione> it's funny to see udev fighting with itself when you have 2 interfaces with the same mac address :)
<shawarma> Ok, so now I get how it figures out which interface should have which name. How does it actually do it? ifrename is missing, it seems.
<fabbione> shawarma: apt-get source udev ?
<fabbione> it's probably naturally coded in there rather than using yet another external program
<shawarma> Ok, so if I'm too lazy to reboot, my only hope is to reload the driver and have udev detect it again?
<fabbione> that will do
<fabbione> rmmod modprobe will do
<shawarma> Only problem is that the driver is not a module (it's inside user-mode-linux).
<shawarma> Oh, well.
<shawarma> asac: I'm not getting any video on youtube with the gnash plugin?
<asac> shawarma: does gnash start?
<shawarma> asac: I got sound?
<asac> oh ... happens on any video?
<shawarma> Um... havent' tested all of them :) But all that I've tested, yes.
<asac> you have a link so i can verify that it works here?
<shawarma> For a split second, I see a grey area that seems to have the correct size, but then it disappears.
<shawarma> http://www.youtube.com/watch?v=nYM__s3R5q0
<asac> oh you even don't see a grey area? .. no 'flash' area at all?
<shawarma> asac: No, just white.
<shawarma> asac: It's been a week or so since I did a full upgrade, could that mean anything?
<asac> hmm ... usually not, but i am unsure what latest gtk brought so maybe try
<shawarma> asac: Will do.
<asac> shawarma: do opengl apps otherwise work for you?
<shawarma> asac: glxgears work like a charm
<asac> and mplayer with opengl as well?
<sn0> shawarma there was a new ver of gnash, just incase you aren't aware
<shawarma> asac: Yup.
<sn0> http://www.miriamruiz.es/weblog/?p=68 fyi
<asac> asw: 
<asac> ups
<sn0> it mentions the gstreamer packages required for youtube browsing
<shawarma> sn0: Yes, I believe that's what asac packaged?
<asac> sn0: i think shawarma is testing my upload :)
<sn0> oh my apologies then :-)
<asac> yes my upload superseeds that one
<sn0> thanks for the upload asac 
<asac> i uploaded to debian the same without easy-codec feature
<asac> but i think it will be in NEW until after debconf
<shawarma> asac: Just a sec... which version of the plugin am I supposed to be looking at?
<asac> shawarma: what do you get on console?
<asac> 0.8.0... something
<asac> shawarma: if you didn't install today then ;)
<asac> ...
<shawarma> 0.8.0~cvs20070611.1016-1ubuntu2 ?
<asac> yes
<asac> thats the one
<shawarma> asac: Nothing on the console..
<asac> nothing?
<asac> thats wierd
<asac> you sure that you use gnash in firefox? take a close look at about:plugins
<shawarma> It's gnash alright.
<shawarma> asac: Hm... gimme a sec.
<sn0> must try this new gnash also, would be nice to get rid of adobe 
<asac> sn0: its actually better than i expected
<asac> :)
<shawarma> asac: Uargh..  Just updated gstreamer packages. Now I get huge amounts of alsa stuff.
<sn0> \o>
<asac> shawarma: oh ... maybe thats my bad
<shawarma> asac: Uh!
<shawarma> asac: It works.
<asac> naturally 
<shawarma> asac: :-P
<asac> please try easy-codec as in mail
<asac> :)
<shawarma> asac: Updating gstreamer and rebooting firefox helped.
<sn0> how is the cpu usage with it shawarma / asac ?
<shawarma> asac: Wtf?!??
<shawarma> asac: Um.. Now it's back to adobe? How did that happen?
* Hobbsee waves
<shawarma> asac: Um.. It works now. I must be an idiot.
<shawarma> asac: Is the preference option in the menu supposed to bring anything up?
<xxxxx1> anyone here have experience with ia64?
<xxxxx1> the buildd log of my package on ia64 fails due to -m64 not being recognized.
<asac> shawarma: yes, the menu appears to be not bound to any action (except Quit)
<shawarma> asac: Alright.
<shawarma> asac: Well, it seems to work on youtube now, at least. Break.com seems to not be so grand, though.
<pitti> whoops, shit; I forgot NOMAILS for the autosync run
<pitti> sorry for the bug spam
<pitti> s/bug/-changes/
<StevenK> pitti: Just out of interest, did the autosync pull across Linda?
<pitti> StevenK: just flushed, can't say any more, but you'll see it on -changes
* StevenK nods.
<pitti>   17 N   15.06.07 15:03 Ubuntu Installer  Accepted linda 0.3.25 (source)
<StevenK> Yay
<StevenK> Thanks.
<Hobbsee> hiya pitti 
<Hobbsee> pitti: NOMAILS?
<Hobbsee> who gets mails for it anyway?
<pitti> Hobbsee: to not send mails to -changes for autosyncs
<Hobbsee> ahhh
<seb128> pitti: did you sync purple-plugin-pack on Debian?
<pitti> seb128: yes?
<seb128> k, just weird to have it under dholbach's name when it should be autosynced
<pitti> seb128: he requested the sync in a bug
<pitti> seb128: maybe it was too new for the last autosync run
<seb128> I know about the bug; I've ignored it waiting for the next autosync run ;)
<seb128> I'm wondering if anybody does new package synced while Tollef is not there though
<seb128> s/synced/syncing
<soc> hi
<soc> does someone know where the xserver-xorg-video-avivo driver is?
<mjg59> soc: FTBFS. I'm looking into it.
<Tonio_> pitti, seb128: just a bit of polishing/documentation concerning the patches and nm 0.6.5 should be available
<soc> ah thx
<seb128> rock on
<soc> i would be really really happy to throw this frglrx crap out ...
<soc> is there somewhere a page with server logs to see why the avivo build failed?
<soc> is there already a decision on how avivo will be used among radeon and fglrx?
<pitti> soc: https://launchpad.net/ubuntu/+source/xserver-xorg-video-avivo/0.0.1-0ubuntu2, click on the architecture
<StevenK> Looks like a missing Build-Depends on autotools-dev.
<soc> configure: error: cannot run /bin/bash ./config.sub ...
<soc> mhh
<soc> or maybe a bash/dash incompatibility?
<mjg59> StevenK: config.sub is not a symlink
<soc> mh no, it seems to use bash explicitely ...
<StevenK> mjg59: Actually, the build rm -f config.{guess,sub} and then ./configure tries to execute config.sub
<mjg59> Oh, so it does
<mjg59> How the hell did that build in my chroot?
<Hobbsee> chroot on crack.
<StevenK> That's between you and your chroot. :-P
<mjg59> It was a fresh pbuilder
<Hobbsee> pbuilder on crack, then.
<soc> when can we expect a corrected upload?
<soc> someone on it?
<mjg59> About 5 minutes?
<soc> ok cool
<soc> thx
<soc> how do these build servers work?
<soc> how much time does elapse between upload and build?
<pitti> soc: source needs to get published first, which happens every hour
<soc> ah ok
<pitti> soc: everything that is uploaded until :00 gets published at :35
<soc> so in 35 minutes?
<soc> ah ok
<pitti> no, build will start in ~ 1 hour
<cjwatson> soc: that's when the source gets published, and then at minimum another hour to build and publish the resulting build
<soc> ah ok
<soc> is there a specific reason that it doesn't gt published immediately?
<StevenK> cjwatson: Got a tick for a PM?
<cjwatson> StevenK: sure
<soc> ok thanks to everyone for the information
<mjg59> Ok, uploaded
<mjg59> Should be fine now
<soc> thx mjg59
<soc> is it necessary to update the xserver to 1.3 to install avivo?
<soc> i had to pin 1.3 because the fglrx driver don't work
<soc> s/don't/doesn't
<mjg59> I don't think we use any 1.3 API
* Hobbsee waves to sabdfl 
<mjg59> But it's been built against 1.3, so it's possible
<sabdfl> hey Hobbsee
<Hobbsee> :)
<sabdfl> hi mjg59
<soc> ok thanks
<soc> another question:
<mjg59> Also, if you have an X1650 or later this isn't going to work yet
<mjg59> The init code still doesn't handle them fully
<soc> which driver will be used for ipw3945?
<soc> ok, i have a x1400
<soc> i'll report back
<mjg59> soc: If it's stable enough, iwlwifi
<soc> after i installed avivo
<soc> ok, that sound sgood
<mjg59> Right now it's still about as stable as a drunk one legged man on a ship
<soc> parts of dscape were already introduced in feisty, ewren't they?
<Hobbsee> mjg59: iwlwifi?
<soc> ah ok
<soc> is iwlwifi currently used?
<mjg59> Hobbsee: Yeah
<soc> because my wireless doesn't work anymore :-)
<mjg59> soc: Not sure, I haven't checked yet
<mjg59> Quite possibly
<StevenK> mjg59: During a storm? :-)
<mjg59> Since it's hit mainline
* Hobbsee thought it was some acronym she didnt understand.  nvm
<mjg59> Hobbsee: Oh, sorry - intel wireless lan driver
<mjg59> 3945 and 4965 support
<Hobbsee> oh right.  
<Hobbsee> neat.  a free one, presumalyb?
<mjg59> Yes
<Hobbsee> woo!  :)
<mjg59> ipw3945 needs the non-free daemon and doesn't drive 4965
<soc> without binary userspace regulator ...
<Hobbsee> yep
<mjg59> On the other hand, it works - something that iwlwifi doesn't handle so well
<soc> hope it will be stable, so we can remove the ipw3945 driver
<soc> what about 2200/2100? are there any plans yet?
<soc> e. g. to port them to the new api or is this not a top priority as long as it works?
<mjg59> soc: There's no real reason to port them to the new API
<mjg59> They'll need to be ported to the new config API at some stage, but that's about it
<soc> ah ok
<soc> what about building packages with dh_make?
<soc> is this different?
<soc> sorry, wrong window ...
<lool> Mithrandir: Heya; I see you did some bluez-utils updates; does the org.bluez.serial.Manager DBus interface work for you in newer versions?  Can you list devices with obex:/// in nautilus?
<Hobbsee> lool: he's on leave
<lool> Oh
<lool> Ok, thanks
<dholbach> lool: did you pair your phone with your machine?
<dholbach> lool: did you restart nautilus?
<dholbach> lool: which bluez-utils version do you have?
<lool> dholbach: The phone works with obex://[]  urls
<lool> dholbach: I have bluez-utils 3.11-0ubuntu1
<Tonio_> seb128: http://tonio.homelinux.org/temp
<dholbach> lool: hum, what's the problem?
<Tonio_> seb128: all n-m 0.6.5 is there, a few patches not applied, documented in the changelog
<lool> dholbach: obex:/// is empty and the test case python script for serial devices doesn't work for me
<Tonio_> seb128: I'd like someone to confirm it basically works before uploading ;)
<lool> Looking at the code, I don't understand how it's ever going to really start a subservice, but well
<Tonio_> if someone here wants to help on testing....... I don't have or use gnome so.....
<lool> dholbach: I've read http://blogs.gnome.org/jamesh/2007/06/11/obexftp-changes/ and expected obex:/// to work, but well
<seb128> Tonio_: I'll look in a moment
<dholbach> lool: hrm, best to ask jamesh
* lool reboots for a BIOS upgrade
<Tonio_> seb128: great, thanks
<lool> dholbach: Does it work for you?
<dholbach> lool: yes
<lool> dholbach: I thought it might be some discrepancies between phones
<dholbach> I tried before I uploaded gnome-obex-vfsftp
<dholbach> might be
<lool> The rest of gnome-vfs-obexftp works for me
<jwendell> hi, dholbach 
<dholbach> hi jwendell
<jwendell> dholbach, a doubt: is there any way to get php4 back to feisty?
<jwendell> (i guess no)
<dholbach> jwendell: it's not supported any more and we're happy to not have it in - if we'd get it back people would expect it to be supported in some way
<dholbach> jwendell: but I'm far from being an php expert
<jwendell> dholbach, i'm asking it in order to know what to do with bug 102343
<ubotu> Launchpad bug 102343 in kdemultimedia "mixer cannot be found" [Undecided,Rejected]  https://launchpad.net/bugs/102343
<jwendell> oh
<jwendell> bug 102843
<ubotu> Launchpad bug 102843 in Ubuntu "php4 feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102843
<dholbach> jwendell: best to reject with a friendly reply saying that we don't want to pretend to support it
<jwendell> dholbach, yeah, thanks
<dholbach> thank YOU
<pygi> Zdra: poke
<Zdra> pygi: pong
<pygi> Zdra: got a little time?
<Zdra> pygi: yes
<pygi> Zdra: add (mario dot danic at gmail dot com) and try talking to me
<pygi> jabber protocol
<Zdra> pygi: ok 3sec
<Zdra> pygi: done
<pygi> Zdra: got your request, but since I can't authorize you (just yet), start the talk :)
<jetscreamer> so what kind of questions do i get to ask in here
<jetscreamer> :)
<hunger> jetscreamer: Not stupid stuff like those you just asked... only philosophical questions on the essence of ubuntu are allowed here;-)
<jetscreamer> wasn't stupid, just ignorant
<hunger> jetscreamer: Maybe... I'm not a native speaker.
<jetscreamer> ah
<jetscreamer> so i can complain about how i think something should be done another way, but not ask how to do something, right? :)
<Hobbsee> jetscreamer: you can do both
<Hobbsee> jetscreamer: howeve,r the former will probably be ignored, unless it's sensible, and the relevant devloper happens to be watching
<hunger> jetscreamer: That is basically what I try to do... I usually end up asking how to do something that recently changed though.
<jetscreamer> oh ok. i thought i wasn't supposed to ask how to do 
<jetscreamer> thanks
<hunger> jetscreamer: You aren't.
<hunger> jetscreamer: But people are friendly... 
<Hobbsee> jetscreamer: you arent supposed to ask to ask, you're supposed to ask whatever.
<Hobbsee> but i'ts development of ubuntu, not about ubuntu, and universe stuff goes to #ubuntu-motu, as the topic says.
<Hobbsee> #ubuntu for general support questions, although you probably get away with teh odd one in here.  maybe.
<jetscreamer> i don't have any questions atm, much... just wondering where to ask them. 
<jetscreamer> like ... "wtf is this locales!!!"
<jetscreamer> :)
<Hobbsee> heh
<Hobbsee> which can usually be answered witha  google search, or an apt-cache show <packagename>
<Hobbsee> jetscreamer: usually people will tell you how to find an answer, rather than giving it to you
<Hobbsee> jetscreamer: the whole thinig about giving a man a fish, vs teaching him to fish.
<jetscreamer> Hobbsee: the ubuntu locales package differs from the debian one. i want to remove all locales except for en_us* .  
<jetscreamer> then there's this belocs-locales thing
<jetscreamer> anyway
* Hobbsee knows nothing on locales.
<jetscreamer> me neither
<jetscreamer> no biggie though
<stgraber> Riddell: About miniracer, pitti sent me a mail to have more information about those files as well, they basically are the output of GtkRadiant a level editor (mapping tool as they say), the .pak is the standard archive file for Quake 1 / Quake 2 engine and contains .bsp and some other level information file. You can find a .tar.gz with all the tools and file required to generate them.
<Riddell> stgraber: so the .bsp files are opened and saved by GtkRadiant?
<stgraber> Riddell: A bit different, you can get a .map back from the .bsp, the .bsp is a .map + lighting and rendering settings
<stgraber> Riddell: the .map is also provided in the mapping tools .tar.gz
<stgraber> Riddell: Seems to work the same way with all Quake-based games ...
<Riddell> stgraber: I don't see any .tar.gz in the miniracer sources
<stgraber> they have done a separate one
<stgraber> http://prdownloads.sourceforge.net/miniracer/miniracer-tools-1.0.2.tar.gz?download
<stgraber> "Mapping tools and sources" they say
<Riddell> stgraber: so the .map is the source to the .bsp?
<Riddell> what's the source to the .pak?
<stgraber> Riddell: there aren't any source, it's just an archive containing .wav, .tga and other textures
<stgraber> Riddell: but they should have put a copy of its content in a seperate archive, opening .pak doesn't seem to be easy at all 
<Riddell> stgraber: I'll reject this then, you need to upload it with a new .orig.tar.gz that contains the .maps for the .bsp's and whatever the preferred modifiable form of the .pak is
<cjwatson_> ok, I hope nobody minds, but I'm going to promote celementtree back to main, as bzr needs it again; it was in main in edgy so I assume this is ok
* Hobbsee grabs the pitchforks and flaming torches, and hands them out to the army coming to hunt cjwatson_ 
<stgraber> Riddell: ok, in such a case is it ok to alter the original .tar.gz as taken from their website ? and how should I put the .map and others sources file as there are no command line tool to build them (gtkRadiant is a gui) ?
<Riddell> stgraber: yes, i think you have no choice but to alter the .orig
<Riddell> stgraber: mkdir sources and copy the files in, add a README.Debian file describing which files are needed and where to get them upstream
<Riddell> stgraber: you can also add a rule in debian/rules to do it automatically if possible so it's easier to repear in future
<stgraber> ok, will do that when I have some time
<jwendell> Hi, folks
<jwendell> which software cares about hotkeys on laptops?
<jwendell> i mean, when i press Fn+FX, which program is run?
<mjg59> Ubuntu, Kubuntu or Xubuntu?
<jwendell> ubuntu
<jwendell> seb128, any idea?
<jwendell> i'm asking because bug 104155
<ubotu> Launchpad bug 104155 in linux-source-2.6.20 "[regression]  Fn+F10 (eject) doesn't work on feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104155
<jwendell> which seems not related to kernel
<mjg59> jwendell: gnome-settings-daemon
<jwendell> mjg59, do you have any clue about that bug?
<mjg59> No
<mjg59> But gnome-settings-daemon is the right package
<seb128> not sure
<seb128> depends if it generates the right keycode
<jwendell> seb128, it's generating the right keycode
<jwendell> the eject icon appears on the screen
<seb128> does "eject -T" works?
<jwendell> but it only ejects if there is no media mounted
<jwendell> seb128, yep, it works
<seb128> weird
<seb128> gnome-settings-daemon only call "eject -T"
<seb128> works fine on my desktop
<jwendell> seb128, it worked fine on my desktop too, in edgy
<seb128> it works fine with gutsy here
<seb128> and I doubt this code changed between edgy and feisty
<seb128> jwendell: do you have a /apps/gnome_settings_daemon/eject_command key?
<jwendell> seb128, no!
<seb128> if not it should just call "eject"
<seb128> k, so it calls eject
* jwendell creates
<seb128> no need
<seb128> if it's not set it uses eject
<jwendell> hmmm
<jwendell> eject or eject -T
<jwendell> ?
<seb128> eject
<seb128> looks like the "-T" is a recent gutsy change
<jwendell> seb128, ah, just 'eject' fails
<seb128> k
<seb128> so it's not a bug with gnome-settings-daemon
<seb128> or you can consider it as a bug fixed in gutsy if "eject -T" is working
<jwendell> wendell@wendell-laptop:~$ LANG=C eject
<jwendell> umount: /media/Ubuntu 7.04 i386 is not in the fstab (and you are not root)
<jwendell> eject: unmount of `/media/Ubuntu 7.04 i386' failed
<afflux> can someone check if bug 119968 is a bug or a feature?
<ubotu> Launchpad bug 119968 in quodlibet-plugins "Notify plugin stacks up balloons if you press forward repeatedly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119968
<jwendell> seb128, ok, i'll close the bug
<jwendell> (i'm the reporter :))
<seb128> afflux: I would say none of those
<seb128> it's not really a bug, it displays the different events
<seb128> and it's not a feature
<seb128> there was a similar bug on rhythmbox
<seb128> might a wishlist for notification-daemon
<jwendell> seb128, thanks for point out "
<jwendell> !
<seb128> you're welcome
<afflux> seb128: okay. could you change it to affect only the notification-daemon and set it to wishlist? I can't ;)
<seb128> afflux: I've marked it duplicate of bug #108702
<ubotu> Launchpad bug 108702 in notification-daemon "multiple notification bubbles overlap" [Wishlist,Confirmed]  https://launchpad.net/bugs/108702
<afflux> oh, didn't see that one. thank you.
<seb128> you're welcome
<wereHamster> what is the reason to not add /usr/local/li to the default search path?
<wereHamster> it causes major PITA for users who try to compile/install software from sources and follow the usual './configure && make && sudo make install' guide
<Treenaks> wereHamster: /usr/local/li ?
<wereHamster> it would make sense if build-essential added that path to /etc/ld.so.conf
<Treenaks> wereHamster: ah lib.
<wereHamster> /usr/local/lib, please use common sense :(
<wereHamster> I'm a bit upset, so excuse me if I'm ruse :-/
<wereHamster> rude
<Treenaks> wereHamster: well, I know programs that install in /usr/local/{program name}
<Treenaks> wereHamster: and I can imagine some program called 'li'
<Treenaks> but anyway, I have no idea, sorry
<wereHamster> almost all packages have default prefix /usr/local, which means libraries usually get installed into /usr/local/lib
<cjwatson> I think what happened is that it got removed eons ago in response to a bug that happened due to /usr/local/lib not existing at all (http://lists.debian.org/debian-devel/1997/03/msg00559.html)
<cjwatson> and then subsequent glibc maintainers found the entry in the changelog saying that it was removed but with no explanation, and were thus reluctant to add it back
<cjwatson> (AFAICT from the mailing list history, anyway)
<cjwatson> we should probably bring it up again with Debian
<cjwatson> see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395177
<ubotu> Debian bug 395177 in libc6 "libc6: default library search path is inconsistent with gcc" [Normal,Open]  
<cjwatson> I don't think I'd want to do this just in Ubuntu, though - it would be quite a fundamental change that could easily cause surprise
<cjwatson> BTW, build-essential would be a most inappropriate place for this to be done, given that that package purely exists for informational purposes
<alex-weej> how do i patch an ubuntu package?
<cjwatson> alex-weej: https://wiki.ubuntu.com/MOTU/School/PatchingSources
<wereHamster> cjwatson, having /usr/local/lib there by default works on gentoo
<alex-weej> cjwatson: thanks
<wereHamster> bug 120608
<ubotu> Launchpad bug 120608 in Ubuntu "Add /usr/local/lib to ld search path" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120608
<wereHamster> .. now at least we have a bug to track that 'issue' :)
<jwendell> wereHamster, sorry, but isn't enough to add that dir to /etc/ld.so.conf ?
<wereHamster> it is, but systems usually have it already there
<pygi> hello folks
<wereHamster> ubuntu just makes it harder for users to compile packages from sources, but that's sometimes necessary
<pygi> wereHamster, it's easy
<pygi> wereHamster, given you know what you're doing
<pygi> I compile stuff all the time
<bryyce> I would like to work on updating the ati fglrx binary driver in restricted modules, however I haven't done packaging for binary drivers yet, nor run across docs on it, so am a little unsure about the procedure.  If anyone has pointers or tips, I'd appreciate it.
<mjg59> bryyce: Just take a look at how l-r-m works
<mjg59> Check it out of kernel.ubuntu.com
<bryyce> hmm, I don't see linux-restricted-modules listed there
<bryyce> would it be ubuntu/ubuntu-gutsy-lrm.git maybe?
<wereHamster> pygi, you know, I don't doubt that, but here it's not about me or you or any of the other developer, it's about making it easy for users that don't know their system that well
<pygi> wereHamster, those should not compile then :)
<pygi> as compiling brings some problems
<pygi> when you don't know what you're doing
<wereHamster> should not compile? make a ubuntu package out of my project then ;)
<jwendell> wereHamster, if you are a developer and wants to make your customer's life easier, just build a package for them
<wereHamster> I don't have ubuntu, and no intention installing tons of different distros only to make packages
<pygi> wereHamster, what software do you want to see packaged?
<wereHamster> seom and yukon, both have a bug requesting to be packaged
<wereHamster> btw, the search in launchpad is broken, there's a bug with the title '/usr/local/lib is not properly supported' and yet searching '/usr/local/lib' won't list that bug
<pochu> wereHamster: in which language are they written?
<pochu> wereHamster: file a bug ;)
<wereHamster> C and a tiny little bit in assembler
<pygi> wereHamster, gimme bug numbers pls
<SoftIce> hello is this the right channel to query a status on a faulty package?
<pygi> (if it's something interesting, perhaps you might even get the packages)
<SoftIce> seg faulting..
<pygi> SoftIce, what's broken? :)
<pygi> which package?
<SoftIce> util-vserver in feisty, i can grab the package from debian etch and it works perfectly if i install it manually.
<SoftIce> all versions down work but not the version in feisty.
<SoftIce> very broken, right down to not even detecting capabilities in the kernel.
<pygi> wereHamster, so bugs? :)
<pygi> SoftIce, not familiar with that package, sorry
<SoftIce> is it possible to find out who maintains that package so i can let them know? or wont it get fixed untill the release of gusty ?
<pygi> I can get it for you
<pygi> sec
<wereHamster> pygi, one second.. creating other bugs
<pygi> SoftIce, meh, nobody actually touched that package. It was auto-synced from debian
<SoftIce> strange, what version does it get synced from
<pochu> pygi: bug 117236
<ubotu> Launchpad bug 117236 in Ubuntu "[needs-packaging]  seom" [Wishlist,Confirmed]  https://launchpad.net/bugs/117236
<SoftIce> etch ?
<pygi> SoftIce, unstable
<pochu> (I was looking at it :)
<SoftIce> unstable, hrm, unstable uses the same version as etch so strange it wasn't pulled from a stable release
<pygi> pochu, what's that seom about? :)
<SoftIce> wonder how they broke the package in debian unstable as its the same version as eth
<pochu> pygi: a library for yukon :p
<pygi> pochu, do we have list of deps?
<pochu> and yukon is a library which uses seom :p
* pochu hides
<pochu> pygi: I don't think so...
<pygi> meh, bad then :P
<wereHamster> pygi, yukon doesn't have a bug, seom: 117236
<SoftIce> i really hope we get a vserver kernel in gusty 
<xtknight> GUTsy!
<xtknight> :)
<SoftIce> oh :)
<SoftIce> why not call it sharka zulu
<pygi> wereHamster, won't do, no time to track deps right now =)
<wereHamster> 'track deps'?
<pygi> btw. building a package != ./configure ; make ; sudo make install
<wereHamster> I know, I wanted to say that the package doesn't require any magic or such, it's a simple library
<wereHamster> no extra post-install rules etc
<wasabi> Is there any udev mechanism to serialize script execution, or do I need to implement my own lock?
<wasabi> Actually... maybe this belongs in watershed.
<pygi> wereHamster, track deps = get what it uses, get all the -dev packages for that, etc, etc
<SoftIce> i've had to disable udev to illiminate millions of vm-liniar or should I say device-mapper errors
<SoftIce> it doesn't like something to do with my patches, i have to look at the diff and see if there isn't some errors with it
<wereHamster> pygi, make, gcc, yasm>=0.5, libdl.so, libpthread.so, libX11.so, libGL.so, install, rm, uname, libXv.so
<pygi> that isn't list of deps :P
<pygi> but meh
<pygi> nevermind
<wereHamster> That's all I can tell you, I'm not running ubuntu nor do I know how ubuntu packages work
<pygi> ok
<Kmos> asac: any news about thunderbird v2.0.0.4 for feisty ? as security update
<Kmos> http://www.mozilla.org/projects/security/known-vulnerabilities.html#thunderbird2.0.0.4
<Kmos> ups, for gutsy, feisty has 1.5
<keescook> Kmos: waiting on asac for an upload, should be soon.
<Kmos> keescook: nice
<dmb> is there a new maintainers guide for ubuntu?
<dmb> for a package?
<dmb> or does one usually get it submitted to debian-unstable first and then it floats here?
<evand> dmb: take a look at the MOTU documentation on the wiki (https://wiki.ubuntu.com/MOTU/Contributing) and seek assistance in #ubuntu-motu.
<Riddell> please test new network manager  deb http://tonio.homelinux.org/repo/ gutsy main
<giskard> what's new?
<Mithrandir> lool: yes, it works for devices I have paired with already.  Not others.
<darwin81> Is it planned to include GNASH by default in Gutsy and include official flash as an option?
<geser> darwin81: what I've heard is that you need the last snapshots to play some flash files
<Bassetts> hi, can someone help me out with the hotkey-setup .hk config files?
<darwin81> geser : Gnash 0.8.0, the latest official release, is good enough to play YouTube videos and I think that would be enough for a lot of people. Plus it's not just a philosophical Free Software problem, the official Flash is causing Firefox to crash a lot.
<beuno> geser: it's in debian's NEW queue right now
<Bassetts> i need to add another key to the lenovo.hk file, can anyone help?
<Bassetts> can someone help me out with hotkey-setup
#ubuntu-devel 2007-06-16
<wasabi> man everytime i upgrade gnome-power-manager leaves teh systray and opens it's own window thing... cuz the gnome-panel recycles
<wasabi> with seemingly no way to put it back
<wasabi> oh, seems like killing and starting it again solves that. Wonder if there's an appropiate way for it to do that on it's own.
<wasabi> Along similar lines. I wonder what a good policy for that stuff is. Should bugs be filed if applications break while upgraded wen running?
<alex-weej_> are there any moderately featured vanilla kernel distributions? i need to test a few sound driver bugs
<alex-weej_> wasabi: isn't that an EggTrayIcon bug?
<wasabi> Got me, most other apps seem to handle it find now.
<alex-weej_> I know that Gossip used to do it at least
<wasabi> d
<crimsun> alex-weej_: you have a card driven by snd-ice17*, correct?
<alex-weej_> crimsun: yes, that's me
<crimsun> alex-weej_: with static?
<crimsun> or other audio artifacts?
<alex-weej_> well, sounds like static
<crimsun> using dmix?
<alex-weej_> yes
<crimsun> feisty or gutsy?
<alex-weej_> feisty, haven't dared test gutsy outside of VM yet
<crimsun> are you using an asoundrc?
<alex-weej_> not a custom one
<alex-weej_> er
<alex-weej_> actually
<alex-weej_> i suppose i am, i use asoundconf --set-default-card
<alex-weej_> but even if i use the "hw:0,0" pcm directly, it happens
<crimsun> edit ~/.asoundrc.asoundconf, scroll down to defaults.pcm.dmix.format, and change S16_LE to S32_LE
<alex-weej_> e.g. aplay -d hw:0,0
<pygi> around' people supposed to be sleeping :P
<pygi> arent*
<alex-weej_> crimsun: it's actually S16 atm, not S16_LE
<alex-weej_> also the card output is 24 bit...
<alex-weej_> still want me to change it to S32_LE?
<cjwatson> alex-weej_: gutsy is pretty nearly vanilla kernel ...
<cjwatson> (aside from additional modules)
<alex-weej_> cjwatson: it's not good enough for kernel devs
<crimsun> alex-weej_: yes
<cjwatson> alex-weej_: well, this is what Ben tells me
<cjwatson> feisty was a bit less vanilla
<alex-weej_> crimsun: ok let me try this now
<crimsun> also, be sure to disable any sort of pci timing optimisation junk in bios
<alex-weej_> crimsun: i have absolutely no idea
<alex-weej_> crimsun: i'm playing back some stuff now with "aplay", unfortunately the whole issue is very temperamental so i'll just have to keep my ears open
<crimsun> if with dmix it's still reproducible (that is, with that asoundrc fix and `aplay /usr/share/sounds/*up.wav`), then see the position_fix parameter to snd-hda-intel.
<alex-weej_> see the what what?
<crimsun> likely you'll need either position_fix=2 or position_fix=3
<crimsun> alex-weej_: modinfo snd-hda-intel|grep ^parm
<crimsun> err, sorry, wrong issue
<crimsun> about position_fix, that is
<alex-weej_> ok
<crimsun> sorry, I'm debugging a similar issue in another IRC channel and got fumble fingers
<alex-weej_> crimsun: tbh i don't even know how this is playing - the card doesn't support 32 bit sample formats
<crimsun> the upper 8 bits are not relevant
<crimsun> it's really 24, but you need S32_LE for ice17xx
<alex-weej_> hm, you know what i really can't tell if it's fixing the problem
<alex-weej_> i'm trying "hw:1,0"
<crimsun> hw:0 I'm not concerned about; plughw:0 and plug:dmix I am
<alex-weej_> (the card is hw:1, btw)
<crimsun> anyhow, to cut the clutter here, please report in said bug report, and I'll take a look tonight when I get into the hotel
<crimsun> (substitute the card index as appropriate, of course)
<alex-weej_> crimsun: well ok thanks but i can't promise i'll have anything to report - it's just not happening atm
<alex-weej_> sometimes it'll happen for like 10 minutes
<alex-weej_> gutsy goes fing mental when i reboot it in virtualbox :E
<alex-weej_> what's with the 11pt default font size these days as well? Windows users think we're short-sighted enough as it is for settling on 10pt before...
<luisbg> Is intel doing such a great supporting drivers for linux work to be the first in the linux friendly hardware vendors list?
<luisbg> I think it's awesome their integrated cards are very well supported =)
<luisbg> that wiki page is going to help people choose their next machines, and that will force vendors to be more free-friendly
<luisbg> are the intel drivers GPL?
<alex-weej_> crimsun: ping
<Toxicity999> Unfortunately so far intel isn't a huge graphics contender yet. But it works nicely for lihht 3D, the newer setups can be good though.
<Toxicity999> I wonder how large that list will grow.
<luisbg> Toxicity999, yeah... having only gpl drivers is very strict but good
<luisbg> Toxicity999, it even looks like intel drivers aren't all gpl, http://www.intellinuxgraphics.org/license.html, only the agp drm modules, the rest is mit
<mjg59> luisbg: MIT is even more liberal than GPL. You can incorporate MIT stuff into GPL code.
<luisbg> mjg59, :S oops, sorry for that 
* luisbg goes to read the MIT license, even more liberal? can't picture it
<mjg59> You can incorporate MIT stuff into closed-source products
<mjg59> It's basically a "Do anything you want with this code" license
<spider> a program to lower music please??
<spider> because I have the limewire but I don't found my music :-D
<luisbg> mjg59, so it's even free in merging, that's awesome
<luisbg> intel graphics for the win! (I'm so tempted in buying a macbook right now LOL)
<luisbg> spider, lower?
<wasabi> Too bad half of the other stuff on the MacBook doesn't work.
<bhale> if you try really hard you can trick dell into selling you a d620 with all intel gear
<alex-weej_> fgs, i have a single python script that i want to package up into a .deb and it's ridiculously complicated :(
<spider> luisbg yes or down 
<luisbg> wasabi, like what?
<luisbg> spider, have you tried nicotine?
<alex-weej_> what's the difference between MIT and BSD?
<wasabi> power management is pretty screwed.
<wasabi> Sound too I think
<spider> no luisbg 
<luisbg> wasabi, hmmmm suspend works, but yeah.. battery lasts half as in the other OS
<luisbg> spider, you should
<spider> I go to see luisbg 
<spider> thanks 
<spider> :-)
<wasabi> Suspend works today, but might not tomorrow. That's my experience.
<luisbg> spider, it uses the soulseek network, great for music
<alex-weej_> oh that reminds me
<luisbg> wasabi, how can that be? if there is support now it won't change
<wasabi> Heh. My suspend in my laptop worked, about 4 months ago.
<wasabi> Never since.
<luisbg> wasabi, backport problem in the kernel?
<wasabi> Now it wakes up immediatly after sleep with screen corruption.
<wasabi> Same experience on my ibook. For a whole week it worked, about a year ago.
<spider> soulseek I never heard about it luisbg
<luisbg> spider, all the people of audiogalaxy went to that server
<luisbg> wasabi, and it just stopped working, without changing anything in you software?
<wasabi> No way. I upgrade every 30 minutes.
<spider> ok luisbg
<luisbg> wasabi, then it's a backport issue and... 30 minutes!? that's insane
<spider> do you use ubuntu luisbg ???
<wasabi> whenever update-manager tells me to. ;)
<luisbg> spider, why would I be in devel if I didn't
<luisbg> spider, that's a yes :P
<alex-weej_> anyone know what the source package is called for linux kernel?
<luisbg> wasabi, LOL
<luisbg> alex-weej_, isn't it the same but with apt-get source?
<wasabi> linux-source? :)
<alex-weej_> luisbg: linux-meta?
<alex-weej_> E: Unable to find a source package for linux-image
<alex-weej_> linux-meta seems to have... nothing...
<wasabi> meta packages don't exist.
<wasabi> They are provided by other packages.
<spider> where are you from luisbg ??? :-D
<alex-weej_> so how do i find the changelog for 2.6.20-11?
<alex-weej_> because it fixed a shutdown bug which i'm convinced is related to my suspend bug
<wasabi> The Ubuntu change log?
<luisbg> spider, from Spain (from canary islands but I live in madrid now)
<alex-weej_> wasabi: yes
<wasabi> apt-get source linux-image-whatever
<alex-weej_> E: Unable to find a source package for linux-image-i386
<spider> ok, I'm from mxico luisbg  :-D 
<luisbg> alex-weej_, check in packages.ubuntu.com
<luisbg> alex-weej_, I think you can get the changelog there, if not... search for the package in launchpad
<luisbg> spider, ahhhh... you see, I'm saying stupid stuff because here it's 4:25 am
<alex-weej_> does anyone here have a clue about what goes on with kernel development? because there was this bug that made some Asus motherboards reboot instead of shutting down about 3/4 months ago
<spider> :-S
<alex-weej_> the response on launchpad was basically 
<alex-weej_> wait till new upstream version - is it fixed yet?
<luisbg> no new posts in the bug report at launchpad?
<alex-weej_> as such nobody seems to have a clue what fixed it, and my suspend problem (which is suspiciously similar) doesn't get fixed
<luisbg> alex-weej_, ask in the bug report... it will get to the correct mailing boxes
<spider> It is very late luisbg  
<luisbg> and they should at least read the subject of the mail 
<luisbg> spider, for you it isn't 
<alex-weej_> luisbg: tried a lot a long time ago, i figure it's obscure enough for no-one to care
<spider> no luisbg here it is 9:00 of the night
<spider> :-)
<luisbg> alex-weej_, that sucks, I'm sorry
* luisbg wants the laptop hardware support issues to be gone for good
<alex-weej_> desktop here
<luisbg> it's very hard to find a decent laptop with all supported nowadays
<luisbg> alex-weej_, ahhh sorry
<alex-weej_> i just wish ubuntu would bless a set of hardware sometimes
<alex-weej_> and actually have a hw testing routine
<spider> it's early luisbg
<alex-weej_> because every couple of kernel releases it's a new problem - sound issues, SATA, IRQs, video, shutdown, suspend
<alex-weej_> gutsy doesn't even boot if i have my floppy disk BIOS enabled right now
<alex-weej_> i wish i could just throw this PC in the trash and buy something that i knew would be well supported
<alex-weej_> i guess this is why Apple do what they do...
<luisbg> alex-weej_, well... the ubuntu kernel developers don't have every piece of hardware in the market available in their offices to test
<alex-weej_> luisbg: i know, i don't expect that at all
<luisbg> apple has the benefit of building the hardware they have to build drivers for, makes it easy, makes it work very well
<luisbg> but limits the consumers to just a few options
<alex-weej_> luisbg: what would be nice, though, is for a list of supported hardware to begin to form
<alex-weej_> with a proper community-involved testing routine
<luisbg> alex-weej_, there are a few things, but I do agree it is limited
<luisbg> you have to understand ubuntu depends on the users on this but...
<luisbg> check this out for example
<alex-weej_> yeah but 99% of real world people aren't interested, they want the 1% remaining to do the testing for them - i don't see why that can't work
<luisbg> https://wiki.ubuntu.com/LaptopTestingTeam
<luisbg> cannonical has baught a bunch of laptops for people to test
<luisbg> which is something I haven't seen any other distro do
<alex-weej_> and do proposed updates filter through this testing team before they are released?
<luisbg> that's spending thousands of dollars, we can't expect more
<alex-weej_> let me just set the record straight - i don't "expect", i just wish we had a nicer situation :)
<alex-weej_> it would be nice if people could volunteer to be part of testing routines
<luisbg> alex-weej_, lead by example and add any information you have about your hardware in
<luisbg> https://wiki.ubuntu.com/HardwareSupport?highlight=%28hardware%29
<luisbg> alex-weej_, I would volunteer happily, but I don't have the money to buy hardware to test
<alex-weej_> but the important thing is that the updates need to be put on hold until the testing routines come back clean
<luisbg> I'm buying a laptop soon, I will report all my founding on it
<alex-weej_> luisbg: that's great as a one-off
<luisbg> this remembers me a conversation I was in a few years back, a few guys in a convention asking a gnome hacker
<luisbg> to get support for bluetooth devices in his system manager
<luisbg> the gnome hacker didn't even had a cellphone, he was unemployed at the moment
<luisbg> anyway...
<luisbg> I'm gonna go read a book to get a sleepy and sleep
<alex-weej_> gnight
<luisbg> alex-weej_, talk to you an other time =)
<alex-weej_> laters ;)
<dmb> whats the best way to get a folder in /usr/lib to be in the library search path when creating a package?
* StevenK sighs. fig2png SEGV'd on floe.
<macogw> can I add Intel to the "wifi" column on the free-driver-vendors table?
<macogw> since their drivers are open and included in ubuntu and just the firmware is closed
<macogw> broadcom would fit that too, for that matter
<macogw> well, except that the broadcom firmware isnt installed by default like intel's is
<brylie> hello, can anybody point me to an article related to creating a metapackage for the apt repository so that the devs of a project can change the name of the .deb and allow anyone with the old version installed to migrate to the new naming standard?
<brylie> specifically, the current naming standard is python2.x-exe_x.xx.x.deb and the new name would [hopefully]  be exe_x.xx.x.deb
<macogw> brylie: ive never done it before, but from what i've heard, a metapackage just involves having a text file listing what's required, make it into an archive, and then rename to .deb
<brylie> interesting
<brylie> is there a specific format?
<Burgundavia> brylie: look at the seeds for the ubuntu-meta package
<brylie> ok.. seeds.. like, google 'ubuntu-meta package
<brylie> '?
<Burgundavia> brylie: crimsun is dishing out good advice, listen to it
<macogw> brylie: i think s/he wants you to get the ubuntu-desktop source package and unzip/untar it to see what's in there...maybe?
<brylie> ok
* Hobbsee waves
<Burgundavia> hey Hobbsee
<Hobbsee> heya Burgundavia, how's it going?
<Hobbsee> i presume bdmurray went to bed?
<Hobbsee> or is otherwise Not Here?
<Burgundavia> I have no idea
<Burgundavia> I don't sleep or otherwise live near bdmurray
<Burgundavia> sleep with, rather
<Hobbsee> ...
<Burgundavia> heh
<Burgundavia> :D
<Hobbsee> those were two separate statements...
<Burgundavia> they looked like one to me :)
<Hobbsee> :P
<Hobbsee> no, i try not to randomly accuse developers of sleeping with each other
<Hobbsee> it's usually a Bad Thing.
<Burgundavia> the accusing or the sleeping?
<Burgundavia> because while the former is generally a bad thing, the latter is usually enjoyable :)_
<Burgundavia> Hobbsee: gee, that made you quiet
<Hobbsee> Burgundavia: was afk :P
<Hobbsee> heh, either.
<Hobbsee> mum came home.
<Hobbsee> Burgundavia: i did mean the accusing being bad.
<ompaul> ogra, you with us today?
<Kmos> keescook: bug 40112
<ubotu> Launchpad bug 40112 in linux-source-2.6.15 "wakeup failed with Dapper Flight 6 live CD" [Medium,Needs info]  https://launchpad.net/bugs/40112
* Treenaks feels dirty, after poking at the EEPROM of his ipw2200
<Treenaks> (it did work though, I can now connect to my AP on channel 12)
<Treenaks> Lure: hi
<Treenaks> Lure: have you seen the recent DRI/Ati work?
<Lure> Treenaks: R5xx stuff?
<Treenaks> Lure: that, but also the kernel modesetting stuff
<Treenaks> Lure: which might finally fix "my" bug
<Lure> Treenaks: no, but latest -ati package works for me (detect display properly)
<Treenaks> Lure: yeah, you're lucky, I have bug 20283 ;)
<ubotu> Launchpad bug 20283 in xserver-xorg-video-ati "[X700]  Really bad sync on HP NW8240" [Medium,Confirmed]  https://launchpad.net/bugs/20283
<sn00p-> does anybody know why ubuntu 7.04 hangs at startup ? I read some forums about turning noapic off and it gets past the splash but after that it just freeze I have a 8800 gtx geforce video card would that may be a problem?
<Lure> Treenaks: the one from here https://wiki.ubuntu.com/XorgOnTheEdge
<Lure> Treenaks: yeh, I know you are still stuck with that one :-(
<Treenaks> Lure: ooh! l33t x0rgness
* Treenaks reads
<afflux> the source package swfdec0.4 had a ftbfs due to a dependency problem on 2007-05-03, which seems fixed now (at least it works in my pbuilder). Can someone restart the build-process?
<Kmos> uuid generate is part of the kernel ?
<Kmos> !info uuid
<ubotu> uuid: OSSP uuid. In component universe, is optional. Version 1.5.1-1ubuntu1 (feisty), package size 12 kB, installed size 68 kB
<Hobbsee> afflux: probably need to ask on monday
<Hobbsee> since i dont think pitti and such are here
<afflux> okay. Should I just file a bug and subscribe ubuntu-archive?
<Hobbsee> nah
* Hobbsee adds it to her todo list
<afflux> I mean, a bug is already filed by someone else...
<afflux> bug 120673
<ubotu> Launchpad bug 120673 in swfdec0.4 "[FTBFS] unmet build-deps: libxul-dev" [Undecided,Confirmed]  https://launchpad.net/bugs/120673
<Hobbsee> afflux: ah, that's fine.  will ask for a giveb ack when i see the relevant people around
<afflux> thank you
<cjwatson> macogw: I don't think Broadcom would be a reasonable addition at all. They've refused to cooperate with us (e.g. give us permission to redistribute the firmware that's freely downloadable from other sites), and the driver only exists because some people got fed up and reverse-engineered it.
<Hobbsee> cjwatson: could you be persuaded to do a couple of givebacks, then?
<cjwatson> Hobbsee: persuading me won't help because I don't have access to do so
<Hobbsee> cjwatson: oh, sorry, i thought you did.
* cjwatson is not in launchpad-buildd-admins
<Hobbsee> apologies
<Hobbsee> i keep thinking it's a standard archive-y type thing.
<cjwatson> nope
<geser> Hobbsee: pitti and doko were recently added as buildd admins
<Hobbsee> yes, but pitti's not here.
<Hobbsee> and i dont think doko is either
<pochu> Mithrandir seems to be.
<geser> afaik is he on holidays
<Hobbsee> he's on leave
<pochu> Ah, ok.
<geser> Hobbsee: do you know how long?
<Hobbsee> geser: he should be back at the end of next week.  it was two weeks from sunday
<Hobbsee> well, 2 weeks from last weekend
<Mithrandir> I'm going to be at debconf from tomorrow on, I'm not really here now.
<Hobbsee> ahh, he is alive!
<pbn> hi there, finally fixed kppp problem, bug 36655 was right, I had to uncomment noauth in /etc/ppp/peers/kppp-options
<ubotu> Launchpad bug 36655 in kdenetwork "pppd dies on connection" [High,Confirmed]  https://launchpad.net/bugs/36655
<Fjodor> I seem to be hitting Bug #96566 in feisty. Furthermore, I cannot administer the group "mail" with users-admin to add users to it. Would it be safe to chgrp it to users?
<ubotu> Launchpad bug 96566 in mozilla-thunderbird "movemail account does not work with default /var/mail permissions" [High,Confirmed]  https://launchpad.net/bugs/96566
<Hobbsee> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<Fjodor> Hobbsee: Right (again). Just trying my luck anyways. And since it was sort of bug related, I tried here first. However, thanks again for the notice
<Hobbsee> no problem - just a note for both fo you
<Fjodor> But would you care to give a "shot-from-the-hip, no-resposibility" opinion as to whether /var/mail might be chgrp'ed to users?
<Fjodor> ...since you seem to often know a lot of other stuff ;-)
<Hobbsee> i have no idea.
<Fjodor> Hobbsee: Fair enough. Thanks anyway.
* bhale pokes Hobbsee 
<persia> Fjodor: changing it is a security risk.  I'm not familiar with movemail, but /var/mail is intended to be restricted to reduce the chance that users have any access to any information about mail for other users.
* Hobbsee pokes bhale 
<Fjodor> Oh, well, I guess I can always chgrp it back again later. Also, it's a personal machine, so I the only regular user, and the others are trusted...
<Fjodor> persia: Ok, thanks for that. But as I just said, almost only user and stuff...
<Fjodor> Afterall, the mail files in the dir are 660, grp mail, so I guess it would actually be better to chgrp the dir to users, and keep users out of the mail group
* Hobbsee ponders whether what she's about to post will violate the COC.
<mjg59> Hobbsee: If you have to ponder, then maybe it will :p
<Hobbsee> mjg59: well, it doesnt say "you are a fucking moron".  that's a start.
<pygi> Hobbsee, just do it
<Hobbsee> http://rafb.net/p/3LkKkL41.html is the proposed response.
<pygi> meh, shirish again
<Hobbsee> mjg59: okay, more to the point, i think it does violate it - the question is how badly, and whether i can actually tone it down
<Hobbsee> pygi: exactly.
<mjg59> Hobbsee: I think the best thing to do would either be not to answer or to provide a purely technical response
* Hobbsee already gave him an in-channel blasting...but this takes the cake...
<pygi> Hobbsee, he's arguing me now why we at libburnia don't like trac & mailing lists, and why don't we use it all the time
<Hobbsee> mjg59: it was all good until i got to 
<Hobbsee> >  Lemme mention that Ms. Sarah Hobbes had been very helpful in her own
<Hobbsee> > capacity to help me & did the update but some things are still
<Hobbsee> > missing.
<pygi> Hobbsee, he can't neither read or write proper english I think
<mjg59> Hobbsee: I think that's either a language or cultural misunderstanding rather than a desire to be patronising
<bhale> Hobbsee: Miss :)
<Hobbsee> no, sorry, your incapability to undesrtand what's being said to you, when others in the channel can is not my problem, nor can you say that i'm an idiot.
<pygi> Hobbsee, where did he write those stuff?
<Hobbsee> pygi: -devel-discuss and -bugsquad
<pygi> damn!
<pygi> Hobbsee, I understand you :-/
* Hobbsee says "what the hell" and hits send.
<Hobbsee> i dont think it's *that* bad a violation.
<pygi> agreed
<pygi> plus you have a point
<pygi> if you need a hand there, do poke
<Hobbsee> because if he keeps this up, i *will* end up calling him a fucking moron, in a public place, and he will not be happy.
<Hobbsee> okay, more public than this.
<pygi> Hobbsee, isn't -devel-discuss list only for people who are approved to post there? Or is it -devel that's like that now?
<Hobbsee> pygi: devel-discuss is moderated somewhat, but -devel is the main moderated one
<pygi> Hobbsee, got it
<Hobbsee> mjg59: i resisted the urge to make a comment about the indians, as that would be a COC violation, and racist.  i think what ended up there isnt too bad, myself :P
<pygi> Hobbsee, I know people from india who can speak clear english, and are pretty good developers, and persons
<pygi> so that wouldn't work
<Hobbsee> pygi: my problem with them is that they tend to think "OMG, IT'S A GIRL.  how much can i hit on her?"
<pygi> perhaps ... but still a stereotype
<Hobbsee> true that
<mjg59> I think is is probably starting to verge on the inappropriate
<Hobbsee> actually, i have some cool indian friends.
<Hobbsee> so it is unfair of me to say
<ion_> How big has the sample been this statistic is based on?
<pygi> ion_, yay, haven't seen you in ages :)
<Hobbsee> ion_: not big enough.  people generally on irc.  i'll freely admit to that
<ion_> Hi pygi
<mjg59> Perhaps I should make my hints less subtle :)
<pygi> mjg59, ^_^
<Hobbsee> mjg59: point taken.  i'll cool off in a bit though
<pygi> good, good
<pygi>  ion_ how you've been?
<ion_> pygi: Well, okay-ish. :-)
<ion_> pygi: How are you?
<pygi> ion_, seriously tired :P
<pygi> had 5 exams this week :(
<ion_> Ouch
<pygi> indeed :P
<pygi> appear sometimes on "you know what channel" :)
<pygi> you're never there anymore
<ion_> Im on too many channels. :-)
<pygi> you told me that already :p
* elkbuntu hugs Hobbsee
* Hobbsee hugs elkbuntu 
<elkbuntu> i figured you might need it ;)
<Hobbsee> hehe, yeah.
<Hobbsee> that and a stiff drink, maybe.
<soc> hi
<soc> i just saw that xserver-xorg-video-avivo came in
<soc> changed the line from fglrx to avivo
<soc> didn't work
<soc> (EE) No devices detected
<soc> to who should i report back?
<ogra> launchpad
<soc> it says it supports RV515, RV530, R580
<soc> i have a RV515
<mc44> soc: did you read the announcment? it is for developers only
<soc> maybe there is just the pci-id missing
<soc> the mobile gpus are sometimes called M52/M54, but they are in fact RV515
<soc> uh nice ... my noteook startet beeping when i did sudo gdm
<soc> cold reboot
<pygi> Hobbsee, you've got shirish again :)
<Hobbsee> pygi: hm?
<Hobbsee> pygi: whta, the new documentatoin?
<Hobbsee> pygi: i twitched, and left it alone.
<pygi> -devel-discuss and -doc
<pygi> hehe
* Hobbsee isnt on -doc
* Hobbsee will wait for the doc team to shoot down that one.
<Hobbsee> pygi: ignoring may well be the best strategy in the long run.  with the odd potshot to say "you're really not helping, youv'e been told the ways you can, but arent really going in the right way"
<pygi> got it
<habeeb> asac, are you alive, sir?
<asac> habeeb: whats up?
<habeeb> asac, check your pms
<asac> habeeb: no pm received ... if its mozilla related, we can do this in #ubuntu-mozillateam as well :)
<habeeb> No, it isn't. Its gnash related
<pochu> habeeb: you aren't identified, so you can't pm
<habeeb> Aw..
<habeeb> Ta~ta gnash has an IRC channel too ^_^
<Kmos> crimsun: are you there?
<crimsun> hi
<Kmos> crimsun: bug 42201
<ubotu> Launchpad bug 42201 in phpmyadmin "Silly problem with a parameter" [Medium,Needs info]  https://launchpad.net/bugs/42201
<Kmos> can you check this one.. is with phpmyadmin
<crimsun> I'm not sure what you want me to check; it's currently synced from Debian. Are you asking for an SRU?
<Kmos> no.. if the bug was fixed
<Kmos> and there is a new version if you want to know :)
<Kmos> v2.10.2
<crimsun> I honestly have no way of checking; I can't install anything on this laptop ATM.
<crimsun> probably better posed to -motu, since it's in universe.
<Kmos> i will install it to check the bug
<Kmos> :)
<Kmos> crimsun: it's fixed
<crimsun> Kmos: ok
<jdong> crimsun: would you be willing to sponsor a ktorrent SRU?
<jdong> I've been patiently waiting for a few weeks already :)
<crimsun> bug #?
<ogra_> crimsun, do you have any idea if we will see support for the SiS7019 before gutsy comes out ? 
<jdong> bug 110881
<ubotu> Launchpad bug 110881 in ktorrent "[SRU]  Citical bug cherrypicks from SVN" [Undecided,In progress]  https://launchpad.net/bugs/110881
<ogra_> i know there are some patches but dont know the status ...  i have a bunch of ltsp users that have ordered big amoounts of ebox 2300 thin clients, they are equipped with these things ...
<LaserJock> jdong: got a sec to talk TeX?
<jdong> LaserJock: yeah, sup?
<LaserJock> jdong: was reading the debian-tex list
<LaserJock> jdong: are you doing any backporting work?
<jdong> LaserJock: I haven't done anything with TeX as far as backporting it
<jdong> LaserJock: there is a request for texlive
<jdong> but it seems to be some 20-odd source packages with a few source edits
<jdong> for build-dep version bumpdowns
<jdong> I was kinda scared to touch it till I talked to someone who knew something about it :D
<LaserJock> well, there is another person who's got backports already
<LaserJock> and I was thinking of setting up a repo for it
<LaserJock> I didn't think texlive 2007 would be very good -backports material
<LaserJock> what's your opinion?
<crimsun> ogra_: -ECRYSTALBALL
<jdong> LaserJock: texlive replaces the existing tex stuff (or some of it), right?
<jdong> I'm not well-versed in tex... I've used latex like 3 times
<jdong> :D
<LaserJock> yes, in gutsy we got rid of tetex
<LaserJock> and fiesty ships with both tetex and texlive 2005
<jdong> ah
<jdong> what would be the consequences of replacing texlive 2005 with 2007? any compatibility issues?
<LaserJock> tetex is dead upstream
<LaserJock> well, with tex it's pretty hard to figure out the consequences
<LaserJock> users tend to do a lot of manipulation/configuration/customization to their TeX installs
<jdong> true
<jdong> it sounds pretty uneasy to me
<jdong> I personally don't want to touch it if not direly necessary
<LaserJock> but this one guy was able to backport texlive 2007 to feisty, edgy, and dapper
<LaserJock> going from the Debian unstable packages
<jdong> AFAIK all it took was recompiling sid packages
<jdong> doing a bit of b-d tweaking
<jdong> to force a few versions slightly lower
<LaserJock> dapper might take a bit more work
<LaserJock> but feisty is pretty easy I think
<LaserJock> but I wanted to talk to you about whether you thought we should shoot for -backports or try to do some semi-official repo
<jdong> LaserJock: if feisty looks easy, I'm all for doing it; if build-dep tweaks and a few additional backports is all it needs, we can totally do that
<jdong> but for dapper/edgy, it is probably better unofficial
<pygi> jdong, you're here finally!!!
<jdong> in the meantime I have no issues with him keeping unofficial backports
<jdong> privided that they're sanely versioned, etc
<LaserJock> jdong: using -backports is a bit nicer as it takes something like 700MB to host the whole lot
<LaserJock> so finding somebody to host an unofficial repo can be difficult
<pygi> jdong, poke when you get time pls
<Nafallo> does backports get hammered a lot?
<jdong> Nafallo: haha apparently it does
<jdong> pygi: I've got some time now, sup?
<Nafallo> then my 3Mbit probably won't suffice ;-)
<pygi> jdong, we should do a backport of libburn, libisofs, and brasero
<jdong> Nafallo: haha, we used to clock in at 25GB/day when we were unofficial
<jdong> pygi: sounds cool; haven't I done something like that before?
<pygi> jdong, you did. But new versions =)
<jdong> pygi: ooh, me likey new versions
<Nafallo> jdong: see priv :-)
<jdong> LaserJock: if the dude who does the unofficial backports is well-qualified, we could just have him upload the sources manually to -backports
<jdong> LaserJock: I'm sure -archive will be irked but meh :D
<LaserJock> jdong: well, he seems to be able to get things to work, but I think he needs to go through somebody for a while at least
<pygi> jdong, k, let me know when we do it, so I can give you a hand
<LaserJock> jdong: so what I can do is grab his packages, look them over myself or have another MOTU look at them, and then shove them off to you
<LaserJock> sound ok?
<jdong> LaserJock: sounds great , thanks!
<jdong> pygi: mmmkay, after I get back from vacation
<pygi> jdong, doki
<Kmos> crimsun: http://revu.tauware.de/details.py?upid=5586
<crimsun> Kmos: it's better to tell me in #ubuntu-motu, please
<Kmos> wrong channel
<Kmos> sorry
#ubuntu-devel 2007-06-17
<Hobbsee> hey all!
<mrsn0> hoi
* Hobbsee shakes her head.
<Hobbsee> yay, -devel-discuss.
<nesl247> Is there a list of patches ubuntu uses, and the patch istelf
<Hobbsee> nesl247: patches.ubuntu.com
<nesl247> Hobbsee: Those are against debians packages
<nesl247> I need the patches against the upstream tarball
<nesl247> At least that's what the page says
<Hobbsee> nesl247: then you'd have to download the source, and look in the .diff.gz
<Hobbsee> or in debian/patches of the source - depending on how much you want
<nesl247> Ugh, That's what I'm doing, such horrible management for patches
<nesl247> I'm really surprised there isn't a patches.ubuntu.com that has each package, and it's patches
<nesl247> Against upsream, not debian
<Hobbsee> there may be.  i just dont know of it
<Hobbsee> debian may have one, too
<nesl247> Still trying to figure out what ubuntu patched to get the nice logout dialog
<minghua> there isn't, either in ubuntu or debian
<minghua> every package deals with patches in its own way
<nesl247> minghua: That's bad. All the patches should be listed in one location, and of course included in each package..
<nesl247> I mean, if someone wants to use the patch for another distro let's say, they have to jump through hoops
<Hobbsee> depends what they'r eusing as a base and such
<minghua> nesl247: they are, in the .diff.gz files
<nesl247> minghua: I told you, that's a pain in the ass to use
<minghua> nesl247: they are just not necessarily separated to individual patches
<nesl247> I mean, it's not too bad, but it's not a simple download a patch. You have to download that, patch, then get the patch from that
<nesl247> Do any of you know what patch does the nice logout dialog?
<minghua> nesl247: Depends on the point of view, I suppose.  It's very easy to use for Debian-based distros.
<nesl247> minghua: Yes, but when you create a patch, you tend to think of submitting it upstream. At least that's what a lot of distros do
<Hobbsee> nesl247: it's in gnome-session, i'm told
<nesl247> Hobbsee: I think I have the patch, but the logout dialog didn't change
<Hobbsee> nesl247: sure -but there's no point sending a humongous block patch of the entire debian directory
<nesl247> Hobbsee: that's why each patch should be located separately as just the individual patches
<minghua> nesl247: in Debian, it's a decision of individual maintainers.  And I believe (I don't have hard data to back up) the majority of maintainers do send patches upstream.
<Hobbsee> like patches.ubuntu.com/by-release/ is.  yes
<minghua> And IIRC, the logout dialog patch was definitely sent upstream.
<nesl247> It's not included in gnome yet then, trying to port it.
<minghua> I believe GNOME upstream has their reasons for not accepting it immediately, but that's not really because Ubuntu didn't make the patch available.
<nesl247> I wonder why the patch isn't working then
<nesl247> Hppane to have a link to the patch. Maybe I'm missing a package that needs patching
<nesl247> Aha, think I'm missing gnome-panel stuff
<ccxxpro> hi all
<ccxxpro> anybody there can help me to solve the installation problem 
<ccxxpro> i'd like to dual boot vista + ubuntu 
<ccxxpro> and i follow the instruction from the forum 
<ccxxpro> i got the menu from the grub and window vista 
<ccxxpro> but when i choose to boot from window vista 
<ccxxpro> instead of booting from vista , it just restart my laptop
<ccxxpro> anybody , can help me to solve the problem ?
<AndyP> ccxxpro: this isn't a support channel, try #ubuntu
<grayman> sure! The instructions for solving that problem is in the topic
<ccxxpro> thanx
<ccxxpro> wrong channel
<ccxxpro> hehe
* Hobbsee waves
* ion_ applies a sine wave to his hand.
<Hobbsee> heh
<pygi> morning
<Fjodor> 'morning pygi
* Mithrandir yawns.
<pygi> morning Fjodor and Mithrandir 
<Fujitsu> Hi Mithrandir, Fjodor, pygi.
<pygi> and hi Fujitsu :)
<Mithrandir> hiya fuji, pygi
<Fjodor> Hi Fujitsu 
<Fjodor> And Mithrandir, of course :-)
<mdke_> Mirv: yeah, we should do some
<Kmos> any core-dev ?
<Kmos> https://launchpad.net/ubuntu/+source/aegis-virus-scanner/0.1.1-1 -> no more supported by author
<Kmos> v2.0.0 in development :)
<drlivesey> /who
<bhale> http://ars.userfriendly.org/cartoons/?id=20070617
<sn0> userfriendly ftw :] 
* Hobbsee waves
<bhale> hi Hobbsee 
<jsgotangco> hey
<bhale> yay, jerome
<Hobbsee> :)
<Hobbsee> hiya bhale, spam
<jsgotangco> hey brandon, Hobbsee
<jsgotangco> good weekend to you guys!
* Hobbsee ponders the gunshots
<Hobbsee> or fireworks.  not sure which
<desrt> bhale; from a reference point of view, yay for us.  from a "funny?" point of view: no. :p
<bhale> desrt: i was recounting our runins with sexpert to brad (medsphere) yesterday
<bhale> desrt: I cant find him on the web
* desrt shrugs?
<desrt> why should you expect to?
<bhale> Im not sure, I had an idea that he did something worthwhile for GNOME once
* desrt finds on planet gnome Today's HUGE news
<desrt> Huge news!! A few minutes ago, 4 Front has released the Open Sound System (OSS) under GPL!!
<bhale> desrt: i see that on lwn also, I scratched my head.
* Hobbsee ponders the merits of changing from 8 megabit max broadband to 17 megabit max broadband.
<desrt> broadband would be so much more useful if 17mbit was actually 17mbit
<desrt> and not like 17down/2up
<Hobbsee> yeah, well
<Hobbsee> http://bigpond.com/offer/sco/?page_name=cable&offer=coles
<pygi> desrt, you're lucky you can get 17down even
<desrt> i can't.
* Hobbsee wonders what FTTN ends up being.
* desrt wanders away to perform various morning activities
<jsgotangco> hey sabdfl
<sabdfl> hiya
<soc> some here who knows something about avivo?
<soc> how can  i find out my gpu's pciid?
<ion_> lspci -n | grep 0300
<soc> ah thx+
<soc> do you know if there is somewhere a websvn, so i can look if the avivo developers forgot to add my card or if it is something different
<Nafallo> soc: apt-get source isn't good enough? :-)
<dorto> Bug #107925 was filed in April, not fixed yet. It seems to be a trivial fix, what could be the possible reasons for not applying it yet?
<ubotu> Launchpad bug 107925 in synaptic "Synaptic writes wrong download scripts" [Medium,Confirmed]  https://launchpad.net/bugs/107925
<dorto> url: https://bugs.launchpad.net/synaptic/+bug/107925
<dorto> oh, already generated :)
<Nafallo> dorto: ubotu already said the URL :-P
<dorto> yeah, saw it a little late :)
<pH> i everyone, i would be interested in contributing to ubuntu. what is the better way to start ?
<Nafallo> pH: in what way? :-)
<pH> fixing bugs, coding
<Nafallo> #ubuntu-motu should be the place to be then :-)
<pH> thx :-)
<soc> ok found it: http://gitweb.freedesktop.org/?p=avivo/xf86-video-avivo.git; a=blob_plain;f=include/avivo.h
<soc> would it be enough to add another entry like "#define PCI_CHIP RV515_7145 0x7145"
<soc> ok, seems i have to change the headerfile and things in avivo.c
<soc> will i be able to damage my hardware by adding another (maybe) gpu to the accepted id's?
<soc> ... another (maybe compatible) gpu to the accepted id's?
<mjr> shouldn't
<soc> ah ok
<soc> then i'll try it
<mjr> people have done that all the time with atis ;] 
<soc> i downloaded the source with apt-get source
<soc> will debuild be enough to rebuild the package?
<soc> mjr:
<soc> mjr: i installed the modified package ... i'll hope your right :-/
<pygi> hey Zdra 
<Zdra> hello :)
<soc> omg ...
<soc> i saw something
<soc> i added my card and saw something graphical with it ...
<soc> i switched it off panically
<soc> ok i'll try again ...
<soc> maybe some psychological support?!?!
<soc> i could need that now
<soc> ok, resolution is fucked up ...
<soc> but it seems to work ...
<soc> i saw gdm approximatley 3 times ,,,
<soc> can somebody help me?
<soc> please?
<soc> where is the original author of avivo?
<Hobbsee> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<Hobbsee> i'm not sure this is an appropriate channel, either.
<pygi> Hobbsee, good morning kid :)
<Hobbsee> hiya
* pygi is off to dinner
<pygi> Hobbsee, you good? :)
<Hobbsee> yeah. 
<pygi> perfect ^_^
<soc> yeah ok ...
<soc> it seems to kind of work ...
<soc> does someone have the email/im of jerome glisse?
<soc> he seems to be one of the developers
* Hobbsee suggests launchpad, or google, might be an appropriate place to look
* Hobbsee also notes that this is not the appropriate channel.
<soc> ok, so where should i go?
<Hobbsee> #ubuntu+1, probably
<Hobbsee> seeing as it's gusty
<Hobbsee> er, gutsy
<Hobbsee> maybe to the relevant channels for what you're working on - google might be able to tell you if there's an applicable irc channel
<mc44> soc: why don't you read http://lists.freedesktop.org/archives/xorg/2007-June/025506.html and http://www.fooishbar.org/blog/2007/Jun/15#donations-2007-06-15-00-09
<soc> ah thx
<pygi> Hobbsee, back to bug you
<Hobbsee> oh noes!!
<pygi> :)
<alex-weej> what is the partitioning library used by ubiquity?
<alex-weej> does it share code with GPartEd?
<alex-weej> i ask as GPartEd 0.3 supports moving file systems, which is incredibly useful when installing
<LaserJock> I thought it used parted but I don't know if that's changed
<Kmos> http://dad.dunnewind.net/main.php
#ubuntu-devel 2008-06-09
<Linolium> hi all, I have a silly question
<Linolium> does anyone here know about the linker ld?
<persia> Linolium: You're better off asking your question directly.  While someone might know the answer to your specific question, few are foolhardy enough to admit to complete knowledge of ld, and this may or may not be the ideal forum.
<brandonperry> I know everything about ld
<brandonperry> :-P
<pwnguin> what about gold?
<brandonperry> I lie, I have only used it a couple times
<Linolium> I am using ld for my generated code but it is giving jmp calls the wrong address  ie. 0x80000300 instead of 0x00000300  Does anyone know what ld option can fix this?
<Linolium> my .map file contains .=(0x80000000+SIZEOF_HEADERS) which is the problem
<Linolium> the code itself is in the correct location
<persia> Linolium: That's a much better question.  You might want to specify the package on which you are working, and provide a pastebin of the build log to show context.
<Linolium> I am working in windows aiming for taito f3 system that uses a MC68020 processecor
<Linolium> using gcc's windows distro
<Linolium> everything is fine except for the address relocation for jumps
<Linolium> in the code
<persia> Linolium: In that case, I suspect this isn't the best place to get the answer.  Unfortunately, I don't know which would be the correct forum.
<Linolium> that is what I was afraid of
<Linolium> :: sigh
<Linolium> ::
<Linolium> there doesn't seem to be any place that knows ld well :(
<pwnguin> surely mingw has a channel
<Linolium> dunno
<Linolium> one would hope
<pwnguin> or a linux devices or embedded channel
<pwnguin> i bet one of the linksys firmware channels knows the right people
<Linolium> ok
<Linolium> well thanks
<Linolium> it's time for me to sleep now
<Linolium> I'll tackle this problem more tomorrow
<pbn> hi
<pbn> Linolium: you are simultating the Motorola 68020 in Windows ?
<Linolium> mame
<Linolium> :)
<pbn> yes, mame :)
<pbn> I was gonna say MAME already does that :)
<Linolium> heh
<pbn> doesn't it ?
<Linolium> yeah
<Linolium> it does
<Linolium> well, up to my function calls
<Linolium> hehe
<pbn> ah, now I get it :)
<pwnguin> wait, why not ask the mame people?
<pbn> yeah
<pwnguin> they're all over efnet
<pbn> I was gonna say, ask the mame developers
<pbn> yeah they're probably on efnet
<Linolium> efnet #mame?
<pbn> efnet #mame probably
<Linolium> guessing
<Linolium> ok
<Linolium> thanks
<Linolium> peace guys
<alex1> hi guys. i've enabled hardy-propesed in software updates, but can't see the patched kernel in the list of packages to be updated? I want the latest patched kernel that should be in -proposed... what am i doing wrong?
<persia> alex1: You are confusing linux with linux-meta and #ubuntu-devel with #ubuntu
<alex1> err sorry yeah i should've asked in #ubuntu. linux-meta?
<alex1> oh i see. https://launchpad.net/ubuntu/hardy/+source/linux-meta  thanks :)
<dholbach> good morning
<pitti> Good morning
<dholbach> hi pitti
<dholbach> hi mvo, thekorn
 * Hobbsee crash-tackles pitti in greeting!
<mvo> hey dholbach
<mvo> hi pitti
<pitti> tkamppeter: which "custom options" patch do you have in mind? why isn't it going into 1.4?
<pitti> tkamppeter: please don't upload anything into Ubuntu yet
<pitti> tkamppeter: (I mean cups)
<pitti> tkamppeter: I wait until the cupsys -> cups rename makes it past Debian NEW
<pitti> tkamppeter: of course feel free to commit stuff to the svn
<pitti> Riddell: was on VAC on Friday; doko and I wanted to attack  MIR today
<pitti> hey Hobbsee, hi dholbach!
<pitti> *group hug*
<Hobbsee> :)
 * pitti hugs mvo, too
<dave_> Interested in MOTU!
<persia> dave_: Come to #ubuntu-motu !
<thekorn> hello dholbach
<pitti> asac: what's your feeling on bug 233922? ready for -updates? looks good from my POV so far?
<ubottu> Launchpad bug 233922 in yelp "[new-upstream] Firefox 3.0 RC1 is available" [High,Fix committed] https://launchpad.net/bugs/233922
<wgrant> Don't we have RC2 now?
<pitti> that's a different issue
<pitti> the -proposed ones should go to -updates first
<wgrant> Is it really safer to push two large changes to -updates than one larger one?
<pitti> wgrant: we know that the current set is good
<pitti> if we keep piling up new uploads in -proposed, testing all the changes gets too complicated
<pitti> and we don't have -rc2 packages
<wgrant> OK.
<pitti> seb128: bonjou!
<asac> wgrant: yeah RC2 should be much quicker
<pitti> bonjour, even
<asac> pitti: i'd say its good. ill go through the bug reports once more and let you know later
<pitti> asac: cool, thanks
<seb128> guten tag pitti
<\sh> asac: rc1 is much faster then the orig hardy one
<asac> \sh: hehe ... i referred to the time that is needed till it hits the archive ;)
<asac> but yes, there have been additional performance boosts and a few more IO bustage fixes
<Q-FUNK> to which package could I reassign Bug #236961 that would remotely make sense?
<ubottu> Launchpad bug 236961 in upgrade-system "8.04 Install Error" [Undecided,New] https://launchpad.net/bugs/236961
<\sh> asac: oh...damn..I'm still lacking reality ;) free beer in a pub is nice but makes life a hell
<Q-FUNK> same question for Bug #236732
<ubottu> Launchpad bug 236732 in upgrade-system "upgrade fails dapper to edgy" [Undecided,New] https://launchpad.net/bugs/236732
<asac> \sh: i know what you mean :)
<pitti> Q-FUNK: installer errors -> debian-installer or ubiquity, upgrade errors -> the package that failed the upgrade, or if it is a bug in the upgrader itself, 'update-manager'
<\sh> asac: but at least we won ;)
<Q-FUNK> pitti: I regularly get people who presume that upgrade-system is a generic package name to report an upgrade failure. figuring out which package to reassing these 3 to is challenging.
<cjwatson> Q-FUNK: looks like a dirty CD drive to me; a CD drive cleaning kit might well work wonders. I very much doubt it's an installer bug as such, because actual corrupt packages (as he's reporting) would happen to everyone. However, there's an outside chance that the kernel's driver for his CD is busted, in which case 'linux' would be the appropriate package
<cjwatson> Q-FUNK: I doubt we can do anything about his problem in either debian-installer or ubiquity
<Q-FUNK> cjwatson: looking at his bug, I'm thinking more of e general failure in his IDE controler, for which he is evidently blaming his upgrade.
<cjwatson> Q-FUNK: could be; by "driver for his CD" I guess I was including everything in the relevant stack
<Q-FUNK> cjwatson: replying to someone who already made up their mind thta whatever fried his hardware is our fault generally is a lost cause.
<cjwatson> I'd probably include some advice about CD drive cleaning, and toss it over to linux in case they can make anything of it
<cjwatson> it may be that there is at least something recoverable from dmesg
<Q-FUNK> could be, indeed
<dholbach> mvo: thanks for doing your share of sponsoring :)
<mvo> dholbach: heh :) funny that you noticed
<dholbach> mvo: I sure did :-)
 * mvo hugs dholbach
 * dholbach hugs super-soccer-mvo :)
 * mvo is more super-keen-injury-mvo now :P
 * ogra hrms about the kino bug dholbach just assigned to him
<dholbach> ogra: what's wrong?
<ogra> well, its unsolvable, dv1394 is going away in the kernel and Keybuk wont make udev create /dev/raw1394 with world permissions ...
<ogra> its an ancient butg (might be a duplicate of a 4 digit ubuntu bugzilla bug even
<dholbach> I can't do much about it
<ogra> me neither
<ogra> apart from changing the concept of ieee1394 completely :)
<persia> ogra: juju juju juju
<dholbach> if there's no other option at all to fix it, close it "won't fix" - I just wanted to get it through the sponsorship queue
<highvoltage> ogra: would it be inappropriate to link to a wiki page explaining how a user could make their own udev rule, even if it's unsupported?
<ogra> dholbach, wont fix will result in another bug agin ....
<ogra> i'D like to quiten it down
<ogra> highvoltage, sounds like an excellent idea, i tried to gather some info half a year ago for such a site
<pitti> dholbach: bah, I never got a mail for bug 232452; #$*(#$
<ubottu> Launchpad bug 232452 in latex-beamer "syntax error in colortheme beaver" [Undecided,Confirmed] https://launchpad.net/bugs/232452
<ogra> but didnt get any input (i dont own a dv cam)
<dholbach> pitti: AFAIK the LP bug about "subscription to a bug should send a mail rightaway" is closed now - so it should work out better in the past
<pitti> right
 * dholbach hugs pitti
<pitti> . o O { most of the work for sponsoring is to forward these patches upstream }
<Q-FUNK> pitti:  seems that someone finally confirmed that my new -geode package works, in combination with the new -nsc package I had to produce to eliminate PCI ID conflicts. both are in my PPA, but might need some cleanup before they can be merged in.
<highvoltage> Q-FUNK: ah, are you the q-funk that's been talking to (I think his nick is coolio on freenode) about these drivers? I need to assist him with it at some point.
<Q-FUNK> highvoltage: my nick is q-funk everywhere, so probably not. :)
<highvoltage> bah! :)
<Q-FUNK> highvoltage: but what was the issue he had?
<highvoltage> Q-FUNK: he has new thin clients from Via with brand new display chips, which don't work well with Edubuntu currently, he told me he talked to someone on #edubuntu who said that they're working on packages for these driverse
<highvoltage> Q-FUNK: but I haven't had chance to catch up on it yet.
<Q-FUNK> highvoltage: via doesn't use the -geode driver, though. IIRC they have someone making them custom X drivers that might eventually be merged.
<DktrKranz> sponsors for main, mind reviewing scons merge from bug 226783? thanks.
<ubottu> Launchpad bug 226783 in scons "Merge scons 0.98.4-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/226783
<tkamppeter> pitti, hi
<tkamppeter> Riddell, hi
<Riddell> hi tkamppeter
<tkamppeter> Riddell, there is a probvlem with the build server and Qt. I tried my first upload as core-dev, HPLIP 2.8.5, and I got an FTBFS with the following error:
<tkamppeter> The following packages have unmet dependencies:
<tkamppeter>   python-qt4: Depends: python-elementtree but it is not installable
<pitti> tkamppeter, Riddell: bug in python-qt4
<tkamppeter> The package tried to pull python-qt4 with its build dependencies.
<pitti> p-e is an intregral part of python2.5 and doesn't need to be depended on for 2.5 (and to be in main)
<pitti> -> depends: python2.5 | python-elementtree
<tkamppeter> pitti, Riddell, any chance that this get fixed soon?
<Riddell> tkamppeter, pitti: I can fix that now
<tkamppeter> Riddell, great, HPLIP 2.8.5 needs testing, upstream has done a lot on hp-toolbox and there are a lot of new bugs which need to get to upstream so that Intrepid gets a nice 2.8.7.
<tkamppeter> Riddell, pitti, after Riddell has fixed python-qt4, what has to be done so that the build server does a new build of the same HPLIP package?
<pitti> tkamppeter: you can retry the build
<pitti> tkamppeter: please tell me when the fixed pakcage is in the archive
<tkamppeter> Riddell, can you also check whether perhaps python-qt3 suffers the same problem?
<pitti> tkamppeter: then I'll show you
<pitti> Riddell: I'm always amazed how many arithmetic libraries for the same purposes one can invent...
<Riddell> surely not exactly the same purpose
<munckfish> When uploading bzr source branches to LP is it ok to upload multiple sources and link them with a single product as a collection? E.g. Cell SDK would be the product, under which I'd want bzr branches for cell-gcc, cell-binutils and so on.
<munckfish> Rather than having separate LP products for each e.g. Cell GCC, Cell binutils etc
<Riddell> tkamppeter: python-qt3 does not seem to have that issue
<pitti> Riddell: indi failed to upload; did you get an explanation via mail?
<pitti> Riddell: ah, because it was NEWed incorrectly
 * pitti fixes
<pitti> Riddell: ok, I processed MIR up to what I can
<zul> morning
<Riddell> pitti: ok, thanks
<nixternal> woo, go pitti go!
<cjwatson> munckfish: while it would work, it's not really kosher
<cjwatson> munckfish: Launchpad projects are supposed to correspond to single atomic upstream projects
<cjwatson> munckfish: I suppose it depends on whether you think that cell-gcc is just a branch of gcc (my view) or whether it's part of a separate Cell SDK entity that's permanently forked gcc
<munckfish> cjwatson: hi, yes this is the problem I have - for normal GCC I'd say keep it separate of course
<munckfish> however, all of these related bits from the Cell SDK page are like a forked collection
<munckfish> I sort of felt it important to group them together so that was obvious
<munckfish> I also realise they will go away eventually
<munckfish> but having struggled to create a cross tool chain with gcc-4.3 et al, I'm thinking of continuing to maintain these cell-* sources
<munckfish> So, do you still think separate or collection?
<cjwatson> munckfish: I would still lean towards separate, but seems like a grey area. Perhaps ask #launchpad for a ruling
<munckfish> cjwatson: ok, I'll do so
<munckfish> thx for your opinion
<Hobbsee> cjwatson: btw, any chance of seeing the new vim in intrepid anytime soon?  looks like there's a request for sponsorship, with your name on it :)
<alex-weej> seb128: can you push a patch for https://bugs.launchpad.net/ubuntu/+source/gnome-applets/+bug/211604 so people stop complaining about invisible trash icons? the patch is upstream on gnome but it's not going anywhere.
<ubottu> Launchpad bug 211604 in gnome-applets "trash icon disappears in panel" [Low,Triaged]
<nixternal> Hobbsee: you call me a vista lover, yet you are requesting vim? vi vi vi - the sign of the devil!
<Hobbsee> nixternal: at least vim runs on ubuntu.  the same cannot be said for vistsa.
<seb128> alex-weej: I've read your comments, but do you care to explain what it's doing and why?
<Hobbsee> -s
<alex-weej> seb128: it's the same fix that went into many other applets that used to break
<seb128> alex-weej: that's not very useful to me to understand what it's doing and why
<alex-weej> bonobo-activation-server is *allowed* to exist across login sessions, the fact that it does is in most cases a bug, but it still shouldn't break objects
<alex-weej> the trash applet needs a DBus connection since the move to GIO
<seb128> alex-weej: isn't that bug #49594?
<ubottu> Launchpad bug 49594 in libbonobo "Bonobo-activation-server sometimes is not killed after session restart, leading to many unexpected problems" [Undecided,New] https://launchpad.net/bugs/49594
<alex-weej> seb128: yes, but it's a separate bug that is not important
<seb128> well, it leads to similar issues
<alex-weej> if the trash applet process gets activated by bonobo, it inherits the activation server environment by default
<alex-weej> bonobo specifically has mechanism to allow the activated object to inherit specific env variables from the *activator*
<alex-weej> i.e. trash applet will take the dbus session bus address from gnome-panel
<alex-weej> if the patch is applied
<seb128> why is it working for me without the patch then?
<alex-weej> because your b-a-s exits
<alex-weej> trust me, it needs to be in and it will fix this bug.
<seb128> seems to be a workaround, but it it makes things work better while the libbonobo issue is still there
<alex-weej> no it's not
<alex-weej> there are legitimate cases for b-a-s to exist cross-session, and fixing bug 49594 won't fix this bug in 100% of cases
<seb128> we had bugs about the trash not showing an icon way before gio and dbus use
<ubottu> Launchpad bug 49594 in libbonobo "Bonobo-activation-server sometimes is not killed after session restart, leading to many unexpected problems" [Undecided,New] https://launchpad.net/bugs/49594
<alex-weej> seb128: probably because it still used dbus with gnomevfs
<alex-weej> seb128: i wrote a patch last year to cause b-a-s to exit with the session, thus resolving 49594. it was rejected.
<alex-weej> i learnt from the devs that it is supposed to be allowed to outlive a session
<seb128> but in such cases it has a wrong environment
<alex-weej> and that fixing dbus-using activated objects is done by telling b-a-s to pass the env vars from the activating process
<seb128> ie, outdate dbus bus informations
<alex-weej> well, it's up to you. the bug will be accepted upstream eventually because it is the right thing to do. if you want to keep triaging these bugs then suit yourself :P
<alex-weej> and i made all of these arguments about it the first time round. turns out i just didn't understand the bonobo architecture properly.
<alex-weej> let me find the bug.
<seb128> alex-weej: as said before I don't discuss this change, I'm trying to understand what else is broken there
<x_dimitri> what practical advice would you give an open-source enthusiast who would like to get involved as a contributing developer to ubuntu?
<x_dimitri> I'm talking about coding skills to master (language, paradigms e.t.c.)
<alex-weej> you just said what is broken. there is /nothing/ wrong with b-a-s having "outdated" DBUS_SESSION_BUS env. it shouldn't really be there in the first place, as b-a-s outlives dbus sessions
<x_dimitri> among other things
<dholbach> x_dimitri: check out http://wiki.ubuntu.com/MOTU/GettingStarted and the pages linked from there
<alex-weej> assuming the ideal case that it wasn't there, the env var would have to be passed from the activating process anyway
<ogra> x_dimitri, start in #ubuntu-motu, look through the different available tasks, grab oe and start working on it :)
<alex-weej> and the way to do that is with the .server definition file XML
<seb128> alex-weej: is there any case when we want to get the environment from b-a-s then? why not defaulting to use the activator one?
<alex-weej> yes there is case for getting env from b-a-s
<seb128> alex-weej: there is lot of .server around and I'm wondering if it makes sense to start change all of those rather than changing b-a-s
<x_dimitri> dholbach: thanks. I have seen those.
<dholbach> x_dimitri: great
<alex-weej> for every other env var that also outlives dbus sessions
<x_dimitri> :-)
<x_dimitri> ï»¿ogra:what does 'oe' mean
<ogra> one
<alex-weej> seb128: don't worry about changing b-a-s. the real fix is to move panel applets away from bonobo. it's coming!
<ogra> missed a char
<seb128> alex-weej: well, LC_ALL can change between sessions too, etc
<alex-weej> it can change *within* sessions
<seb128> alex-weej: should we apply the same trick to other environment variable?
<x_dimitri> ogra: oh, ok. Thank for your suggestions guys..
<alex-weej> it's not a trick, it's documented exactly for this case. it's the best of a bad situation.
<seb128> alex-weej: right but that's not common case
<x_dimitri> lemme see what the guys in #ubuntu-motu ahve to say
<alex-weej> i have to study
<alex-weej> cya
<seb128> alex-weej: ok, so should we use this documented case to make sure than other things, ie the locale, are correctly set too?
<pitti> asac: how's the rc1 bug front?
<zul> pitti: ping
<cjwatson> Hobbsee: I've been off for several days and am catching up; it would be best for somebody else to take it if possible
<asac> pitti: so far it looks good. how long will you be on today? I'd like to clean the relevant bugmail folders before we push this. is there still some time?
<pitti> asac: guaranteed until 18:00 CEST, then sporadic
<asac> pitti: ok thanks. Ill hurry - still need to do a quick lunch though ;)
<pitti> asac: enjoy
<cr3> why does archive.ubuntu.com/ubuntu/dists/dapper/Release mention "ia64" under Architectures, also mentions main/binary-ia64/Packages.bz2 with a size of 616356 bytes, but there's no such file under archive.ubuntu.com/ubuntu/dists/dapper
<elmo> cr3: because the archive is split between archive.ubuntu.com and ports.ubuntu.com after Releases files are generated
<cr3> elmo: hm, that makes my life complicated but nothing which can't be worked around. thanks for the explanation
<ogra> cr3, note that the ports url uses ports.ubuntu.com/ubuntu-ports instead of /ubuntu
<ogra> its not obvious and there is no link or anything on ports.ubuntu.com/ so you could see that
<cr3> ogra: thanks for the note, but I see no "ubuntu-ports" subdir under http://ports.ubuntu.com/
<ogra> yeah
<ogra> its a redirect apparently
<cr3> ogra: man, the weirdness just doesn't stop :)
<ogra> yeah
<ogra> took me ages to figure that out
 * ogra wouldnt have found out if inifinity wouldnt finally have told him
<cr3> ogra: what's wrong with just using ports.ubuntu.com/, couldn't that have worked?
<cjwatson> ogra: /ubuntu-ports is just a redirect to / though
<ogra> cr3, thats not te url used in the tools (apt-setup for example)
<cjwatson> cr3: that should work fine
<ogra> yes, it should
<cjwatson> ogra: it's not the "official" URL, but it'll work
<ogra> its just inconsistent
<ogra> indeed
<cjwatson> the reason we generally use /ubuntu and /ubuntu-ports and such is to aid mirrors
<ogra> i dont understand the reason for -ports though
<ogra> ah
<cjwatson> so that if somebody is mirroring a zillion different free software distributions they don't have to have a virtual host for each
<ogra> right
<cr3> I love asking these questions which seem just weird but have a perfectly reasonable explanation
<ogra> makes sense
<cjwatson> and /ubuntu-ports so that they don't have to figure out how to merge it back into /ubuntu
<\sh> is mono somehow uninstallable in intrepid?
<cjwatson> seb128: do you have any idea how I would go about fixing bug 236988? According to the freedesktop.org wm-spec, _NET_WM_STATE_FULLSCREEN goes above _NET_WM_STATE_ABOVE (and presumably this has to be the case so that fullscreen > panels)
<ubottu> Launchpad bug 236988 in openssh "HARDY: gnome-ssh-askpass does *not* grab keyboard or focus if contested with other apps" [Undecided,New] https://launchpad.net/bugs/236988
<tkamppeter> pitti, according to LP (https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/python-qt4/4.4.2-0ubuntu2) Riddell's fix is up. How do I proceed to rebuild HPLIP?
<Riddell> tkamppeter: go to the build page in launchpad
<Riddell> click retry
<Riddell> https://edge.launchpad.net/ubuntu/+source/hplip/2.8.5-2ubuntu1/+build/632305
<seb128> cjwatson: not sure, gnome-keyring seems to use _NET_WM_STATE_MODAL, _NET_WM_STATE_ABOVE, but mvo might know better
<seb128> that would also be a wm bug
<seb128> s/would/could
<cjwatson> you aren't supposed to use gdk_window_set_modal_hint on non-transient windows, apparently, and gnome-ssh-askpass doesn't have anything it could be transient on
<pitti> tkamppeter: right, what Riddell said; you have to do that for all architectures where it failed
<cjwatson> gdk_window_set_modal_hint doesn't obviously help, anyway
<cjwatson> but I have to go
<mvo> cjwatson: I have a look
<seb128> cjwatson: gnome-keyring does that
<seb128>         /*
<seb128>          * We do this to guarantee the dialog comes up on top. Since the code that
<seb128>          * that prompted this dialog is many processes away, we can't figure out
<seb128>          * a window to be transient for.
<seb128>          */
<seb128>         gtk_window_set_keep_above (GTK_WINDOW (dialog), TRUE);
<seb128>         gtk_window_set_resizable (GTK_WINDOW (dialog), FALSE);
<seb128>         gtk_window_set_type_hint (GTK_WINDOW (dialog), GDK_WINDOW_TYPE_HINT_NORMAL);
<mvo> (and check against gksu as well)
<cjwatson> seb128: doesn't help - must be doing something else as well
<tkamppeter> Thanks, pitti and Riddell. I see this button for the first time, is it a new LP feature or a core-dev-only feature?
<pitti> tkamppeter: it has recently been made available to developers
<seb128> ok, so I don't know
<cjwatson> (or else gnome-keyring has the same problem!)
<tkamppeter> Feature request: "Retry all failed archs" button.
<tkamppeter> pitti, with "developers" you mean core-devs or also MOTUs? Or does it depend in which repository the package resides (I only want to know it to tell the correct thing to others who ask me)?
<pitti> tkamppeter: feature request> there is a script which automates this; I'll show you next time
<pitti> tkamppeter: I'm not sure; I guess if you can upload a package, you can rebuild it now
<tkamppeter> pitti, HPLIP is now successfully built for 5 architectures (in the queue for the 2 missing ones). So these 5 are already on the way to the mirrors now?
<pitti> tkamppeter: yes, in one or two hours (depending on whether they finished building more than 3 minutes ago)
<tkamppeter> pitti, in former times I have seen a lot of "give-back" messages here on the IRC. Was this the retrying of a build when the first build went wrong?
<pitti> tkamppeter: exactly
<pitti> tkamppeter: "give back" is the term for historical reasons (it's still called like that in Debian)
<pitti> seb128, pedro_, bdmurray: can anyone of you play a bit with an NTFS volume to verify bug 229000?
<ubottu> Launchpad bug 229000 in ntfs-3g "random file corruptions in ntfs-3g < 1.2506" [High,Fix committed] https://launchpad.net/bugs/229000
<tkamppeter> pitti, then all except amd64 will make it in one hour and amd64 perhaps only in two hours.
<tkamppeter> pitti, what means if the "successfully built" for an arch switches from ACCEPTED to DONE?
<pitti> tkamppeter: "ACCEPTED" is the queue which holds built packages; the next publisher run (at :03 hourly) picks up those and puts them into the actual archive
<seb128> pitti: just playing on a ntfs partition and looking if everything works correctly?
<seb128> pitti: there is no TESTCASE on the bug
<pitti> tkamppeter: when that happens (aronud :05 hourly) it will get to DONE
<pitti> seb128: no, reproducing the actual bug is really hard
<pitti> seb128: I described my own testing in the bug (test suite, some operations in nautilus, etc.)
<tkamppeter> pitti, thanks.
<tkamppeter> pitti, can I also build Debian or Ubuntu packages with a .orig.tar.bz2 instead of a .orig.tar.gz file?
<pitti> tkamppeter: that feature is in hardy; so it depends on whether soyuz is running on hardy now; cprov?
<cprov> pitti: we haven't backported it to edgy. Let me check it again.
<tkamppeter> pitti, can you have a look at CUPS bug 2814?
<ubottu> CUPS bug 2814 in Core CUPS Software "Support AllowedChars for String/Password type custom PPD options" [Priority request for enhancement,New] http://www.cups.org/str.php?L2814
<pitti> cprov: edgy!
<tkamppeter> pitti, one minute this was not the right one.
<tkamppeter> pitti, it was the right one.
<cprov> pitti: confirmed, it's not there. Please file a bug so it can be done at some point in before LP 2.0.
<pitti> tkamppeter: ^
<seb128> pitti: ok, I didn't try the testsuite thing you mentionned but normal usage (copies, move, renaming, deleting, mount, unmounting, browsing the drive, dnd, etc) works correctly, I've added a comment to the bug
 * pitti hugs seb128, thanks
 * seb128 hugs pitti
<tkamppeter> pitti, it is about some enhancements to CUPS to really support the custom options which Mike has introduced in CUPS 1.2 (string, password, numeric, ...) but they got never really used. Currently, I am on the way to get them advertized to the manufacturers and supported by the Common Printing Dialog.
<asac> pitti: ok, lets feed this to the masses :/
<pitti> asac: rumble!!!
<tkamppeter> pitti, Lars Uebernickel (developer of foomatic-rip 4.0 and now GSoC student for the CPDAPI DBUS interface for the Common Printing Dialog has written two CUPS patches for these options.
<ogra> asac, food ?
<tkamppeter> One is for a special PPD keyword to restrict the allowed characters in string options, the other is about supporting the options in the CUPS web interface-
<ogra> yummy
<asac> pitti: should i set to verification-done?
<pitti> asac: please do, and describe the amount and quality of feedback you got
<tkamppeter> pitti, CUPS bug 2807
<ubottu> CUPS bug 2807 in Core CUPS Software "Exposing custom options in the web interface" [Priority request for enhancement,Closed w/o resolution] http://www.cups.org/str.php?L2807
<tkamppeter> pitti, and CUPS bug 1729
<ubottu> CUPS bug 1729 in Core CUPS Software "CUPS web UI should support new UIOption types (int, string, password)" [Priority request for enhancement,Pending] http://www.cups.org/str.php?L1729
<tkamppeter> Mike has rejected bug CUPS bug 2814 and he did not answer yet to the last patch for CUPS bug 1729.
<ubottu> CUPS bug 2814 in Core CUPS Software "Support AllowedChars for String/Password type custom PPD options" [Priority request for enhancement,New] http://www.cups.org/str.php?L2814
<ubottu> CUPS bug 1729 in Core CUPS Software "CUPS web UI should support new UIOption types (int, string, password)" [Priority request for enhancement,Pending] http://www.cups.org/str.php?L1729
<pitti> tkamppeter: I don't want to permanently carry large patches which are rejected upstream; we've been through this :/
<tkamppeter> pitti, so I leave them out as long as Mike does not accept them. If Mike turns away from the custom options I make them my baby with system-config-printer and the Common Printing Dialog. Perhaps Mike will return to them when I have made them common practise. Support from inside CUPS is a nice plus but not required.
<asac> pitti: commented.
<pitti> tkamppeter: ok, thanks
<pitti> tkamppeter: please file the orig.tar.bz2 thing as a bug against soyuz
<tkamppeter> In s-c-p and CPD I am upstream and I can publish specs on OpenPrinting, so no support from Mike Sweet required.
<tkamppeter> pitti, how do I report a bug on soyuz, which project? Which package?
<pitti> tkamppeter: "soyuz", no package
<pitti> bugs.lp.net/soyuz/+filebug
<tkamppeter> pitti, someone else reported this already as bug 225151.
<ubottu> Launchpad bug 225151 in soyuz "Please add support for .orig.tar.bz2" [Undecided,New] https://launchpad.net/bugs/225151
<pitti> seb128, asac: note that epiphany-browser has a newer version in intrepid, and xulrunner is already updated in intrepid, so I won't copy the lot from hardy-proposed to intrepid
<pitti> asac: bug 236984 is still open in intrepid?
<ubottu> Launchpad bug 236984 in xulrunner-1.9 "firefox 3.0 RC1 can easily deadlock when touching any chrome file while running" [High,Fix committed] https://launchpad.net/bugs/236984
<asac> pitti: yeah. its fix committed as our development branch is already on RC2 ... waiting for the queue to clear
<pitti> ok
<pitti> asac: xul and related copied, mass-copying of language packs in progress
<asac> pitti: ok ... let the fun begin.
<kees> pitti: er, I'm looking at "cron" to advise kirkland on doing a debdiff, and I'm not sure what version number to recommend.  :P
<kees> 3.0pl1-104+ubuntu1?  104ubuntu2 won't work due to the +build1, iiuc
<slangasek> 104ubuntu2 > 104+ubuntu1, no?
<pitti> kees: argh, I was so proud that we're finally back in sync :)
<pitti> kees: 104+ubuntu1 will work, yes
<kees> pitti: heh.  yeah, we've got a small correction that is unACKd upstream
<kees> they call /usr/bin/editor instead of /usr/bin/sensible-editor
<kees> and since kirkland is making changes to sensible-editor, this got examined at the same time.  :)
<pitti> kees: sorry for the weird version number in the first place; but it was the least evil-looking way to bump the number to something non-ubuntuish
<kees> yeah, I think it's the right solution; I'd just never hit this corner-case before.  :)
<kees> mvo: are the changes to apt-listchanges for "dapper->hardy" still needed?
<kees> mvo: I'm going to assume "no", please let me know if I should re-add them.  I'm requesting a sync for it since the other changes (security) are already upstream.
<mvo> kees: no
<kees> mvo: perfect :)
<mvo> kees: you assumed right :) its only needed for very old installs
<kirkland> kees: updated patch uploaded to https://bugs.edge.launchpad.net/ubuntu/+source/cron/+bug/222830
<ubottu> Launchpad bug 222830 in cron "crontab not observing EDITOR or VISUAL" [Wishlist,In progress]
<kirkland> kees: btw, previous one did not update the Maintainer field ;-)
<kees> bryce: can you check on efibootmgr?  if the ubuntu changes are upstream, can you do a "requestsync" for it?
<kees> kirkland: ah yes, good catch.  I would have noticed when I compiled it.  ;)
 * kirkland is glad he cleaned that one up before getting smacked by kees ;-)
<kees> hehe
<kees> argh, libx86
<kirkland> kees: is that 'argh' intended for me?
<kees> kirkland: no, just myself, I'm looking at my merges
<kees> ogra: say, can you do the powernowd merge?  while I touched it last, it was just a bug fix and I'm not entirely familiar with the code-base.
<ogra> me neither
<ogra> i only touched it once in my life iirc
<ogra> but if its needed, i'll take a look
<kees> ogra: ah, heh, okay, perhaps we can find someone else.  :)
<Mirv> since the language packs copying to -updates is not immediate but takes time, there might be a corner case situation right now that updating now results in eg. firefox failing because the firefox translations move and some packages updateable while some not
<Mirv> at least I was able to update my laptop so that Firefox gives some error on launch at the moment, though starts nevertheless
<ion_> I had to disable the Finnish language pack in my fatherâs Firefox in 8.04 because some functionality didnât work.
<Mirv> ion_: well the printing problem is known and fixed now in the new packs
<Mirv> ion_: also it's a matter of changing one "%" in the jar package
<ion_> Yeah, iâll re-enable it when i visit them the next time.
<blueyed> Can somebody from ~ubuntu-archive, please approve virtualbox-ose-modules for Hardy?
<ogra> blueyed, oh, did you enable lpia there as well ?
<ogra> that would be very handy
<blueyed_> sry.. system froze hard.. :/
<bryce> kees: the ubuntu change for efibootmgr is to build on lpia - I'm assuming that's not something upstream is interested in
<kees> bryce: ah, okay.  well, in that case, it might be time for a re-merge.  I was just browsing MoM and noticed it since I was the uploader for it.
<ogra> blueyed, did you enable lpia there as well ? hat would be very handy
<ogra> *that
<bryce> kees, ok I can take a look at it in a bit
<blueyed> v-o-m for lpia? could do, if you know that it works..
<blueyed> ogra: ^^
<slangasek> blueyed: well, please bear in mind that if you're adding functionality instead of just rebuilding for the ABI change, vbox will need to go through the full SRU process
<Mirv> (lang packs all synced now)
<blueyed> slangasek: sure.. and since I have no means to test it (apart from ppa) and not much time at hand, please ACK the current upload.
<ogra> blueyed, i only need the guest modules/utils, adding them would help with UME testing since you cant have 800x480 without the vbox X driver
<ogra> Keybuk, hey, what about making kino and friends polkit capable, then we could have a fine grained access model for 1394 devices :)
<blueyed> ogra: feel free to add it then.. :)
<blueyed> ogra: it's in Intrepid after all: https://edge.launchpad.net/ubuntu/intrepid/+source/virtualbox-ose-modules/24.2
<ogra> blueyed, i know :)
<Mirv> gash, by updating langpacks at the wrong time I was able to break firefox (profile) completely
<Mirv> it doesn't help that the rest of the packages came along now.
<Mirv> uh, ok, great actually, I just happened to had a hidden firefox on other desktop. it's fail-proof after all.
<highvoltage> ogra: not sure if you're interested in this, but this is what one of my friends have been doing in Nigeria: http://blog.wizzy.com/post/OLPC-and-Classmate-in-Nigeria
<ogra> rinning XP ?
<ogra> *running
<laga> seems like intel is just throwing money at the problem :)
<ogra> not really
<laga> WiMAX for $10000/month? :)
<hwilde> asus eeepc is going to have wimax builtin
<kestaz> how to compile kernel-ppa sources ?
<asac> Mirv: so no issue?
 * kees nominates gcc-4.3 as second only to openoffice.org in least-easy-to-understand-build-system
<mneptok> awalton_1: meep
<mneptok> kees: gcc gets extra points for its masturbatory nature.
<kees> mneptok: heh, true.
<slangasek> kees: I counter-nominate mpich!
<mneptok> kees: ask me about m_meeks' world sometime :)
<kees> slangasek: eek, I don't want to look now
 * slangasek grins
<kees> I'm beating my head against how to run the gcc testsuites using the locally installed gcc.  /me has given up now and is just building gcc again... hopefully I can poke into the Makefile what I need.
<kees> I'm too dense for doko's hints to penetrate my brain.  runtest hates me. wheee
<kees> at least it's a parallel build
#ubuntu-devel 2008-06-10
<Keybuk> kees: gcc probably doesn't like being compiled with -foh-hai -fi-can-haz-securitah
<mneptok> make --onan=true
<kees> Keybuk: the compiler part doesn't seem to mind, but the testsuite complains in parts
<kees> slangasek: gcc-4.3 wc -l on rules* is 10090.  mpich is just 292 :)
<slangasek> oh, well, there's that
<slangasek> though maybe it wasn't mpich, maybe it was some package that build-deps on mpich
<slangasek> hdf5, maybe
<pwnguin> kees: what about gcc-avr? surely cross compilation is more confusing
<slangasek> I think gcc-avr inherits all of its specialness from the gcc rules
<kees> pwnguin: gcc does ppc cross compiles too.  :)  but yeah, I probably shouldn't try to nominate "2nd most confusing" I bet there are tons
<pwnguin> tinyOS comes to mind
<kirkland> pitti: broken links to http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html and http://people.ubuntu.com/~pitti/ubuntu-cve/unchecked.html on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<kees> kirkland: I'll fix that, one sec
<kees> kirkland, pitti: MIR wiki adjusted.
<kirkland> kees: thanks
<confused_david> hi
<pitti> Good morning
<Hobbsee> pitti!
 * Hobbsee throws pitti a gummy bear in greeting
<pitti> hey Hobbsee!
<colo939> morning
<pitti> kees: thanks for fixing the wiki
<colo939> so are you all members of Ubuntu's development team?
<Hobbsee> mostly, yes
<colo939> cool, I have to say you guys are really doing a great job
<TheMuso> colo939: Thanks for the compliment. It is nice to know our work is appreciated.
<colo939> I might be interested in getting involved somewhere in the near future
<dholbach> good morning
<pitti> bryce: btw, fakesyncs should be Nbuild1, not Nubuntu1, and shouldn't have XSBC-Maintainer
<bryce> pitti: ok, I had looked for documentation on how to do fakesyncs but didn't see any so just followed how it had been done previously
<pitti> bryce: well, it isn't wrong, but with build1 it's pointed out more explicitly, and it'll get autosynced again as soon as Debian gets a new orig.tar.gz
<persia> bryce: General rule is for fakesyncs, only debian/changelog should differ from Debian (and better to use *buildN)
<dholbach> hi seb128
<seb128> hello dholbach
<\sh> moins
<asac> pitti: did you do tzdata update?
<pitti> asac: yes, why?
<asac> pitti: http://paste.ubuntu.com/18981/
<pwnguin> heh
<asac> pitti: [reed] got his java removed because of it :)
<[reed]> I didn't use java anyway ;)
<pwnguin> why = ?
<pitti> asac, [reed]: seems you don't have hardy-updates for universe?
<pitti> Package: tzdata-java
<asac> pitti: he says that he has no -proposed at all
<pitti> Version: 2008c-1ubuntu0.8.04
<pitti> Depends: tzdata (= 2008c-1ubuntu0.8.04)
<asac> was tzdata-java updated in -proposed?
<pitti> asac: right, for hardy it's in -updates already
<[reed]> root@jarodplus:~# cat /etc/apt/sources.list | grep hardy-updates
<[reed]> deb http://us.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
<[reed]> deb-src http://us.archive.ubuntu.com/ubuntu/ hardy-updates main restricted #Added by software-properties
<[reed]> deb http://people.ubuntu.com/~ubuntu-archive/ddebs hardy-updates main universe
<pitti> yes, it was
<pitti> [reed]: right, no hardy-updates for universe
<asac> ok then its just a transitional thing?
<pitti> asac: no, it's not
<asac> okay ;)
<asac> i see
<pitti> asac: this will happen very commonly with sources which build binaries for both main and universe
<pwnguin> so they DO exist
<pitti> yes, in hardy-updates
<persia> Is there a way to reduce the chance of this happening?
<pwnguin> (packages that build universe and main)
<pitti> well, we could add some sanity checks to update-manager perhaps
<persia> pwnguin: Lots of them.  Source is in main, but some of the binaries aren't.
<pitti> but either way, update-manager *removing* packages is a bug on its own
<asac> [reed]: you appear to not have  universe at all in your sources.list
<pitti> mvo: ^ it still does that?
<pitti> asac: (NB that he just grepped for hardy-updates, not hardy itself)
<persia> pitti: fixing update-manager is a way to reduce the impact, but is it not possible to synchronise the -updates push for all binaries in a single source?
<pitti> persia: that's already done
<[reed]> asac: http://paste.ubuntu.com/18984/
<persia> Also, update-manager will still remove packages in certain circumstances, where there's no declared dependency.
<pitti> persia: but if someone has hardy-updates/main in their sources.list, but not hardy-updates/universe, that won't help him
<persia> pitti: I see.  It's a matter of sources.list, rather than the state of the archive.
<pwnguin> people.ubuntu.com?
<[reed]> dbgsym packages
<[reed]> for generating proper, complete stacks in gdb
<pwnguin> sure
<asac> [reed]: you dont have hardy-updates at all in your sources.list
<[reed]> asac: well, I haven't touched this file in a long time
<asac> [reed]: err, same parse error on my side :)
<persia> asac: "| grep universe"
<asac> yeah
<pwnguin> unless theres a problem with that, i'd just well paste the whole thing
<persia> [reed]: You'll want to add universe to your hardy-updates line.
<[reed]> pasting entire file now
<asac> [reed]: ++
<[reed]> http://paste.ubuntu.com/18987/
<[reed]> guess I could remove the Canonical partner archive... added it for parallels
<[reed]> hmm
<persia> That's not the issue.  You need to mirror lines 6&7 after line 16.
<[reed]> I know... I'm thinking out loud
<[reed]> :)
<asac> mvo: ^^ for the above (20 lines) ... does apturl add the proper section for -updates as well?
<pwnguin> proper care and maintaince of source.list is vital for smooth operation ^_^
<mvo> asac: generally it does if universe was enabled at the time when apturl was run
<[reed]> pwnguin: and you expect some average user that doesn't know Linux at all to know that? ;) (I'm not an average user by any means, but just thinking of all those users who don't understand this stuff)
<asac> [reed]: i think pwnguin tried to be sarcastic :)
<pwnguin> most "average users" should the software sources tool. which i expect works, but nobody i know uses it
<asac> mvo: you mean "... when -updates was enabled when running apturl" ?
<asac> mvo: just wonder if he ended up in this state when installing icedtea plugin through apturl
<mvo> asac: I haven't seen the apturl line, but if e.g. the sources.list has "hardy universe" and apturl is run with "apturl apt:foo?section=universe" it will not add anything because universe is enabled already.  if it is not in the file, then it will add it and also add -updates
<mvo> hm
<asac> mvo: hmm. ok, worth a bug? e.g. add universe to -updates if hardy-updates line exists already?
<asac> e.g. if user has not opted out of -updates
<mvo> feel free, I'm not sure if we can catch all corner cases, but we can try. was the content of the pastebin manully edited? or only through tools like software-properties/apturl etc
<mvo> ?
<Mirv> asac: yep, no issue
<asac> mvo: at least the dbgsym lines were added manually i guess
<asac> [reed]: did you do any other manual operations on your sources.list?
<[reed]> hmm, probably uncommented stuff over the years
<[reed]> back when I first installed edgy
<[reed]> or dapper?
<[reed]> can't remember
<[reed]> hmm, update manager is offering me more updates now
<[reed]> :)
<[reed]> 33 more updates
<[reed]> and half of these are Firefox-related
<[reed]> 19 / 33 updates are Firefox related, hah
<[reed]> er, 20 of 33.
<asac> [reed]: how did you count that?
<asac> :)
<[reed]> I looked at the changelogs for all 33, plus I know the ones that are related.
<pitti> [reed]: please note that people.ubuntu.com/~ubuntu-archive/ddebs is now called http://ddebs.ubuntu.com/
<pitti> this was announced some months ago on u-devel-announce@
 * [reed] updates
<pecisk> hi people, does FF3 respect /etc/alternatives/mozilla-flashplugin? I have set it to swfdec and removed pluginreg.dat from profile folder but it still gets recreated with Adobe Flash as default swf player, as about:plugins shows
<pecisk> another question is - is this a bug or expected behaviour?
<MacSlow> how do I force the creation of a -dbg package?
<pitti> MacSlow: that needs packaging changes
<gnomefreak> pecisk: it uses xulrunner-plugins
<pitti> MacSlow: however, you can automatically create those -dbgsym packages
<pitti> MacSlow: by installing pkg-create-dbgsym and just building the source package once
<MacSlow> pitti, anything I need to pass to dpkg-buildpackage?
<pitti> MacSlow: no, it's fully automagic
<gnomefreak> pecisk: the exact name is off but look for something like that using 1.9
<pitti> MacSlow: if you need them for an existing ubuntu package, they shuold be on http://ddebs.ubuntu.com
<MacSlow> pitti, no I want to create it for libgksu I'm testing here locally with a patch of my own
<pecisk> gnomefreak: ahhhh so, I see. Well, thanks
<pitti> MacSlow: ah, then a local build will be fine, yes
<gnomefreak> pecisk: np
<Riddell> mvo: you seem to have uploaded a SRU for bug 198292, but you havn't made any comment on that bug
<ubottu> Launchpad bug 198292 in motion "Hardy upgrade - motion halts upgrade" [Medium,Triaged] https://launchpad.net/bugs/198292
<Riddell> leading other people to have created other patches
<mvo> Riddell: let me check
<mvo> Riddell: oh, sorry - yeah, I uploaded it 8 days ago and forgot to mention that in the bug :(
<Riddell> mvo: can you attach your debdiff to the bug, then I'll let it through
<mvo> ogra: could you please have a look at bug #231104 - sounds like a broken edubuntu applications.menu file, do you know anything about this? is it fixed in later versions?
<ubottu> Launchpad bug 231104 in gnome-app-install "Error on attempting to install edubuntu addon: gnome-app-install crashed with IOError in parseFile()" [Undecided,Incomplete] https://launchpad.net/bugs/231104
<mvo> Riddell: sure, give me a sec
<ogra> mvo, checking
<mvo> Riddell: *cough* I think motion was drive-by-fixing on my part, I think I don't have the uploaded bits anymore :/
<mvo> iirc it was a very esay fix, this is why I not bothered too much
<Riddell> mvo: let me jog your memory http://people.ubuntu.com/~jriddell/motion.debdiff :)
<persia> mvo: You could probably reconstruct by downloading from unapproved and hardy, and running debdiff :)
<mvo> Riddell: thanks, I'm updating the bugreport now
<ogra> mvo, i attached the file, but cant find anything wrong in there (and i know tons of people have used it successfully)
<mvo> ogra: thanks, it might be a) bad CD burn b) old CD that contained a bad file
<ogra> yeah, i'd guess so... he doesnt say which app he tried to install though
<mvo> Riddell: updated the bug
<Riddell> mvo: accepted, is it fixed in intrepid?
<Riddell> mm "* Fixed: init script hangs on startup" suggests it is, groovy
<mvo> Riddell: yes, it got fixed in debian
<mvo> Riddell: thanks and sorry for the confusion
<asac> pitti: http://paste.ubuntu.com/19017/
<asac> i think its bug 236115
<ubottu> Launchpad bug 236115 in epiphany-extensions "new upstream 2.22.2 release" [Undecided,In progress] https://launchpad.net/bugs/236115
<asac> wasnt in the RC1 bug
<asac> just copy over?
<pitti> uh, wow, WTF? https://edge.launchpad.net/ubuntu/+source/epiphany-extensions/2.22.2-0ubuntu0.8.04.1 shows it as built for amd64
<asac> pitti: well ... it wasnt build when you copied it :(
<asac> pitti: let me know what i should do ... i can verify that thing for you so you can copy the rest
<pitti> cprov: I think I need your help here
<Riddell> doko: how come ca-certificates-java is marked as contrib?  it seems to depend on stuff in universe only
<pitti> cprov: ubuntu/pool/main/e/epiphany-extensions/epiphany-extensions_2.22.2-0ubuntu0.8.04.1_amd64.deb exists on drescher, and https://edge.launchpad.net/ubuntu/hardy/amd64/epiphany-extensions/2.22.2-0ubuntu0.8.04.1 looks fine as well, but it isn't published in either hardy-proposed nor hardy-updates
<doko> Riddell: ohh, please move it to universe; that was for the debian upload (where the recent upload was done for non-free)
<Riddell> doko: ok, accepted
<sistpoty|work> Riddell: thanks for the xdg-open hint for tk-brief (oh, and dpkg-source tricked me with removing the cvs dir... I'll respin an upload tonight or so)
<cprov> pitti: that version is only published in proposed
<Riddell> sistpoty|work: ok, poke me when it's uploaded
<pitti> cprov: can it be rescued with copy-package to become published in hardy-updates?
<pitti> cprov: ATM it's not even in hardy-proposed's amd64 Packages.gz any more
<pitti> cprov: (or not yet, it just finished building)
<sistpoty|work> Riddell: sure, will do (but I guess it won't happen before 7 or 8 UTC today)
<cprov> pitti: and it will be listed in the index within 5 minutes or so
<cprov> pitti: I meant the source
<cprov> pitti: it's just a matter of waiting, not a bug, right ?
<pitti> cprov-lunch: well, not really a bug, I'm just not sure how to recover from this
<pitti> cprov-lunch: we copied to -updates before the amd64 build was done
<pitti> and deleted from -proposed 4 hours ago
<pitti> and now the build arrived
<pitti> so we don't have any source to copy-package any more
<pitti> just the amd64 binary
<pitti> asac: working on it
<pitti> Keybuk: do you have some time today or tomorrow to discuss https://blueprints.edge.launchpad.net/ubuntu/+spec/gdm-guest-login ?
<Riddell> is there any consensus about what to do with bug 175508 ?
<ubottu> Launchpad bug 175508 in reportbug-ng "Please remove reportbug-ng from Intrepid" [High,Triaged] https://launchpad.net/bugs/175508
<Riddell> bdmurray, ScottK, siretart?
<heno> Riddell: IMO it should be removed until we can make it DTRT
<heno> which is report bugs in LP or deffer to Apport or something
<Keybuk> pitti: sure
<Riddell> heno: what about reportbug?
<Riddell> currently it e-mails ubuntu-users, which seems pointless
<pitti> Keybuk: I wrote an initial braindump now, but I left a big TODO item there, about how to plumb together gdm, that guest session binary, and PAM
<pitti> Keybuk: so I'd like to pick your brain about PAM
<pitti> Keybuk: maybe we can deal with it on tomorrow's phone call?
<heno> Riddell: agreed. It gives an incorrect impression that the issue will be tracked
<Keybuk> pitti: sure
<heno> Riddell: I would advocate removing that too
<pitti> Keybuk: ok, thanks
<siretart> Riddell: my opinon is stated in the bug. I find the tool useful and therefore would vote to keep it
<siretart> Riddell: it might have bugs and be preferable adapted to offer the user a choice to report a bug either to debian or launchpad, but I wouldn't consider that making the package unreleasable
<siretart> Riddell: same applies to reportbug
<siretart> in the end, both packages are in universe for a reason
<ScottK> Riddell: At UDS, James Westby said he'd fix it.
<ScottK> IIRC it's reportbug that mails ubuntu-users.  Reportbug-ng will send stuff to Debian.
<ScottK> Reportbug should definitely NOT be removed.  It's quite useful for reporting bugs to Debian when that's appropriate.
<ScottK> Reportbug-ng just got removed from Testing for being not sufficiently useful, so removing it for now wouldn't be awful.
<ScottK> Riddell:^^^
<Riddell> siretart: how is reportbug useful for debian reporting when it reports to ubuntu-users?
<heno> We should at least coordinate the use of reportbug (if configured to send to Debian) though.
<sistpoty|work> Riddell: it has a -B switch to choose debian's BTS
<heno> Don Armstrong (Debian BTS guy) felt that even bugs in unmodified packages were not self-evidently Debian issues because we run them in an Ubuntu environment with our own configurations
<heno> so the bugs reported from us should at least be tagged clearly as such (are they?)
<siretart> Riddell: by using it with 'reportbug -Bdebian' - at least that's the only way I use it.
<heno> siretart: is it obvious on the Debian end that the bug is from Ubuntu?
<siretart> heno: sort of, it is at the end of the message if the user didn't delete that from the template.
<siretart> heno: the more challenging problem is that most ubuntu users are not aware what happens to their message, read: the have no idea where the report goes to and who is in charge dealing with it.
<sistpoty|work> siretart: by default it actually gets stuck at fiordland anyways ;)
<heno> ok, so we would need to modify reportbug to provide that info
<siretart> sistpoty|work: that's why I configured it in my user config to use /usr/bin/sendmail.
<siretart> heno: even better: make it report to launchpad.
<sistpoty|work> siretart: heh
<heno> what features does it have that apport doesn't?
<heno> as in "apport-cli -f -p PACKAGE"
<siretart> heno: I don't see how apport and reportbug(-ng) relate.
<\sh> siretart: I thought reportbug-ng is past tense for lenny?
<siretart> \sh: I expect it to be fixed in time
<\sh> siretart: let's hope :)
<siretart> heno: reportbug e.g. support package specific hooks for collecting extra data. it respects the Bugs: field of the package, it does not require authentication -- there are so many fundamental differences that I wouldn't even consider comapring it to apport
<heno> siretart: they both collect info to help you file a better bug. Apport supports package hooks as well https://wiki.kubuntu.org/Apport
<heno> they seem to me to have some overlap :)
<heno> though I'm sure there are major differences too
<siretart> heno: which are not the same hooks we already have in debian. so we need to reimplement all those nice hooks in debian pacakge again for ubuntu :/
<siretart> heno: but I think the most important point for this discussion here is: apport cannot be used to report bugs to debian. that's why I stick to reportbug and reportbug-ng
<heno> and I think the question is whether we as Ubuntu should ship a package that does that (or perhaps that should be installed directlt from debian for those who want it) IMO the answer will depend on debian's view on getting bugs from us
<heno> (to the extent there is a "debian's view")
<sistpoty|work> heno: given that reportbug itself doesn't by default report anything to debian, unless you fiddle with command line switches and configuration, I guess it's the risk of bugs reported to the wrong BTS is minimal
<pitti> epiphany-extensions | 2.22.2-0ubuntu0.8.04.1 | hardy-updates | source, amd64, i386, lpia, powerpc
<pitti> asac: ^
<pitti> lool: ^ as well
<heno> sistpoty|work: true, but the default configuration is definitely bad :)
<sistpoty|work> heno: heh, yeah :)
<siretart> heno: it may be buggy. but still not a reason to remove it, IMO.
 * asac hugs pitti 
<heno> siretart: ok, I don't have strong feelings about it; if it has a use case and is otherwise used carefully, and isn't causing annoyance in debian then I'm not worried
<ScottK> The bigger problem is reportbug-ng that does report bugs to debian by default even though it's supposed to know better.
<Keybuk> Finally, Stallman suggested keeping Oyster cards in aluminium foil when they aren't actually being scanned for travel, to prevent them being scanned secretly.
<Keybuk> assuming he has spare foil left over from his hat
<Hobbsee> oyster cards?
<Hobbsee> ah, transport card.
<mvo> pitti: how can I force a retrace of bug #205797 ?
<ubottu> Launchpad bug 205797 in gnome-app-install "gnome-app-install crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/205797
<pitti> mvo: re-tag it with need-retrace-i386
<pitti> mvo: but the retracers are down ATM
<pitti> still on my TODO list
<mvo> thanks, I added it now
<Keybuk> pitti: did you merge devmapper?
<pitti> Keybuk: yes, last week or so
<Keybuk> pitti: you can have #238793 then :p
<pitti> argh, TIL stickyness?
<Keybuk> no
<ogra> _MMA_, ping
<Keybuk> part of the export patch appears to be missing
<pitti> Keybuk: ok, I'll have a look; sorry
<_MMA_> ogra: Hello sir.
<ogra> _MMA_, hey, i was wondering what you think about the idea to pull in ubuntoon into edubuntu in intrepid :)
<ogra> i see it isnt in the archive yet
<_MMA_> ogra: Sure. I had meant to talk to you in Prague about it. Lemmie give it a update this week (most likely tomorrow) and Ill ping you when done. Sound cool?
<ogra> _MMA_, absolutely, no hurry artwork deadline is still far out (and i ted to ignore it slightly in edubuntu anyway :) )
<ogra> *tend
<_MMA_> ogra: Cool.
<lool> pitti: Cool, thanks
<lool> pitti: Could you check gcc-defaults/lpia too?
<lool> It seems to be there for amd64 and i386
<pitti>        gcj | 4:4.2.3-1ubuntu6 | hardy-updates | amd64, hppa, i386, ia64, lpia, powerpc, sparc
<pitti> lool: really? it's fine on drescher
<lool> pitti: How do you do that madison on all arches?
<lool> or dak ls :)
<pitti> lool: that's madison-lite on drescher
<pitti> which uses the actual archive's Packages.gz
<StevenK> Which rmadision hooks into
 * lool doesn't have drescher access unfortunately
<pitti> rmadison does not have ports
<StevenK> lool: ^
<StevenK> Oh
<StevenK> Pity
<lool> I'm using rmadison a lot, I wish there would be a ports' cgi too
<lool> pitti: Aha, my script thought gcc was missing because I didn't know how to retrieve the Source version of a binary package when it's different from the source, so I was looking at any binary from this source with this version; there was none for gcc-defaults, but I now have an example to get the source version of a binar
<lool> y
<lool> pitti: (Source: gcc-defaults (1.62ubuntu6))
<lool> I'll update my script now that I have proper sample data
<lool> Hmm I see rmadison has a flag to filter which architecture to output; I guess we could simply add support for it in the ubuntu madison cgi
<pitti> asac: oh, ffox rc2 changes abi again? I. e. everything needs a rebuild again?
<asac> pitti: who said that?
<pitti> asac: you created tasks for all of the reverse dependencies for the "RC2 update" bug
<asac> pitti: those are investigation bugs. most are already invalid
<pitti> oh, ok
<asac> pitti: e.g. check for regressions (besides ABI/API which should be ok)
<asac> pitti: most likely just firefox-3.0 and xulrunner-1.9 ... and even those were uploaded with lax dependencies
<geser> pitti: can you please remove libversion-perl from the NEW queue? I didn't catch that it got removed from intrepid. Thanks.
<pitti> geser: done
 * pitti yays -- finally a fully DKMSified, packaged, and working dvb-T driver for hardy
<ogra> pitti, oh, really ? i didnt see the kernel fix in any changelogs
<pitti> ogra: no, in my PPA; I just blogged about it
<ogra> ah
<geser> kirkland: hi, are you aware that select-editor doesn't write ~/.selected_editor if only one exists and sensible-editor fails to source that file and fails
<superm1> pitti, after you get some reports on it, perhaps would you get it into hardy-backports for wider adoption?
<pitti> superm1: hm, maybe
<pitti> I didn't actually plan to upload it into intrepid, though
<pitti> since that would mean I officially have to maintain it for very long :)
<kirkland> geser: please clarify....
<superm1> ah right :)
<geser> kirkland: when I try to call sensible-editor in my intrepid chroot I get: .: 17: Can't open /home/michael/.selected_editor
<pitti> superm1: once jockey gets supoprt for an online driver db, I'd rather link it in the db and keep the driver in a ppa
<kirkland> geser: does /home/michael exist?
<geser> kirkland: sure
<geser> kirkland: this only happens when VISUAL and EDITOR are unset
<kirkland> geser: right, that's the case where select-editor should kick in
<kirkland> geser: let me understand why it can't write that file, though
<kirkland> geser: what user is executing it?
<kirkland> geser: and would that user not have write access to /home/michael/.selected_editor ?
<geser> kirkland: looking at the code of select-editor it calls "update-alternatives --list editor | wc -l" which gives 1 for me and skips the next if where that file is created
<kirkland> geser: ah, good catch
<kirkland> geser: hey, i've got a fix...  can you open a bug in launchpad against debianutils?  i'll attach a debdiff and get it sponsored asap.  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/debianutils
<kirkland> geser: nevermind, i filed one: https://bugs.edge.launchpad.net/ubuntu/+source/debianutils/+bug/238879
<ubottu> Launchpad bug 238879 in debianutils "sensible-editor fails when there is only one alternative" [Undecided,New]
 * pitti tosses bug 237317 back to lool
<ubottu> Launchpad bug 237317 in cupsys "/usr/share/doc/libcupsys2/changelog.gz: broken symbolic link to `../libcupsys2/changelog.gz' " [High,Incomplete] https://launchpad.net/bugs/237317
<kirkland> geser: debdiff attached.  you can apply the patch locally against /usr/bin/select-editor if you like
<kirkland> kees: hopefully you can sponsor the fix for https://bugs.edge.launchpad.net/ubuntu/+source/debianutils/+bug/238879 when you get in
<ubottu> Launchpad bug 238879 in debianutils "sensible-editor fails when there is only one alternative" [Low,Confirmed]
<asac> pitti: do you have cycles to let xul + ffox into -proposed today?
<geser> kirkland: I've tested the patch and can confirm that it fixes the issue. Thanks.
<kirkland> geser: excellent, wanna note that in the bug?  might help accelerate sponsorship.....
<pitti> asac: I need to run out in 5 minutes, but I'll touch it now
<geser> kirkland: done
<kirkland> geser: thx
<kirkland> pitti: can you sync the -46 version of ecryptfs-utils in Debian to Intrepid?
<asac> pitti: thanks so much.
<pitti> kirkland: will happen during autosync, will do tomorrow morning
<pitti> kirkland: (sorry, need to run out soon)
<kirkland> pitti: good enough for me
<kirkland> pitti: thanks
<tseliot> pitti: email sent. The links are there.
<bdmurray> Riddell: While I'm a bit late and haven't read the whole discussion I think it is worth keeping too
<Riddell> bdmurray: I think I'll just leave it and hope someone else sorts it :)
<bdmurray> heh
<lool> MacSlow: Hey, cairo-clock Recommends compiz: is this really needed?
<Riddell> tkamppeter: are you able to merge cups-pdf sometime?  I'm down for it as the last uploader but I think you are a better person to merge it with Debian
<tkamppeter> Riddell, OK, I can do so.
<MacSlow> lool, well a compositor... that can be either compiz or metacity (with an enabled compositor)
<lool> MacSlow: It seems that even without compositor, it will work, just wont be transparent, right?
<MacSlow> lool, but since one cannot put "metacity (with enabled compositor)" in the control file I chose compiz
<lool> MacSlow: We're pulling cairo-clock in UME now, I'd rather not pull compiz though; perhaps this should simply be covered in the doc -- compiz is the default in Ubuntu anyway, no?
<MacSlow> lool, no I intercept that and present the user an error-message.
<lool> Oh, so it's handled at runtime already
<lool> Not sure we need to have a dep then
<MacSlow> lool, of course... that's why I used "recommends" and not "depends"
<lool> agoliveira told me it works on his laptop with compositing enabled and not running compiz
<MacSlow> lool, but I thought that's what the field "recommends" was meant for
<Riddell> tkamppeter: thanks
<lool> MacSlow: As you were saying, it's quite an imprecise way of saying "anything providing compositing"; we could use virtual packages for this, but it would be a bit heavy
<lool> MacSlow: I think in your case you want a Depends on a compositor
<lool> MacSlow: But as there's no virtual provide for this, and it's per user anyway -- or even per session -- I'm not sure you want to reflect in the dependencies
<MacSlow> lool, gee... I won't be the one introducing stuff like that :) I'm not enough of a MOTU to forsee all the implication such a suggestion could have.
<ogra> just move Recommends: compiz to Suggests: compiz
<lool> Yes, that's what I wanted to offer
<lool> MacSlow: Would you mind if I downgraded to suggests in intrepid?
<lool> Or removed the dep entirely, perhaps adding a README in the package?
<ogra> that way even openbox users with xcompmgr can use it without cluttering their disk wih compiz
<MacSlow> lool, np
<ogra> i think a suggests is fine ... i'd make it even Suggests: compiz | xcompmgr
<MacSlow> lool, btw... xcompmgr works too with cairo-clock... at least last time (some months ago) I tested it
<lool> MacSlow: Ack; thanks for discussion
<MacSlow> lool, you're welcome
 * Hobbsee wonders when the apt transition will complete
 * lool suggests Hobbsee to stare at cairo-clock until the transition completes
<Hobbsee> lool: heh.  i do like that clock
<ogra> heh
<Hobbsee> lool: but we are supposed to have an alpha release this week, so having stuff installable is probably a reasonable expectation?
<Hobbsee> at least, that's what the schedule says
<lool> Hobbsee: Who needs APT anyway?  ar ought to be enough for end users
<Hobbsee> lool: heh.
<Hobbsee> lool: sure, but this is not 1990.
<laga> pitti: good job on the v4l-dvb package. i've been meaning to do that for mythbuntu for a long time
<mkrufky> i noticed that
<mkrufky> wont it break out of tree drivers?
<laga> in what way?
<mkrufky> err...  it _will_ break out of tree v4l/dvb drivers
<mkrufky> replacing videodev by a new videodev, where modules in l-u-m depend on the kernel provided videodev
<mkrufky> i have a fix for that, actually :-)
<mkrufky> but its not fully backwards compatable
<laga> yeah, i was just looking at l-u-m
<laga> it'd be nice if l-u-m also used dkms.
<mkrufky> yeah, anty media driver in l-u-m would get broken
<mkrufky> if he changed his dkms build to -not- replace videodev, that would do it......  although it would only go back so many kernel versions
<mkrufky> ...same applies to dvb-core, if there are any out of tree dvb devices in l-u-m
<laga> mkrufky: do you know the state of the multiproto api?
<mkrufky> it's not in kernel
<mkrufky> and never will be
<mkrufky> the author chose to fork and refuses any merge attempts
<mkrufky> dont bother supporting it
<mario_limonciell> laga, dkms shouldn't necessarily be used for everything in lum, but this model for updated drivers and binary drivers only is a good idea.
<laga> it's a bit hard not to support it (in the future) as it's the only way to use DVB-S2.
<laga> AFAIK
<laga> mario_limonciell: well, l-u-m still should provide binaries, of course, but it'd also be nice if it didn't break if someone compiles their own kernel.
<laga> granted, it's easy to rebuild.
<mario_limonciell> the problem with putting dkms on too much stuff is that you end up having to have a build chain to build it when it needs to be used
<mario_limonciell> and then you add extra delay to postinst when you build stuff
<mario_limonciell> or during the next boot if you build it there
<laga> thats why we have prebuilt modules for people who use the stock kernel. :)
<laga> anyways, that discussion is probably fruitless. :)
<mkrufky> laga: im only saying that userspace trying to support the multiproto api might be a wasted effort when the developer is unwilling to merge, and another developer is working on a better solution
<laga> mkrufky: oh? got a keyword for me to throw at google?
<mkrufky> mario_limonciell: i been trying to find you
<mkrufky> change your nick much?
<mkrufky> no, laga
<mkrufky> all i can say is that we wont be held up by developers that dont play nice
<mkrufky> at least, not forever
<laga> mkrufky: so i guess you won't have an ETA either (for me). i'm moving soon and i'll have a dish there ;)
<mkrufky> i dont involve myself with dvb-s at all -- ur asking the wrong guy
<mkrufky> im just saying not to waste your time writing userspace software for a dead api
<laga> mkrufky: alright, thanks!
<mkrufky> then again, there's no telling when a real api will come
<mkrufky> others are already working on temporary solutions
 * lamont wonders which lib defines ap_get_token
<mario_limonciell> mkrufky, while i'm at work I use this nick, when i'm home i use superm1
<pitti> lamont: \o/
<pitti> laga: \o/
<pitti> lamont: sorry, ETAB
<lamont> pitti: heh
<ion_> pici: Heh
<Pici> heh, oh wait.
<\sh> pitti: which dvb-t stick do you have? which usb id i mean? ending with :5070 some sort of?
<pitti> \sh: 7070 is the product ID
 * pitti finds it and plugs in
<\sh> pitti: or that...yes...that's why I have too :)
<pitti> \sh: standard 29 EUR WinTV Nova-T stick
<\sh> pitti: yepp :)
<pitti> Bus 003 Device 004: ID 2040:7070 Hauppauge
<\sh> pitti: that's the same :)
<\sh> one of the newer ones which only works with newer linux-dvb drivers...hehe :) what a conincidence :)
<mkrufky> (supported)
<\sh> mkrufky: but not in hardy :)
<mkrufky> no new cards are _ever_ supported in a distro
<mkrufky> http://linuxtv.org/repo for howto, or use pitti's dkms package
<\sh> mkrufky: you can't check beforehand..the stick is supported with older prod ids..
<mkrufky> never, i said \sh
<mkrufky> mario_limonciell: / superm1: whenever you're around, plz ping me
<mario_limonciell> mkrufky, i've got about 15 minutes right now
<mario_limonciell> pm?
<mkrufky> k
<\sh> pitti: i'll test it tomorrow in the office..there's the stick laying, wanted to use it for watching the EM during work time ;)
<emgent> heya people
<Cliph> Having a problem with a one of my meta dpkgs, is this a good place to get some help?
<Cliph> or should I go to -motu?
<Cliph> I have output and pastebins ready
<sistpoty> Riddell: tk-brief uploaded to hardy-proposed again (with the xdg-open change, works like a charm, thanks!)
<sistpoty> Riddell: oh, and of course I've also uploaded it to intrepid beforehand
<Riddell> sistpoty: accepted
<sistpoty> Riddell: thanks a lot!
<rubikcube> hmm, I had thought that I had fulfilled everything in the original post already... what do you think? https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/238634
<ubottu> Launchpad bug 238634 in language-selector "gimp (or any other gnome app) should pull in the respective language-pack-gnome-*" [Undecided,Incomplete]
#ubuntu-devel 2008-06-11
<TheMuso> crimsun: Is the alsa-driver merge/bzr branch in an uploadable state?
<lifeless> ~
<superm1> slangasek, how come the current 8.04.1 dailies aren't including the latest kernel images?
<superm1> (I've got some hardware that will only boot on the later kernels)
<slangasek> superm1: where "dailies" == "live CD", I assume?
<slangasek> if so, it's because the livecd build scripts regressed since the last dapper point release; should be resolved with tomorrow's dailies, but I'm still waiting for confirmation from the buildd end that everything's sorted
<persia> Are there 8.10 dailies yet?  (with the expectation that they usually fail)
<slangasek> of a sort; e.g., http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/xubuntu/latest/livecd-20080610-i386.out
<superm1> slangasek, yeah dailies == live cd.
<persia> Oh excellent.  Thanks!
<crimsun> TheMuso: yes.
<TheMuso> crimsun: Did you want it uploaded any time soon, or do you have more to do on it?
<mneptok> persia: there's no libc, but that shouldn't matter much.
<crimsun> TheMuso: it's fine as is; I no longer have commit access to that branch anyhow.  I'll be making further changes in my own.
<persia> mneptok: I wasn't looking for something that worked, only something to understand where we were.  Now I know.
<TheMuso> crimsun: Oh right.
<mneptok> persia: you sound like the Vista release manager
<mneptok> (all apologies to slangasek)
<persia> mneptok: My possible resemblance to such mythical creatures is one of the many reasons I'm not part of the release team :)
<TheMuso> crimsun: Ok, so short of something I should wait for, I guess I should get it uploaded then.
<dholbach> good morning
<Hobbsee> dholbach!
<dholbach> hi Hobbsee
<ion_> Hi
<dholbach> hi ion_
<dholbach> hey mvo, hey seb128
<seb128> hello dholbach
<mvo> hey dholbach, hey seb128
<mvo> good monring MacSlow
<MacSlow> mvo, Mahlzeit
<MacSlow> *yawn*
<seb128> hey hey mvo
<MacSlow> yo seb128, dholbach
<seb128> hello MacSlow
<seb128> dholbach: no need to add comments now when you subscribe somebody to a bug, just for information ;-)
<seb128> "You have been subscribed to a public bug by Daniel Holbach (dholbach)"
<seb128> launchpad already send the bug description using that comment
 * pwnguin wonders what Moins means
<Hobbsee> pwnguin: short version of morning?
<Hobbsee> (slang, iirc)
<slangasek> northern German slang for morning
<Hobbsee> oh, so it's german?  right.
<stgraber> morning
<asac> moin moin ;)
<davmor2> asac: adding wiki inference this time in the morning to be banned as bad taste ;)
<asac> haha
<dholbach> hi seb128
<pwnguin> well, i kinda thought it was something like that, but i thought i'd google it
<dholbach> seb128: I scripted that in the meantime - I thought it was friendlier to say "xyz: can you please take a look at it?" :)
<seb128> dholbach: ok, makes sense, that was just in case you had a doubt on whether the launchpad bug was fixed now ;-)
<dholbach> right :)
<dholbach> thanks seb128
 * seb128 hugs dholbach
 * dholbach hugs seb128 back
<\sh> slangasek: the right term in nothern slang (e.g. hamburger platt) is "moin moin"..."moins" means a bit more : "Good morning, dude, how are you this morning?" or in real new world order german slang "hey alder, was geht!" ;)
<pwnguin> man
<pwnguin> "hamburger platt" just makes me hungry for a plate of hamburgers
<\sh> lol
<xnv> Is there a general trick to fix the issue of the dev files not being installed where other dev files expect them to be. For instance, glib.h is installed to ../glib-2.0/glib.h, but when I source a library that depends on it, it's expecting it in ../glib.h.
<\sh> xnv: setting correct -I lines ... I though glib worked via pkgconfig...so when you use pkgconfig it should catch the right include dir
<xnv> \sh: In this case I'm using gsf and virtually all source code I find uses #include <gsf/gsf.h>. However, that's file not found for me.
<xnv> \sh: Adding -lgsf doesn't fix that
<\sh> -I <-- I as in INCLUDE ;)
<\sh> not -l as in library ;)
<xnv> \sh: Oh, so I need to do -I/usr/include/whatever for every dependency?
<siretart> xnv: try `pkg-config --cflags glib-2.0`
<xnv> siretart: So I have to use all of those?
<\sh> xnv: libgsf-1-dev installs a /usr/lib/pkgconfig/libgsf-1.pc which is used by pkgconfig...so if you use pkgconfig (example was given by siretart) you should always catch the correct include paths, library paths etc.
<siretart> at least if upstream didn't make a mistake here (which happens from time to time)
<xnv> OK, it compiles. Thanks guys. I guess I just wasn't expecting my compile command to be longer than the code itself. :-)
<siretart> xnv: your compile command doesn't need to be longer. just calculate your CFLAGS correctly in the makefile
<xnv> siretart: Hehe, I know. This was a simple enough test that I didn't bother with the makefile though. :-)
<xnv> Guess that was a bad idea
<siretart> "gcc `pkg-config --cflags --libs libgsf-1` foo.c " should do it as well. which is rather short as well
<pitti> Good morning
<seb128> hey hey pitti
<pitti> seb128: Bonjour, Monsieur? Comment vas-tu? (was that right?)
<Hobbsee> pitti!
<Keybuk> is "unbekannt" German for "unknown" ?
<siretart> indeed
<pitti> Keybuk: yes
<Keybuk> aha
<Keybuk> that explains it then
<Keybuk> according to aki-aki, someone with the profile name "unbekannt" followed me all the way from the station to Millbank ;)  but if it's just what it calls unknown people ... I need not get paranoid :p
<seb128> pitti: bien merci, et toi? ;-) (oui c'est correct)
<pitti> seb128: moi bien!
<tjaalton> oo.o-voikko needs to be rebuilt for hardy-proposed, since currently h-p is unusable for Finns (would delete packages). what versioning should be used, just increment buildN?
<pitti> Keybuk: ah, Mr. Arno Nym?
<pitti> tjaalton: it's currently build2, thus build3 is fine
<tjaalton> pitti: roger, so ok for me to upload?
<Keybuk> pitti: Arno Nym?
<slangasek> moi, je vais ainsi: <dance>
<pitti> tjaalton: sure, go ahead; please open a SRU bug and include it in the changelog, thogh (for testing feedback)
<tjaalton> pitti: there alread is bug 236248, is that enough?
<ubottu> Launchpad bug 236248 in openoffice.org-voikko "Rebuild openoffice.org-voikko for the 2.4.1 upload of openoffice.org" [High,Confirmed] https://launchpad.net/bugs/236248
<pitti> Keybuk: common malapropism for "anonym" that looks like a real name
<pitti> tjaalton: yes, that's fine
<tjaalton> pitti: cool, thanks
<pitti> tjaalton: as long as the source.changes has a referenced LP: #1234, all is well
<pitti> I'm just strict with rejecting SRUs with no bug # at all
<laga> heh. i noticed. :)
<Keybuk> pitti: Ah. Mr A. Nonymous
<tjaalton> pitti: sounds reasonable. uploaded
<\sh> pitti: shame...that my stupid pc here doesn't have an usable usb 2.0 port for the dvb-t stick :(
<ogra> Keybuk, are you sure that wasnt RMS with his foiled oyster card so he couldnt be identified ?
<pitti> TheMuso, \sh, ScottK, DktrKranz: (CC: tseliot): can you please have a look at bug 239115? WDYT about similar updates in the future?
<ubottu> Launchpad bug 239115 in linux-restricted-modules-envy-2.6.24 "The NVIDIA driver in the lrm-envy doesn't support Geforce 9xxx" [Undecided,In progress] https://launchpad.net/bugs/239115
<\sh> pitti: Added preliminary support for X.Org server 1.5. if it's giving us no regression in hardy, fine with me...
<pitti> tseliot: ^ ?
<DktrKranz> ... and given that we want to support new hardware in LTS releases, I guess it's ok
<tseliot> ok, great
<tseliot> ï»¿pitti: anything you would like me to add?
<tseliot> on this topic, I mean
<pitti> tseliot: fine for me now
<tseliot> ï»¿\sh: no regressions here ;)
<\sh> tseliot: ok :) I can't test it, no nvidia here :)
<tseliot> ok then
<\sh> actually, I trust pitti a lot in this case...he worked with alberto to push this thingy in...when I remember correctly
 * \sh kicks pykde4
<tseliot> ï»¿\sh: right ;)
<\sh> tseliot: ah...;) now I got your nick <-> name right ;)
<\sh> tseliot: btw...good work :)
<tseliot> ï»¿\sh: thanks. The best is yet to come on Intrepid though :-)
<\sh> tseliot: yeah...fix ATI !
<tseliot> \sh: that's a task which I will leave to superm1 aka mariolimonciell. I will maintain the Nvidia driver only (together with tjaalton)
<tseliot> this is for Intrepid though.
<tseliot> I'll deal with the ATI driver on Hardy through envyng.
<tseliot> \sh: ATI users won't be left alone ;)
<pitti> tseliot: huh, why did it land in NEW>..
<tseliot> pitti: ???
<pitti> tseliot: ooh, I see
<pitti> tseliot: because it's NEW in hardy-proposed
<pitti> it isn't in hardy final
<tseliot> ok then
<dholbach> hi thekorn
<thekorn> hi dholbach
<Laney> Good morning everyone
<Mez> BenC, do you know if there's a fix anywhere in ubuntu for the "adjust brightness hardlocks laptop when using intel chipset for video"
<ScottK> Mez: Do you have a bug?  I've got intel chipset and have never had that problem.
<Mez> ScottK, it's somewhere in the bug tracker... only started happening with me yesterday. Replaced machine - same thing again.
<Mez> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/65027
<ubottu> Launchpad bug 65027 in linux-source-2.6.17 "Notebooks freezes after closing lid or pressing some FN key combination" [Medium,Confirmed]
<Mez> alsi now getting device descriptor read/8 error -110
<ScottK> Ah.  I'm running Hardy, so no wonder.
 * Mez is getting the issue in hardy
 * ogra has never had that prob and uses various different intel chipsets over here 
<ScottK> Mez: Exactly which Intel video?
<ogra> i would blame the broken i810 driver (which shouldnt be used anymore anyway)
<Mez> Intel Mobile GM965/GL960 Integrated Graphics controller rev 3
<Mez> and it's using /usr/lib/xorg/modules/drivers//intel_drv.so
<broonie> I've got what sounds like the same issue with the 945 on Hardy.
<broonie> Worked fine with all the releases up until Hardy.
<ScottK> Hmmm.  I've got 945 and don't seem to have it.
<ScottK> broonie: Which driver are you using?
<ogra> 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
<ogra> same here
 * Mez sighs
<broonie> i810_drv
<ogra> no probs at all since i installed it
<Mez> and for some f**ked up reason... I'm not picking up wireless anymore
<ScottK> broonie: Same here.
<broonie> This is a Dell D420 laptop.
<ScottK> Mine is D430
<wgrant> One really shouldn't be using i810 nowadays...
 * Mez is getting annoyed at these issues. I thought it was a hardware issue... so I wen and replaced the laptop. This is worse, and makes ubuntu unusable.
<broonie> Mine might be a generic resume problem, but it *looks* like video.
<ogra> wgrant, there are circumstances where you cant avoid it ... but i generally agree :)
<ScottK> Of course I see an update to the driver waiting for me in hardy-updates.
<wgrant> ogra: Like?
 * ScottK tries it.
<ScottK> wgrant: One is that i810 supports xinerama, which, unfortunately, is all that displayconfig supports (so in Kubuntu we are stuck with).
<ogra> wgrant, like situations where you need a panning mode instead of multiple display support, i810 still uses old xrandr setup instead of the new one where Virtual is interpreted differently
<wgrant> ScottK: Oh dear. I guess this is where a CLI is useful.
<Hobbsee> ScottK: wfm on hardy, too
<ScottK> wgrant: Yes.
<Hobbsee> er, intrepid
<Hobbsee> same chipset
 * Mez sighs. Mine is not on a resume.. it's ANY time
<wgrant> ogra: I think I heard something about that being on the roadmap for RandR 1.3. Or something like that.
<ScottK> wgrant: That would take me having a display projector and enough time to make sure it works (e.g. not in the middle of a meeting).
<wgrant> Or beating various Kubuntu devs with a stick until they write a RandR 1.2 GUI, I guess.
<ogra> wgrant, wll, last time i touched the issue i was told its mutually exclusive ... you either have multi display or pannong
<ogra> *panning
<ScottK> wgrant: We have one for KDE4.
<wgrant> ScottK: Oh good.
<ScottK> wgrant: Just getting displayconfig not to catch on fire and burn to the ground on a daily basis was a major accomplishment for Hardy.
<wgrant> ScottK: Surely it would have been better and easier to port the GNOME tool to KDE?
<ScottK> wgrant: No.  The gnome tool was written with no consideration of providing a different front end.
<wgrant> ScottK: Ah. Well, I guess that's RandR's job.
<ScottK> JFTR, it wasn't bryce that did it that way either.
 * tseliot thinks that RandR GUIs should be written in Python with a backend which could be shared between KDE and GNOME
<wgrant> What more backend can be shared than RandR itself?
<tseliot> wgrant: writing RandR bindings for Python (RandR is written in C) which could then be used in a Python program that should do most of the work for the 2 GUIs
<ogra> wgrant, a python module that doesnt force you to use exec and system or something similar weird in python sctipts would be a good start :)
<ogra> ah, tseliot beats me :)
<wgrant> ogra: There's no RandR lib?
<ogra> not for python
<tseliot> ogra: not yet ;)
<tseliot> I would like to do it myself in the future
<wgrant> One could always right the frontends in something that isn't Python.
<ScottK> The KDE4 Xrandr tool is not in Python, if that makes you feel any better.
<ogra> if you have one generalized backend used by differen frontends it makes maintenance a lot easier
<ogra> the thing is that python is just convenient for such a setup
<tseliot> ogra: right
<mvo> tseliot: do you know about python-xrandr ? this is a ctypes implementation of xrandr in python
<mvo> tseliot: it only lifes in bzr currently, but its not ideal because xrandr needs a lot of setup code etc
<tseliot> ï»¿mvo: sure, the one made by glatzor and you
<mvo> tseliot: best would be to refactor code in xrandr.c to libxrandr that would hide the nasty bits
<tseliot> mvo: the problem is that I'm still learning C, therefore I don't know when I'll be able to do this
<tseliot> mvo: BTW did you have the time to review my xorg parser?
<mvo> still not :( - but its on my list for this week
<tseliot> ok
<Riddell> jdstrand, kees: any ETA for commenting on the MIRs that pitti asked for an opinion on?
<jdstrand> Riddell: what are the bug numbers?
<Riddell> https://bugs.edge.launchpad.net/ubuntu/+source/openbabel/+bug/236051
<ubottu> Launchpad bug 236051 in openbabel "main inclusion review for openbabel" [Undecided,Incomplete]
<Riddell> https://bugs.edge.launchpad.net/ubuntu/+source/chmlib/+bug/236113
<ubottu> Launchpad bug 236113 in chmlib "main inclusion report for chmlib" [Undecided,Incomplete]
<jdstrand> ok, found them in my mail
<jdstrand> Riddell, kees: I have several things that I need to push out, so I couldn't look at them until next week.
<jdstrand> Riddell: I'm sure kees will respond when he comes online, but we'll coordinate it between us
<Riddell> pitti: any ETA for the newer MIRs?  qca, qscintilla and libzip?
<pitti> would Friday be ok? will do it together with archive bits
<Riddell> not for alpha 1, but I don't suppose that's likely to happen
<pitti> not tomorrow anyway, due to LP outage
<pitti> Riddell: if it's critical for a1, I'll try tomorrow (or you can try to blackmail doko to do it earlier :-P)
<doko> blackmail? depends ...
<Riddell> pitti: no more than the other ones which jdstrand won't be doing in time either
<tseliot> superm1: these dependencies don't seem to be enough for DKMS: make, dkms, linux-libc-dev, linux-headers. It looks like libc6-dev is required too. (this happens to me on Intrepid)
<pitti> tseliot: hm, libc-dev for a kmod?
<pitti> that sounds weird
<tseliot> ï»¿pitti: yes, I can show you the error which I get without that package
<pitti> please, I'm interested
<tseliot> pitti: here's the content of my make.log in /var/lib/dkms/173.14.05/build/ : http://pastebin.ubuntu.com/19344/
<tseliot> ï»¿pitti: DKMS no longer complains after I install libc6-dev
<superm1> tseliot, are you sure it's not just wanting gcc?  It does seem odd that libc6-dev is all that it needs?  When you install libc6-dev, does it grab dependencies too?
<tseliot> ï»¿superm1: gcc is already installed. And no, it doesn't grab any dependency
<superm1> then nvidia's build system must be looking for it for some reason or another i suppose
<superm1> that's a bit unfortunate
<tseliot> ï»¿superm1: one more dependency, I know...
<tseliot> ï»¿superm1: the packages are almost finished, they need some testing. I can send you an email if you want to help testing.
<superm1> well the intrepid CDs weren't generating
<superm1> so testing them ends up a little difficult
<tseliot> ï»¿superm1: they should work on hardy too
<superm1> okay well then go ahead and fire me an email with a PPA to grab them from or similar to mario_limonciello<at>dell.com and i'll give them a shot later today
<tseliot> superm1: ok, I'll do it ASAP
<kees> Riddell: hello!  I don't see it in email, where was it sent?
<kees> jdstrand: you said you found the MIR review requests in your mail?  what're the subjects?
<jdstrand> kees: main inclusion ...
<cjwatson> superm1: intrepid CDs probably won't work yet, generated or not
<jdstrand> kees: they went in my subscribed folder (ie to the folder where ubuntu-security team bug mail goes)
<cjwatson> at least not for installation
<kees> jdstrand: ah, found it in bug email.
<cjwatson> I have some more stuff to upload before that'll be workable
<pitti> tseliot: re; looking
<pitti> tseliot: oh, I see; that's a configure test
<pitti> tseliot: is that really dkms? It looks like the makefile/configure from the driver you are DKMSifying
<tseliot> ï»¿pitti: yes, right
<tseliot> pitti: it's the NVIDIA driver
<superm1> cjwatson, how much do you plan on slipping on the alpha then?
<cjwatson> superm1: don't know at present, it's on the platform team agenda for tonight
<cjwatson> I was unexpectedly off for a week, which didn't help
<superm1> tseliot, what pitti is saying is that you can possibly just compile the kernel modules rather than having to run the whole make/configure
<superm1> cjwatson, ah.  i hope all is well.
<tseliot> ï»¿superm1: mmm...
<kirkland> pitti: did the auto sync with debian happen yet?
<pitti> kirkland: I actually did a run this morning, but it seems that ftp.uk. is out of date
<kirkland> pitti: i could use a sync of ecryptfs-utils
<pitti> kirkland: I'll do a manual sync then, if it's urgent (download Debian pacakge and dput it)
<kirkland> pitti: i don't have upload priv's....  where would I dput it?  REVU?
<pitti> kirkland: I'll do it, don't worry
<kirkland> pitti: okay, just for clarification, where were you suggesting I dput it?
<pitti> kirkland: no, I said I'll do a manual sync
<pitti> kirkland: sorry for the delay; I usually don't pay too much attention to which apcakges are autosynced
<kirkland> pitti: okay, thanks, sorry to nag
<pitti> kirkland: ok, fake-synced
<kirkland> pitti: thanks.
<tjaalton> pitti: hey, I noticed your post about vdr. aren't the packages in hardy fresh enough?-)
<pitti> tjaalton: haven't tried them myself TBH; admittedly it was just hearsay
<tjaalton> hardy has the latest stable version, and maintaining the devel-series is a pain since the ABI keeps changing, and plugins should be rebuilt every time that happens (basically for every upstream devel-release)
<tjaalton> e-tobi does have a lot of plugins, and I used to use it for my setup, but most of the plugins are pretty bad or dead
<tjaalton> so for hardy we (Ng and me) decided to pull some of the more useful ones that debian didn't have
<tjaalton> pitti: anyway, he's more than welcome to join the team ;)
<DktrKranz> any sponsor for main around to review bug 226783?
<ubottu> Launchpad bug 226783 in scons "Merge scons 0.98.5-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/226783
<luisbg> is there a way to see all the tree of dependencies a package has? like what you can see as dependencies in packages.ubuntu.com, but with also the dependencies of the dependencies
<pitti> kirkland: hm, it FTBFSed
<pitti> kirkland: ah, bug in libopencryptoki-dev
<luisbg> sorry for the above question, should be asked in  #-motu, will talk about it there
<_Schattenboxer_> hi
<_Schattenboxer_>   wie gehts euch  spackos
<_Schattenboxer_>    ihr hurensÃ¶hne
<_Schattenboxer_>   hr scheis penners
<_Schattenboxer_> i
<ogra> Hobbsee, ?
<_Schattenboxer_>   auslÃ¤nder
<_Schattenboxer_>  kanacken seid ihr
<_Schattenboxer_>   sches  auslÃ¤nder ausrotten muss man euch
<\sh> it's nice that he's annoyed...looks like he needs ubuntu in general...
<sistpoty|work> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<jpds> Hobbsee: ^
<ogra> sistpoty|work, well, i didnt want to go that far :)
<sistpoty|work> ogra: heh, sorry... but ubotu is so convenient there :)
<ogra> yeah
<kirkland> pitti: okay, cool, thanks for trying, i'll have a look
 * cjwatson attempts to produce a busybox merge that actually lets the system boot
<zul> slangasek: ping
<james_w> kees: hi. I'm trying to prepare a fix for insight, but it doesn't build on intrepid, due to the embedded copy of gdb not compiling with "-D_FORTIFY_SOURCE=2" (I assume)
<james_w> kees: looking in the CVS of gdb the unchecked fgets line is still present, so I'm wondering how gdb itself builds on intrepid.
<rubikcube> hi, any idea with respect to which point I wasn't specific enough here? https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/238634
<ubottu> Launchpad bug 238634 in language-selector "gimp (or any other gnome app) should pull in the respective language-pack-gnome-*" [Undecided,Incomplete]
<Kopfgeldjaeger> what's a good way using gettext with python? at the moment i compile the files by hand, but i guess i can do that with a debian/rules file
<kees> james_w: embedded gdb!?
<kees> james_w: that should be removed, I imagine.
<james_w> kees: yup, fraid so.
<kees> james_w: as for gdb, it probably doesn't -- I bet it was built before the options went in.
<kees> james_w: can you rip gdb out of the insight builds?  that's gross.  :P
<james_w> kees: ah, sorry, I got confused by lp, they updates in intrepid were pocket copies from hardy-updates
<persia> rubikcube: You'd get a better response to queries about bugs in #ubuntu-bugs.
<rubikcube> persia: thanks, didn't know about that channel... *quick check* hmm, shouldv've read /topic till the end :-)
<james_w> kees: I'd rather not, I just wanted to do an SRU for a simple debian/rules fix. I'm not even sure why it wants to embed it.
<kees> james_w: SRU? in that case you're compiling under hardy though, right?
<james_w> yeah, but the rules state that it should be fixed in Intrepid first.
<kees> james_w: oooh, right yes yes.
<ScottK> It doesn't need to be an identical fix though.  You can rip apart then intrepid package all you need to and then just use the minimal change for the SRU.
<persia> The goal of the rule is only to make sure that we don't leave a bug unfixed when doing an SRU.  Alternate solutions are encouraged for a wide variety of special classes of bugs.
<pitti> seb128: is intrepid a good time to get rid of scrollkeeper? scrollkeeper-update is mad...
<laga> will intrepid be using upstart more, eg for gdm?
<pitti> seb128: also, I suppose bug 214903 is fixed in intrepid?
<ubottu> Launchpad bug 214903 in gnome-games "Aisleriot regression for double-clicking stacks" [Low,Fix committed] https://launchpad.net/bugs/214903
<ramvi> Hi, what file do I change to change the default applets in the gnome panel when creating a new user?
<pwnguin> wait, we can get rid of scrollkeeper?
<pitti> pwnguin: I thought rarian was the successor?
<pwnguin> ive no idea
<pwnguin> but i like the idea of no more scrollkeeper-update
<ramvi> ï»¿ï»¿Hi, what file do I change to change the default applets in the gnome panel when creating a new user?
<emgent> heya
<seb128> pitti: yes and yes
<Mithrandir> is it just for me that in current hardy (with updates and all), opening firefox always open the "welcome to ubuntu" page, in addition to the saved pages?
<lukehasnoname> echo "hello"
<calc> can someone process ooo and ooo-l10n for hardy-proposed (when it shows up) in a few min
<psypointer> good evening
<psypointer> https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/238974 is the problem which causes this bug already known? this bug causes massive problems when installing via pxe + preseedfile.
<ubottu> Launchpad bug 238974 in ntfs-3g "Netboot install fails with "Failed to load installer component - Loading libntfs-3g23-udeb failed for unknown reasons. Aborting."" [Undecided,New]
<psypointer> or is there any way to fix it by myself
<cjwatson> psypointer: known and should be fixed in hardy-proposed; use the hardy-proposed images
<cjwatson> http://archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/installer-i386/current/ etc.
<cjwatson> it's basically bug 234486
<ubottu> Launchpad bug 234486 in net-retriever "failed for unknown reasons" [High,Fix committed] https://launchpad.net/bugs/234486
<calc> ok ooo/ooo-l10n is waiting for approval now
<calc> also whoever has access please pocket copy(?) that to intrepid as well
 * calc thinks that is the correct term
<psypointer> cjwatson: oh, i'll try the new installer
<psypointer> thank you !
<cjwatson> psypointer: it's not actually ntfs-3g's fault, FWIW - that's just the current thing that happens to blow up
<cjwatson> so just trying to exclude ntfs-3g might well not help anyway :)
<psypointer> cjwatson: hm okay, good to know..
<cjwatson> I've posted a similar note on the forums
<psypointer> great, this will reduce the stresslevel of the other sys admins :) thanks!
<xivulon> Mithrandir, hi
 * Nafallo tickles Mithrandir 
<xivulon> Mithrandir, one of your comments was reported in 230703,
<xivulon> is there any plan to fix hibernation?
<Mithrandir> to fix hibernation for casper?
<xivulon> the issue being that if the initrd mounts a journaled filesystem that was hibernated, once the system resumes from hibernation you get fs corruption
<xivulon> I am concerned that there are a few of those situations in place already
<xivulon> other than 230703 (which was reverted)
<cjwatson> xivulon: please take that to bug 41624, where I have commented
<ubottu> Launchpad bug 41624 in partman-basicfilesystems "Replaying journals of other OS's filesystems, by mounting them, is unsafe" [High,Fix released] https://launchpad.net/bugs/41624
<xivulon> cjwatson, thanks, will do that
<xivulon> was only wondering if that could be fixed somehow when resuming hibernation rather than preventing other packages from mounting fs
<cjwatson> no, it can't
<Mithrandir> ideally the fs should have a revision counter of sorts and the hibernation should check the revision counter has not changed when resuming.
<cjwatson> there's still potential for data loss there surely
<Mithrandir> which would give you some sort of data loss, but if you're already in that situation, it's better than resuming and blasting the fs more or less out of existence.
<cjwatson> we can't fix all the other systems in question, though
<cjwatson> trivially, Windows
<Mithrandir> true.
<cjwatson> still potential for data loss> e.g. open applications with unsaved data
<Mithrandir> it's in no way a replacement for not replaying journals of hibernated file systems.  It's a recovery mechanism when that has already happened.
<ion_> Perhaps each OS (that we can control) should write a per-installation UUID to mounted partitions to say âi have mounted thisâ and remove it when umounting. Mount could then refuse to write anything to partitions it thinks are mounted by another OS, that is, mount readonly, not replay the journal.
<ion_> Someone could even write a program for WindowsÂ® that writes such a thing to the filesystems, without needing to modify the actual OS. :-P
<ion_> Although what WindowsÂ® decides to mount might not be that easy to control.
<FabParma> [OT] Does exist a VM/CPU-emulator that can let chooses which cpu (amd or intel) to use into the guest enviroment w/o ties with host hw config? Thank You for help me, Fab
<lukehasnoname> fabparma, check #ubuntu-server
<lukehasnoname> they might know
<lukehasnoname> and it would be on topic there
<[cliff]> hi all
<[cliff]> I just got home to find out my laptop didn't suspend properly if I remove an USB drive while it's suspending to ram. end result, the bloody machine was carried inside a bag for more than an hour at full throttle. how can I debug this crap so that it doesn't happen again? I'm running hardy (which I refuse to call LTS given the amount of trouble I've had with it)
<[cliff]> last useful message in logs is: Jun 11 19:42:00 starfish gnome-power-manager: (cpinto) Suspending computer. Reason: The suspend button has been pressed.
<brandon|work> It is still LTS, the amount of trouble you have doesn't dictate the length of support time :-/
<brandon|work> and what kind of laptop is it?
<[cliff]> brandon|work that's a good point, but it isn't as stable as an LTS should be (my perspective) and I've been using it since 4.10
<[cliff]> hp dv1245
<calc> slangasek: can you approve the 2.4.1 upload?
<stgraber> [cliff]: always depend on the hardware ... I didn't have any single crash on my lappy since Hardy Beta, my uptime is only reset when I upgrade the kernel
<slangasek> calc: I rather want to get the current package in -proposed copied to -updates first, if possible...
<stgraber> so you can't really say if a release is stable or not, it will always be for some people and won't for others
<[cliff]> i'm really open to whatever suggestions you may have. if there's a kernel param I need to set, let me know. if it's an acpi tweak, please tell. what I don't want is for the laptop to blow my back to smithereens :-)
<brandon|work> [cliff], have you tried booting with the acpi=off option?
<[cliff]> stgraber, yeah, I miss those days too :-) I once had an uptime of 2+months with this very same hardware
<Mithrandir> brandon|work: that's hardly a solution for a laptop.
<Mithrandir> [cliff]: I'd start by not pulling out hardware while the system is suspending or resuming. :-P
<brandon|work> worked with mine for 6.10
<stgraber> you said "if I remove an USB drive while it's suspending", what about just not doing that ?
<[cliff]> brandon|work no, not really, but I'm giving it a shot
<[cliff]> Mithrandir why not fix the software problem instead so that no one else gets to hear of it? :-)
<stgraber> removing devices when drivers are unloaded or suspended is clearly not a good idea and I'd expect that to crash ...
<calc> slangasek: ok
<[cliff]> brandon|work any more suggestions? I'm taking notes so I'll try all of them
<calc> slangasek: how do we go about doing that?
<[cliff]> brb
<slangasek> calc: hmm, maybe I should think twice about that, though, since that means double the bandwidth from users grabbing -updates
<calc> slangasek: fwiw the 2.4.1-1ubuntu1 is the same as rc2 except for a few changes in ooo-build
<stgraber> we can't lock your USB drive in the socket while the driver is being unloaded, so the kernel panic / oops / ... makes sense to me and the user should just not change their hardware configuration when suspending (I wouldn't do that with any OS actually)
<calc> slangasek: they just renamed rc2 to 2.4.1 final since there were no new blockers found
<slangasek> calc: ok, I'll have a look at whether that's reasonable to feed into -proposed then, thanks
<[cliff]> stgraber, I'm here for solutions mate, not workarounds
 * calc will take a look at the ooo-build diff here as well
<[cliff]> stgraber, if the kernel ooops shouldn't it be in the logs?
<stgraber> when it fails to suspend, does it go back to gnome or just get stuck there and needs rebooting to go back to something usable ?
<[cliff]> stgraber, stuck, no keyboard response but video's (at least the monitor) on
<[cliff]> only way is to power off
<cjwatson> coo, we can sync xkeyboard-config
<cjwatson> big pile of patches merged upstream, plus pre-hardy upgrade code ...
<stgraber> [cliff]: ok, then if it's a kernel panic, you won't get any debug information logged because the whole system crashed, syslog included
<[cliff]> as a side story, I've been muttering about this for a long time now: would you guys, at Canonical, accept donated hardware to perform regression testing? e.g. in a few months I'm retiring this laptop, do you have any QA program for regression testing that would like to receive it (minus hard-drive of course)?
<[cliff]> if there is no such QA, would Canonical consider starting one?
<lukehasnoname> [cliff] killdisk
<[cliff]> stgraber, what about kern.log? does it depend on syslog too?
<[cliff]> never mind, i'll check that
<[cliff]> yeah
<[cliff]> right, you have a point stgraber. almost i'd say... shouldn't the caps/scroll/numlock keys flash when an oops occurs? I remember that happening on desktop systems
<stgraber> well, I never had one with 2.6.24 so I don't know :) but I remember of that behaviour with older kernels yes
<[cliff]> brb (prep'ing chow)
<[cliff]> right, so let me exclude that for now. any idea on how to debug kernel? I remember something had to be turned on to make it accept magic sysrq combos
<slangasek> calc: um, clearly this isn't "the same as rc2 except for a few changes in ooo-build", it shows a merge with Debian which brings in various changes to debian/
<calc> slangasek: ugh i forgot about that, of the changes in 'Debian' we have bugs about the filter-binfilter, the icon sizes (which why he credited me), so the only change we don't have a bug already is about the broffice bit
<calc> i didn't annonate those since they were listed as fixed in the debian part of the changelog
<calc> lp#237484 is about the icon sizes
<slangasek> there are no LP bug numbers in the Debian part of the changelog
<slangasek> which means we can't track them through LP as part of the SRU...
 * calc adds the 237484 to sru
 * calc sees if he can track down the number for the binfilter one
<calc> grr i can't seem to find the binfilter bug :-\
 * calc doesn't remember what the filer called it
<calc> other one is 234917
<calc> both have been marked for hardy and ubuntu-sru subscribed
<slangasek> calc: ok - are you intending to re-upload with a fixed changelog, so these are trackable through the available reports?
<calc> slangasek: i can if you would like, it takes ~ 1-1.5hr to reupload though on my dsl
<slangasek> calc: if you can spare the bandwidth, I would appreciate being able to use our normal tools for tracking the bugs
<[cliff]> back... can't jam it again. tried about 10 times, plugging and unplugging usb drive, usb mouse, with power, without power on, also closing lid, with lid open... I'm guessing it happens when some special alignment happens in the universe.
<calc> slangasek: ok
<calc> slangasek: i can use the same version number for the upload?
<slangasek> calc: yes, please
<[cliff]> it's not the first time, usually it happens when I leave the laptop on the desk so it doesn't bother me much but having it running so hot inside a bad was "it" for me
<calc> ok
<[cliff]> so if anyone has more suggestions, please share
<calc> slangasek: lp knows to just close the bug for the hardy bit right since i am uploading to hardy-proposed?
<compbrain> cjwatson: ping
<slangasek> actually, lp won't close it at all, we get to close them by hand :)
<slangasek> (we == SRU team)
<calc> slangasek: ah ok
<cjwatson> compbrain: yes?
<compbrain> I'm updating #234486, im hitting a block with kernel/module mismatch with images in proposed/i386/current
<cjwatson> compbrain: are you certain they're 2.6.24-16? That's very odd because they're supposed to be -19
<cjwatson> compbrain: does uname -r say 2.6.24-16?
<compbrain> hrm.
<compbrain> This may be a mirroring issue, let me double check
<cjwatson> I booted the mini.iso there in kvm, and uname -r says 2.6.24-19-generic
<calc> slangasek: uploading now, should be done in an hour or so
<slangasek> calc: cheers
<cjwatson> however, I do get the kernel module error ... ah
<cjwatson> compbrain: -19 isn't in -updates yet, so you need to put "apt-setup/proposed=true" on the kernel command line
<compbrain> alright, good to know i'm not going crazy
<compbrain> will give that a shot.
<compbrain> I can't keep track of all the kernels moving into proposed these days
<cjwatson> my bad for forgetting to mention it earlier; I've updated the bug report
<compbrain> cheers, thanks for the nudge.
<cjwatson> am just confirming the fix now
<cjwatson> compbrain: yeah, works for me with that addition
<compbrain> I fat fingered the debconf line, giving it another shot
<[cliff]> cheer-io-s
<compbrain> There needs to be a better way to determine the first bootable disk to install on, as opposed to the first disk detected
<cjwatson> compbrain: sadly it's very difficult to extract this from the BIOS
<compbrain> Yeah.
<compbrain> The sun X4500 is especially fun, where the bootable disks are named sdac and sdy
<ogra> you could try to interpret existing mbr's though
<compbrain> hacky at best
<ogra> indeed
<cjwatson> it's not even clear that using the first bootable disk is unambiguously sensible
<cjwatson> after all, if you have two disks and one of them already has a boot sector on it, then that clearly already has an OS on it that you might not want to erase; I can see an argument that in that event it would be better to default to the blank disk
<cjwatson> in practice, the "first disk" hack in partman-auto is really not intended for any of this
<cjwatson> its purpose is to simplify things when you only have one disk to start with
<compbrain> thats fair. I'm thinking in the use case of enterprisey blast-an-image-out to all machines technique
<cjwatson> on systems with more than one disk, I expect that people doing unattended installations would want to do something more sophisticated and ignore any defaults we set anyway
<cjwatson> which they could do with preseed hooks
<compbrain> I'm thinking something like 'user left a sd card in the reader' or had an external backup drive connected
<pwnguin> someone filed aboug about leaving a usb drive in accidentally; i cant remember the resolution
<compbrain> cjwatson: Everything works out with the apt-setup config item. Much thanks, again
<cjwatson> compbrain: good stuff
<cjwatson> compbrain: can you put that in the bug log if you haven't already, so that it can be considered for hardy-updates?
<compbrain> Yup.
<YokoZar> How do I make a "post from the developers" comment on brainstorm?
<ajmitch> jcastro would know
<jcastro> YokoZar: tell nand or stgraber that you'd like to get developer access and they'll set you up.
<YokoZar> stgraber: I'd like Brainstorm developer access ;)
<james_w> YokoZar: they need your numeric user id, if you don't know it log in and click your user name.
<YokoZar> 10632
<stgraber> jcastro: you should remember we both in the CEST timezone (00:40) so not very likely to answer at that time of the day :)
<stgraber> YokoZar: done
<YokoZar> stgraber: thank you :)
<jcastro> stgraber: ah ok, next time I'll just have them send you mail
<stgraber> that remains me I really should spec that LP integration bit and move everything to OpenID :)
<kirkland> is there a "proper" way for a script to write to /etc/fstab?
<kirkland> ie a library, or another program, or script, or such?
<kirkland> kees: ^^ ?
<kees> kirkland: uhm
 * kees ponders
 * ogra doesnt think something like that exists
<kirkland> kees: see 'man fstab'
<kirkland> i'm concerned about "fstab is only read by programs, and not written"
 * kees punts to slangasek or others deeply familiar with conf file management
<kirkland> kees: good call.... slangasek?
<slangasek> if by "script" you mean "package", then no there's no proper way to write to it :)
<slangasek> but of course, /etc/fstab itself is created by the installer, so you can probably steal info from there
<kirkland> slangasek: no, by script i mean a shell script I'm working on for setting up per-user ~/Private encrypted directories
<kirkland> slangasek: I need to add an fstab entry for those
<kirkland> slangasek: I have shell code that works, but I was checking to see if there was any existing API
<slangasek> API> nope
<ogra> does it really need to be in fstab ? how about using gnome-mount instead ?
<kirkland> slangasek: kthx
<kirkland> ogra: what about server installs with no gnome?
<ogra> (surely needs some hal integration though)
<kirkland> ogra: i think for non-root users to be able to mount, it MUST be in fstab
<kirkland> ogra: see "man mount" for that one
<ogra> well, there is pmount (for which pitti would be reluctant to get it back to main though)
<kirkland> ogra: interesting, never heard of pmount... what's wrong with it?
<ogra> kirkland, i know how it is, i wrote a lot of ltspfs which needs to deal with such issues a lot
<ogra> its been replaced by gnome-mount in ubuntu
 * kirkland offers an empathy hug to ogra
<ogra> and pitti was happy to let it go and not have to maintain it ... but ideed there is no gnome-mount on servers
<kirkland> ogra: yeah, that's a bummer, we need to be able to do this with/without gnome
<ogra> but mangling fstab is/can become quite dangerous
<compbrain> cjwatson: You wouldn't happen to know what the kernel command line length limit in the netboot kernels is would you?
#ubuntu-devel 2008-06-12
<cjwatson> compbrain: netboot kernel == all other kernels
<cjwatson> I don't know offhand, but you might find that bit of information useful ;-) it's just the regular generic kernel
<compbrain> Alrighty.
<compbrain> looks like 2048 bytes. probably a gpxe issue then.
<bryce> kirkland: hey I see in the server team meeting notes that you're putting man pages up on the web - awesome, I've had on my todo list to post the Xorg man pages (particularly for the input and video drivers and xorg.conf).  I'd be quite interested in seeing your work in this area
<superm1> slangasek, i saw the re-rolled hardy on cdimages from yesterday with the newer kernels.  thanks for that.  it will help immensely on some otherwise non functional boxes
<slangasek> superm1: hmm, which one did you see with newer kernels that's actually usable? :)
<slangasek> superm1: the alternates are all oversized unless someone fixed this for me, the liveCDs didn't have the new kernel yet
<superm1> the live disk
<superm1> the 2008-06-11.1
<superm1> i extracted it to a flash key
<superm1> so if it was oversize, wouldn't have mattered
<superm1> it boots on the box in question :)
<slangasek> ok :)
<Hobbsee> ogra: sorry, i'd gone to bed by that point.
<Hobbsee> exams and all :(
<marcot> ï»¿ï»¿Hello, I've downloaded the synaptic source package with apt-get source, and i'm looking at the pt_BR.po file, and the strings are different from the strings shown in my installed package.
<marcot> ï»¿I get a welcome message with some mistakes, including </b without >, and in the po file the sentence is writen with other words, and it's not with these erros.
<pitti> Good morning
<ScottK> Good morning.
<ScottK> Urgh.
<ScottK> When pitti is saying good morning, it's well past time for me to get to bed.
<pitti> kirkland: hmm; fstab for user-side mounts is soo much 1990..
<ajmitch> hello pitti
<kirkland> pitti: suggestions?
<pitti> kirkland: oh, still awake? :-)
<kirkland> pitti: 2 more hours until slangasek's party
<ScottK> Heh.
<pitti> kirkland: I'd rather use the existing hal/dbus infrastructure
<ScottK> pitti: Would you be up for accepting the SRU for Bug #226845?
<ubottu> Launchpad bug 226845 in amavisd-new-milter "amavisd-new-milter: unmet dependencies" [Medium,Fix committed] https://launchpad.net/bugs/226845
<pitti> kirkland: I think it's much easier and cleaner to write a command-line frontend which does the dbus calls than to reinvent the entire backend
<pitti> ScottK: will process the queue in a bit
<kirkland> pitti: interesting.... can you point me to some examples of how I might do this for ecryptfs mounts?
<ScottK> pitti: Thanks.
<pitti> kirkland: well, hal doesn't support ecryptfs yet, we have to teach it about it
<kirkland> pitti: i need to do the equivalent of this in /etc/fstab:
<kirkland> /home/dustin/.Private /home/dustin/Private ecryptfs rw,ecryptfs_sig=7ab2a4d59b181d9b,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,user,noauto 0 0
<kirkland> pitti: i can easily generate that, or the explicit mount -t foo -o bar options
 * ScottK goes to bed.  Good night all.
<pitti> kirkland: what's that signature?
<kirkland> pitti: signature of the passphrase stored in the kernel's keyring
<kirkland> pitti: used to retrieve the appropriate key from the keyring without giving anything away
<kirkland> pitti: a hash, so to speak
<pitti> kirkland: is that a secret that the user needs to supply, or the hal side?
<pitti> kirkland: anyway, the existing dbus mount API supports passing mount options
<kirkland> pitti: the sig isn't secret... it can be stored in a 644 permed /etc/fstab
<kirkland> pitti: the passphrase/key, of course, is secret
<pitti> we just need to add a tiny patch that allows ecryptfs as a valid file system, and the set of options that the user needs to/can supply
<kirkland> pitti: cool, sounds good to me
<pitti> kirkland: as for supplying the passphrase, that needs a deeper look, of course
<kirkland> pitti: and then, what does the UI look like for the user to do the mount, then?
<kirkland> pitti: nah, that's already handled by an ecryptfs pam module
<pitti> we already do it on the desktop for luks encrypted devices
<kirkland> pitti: i'm good on that part
<pitti> kirkland: ah, great
<kirkland> pitti: how does one trigger the mount?
<pitti> kirkland: well, shuold there be an UI at all? I thought it should happen on login?
<kirkland> pitti: i want it to happen on login
<kirkland> pitti: right, exactly
<pitti> 'zactly
<pitti> kirkland: hm, two things come to my mind
<kirkland> pitti: so right now, i have a shell script that I call in .bash_profile (and .config/autostart)
<pitti> /etc/bash_profile, or a PAM extension for common-session
<pitti> the former is easier, the latter more elegant, but takes some more effort
<kirkland> pitti: is that a question?
<kirkland> pitti: oh
<pitti> kirkland: anyway, this is a pretty interesting problem, since a CLI version of gnome-mount is generally useful, not just for ecryptfs
<pitti> well, of course there's always the highly comfortable CLI called "dbus-send" :-P
<kirkland> pitti: yeah, i can see that... i'm using a custom script, /usr/bin/ecryptfs-mount-confidential
<kirkland> pitti: and the /etc/fstab hackery is just that... hackery
<pitti> kirkland: right; please let's not do that (fstab)
<pitti> kirkland: I propose three implementation steps:
<pitti> 1) implement the support for ecryptfs mounts in hal; this can be tested with standard gnome-mount
<pitti> 2) develop a CLI version of gnome-mount
<pitti> or,
<pitti> 2b) write a small shell script wrapper around dbus-send to trigger the mount
<pitti> 3) think about how to trigger the mount, i. e. where to call that script: PAM module or bashrc
<kirkland> pitti: okay, regarding (3)....
<kirkland> pitti: we'll want to mount /home/user/.Private on top of /home/user/Private whenever they login and if it's not already mounted (ssh, console, desktop, whatever)
<pitti> kirkland: in the interest of not depending on a shell and supporting upgrades, a PAM-based solution would certainly be better
<kirkland> pitti: agreed, PAM would be better, but let me mention one other thing....
<pitti> kirkland: we can probably just extend libpam-mount to support our script, or even better, directly issue the dbus call
<kirkland> pitti: i'd also like to see to it that the last one logging out umounts
<kirkland> pitti: (my shell script is handling that with a "who | grep user | wc -l")
<pitti> kirkland: that call can check if it's already mounted (in fact, that's what hal already does; users aren't allowed to double-mount, you'll just get an error back)
<kirkland> pitti: and, I really want to chmod 500 both ~/.Private and ~/Private when it's not mounted, and 700 when it is
<pitti> kirkland: as for the 'last one switches out the light', that's more interesting
<pitti> kirkland: but PAM should certainly know which other sessions you are running?
<kirkland> pitti: hmm, i don't know about that
<superm1> hurm.  i uploaded a new upload of crash today that is supposed to build for lpia (at least as I put in debian/control).  does it need some archive admin love to do that too?
<superm1> https://edge.launchpad.net/ubuntu/intrepid/+source/crash/4.0-6.3-1ubuntu2
<kirkland> pitti: i mean, i don't know enough about PAM's session management to know
<pitti> superm1: you added the Architecture: field?
<superm1> i added lpia to the Architecture field yeah
<pitti> kirkland: I know that it is possible
<superm1> it already had one
<superm1> just was missing lpia in it's list
<pitti> kirkland: in earlier times we used libpam-foreground
<pitti> kirkland: and that wrote a /var/run/console/<user>:<vt> stamp for all logins
<kirkland> pitti: ah, so it used /var for accounting?
<pitti> kirkland: PAM runs code when the user logs out
<pitti> kirkland: nowadays we use ConsoleKit as a replacement, but I'm not sure whether you want to depend on that on servers
<kirkland> pitti: yeah, i have to keep servers+desktops in mind
<pitti> kirkland: anyway, I think on logout it should probably just test whether the user still has any process running? and if not, umount/clean up?
<pitti> superm1: let me check P-a-S
<kirkland> pitti: yeah, i'd just need to think about corner cases of a logged out user with processes still hanging around
<pitti> superm1: yep, that's it; P-a-S has "crash: amd64 i386 ia64 alpha powerpc      # not yet ported to other platforms"
<pitti> superm1: you need lamont's or infinity's help for that to add it there
<superm1> pitti, what's P-a-S actually?
<pitti> superm1: it's called "Packages-arch-specific" and overrides wrong Architecture: fields
<pitti> i. e. it blacklists packages from being built on particular architectures
<superm1> oh i see.  well it builds nicely on lpia at least
<persia> (And also overrides right architecture fields, if an entry exists)
<Hobbsee> afternoon pitti!
<superm1> i ran it through a PPA to verify
<persia> Is there anything that works on i386 that wouldn't work on lpia?
<pitti> hey Hobbsee
<superm1> whether it's entirely functional, that's a different story. I'm sturggling with other issues in reproducing this exact trace
<persia> Might it be sensible to have lpia check P-a-S for "i386"?
<superm1> *struggling
<kirkland> pitti: regarding (1), i'm looking at hal-storage-mount.c, right?
 * Hobbsee belatedly throws pitti a gummy bear.
<kirkland> superm1: I like "sturggling"
<kirkland> ;-)
<pitti> kirkland: right; but it doesn't hardcode the user-permitted file systems and mount options
<superm1> :)
<pitti> kirkland: those are defined in fdi/policy/10osvendor/20-storage-methods.fdi
<kirkland> pitti: aha
<pitti> kirkland: you should probably add a separate FDI instead of patching this
<kirkland> pitti: really?
<pitti> kirkland: e. g. fdi/policy/10osvendor/15-storage-luks.fdi is an extension for LUKS-encrypted devices
<kirkland> pitti: there's a bunch in there
<kirkland> pitti: ah
<pitti> kirkland: that should make a good template for you to copy
<kirkland> pitti: the leading 15- ... is that a priority or something?
<pitti> kirkland: hm; wait a minute; there's more to do for that, of course
<pitti> kirkland: yes, they are read in asciibetical order
<pitti> kirkland: i. e. latter ones can override the previous ones
<pitti> kirkland: with hal you can only mount "volumes" (block devices) which hal knows about
<kirkland> pitti: um, hang on a second....
 * pitti ponders
<kirkland> pitti: with ecryptfs, we're not dealing with block devices
<kirkland> pitti: it's a vfs
<pitti> kirkland: right, that's ok
<kirkland> pitti: overlay mounting
<pitti> kirkland: that's why it's called "volume" (an entity you can mount)
<kirkland> pitti: okey doke
<pitti> so this volume shuold be created in hal's database so that it can be properly represented in the hal tree
<pitti> it's no problem to create that on the fly when you try to mount it, but it does need some code
<pitti> kirkland: so either you use the existing code in hal-storage-mount.c which needs a representation of the volume in the hal tree (better IMHO, and upstream compatible) or special-case ecryptfs in hal-storage-mount.c and just do what you currently do to mount it
<pitti> kirkland: I can give you a hand with the hal side, of course
<kirkland> pitti: assistance accepted ;-)
<kirkland> pitti: let's go with upstream compatibility
<pitti> kirkland: well, as for that, I wouldn't worry too much
<kirkland> pitti: assuming that everything can be done in time for intrepid
<pitti> kirkland: hal is going to die in favor of devicekit
<pitti> kirkland: but I wouldn't want you to block on getting devicekit and devicekit-disks packaged and into intrepid
<pitti> kirkland: thus we should just do the custom Ubuntu patch for hal in intrepid, and then properly port it to DK-disks in intrepid+1 and make it upstream compatible
<kirkland> pitti: okay, and the custom ubuntu patch would be against hal-storage-mount.c ?
<pitti> kirkland: hmm; actually, what stops us from doing the mount right in the PAM module (libpam-mount)?
<pitti> kirkland: yes, that and the FDI
<pitti> but actually, maybe we are just overdesigning it
<pitti> isn't libpam-mount meant for exactly those cases?
<kirkland> pitti: does the PAM run with root privilege?
<pitti> kirkland: yes
<kirkland> pitti: oh, libpam-mount right.... i just read about that today
<kirkland> pitti: i haven't given much thought to libpam-mount yet
<kirkland> pitti: i bookmarked a howto on it ;-)
<pitti> kirkland: it can already be used to mount a LUKS partition or image as your home dir when you log in
<pitti> that shouldn't be too far apart from what you want to do
<kirkland> pitti: right, that's pretty much exactly what i need to do
<kirkland> pitti: where does a given user set up their libpam-mounts?
<pitti> kirkland: TBH I don't know; I didn't use it myself yet
<kirkland> pitti: okay, i'll dig into that
<slangasek> I don't believe libpam-mount provides for user-level configuration
<kirkland> slangasek: bummer, so it still requires a privileged user/admin to collect all libpam-mount's in an /etc config file?
<slangasek> AFAIK, yes
<kirkland> ewww.... pam_mount.conf.xml
<kirkland> slangasek: man pam_mount(8): "Individual  users  may define additional volumes to mount if allowed by pam_mount.conf.xml (usually ~/.pam_mount.conf.xml)"
<kirkland> \o/
<slangasek> ah, ok
<TiMiDo> hey i have a question
<TiMiDo> can someone guide me or help me?
<ion_> Yes: you type it and hit return. :-)
<Hobbsee> no
<Hobbsee> ion_: ++
<dholbach> good morning
<ion_> Hi
<kirkland> howdy
<TiMiDo> look im trying to make a packaged and i'm getting this error
<TiMiDo> Source archive you specified ( ../mdk-1.2.4 ) was not found!
<TiMiDo> any ideas?
<ion_> #ubuntu-motu is the place for packaging.
<kirkland> pitti: btw, i don't know if you noticed, but kees sponsored the select-editor patch.  thanks for looking at it with me at UDS.
<pitti> kirkland: I saw it, also your bug fixes yesterday; great!
<kirkland> pitti: ;-)
<emgent> morning
<hunger> Is alpha1 today?
<slangasek> hunger: afraid not; there's still work that needs to be done for the bootstrapping
<hunger> slangasek: Ah, thanks for the info. I was already wondering since almost every package I do care about is at the same version as in hardy:-|
<hunger> slangasek: The kerel in hardy is actually newer than the one in intrepid!
<slangasek> correct, the kernel team has been somewhat, er, distracted by the upcoming hardy point release :)
<slangasek> we should be able to let them loose on intrepid soon
<hunger> slangasek: Why are there so few things merged with debian yet?
<hunger> s/with/from/
<slangasek> hunger: again, I think it's largely due to the developers' attention being split between 8.04.1 and intrepid
<hunger> slangasek: Thanks again for the info.
 * hunger usually is at the current+1 release about 2 weeks after the repos open but has not found anything to make the upgrade to intrepid necessary yet.
<robinp> is there a generic Java extensions directory on ubuntu ? (i.e. that works across all java runtimes )
<persia> robinp: Java extensions directory?  How do you mean?  For libraries?
 * Hobbsee wonders why sections of gnome are borked on intrepid
<Hobbsee> half of the top panel missing is strange - and means there is no close button
<seb128> Hobbsee: ask mvo that's a compiz issue and he said he would upload a new snapshot version yesterday ;-)
<Hobbsee> seb128: ahhhh.  i'll have to boot to there, and update then
<mvo> Hobbsee: its already in bzr, but compiz FTBFS currently (I think somewhere in kde, need to investigate)
<Hobbsee> oh, tasty.
<Hobbsee> want a hand?
 * Hobbsee fixes hardy, so it actually boots.
<mvo> maybe, let me look at it again
<slangasek> seb128: as of ~11h ago, the packages were still not fixed as far as antimony was concerned
<slangasek> pitti: hrm, does ia32-libs really need updated for alsa-lib?  Isn't that just lib32asound2, built from alsa-lib source?
<seb128> slangasek: could you check if that's fixed now?
<pitti> slangasek: right, but we should update it to .16 for completeness
<TheMuso> slangasek: I think ia32-libs will need updating as it has plugins in it I think.
 * TheMuso checks
<TheMuso> slangasek: alsa-lib and alsa-plugins are in there.
<slangasek> seb128: sorry, s/antimony/livefs buildd/.  anyway, trying a rebuild now; if it still doesn't see the fixed package, I'll probably need to grab infinity about it in the morning
<seb128> ok
<slangasek> TheMuso, pitti: I only see the plugins inside the ia32-libs binary package
<slangasek> seb128: oh, the cronjob already ran for this morning; evolution-exchange looks ok, now we just need to straighten out libffi4 and apt
<slangasek> (http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu/20080612/livecd-20080612-amd64.out)
<seb128> cool
<seb128> so I've fixed the desktop things correctly ;-)
<mvo> Hobbsee: so what is the deal with kde in intrepid, the default kde switched to 4 but 3 is still available?
<Hobbsee> mvo: iirc, yes.
<Hobbsee> mvo: and it's still all going thru the mir process
 * mvo nods
<psypointer> hi
<psypointer> i just used the netboot images from hardy proposed to install my computers via pxe and preseed. after adding the kernel parameter apt-setup/proposed=true the installations works without errors, but it ignores my preseed commands (preseed_late for example). how can i fix this?
<psypointer> d-i preseed/late_command string wget http://10.255.255.254:88/files/preseed_late.sh -O /tmp/preseed_late.sh; sh /tmp/preseed_late.sh; thats what i'm using in my preseed conf but its simply ignored by the proposed version of the installe
<psypointer> preseed ealry works..
<psypointer> s/ealry/early/
<pitti> dendrobates: anyone in the server team who could test the php5 package in dapper-proposed for bug 52866?
<ubottu> Launchpad bug 52866 in php5 "SOAP response for associative array is different on ubuntu 6.06" [Undecided,Fix committed] https://launchpad.net/bugs/52866
<pitti> ogra: did you get any feedback to any of the ltsp bug fixes in -proposed? none of them are verified ATM
<ogra> i can verify all of them, but i guess thats not enough ?
<slangasek> if you uploaded them, then that shouldn't be enough, no :)
<slangasek> hard to eliminate blind spots that way :)
<ogra> yeah, thats what i suspected ...
<ogra> bad thing is that the usual habit of ltsp users is to not upgrade the client chroot they use whats been set up during install ... so best feedback would come from 8.04.1 CD users ... somewhat a chicken <-> egg problem
<ogra> but i'll try to gather some feedback
<pitti> ogra: well, if you do tests with teh actual .debs from -proposed and give feedback in the bugs, that's already a good data point
<pitti> for testing misbuilds, screwed dependencies, etc.
<pitti> feedback from the uploader is very helpful, just not entirely sufficient
<ogra> yep
 * pitti hugs ogra, thanks
<ogra> :)
<stgraber> ogra: I'll regenerate a new chroot at home, probably this afternoon. I can enable -proposed and have a look at the fixes
<ogra> stgraber, gracias !
<stgraber> I can actually generate the chroot from there, I forgot that this server is on my VPN :)
<stgraber> ogra: should I also enable -proposed in the chroot ?
<ogra> yes, best is to use --copy-sourceslist
<stgraber> ok
<stgraber> Fetched 133MB in 1min8s (1946kB/s), /me loves new home internet speed :)
<ogra> heh
<pitti> nice!
<stgraber> ogra: what's the easiest way to test that xubuntu fix ?
<ogra> hmm
<ogra> it checks if xubuntu-desktop is installed and the default
<ogra> thats hard to reproduce, leave that one to me, i'll do a xubuntu install during the day in vbox and test it there
<ogra> (need to grab the iso though)
<stgraber> ok
<stgraber> ogra: I confirmed two fixes, others will need that I boot a thin client (I can't really do that from the train station over VPN :))
<ogra> bah
<ogra> get a better train station
<ogra> :)
<stgraber> I don't think the download speed is the problem but rather my upload speed at home :) 2Mbit/s seems to be too slow to boot a thin client :)
<cjwatson> hunger: looking at the graph at the bottom of http://merges.ubuntu.com/main.html, I'm not sure that's a fair characterisation of merge progress; there is certainly a lot to do, but somewhere between a third and half the main merges have been done
<sdfg> can somebody help me with a cres-dev toolchain for powepc
<kirkland> slangasek: are you still around?
<hunger> cjwatson: I have not checked that graph. I just checked which packages would get updated by aptitude if I did a upgrade to intrepid and almost everything I care about is not, even though debian has newer versions.
<kirkland> pitti: i officially *hate* pam_mount
<pitti> kirkland: is it that bad?
 * lamont tries to figure out what exactly causes his brain the most pain about a package 'db_4.7.25-1' being the first upstream 4.7 version to land
<fabbione> ouch
<pitti> lamont: let's just hope it's a date :)
<lamont> or that the 7 and the 25 are independent counters
<lamont> previous version being 4.6.21
<\sh> dholbach: is it possible to use the single cookie line for lp/edge.lp and save it somewhere for python-launchpad-bugs?
<ScottK> Was there a discussion about adding Landscape to the SRU exception list (as there recently was with hal-info) that is publically archived somewhere?
<dendrobates> pitti: we are short handed, could the php bug test wait a couple days?
<pitti> dendrobates: absolutely; it's waiting for half a year already, that won't make much of a difference
<pitti> I'm just looking for someone who touched php to test it
<ScottK> pitti: Back in February you added Landscape as a special SRU case (rev 85 of the SRU wiki page).  Was this discussed?  I'm trying to understand why it would be there.
<dholbach> \sh: best to ask thekorn about that
<\sh> dholbach: k
<pitti> ScottK: ah, complicated story
<pitti> ScottK: we actually discussed it, but only within Canonical so far; there hasn't been a TB decision about it yet, and we actually didn't do a landscape update yet
<ScottK> pitti: I think it ought to not be there then.
<ScottK> There are a lot of packages that would meet the same criteria.
<pitti> ScottK: there's still an ongoing (but dragged) attempt to reformulate the SRU policy to provide something consistent for SRU, -backports, partners, etc.
<ScottK> I think "Canonical has this proprietary product we have to keep up with" is a bad policy (which is what that reads like to me).
<pitti> ScottK: well, I know tor, which we actually updated to a new upstream in stables in the past
<pitti> ScottK: right; we need to formulate it differently, and thus cover similar cases as well
<ScottK> Tor is a special case for reasons that we discussed widely at the time.
<ScottK> pitti: Would you mind if I removed it pending a better formulation?
<pitti> already at changing it
<Hobbsee> ScottK: it's in main.  you're not part of the main release team.  why do you care?
<ScottK> pitti: Thanks.
<ScottK> Hobbsee: I care because I believe that Ubuntu and Canoncial are different entities with different governence.  It is benificial in the long run for Ubuntu to not be seen as having excessive favoritism for Canonical (and particularly it's proprietary products).
<Mithrandir> it's similar to many other products where the protocol for talking with a server Ubuntu does not control changes and the client therefore needs updating.  IMO.
<Hobbsee> ScottK: then shouldn't you be pushing for more people on the ubuntu release team (for main) who are not canonical employees?  They are the ones who should know about it, and make those decisions.
<Hobbsee> ScottK: for all intents and purposes, you don't know if it was discussed privately among the relevant release team, and decided.
<pitti> in fact we did this already, for some google service protocol in hardy-updates
<pitti> (can't remember which one any more, though)
<ScottK> Hobbsee: I would be in favor of that.
<Mithrandir> pitti: yeah, it's not really a happy situation, but it's probably not a problem we can solve easily.
<ScottK> Hobbsee: That's why I asked pitti if it was discussed.
<pitti> so, it was, but not in the right Ubuntu forum so far
<ScottK> He's the one that put it on the wiki.
<Hobbsee> obviously, it would have been better if it was open, but just because it wasn't particularly public doesn't necessarily mean that it's an inside canonical thing, and they're rorting the system.
<ScottK> As I understand it TB is the authority for such blanket waivers.
<ScottK> it/is
<Mithrandir> I believe it's been decided by the release team in the past.
<ScottK> Dunno, but I'm happy with the markup as it now.
<ScottK> pitti: Thanks.
<ScottK> pitti: When you get ready to work on improving the process documentation, I'd be glad to contribute something about updating unmaintainable libraries with the rdepends via -backports as I did with clamav (BTW, no user complaints about the Feisty/Gutsy updates to what Hardy has on that one).
<kirkland> pitti: hey, so, yeah, pam_mount doesn't quite work as advertised
<pitti> kirkland: what does it do?
<kirkland> pitti: doesn't unmount on logout
<kirkland> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736
<ubottu> Launchpad bug 117736 in libpam-mount "pam_mount unable to unmount needs root priv" [Medium,Confirmed]
<kirkland> pitti: see what you make of that
<pitti> kirkland: urgh, messy; so that PAM configuration is Debian/Ubuntu specific
<kirkland> pitti: possibly, i have a Fedora kvm, that I'm also looking at
<kirkland> pitti: your pointer to pam_mount is a good one; if it did what it's designed to do (unmount on logout), this would be a perfect fit
<pitti> kirkland: so maybe let's aim to fix this, that would make a lot of other people happy as well
<kirkland> pitti: yea
<kirkland> pitti: i worked through the night on it, and i can't decide whether to fix this in pam, ssh, or pam_mount
<kirkland> pitti: would be nice if it were fixable just in pam policy (no code)
<pitti> apparently not in pam_mount, if our pam_mount source works on mandriva
<pitti> and not in ssh, if it also affects local console logins
<pitti> kirkland: might just be hidden in /etc/login.defs?
<kirkland> pitti: i don't think it does affect local logins
<kirkland> pitti: i tried enabling CLEAN_SESSIONS (some people said it helped--a few years ago)
<kirkland> pitti: no avail
<kirkland> pitti: i assume a setuid umount would be a no-no?  even if it were a special one for just this case?
<pitti> kirkland: it is already suid (needs to be for user umount)
<kirkland> pitti: i think umount.crypt was written to handle this issue
<kirkland> pitti: hmm, right, doh
<Misterio> hi all
<Misterio> ;D
<Misterio> bye all :) ;) :Â·)
 * mkrufky says "hi" to mario_limonciell
<mario_limonciell> hi mkrufky
<mkrufky> any final word on that thread... kinda went nowhere
<mario_limonciell> unfortunately not.  i'll try to revive it
<mkrufky> k
<mkrufky> im merging power management fixes today
<kirkland> pitti: interesting, i've managed to fenagle a working pam policy for Fedora
<kirkland> pitti: i'll try to duplicate this on Intrepid after i get some coffee in me
<mathiaz> kirkland: pitti: could pam_mount be used to mount a user home directory via cifs at login ?
<kirkland> mathiaz: yes
<kirkland> mathiaz: that's one of its classical use cases
<kirkland> mathiaz: however, there is a bug, it seems on Debian-based distros, that keeps unmount from working when logging out of ssh
<mathiaz> kirkland: ok
<kirkland> mathiaz: see https://bugs.edge.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736
<ubottu> Launchpad bug 117736 in libpam-mount "pam_mount unable to unmount needs root priv" [Medium,Confirmed]
<mathiaz> bdmurray: does python-launchpad-bugs support extract the list of packages a team is subscribed to (ex from https://bugs.launchpad.net/~ubuntu-server/+packagebugs) ?
<bdmurray> mathiaz: no it does not
<bdmurray> slangasek: what is the nomination / milestone document you've worked on?
<calc> jcastro: ping
<jcastro> calc: pong
<calc> jcastro: just replied to your question about upstream'd bugs
<jcastro> rock, thanks
<calc> jcastro: afaict there are several hundred for OOo
<calc> jcastro: so either i don't understand what the new page shows or there is a bug in it
<jcastro> yeah I am strongly leaning towards "there has to be a bug in it."
<calc> i included the link to show most of the upstreamed bugs for OOo
<jcastro> calc: when you forward a bug or patch do you make a link from an existing bug in lp to the upstream bug tracker?
<calc> its a bit long:
<calc> https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bugs?field.searchtext=&orderby=-importance&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.status_upstream=resolved_upstream&field.status_upstream=open_upstream&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.ta
<calc> jcastro: yea, eg https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/36424
<ubottu> Launchpad bug 36424 in openoffice.org "[Upstream] [hardy] OpenOffice fails to open file over ftp when user not anonymous" [High,Confirmed]
<calc> it has a upstream project called "OpenOffice" with the ooo issue tracker number and link
<jcastro> ah ok.
<jcastro> this lists looks more sane. :D
<calc> maybe the page only works if the upstream project has the same name as the Ubuntu package?
<jcastro> substituting firefox in the url comes up with a sane list as well
<jcastro> calc: excellent, thanks, I'll forward this along to kiko and see about fixing it
<kirkland> slangasek: are you around yet?
<calc> jcastro: great :)
<kirkland> slangasek: pam_mount frustrations....
<jcastro> calc: if I hover over the 0 for OOo it shows that it's looking for status "triaged", maybe that's it?
<calc> jcastro: ah maybe so
<calc> jcastro: there is a separate section for triaged though
<jcastro> yeah, those are all the ones that are triaged but not linked upstream
<jcastro> the upstream column is a subset of those
<calc> hmm so the new rule is a upstream bug has to be marked triaged as well?
<calc> i don't think i have used triaged for any OOo bugs
<calc> i mark them confirmed and upstream if they are upstream bugs
 * calc could back and mark them all as triaged but an upstream bug should automatically be considered done enough
<calc> i guess confirmed that i have verified would be better marked as triaged if they aren't also upstream bugs
<calc> i think the url is also wrong
<jcastro> well, the onus is on us to make sure we're following what people are using. It should probably do all open bugs
<calc> it uses edge. instead of bugs.
<calc> https://bugs.launchpad.net/ubuntu/+source/openoffice.org?field.status_upstream=open_upstream works but edge. doesn't (if you remove the triaged bit)
<calc> that also only shows open upstream bugs not ones that have been fixed upstream (i think?)
<calc> just because a bug is fixed upstream doesn't necessarily mean we can use it yet, in OOo case many of those are fixed in 3.0
<calc> which isn't actually released yet
<jcastro> yes, it's only measuring open bugs
<wwinter> Hey everyone.
<wwinter> I was interested in helping with the development of ubuntu, I'm fairly competant in C++ and C, and was interested in maybe being mentored if that'd be possible?
<ScottK> wwinter: What are you most interested in (Ubuntu, Kubuntu, Ubuntu Server, Etc.)?
<wwinter> Ubuntu, mainly use it for audio production.
<smallfoot-> make ubuntu faster, its slower than windows xp
<ScottK> wwinter: Then I'd look into #ubuntustudio or #ubuntu-desktop.  If you want to learn about packaging programs for Ubuntu, there's #ubuntu-motu
<wwinter> Thanks :)
<wwinter> smallfoot: get a better pc :P
<smallfoot-> i have intel dual-core, 4gb ram
<smallfoot-> kickass pc, with 8600gt
<smallfoot-> 2.13 GHz
<wwinter> Okay.. is it just slow all the time or what?
<smallfoot-> and its blazing fast in XP, but in Ubuntu, its slower
<smallfoot-> no, its just less responsive
<wwinter> What version are you running?
<smallfoot-> when i open calculator, notepad or something in xp, it opens immediatly <1ms delay, in ubuntu 8.10, when i open gedit or gcalc, it takes 0,5-2s delay
<wwinter> Are you using the proper driver for your gfx card in Ubuntu?
<smallfoot-> yes
<wwinter> Hmm I see what you mean, never really noticed it before lol
<wwinter> It's not that bad though.
<smallfoot-> yeah, its not that bad
<smallfoot-> its like its "god this is slow"
<smallfoot-> its not liek its "god this is slow"
<smallfoot-> but after i use ubuntu for long time, then i reboot to xp, i feel "wow, xp is fast, everything happens immediatly!"
<wwinter> I guess so, but I always found ubuntu more stable than windows.
<wwinter> Especially so with Vista.
<smallfoot-> yeah, vista sucks
<smallfoot-> xp is rock solid though, and has been more stable for me than ubuntu
<smallfoot-> applications crash a lot more often in ubuntu than in xp
<smallfoot-> example, firefox, but it might have todo with the flash plugin
<wwinter> Hmm, I've never had problems with ubuntu, but I'd say the short delay's just due to the gnome code being less optimised than xp explorer.
<smallfoot-> yeh, or maybe gtk library
<wwinter> You could try using KDE and see if it happens there too.
<wwinter> If not, it's gnome, or the gtk libs
<smallfoot-> yeah, just cant be bothered install whole big kde, or get kubuntu
<slangasek> kirkland: I haven't used pam_mount personally, fwiw :)
<slangasek> bdmurray: https://wiki.ubuntu.com/RCBugTargetting
<kirkland> slangasek: ;-)  ... so this is about https://bugs.edge.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736
<ubottu> Launchpad bug 117736 in libpam-mount "pam_mount unable to unmount needs root priv" [Medium,Confirmed]
<kirkland> slangasek: a note from you on the topic http://www.redhat.com/archives/pam-list/2003-April/msg00015.html from 4 Apr 2003 ;-)
<kirkland> slangasek: i've added some debugging to sshd and pam_mount.  it looks to me like the problem is that sshd is running with a real uid of 1000 (well, not 0) when it calls the pam_close_session()
<kirkland> slangasek: which means that pam doesn't have the authority to do what it needs to do (like unmount filesystems)
<ogra> old known problem
<kirkland> ogra: cool, i thought you might have some insight....
<kirkland> ogra: gimme the dirt....
<slangasek> kirkland: ah, well, for that you need to talk to cjwatson with his ssh hat :-)
<ogra> you can work around it by disabling privilege separation in shh
<ogra> *ssh
<ogra> but that drops security
<kirkland> ogra: i've actually tried dropping privilege separation, but that doesn't fix the problem for me
<kirkland> ogra: any other ideas on the problem?  a way to solve it in the code without dropping priv separation?
<ogra> use pam_script instead of pam_mount and script something together with a suid binary would be one ugly solution ...
<kirkland> ogra: yup, that's what i was trying to move away from in favor of pam_mount
<ogra> i dont really think there is a clean one
<kirkland> ogra: okay, thanks.  i can actually avoid the setuid binary if i add the mounts to /etc/fstab and use the "user" flag
<ogra> indeed
<ogra> but then you have to fiddle with fstab
<kirkland> ogra: this all started about 13 hours ago when I became damned and determined to remove those entries from /etc/fstab :-/
<ogra> cant you do something with fuse instead of using real mount ?
<kirkland> ogra: i think i want/need a real mount
<ogra> oh, and nbd works fine fuly in userspace (even as the user) you can loopmount a file from localhost with it
<kirkland> ogra: what are the limitations of fuse?
<kirkland> ogra: this is an ecryptfs filesystem
<kirkland> ogra: it's a vfs, mounting an encrypted directory on a mountpoint
<kirkland> ogra: in kernel, uses the kernel keyring
<ogra> hmm, sad, nbd could solve your prob (it can work like a user owned loopback device) but that uses only images
<kirkland> ogra: one of the advantages that i'm trying to use of ecryptfs is that the underlying encrypted files can be incrementally backed up, not practical if you only have a single encrypted 4G file
<ogra> fuse is likely to top layer ...
<kirkland> ogra: i don't see where fusermount would let me specify a filesystem type of -t ecryptfs
<kirkland> pitti: okay, i'm right back where i started....  using /etc/fstab
<kirkland> pitti: for good reasons, now, mind you
<jussi01> pitti: If you are around, just wanted to thank you for your tv drivers package :D works a treat :)
<ssam> i am running hardy with proposed-updates enabled. today my mouse is very jerky, some clicks are being ignored and keeeys are multiply pressing. i am not surrre if its one of the updates that has caused     this or which oneeee. where should i report itttt?
<calc> jcastro: wrt the bug report it might be useful if it can be squeezed in to show the number of incomplete bugs
<calc> jcastro: OOo in particular has lots of those
<jdstrand> kees: what is the url for checking the build status of a package in Debian? (I'd like to see what is happening with openssl-blacklist)
<kees> jdstrand: I assume it's stuck in binary NEW, but let me go dig it up
<kees> jdstrand: oh, right, no build logs -- it's an _all package, so my upload of it IS the build.  :P
<kees> jdstrand: http://ftp-master.debian.org/new.html
<jdstrand> kees: cool thanks
<RainCT> bryce: Do you know when the problem that your  21_fix_dpll_prg_in_crtc_mode_set.patch patch in xserver-xorg-video-intel fixes was introduced?
<bryce> hi RainCT, let me doublecheck
<bryce> RainCT: do you mean 20_dpll_prg_in_crtc_mode_set.patch?
<bryce> RainCT: ah, right, for hardy.
<bryce> RainCT: the bug was first reported to us on 5/30
<bryce> RainCT: the problem was introduced in commit 3c22ed633be2ac96eea7bc533839e956f1f31b84
<RainCT> bryce: Ah, it isn't the problem I'm experiencing then. Well, thanks :)
<bryce> np
<pzn> Hi... already asked in #ubuntu, but no answer... do you know then gutsy will be discontinued? I need to plan the dates of some upgrades.
<soren> pzn: 18 months after release.
<pzn> soren: thanks!
<YokoZar> So, Wine 1.0 and Firefox 3 might release on the same day by pure coincidence
<cjwatson> kirkland: it might be possible to change it, although messing around with pam_session handling in sshd has a very strong history of fixing one thing and breaking another
<kirkland> cjwatson: thanks for the update...  i think i'm going back to adding entries to /etc/fstab
<kirkland> cjwatson: pam_mount just isn't going to cut it
<cjwatson> changing pam_open_session is more likely to break things than close, of course; though I suspect that there are some modules that rely on open and close being called with the same privileges
<kirkland> cjwatson: and i don't want to negatively affect anyone's ssh configuration
<slangasek> well, pam_mount is such a module that relies on them being called with the same privs
<kirkland> cjwatson: i think it's one step back from that....  ssh calls pam_close_session as a non-priv user
<cjwatson> right, we went through a period several years ago when it got changed back and forward a bit
<cjwatson> kirkland: because it also calls pam_open_session with dropped privileges
<cjwatson> if you change that, I *know* it breaks other things
<slangasek> hmm, but then the question is, how does pam_mount work at all under ssh
<kirkland> cjwatson: it looks to me like the only universally available "proper" way for a non-priv user to mount/unmount is to have an entry in /etc/fstab with "user" option
<cjwatson> it doesn't have a set-id helper does it?
<cjwatson> not sure how that could be made to work securely, mind you
<cjwatson> (!)
<kirkland> cjwatson: slangasek: looks to me like pam_session_open is called with uid 0, but close with uid 1000 (in my case)
<cjwatson> oh, you're right
<cjwatson> and indeed it should be called with raised privileges, I had it the wrong way round
<kirkland> cjwatson: "it" = open|close ?
<cjwatson>     - New PAM implementation based on that in FreeBSD. This runs PAM session
<cjwatson>       modules before dropping privileges (closes: #132681, #150968).
<cjwatson> open should (i.e. I expect that that is the way it works right now); close should (i.e. ought to in an ideal world)
<cjwatson> kirkland: https://bugzilla.mindrot.org/show_bug.cgi?id=926
<ubottu> bugzilla.mindrot.org bug 926 in PAM support "pam_session_close called as user or not at all" [Normal,Assigned]
<kirkland> cjwatson: yeah, i pointed https://bugs.edge.launchpad.net/ubuntu/+source/pam/+bug/117736 to that
<ubottu> Launchpad bug 117736 in libpam-mount "pam_mount unable to unmount needs root priv" [Medium,Confirmed]
<cjwatson> apparently that patch screws pam_mount in other ways though ...
<cjwatson> I'll be upgrading to openssh 5.0p1 once all the openssl mitigation stuff is definitively out of the way, so we can try it then
<cjwatson> kirkland: ah yes, so you did
<kirkland> cjwatson: cool, thanks.
<kirkland> cjwatson: in the meantime, i was thinking of writing a little utility that would cleanly update fstab for my purposes
<kirkland> cjwatson: right now, its embedded in another script (ecryptfs-setup-confidential)
<kirkland> cjwatson: but I think it would be more easily reviewable, and potentially useful elsewhere
<kirkland> i gotta drop for a bit, see ya.
<mathiaz> slangasek: in a SRU (openldap in this case), do you prefer to have the patches deleted from the debian/patches/ when they're no longer applied or just have then uncommented in the series file ?
<slangasek> mathiaz: deleted, please
<mathiaz> slangasek: even if the debdiff will be bigger ?
<slangasek> mathiaz: yes, because it's also clearer that way precisely what's been changed
<mathiaz> slangasek: ok
#ubuntu-devel 2008-06-13
<TheMuso> slangasek: WOuld it be better to have a new bug for the alsa-{lib,plugins} SRU, or should I use an existing bug, like the one you adjusted task status on yesterday?
<slangasek> TheMuso: better to use the same bug, I think
<TheMuso> slangasek: Ok I thought so too, but just wanted to be sure.
<azeem> w31
<azeem> oops
<TheMuso> slangasek: SInce the alsa bits are new upstream, is it ok for them to be in a PPA, instead of a diff? Or would you prefer a diff? I will attach the changelog entry of course.
<slangasek> TheMuso: in practice, we don't normally review or require diffs submitted to bugs for main SRUs, we just debdiff the queue
<TheMuso> slangasek: Ok.
<TheMuso> So in this instance, should the version number be the same as intrepid, or should it be something like 1.0.16-2ubuntu0.1?
<slangasek> it can never be the same
<TheMuso> Right.
<slangasek> if you use 1.0.16-2 as a base for your work, then 1.0.16-2ubuntu0.1 would be ok; but please be cautious about introducing unrelated packaging changes relative to what's in hardy
 * TheMuso nods.
<TheMuso> Well in that case, I might only update to the new upstream, and subject to finding out the usefulness of any other patches Debian has added, add them also...
<slangasek> yes, that's what I would recommend
<mathiaz> slangasek: looking at the diff for openldap SRU, I've noticed that: http://paste.ubuntu.com/19764/
<mathiaz> slangasek: would this be a problem in terms of ABI changes ?
<slangasek> "static int", so no
<mathiaz> slangasek: but that is an API change right ?
<slangasek> mathiaz: no, it isn't; "static" functions are local to the file they're defined in, so this isn't part of any API visible from outside this one source file
<YokoZar> slangasek: What's the relationship between hardy-backports and 8.04.1 ?  If I backport Wine 1.0 to Hardy, will that stay in -backports forever, or can it be promoted in some sense?
<mathiaz> YokoZar: -backports and 8.04.1 (which is -updates actually) are two different repositories
<YokoZar> mathiaz: Yeah, I suspected as such.  I just wondered if it might be appropriate to push some things in -backports to -updates for 8.04.1
<slangasek> not really, no
<slangasek> -updates is for post-release fixes of critical bugs; not for new upstream versions, except for very specific exceptions
<YokoZar> Like Firefox and such for 8.04.1
<YokoZar> I guess I'm just wondering how 8.04.1 is different from a handful of SRUs.
<slangasek> the main difference is that there are now ISOs issued
<slangasek> s/now/new/
<TheMuso> slangasek: It seems that only bluetooth audio/alsa packages add other plugins to be used with alsa. Alsa plugins live in /usr/lib/alsa and only bluetooth-alsa and bluez-audio packages add extra shared objects in that directory.
<TheMuso> usr/share/alsa-lib even
<slangasek> TheMuso: right
<mathiaz> slangasek: I'm not sure if this diff is suitable for an SRU (http://paste.ubuntu.com/19768/)
<mathiaz> slangasek: there seems to be some changes in the libldap_r library
<slangasek> mathiaz: anything that's ldap_int or ldap_pvt is actually not part of the published APIs, either; so I would still be willing to accept such changes in an SRU.  But if you'd prefer, I'd also be happy to have only the select bugfixes backported and applied :)
<mathiaz> slangasek: oh no no - if that's fine with you I'd rather go with 2.4.9 :D
<mathiaz> slangasek: and we'll probably get 2.4.10 in hardy as well
<mathiaz> slangasek: at a later time though
<mathiaz> Considering that openldap-2.4.9 is already in intrepid, do I need to include openldap-2.4.9.orig.tar.gz in the upload to hardy-proposed ?
<slangasek> mathiaz: AFAIK it won't matter
<mathiaz> slangasek: well - I've uploaded the orig.tar.gz file - we'll see
<TheMuso> slangasek: I've slightly adjusted the regression potential in the bug, and attached plugins and lib upstrea mchangelogs. DO you want to look over them first, or should I upload?
<slangasek> TheMuso: go ahead and upload please, I won't be able to review it in real time at the moment
<TheMuso> slangasek: Ok.
<calc> jcastro: btw i think i will go in and mark the upstream'd bugs as triaged to make it easier for the page to track status
<calc> jcastro: it seems now that we have triaged that is the preferred way to do it anyway
<ScottK> calc: Confirmed is going to go away soonish from LP, so don't get too used to having the two status choices.
<persia> ScottK: Is that completely confirmed?  I thought there were other projects that had valid use cases to preserve confirmed, and that might also impact Ubuntu.
<TheMuso> ScottK: What is it being replaced with?
<ScottK> A 'me too' button so users just click there and you get a me too count instead of a bazillion useless me too comments.
<ScottK> persia: Nothing in Launchpad is ever completely confirmed.  Not even after it's implemented because they might take it back.
<calc> ok
<calc> well i'm moving everything that is confirmed by me to triaged since it seems that is a good use of that status
<calc> i had been using confirmed as i could reproduce it but it seems that would be better as triaged
<calc> then let users use a me too or confirmed or whatever
<jcastro> calc: that seems to make sense
<jcastro> from what I gather no one has just declared "we're using triaged now."
<persia> I've always used confirmed when I can reproduce it, and triaged when the bug report contains a sufficient information for a solution (which are not always the same thing).
<ScottK> jcastro: We get what LP implements and that's what they said they were planning at UDS.  Plans change of course.
<jcastro> yeah
<jcastro> My concern is that not everyone knows that
<ScottK> I think most developers are well aware the we get whatever LP decides to implement.
<jcastro> heh
<ScottK> Good night.
<lifeless> gnight
<dholbach> good morning
<ajmitch> hi dholbach
<dholbach> hi ajmitch
<pitti> Good morning
<ion_> Hi
<pitti> jussi01: you're welcome :)
<pitti> kirkland: ugh, fstab dynamically? that doesn't sound like a final solution?
<kirkland> pitti: i'm also going to look into capabilities
<pitti> kirkland: so PAM can't be fixed to umount as root during logout?
<kirkland> pitti: it's ssh that would have to be fixed, i think
<kirkland> pitti: additionally, i'm going to look into kernel capabilities
<kirkland> pitti: when sshd switches execution back to pam on logout, the context is running with uid 1000 (not 0)
<pitti> kirkland: hm, keeping CAP_SYS_ADMIN as an user process is almost as good as root
<kirkland> pitti: it's more finegrained than setuid, methinks
<pitti> kirkland: maybe we should reconsider a hal-based solution then
<pitti> kirkland: or at least d-bus
<kirkland> pitti: i'm open to either
<kirkland> pitti: if you think they can be completed within intrepid
<pitti> kirkland: if you create your own dbus service, that's relatively easy, and we do not need to touch hal
<pitti> it's a much bigger cannon than using PAM admittedly, but it gives us the fine-grained privileges you need
<kirkland> pitti: okay....  i might need a primer at some point
<kirkland> pitti: which sprint are you attending?
<pitti> kirkland: London
<kirkland> :-/  hmm
<kirkland> seems like the several people i need to work with are going to London
<pitti> kirkland: other question: do you have a running daemon process for transparently unencrypting ~/.Private to ~/Private?
<pitti> i. e. is it like FUSE?
<pitti> or does the kernel handle that?
<kirkland> pitti: kernel
<kirkland> pitti: handled by mount
<kirkland> pitti: a pam module, pam_ecryptfs takes your password on login, and unwraps an encrypted file containing a mount passphrase, and inserts it into your kernel keyring
<pitti> kirkland: I wonder whether it would be more elegant to have the kernel itself umount ecryptfses once the last user process dies
<kirkland> pitti: i had dinner with the maintainer tonight, and discussed that to some extent
<kirkland> pitti: there is an ecryptfsd daemon (which we're not using at the moment for ~/Private work)... he suggested that it could be tought to do so
<pitti> kirkland: what is it used for?
<pitti> kirkland: couldn't that just clean up umounts?
<kirkland> pitti: other forms of key management besides passphrase (openssl, TPM, pkcs11)
<kirkland> pitti: it probably could be made to do so
<pitti> ah, so it isn't really meant for managing the mounts
<kirkland> pitti: not currently, no.... key management more so it's currently duty
<pitti> kirkland: my idea was to start a daemon in the background on login which will trigger the umount when it exits
<pitti> but having a daemon for each logged in user which does nothing all the time doesn't make me too happy either
<kirkland> pitti: right
<pitti> so if that's done by a central daemon, that would be much more useful
<kirkland> pitti: perhaps, but i keep asking myself if entries in /etc/fstab are really that horrible
 * pitti doesn't like constantly changing configuration files
<kirkland> pitti: constantly?
<kirkland> pitti: it would only get changed on adduser
<pitti> and it's subject to all sorts of race conditions, confuses backup software, etc.
<kirkland> pitti: well, userdel too
<pitti> kirkland: oh, not on login? (dynamically creating a stanza for logout)
<kirkland> pitti: no no no
<pitti> kirkland: if it's that static, how do you handle NIS, AD, etc.?
<kirkland> pitti: :-)
<kirkland> pitti: local users only
<pitti> kirkland: but seriously, I'd rather teach umount to allow you to umount your own ecryptfses than fiddling with fstab
<kirkland> pitti: at this point
<kirkland> pitti: okay
<kirkland> pitti: the guys i had dinner tonight with were talking about some new "user mounts" work in the kernel
<kirkland> pitti: someone named Mikko? working on it, i think
<kirkland> pitti: not in yet, perhaps -mm?
<pitti> kirkland: so if you could do "umount ~/Private" as normal user, that would basically solve it with pam-mount?
<pitti> that approach is pretty much what we did with pmount in warty to breezy
<kirkland> pitti: i think so
<kirkland> pitti: i'll create a super-umount tomorrow and test it out
<kirkland> pitti: for testing purposes ;-)
<pitti> and umount already allows users to umount stuff
<kirkland> pitti: if its in /etc/fstab, yeah
<kirkland> pitti: and is set as a "user" mount in the options
<pitti> kirkland: so, ecryptfs-utils could ship wrappers "ecryptfs-mount" and "ecryptfs-umount" which do pretty much that
<pitti> check that what you try to do is sane, and call mount/umount
<pitti> that's not a highly elegant solution, but it's doable in intrepid with the technology that we have today
<pitti> and if it's hidden in a PAM module, we can transparently change the technology to kernel user mounts later
<pitti> "it" -> the call to ecryptfs-umount
<pitti> kirkland: actually we won't even need e-mount, right?
<kirkland> pitti: that's pretty much what i've created, see ....  http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=blob_plain;f=src/utils/ecryptfs-mount-confidential;hb=HEAD and http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=blob_plain;f=src/utils/ecryptfs-umount-confidential;hb=HEAD
<pitti> just e-umount, and that just needs to traverse /proc/mounts and compare uid, path (owned by caller), and fstype
<pitti> kirkland: right, except you need to write that in C, so that you can suid root it (and add more defensive checks)
<kirkland> pitti: sure, that's doable
<pitti> kirkland: feel free to look at pumount.c and take the sanity checks from it
<kirkland> pitti: thanks for the pointer, i'll do that
<kirkland> pitti: so i can store the mount options as variables i store in a ~/.ecryptfsrc file or something
<kirkland> pitti: source that (read in C)
<kirkland> pitti: sanity check
<kirkland> pitti: and suid do the mount for the uesr
<pitti> kirkland: what would be in that file?
<pitti> kirkland: AFAICS, you don't need to permanently store anything else than the encrypted key, right?
<kirkland> pitti: cypher type, key length, key fingerprint
<pitti> right, so basically the key and its metadata
<kirkland> pitti: yeah
<pitti> kirkland: but why do you need that on umount?
<kirkland> pitti: and the data dir and mountpoint
<kirkland> pitti: in case you want it somewhere other than ~/Private (IBM uses ~/Confidential)
<kirkland> pitti: oh, not on umount
<pitti> kirkland: no, you should get that as a command line arg, and verify it in /proc/mounts
<pitti> please don't store information about mounts in ~
<kirkland> pitti: sorry, i was thinking about writing both e-mount and e-umount
<pitti> kirkland: ah, I see
<pitti> yes, that makes more sense; so the user can choose which dirs to mount on login
<kirkland> pitti: as you see above, i have both in shell form now
<kirkland> pitti: also, i like changing the perm on the ecrypted underlying dir to 500 when not mounted
<kirkland> pitti: to keep from inadvertently writing something in there unencrypted
<kirkland> pitti: as well as the mountpoint (same reason)
<kirkland> pitti: but keep r-x------ for backup purposes
<pitti> right
<kirkland> pitti: that's sort of a custom job for these sorts of mounts
<kirkland> pitti: and on mount, we have to bump up the perms to 700
<pitti> kirkland: I hope the mount script doesn't come from upstream, but is just a local test script of your's :)
<kirkland> pitti: it's evolving
<pitti> (I mean because of the nice root privilege escalation)
<kirkland> pitti: ?
<kirkland> pitti: those two scripts are not currently setuid
<kirkland> pitti: b/c they rely on the mounts being in fstab
<kees> good evening
<pitti> no, but they certainly run as root, don't they?
<kirkland> pitti: /bin/mount and /bin/umount are setuid
<kirkland> pitti: nope
<kirkland> pitti: they don't
<pitti> kirkland: ah, I thought you'd call them from pam
<pitti> hey kees
<kirkland> pitti: no, i call them from .bash_profile and .bash_logout
<pitti> kees: highlight on "root privilege escalation"?
<kirkland> pitti: and .config/autostart/foo
<kirkland> kees: :-)  howdy
<kees> pitti: hahah, no, but I should.  ;)
<kees> (actually highlighted on "regression" for a while back)
<kees> I'm just up doing xorg publication
<kirkland> pitti: you with me now?
<pitti> kirkland: yep, sure
<kirkland> pitti: pam as root unwraps your mount passphrase and inserts it into your kernel keyring
<pitti> kirkland: so the umount script will have s/umount/ecryptfs-umount/
<kirkland> pitti: okay....
<pitti> and the mount one will run from pam as root (and thus needs robustification), or do you want to create an ecryptfs-mount (which then needs to be robust)?
<pitti> Mithrandir: good morning
<Mithrandir> pitti: hiya, how's intrepid going?
<pitti> Mithrandir: I don't know much TBH; I'm still on hardy duty
<kirkland> pitti: i don't think i follow your last statement
<Mithrandir> ah, wrapping up all the loose bits so .1 will shiny like, uh, something shiny?
<pitti> Mithrandir: exactly! *bling*
<pitti> kirkland: I meant, what's your final design for the mount step on login? from pam as root, or from the user's account with a suid root ecryptfs-mount?
<kirkland> pitti: so if pam_mount worked as advertised, i'd use that.  and by that i mean if it were able to both mount and unmount, I'd prefer using it.
<kirkland> pitti: if that can be solved, i'm all for it.  i want to talk to cjwatson a bit more about the ssh end of it
<pitti> kirkland: ok; looking forward to trying it out eventually :)
<kirkland> pitti: b/c it works for local user locals on the console, but not ssh
<pitti> kirkland: "b/c"?
<kirkland> pitti: oh, b/c means that this is an ssh issue
<kirkland> b/c = because
<kees> Mithrandir: ah, your appearance has reminded me to post my zombie meme
<pitti> kirkland: well, if the problem is only on the umount side, and solved with ecryptfs-umount, then everything using pam, including ssh, should work with it
<kirkland> pitti: there's one other side effect of the ssh/pam_mount bug, that might be fixed separately
<kirkland> pitti: pam_mount accounts the number of open sessions a user has in /var/run/pam_mount/username
<kirkland> pitti: increments/decrements it
<Mithrandir> kees: zombies > *
<kirkland> pitti: but on ssh logout, the pam_session_close running as uid 1000 doesn't have sufficient privilege to decrement
<Mithrandir> kees: I was wondering how much I should have made mine D&D-themed.
<kirkland> pitti: i think that can probably be solved by changing the group ownership and g+w of that file
<kirkland> pitti: so let me see if i can get an suid ecryptfs-umount working
<kirkland> pitti: is that the one you were suggesting should be in C?
<pitti> kirkland: yes, to be able to suid root it
<pitti> kirkland: eww @ user-writable reference counter
<pitti> why does it need to be in a file in the first place?
<kirkland> pitti: after my 48 hours with pam_mount, i have a very low opinion of the module in general
<pitti> 'who' knows about all sessions, so they must be stored *somewhere*
<kees> Mithrandir: heh.  I liked it as is.  I haven't been able to think of a better famous person.  :)
<pitti> kirkland: right, I'm not saying that you should use exactly pam_mount; yesterday I just thought that it does a very similar thing, and that it might be worth taking a look at it
<Mithrandir> kees: the archangel gabriel might work well too.
<kirkland> pitti: i point you back to my script .... http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=blob_plain;f=src/utils/ecryptfs-umount-confidential;hb=HEAD
<kirkland> pitti: note the call to `who | grep | wc `  ;-)
<Mithrandir> anyway, off to work. :-)
<pitti> kirkland: right, I know; I just wonder why the heck libpam-mount does it that way
 * Hobbsee_ waves
 * RAOF shores
<kees> heya Hobbsee_
<Hobbsee_> kees!
<kees> how goes it?  I'm up this late so rarely.  :P
<Hobbsee_> kees: just done the evil networkign exam.
<Hobbsee_> kees: so i'm glad that's over :P
<kees> oooh, computer networking?
<Hobbsee_> yeah.
<Hobbsee_> would be good, if they can actually mark correctly.  *shrug*
<Hobbsee_> but when two people give the same answer, and one gets marked right, and one wrong, it's not exactly inspiring confidence :P
<kees> Hobbsee_: ewww
<kees> Hobbsee_: just general networking, or some specific sub-topic?
<Hobbsee_> kees: general.
 * Hobbsee_ heads home, hoping to aviod the traffic.
<pitti> seb128: hm, seems that the SRU in bug 209662 didn't fix the problem?
<ubottu> Launchpad bug 209662 in deskbar-applet "<defunct> processes" [Low,Fix committed] https://launchpad.net/bugs/209662
<pitti> seb128: oh, good morning!
<seb128> hey pitti
<seb128> pitti: right
<seb128> pitti: but there is no regression either and it fixes several other issues
<pitti> seb128: did you try out the .debs from -proposed?
<pitti> seb128: if it generally works, I'm fine with copying and reopening the bug
<seb128> pitti: yes, I'm running it on my laptop and old old desktop without issue
<pitti> ok, thanks
<seb128> pitti: and no bug has been opened on launchpad about it recently either
<seb128> mvo: hey
<mvo> hey seb128
<seb128> mvo: could you have a look to http://launchpadlibrarian.net/15239248/buildlog_ubuntu-intrepid-i386.compiz-fusion-plugins-extra_0.7.6-0ubuntu1_FAILEDTOBUILD.txt.gz today? it's making compiz not installable on intrepid
<mvo> seb128: sure
<seb128> thank you
<mvo> whos archive-admin day is today? I filed some sync requests last week and would like to ask about those :)
<pitti> o/
<seb128> pitti: I can give you a hand on archive admin tasks if you want, I've been too busy on wednesday to do a lot of those again
<mvo> pitti: do you plan to check on the syncs today? its not urgent, but it would be nice to get them off the list on merges.u.c
<pitti> seb128: that would be great; still working on SRUs, but I'll do archive admin later (I also need to tend to MIR, argh)
<pitti> mvo: yes, definitively
<pitti> seb128: what would you like to start on?
<seb128> pitti: ok, doing syncs and backports now
<mvo> I tihnk I should apply too, looks like we could do with some more hands
 * pitti hugs seb128
 * seb128 hugs pitti
 * mvo waves to davmor2
<davmor2> morning mvo :)
<sladen> germany finally had rain
<mvo> lots of it yesterday
<pitti> seb128: I'll start off with removals, archive bugs, and component-mismatches then, and go on with MIR
<pitti> seb128: you'll also do a sync-source -a?
<seb128> pitti: yes, I've done some of those yesterday already
<seb128> pitti: will do an another one now
<seb128> pitti: I'll try to tacklo some of the NBS list too
<pitti> oh, great, thanks!
<\sh> sladen: still in .de?
<\sh> I wonder if there is any possibilty to make urllib2 report a progress of the connection/reading/closing socket state....as urllib.urlretrieve can do via hook
 * Hobbsee waves
<RAOF> Hobbsee: Back home?
<thekorn> \sh, you can read the content block-wise in a loop
<\sh> thekorn: yes...but this is not working, because for that I would have to change pylpbugs ;)
<\sh> thekorn: question is, I need to show the user a infobox while the buglist e.g. is being fetched...(which takes time)...and for this i need something like a hook inside pylpbugs which gives me a status somehow
<thekorn> \sh, hehe, you are right, I think it's easy to add such a hook interface to py-lp-bugs,
<thekorn> I think there is a bugreport open for this
<thekorn> \sh, btw. nice LP gui! did you publish the source somewhere?
<\sh> thekorn: yes...it's on my lp code page...brb meeting
<thekorn> ok, cool
<seb128> Lutin: hi
<seb128> Lutin: when you open sync request could you describe what the ubuntu changes are instead of writting that they are all in debian now which is expected anyway if you open a sync request
<seb128> Lutin: thank you
<thekorn> \sh, I added a patch to bug 239684 to add such progress-hook thing to py-lp-bugs
<ubottu> Launchpad bug 239684 in python-launchpad-bugs "add progress-hook to HTTPConnection" [Undecided,New] https://launchpad.net/bugs/239684
<\sh> thekorn: cool...I'll test it later...estimation meeting done...new infrastructure meeting now....my life is doomed now ;)
<pitti> Riddell: hm, all kde-i18n-* were demoted to universe in intrepid; component-mismatches complains now (seeded in DVD); was this deliberate or a glitch?
<seb128> pitti: if you do seed edition please drop workrave too ;-)
<pitti> seb128: demoted
<seb128> danke
<pitti> I'm not currently touching seeds, though
<pitti> so, NEW and hardy-proposed queues empty; nobody touch anything now! :-)
<seb128> pitti: and syncs cleaned
 * mvo hugs seb'sync-master'128
 * pitti hugs seb128
<pitti> seb128: you said you're going to do the backports as well? doing the other archive-admin bugs now
<seb128> pitti: there is almost no backports to do in fact, will have a look later, I want to catch up on bug mails first now
<pitti> right; thanks
<seb128> np, feel free to do the few backports listed in the bug list
<seb128> I'll do those later otherwise
 * pitti does the remaining two syncs
<seb128> pitti: the flushing is in progress btw
<pitti> oh, ok; will wait
<Riddell> pitti: kde-i18n can be unseeded
<Riddell> replaced with kde-l10n-*
<pitti> aah
<pitti> Riddell: so the packages shuold actually be removed then?
<Riddell> pitti: the translations are still useful for some apps that don't have kde 4 versions (kdevelop, quanta)
<seb128> pitti: ok, manual and autosyncs flushed now, enjoy ;-)
<Riddell> but nothing in main
<pitti> ah, -i18n -> KDE3, l10n -> KDE4 only
<Riddell> pitti: exactly
<pitti> Riddell: ok; I won't touch it then
<pitti> thanks for the heads-up
<psypointer> good morning
<psypointer> is it possible to automatically restart the computer if an installation via pxe and preseed failed?
<apachelogger_> pitti: hey, I think kopete-plugin-thinklight 0.3-0ubuntu3.1 can be moved to -updates, see bug 221531
<ubottu> Launchpad bug 221531 in kopete-plugin-thinklight "Thinklight doesn't blink because /proc/acpi/ibm/thinklight has wrong permissions" [Undecided,Fix released] https://launchpad.net/bugs/221531
<pitti>  apachelogger_: hmm, no SRU task?
<pitti> and the bug doesn't mention who accepted it
<pitti> nor an ACK from ~motu-release
<apachelogger_> pitti: Riddell did
<pitti> this is heavily non-SRU compliant
 * pitti subscribes motu-sru
<pitti> apachelogger_: bug updated
<apachelogger_> pitti: ok, thanks
 * apachelogger_ pokes \sh and ScottK
<Hobbsee> RAOF: eyah
 * \sh peeks apachelogger
<apachelogger> \sh: bug 221531
<ubottu> Launchpad bug 221531 in kopete-plugin-thinklight "Thinklight doesn't blink because /proc/acpi/ibm/thinklight has wrong permissions" [Undecided,Fix committed] https://launchpad.net/bugs/221531
<\sh> apachelogger: yepp.after acked...next time, you'll get a kick ;)
<apachelogger> \sh: fair enough
 * apachelogger creates a knote with the SRU wiki page
<\sh> thekorn: regarding the patch in bug #239684 .. you didn't commit it, right? so I can create my own branch to test this
<ubottu> Launchpad bug 239684 in python-launchpad-bugs "add progress-hook to HTTPConnection" [Undecided,New] https://launchpad.net/bugs/239684
<thekorn> \sh, right i did not commit it yet, since I had no chance to test it much
<\sh> thekorn: I'll do that now/1h/this evening...depending on my workload :=
<thekorn> \sh, no problem, please comment on this bug if something does not work as you expected so I can work on it over the weekend
<DktrKranz> pitti, could you please reject oggconvert upload in hardy-proposed? I included wrong bug # :(
<Hobbsee> DktrKranz2: done
<DktrKranz> Hobbsee, thanks :)
<Hobbsee> you're welcome
 * \sh hates perl modules with a version number of 0.01
<emgent> heya
<\sh> uh..who updated the sync mechanism to send out accepted mails ? :)
<pitti> DktrKranz2: done
<pitti> DktrKranz2: oh; seems Hobbsee already did it and you uploaded a new one?
<Hobbsee> hmmm.  totem is broken
<DktrKranz2> pitti: yes. I uploaded a correct version.
<cjwatson> \sh: they always did for manual syncs
<cjwatson> \sh: note, it's a manual decision by the archive administrator operating the mechanism whether mails get sent out or not, so sometimes mistakes are made
<DktrKranz2> do autosyncs still happen?
<DktrKranz2> several packages are not up-to-date
<cjwatson> DktrKranz2: yes
<cjwatson> DktrKranz2: example?
<DktrKranz2> cjwatson: wink
<ogra> they happen for everything without ubuntuX versioning
<DktrKranz2> sid has 1.5.1060-5, intrepid 1.5.1060-4
<cjwatson> DktrKranz2: they have to be run separately for main, contrib, and non-free, so it may be that they've only been run for main lately
<cjwatson> I'll do a contrib/non-free pass now
<DktrKranz2> cjwatson: ah... didn't know that. thanks.
<cjwatson> (wink is non-free)
<\sh> cjwatson: I wasn't seeing that as mistakes...I was wondering, because in former times no accept mails were send out to the sync requestor
<cjwatson> \sh: that would have been mistakes
<cjwatson> \sh: I don't recall a time when such messages were intentionally not sent
<DktrKranz2> cjwatson: does autosync take XbuildY packages and sync them automatically without developer attention?
<cjwatson> DktrKranz2: yes; only the substring "ubuntu" suppresses syncs
<DktrKranz2> ARGH
<DktrKranz2> so, there could be regressions in freeradius
<cjwatson> you'll need to reupload properly, then
<cjwatson> this is not new - Ubuntu has behaved this way since warty
<DktrKranz2> yes, I saw a package which introduced ubuntu deltas with a XbuildY version scheme during hardy
<cjwatson> well, perhaps the hoary sync process :-) but it was certainly advertised during warty
<DktrKranz2> so I guess it should be checked for regressions
<cjwatson> DktrKranz2: sometimes that's deliberate since it's known that the change should go away
<DktrKranz2> cjwatson: I'll check and eventually ping uploader. thanks.
<cjwatson> looks like it was zul
<cjwatson> and that the diff from 1.1.7-1build2 to 1.1.7-1build4 needs to be reapplied
<ScottK> DktrKranz2: I've seen Ubuntu changes introduced with XbuildY when the uploader knew they would be in Debian by the time autosync ran for Intrepid.  I think that's a reasonable labor saving approach.
<cjwatson> in this case it's a clear mistake, I'll send mail
<DktrKranz2> ScottK: good point.
<pecisk> people, when there is string freeze for debian-installer and stuff for 8.04.1?
<cjwatson> there shouldn't have been string changes since before 8.04 ...
<pecisk> ok, question then - do 8.04.1 release means that debian-installer will get newest translation for certain language?
<cjwatson> pecisk: it has had some updates
<cjwatson> pecisk: but we won't be going through and reuploading all udebs (installer components) - enormously labour-intensive, I'm afraid
<pecisk> heh
<pecisk> I just did a huge job to fix lv
<pecisk> would be sad not to see that in 8.04.1
<cjwatson> pecisk: the best way to fix d-i translations is to do it in d-i upstream, by far
<cjwatson> pecisk: I'm afraid it's simply impractical to do lots of that in Ubuntu
<cjwatson> pecisk: ubiquity and oem-config have been reuploaded, I know
<cjwatson> (obviously you have to translate Ubuntu-specific strings in Ubuntu)
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/ubiquity/ubiquity/debian/po>$ msgfmt -o /dev/null --statistics lv.po
<cjwatson> 196 translated messages, 11 untranslated messages.
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/oem-config/oem-config/debian/po>$ msgfmt -o /dev/null --statistics lv.po
<cjwatson> 26 translated messages.
<doko> 35mb sucked in when trying to install devscripts
<seb128> doko: yeah for recommends by default ;-)
<pecisk> cjwatson: hmmm, didn't know that ubquity and oem-config is seperated modules. Though it all in debian-installer
<cjwatson> pecisk: in Launchpad translations, they're all presented in debian-installer
<cjwatson> pecisk: but the actual packages are split out
<pecisk> cjwatson: ahh I see. Well, I have po still on my computer, because I have few corrections left to do. Is it still possible to upload it and it will be in 8.04.1 or it is already gone now?
<cjwatson> pecisk: afraid it's likely to be too late
<cjwatson> pecisk: 8.04.1 needs to undergo testing and recertification before release, which means final images need to be ready well before the release date
<pecisk> I see
<pecisk> well, nevermind
<cjwatson> DktrKranz2: wink's on its way in now
<pecisk> cjwatson: 8.04.2 was planned in next year somewhere yes?
<cjwatson> pecisk: six months from 8.04.1, roughly
<pecisk> ok, I see
<pecisk> well, not such big tragedy :)
<pecisk> thanks for info
<DktrKranz2> cjwatson: thanks.
<pitti> DktrKranz2: ok, then I killed your 'good' one; hang on
<pitti> DktrKranz2: unrejected and accepted
<DktrKranz2> pitti: thanks and sorry for the mess
<pitti> DktrKranz2: not your fault, no problem
<asac> where can i get the latest 8.04.1 images?
<\sh> thekorn: did you read my comments? :)
<thekorn> \sh, yes I'm on it
<thekorn> \sh, I understand why you get a set of 7 bugs, instead of 8
<\sh> thekorn: let me guess: duplicates or "same bug number" ;)
<thekorn> \sh, because you are assigned to 7 different bugs, but 8 tasks
<cjwatson> asac: http://cdimage.ubuntu.com/hardy/
<\sh> thekorn: ok..that was what I was suspecting
<thekorn> \sh, with    BugList = ConnectBugList(all_tasks=True)   you get 8 bugs
<asac> cjwatson: thanks. i thought i looked there. wierd
<thekorn> \sh, but the don't really understand how you made it to get a list of 6 bugs
<thekorn> i can't reproduce it
<doko> pitti: any opinion to promote libssh for intrepid now?
<\sh> thekorn: hmm
<\sh> thekorn: trying to get more numbers from inside the http_connection...
<\sh> lp down?
<Pici> \sh: seems that way.  I though I saw an email about LP downtime, but I cant seem to find it or remember the dates/times
<pitti> doko: why do we want it so badly again?
<cjwatson> Pici: LP downtime is next week
<doko> pitti: curl
<Pici> cjwatson: Ah, thanks
<doko> pitti: but I can drop it again
<pitti> I'm still not happy about a second ssh implementation TBH
<doko> ok
<doko> then please finally reject the mir
<pitti> ok
<mterry> LP looks like it's back up
<tkamppeter> Anyone around who can do fixes on the HPPA build server? After uploading foomatic filters I got a
<tkamppeter> The following packages have unmet dependencies:
<tkamppeter>   cdbs: Depends: intltool but it is not going to be installed
<tkamppeter>   libgs-dev: Depends: libgs8 but it is not going to be installed
<tkamppeter> E: Broken packages
<Hobbsee> tkamppeter: likely lamont
<tkamppeter> from the HPPA build server.
<lamont> Hobbsee: inifinty
<Hobbsee> slangasek: er, when are you going to do the point release for 8.04?
 * lamont doesn't mess with the buildd chroot stuff
<Hobbsee> lamont: oh, i thought you were still the hppa guy
<lamont> I am the hppa guy
<pitti> tkamppeter: just ignore hppa for now; ATM it's hopelessly out of date
<pitti> tkamppeter: once the basic packages get fixed, someone will do a mass build-retry anyway
<lamont> now, if it's just that it's out of date, yeah... that's a "pester lamont" thing
<pitti> oh, hi lamont
<lamont> g'morning
<tkamppeter> Thanks, lamont.
<lamont> hppa usually catches up right after the freeze for an alpha. :-)
<tkamppeter> And also thanks, pitti
<lamont> hah.  sparc is further behind than hppa.
<pitti> lamont: most ftbfs I saw were due to intltool
<lamont> tkamppeter: which package was that?  (example, please?)
<qense> ping persia
<hwilde> Keybuk, how do I get udevinfo for network interfaces?
<Keybuk> hwilde: what are you trying to do?
<hwilde> Keybuk, I want to make net70 persistent based on vendorid instead of mac
<Keybuk> udevinfo -ap /class/net/ethX ?
<pitti> oh, wow, I wasn't aware that you can do "less foo.deb" and it would do something really sensible
<seb128> pitti: waouh, me neither ;-)
<pitti> (dpkg -I and dpkg -c concatenated)
<pitti> that eases review/MIR
<dholbach> pitti: where did you find out? :)
<pitti> just by accident
<pitti> I would have never done it deliberately
<mario_limonciell> woah that's neat pitti.  great find
 * ogra knew that .... but nobody asked :P
<hwilde> Keybuk, http://pastebin.com/m5ada7265  is it ok to use DRIVERS== for the net rules,  or can I use partial MACs somehow like the first four?
<sistpoty|work> ogra: other cool things you can show us? :P
<ogra> sistpoty|work, if you ask for particular ones :P
<sistpoty|work> ogra: heh
<kirkland> cjwatson: hey, what's the name of the utility that you showed me that used apt-get to pull and extract individual manpages from debs?
<Keybuk> hwilde: either
<Keybuk> hwilde: you can match on anything udevinfo gives you
<Keybuk> and can use wildcards
<cjwatson> kirkland: debman
<cjwatson> kirkland: it's in the debian-goodies package
<cjwatson> kirkland: there's also debmany, which is a neat idea, though I didn't write that myself and haven't looked at it much
<tkamppeter> lamont, it was foomatic-filters what I uploaded and the problems were with intltool and libgs, see http://launchpadlibrarian.net/15261599/buildlog_ubuntu-intrepid-hppa.foomatic-filters_4.0.0%7Ebzr144-0ubuntu1_FAILEDTOBUILD.txt.gz and https://launchpad.net/ubuntu/+source/foomatic-filters/4.0.0~bzr144-0ubuntu1
<qense> retry: ping persia
<mathiaz> kees: I've been using mk-sbuild-lv lately to re-create my intrepid chroot and exim4 is installed by default now
<tkamppeter> Anyone around who can fix things on the build servers?
<kees> mathiaz: interesting -- did something change?
<cjwatson> tkamppeter: is this still about intltool et al? that isn't a buildd problem, the packages are just plain uninstallable on that architecture
<mathiaz> kees: well - apt installs Recommends by default now
<kees> erg
<mathiaz> kees: I wonder if something pulls exim4 in
<kees> should I switch it to not doing that in the script?
<cjwatson> tkamppeter: this is very common in the early stages of merging up a new release
<cjwatson> tkamppeter: and, while it needs to be fixed, generally isn't something that people should get too worried about
<tkamppeter> cjwatson, this time I got also a failure on amd64.
<cjwatson> tkamppeter: link please
<cjwatson> tkamppeter: anything of the form "package <blah> could not be installed" is with 99% probability not a build daemon problem
<tkamppeter> I tells only about libgs8 and not about intltools: https://edge.launchpad.net/ubuntu/+source/foomatic-filters/4.0.0~bzr144-0ubuntu1 and http://launchpadlibrarian.net/15265721/buildlog_ubuntu-intrepid-amd64.foomatic-filters_4.0.0%7Ebzr144-0ubuntu1_FAILEDTOBUILD.txt.gz
<cjwatson> we've had this conversation in previous release cycles, I'm certain :)
<cjwatson> tkamppeter: look at http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html; note that libgs-dev is listed as uninstallable on amd64
<mathiaz> kees: according to mvo emails, it may worth using the --no-install-recommends option
<mathiaz> kees: in the finish script - I'll try that
<cjwatson> it may well be collateral damage from something else, considering the huge list of uninstallables
<kees> yeah, that's what I was thinking.  let me know if that works and I'll add it.
<cjwatson> tkamppeter: the best way to find out what's going on is to bootstrap an intrepid chroot and try to install the package by hand, then sometimes you have to manually drill down by trying to install the subsequent packages it complains about
<mvo> kees, mathiaz: at recommends a mail-transport-agent, that probably brought it in
<mvo> same for cron
<tkamppeter> Seeing the list of uninstallables nearly everything is uninstallable ...
<cjwatson> tkamppeter: I imagine that libgtk2.0-0 being uninstallable isn't helping much
<cjwatson> (for starters)
<tkamppeter> cjwatson, what I would also like to see is why the listed packages are uninstallable.
<tkamppeter> I am building a pbuilder chroot now to see whether Intrepid is really so broken.
<cjwatson> tkamppeter: testing is rarely wrong, just underinformative :-)
<cjwatson> testing> by which I mean the list at that URL
<mathiaz> mvo: yeah - or mailx
<mathiaz> kees: adding --no-install-recommends fixes the issue
<cjwatson> tkamppeter: I think the problem is that libkrb53 and friends got demoted to universe for some reason
<cjwatson> tkamppeter: so I'll fix that
<mathiaz> kees: there are two places where you could add - the first one when gnupg and ubuntu-keyring is installed
<mathiaz> kees: I don't think you need to add the --no-install-recommends there as it just brings ca-certificates in
<mathiaz> kees: the second call is when you install more packages (devscripts, etc...) - that's where I'd add --no-install-recommends
<kees> mathiaz: cool, thanks for testing that, I'll get it added
<cjwatson> tkamppeter: given that purging that from my chroot takes out ubuntu-minimal, that ought to fix a good pile of uninstallables :)
<mathiaz> kees: http://paste.ubuntu.com/19932/
<cjwatson> (it'll take about 1.5 hours for that to propagate though)
<slangasek> Hobbsee: 8.04.1 is for the beginning of July
<cody-somerville> slangasek, make the Xubuntu builds stop failing :P
<slangasek> cody-somerville: the powerpc ones?
<cody-somerville> ;]
<cody-somerville> slangasek, Were they failing last release cycle too?
<cjwatson> yes, they were
<cjwatson> it's an awkward corner case with ports vs. universe
<cjwatson> to do with how the mirror on cdimage is arranged
<cjwatson> do you have anyone who actually cares about Xubuntu on powerpc? for now, the pragmatic course might be to disable those builds
<cody-somerville> I think people use it for the playstation?
<cjwatson> cody-somerville: oh, ugh, true
<tkamppeter> cjwatson, pbuilder is currently not able to build an Intrepid chroot on 64-bit. It says
<tkamppeter> The following packages have unmet dependencies:
<tkamppeter>   gnupg: Depends: libkrb53 (>= 1.6.dfsg.2) but it is not installable
<tkamppeter>   libcurl3-gnutls: Depends: libkrb53 (>= 1.6.dfsg.2) but it is not installable
<tkamppeter> E: Unmet dependencies. Try using -f.
<cjwatson> tkamppeter: perhaps you missed the comments I made above?
<cjwatson> 18:05 <cjwatson> tkamppeter: I think the problem is that libkrb53 and friends got demoted to universe for some reason
<cjwatson> 18:05 <cjwatson> tkamppeter: so I'll fix that
<cjwatson> 18:07 <cjwatson> tkamppeter: given that purging that from my chroot takes out ubuntu-minimal, that ought to fix a good pile of uninstallables :)
<cjwatson> 18:08 <cjwatson> (it'll take about 1.5 hours for that to propagate though)
<cjwatson> the current time is 18:45 by my clock
<tkamppeter> Sorry, I left for dinner and than looked at the result of my pbuilder run.
<bXi> hello
<bXi> i've written a tool which i want to distribute
<bXi> but i dont know if its frowned upon if i'd make the application SUID root
<bXi> (its a frontend to mount basicly)
<slangasek> yes, it's frowned upon :)
<bXi> can you recommend something else then?
<slangasek> well, sometimes it's necessary
<slangasek> but there will be plenty of frowning among the security folks any time you proposed to introduce a new SUID app
<bXi> i was thinking about using gksu to run it
<kees> bXi: I recommend examining how PolicyKit works
<bXi> policykit
<bXi> roger
<bXi> can i put my code up for review somewhere?
<kees> bXi: basically, there are backends registered with PolicyKit to do certain actions, and those actions are requested over dbus, etc.
<kees> bXi: anywhere is good, but I'd recommend possibly REVU, if it's been packaged
<bXi> it hasnt been packaged into someething normal yet
<cjwatson> or if you're using bzr for it, point people to the appropriate URL on bazaar.launchpad.net for code browing
<cjwatson> browsing
<bXi> i havent put it up anywhere yet
<kees> bXi: in that case, I'd recommend getting it into a bzr branch on launchpad: https://wiki.ubuntu.com/BzrMaintainerHowto
<bXi> was thinking of making a sourceforge project out of it
<wasabi> Hmmmm.... preseeding mirror/http/proxy ain't working. =(
<wasabi> n/m my fault.
<slangasek> TheMuso: are 221673 and 191027 the only bugs expected to be closed in this SRU?  I thought there were more
<slangasek> TheMuso: it would have been helpful if you had mentioned all of the related bugs in the usual changelog syntax, so that they would show up automatically on http://people.ubuntu.com/~ubuntu-archive/pending-sru.html for tracking; obviously not a change to reupload for in this case, but please bear it in mind for future SRUs :)
<cjwatson> tkamppeter: intrepid uninstallables list looks a lot happier now; I suggest hitting the retry button on the builds of yours that failed
<ScottK> brandonperry: All the Ubuntu clamav packages are pretty current.  What is it you think needs to be packaged?
 * ScottK just read you on planet.
<slangasek> cody-somerville: so I can't really see a good, quick fix for the xubuntu/ppc failures (now that I look at the error messages, I remember why this problem exists); so I can disable the builds to suppress the error mails, or we can keep getting the daily error mails as a nag-minder, your choice :)
<cody-somerville> slangasek, we can do the latter if you set it to e-mail ubuntu-devel too ;]
<slangasek> heh, not so much
<slangasek> so you'd prefer that I disable the builds until someone can look at it?
<cody-somerville> Well, maybe infinity could take a look?
<slangasek> it's an issue with the cdimage setup, infinity would happily punt that problem back at me anyway :)
<cjwatson> slangasek: maybe the best approach would be to have anonftpsync.ports pull universe and multiverse? I don't think we care so much if universe/multiverse leaks into Ubuntu ports CDs by accident, really
<slangasek> ok
 * cody-somerville cheers.
 * cjwatson makes a small change to anonftpsync to support that
<cjwatson> should be in principle possible to say RSYNC_EXCLUDE= now
<slangasek> cjwatson: which of the various d-i merges, if any, are in progress on your end right now?
<mathiaz> is it normal that ubuntu-standard pulls stuff from universe ?
<slangasek> mathiaz: apt-get with recommends-by-default may do so
<slangasek> mathiaz: since I'm sure the recommends in main aren't tested for closure
<cjwatson> slangasek: base-installer and debian-installer itself; I'd also like to do localechooser
<slangasek> ok
<mathiaz> slangasek: right - but ubuntu-standard *shouldn't* pull anything from universe ?
<cjwatson> not bothered about the rest, although I think partman-target's status was odd because it had something in trunk which I thought was supposed to be for hardy
<cjwatson> mathiaz: libkrb53? should be fixed if you update
<slangasek> mathiaz: I think that's a question that's been insufficiently explored to date, since the change to recommends-by-default has only just been made :)
<cjwatson> evand: were you planning to do anything with bug 224446? it has a hardy task
<mathiaz> cjwatson: oh no - I've just installed ubuntu-standard in an intrepid chroot - I saw a couple of packages downloaded from universe (ex apparmor-profiles)
<ubottu> Launchpad bug 224446 in ubiquity "lack of installer permission validation on existing partition" [Medium,Fix committed] https://launchpad.net/bugs/224446
<cjwatson> mathiaz: at the moment, germinate doesn't follow recommends, so that sort of thing will be improperly checked
<cjwatson> I am fairly certain that installing ubuntu-standard *ought* not to pull anything from universe, though as slangasek says it's early days
<mathiaz> cjwatson: ok - but the goal is to have ubuntu-standard only pull things from main
<cjwatson> that's correct
<mathiaz> cjwatson: ok - thanks for the clarification
<cjwatson> slangasek: I think localechooser and debian-installer itself are the only remaining blockers to being able to build a vaguely working installed
<cjwatson> installer
<slangasek> cjwatson: ok, cool
<cjwatson> the other bits are outside the initrd
<cjwatson> I'm most of the way through debian-installer, just figuring out what to do with the switch to syslinux' vesamenu system
<tedg> kees: You know more about gcc than I do... why does this come out 0, 0, 5, 5?  http://pastebin.ubuntu.com/19958/
<tedg> It seems like the pointer shouldn't even be valid to come up with a zero.
<slangasek> tedg: er, is that valid to initialize myvar_pa and myvar_ca like that above the declarations of myclass_a and myclassp_a?
<slangasek> tedg: I'm having a visceral reaction to the sight of this much overt C++-ism :)
<evand> cjwatson: ah, definitely.
<tedg> slangasek: It doesn't give a warning... and it seems like it should be with the externs in there.  But it would seem to me atleast, that it should create some sort of dependency graph instead of working them in order.
<cjwatson> slangasek: I think with my launchpad-integration upload and my moves of krb5 and gmime2.2 binaries back to main (they'd landed back in universe for mysterious reasons), ubuntu-desktop/intrepid should be installable again after a couple of publisher runs
<slangasek> cjwatson: excellent!
<tedg> slangasek: It's small example of a bigger problem I'm having, but the linking is alot crazier.
<slangasek> cjwatson: how did krb5 get bumped to universe, btw?
<cjwatson> slangasek: I have no idea
<cjwatson> obviously it took out half of main for installability
 * slangasek nods
<cjwatson> rather freaked me out to be perfectly honest
<cjwatson> evand: maybe 6.06.2 at this point ...
<slangasek> tedg: well, AFAIK even in C++, extern just tells the compiler that it's allowed to resolve references to this object by way of other object files; given that the part that's misbehaving is precisely the part that looks wrong to me (querying get_var() above the initialization within the source file), I suspect that the C++ standards don't allow this? :)
<evand> ok
<cjwatson> evand: (just a suggestion; it does feel late to be shoving it in, though, given it's an edge case)
<tedg> slangasek: The problem comes to when I put these in lots of different files, it's virtually impossible to determine the initialization order.
<evand> indeed, though I agree.
<slangasek> tedg: that would be an argument for not putting your non-static initializers in global scope? :-)
<slangasek> tedg: sorry, "and that's why C doesn't allow this" is perhaps not the kind of help you're looking for :-)
<tedg> It behaves the same with statics.
<slangasek> tedg: can't be; if your initializers are all static, then none of them are interdependent
<tedg> No one uses C anymore, that's soooo 1980's ;)
<tedg> slangasek: Oh, sorry, I thought you meant class blah { static int a; }
<cjwatson> with C, you can understand why your code is failing ;-)
<cr3> is there a name to describe the top-level directory under ubuntu archives, such as "ubuntu" under archive.ubuntu.com and "ubuntu-ports" under ports.ubuntu.com?
<cjwatson> not AFAIK
<kees> tedg: that code is hurting my head!
 * slangasek grins
<kees> tedg: why the "extern"s ?
<tedg> kees, It doesn't compile otherwise ;)
<tedg> I was trying to simulate the situation I had with multiple files -- which do need the externs in the headers.
<kees> but...
<kees> int myvar_pa = myclassp_a->get_var();
<kees> happens before
<kees> test * myclassp_a = &myclass_a;
<kees> you're just getting lucky or something.
<tedg> I know, and gcc should fix that!
<kees> "fix"?
 * slangasek cackles
<kees> it can't "fix" it -- it's the order it's written in.
<tedg> It shouldn't let you call a function on an object that hasn't yet been initialized.
<kees> hahaha.  Well, I certainly agree there.
<tedg> Okay, the linker should fix it when it's in multiple files.
<kees> it can't know
<slangasek> right, if it's in multiple files, there's no way the linker can know
<tedg> Okay, and there's no way that I can tell the linker it seems...
<tedg> It doesn't seem that link order helps.
<tedg> It just becomes fragile.
<kees> tedg: I don't understand the problem you're trying to fix yet.  :P
<slangasek> nope, the linker's job is solely to fix up the references between the objects
<kees> tedg: can you make two .cc files that demonstrates this?
<tedg> Yes, give me a sec.
<slangasek> kees: he's trying to keep using non-static initializers in global scope, while having the compiler tell him when it's not ok for him to use non-static initializers in global scope :-)
<cjwatson> presumably it doesn't give a warning because the compiler can't know whether some other bit of the link has a constructor for those objects
<kees> yeah.  madness
<cjwatson> you can't fix this without integrating the compiler and the linker
<cjwatson> AFAICS
<tedg> Oooo, the link order does fix it, but it's backwards!
<slangasek> right, that's not a very proper fix :-)
<slangasek> cjwatson: don't mention that, you'll lend credence to the KDE practice of concatenating all source files at compile time... :)
<cjwatson> it actually looks to me as if the compiler *is* reordering the constructors
<cjwatson> if I put this in get_var:
<cjwatson> fprintf(stderr, "%p %d\n", this, var);
<cjwatson> I get
<cjwatson> 0x80498d8 0
<cjwatson> 0x80498d8 0
<cjwatson> 0x80498d8 5
<cjwatson> 0x80498d8 5
<tedg> build: http://pastebin.ubuntu.com/19964/   main.cpp : http://pastebin.ubuntu.com/19965/   test.cpp : http://pastebin.ubuntu.com/19966/    test.h : http://pastebin.ubuntu.com/19967/
<cjwatson> so it's all the same object and the pointer gets validly initialised in time
<cjwatson> but goodness knows why and I never want to see code that relies on that
<slangasek> ah, so there's an implicit constructor, haha
<tedg> Hmm, so I wonder if I block the explicit constructor....
<cjwatson> for the first call, yeah, and then the second one fills the same memory slot
<cjwatson> so more complicated versions of this will likely crash
<cjwatson> or misbehave
<tedg> That could be optimization though, in other cases it may not optimize to use the same address.
 * cjwatson promotes bsd-mailx/mailx and syncs db4.6, which should fix a bit more of the world
 * cjwatson promotes ruby1.9 too, since rrdtool build-depends on it as well as ruby1.8; duplication, but I think it's OK for the time being ...
<Nafallo> who takes care of usplash those days?
<Nafallo> I just saw a screenshot of a segfault
<geser> any main sponsors around which has some time to sponsor bug #239857?
<ubottu> Launchpad bug 239857 in db "[intrepid] libdb-dev uninstallable due to a typo in Conflicts" [Undecided,New] https://launchpad.net/bugs/239857
<cjwatson> geser: yes, one moment
<brandonperry> ScottK: it isn't anything big, but the one in the repos is 0.92.1 while current is 0.93.1
<brandonperry> I like to stay current with things like that
<ScottK> brandonperry: 93.1 is already in Intrepid
<brandonperry> oh, I didn't know that
<calc> jcastro: up to 20% now for triaged :)
<ScottK> Unfortunately they changed all the libclamav interfaces with 0.93 and so backporting is non-trivial.
<cjwatson> geser: done
<brandonperry> yeah
<ScottK> brandonperry: We just finished getting 0.92.1 back into all supported releases and that's a pretty major thing.
<brandonperry> that is fine, I just thought someone would like to know how to get 0.93.1
<geser> cjwatson: thanks
<ScottK> brandonperry: What we need is help getting programs working with 0.93.1 so that we can put it in the official backports repo.
<brandonperry> ok, any specific programs? I could check into that this weekend
<ScottK> brandonperry: avscan has a new upstream version that needs packaging.
<ScottK> let me look at my list ...
<jcastro> calc: wow, you're in the green now! :)
<TheMuso> slangasek: Firstly, they were the only bugs I could reliably identify as 1.0.16 helping to fix issues users were having. The LP bug syntax was purely a misshap on my part, apologies, and I'll keep an eye on that for future reference.
<slangasek> TheMuso: ok, thanks :)
<ScottK> brandonperry: It looks like avscan, gurlchecker, and havp.  See https://wiki.ubuntu.com/MOTU/Clamav and feel free to update it if you find something out.
<brandonperry> yeah, definitely
<brandonperry> thanks
<ScottK> brandonperry: You might also want to update your blog entry to at least suggest grabbing the source package from Intrepid and building it locally for an earlier release.
<brandonperry> ok
<ScottK> brandonperry: Actually, now that I think of it, I need to stick 0.93.1 in the clamav team PPA.
<brandonperry> :-)
<calc> jcastro: i should have somewhere around 43% triaged when i get done with the pass
<calc> once i get all of my new bugs processed it will be closer to 80% :)
<jcastro> calc: rocking
<jcastro> calc: percentage of triaged bugs to me isn't as important the percentage of those bugs which have upstream links
<jcastro> wait, let me make sure I understand what I just said
<jcastro> yeah, that's what I meant. :)
<calc> yea :)
<calc> i don't have very many non-upstream bugs open that have been reviewed anyway
<ScottK> brandonperry: https://launchpad.net/~ubuntu-clamav/+archive - 0.93.1 is uploading for Hardy right now.
<calc> a few haven't been forwarded yet, but this should help me to see them easier :)
<brandonperry> thanks
<jcastro> calc: I suspect that once everyone uses triaged that the numbers will end up being way better than we expected before
<jcastro> calc: I think we should bring up this whole triaged state thing up to QA people during the sprint or something
<calc> yea
<calc> maybe a post ubuntu-devel list with the page and mentioning proper use of triaged would be helpful as well
<jcastro> makes it hard to measure things when everyone has different assumptions on what different states should be
<jcastro> yeah
<jcastro> I'll put it on my todo to ask heno about it
<calc> triaged is a relatively new status, so reminding people to use instead of confirmed when a bug has all needed data might be helpful
<jcastro> yeah
<jdstrand> kees, kirkland: fyi bug #239864
<ubottu> Launchpad bug 239864 in launchpad "request merge should send an email" [Undecided,New] https://launchpad.net/bugs/239864
<jdstrand> it'll be embarassing if the functionality exists, but I mentioned as much in the report
<kees> jdstrand: cool, I've sub'd myself
<kirkland> jdstrand: I've marked "Confirmed"
<jdstrand> that'll show 'em
<jcastro> tkamppeter: where do you usually file upstream system-config-printer bugs, in the RH bugzilla or the fedorahosted trac? I am trying to determine on which one to set as the bug tracker in lp
<slangasek> TheMuso: hum, I find 184 exported symbols dropped between 1.0.15 and 1.0.16, including a number of these with clearly public names
<TheMuso> slangasek: This is what I wasn't sure of, and why I was uneasy about doing 1.0.16.
<slangasek> TheMuso: do you have information that shows these symbols are only exposed as part of the plugin API?
<TheMuso> slangasek: Other than what I have read in changeogs, no. What you've brought up though really has me thinking we should just can the proposed updates before they cause more problems.
<slangasek> TheMuso: well, a significant number of these are not exposed in the 1.0.15 headers, and the change is explained as "make local functions really local", with a #define to rename them so that they're excluded from the symbol table; I'm auditing the list of changed symbols now to confirm that that's all they are
<TheMuso> slangasek: ok
<slangasek> TheMuso: if they are, then I'm not going to second-guess upstream any further about ABI compatibility: somebody would be screaming by now if the symbols really had been exported before
 * TheMuso nods.
 * cjwatson had forgotten how soul-destroying localechooser merges are
<cjwatson> actually, that's a slight lie, I hadn't really which is why I'd been putting it off ...
 * slangasek grins
<TheMuso> haha
<slangasek> TheMuso: ok, all the symbols with public names are accounted for under the "make local functions really local" change
<TheMuso> slangasek: Right.
<slangasek> TheMuso: do you have references describing why the plugin API is an issue between .15 and .16?
<TheMuso> slangasek: For a start, the ioplug plugin has a new symbol, whicih the pulse plugin in alsa-plugins 1.0.16 uses.
<slangasek> oh; so inter-plugin issues
<slangasek> ?
<slangasek> so alsa-plugins needs to have a versioned depends on libasound2, I guess
<slangasek> but upgrading libasound2 doesn't break the existing alsa-plugins, right?
<TheMuso> slangasek: Plugins do break if you update libasound2 as libasoudn2 seems to look for specific versioned plugins.
<slangasek> hrm, ok
<slangasek> how does it test for this?
<TheMuso> Not sure, I just remember upgrading libasound2, trying to use a plugin, and getting errors.
<TheMuso> slangasek: I can dig deeper on Monday.
<slangasek> ok
<slangasek> I'm trying to figure out how we'll know if we got it right for the bluez plugins :)
 * TheMuso nods.
<TheMuso> Pitty I don't have a bluetooth audio device handy.
<hunger> How is the debian merge into intrepid progressing?
<cjwatson> it takes in excess of a month at the beginning of each release cycle to get it done, so please don't ask daily
<cjwatson> you can monitor progress using merges.ubuntu.com and the intrepid-changes mailing list
<slangasek> TheMuso: I do, but app integration with alsa bluetooth is awful :)
<TheMuso> slangasek: heh.
<bryce> hunger: if you're interested in lending a hand, we'd be happy to give some pointers
<hunger> bryce: Nope, I am too busy backporting stuff from debian to my hardy setup;-)
<pwnguin> hunger: there's backports team you might be interested in
 * bryce nods with pwnguin
<sistpoty> bryce: anything in particular you'd like to get merged?
<hunger> pwnguin: Grabbing stuff from debian unstable and running debuild on it is not really backporting:-)
<hunger> sistpoty: I'd like cmake, git-core and subversion. That is what keeps me from upgrading to intrepid at this time.
<bryce> sistpoty: I'm working my way through the X stuff on MoM and of course would appreciate any help there; at this point everything listed on MoM is fair game
<bryce> X merge status is here - http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<sistpoty> bryce: ok, I guess I'll try to look at some X stuff tomorrow
<pwnguin> hunger: good point
<hunger> pwnguin: The good news is: git-core and cmake are very easy to get running in hardy. debuild is enough;-)
#ubuntu-devel 2008-06-14
<lamont> audit(1213394267.034:32): type=1503 operation="inode_permission" requested_mask="::w" denied_mask="::w" name="/var/cache/bind/" pid=15541 profile="/usr/sbin/named" namespace="default"
 * lamont wonders what insanity apparmor wants before it approves that
<crimsun> TheMuso: you probably will want to patch alsa-lib to lower the spam for people using dmix/dsnoop on HDA.  I'll generate a quilt one this weekend.
<crimsun> TheMuso: (referring to hardy-proposed's alsa-lib)
<crimsun> TheMuso: (affects debian 469641)
<ubottu> crimsun: Error: Could not parse data returned by Debian bugtracker: global name 'ls' is not defined (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469641;mbox=yes)
<\sh> moins
 * cjwatson fixes hppa builds a bit, hopefully
<cjwatson> (libxml-parser-perl rebuild => intltool will be installable => cups will be buildable => libgtk2.0-0 will be installable)
<ranxerox> yo
<cjwatson> garrr, if only libxml-parser-perl were actually *buildable* on hppa ...
 * cjwatson dives further down the stack
 * cjwatson retries the build and hopes
<cjwatson> (libhtml-parser-perl)
<ranxerox> yo
<Hobbsee> cjwatson: who gets poked to make debian's rmadison work again?  it apperas to be just hanging
<cjwatson> Hobbsee: the network hosting it is down, AFAICT
<Hobbsee> cjwatson: :( darn
 * cjwatson suspects DSA are aware
<cjwatson> (though I haven't had time to check myself yet)
<qense> ping persia
 * Darklock pings persia
<cjwatson> qense: note that many IRC clients only highlight messages specially if you write them in the form "persia: ping"
<cjwatson> i.e. nick at start of line
<qense> ok :) I'll try again, thx for the tip
<qense> persia: ping!
<cjwatson> also, you should say what you want, rather than just something that amounts to "hi, are you there? not going to say what it's about or how long it'll take though ..."
<cjwatson> otherwise conversations end up with more round trips than they need, which in an asynchronous environment like IRC can add days to the time
<qense> OK, you're probably right
<qense> persia: j castro told me that dholbach said that you might be interested in this idea: http://www.qense.nl/posts/114/ What do you think?
<rdz> hi all. the package description page on http://packages.ubuntu.com/de/hardy/libasound2-plugins mentions the jack plugin and it contains also an example how to set it up. however, the actual plugin-file is not part of the package. is that a bug?
<leleobhz> rdz: i think it is
<rdz> example=README-jack
<rdz> leleobhz, where to post bugs?
<rdz> (i am wuite new to ubuntu and i haven't reported bugs yet)
<leleobhz> refer to a library which dont exist
<leleobhz> rdz: http://bugs.launchpad.net/ubuntu
<rdz> leleobhz, thanks
<leleobhz> :]
<leleobhz> youre wellcome
<dbmoodb> hi ah there is a bug -- in totem player it will not suggest you install the program to be able to read css encrypted dvds
<dbmoodb> but it suggests other software, seeing i'm outside australia perhaps.... if i a user selects a country were you can legal do this the package / script should be shown along side the gstream ones -- or a suggestion to use vlc player is given
<jpds> dbmoodb: libdvdcss was fuond to be illegal in the US (or something like that)
<dbmoodb> jpds: it is illegal in the us for use yes
<dbmoodb> but in australia i am allowed to
<dbmoodb> and i see no reason for restricting or no providing a reason why it can't read a disk
<dbmoodb> that is just being stubborn
<dbmoodb> jpds: i don't see how ubuntu would be in trouble for providing info on to enable it or why it didn't work
<dbmoodb>  / doesn't work
<dbmoodb> that is not very use friendly
<cody-somerville> I'd really appreciate it if someone familiar with dbus could help me with bug #232364
 * cody-somerville just had dejavu.
<ubottu> Launchpad bug 232364 in dbus "dbus-launch freezes for unknown reason at session start" [High,Confirmed] https://launchpad.net/bugs/232364
 * cody-somerville pokes james_w 
<james_w> hi cody-somerville
<cody-somerville> james_w, I made some more progress on bug #232364
<ubottu> Launchpad bug 232364 in dbus "dbus-launch freezes for unknown reason at session start" [High,Confirmed] https://launchpad.net/bugs/232364
<cody-somerville> You might have some more insight now :)
<zorglu_>  http://xmlsoft.org/examples/tree2.c compiled with "gcc -static -Wl,--start-group `xml2-config --cflags --libs --static` tree2.c -Wl,--end-group -o tree" aka compiling in static with libxml2 the example of their own website, and then running "./tree2" produces a coredump here... can somebody else try to ? just to ensure this is not an issue of my local installation
<james_w> cody-somerville: 'fraid not
<james_w> cody-somerville: I'd want to know what the X server is doing during the hang, but I don't know how to find that out.
<cody-somerville> james_w, well, dbus-launch is hanging on fd 13 which is a socket
<cody-somerville> Is there anyway to confirm that is the bilateral socket to X?
<james_w> does looking at /var/log/Xorg.0.log while it is hanging show anything helpful?
<cody-somerville> james_w, I'll check the next time it freezes.
<james_w> cody-somerville: I thought it was that from looking through the code related to the backtrace that you provided.
<cody-somerville> james_w, right but I'd like to be able to actually check the fd and maybe see if I can confirm that guess
<iandouglas> hey all, question about upgrading -- I upgraded successfully last night from 7.04 to 7.10, then tried the 7.10 -> 804 upgrade using the "Update Manager" but it failed just before the "clean up" stage -- how do I manually run the upgrade program again, or get a list of what needs to be cleaned up?
<cjwatson> mvo isn't around
<iandouglas> ah, darn
<cjwatson> European working hours :)
<iandouglas> i'm just curious whether I need to reinstall from scratch, or just leave it as is and hope for the best
<cjwatson> you could use answers.launchpad.net/ubuntu to ask a question on the update-manager package
<cjwatson> (which he might see asynchronously even if he's not on IRC)
<cjwatson> you ought to be able to use apt-get to finish off the upgrade, although the cleanup won't be done
<iandouglas> thanks very much!
<cjwatson> 'sudo apt-get -f install' is likely to at least have a go at improving things
<iandouglas> the -f install cmd returned a ton of "dependency problems - leaving unconfigured" and "package (whatever) is not configured yet" and returned with an error code of (1)
<iandouglas> meh, i'll take my chances, thanks again for the help cjwatson!
<qense> persia: j castro told me that dholbach said that you might be interested in this idea: http://www.qense.nl/posts/114/ What do you think?
<NewProggie> Hello together
<sistpoty> anyone who'd like to sponsor xserver-xorg-video-nv merge (bug #240034)?
<ubottu> Launchpad bug 240034 in xserver-xorg-video-nv "merge 2.1.9-1 from unstable/main" [Undecided,New] https://launchpad.net/bugs/240034
#ubuntu-devel 2008-06-15
<pwnguin> is there a reason to prefer bitmap icons over svg for icons?
 * Hobbsee wonders why she can't access samba shares in intrepid
<Zic> !deowner
<ubottu> Factoid deowner not found
<Zic> !deop
<ubottu> Factoid deop not found
<ion_> ...
<Zic> (sorry, amsg error on multiserverâ¦)
<Zic> DÃ©solÃ© erreur d'amsg multiserveur / Error of /amsg command on multiserver, sorry
<qense> persia: j castro told me that dholbach said that you might be interested in this idea: http://www.qense.nl/posts/114/ What do you think?
<Chipzz_> qense: try asking during the week
<qense> OK
<guysoft42> hi all, it seems the latest python-twisted-core package gives an error status 1 on install
<guysoft42> is there anyone that this will interest here?
<qense> I know there is a way of letting avahi 'publish' a domain name to other zeroconf enabled computers so they know that 'mywonderfulserver.local' points to you, but how do you do that?
<lukehasnoname> bug #239072
<ubottu> Launchpad bug 239072 in jockey "Driver manager doesn't detect correct drivers for 8800M" [Undecided,New] https://launchpad.net/bugs/239072
<Lutin> doko_: would the gcc hardening patches cause a FTBFS if eg NULL is used and stddef.h included indirectly ?
<GyrosGeier> hi
<GyrosGeier> I maintain asio in Debian, and just noticed that it got into intrepid/main
<cjwatson> yes, seems so
<GyrosGeier> since we're not sure whether asio will ship as a "proper" library or as a bunch of files that use "using namespace boost::asio;" to get all users of that code (that is currently duplicated by upstream and packed into two separate tarballs) towards using a single copy
<GyrosGeier> (we being upstream and the rdepends in Debian)
<GyrosGeier> it might be a good idea to sync that
<cjwatson> sync which, sorry?
<cjwatson> (bug 213688 is the context for main promotion)
<ubottu> Launchpad bug 213688 in asio "Main Inclusion Report for asio" [Undecided,Fix released] https://launchpad.net/bugs/213688
<GyrosGeier> my point is that it might get dropped from Debian pre-lenny
<GyrosGeier> in which case Ubuntu would be stuck with it
<GyrosGeier> "dropped" as in "replaced by a redirector library"
<cjwatson> well, we could just follow what Debian does, no need to be stuck with it as long as it happens reasonably before intrepid ...?
<GyrosGeier> that was my concern
<cjwatson> at the moment we're just syncing the package in the normal way, it seems
<cjwatson> in any case, the relevant rdepend seems to be abiword 2.6
<cjwatson> is there a bug on abiword we can follow?
<GyrosGeier> well, currently upstream still ships the library as two separate packages
<GyrosGeier> but is contemplating to stop that, now that asio is part of boost 1.35, although with a different namespace
<cjwatson> I guess I'm slightly confused as to what we're supposed to do for now
<cjwatson> we can't realistically throw abiword 2.6 back out, and we can't ship code that isn't written yet ;-)
<GyrosGeier> nothing, if intrepid is far enough away
<cjwatson> I'm not sure what's happening with abiword 2.6 in hardy; it was certainly on the cards at some point
<GyrosGeier> the basic questions for me would be in which timeframe such a replacement package would need to appear
<GyrosGeier> asio is in hardy/universe
<cjwatson> though, well, it would hardly be the first time we continued to support code that upstream doesn't care about any more
<cjwatson> right now, yes
<cjwatson> that may not continue to be the case if abiword 2.6 is added to 8.04.1
<GyrosGeier> ah
<cjwatson> which was at one point a possibility, though I'm not up to date
<GyrosGeier> is there an individual I should coordinate with?
<cjwatson> the timeframe for Debian uploads filtering straight through to intrepid with no fuss is 26 June; after that it requires manual action but no particular approval until 28 August
<GyrosGeier> okay, so semi-urgent
<cjwatson> after that we need to think about whether the new thing is better than just leaving the old thing where it is
<GyrosGeier> there are two main ideas
<GyrosGeier> either the library does the namespace forward, or the users are patched
<GyrosGeier> i.e. s/asio::/boost::asio::/
<cjwatson> I think Ryan Pavlik (launchpad.net/~abiryan) has been dealing with the abiword packaging
<GyrosGeier> okay
<cjwatson> and since it's an 8.04.1 proposal, various core developers have been involved in reviewing and helping out (at least doko, pitti, slangasek)
<GyrosGeier> i.e. ubuntu-devel would be the best address, Ccing Ryan?
<cjwatson> GyrosGeier: yes, I think so
<GyrosGeier> cool, thanks
<GyrosGeier> will do that then
<leandroal> is there any documentation explaining how to build my own distribution based on ubuntu?
<sladen> riddell is almost back
<Riddell> usability talk about to start for Kubuntu Tutorials Day in #kubuntu-devel
<lukehasnonam1> Where do I go to discuss putting a binary driver into Ubuntu's repos?
<pwnguin> lukehasnonam1: which driver?
<lukehasnonam1> pwnguin: Nvidia driver
<lukehasnonam1> 64 bit for my 8800M
<lukehasnonam1> The Restricted Hardware manager didn't detect my card correctly,
<lukehasnonam1> but the nvidia linux driver worked. I still have trouble because I think ubuntu rewrites my xorg.conf
<lukehasnonam1> In any case, It would seem that Ubuntu does not currently support the 8800M, so I thought I'd talk to someone about it. A bug report is filed, Bug 239072
<ubottu> Launchpad bug 239072 in jockey "Driver manager doesn't detect correct drivers for 8800M" [Undecided,New] https://launchpad.net/bugs/239072
<pwnguin> lukehasnonam1: wouldn't it be great to have good open source nvidia drivers?
<lukehasnonam1> Yes, but I can't write graphics drivers.
<pwnguin> i know some people who can..
<pwnguin> lukehasnonam1: have you heard of nouveau?
<lukehasnonam1> no
<pwnguin> nouveau.freedesktop.org/
<pwnguin> lukehasnonam1: you could contribute in numerous ways
<pwnguin> lukehasnonam1: #nouveau is a channel that can help you with the details on how
#ubuntu-devel 2009-06-08
<gbear142751> hey guys, new person to open source management and was wondering if any of you had some good information about managing opensource projects, specifically with using svn for version control and building release candidates.  Any suggested howto's or other information would be greatly appreciated
<lifeless> gbear142751: don't use svn
<lifeless> gbear142751: use bzr (or git or hg)
<gbear142751> lifeless: just found out about bzr tonight... are there significant improvements over svn, or just another flavor of version control?
<directhex> branching is more powerful in distributed systems like bzr
<robinp> is there some way of digging up an old package source. The package was rejected due to license however the license has now changed and so I believe the package(s) should now be valid.
<robinp> I'm looking at mdnsresponder.
<directhex> robinp, depends on whether the package was uploaded to the archive
<robinp> i imagined the source has changed a bit from then - maybe I am just better off doing a packagisation from scratch
<ScottK> robinp: Not that I can find.
<ScottK> robinp: #ubuntu-motu is generally a better channel to discuss making new packages for Ubuntu.
<robinp> ok thanks
<calc> directhex: can't you make the stupid boycottnovell people disappear ;-)
<calc> directhex: MONO is so evil it surely has a way to vaporize its opponents ;-)
<calc> i'm only ~ 1 week behind in bug triage now, whee
<dholbach> good morning
<pitti> Good morning
<dholbach> hiya pitti
<pitti> geser: thanks for your analysis
<pitti> geser: patch makes sense, thank you!
<siretart> pitti: I need to do another quick upload of mplayer, I've forgot to bump the epoch in debian/control as well :-/
<siretart> morning #ubuntu-devel!
<pitti> siretart: wait
<siretart> pitti: anything else I can or should change in debian/control that would help the issue?
<pitti> siretart: I'm about to upload pkg-create-dbgsym
<siretart> :-)
<pitti> siretart: if you can wait for 2 hours, the fixed p-c-d is in and you don't need to change anything
<pitti> siretart: (or upload it now, and retry the build in 2 hours)
<siretart> pitti: no, the package is really buggy and has a broken upgrade path. the replaces needs a bumped epoch as well to have any effect in ubuntu
<siretart> I'd prefer the latter, since any ubuntu dev can retry the build as soon as pkg-create-dbgsym is installed in the chroots
<pitti> sure, go ahead
<siretart> uploaded!
 * pitti too :)
<siretart> pitti: is your upload automatically active on the buildds, or do the chroots need handholding?
<gpocentek> hello!
<siretart> hi
<pitti> siretart: no, they should auto-update
<siretart> great!
<pitti> but of course it needs to build/publish first
<gpocentek> could someone get the new goffice binaries out of NEW? it's a soname bump with package name changes
<gpocentek> gnumeric is waiting for the packages to build, it'd be nice to have it ready for the next xubuntu alpha
<pitti> gpocentek: will you care about the transition until alpha-2?
<gpocentek> pitti: sure, there's only one package concerned with a patch ready (waiting for an upstream review)
<pitti> great
<pitti> gpocentek: done
<gpocentek> pitti: thanks!
<pitti> TheMuso: hi!
<pitti> TheMuso: would you mind if I backport the hal -> udev migration patches for pulseaudio?
<TheMuso> pitti: dtchen has done it in our bzr pa branch. Unless it needs to be uploaded ASAP, can it wait till our next pulse upload?
<pitti> TheMuso: hm, not in http://launchpad.net/~ubuntu-core-dev/pulseaudio/ubuntu then
<pitti> TheMuso: yes, it's not super-urgent, I'm just curious :)
<TheMuso> pitti: no because I haven't merged it. Its still in dtchen's branch.
 * pitti marks it on https://wiki.ubuntu.com/Halsectomy
<pitti> TheMuso: thanks!
<TheMuso> np
<TheMuso> 3~/c
<mneptok> pitti: every time i see you discussing disabling HAL, i hear "Daaaaaaaaisy, Daaaaaaaaaaaaaaaaaaaaaaaaaaaaaisy ...." in my head
<pitti> mneptok: heey!
 * mneptok waves :)
<pitti> mneptok: hm, I guess I would have needed to watch Odyssee 2001 to get that joke? :-)
<mneptok> naturlich
<mneptok> pitti: http://www.youtube.com/watch?v=85wCw3ArNhs
<pitti> mneptok: how are you these days?
<mneptok> pitti: very well, thanks! busy as hell, but in a good way.
<\sh> pitti: you didn't watch odyssee 2001? that's a pitty, pitti ;)
<geser> good morning
<\sh> I wonder if there is any debian policy document about packaging javascript libraries....
<siretart`> hey \sh :-)
<\sh> siretart`: moins :) did you get in touch with czessi? :)
<siretart`> \sh: whats wrong with installing them in /usr/share and be done with it?
<\sh> siretart`: oh well...I meant more for naming issues...like libzend-framework-php I'm using now something like libdojo-toolkit-core-js ;)
<siretart`> \sh: no, it seems that everyone here in nueremberg prefers to stay here, and we have a big party at the university at thursday here. now I'm really considering if I should go to LT2009 at all :-(
<pitti> cjwatson_: would you mind if we unseed apmd? nothing in main depends on it, and it just sounds horribly outdated
<siretart`> \sh: I'm sure there are already javascript libraries packaged in debian. What do the others do?
<\sh> siretart`: it looks like they do it the other way around...libjs-<name of the lib>
<\sh> so I need to change the naming...
<\sh> siretart`: btw...I wonder if you see nobse somehow...if so, I would like to know his progress on mysql-cluster...didn't find any progress on it on his blog or on his debian page
<ajmitch> \sh: I think there actually is some policy around js libraries
<\sh> ajmitch: yes...I just didn't find it yet ;) but libjs-<name> sounds sane
<ajmitch> there's a javascript-common package there as well
<ajmitch> http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2009-April/000206.html details the 'policy' so far :)
<\sh> ajmitch: you are my savior, man (sorry for quoting matrix)
<siretart`> \sh: he seems terribly busy with his work these days. several months ago he called for help to create a mysql packaging team; without much success AFAIUI
<siretart`> \sh: I have him in my jabber list though, where I often see him online
<ajmitch> siretart`: do you know what help he needs with mysql?
<\sh> siretart`: oh well...then I need to jump on the wagon
 * wgrant whispers 'removing it'
<siretart`> my ajmitch! :-)
<ajmitch> er... :)
<siretart`> ajmitch: there was a blogpost about that, but I'm not uptodate with the current state of affairs
<siretart`> s/my/hey/
<siretart`> *g*
<siretart`> bah, I should chat thta much at work...
<\sh> wgrant: "REMOVING MYSQL?"
<wgrant> \sh: Yes!
<ajmitch> siretart`: I think I saw it awhile back
<ajmitch> it's still on the front page of his blog
<\sh> wgrant: no ways...or do you mean, remove mysql and introduce mariaDB?
<ajmitch> \sh: I think he means use postgresql
<wgrant> I mean remove MySQL and all derivatives, and use PostgreSQL, yes.
<mneptok> pfffft
<mneptok> use MariaDB :P
<\sh> ajmitch: that's difficult...because postgresql and clustering is not a good partnership...third party tools are there, but mostly non or less documented...and no one has any clue about the "right way"
<\sh> the same goes for master/slave setups...slony is there, yes, but really not the right way to do it
<ajmitch> mneptok: you has no bias, right? :)
<\sh> performance, agreed, postgresql is much better...
<mneptok> ajmitch: i don;t get paid for June until July 7, so no ;)
<\sh> (and before someone comes and tell me: "you have no clue"...we have all the setups right here @office...and tested it :))
<mneptok> Postgres is a bad idea.
<mneptok> it changes the LAMP acronym to LAPP, and that means your servers eat reindeer
<soren> orly?
<mneptok> MariaDB, OTOH ...
<ajmitch> but it's popular these days to not even use apache
<wgrant> LLPP?
<mneptok> wgrant: that's LL Cool J's incontinent brother
<siretart`> unpronouncable. this is a killer criteria
 * ajmitch watches mneptok try & pronounce that one
<\sh> MariaDB is charming...my moms name is "Maria" ;)
<soren> That would be L2P2.
<\sh> oh my god...it's monday morning here...how can we be so funny ... it's to early(tm)
<\sh> s/to/too/
<ajmitch> heh
<ajmitch> only way to face up to the week ahead
<mneptok> ajmitch: he said "funny," not "liquor and a handgun"
<ajmitch> you must have one interesting workplace
<mneptok> especially on "Clothing Optional Wednesdays"
<ttx> slangasek: re: release meeting action, I sent you a mail about likewise-open status in karmic.
<pitti> lool: shall we try syncing libipc-sharelite-perl, and see if the new upstream version's test suite works on armel now?
<\sh> mneptok: this week we do need more than a handgun...pumpgun is much better...but after some guys running amok here in goodl ol' .de even this is not allowed by law nowadays ;)
 * soren is still baffled that it takes someone going on a killing spree for people to realise that guns aren't cool
<soren> ..but that's just me.
<\sh> soren: because the problem is not the gun...the problem is the man/woman behind the gun...same goes for cars...a car could be a gun when the wrong person is driving the car
<soren> Except you can use cars for sensible things as well.
<pitti> \sh: .. and the actual owner of guns, who are way too careless
<\sh> pitti: right...but as our politicians are seeing it: "There is no problem with the owner...it's all Counterstrike's fault"
 * wgrant points out that this discussion probably isn't going to go anywhere good.
<pitti> yeah, and Tetris clearly needs to be forbidden as well
<pitti> it leads to people dropping stones from Autobahn bridges
<\sh> pitti: minesweeper I say, minesweeper ;)
<ttx> and solitaire, which develops onanism.
<\sh> anyways...meeting now...where's my cluebat
<soren> Strip solitaire?
<\sh> bbl
<smb> seb128, Hi Sebastien, I just followed the last uploader trail. Would you be the right person to discuss gvfs?
<seb128> smb: hi, probably, you can use #ubuntu-desktop too if you want
<smb> seb128, Might be the better place. Let me move over there...
<cjwatson> pitti: no problem dropping apmd as far as I'm concerned. Did I add it in the first place or something?
<pitti> cjwatson: no, just collecting a second opinion
<pitti> kirkland: please drop /usr/share/hal/fdi/policy/10osvendor/10-kvm.fdi and /usr/share/PolicyKit/policy/org.freedesktop.hal.kvm.policy from  kvm, it's not used any more (hal deprecation)
<pitti> kirkland: kvm isn't maintained in bzr, is it?
<slangasek> ttx: received, thanks
<ion_> Has anyone else encountered LP #384579?
<ubottu> Launchpad bug 384579 in devicekit-disks "Blocks system startup for almost a minute" [Undecided,New] https://launchpad.net/bugs/384579
<pitti> ion_: working fine here; what is it doing during that time?
<ion_> I have no idea, except for what you can analyze from the bootchart. I havenât got around to investigating it more yet.
<pitti> ion_: could you run sudo /lib/udev/devkit-disks-part-id /dev/... on all your partitions and check if one of them reproduces the long hang?
<pitti> ion_: replied in the bug
<ion_> pitti: Ah! It hangs for /dev/fd0
<ion_> pitti: Neither of the computers in question have a floppy drive.
<pitti> ah, doesn't have anything in the drive, I suppose
<pitti> heh
<pitti> ion_: curious why you have a /dev/fd0 then; can you please also attach /var/log/udev ?
<slangasek> until I read "floppy drive", my brain thought "/dev/fd0" was an alias for "/dev/stdin"
<slangasek> how many people would notice if we made that true
<ion_> sudo /lib/udev/devkit-disks-part-id "$p"  0.02s user 0.01s system 0% cpu 52.302 total
<ion_> pitti: Will do, a moment...
<pitti> /dev/stone_tablet0
<ion_> pitti: Attached
<ion_> I should probably take a look at the BIOS settings and disable the drive from there. But one would think the kernel could realize a drive doesnât exist anyway.
<pitti> ion_: the kernel detects an fd0 indeed, according to udev log
<pitti> KERNEL[1244325984.817689] add      /devices/platform/floppy.0/block/fd0 (block)
<pitti> has media:               1 (detected at su  7. kesÃâ¬kuuta 2009 03.05.53)
<pitti> LIES!
<ion_> pitti: Also in dmesg
<ion_> lshw doesnât list a floppy drive.
<pitti> ion_: can you please run apport-collect on the bug, to collect kernel information?
<pitti> ion_: nevermind, dmesg is there already
<seb128> devicekit-disks doesn't seem floppy driver friendly, people who have a floppy drive get constant polling apparently too
<seb128> it's like people were not expect floppy drives to still be used or something ;-)
<pitti> seb128: it does that by defualt for all removable devices
<pitti> seb128: but if that's causing trouble, please have them file a bug
<pitti> we can certainly special-case floppies to not get polled
<ion_> Amiga computers poll the floppy drives periodically, causing a click. And thereâs a piece of software for AmigaOS that makes the poll clickless. :-)
<seb128> pitti: bug #384469
<ubottu> Launchpad bug 384469 in devicekit-disks "contantly polls floppy drive" [Undecided,Confirmed] https://launchpad.net/bugs/384469
<seb128> pitti: well every time you poll on a floppy drive it makes noise
<seb128> pitti: so yes, it's quickly annoy apparently ;-)
<ion_> One would think it would be possible to do a noiseless poll with PC floppy drives as well.
<pitti> ion_: well, one would think that floppies/cd-roms would generate an interrupt when a media is inserted..
<ion_> True :-)
<pitti> I'll deal with the floppy polling bug now
<seb128> pitti: thanks
<pitti> ion_: if you feel like it, can you please forward your detection bug to bugzilla.k.o.?
<ion_> pitti: Will do
<ion_> pitti: For Linux (or udev or devicekit-disks)?
<pitti> ion_: linux, IMHO
<pitti> if the kernel claims to have a floppy drive with media, then trying to open() it will hang and time out
<pitti> I don't think this should be hacked around in userspace
<ion_> Yeah
<ion_> pitti: Which bug category to pick? :-) Drivers: Bugs related to device drivers; IO/Storage: Bugs related to IO; Platform Specific/Hardware: Bugs that are platform specific?
<pitti> ion_: hm, I'd pick "storage"
<slangasek> bugs with compound wings
<ion_> pitti: Heh, thereâs no âUbuntuâ or even âOtherâ option in the tree field. Thereâs Fedora, though.
<pitti> ion_: we should be pretty close to git head, though (2.6.30rc8)
<slangasek> cjwatson: from the discussion at UDS, should I go ahead and remove the 'server' seeds from kubuntu.karmic?
<Riddell> please, I've been meaning to  do that for ages
<cjwatson> yes, I think so
<slangasek> done, ta
<slangasek> dholbach: instead of acking sync bugs that are redundant, perhaps you could mark them invalid? :)
<ion_> pitti: http://bugzilla.kernel.org/show_bug.cgi?id=13486 (now if i could just find the way to add a bug watch with Launchpad...)
<ubottu> bugzilla.kernel.org bug 13486 in Other "Linux thinks thereâs a floppy drive when thereâs not. Userland doesnât appreciate." [Normal,New]
<pitti> ion_: thank you!
<ion_> Ah, found it. âAlso affects projectâ first, then add the bugzilla URL.
<pitti> ion_: done now; I linked the Ubuntu/linux package to the upstream product series, so adding upstream tasks should be easier in the future
<ion_> pitti: The bug watch thinks the bug has been confirmed in bugzilla.k.o, even though it hasnât.
<pitti> ion_: sounds like a LP bug
 * Keybuk tries to figure out which teams he needs to apply for membership for
<Keybuk> I remembered to add myself to core-dev just in time ;)
<slangasek> Keybuk: ~real-madrid?
<asac> rfcXXXX.txt files are usually not dfsg free, right?
<pitti> cjwatson: bug 384183> hm, where can I actually find the LP translations?
<ubottu> Launchpad bug 384183 in partman-target "Translation wrong in installation-gui" [Undecided,New] https://launchpad.net/bugs/384183
<pitti> cjwatson: or doesn't that use LP at all, and we just import Debian's?
<directhex> asac, IME, spec files are usually non-free
<pitti> cjwatson: (just followed up on that)
<asac> directhex: thx. thats what i thought too.
<directhex> asac, debian bug 393373 is one example of it
<ubottu> Debian bug 393373 in gtk-gnutella "Source package contains non-free IETF RFC/I-D's" [Serious,Closed] http://bugs.debian.org/393373
<cjwatson> pitti: I'll reply on the bug
<directhex> asac, we had to hax mono 2.4 to remove a spec file (from now on, upstream will instead ship source generated from the spec file, which is Free)
<asac> directhex: right. i am sure for ietf's ... but not so much for rfc's
<slangasek> asac: EPARSE?  There's only one IETF :)
<slangasek> but yes, unfortunately IETF RFCs generally have terms preventing free modification
<Keybuk> sure
<Keybuk> because modifying a standard somewhat defeats the point
<Keybuk> you're allowed to resubmit it as a new standard with mods though
<slangasek> Keybuk: I think you want #debian-devel for debating the DFSG :)
<Keybuk> slangasek: oh, I wasn't debating the DFSG, I missed the context ;)
<Keybuk> however such things are allowed under the Ubuntu Guidelines
<dholbach> slangasek: sure, can do
<slangasek> <blink> why does libclamunrar not build a -dev package?
<ion_> Who is blink?
<slangasek> my eyeballs
<xnox> hello everyone =D
<xnox> xubuntu jaunty source cd is size 0
<xnox> http://cdimage.ubuntu.com/xubuntu/releases/jaunty/release/source/
<xnox> how would you like me to report this? I'm struggling to pick correct package in launchpad. Or shall just file a bug and subscrive archive maintainers to it?
<slangasek> xnox: please use the ubuntu-cdimage project in launchpad
<xnox> slangasek: thanks
<siretart`> pitti: mplayer built, it needs NEW love now
<siretart`> btw, do we have an ARM porting team?
<ion_> mvo: I added more rambling to <https://wiki.ubuntu.com/AptSyncInKarmicSpec> recently.
<pitti> siretart`: nice
<quadrispro> I would work on findutils merge, isn't anyone already working on it?
<slangasek> Riddell: is bug #376396 still in progress for alpha-2?
<ubottu> Launchpad bug 376396 in kdebase "pulls in phonon-backend-null" [High,In progress] https://launchpad.net/bugs/376396
<Riddell> slangasek: yes it is
<steveire> cjwatson: ping?
<\sh> pitti: you are writing emails with no content ;)
<asac> hehe
<pitti> \sh: uh, what?
<asac> saw that too
<asac> pitti: Message-ID: <20090608124849.GA7265@piware.de>
<Sikon> pitti, that's a surprisingly brief letter to ubuntu-devel :p
<pitti> ugh, no idea how that happened
<cjwatson> steveire: ok, I've reconstructed your disk layout here and reproduced the parted failure; building a debugging version to dig into it now ...
<steveire> Awesome. If there's any more I can do to help, just shout out.
<cjwatson> steveire: get me a faster disk ;-)
<steveire> I can get you a bigger hamster to spin it ... :)
<soren> Interesting. I would have expected most people in this channel to have easier access to faster disks than to bigger hamsters.
<soren> ..but that's just me. :)
<slangasek> cjwatson, ArneGoetje: Debian has dropped ttf-bitstream-vera, which is seeded citing dejavu as a replacement; do you know if it's reasonable for us to follow suit?
 * slangasek grumbles about glibc continuing to show up in process-removals :)
<siretart`> is ubuntu going to stick with glibc or do we follow debian with eglibc?
<slangasek> calc: ping, re: OOo-l10n :)
<pitti> slangasek: is it broken again?
<slangasek> pitti: OOo-l10n-en-za is 8MB oversized
<slangasek> calc said to nag him if he hadn't uploaded by Monday
<pitti> slangasek: ah, so that will give us back some 6 MB of CD space? nice
<slangasek> in theory it'll give us back a full 8MB on the alternate
<pitti> -en-gb is 1.9 MB, I figure -en-za will have a similar size?
<slangasek> on desktop I don't know, I guess if dupe file detection is good then there's no savings
<pitti> ah, ok :/]
<slangasek> I'm expecting -en-za to shrink back down to its jaunty size
 * pitti repairs the smiley's chin
<cody-somerville> pitti, Who approved LP #353080 ?
<ubottu> Launchpad bug 353080 in netbeans "Netbeans IDE 6.5 don't autocomplete import statement" [Medium,Fix committed] https://launchpad.net/bugs/353080
<pitti> cody-somerville: it was a crash, and apparently a regression, so I accepted it into -proposed
<pitti> unfortunately, motu-sru@ isn't responsive any more, so I guess ubuntu-sru has to do the decisions now?
<cody-somerville> If there is a problem with the responsiveness of motu-sru then we should try and fix that issue, not totally disregard the currently accepted policies.
<cjwatson> steveire: does your 8th partition (looks like a 2.5GB FAT32 partition) actually work?
<cjwatson> steveire: it looks as if the problem is that its size in the partition table overflows the end of the disk
<steveire> cjwatson: Well I've just mounted it without issue. I think it's some kind of Dell recovery partition.
<cjwatson> steveire: hmm, the end of a FAT filesystem is a secondary copy of the filesystem headers IIRC
<cjwatson> so maybe it just copes with those being missing or something
<cjwatson> I'll carry on investigating
<pitti> cody-somerville: oh, I thought that ubuntu-sru was a member of motu-sru; apparently I mixed that up with {motu,ubuntu}-release, sorry
 * pitti uploads an apport package with interactive hook support to his PPA, go wild!
<steveire> cjwatson: I have had issues with this disk before: http://ubuntuforums.org/showthread.php?t=904702. There's a Dell quick media thing or something which apparently messes them up.
<cjwatson> steveire: can you confirm what 'parted -s /dev/sda print' in a terminal window in the installer says? For me, it says "Can't have a partition outside the disk!"
<cjwatson> or a terminal window in an ordinary system I guess
<steveire> Yes, I can confirm that.
<steveire> It says the same
<cjwatson> ok, so it's not just me getting the disk size wrong
<cjwatson> I'll compare with the kernel source to see whether it does something different with respect to partitions that overflow the disk
<calc> slangasek: will be getting it done today
<slangasek> calc: ok
<kirkland> pitti: no, kvm isn't
<kirkland> pitti: i'm trying to get it syncing from git
<kirkland> pitti: but it's run into a few issues
<pitti> kirkland: well, that piece should bring you a step closer then :)
<pitti> kirkland: if that is upstream, nevermind; it doesn't hurt, it's just not used any more
<kirkland> pitti: hmm, dropping hal, is it back to kvm group for /dev/kvm permissions?
<pitti> kirkland: no, automatic ACLs are done by udev-extras now
<pitti> /lib/udev/rules.d/70-acl.rules
<kirkland> pitti: so do i need to add something there?
<pitti> kirkland: no, I already committed it upstream
<kirkland> pitti: neat, thanks :-)
<directhex> pitti, http://www2.apebox.org/wordpress/linux/113/
<cjwatson> steveire: http://lkml.org/lkml/2008/10/9/219 looks sort of related; the kernel limits broken partitions like this to the disk size
<cjwatson> steveire: if you're in a hurry, my advice would be to back up the contents of partition number 8 and then delete it
<cjwatson> steveire: and probably also complain to your manufacturer
<steveire> Just reading the link. I'll probably do that.
<steveire> But should I be able to see kernel warning messages somewhere
<steveire> ?
<cjwatson> steveire: that's what I'm currently mystified about
<cjwatson> steveire: can you look at dmesg after mounting /dev/sda8? AFAICS, you should get something
<cjwatson> "sda: p8 size <blah> limited to size of disk" or some such
<cjwatson> actually I think you should get it well before trying to mount it, but you don't seem to ...
<steveire> Nothing: http://dpaste.com/52822/
<cjwatson> steveire: could you put updated 'fdisk -l /dev/sda' output on the bug?
<cjwatson> steveire: I know you posted it in the forums thread but the disk layout seems to have changed a bit since then
<cjwatson> I'm just trying to double-check everything before I spam parted-devel upstream ...
<steveire> Done
<cjwatson> thanks
<geser> pitti: as you merged pbuilder, could you sponsor bug 384284? or should I wait till after alpha-2?
<ubottu> Launchpad bug 384284 in pbuilder "CHROOT variable got lost during the last merge breaking pbuilder-satisfydepends-gdebi" [Undecided,New] https://launchpad.net/bugs/384284
<nixternal> pitti: I am going to take a look at the apport-qt stuff unless someone has already gotten in touch with you about it
<pitti> geser: sure, will do
<pitti> geser: no, that shouldn't be blocked by alpha-2 at all, it's a dev tool
<pitti> nixternal: oh, great! no, didn't get a response so far
<pitti> nixternal: please let me know if you start working on it and have questions about how it should behave, etc.
<pitti> geser: sorry for breaking it, and thanks for cleaning up after me
<nixternal> pitti: ya, looking through it now...the code is pretty much self explainable thus far...I branched your interactive-hooks repo
<pitti> nixternal: test with PYTHONPATH=. qt4/apport-qt -f -p pmount
<pitti> nixternal: (assuming that you install pmount.py package hook)
 * nixternal notes that down
<pitti> you can pick any package name, of course
<pitti> nixternal: I use this for testing: http://people.ubuntu.com/~pitti/tmp/pmount.py
<pitti> it uses all of the interactive functions
<pitti> -> /usr/share/apport/package-hooks/pmount.py
<nixternal> got it
<nixternal> No module named packaging_impl - yay :(
<pitti> re
<pitti> nixternal: cp backends/packaging-apt-dpkg.py apport/packaging_impl.py
<lajjr> hello pitti.
<pitti> hey lajjr
<lajjr> I was looking at the new bugs for apport
<lajjr> I see there is some request for version (eg: apport-gtk -v apport-qt -v) and others.
<lajjr> is there a reason I was going to use opt parse in python do you want me to use it or a different method.??
<pitti> lajjr: apport/ui.py already uses optparse
<pitti> lajjr: see parse_argv()
<nixternal> pitti: beat you to it, thanks to bug reports :)
<pitti> lajjr: so go ahead and add it
<pitti> nixternal: great!
<pitti> lajjr: so there needs to be some clever build-time hack to expose the version number from setup.py to apport/ui.py
<lajjr> yea what I mean do you want me to add -version for apport-gtk apport-qt?
<pitti> lajjr: or we could move the version number to ui.py and setup.py imports that and grabs it from there (probably much cleaner)
<lajjr> well you don't want hard code do you?
<nixternal> pitti: on the "Pick File" window, any specific file to pick?
<pitti> lajjr: no need to add it to individual frontends; they all use apport/ui.py
<pitti> nixternal: in the example? no
<nixternal> roger that
<pitti> nixternal: I just pick the first I come across
<nixternal> ROFL!!!!
<pitti> nixternal: look at the test hook, it just attaches it to the bug
<nixternal> "I can has a bug report?"
<nixternal> gahahahahahaha
<nixternal> I didn't catch that in the code :)
<pitti> nixternal: that's just from pmount.py, not from actual apport code :)
<nixternal> I just had pmount.py open too and looked at it :)
<pitti> lajjr: well, it needs to be hardcoded in exactly one place
<lajjr> do you want it to pop up like gdb etc.
<pitti> lajjr: right now that's setup.py, but there's no reason why we can't move it to ui.py and define __version__ there, for example
<lajjr> ok define it no prob do you want me to add it to the list. For me?
<pitti> lajjr: http://www.python.org/dev/peps/pep-3001/ says to use __version__, so let's do that
<pitti> lajjr: if you want, sure
<pitti> lajjr: thank youo
<lajjr> no prob I will.
<pitti> lajjr: I'll review your bug followups; are you subscribed to the bugs you commented on? or to apport bugs in general? (so that you'll see my replies)
<lajjr> would you rather me make a branch so if it is approaved you can merge?
<lajjr> yes I subscribed to some I better add the rest.
<lajjr> I was going to send a quick mail with a list and what I proposed.
<pitti> lajjr: sure, that should be convenient for both of us
<lajjr> great.
<pitti> lajjr: e. g. I just followed up on bug 372893
<ubottu> Launchpad bug 372893 in sun-java5 "don't report package install failures for declined license" [Undecided,Triaged] https://launchpad.net/bugs/372893
<pitti> lajjr: (which is admittedly quite complex, and I reassigned it)
<lajjr> So would like me to add some of the ones that will call optparse. Them to tasks I will do I see about 3 or so.
<lajjr> oh sorry..
<pitti> lajjr: as I said, apport/ui.py already uses optparse, just add it there
<pitti> lajjr: no need to be sorry, just pointing out some bugs, so that you can get a better feeling about what goes where in apport :)
<lajjr> yep that is what I mean.
<lajjr> great..
<lajjr> I will send an email with a few items I would like to take and do since it will be in same areas if ok.
<lajjr> I will try to contact you later I have to get one of my children from school sick :(..
<qaws> hello, I get an error "end_request: I/O error, dev fd0, sector 0" every 2 seconds, floppy drive is still rotating (no floppy inside) - it is caused by devkit-disks-da. Should I report it as a bug?
<ion_> It has already been reported and is being fixed.
<qaws> ion_, thx, what is the bug name pls?
<ion_> Iâll look it up in a moment. If you want it sooner, check the bug list for devicekit-disks at launchpad.
<qaws> ion_, thx, I have it, it is #384469
<Keybuk> pitti: random Q about devkit-disks
<Keybuk> the rules seem to duplicate a *lot* of what udev has already done
<Keybuk> and worse, call vol_id - which, err, doesn't exist
<geser> anyone got an idea how to debug why I don't have any acls (e.g. to access audio device files) set? (I'm on karmic)
<nixternal> hrmm, to create a new ui or to utilize one that is close, but not that close... pitti any opinions there? does it matter if I create a question/choices ui instead of trying to utilize the QT4ReportDialog and promoting widgets
<kees> can an archive admin check on linux 2.6.27-14.34 in intrepid NEW for -proposed ?
<Kano> hi cjwatson , did you test unionfs-fuse against aufs2 yet?
<Kano> cjwatson: tested with kvm, karmic iso default about 45s, aufs2 mod about 30s
<Kano> i thought the target for next release was speed increase not slowdown ;)
<mweichert> what version of Debian is Jaunty based on?
<ion_> sid and experimental of the time
<BUGabundo> pitti: are you around?
<BUGabundo> wanna ask if Power Button breakage on Karmic is a known bug, and if it is related to FUSA or ACPI
<BUGabundo> humm now that I think about it, it could be related to device kit, right?
<tedg> BUGabundo: Which power button breakage?  What doesn't work?
<BUGabundo> hi tedg
<BUGabundo> tedg: pressing my laptop powerbutton on karmic, does nothing
<BUGabundo> it used to popup the shutdown/reboot/hibernate window
<BUGabundo> another user on +1 confirmed it too
<tedg> BUGabundo: So if you turn on debugging in GNOME Power Manager you can see whether it's getting the keypress or not.
<BUGabundo> ok
<BUGabundo> please tell me how to do that tedg
<tedg> BUGabundo: That'd be the first thing to check, if it's not getting the keypress that is likely due to the hotkeys fixes for karmic.
<tedg> BUGabundo: https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#Getting%20info%20from%20GPM
<BUGabundo> thanks
<BUGabundo> tedg: running with nodaemon and pressing PowerButtons prints nothing
<BUGabundo> is there anything I can run to make sure its running properly?
<tedg> BUGabundo: You're running with verbose as well, right?
<BUGabundo> tedg: $ gnome-power-manager --verbose --no-daemon
<BUGabundo> as mentioned on the wiki
<tedg> BUGabundo: Hmm, it should be printing all kinds of stuff... it generally is doing something.  Is this on a laptop?  Usually there are battery events.
<BUGabundo> laptop with battery and AC
<yoasif> BUGabundo: is this the bug? https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/384890
<ubottu> Launchpad bug 384890 in gnome-power-manager "power button not bringing up shutdown dialog [karmic]" [Undecided,New]
<BUGabundo> let me see
<BUGabundo> yoasif: description fits
<BUGabundo> tedg: can you take a look?
<BUGabundo> I'll add my apport-colect too
<tedg> BUGabundo: I think the next step is to see what HAL is sending.  I think that should be achievable using dbus-monitor, but I've not done it.
<chrisccoulson> tedg / BUGabundo - gnome-power-manager is not responding to power button events from HAL because it was built without --enable-legacy-buttons at the last upload
<chrisccoulson> gnome-power-manager doesn't listen to HAL events any more by default
<BUGabundo> chrisccoulson: ok
<chrisccoulson> it should probably be built with --enable-legacy-buttons still for now
<BUGabundo> so is there a known bug open ?
<chrisccoulson> i don't think so
<BUGabundo> we can use the one from yoasif
<BUGabundo> can you comment that there?
<kees> hah, that's nice.  grub2 finds _all my chroots_.  :P
<BUGabundo> lol kees
<chrisccoulson> BUGabundo - yeah. but the correct fix is for your buttons to not produce HAL events
<BUGabundo> chrisccoulson: humm didn't get that
<chrisccoulson> i think that your power button should behave like a keyboard button and go through X instead
<BUGabundo> ok
<chrisccoulson> gnome-power-manager is only looking at keypresses by default now, unless built with hal support
<BUGabundo> yoasif: seems that gsynaptics fixes the tap to click bug
<yoasif> BUGabundo: does it persist after reboot? what does it do that the packagers aren't doing?
<BUGabundo> yoasif: and old bug about this https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/133060
<ubottu> Launchpad bug 133060 in xserver-xorg-input-synaptics "Synaptic touchpad fails to register some of the taps for tap-to-click" [Undecided,Confirmed]
<yoasif> BUGabundo: ah nice
<BUGabundo> yoasif: no idea. another LoCo user on xubuntu karmic says it works for him
<BUGabundo> yoasif: filed as https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/384968
<ubottu> Launchpad bug 384968 in xserver-xorg-input-synaptics "no tap to click" [Undecided,New]
<yoasif> BUGabundo: very cool
<BUGabundo> and just commented on the other 2 bugs
<BUGabundo> to check for dupes or regression
<yoasif> that reminds me, there was a major regression in jaunty in one of my other machines that i never filed :/
<BUGabundo> thanks for the comment chrisccoulson
<chrisccoulson> no problem
<Sarvatt> BUGabundo, use gpointing-device-settings, gsynaptics is abandoned :D
<BUGabundo> Sarvatt: thanks. will let the user know
<BUGabundo> Sarvatt: humm can't see anythin new on the menu or Mouse tabs :(
<Sarvatt> ahh sorry, theres no shortcut in the packaged one? can make one pointing to /usr/bin/gpointing-device-settings or just run gpointing-device-settings from terminal till thats fixed
<BUGabundo> let me try that Sarvatt
<BUGabundo> humm does nothing to me
<BUGabundo> and tapping is activated
<BUGabundo> but I still can tab or double tab
<cjwatson> kees: linux/intrepid-proposed> accepted now
<kees> cjwatson: great, thanks
#ubuntu-devel 2009-06-09
<virtuald> why does karmics vsftpd enable anonymous access by default?
<lool> pitti: syncing > libipc-sharelite-perl -- no objection from me; NCommander, ogra: if you are tempted to check first whether the new upstream versions passes on armel...
<NCommander> lool, it should have gotten synced automagicially
<NCommander> lool, we were using build vs. ubuntu in the version string
<lool> NCommander: libipc-sharelite-perl | 0.13-1ubuntu1 |        jaunty | source, amd64, i386
<lool> NCommander: I don't think so
<lool> NCommander: there was a sourceful change to disable the testsuite on armel
<lool> or ignore it
<NCommander> lool, I thought we did a buildX for that, or at least that was how we originally disabled it
<lool> NCommander: So feel free to check the testsuite of the new version for Martin
<NCommander> lool, still fails on rimu
<dtchen> virtuald: i'm pretty sure that's not an ubuntu delta
<cody-somerville> I'm experiencing a very very weird bug.
<cody-somerville> Like, my xchat window is showing showing up as pidgin in my windows list
<cody-somerville> and certain widgets (ie. applications menu and my system tray) don't seem to be getting drawn but work as expected if you click where you think they are
<cody-somerville> damn compiz
<TheMuso> pitti: sorry I thought dtchen had backported the hal/udev migration stuff for pulse, but he hasn't. As it is, its still somewhat broken regarding ACLs, so I think we wait till its totally fixed upstream before backporting.
<dtchen> right, i haven't pushed that yet; i'm giving it a spin on a spare machine
<dtchen> don't think it's quite ready for alpha 2 :-)
<Hobbsee> Oh dear.  Whatever climbed out of the rubbish bin and the sewer pipes, and is now on u-d-d?
<TheMuso> Hobbsee: heh
<ajmitch> last week's leftovers
<ajmitch> Hobbsee: tag thread, delete all tagged
<ajmitch> you'll be grateful
<Hobbsee> yeah, exactly
<directhex> Hobbsee, looks like a perfectly normal, daily occurrence to me
<TheMuso> Its at times like that I wish I used mutt's threading function, so I could just delete the thread.
<ajmitch> directhex: because your life is perfectly normal & sane
<Hobbsee> directhex: yeah, well
 * Hobbsee applauds thunderbird's threading
<directhex> ajmitch, gotta /earn/ my astroturfing fee!
<directhex> in this economy, it's not just a given anymore
<h6w> Where do I go for discussion of app development on ubuntu?
<h6w> I'm specifically looking for people who do regular package management.
<TheMuso> h6w: probably #ubuntu-motu is where you want to go.
<h6w> ok, cool.  Cheers. :-)
<Hobbsee> ajmitch: actually, i can do one step better than that.  server side sieve script added to.
<ajmitch> now that's getting fancy
<Hobbsee> if subject contains blah, drop
<directhex> bedtime!
<directhex> i wonder what flames tomorrow holds
<ajmitch> warm, crispy ones
<dtchen> slangasek: / bryce: your sound being muted on login is now fixed in karmic's pa
<slangasek> dtchen: oh? pa was muting the mixer?
<calc> ugh the OOo build is taking a lot longer than i expected, must have been too much churn to cache anything :\
<nixternal> pitti: hey, I just spent the past hour looking over the apport interactive-hooks and I have gone ahead and added the Qt4 support for it. I pushed it to ~nixternal/apport/interactive-hooks - tested it with pmount successfully
 * calc will look at it in the morning and see if it worked out
 * calc heads off to bed :-\
<nixternal> g'nite calc
<ajmitch> nixternal: that was quick work
<nixternal> ajmitch: the only way to work :)
<ajmitch> what, with copious amounts of alcohol? yeah, I can believe that :)
<nixternal> no alcohol, just Dr. Pepper :)
<StevenK> Ewww
<nixternal> no eww
<StevenK> Yes ewww, Dr. Pepper is horrid
<nixternal> no way, gotta love the plum flavor :)
 * ajmitch needs more V
<nixternal> heh, texlive update in karmic, version 2007 :p
<nixternal> gotta love that tex
<ajmitch> at least it's sometime this decade
<StevenK> Unlike TeTeX
<slangasek> calc: ummm, if there's that much churn, then is the OOo-l10n you're planning to upload appropriate for upload the Tuesday of a milestone?
<calc> slangasek: churn in the libraries OOo uses that caused my build not to be sufficiently cached to build in the time i expected it to
<calc> slangasek: wrt ccache
<slangasek> calc: ok, but not extensive source changes :)
<calc> slangasek: not much no
<calc> gar still building even now :-\
 * calc really goes to bed now
<calc> looks like for whatever reason its going to take probably 5hr+ to do the test build
<calc> normally a cached build takes < 2 hr
<pitti> Good morning
<StevenK> Morning pitti
<Hobbsee> heya pitti!
<al-maisan> moin pitti
<pitti> Keybuk: dk-disks> indeed, I guess that's still a lot of "example" code there as well
<pitti> nixternal: I guess you'd write a new .ui file for that? for the GTK choices dialog I added a new one to the glade as well, easier than to write it in Python
<pitti> TheMuso: okay, thanks
<pitti> lool: ok, so I don't sync it then; thanks for testing
<pitti> nixternal: rock, thanks!
<dholbach> good morning
<al-maisan> moin dholbach
<dholbach> hiya al-maisan!
<dholbach> pitti: what do you think about bug 300895 and bug 300896?
<ubottu> Launchpad bug 300895 in d-shlibs "Override of libgio missing" [Undecided,New] https://launchpad.net/bugs/300895
<ubottu> Launchpad bug 300896 in d-shlibs "Override of libpangoft missing" [Undecided,New] https://launchpad.net/bugs/300896
<dholbach> I stumbled over it when I had a look at bug 383570
<ubottu> Launchpad bug 383570 in libgtkdatabox "Please merge libgtkdatabox 0.9.0.1-2 (universe) from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/383570
<dholbach> hola dmb!
<dmb> hey
<pitti> dholbach: no opinion; I don't know d-shlibs at all
<dholbach> pitti: me neither
<dholbach> james_w: ^ do you know what needs to be done there?
<nixternal> pitti: no problem...I can do the qt stuff from now on if you would like, so just throw stuff my way if you want
 * dholbach hugs nixternal
 * nixternal hugs dholbach 
<nixternal> good morning sir
<pitti> hey nixternal
<nixternal> pitti: I would have been done sooner, but I went storm chasing today in hopes of coming across a tornado :)
<pitti> ugh
<nixternal> hehe
 * pitti gazes at the bright blue sky and nice sun outside
<nixternal> I am fascinated by weather, yet so afraid of it at the same time :)
<dholbach> sponsoring! sponsoring! sponsoring!
<nixternal> I will probably do some of that today :)
<dholbach> woohoo!
<nixternal> dholbach: you might appreciate this...my buddy RJ, Ubuntu Chicago representing, made this music thing...here are some links
<nixternal> http://static.ak.fbcdn.net/swf/mvp.swf?8%3A152716%3A1&v=223015705720&ev=0   <- demo
<nixternal> http://www.facebook.com/v/223020915720  <- explanation
 * dholbach not on facebook
<nixternal> it is public
<nixternal> I am not either, facebook is evil!
<dholbach> that looks crazy :)
<nixternal> heh, it is somewhat portable too...gonna have to bring that all Ubuntu Chicago events now
<loic-m> nixternal: I saw a video of that a few years ago
<loic-m> but it was more impressive - they had two people playing music on the table together
<loic-m> and it was electro, but the music they acheived was impressive
<nixternal> loic-m: yes, and that one, which is from the netherlands == closed source
<nixternal> rj did it all open source
<nixternal> he just started working on that thing the past couple of weeks of being home from school
<loic-m> Like 70s-early eighties experimental electronic music that became great modern music in less than a minute ;)
<loic-m> nixternal: the one i saw was open source, i checked at the time
<loic-m> it's actually the same thing AFAIK, the video you link to use the same pictograms
<loic-m> I downloaded the code, but without the table there wasn't much use fot it ;)
<loic-m> about one or two years ago
<nixternal> ya, this is designed after the reactable which isn't open source...watching videos on that now..the guy is good with the music
<wgrant> ubuntu-devel-discuss seems to be getting a bit out of hand.
<nixternal> ahh, the object recognition is open source
<loic-m> http://mtg.upf.es/reactable/?software
<loic-m> wgrant: sorry
<nixternal> right, that is just the vision framework and object recognition...this stuff is groovy...the music this one guy is doing is insane
<wgrant> loic-m: Huh?
<loic-m> nixternal: blows Surface completely
<loic-m> wgrant: for the OT
<nixternal> hell ya it does
<nixternal> heh, reminds me of old herbie hancock
<dpm> pitti: good morning. I've got a couple of questions re: https://lists.ubuntu.com/archives/ubuntu-translators/2009-June/002517.html, when you've got a minute
<dpm> * pitti: On the first issue, I think he is not describing a problem, but just noticing the difference between 'delta' and 'base' langpacks
<dpm> * pitti: On the second question, howcome there is no Jaunty -base package in the PPA archive? (https://edge.launchpad.net/~ubuntu-langpack/+archive/ppa/+index?field.name_filter=es&field.status_filter=published&field.series_filter=jaunty)
<dpm> * pitti: Finally, I can reproduce the problem with Firefox: using the latest PPA it appears untranslated. What's the best way to report this? As a bug against langpack-o-matic? Or against some other package and subscribe Language Pack Builders?
<pitti> nixternal: apport-qt works wonderfully now. thanks!
<pitti> dpm: will get back to you in a bit
<dpm> pitti: thanks
<dholbach> is anybody having trouble with sound in karmic atm? http://paste.ubuntu.com/191481 is what I get?
<nixternal> pitti: no prob. just scream at me if you have anything else to do :)
<nixternal> jeesh, u-d-a is insane..... Mark All As Read!
 * nixternal is on his way to inbox 0
<pitti> nixternal: u-d-d@, I hope?
<nixternal> interesting, I had 111 emails in there just from the past half day
<nixternal> ya
<nixternal> err, not announce :)
<pitti> *phew* :)
<Hobbsee> nixternal: just filter it.  problem solved.
<nixternal> ctrl+r in mutt calls my "read all" macro, so I am good :)
<nixternal> heh, these people screaming "MONO!" are the some of the same people who have complained on the forums, mailing lists, and bug reports about Flash not working
<nixternal> some of these*
<nixternal> would be fun to have an aprils fools release that is nothing but free software, close down multiverse and restricted and see who complains then ;p
<dholbach> nixternal: and remove all the patented code!
<nixternal> that would be fun
<nixternal> I like how I can install free software only from the disc...I tried it out and all of my machines worked like a charm...talk about luck
<dholbach> I think I only need a stupid piece of firmware for my scanner
<nixternal> I don't even need that..HP PSC 1610 all-in-one
<nixternal> works out of the box
<dholbach> but I got that from the stupid driver CD anyway
<loic-m> dholbach> nixternal: and remove all the patented code! > like the Linux kernel :D
<dholbach> nice
<nixternal> throw in hurd
<loic-m> probably half of it will be "infringing" other patents as well
<pitti> nixternal: "#FIXME: Need to finish this up" -> is that an actual issue?
<nixternal> heh, forgot to remove that
<nixternal> tis what I get for working in vim...trying to get used to it
<loic-m> The only way a piece of code isn't "infriging" on patents is if it's not successful. Let every hardware maker support ogg on their media players, and it will be facing patent threats as well
<nixternal> I have become so reliable on eclipse for everything (10+ years with it probably)
<dholbach> I'm sorry I started the patent discussion
<dholbach> let's talk about sponsoring instead!
<nixternal> lol
<nixternal> SPONSORS! SPONSORS! SPONSORS!
<nixternal> dholbach: you need to play with ajax and django! now that is fun stuff
<dholbach> nixternal: I'm a very web0.5 person
<dholbach> no idea about ajax
<nixternal> >.< this close from having build logs almost real time w/o sitting on lp hitting refresh :)
<dholbach> and just very little idea of django
<nixternal> dholbach: so was I until yesterday :)
<pitti> nixternal: ok, I delete that comment in the merge then
<lifeless> nixternal: API's count as hitting refresh
<nixternal> pitti: groovy
<nixternal> lifeless: ya, but they are doing it, not me :)
<pitti> nixternal: vim == â¥ â¥ â¥
<nixternal> heh, I was strictly emacs and eclipse
<nixternal> need an evim, then maybe I will be happy :)
 * nixternal misses org mode
<nixternal> alrighty, time for sleep, 03:12 is all I can do
<nixternal> g'nite all!
<loic-m> nite nixternal... or should it be good morning?
<pitti> nixternal: you are clearly on the wrong side of the planet :)
<dholbach> nightie nixternal
<cjwatson> jpds: you don't seem to be adding debian/changelog entries for your changes to ubuntu-dev-tools - is that deliberate?
<pitti> * NCommander is now known as ApportRetracerPortsCommander
<pitti> seb128: ^ FYI, NCommander now manages the powerpc and armel retracers
<ApportRetracerPo> Bah
<ApportRetracerPo> Freenode has a max nick limit
<seb128> pitti: good
<pitti> NCommander: so feel free to set up a sparc one if you want :)
<NCommander> pitti, when someone uses apport on SPARC, then I'll set one up
<NCommander> and as I'm the only one to use apport on ia64, it would be oddly serve serving
<pitti> NCommander: FYI, we have 3 need-sparc-retrace and 0 need-ia64-retrace
<NCommander> we do?
<pitti> one in hal, one in gnash, one in firefox
<pitti> NCommander: you can't see them, they are only visible to the apport user
<NCommander> Oh
<NCommander> I did send that firefox one
<directhex> i still need to look at apport support for mono apps
<pitti> ugh, two gutsy, one hardy alpha-something
<NCommander> I'm surprised I can't see them
<directhex> anyway, minibus time
<NCommander> pitti, the firefox one is still revelent :-/
<NCommander> I can still trip that one easily on SPARC
<NCommander> pitti, so when apport files a bug, what is it filed against so I can't see it even if I'm in bugsquad
<pitti> NCommander: it's private, and only visible to reporter and apport
<NCommander> pitti, maybe I'm loosing it, but I thought the bug supervisor could see private bugs filed against a project
<pitti> NCommander: the triaging team can see the retraced ones
<pitti> NCommander: since they usually have their coredumps deleted
<NCommander> No, that i know, I'm in that group
<NCommander> pitti, what I'm not getting is how you can have a bug against the Ubuntu distribution which isn't visible to the bug supervisor
<jpds> cjwatson: Yes, will add them later.
<jandem> hello, in a recent mailing list message the ubuntu-boot list was mentioned, but i can't find it?
<dholbach> jandem: https://launchpad.net/~ubuntu-boot
<siretart`> would it be possible to pulish the list via gmane?
<jandem> thanks dholbach, (i looked at lists.ubuntu.com)
<Hobbsee> NCommander: ubuntu-qa can see it.
<Hobbsee> (or whatever they're called)
<Hobbsee> not the one that just anyone can join
<NCommander> Hobbsee, you can see the three bugs that are needs-space-retrace/
<siretart`> Hobbsee: Is there something confidential discussed/published there?
<lifeless> Hobbsee: do we have a membership-board meeting tonight?
<Hobbsee> siretart`: I thought it was just a general question, so i'm not sure.  Perhaps i've missed some context while studying.
<Hobbsee> lifeless: -ENOTELKBUNTU
<siretart`> let's ask Keybuk
<Hobbsee> NCommander: if i could find where they're listed, i'll check
<lifeless> Hobbsee: I know you're not.
<siretart`> Keybuk: could the ubuntu-boot list be published on gmane? - it seems that it is currently restricted to members of ubuntu-qa...
<NCommander> Hobbsee, https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=need-sparc-retrace
<lifeless> Hobbsee: I am <confused> apparently though.
<Hobbsee> lifeless: okay?  *is now more confused*
<Keybuk> siretart`: I don't see why not
<Hobbsee> NCommander: hm, i can't see that.
<NCommander> Hobbsee, yeah, but I can see the powerpc retracing bugs (and I saw them get processed watching apport's logs0
<Hobbsee> NCommander: very strange
<siretart`> Keybuk: since it does not look publicly subscribable (you need and lp account that is member of ubuntu-qa or some subteam), hooking up to gmane seems hard atm
<pitti> cjwatson: does http://cdimage.ubuntu.com/daily-live/20090607/karmic-desktop-i386.manifest tell us that it doesn't use grub2 yet?
<NCommander> Hobbsee, that's why I don't understand why I can't see them :-/
<\sh> hmm...when does update-grub or better ucf create an menu.lst.ucf-dist in /var/run/grub ?
<Keybuk> siretart`: you'd need to talk to an LP team guy about that
<Hobbsee> lifeless: based on fridge, apparently you do have a meeting.  But i'm still not sure why you're asking me :)
<lifeless> Hobbsee: yes, as I said I was confused :)
<siretart`> Keybuk: since I don't think I have time to become active on ubuntu-boot, I'd rather not invest time in that. I would have lurked on the list if it was on gmane, though.
<cjwatson> pitti: maybe it ought to be changed, but grub-pc is available as a .deb on the live CD as well and it will use that
<cjwatson> \sh: ages
<cjwatson> \sh: or do you not mean "since when"?
<pitti> cjwatson: ah, ok
<\sh> cjwatson: no..."when in the update-grub process does ucf creates an ucf-dist file for menu.lst"...reading update-grub it should only be named /var/run/grub/menu.lst with the kernel list fragment
<cjwatson> \sh: it's created if you (explicitly or otherwise) chose something other than "install new version of this file"; it's analogous to .dpkg-dist for conffile
<cjwatson> s
<\sh> cjwatson: hmm...I install grub and install the kernel...then running update-grub (menu.lst in /boot/grub/ is copied from somewhere to this location during automatical installation) but update-grub doesn't update the kernel list fragment...and in /var/run/grub/ there is still the menu.lst.ucf-dist
<cjwatson> \sh: why do you care? :-)
<cjwatson> you're not supposed to care about the existence of .ucf-dist, really
<\sh> cjwatson: because it's not updating the kernel list in /boot/grub/menu.lst and after my installation is finished I have a grub with no kernel list ;)
<cjwatson> \sh: oh, well, maybe you answered "no, keep my own version" in the past and it remembered that
<cjwatson> \sh: ask slangasek when he wakes up
<\sh> cjwatson: actually I didn't say anything..because there is no debconf questioning during unattended FAI installation ;)
 * cjwatson blames FAI
<\sh> -EBUTDEBIANWORKS ;)
<james_w> dholbach: they need to be fixed :-)
<cjwatson> \sh: FSVO "works"; ucf management of menu.lst was introduced for a reason
<dholbach> james_w: do you know how?
<james_w> it's a small patch to the package
<james_w> alternatively you can work around it in the package that uses it
<cjwatson> \sh: anyway, slangasek should be able to help you recover, I'm afraid I can never quite keep the details straight
<cjwatson> looking forward to not having to care about this stuff with grub2
<james_w> the main issue is checking whether it applies to Debian
<\sh> cjwatson: k...I'll poke slangasek thx anyways :)
<directhex> pitti, how does pkg-create-dbgsym behave if a package already has a -dbg defined in control?
<NCommander> ../linux/arm/syscallent.h:435:3: error: #error fix me - wow, that's not vague :-/
<pitti> directhex: it just grabs the debug info without stripping it, so that the following -dbg package creation won't fail
<pitti> directhex: I have about 3 test cases in pkg-create-dbgsym's test suite to make sure that this mostly works
<pitti> directhex: does it fail for one of your packages?
<hyperair> hmm ia32-libs is broken.
<hyperair> at least, the pulse bits are.
<hyperair> skype and flash no longer work with pulseaudio
<directhex> pitti, i'm trying to add support for mono apps (mdb debug symbols), but picked a package with a -dbg as my test case ;)
<directhex> oh. oops. non-arch-all is the opposite behaviour to what i want!
<pitti> slangasek: oh, wrt. our UDS discussion about hotkey-setup, I don't need this ominous sleep setting here; no visible difference with hotkey-setup and without
<jpds> cjwatson: debian/changelog entries added.
<Keybuk> pitti: devkit-disks is spoiling my bootchart <g>
<directhex> pitti, hm. can you think of a way for pkg-create-dbgsym to be callable more than once for the same package? that is, some apps (say, Banshee) contain both C libs and mono apps, so both dh_strip and dh_clistrip get called on them. how to deal with that scenario?
<pitti> Keybuk: because of the additional udev rules?
<pitti> Keybuk: perhaps we can walk through them and check which ones are redundant?
<TheMuso> asac: you wanted to talk to me about bluetooth and pulse?
<Keybuk> pitti: because of the sudden increase in calls to things like blkid
<Keybuk> I think we're calling it 2-3 times per block device all of a sudden
<pitti> directhex: I guess these two would not have much in common, since CLI debug symbols look entirely different?
<pitti> directhex: so they shouldn't get into each other's way?
<pitti> directhex: do you wan to call them -dbgsym?
<asac> TheMuso: yeah ;)
<Keybuk> pitti: I was expecting 0.3s for udev, and got 0.8
<pitti> directhex: if so, then I'd suggest to just add it to pkg_create_dbgsym itself
<directhex> pitti, well, i suppose that's a workaround isn't it - use a different package name for the mdb symbols
<TheMuso> asac: in short, I don't know where things stand. I need to grab the needed pieces, put them together, and test locally. I got myself a bluetooth headset for this purpose.
<asac> TheMuso: whats the status of the -sink/-source pieces?
<asac> ajh ok
<pitti> Keybuk: I guess dk-disks should not really need to call blkid, since udev does that by default already?
<Keybuk> pitti: exactly
<directhex> pitti, the problem is that dh_strip and dh_clistrip get called separately, so pkg_create_dbgsym gets called by both of those (or a replacement tool for the mono version gets called)
<pitti> directhex: right, we shuold just integrate it there instead of having yet another package, IMHO
<pitti> directhex: it's also much easier to write, I guess
 * pitti reboots, brb
<asac> TheMuso: do your tests with gnome-bluetooth and not bluez-gnome (which will go away)
<TheMuso> asac: give me a day at most to get things tested, and I'll get back to you.
<TheMuso> asac: I know about that.
<asac> TheMuso: great. lets talk tomorrow then.
<gpocentek> k
<gpocentek> (sorry)
<ogra> asac, help, my FF shows me cryptic fonts today
<asac> ogra: #ubuntu+1 :-P
<asac> ogra: just kidding
<asac> ogra: what changed since yesterday?
<ogra> nothing
<ogra> i didnt upgrade or anything
<Keybuk> ogra: mine's been doing that for weeks
<asac> screen please
<Keybuk> seems to do it after suspend
<Keybuk> so I figured it was some kind of pango cache corruption or something
<ogra> asac, http://people.ubuntu.com/~ogra/ff_fonts.png
<ogra> Keybuk, i didnt suspend
<Keybuk> ogra: interesting
<ogra> i did absolutely nothign
<Keybuk> ogra: your screenshot is exactly what I get too
<pitti> meh, that reboot took a while; interesting bug in g-p-m
<ogra> it just started out of the blue
<asac> wow
<ogra> i deliberately skipped updates the last two days
<asac> ogra: what graphics driver/chipset?
<ogra> intel
<ogra> using KMS
<ogra> 8086:2a02 ... GM965/GL960
<ogra> i dont see the issue in other programs
<ogra> and i noticed it gets slightly better if i switch to a windows encoding and andale mono
<ogra> but i cant make it go away completely
<asac> let me get my notebook up
<RAOF> I see that too, but only sometimes.  It seems to occur (a) after long idle periods and (b) after resume from suspend.
<asac> sounds like driver issue then
<RAOF> Also KMS, intel, GM9something.
<RAOF> I'd guess so.
<ogra> but funny that only FF exposes it
<ogra> evo, different terminals i tried, xchat etc all work fine
<directhex> pitti, i think it might be best to use a different command, and a different -suffix, for the mono debug symbols. i can't think of a sensible way to overcome the problem caused by pkg_create_dbgsym being called by dh_strip then dh_clistrip (or the other way round), without risking problems. every invocation of pkg_create_dbgsym ends with a call to "dpkg --build", so i can't see how to make sure that --build gets called once only, w
<directhex> ith both elf symbols and mdb files.
 * ogra goes to make some coffee
<asac> ogra: can you check if using firefox-3.5 makes any difference?
<RAOF> That's what I was using.
<ogra> is it in the archive already ?
<RAOF> I seem to remember it affecting other apps, but not to the same extent as firefox.
<asac> ogra: yes. since jaunty
 * ogra installs
<asac> ogra: install firefox-3.5 ... the menu entry is called "Shiretoko" and has the old blue planet thing as icon
<cjwatson> jpds: thanks!
<asac> ogra: do i need to do something to use KMS?
<cjwatson> jpds: I have a rewrite of 404main here using python-apt, but it uses some fairly bleeding-edge methods that (AFAICS) weren't in jaunty. Do you think it's fair enough for ubuntu-dev-tools to Depends: python-apt (>= 0.7.9) for this? I'm thinking most developers will either be on karmic already or moving over in the not too distant future
<ogra> asac, https://wiki.ubuntu.com/X/KernelModeSetting
<jpds> cjwatson: Yeah, I think that would be fine (I don't think anyone wants to backport u-d-t anytime soon).
<pitti> Keybuk: so dk-disks git head doesn't change any udev rules, FYI
<asac> ogra: so i need to build the kernel on my own?
<pitti> directhex: it could still be the same package (pkg-create-dbgsym)
<pitti> directhex: and you just add another wrapper for dh_clistrip
<ogra> asac, no, karmic should have all you need
<ogra> asac, samme behavior with 3.5 btw
<asac> ogra: so i get that without doing anything?
<asac> ogra: upgrading now. think last upgrade was 1 week ago or so
<ogra> asac, create /etc/modprobe.d/i915-kms.conf, add "options i915 modeset=1"
<cjwatson> jpds: ok, cool. committed
<Keybuk> pitti: I didn't quite get why it has most of the ones it has
<ogra> (and i would guess you need update-unutramfs -u thougth the wiki doesnt say that)
<Keybuk> since udev now ships upstream rules, it can rely on them being there
<Keybuk> even the mdadm/devmapper ones are in udev's tarball now
<asac> ogra: ok will check after upgrade finishes
<directhex> pitti, right. i assumed that was the best approach anyway, hence "ii  pkg-create-dbgsym                             0.26+dhx1                                     automatically build debug symbol ddeb packages"
<directhex> pitti, so... any preferences? "-mdbsym"?
<pitti> directhex: sounds fine :)
<ogra> pitti, hal-storage-mount segfaults for unpartitioned (but formatted) usb keys, known bug ?
<ogra> [344310.055062] sd 10:0:0:0: [sdb] Assuming drive cache: write through
<ogra> [344310.055070]  sdb:
<ogra> [344310.058098] sd 10:0:0:0: [sdb] Attached SCSI removable disk
<ogra> [344311.862949] hal-storage-mou[23765]: segfault at 0 ip 0804a9ea sp bf985980 error 4 in hal-storage-mount[8048000+7000]
<pitti> ogra: not known to me
<pitti> ogra: but pretty uninteresting now, that we don't use hal for mounting any more
<ogra> ogra@osiris:~$ sudo mount /dev/sdb /mnt/
<ogra> ogra@osiris:~$ mount |grep sdb
<ogra> /dev/sdb on /mnt type vfat (rw)
<ogra> ok ..
<pitti> Keybuk: eww, most of those look very familiar to what udev is doing anyway, indeed
<pitti> Keybuk: I think the only real thing it adds is devkit-disks-probe-ata-smart
<Keybuk> what does that do?
<Keybuk> the smart values?
<ogra> asac, OH ! i just notice that some tabs have proper fonts with 3.5
<ogra> well, or at least a lot less errors
<ogra> there still are some
<pitti> Keybuk: just DKD_ATA_SMART_IS_AVAILABLE=1
<pitti> Keybuk: not the actual values (they are read on demand by dk-disks daemon, when someone requests them over d-bus I guess)
<pitti> Keybuk: I'm not sure what the ID_DRIVE_FLASH_{MS,SM,SD,CF} stuff is about
 * asac reboots with kms
<asac> ogra: dont see it ... even after resume. will keep my eyes open ;)
<asac> ogra: curious: does pango-view -t "Test TEXT ... (make it longer)" --backend=cairo
<asac> show the same problem?
<ogra> i dont think its actually KMS i would expect to see it in any other apps too if it were a driver prob
<ogra> nope, looks fine
<asac> ogra: nah. ffox really uses cairo heavily ... so you will see driver issues in ffox you dont see elsewhere
<asac> not saying its not a ffox bug. but the symptoms look really driver related
<ogra> well, FF is the only thing exposing it (yet) ...
<ogra> i dont say its a FF bug but i only see it with FF :)
<asac> ogra: yeah. so can you confirm that this starts after resume? and after clean boot it works?
<asac> (like what RAOF observed)
 * ogra reboots
<pitti> asac: KMS working well for you?
<asac> pitti: not 100% if its running. i added the modprobe.d thing mentioned by ogra
<asac> so far things work more or less well
<asac> even compiz is on again ;)
<pitti> asac: that's necessary to enable it in the first place
<pitti> asac: tried suspend/resume?
<asac> pitti: how can i check that i am using KMS?
<pitti> asac: ctrl+alt+f1
<pitti> if that's blazingly fast and you get a nice big VT, it's working
<pitti> asac: and check suspend/resume, and if it comes back even faster than you can open the lid, it's working :)
<asac> pitti: yeah so i am running it
<ogra> asac, hrm, its gone after reboot
<asac> and i already have one suspend/resume done after this boot
<asac> let me do another
<asac> ogra: thats what RAOF said. now suspend/resume ... if its coming back its 99.99% drier issue
<pitti> unfortunately suspend is broken for me right now with current xorg-edgers PPA :/
<asac> ok i do a three suspend resumes now ;)
<ogra> hmm, not coming back it seems
<asac>  ;)
<mpt> Does anyone know what's happening with the video recordings from UDS?
<asac> yeah. so i suspended a few times and it still works here
<ogra> same here
<ogra> weird
<mpt> jcastro, do you know?
<soren> mpt: I imagine they'll end up on http://video.ubuntu.com/ eventually.
<cjwatson> I'm interested in the audio recordings too ...
<soren> cjwatson: There were audio recordings?
<soren> I though we only streamed the audio.
<cjwatson> soren: I don't know
<directhex> dpkg-deb: building package `libmono-microsoft-visualbasic8.0-cil-dbgsym' in `../libmono-microsoft-visualbasic8.0-cil-mdbsym_2.4-1_all.ddeb'.
<geser> directhex: your pkg_create_dbgsym script is buggy, it creates wrong filenames :)
<directhex> geser, howso?
<geser> -mdbsym != -dbgsym
<directhex> geser, indeed
<hyperair> but all the debug symbols are .mdb files anyway
<directhex> geser, it's the easiest workaround to the problem of packages containing both elf debug symbols, and mdb debug symbols, which would end up stripped twice
<pochu> why not put everything in a single package?
<directhex> pochu, i'd love to
<maxb> There appears to be something broken with the kernel in jaunty-proposed. Launchpad says linux 2.6.28-13.44 was published into jaunty-proposed 7 days ago, but the actual binaries published to the Packages file are still ABI 12.
<cjwatson> maxb: binary NEW, I started processing last night but had to fall asleep
<cjwatson> I'll sort it out now
<maxb> oh!
 * maxb was confused that linux-meta abi 13 was in
<cjwatson> it probably oughtn't to have been processed
<cjwatson> anyway
<cjwatson> mvo: I attempted to add support for update to rapt (lp:~cjwatson/rapt/update), but it's currently segfaulting and it looks like something inside apt/python-apt. Could you have a look if you get a minute?
<mvo> cjwatson: sure
<mvo> cjwatson: I merge and check
<cjwatson> mvo: http://paste.ubuntu.com/191589/ is the traceback if that's any use
<ion_> Ooo, rapt looks nice.
<cjwatson> valgrind says "Access not within mapped region at address 0xFED8E900"
<lifeless> mvo: https://edge.launchpad.net/rapt might like to turn on 'uses lp for development'
<mvo> cjwatson: its doing improper type checking for the progress object :/
<cjwatson> oh, did I give it the wrong thing?
<ion_> Oh, wait. A different rapt. I was looking at http://www.steve.org.uk/Software/rapt/
<\sh> hmm...which package adds the %admin group to /etc/sudoers?
<mvo> cjwatson: yes, a TextFetchProgress will work
<cjwatson> ah yes, just tried that :)
<mvo> cjwatson: IIRC this is partly fixed in python-apt bzr
 * cjwatson pushes a better version
<ion_> Was it today or tomorrow when liw returns from his vacation?
<mvo> lifeless: good point, added
<liw> ion_, I'm back
<ion_> liw: :-)
<ion_> liw: I added some rambling to the end of https://wiki.ubuntu.com/AptSyncInKarmicSpec
<liw> ion_, cool; I'll get to it eventually, I'm digging myself out of a ton of e-mail and stuff, but I'll get to it!
<cjwatson> mvo: seems to work nicely now
<ion_> liw: Aye
<mvo> cjwatson: excellent, I will merge (and/or I can add you to be rapt-hackers if you want)
<cjwatson> I've probably scratched my itch adequately now :-)
<mvo> :)
<cjwatson> do the DC porter boxes auto-upgrade rapt or do we need an RT ticket?
<elmo> you need an RT ticket; since rapt isn't available for all the chroots we have
<cjwatson> ok
<directhex> pitti, okay, assuming we overlook the 2-debug-packages-for-some-apps issue, i have a working implementation for packaging up mono debug symbols. there are therefore 3 issues: 1) most apps/libs will need patching to actually produce debug symbols properly (many miss the creation of, or "make install"ing of .mdb files) 2) do we care about -mdbsym versus -dbgsym? it's messy, but is it a problem? 3) it doesn't work for mono itself, as
<directhex>  mono uses a local copy of debian/dh_clistrip for some reason
<cjwatson> mvo: hmm, don't merge that yet, I broke the blacklist stuff
<cjwatson> (fixed)
<cjwatson> maxb: accepted, belatedly
<seb128> directhex: there is not so many applications using it right now, we can patch the build for the few which are shipped by default or interesting
<directhex> seb128, right. i doubt it's a priority issue until debian stops sucking & gains something like pkg-create-dbgsym. but it's certainly worth fixing ad-hoc
<directhex> seb128, and the other two points?
<Brucevdk> Hey dholbach, I saw you were listed as an author for the IndustrialTango theme. I'm having some issues with the border theme when using Compiz as the window manager instead of Metacity (the window icon doesn't work). IndustrialTango seems to be the only theme with issues. Mind if we talk about it here? Maybe there's a more relevant channel, or pm?
<seb128> 3 seems easy to patch or figure why it's using a copy
<directhex> also, seems i need to rebase against the latest version of it, since i was using jaunty's version as a base :/
<seb128> 2 doesn't seem a real issue to me
<dholbach> Brucevdk: I just packaged it
<dholbach> Brucevdk: ... ages ago
<Brucevdk> dholbach: hmm looks like I'm going to have to talk to jdub then
<dholbach> Brucevdk: is there an AUTHORS file?
<Brucevdk> dholbach: yeah I was looking at the wrong authors file, the one from the package
<directhex> seb128, the "why" appears to be "because it doesn't build-depend on cli-common-dev"
<directhex> seb128, now, that introduces a NEW question :)
<Brucevdk> dholbach: you were on IRC, hence, me showing up here ;-)
<dholbach> :)
<Brucevdk> anyho, I'll try and get in touch with jdub, meanwhile rock on ;-)
<dholbach> you too!
<pitti> directhex: well, what's your actual goal with -mdbsym?
<pitti> directhex: e. g. we don't have a sensible mono<->apport integration yet (there's a blueprint, but nothing implemented)
<directhex> pitti, 2 goals. some apps ship with he mdb files (which wastes space), or just throw away the symbols (which is a waste) or have manually written -dbg (which is a PITA to maintain). it provides a sensible way to store debug symbols for things
<directhex> pitti, longer term, i want that apport integration
<pitti> directhex: so for purely manual installation, producing -mdbsym sounds just fine
<pitti> directhex: longer-term, I think it'd make sense to integrate it into dh_strip, or at least unify pkg-create-dbgsym to hook into both and then produce -dbgsym in whichever comes first, and for both gdb and mdb
<directhex> pitti, my problem with visualising that has been how to deal with dh_strip and dh_clistrip given different parameters - you only know which parameters both have received on the SECOND call (if there is a second call), not first
<pitti> directhex: ah, true that
<directhex> pitti, at any rate, what i have so far is at http://paste.debian.net/38477/
<pitti> directhex: any chance you could add a test case?
<directhex> pitti, sure, let's take a look at this.........
<directhex> pitti, aha, test case caught a bug ;)
<jcastro> mpt: IS has them, afaik they get shipped someplace to be edited.
<mpt> thanks Jorge
<directhex> dpkg-deb: building package `dhtest2-dbgsym' in `../dhtest2-mdbsym_2.3-1_all.ddeb'.
<directhex> hm. spot the deliberate error!
<pitti> directhex: the general framework expects -dbgsym?
<directhex> pitti, i just forgot some search/replace in pkg_create_mdbsym
<pitti> directhex: test suites FTW! :-)
<directhex> okay, that's a functional pure-c# test case. now for a mixed-mode test
<Keybuk> holy crap
<Keybuk> Fedora don't even get their mirrors in sync before release
<Chipzz> oh noes!
<Chipzz> ;)
<directhex> PASS: mdbsym ddeb for dhtest1_2.3-1_all.deb exists
<directhex> PASS: unpacked/usr/lib/crash/crash.exe has .mdb file
<Keybuk> Chipzz: it's important ;) have to find out how fast F11 boots in the end
<squirrelpimp> hi, when will packages.ubuntu.com be available again?
<Ng> squirrelpimp: now :)
<squirrelpimp> k
<squirrelpimp> :)
<squirrelpimp> thanks
<lool> Could someone who uses ecryptfs somewhere tell me whether Mutt still works when emails are backed by an ecryptfs mount?  In my case the builtin pager causes the process to be killed
<stgraber> pitti: thanks for your comments, I updated the MIR accordingly
<pitti> stgraber: ah, thanks
<pitti> stgraber: can you please set the bug status back to New?
<stgraber> pitti: sure
<stgraber> pitti: hmm, it already is
<pitti> stgraber: ah, got bug mail, thnaks
<bryce> dtchen: excellent
<directhex> pitti, i'm sending a message to mono upstream to get their thoughts on how to hook apport into mono. is there anywhere I should suggest they talk to smart apport people, like an IRC channel or mailing list?
<pitti> directhex: the apport project in LP has a ML, but TBH I haven't quite figured out yet how it works
<pitti> directhex: for now, mailing me is fine
<pitti> directhex: ah, try  apport-hackers@lists.launchpad.net
<directhex> okay, mailed mono-devel. let's see how flamed i get
<LaserJock> cjwatson: regarding gcompris, don't we need the gnet dependency in order for it to actually get moved into Main?
<LaserJock> directhex: I suppose you're used to that by now ;-)
<cjwatson> LaserJock: I sent a mail to mantha@u.c about that but it bounced ...
<cjwatson> LaserJock: does that address not work any more?
<LaserJock> cjwatson: it's laserjock@
<cjwatson> LaserJock: ah, how about I bounce it to you
<cjwatson> LaserJock: (and no, we don't need it immediately, it's OK to say "gcompris will build-depend on this as soon as it's in main)
<cjwatson> +"
<directhex> LaserJock, i start to feel cold & uneasy without some nice warming flames every day
<LaserJock> directhex: heh
<LaserJock> I think directhex should get the "Flame-retardant underwear of the year" award
<directhex> LaserJock, Riddell provided a Qt t-shirt, does that count?
<LaserJock> cjwatson: the gnet MIR has already been approved
<LaserJock> directhex: perhaps, though some might consider it an accelerant
<cjwatson> LaserJock: oh, it has?
<cjwatson> LaserJock: it used to be in main but was demoted
<cjwatson> I see nothing current on gnet's bug page
<LaserJock> cjwatson: piti approved it ~ 4 days ago
<directhex> i wonder if the mono t-shirt met sabdfl's minimum softness requirements
<cjwatson> oh, meh, it looks as if it was promoted but then (auto-)re-demoted
<LaserJock> cjwatson: bug #383948
<ubottu> Launchpad bug 383948 in gnet "MIR: please (re)promote gnet to Main" [Undecided,Fix released] https://launchpad.net/bugs/383948
<cjwatson> yeah, I see it
<cjwatson> ok, I'll fix up the overrides and reupload, thanks
<LaserJock> oh, so it was auto demoted because nothing depended on it?
<cjwatson> well, "auto"
<cjwatson> as in an archive admin saw it on the "can be demoted" list and did it
<cjwatson> LaserJock: BTW you also didn't talk to the most recent uploader listed on merges.u.c/main.html when working on the merge ;-)
<cjwatson> or at least if you did I forgot ...
<cjwatson> LaserJock: actually, perhaps you could upload gcompris with the gnet build-dep put back, so that somebody more appropriate ends up marked as touched-it-last?
<cjwatson> I've promoted gnet again now
<LaserJock> cjwatson: I hadn't actually worked on the merge and I didn't think a rebuild counted as "last uploader"
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/gnet/+bug/383948 "I'm working on merging gcompris from Debian"
<ubottu> Launchpad bug 383948 in gnet "MIR: please (re)promote gnet to Main" [Undecided,Fix released]
<cjwatson> it does for the purposes of merges.u.c (unfortunately)
<LaserJock> cjwatson: well, thanks for the merge in any case
<LaserJock> cjwatson: I was just looking through the new upstream when I saw you'd uploaded it
<LaserJock> cjwatson: I'll add gnet back in and upload
<asac> TheMuso: any idea if libatk-bridge.so will move to dbus at some point (i think it uses corba atm)
<cjwatson> LaserJock: ta
<slangasek> \sh: manually tweak something in your automanaged kernel block; then adjust one of the magic variables; then run update-grub and you should get re-prompted.
<slangasek> pitti: "ominous sleep setting" == "DOS"?
<slangasek> I still need to talk to mjg59 about that, I think, to figure out why it was ever added
<pitti> slangasek: the remaining bit in hotkey-setup's init script
<slangasek> yep
<LaserJock> cjwatson: would you have any opinion on if we should add a patch system or something to gcompris?
<cjwatson> LaserJock: my opinion is that we should never add patch systems in Ubuntu when they are not present in Debian
<LaserJock> cjwatson: would maintaining it in bzr help?
<cjwatson> in the specific case of gcompris it seems too simple to be necessary; in fact it was *easier* to deal with the merge without a patch system
<cjwatson> LaserJock: we'll get an import into bzr soon enough, along with the rest of the automatic imports ...
<LaserJock> cjwatson: k
<AnAnt> Hello, a question about grub2, will gfxmode be 640x480 in Ubuntu ?
<AnAnt> let me rephrase the question please,
<AnAnt> will there be a way to determine the current gfxmode resolution ?
<cjwatson> from where?
<AnAnt> cjwatson: grub2
<ion_> /etc/grub.d/00_header:if [ "x${GRUB_GFXMODE}" = "x" ] ; then GRUB_GFXMODE=640x480 ; fi
<cjwatson> it's a variable in grub2
<cjwatson> the 'gfxmode' variable, specifically
<AnAnt> ok, there is a /etc/grub.d/05_debian_theme currently
<AnAnt> will that be replaced with a 05_ubuntu_theme ?
<cjwatson> dunno, maybe :)
<cjwatson> we've largely just dropped in the Debian package with some basic branding for the moment
<cjwatson> theming is not a high priority since for the default case we'd prefer the menu not to be displayed
<cjwatson> but we're not opposed to it
<AnAnt> ok
<AnAnt> any news about wether plymouth will replace usplash ?
<ion_> Early Xorg will basically replace usplash AFAIU. Usplash will only be shown with fsck or equivalent.
<cjwatson> plymouth isn't going to replace usplash, no
<AnAnt> ok, thanks
<AnAnt> ok, finally will the new GDM be used in Karmic ?
<AnAnt> I heard that there is a new GDM that doesn't support the old GDM themes
<sladen> I hear lots of things.  I heard a boat just go past, and birds twittering and in the distance I can hear cars too.
<AnAnt> sladen: you like birds ?
<cjwatson> AnAnt: https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus says yes
<seb128> AnAnt: the new gdm is a background and a gtk dialog
<slangasek> calc: are you going to have time to get bug #201114 fixed for hardy, or should I have a look at it myself?
<ubottu> Launchpad bug 201114 in openoffice.org-l10n "-help packages need alternate language-support- dependencies" [High,Fix released] https://launchpad.net/bugs/201114
<slangasek> calc: in time for 8.04.3, I mean (which means getting it uploaded in the next week or so)
<nixternal> pitti: heh, comments on my blog about "I can has bug report" and someone trying to fix the grammar :)
<pitti> nixternal: they didn't get the joke? :-)
<ion_> :-D
<LaserJock> is there a lolcat translation team on LP?
<LaserJock> if we've got klingon surely there should be lolcat
<nixternal> I think they would have if it was s/has/haz/ maybe
<tkamppeter> pitti, hi
<slangasek> I has canned bug reports
<pitti> hi tkamppeter
<pitti> LaserJock: nuQneH?
 * pitti remembers writing http://martin.piware.de/trek/pIqaD.txt and other stuff, from the times when I apparently had too much time
<slangasek> heh
<slangasek> does anyone have the spec for "refactor package management UI" handy?
<directhex> i missed the UDS session. did lpia get the axe?
<LaserJock> slangasek: https://wiki.ubuntu.com/AppCenter ?
<slangasek> LaserJock: ta
<tkamppeter> pitti, I will do the needed steps to get the Poppler-based pdftops filter into CUPS now. Users report in all related bug reports that their problems get solved.
<slangasek> hmm, interesting, AppCenter doesn't mention replacing software-sources-gtk
<tkamppeter> One question to master bug 382379
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released] https://launchpad.net/bugs/382379
<slangasek> er, software-properties-gtk
<slangasek> mpt: ^^ do you have any designs on AppCenter superseding software-properties-gtk, or is that expected to stay the same?
<ion_> âtlh- ke[ttle], air forced between tongue sidesâ The English education in Finnish basic schools generally sucks; incidentally they *never* even mentioned that the t kettle is pronounced any differently than the t in talk. Iâve only realized it basically by watching a lot of American TV-shows.
<tkamppeter> Should I make all cited bugs duplicate of this bug or should I put all the individual bug numbers into the debian/changelog of my next CUPS update?
<pitti> tkamppeter: great, thanks
<pitti> tkamppeter: do duplicates, that's better for getting testing feedback, I think
<slangasek> ion_: American, or British?  we don't pronounce kettle the same ;)
<ion_> American
<ion_> I think :-P
<pitti> it's the effect that you get with saying "tl" primarily
<mpt> slangasek, yes, I think it will subsume Software Sources eventually. Fixed. <https://wiki.ubuntu.com/AppCenter?action=diff&rev2=64&rev1=63>
<slangasek> mpt: "eventually", but not necessarily in the karmic timeframe? (I'm trying to get MultiarchSpec right, which requires touching some of these components)
<mpt> slangasek, yes, I expect in 9.10 software-properties-gtk will stay but possibly have some tweaks
<calc> slangasek: i doubt i will have time in the next week, so if you have the time to look at it that would be good
<slangasek> calc: ack, claiming the bug, thanks
<slangasek> mpt: okie
<Keybuk> http://people.ubuntu.com/~scott/boot-performance/Fedora-11-i686-Live_Dell-Mini9.png
<mpt> slangasek, is that likely to involve interface changes to s-p-gtk
<mpt> ?
<mpt> The multiarch stuff, I mean
<ogra> Keybuk, sill faster than ubuntu LTSP with unionfs-fuse :P
<slangasek> mpt: yes; since this is meant to completely supersede ia32-libs and friends, it's important that users have a straightforward way to enable it, and s-p-gtk is the logical place for that to live
<slangasek> mpt: I'm envisioning a trivial UI, fwiw, just one more checkbox or so ;)
<mpt> I'm not familiar with ia32-libs, so I'm not clear about why it would need to be enabled or disabled
<slangasek> Keybuk: I'm meaning to follow up on list as well, but I noticed your analysis of "must do before the desktop" doesn't include the network; that's going to break various enterprise use cases, does that factor into your design somewhere yet?
<slangasek> mpt: it's needed if a user wants to run any 32-bit binaries on their 64-bit install; skype, wine, etc
<slangasek> (flash)
<slangasek> mpt: the alternative to having it in the s-p-gtk UI would seem to be giving users long instructions for mangling /etc/apt/sources.list at the commandline, and that's not really appropriate for ia32-libs' target audience IMHO
<mpt> slangasek, so if your system if 64-bit but you want to run a 32-bit application, you need to replace some of your installed 64-bit libraries with the 32-bit equivalents? Or install the 32-bit equivalents alongside?
<slangasek> mpt: alongside
<mpt> if->is
<slangasek> ia32-libs is the current, kludgirific way of doing this
<mpt> slangasek, ok, so what would the option be?
<slangasek> as in, what would the label say?
<slangasek> "enable 32-bit software" or "enable 64-bit software", according to the architecture; or something better if you think that's a bad label
<directhex> slangasek, two f's in kludgeriffic
<mpt> slangasek, and what would the other choice be?
<slangasek> mpt: mentioned now at https://wiki.ubuntu.com/MultiarchSpec#Migration; in the perfect world, the user would never need to click this because update-manager can take care of it on upgrade
<slangasek> mpt: the other choice would be to not enable it
<mpt> slangasek, and what would happen if you didn't?
<slangasek> you would have access to all the software built for 64-bit Ubuntu, but not access to the packages needed in order to install closed-source 32-bit software
<mpt> slangasek, ok, so why would someone want to not enable it?
<mpt> (Sorry for these basic questions, this is all to help with the labelling)
<slangasek> mpt: it doubles the bandwidth cost of an apt-get update because you have to grab two copies of each Packages file
<slangasek> no worries; I expected that to be the next question :)
<lajjr> hello pitti.
<mpt> slangasek, and would that be the only difference?
<slangasek> mpt: I think that, and possibly some slow-down on apt's own calculations, would be the only material difference users are going to care about
<slangasek> I could say "you might accidentally pull in a 32-bit package because there's no 64-bit package available", but, er, good then :)
<slangasek> mpt: I guess I would see this being similar to the fact that we give you the ability to disable downloads from main and universe, but enable them by default
<mpt> slangasek, so let's say I'm using 64-bit Ubuntu, I have the option turned on, and I download a 32-bit Skype .deb and double-click on it. Will gdebi tell me that I need to install some 32-bit libraries that I already have 64-bit versions of?
<mpt> Is that how it works?
<walters> slangasek: is debian going to adopt this plan as well?
<slangasek> mpt: I've actually never used gdebi; but assuming it's not reinventing the wheel, its behavior should be the same as if you click on a package that has other, 64-bit lib dependencies that need to be installed
<slangasek> walters: I expect so; we have buy-in from a member of dpkg upstream
<fta> slangasek, subversion seems to be broken now: http://paste.ubuntu.com/191846/   is that a known issue?
<mpt> slangasek, sorry I don't know what that behavior is, I've never had a 64-bit installation
<slangasek> mpt: s/64-bit //
<slangasek> mpt: i.e.: the behavior should be identical to what it already does when you try to use it to install a .deb with currently unsatisfied dependencies
<slangasek> presumably it will automatically install any that it can find, and throw an error for any it can't?  if it directs you to s-p-gtk in the latter case, even better
<mpt> slangasek, ok. On the other hand, if I have the option turned off, it will ... what? fail?
<slangasek> fta: wasn't known to me; sorry, file a bug and assign it to me, since apparently I broke it?
<fta> slangasek, ok
<slangasek> mpt: it would necessarily fail, yes; I don't have a preference for how it presents this failure to the user, I'm happy to have input there
<mpt> slangasek, soooo ... Sorry if this has already been considered (I don't see it when scanning the spec), but did you think about downloading the 32-bit Packages file only if and when you're trying to install a 32-bit package that depends on uninstalled libraries?
<mpt> (or uninstalled anything-else, I guess)
<fta> slangasek, bug 385318
<ubottu> Launchpad bug 385318 in subversion "svn: Unrecognized URL scheme" [Undecided,New] https://launchpad.net/bugs/385318
<maxb> That's a dupe of one that I've made a debdiff for and subscribed sponsors
 * maxb will find number once my desktop has booted
<maxb> bug 384715
<ubottu> Launchpad bug 384715 in subversion "subversion 1.5.6 built without ra_neon" [Undecided,Confirmed] https://launchpad.net/bugs/384715
<slangasek> mpt: while we could have gdebi trigger that automatically if we think that's reasonable, it can't be the only way to enable grabbing the 32-bit Packages file because there will be other use cases we want to support besides gdebi (e.g., Add/Remove Software or whatever will replace it, which can't reasonably have the index available without also downloading the Packages...)
<slangasek> mpt: and, given that we prefer for philosophical reasons to have packages downloaded from the repositories instead of being installed by clicking on a .deb, the design shouldn't give a better user experience via gdebi :)
<mpt> slangasek, I wasn't suggesting this for gdebi only, I was just using it as an example
<mpt> but I guess if you haven't downloaded the 32-bit Packages file in the first place, you won't even see the 32-bit multiverse application you want to install, let alone its dependencies
<slangasek> exactly
<mpt> ok, I think I finally understand
<mpt> thank you for your patience :-)
<slangasek> no problem :)
<slangasek> now that you understand, what guidance can you give me? :)
<mpt> so I guess this checkbox would be sensitive only if you were actually running 64-bit
<mpt> and it would say something like "Include 32-bit packages in available software"
<slangasek> fwiw, there are use cases for being able to install 64-bit packages on 32-bit systems as well; though these are much more marginal and AFAIK are entirely developer-oriented, so I'm ok with not including the checkbox for that case
<slangasek> directhex: etymologically incorrect, btw :)
<directhex> slangasek, aw :(
<ion_> To be accurate, âkludgeâ itself is etymologically incorrect. ;-)
<ion_> http://catb.org/~esr/jargon/html/K/kludge.html
<calc> ug i can't find where the old OOo build was symlinking the files
 * calc thinks it was probably some magic stuff
<slangasek> magic, in OOo's build? neveerrrr
<calc> slangasek: hehe
 * calc checks to see when it last actually worked properly
<calc> 3.0.1-9ubuntu2, hmm wtf
<calc> i can probably make it work again but it would be nice to find out why it stopped working, to make sure it didn't break anything else... and i can't see how it worked before :-\
<slangasek> mpt: ok, thanks for you help - I've inserted your suggested language in the spec, now back to working on release-y stuff :)
<calc> lmao, this works for debian, even more fun
<calc> so now it looks like i get to see what i managed to break in a merge
<mrooney> Anyone know if Empathy and Banshee will be default for Alpha 2?
<mrooney> Also, grub2?
<ion_> https://wiki.ubuntu.com/KernelTeam/Grub2Testing
<directhex> apparently i no speel gud :(
<seb128> mrooney: banshee will not be default until all the issues mentioned at uds will be fixed including accessibility which is not going to be today
<seb128> not to mention some extra one, like banshee upstream not being able to have a clear schedule which means we don't know if 1.5 can be used before karmic
<slangasek> maxb: 384715> ugh, that bug offends all my sensibilities
<slangasek> so subversion was working just fine with neon 0.28.4, up until we rebuilt against it. yay.
<maxb> slangasek: Yes, it's fundamentally dumb
<maxb> But it is fixed more sanely in upstream 1.6
<slangasek> I'll get the configure script neutered later today and upload
<mrooney> seb128: ah ok. I saw your memory tests by the way, I have been keeping a list including a list of bugs and links at https://wiki.ubuntu.com/MikeRooney/KarmicBansheeAsDefault, thought you might be interested, it also includes a link to the upstream metabug
<doko> why does libasound2 depend on libpython2.6?
<slangasek> doko: because I fixed its previous build-dependency of python2.4-dev to point to python-dev like it was meant to :)
<slangasek> /usr/lib/alsa-lib/smixer/smixer-python.so
<doko> slangasek: hmm, is this really needed on the CD?
<slangasek> doko: is that the only thing pulling libpython2.6 in?
<slangasek> it's probably not needed on the CD, but I doubt it's worth the effort of splitting it if libpython2.6 is already there
<doko> slangasek: well, I didn't check for the CD, just did see it in my chroot added.
<slangasek> it was already on the CD in jaunty
<doko> maybe we should fix these packages ...
<slangasek> no objections from me if you think it should be dropped
<slangasek> I was just fixing the python2.4-dev build-dep, which was clearly wrong
<doko> I'll ask mterry ;-)
 * slangasek grins
<mterry> :-/
<slangasek> anyway, no one in Debian or Ubuntu noticed that the asound python bit wasn't built, until I went cleaning up the python2.4 revdeps
<mterry> I'm sure that falls under doko's 20%  :)
<doko> mterry: only if you do the glibc-2.10 upgrade ;-p
<mterry> doko: Couldn't I just do some laundry for ya or something instead?  My 80% of doko-time could be all your non-ubuntu tasks, so you can devote more hours to Ubuntu.
<hyperair> hmm am i the only one who doesn't have working laptop brightness keys now?
<doko> mterry: my luggage didn't arrive yet, you'll have to wait until tomorrow ...
<slangasek> ttx: do you have a bug number for the likewise-open5 breakage?
* slangasek changed the topic of #ubuntu-devel to: Archive: soft freeze for alpha-2 | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> ttx: issue documented in the tech overview, but I would prefer to have an LP bug # that I can link in
<Adri2000> mvo: do you plan an app-install-data-ubuntu sru for jaunty? it would be useful for bug #338419
<ubottu> Launchpad bug 338419 in filezilla "Filezilla fails to install " [Undecided,Invalid] https://launchpad.net/bugs/338419
<mvo> Adri2000: I was not really planning one, but its trivial enough - if its anoying to enough users we can do it
<mvo> Adri2000: lets talk about it tomorow, I need to leave for today
 * mvo waves
<slangasek> persia, YokoZar: what are the plans for MID looking like?  I see that livefs builds are commented out, with a pointer in y'all's direction. :)
<YokoZar> slangasek: we need to transition a whole bunch of packages to rebase off Mer
<slangasek> what's Mer, then?  That's the second mention I've seen of it, but I don't know what it is
<YokoZar> Basically they're our new upstream
<YokoZar> http://wiki.maemo.org/Mer
<ogra> sladen, mer is the new maemo :)
<ogra> err s/sladen/slangasek/
<slangasek> hrm.  Mer is the new Maemo?  I thought MID was based on Moblin, not Maemo.  I'm so confused :(
<cjwatson> mrooney: grub2> see ubuntu-devel-announce :-)
<ogra> slangasek, right, mer is the attempt of freeing up maemo completely and moblin completely moved to netbooks, MID is rather for touchscreen driven devices will very small screens
<ogra> so moblin isnt the right base for MID anymore
<slangasek> oh
<ogra> and mer is driven by the community
<pochu> slangasek: would you mind including $release (e.g. Karmic) on your "Main frozen for Alpha X" mails? :)
<slangasek> pochu: well, I don't guarantee that I'll consistently remember to include it
<pochu> slangasek: that's ok. I thought you had a template or a script though ;)
<james_w> I read that as "I don't guarantee to always remember what release it is"
<pochu> lol
<slangasek> no script, I just copy previous mails and edit them
 * slangasek considers whether dropping libboost-mpi entirely would be ok
<slangasek> james_w: that's not implausible, either ;)
<slangasek> ScottK: do you have any opinion on pruning libboost-mpi?  Nothing uses it, and it would spare us a variety of mpi MIRs
<TheMuso> asac: I'd say it will, but I don't know exactly when.
<asac> TheMuso: was that really directed to me?
<TheMuso> asac: hrm I thought you were the one who asked the question but I'd need to check my backlog again to be sure, sorry for the bother if it wasn't meant for you.
<Viper550> has someone seen this? http://www.youtube.com/watch?v=a1U0dK2HpUk plymouth can run on ubuntu?
<ogra> sure, but it wont be used
<ogra> it can run on certain HW since jaunty
<cjwatson> we discussed plymouth and decided not to use it because (a) usplash can run on kms too so there's no driving reason to drop it, (b) we'd basically have to bring plymouth up to par with usplash in various ways (c) plymouth doesn't really seem to offer anything stunningly new - for example it still uses .so objects for theming (AIUI)
<ogra> d) a splash is just a way to hide a slow bootprocess ;)
<cjwatson> oh, right, indeed, we'll be moving to avoiding a splash screen at all except when necessary for interaction
<ogra> solving the basic prob is more elegant :)
<cjwatson> and trying to bring X up as soon as possible instead
<kirkland> Keybuk: around?  what's the proper way in the init-script-less world to start a daemon on boot?
<kirkland> Keybuk: a newly developed from scratch daemon
<kirkland> Keybuk: i'm trying to avoid an init script
<sladen> kirkland: upstart files
<kirkland> sladen: agreed; is there documentation on creating an upstart configuration for starting a daemon?
<ogra> http://upstart.ubuntu.com/
<ogra> http://upstart.ubuntu.com/wiki/
<kirkland> ogra: thanks
<sladen> kirkland: and have a look in /etc/event.d/ for the existing uses
<cjwatson> kirkland: it's all going to change soon ...
<slangasek> mr_pouit, cody-somerville, NCommander: xubuntu-desktop depends on xfce4-dict-plugin, which is NBS?
<kirkland> cjwatson: right, those "changes" are what i'm asking about
<cjwatson> so now is perhaps not the best time to do it; I would advise continuing to use init scripts for now
<kirkland> (i think)
<cjwatson> all I've heard is Keybuk talking abou ti
<cjwatson> about it
<kirkland> cjwatson: :-)
<kirkland> cjwatson: right, this is why i'm trying to sync up with him
<cjwatson> from what I have heard, I think the upstart wiki is probably not up to date with his latest work
<slangasek> hmm?  there are going to be significant design changes?
<kirkland> cjwatson: i was contemplating an @reboot cronjob, for kicking it off
<kirkland> cjwatson: would this be horrible and evil?
<cjwatson> kirkland: why not just use an init script?
<cjwatson> seriously
<kirkland> cjwatson: oh, i don't mind, using an init script, i just thought we were trying to get rid of init scripts
<kirkland> cjwatson: and i was trying to avoid introducing a new one
<cjwatson> yes, but we're not there yet, so I'm not sure anticipating that is helpful right now
 * kirkland is quite happy with init scripts
<sladen> kirkland: /etc/event.d/logd   exec ...   resprawn
<kirkland> cjwatson: word.
<slangasek> "why not" - because that leaves the admin with no way to manage the state of the daemon, and no way for package maintainer scripts to interact with it
<cjwatson> slangasek: so I understand, yes
<cjwatson> (significant design changes)
<cjwatson> he was talking about it at various stages during UDS
<kirkland> sladen: thanks
<slangasek> cjwatson: are those going to be done by the 22nd? :)
<kirkland> sladen: that looks like what i need
<cjwatson> slangasek: now that I don't know, though I understand he's going to try of course
<Viper550> hmm speaking of init, <leinir> bero's new init system is so fast that really, when the splash screen gets shown, you should already be loading up xorg :)
<cjwatson> kirkland: logd is special because upstart itself owns that
<cjwatson> kirkland: I don't think it should be used as an example by the rest of the archive yet
<cjwatson> Viper550: is that fedora? they're using upstart
<Viper550> no, ark linux. another rpm distro. we're currently starting to modernize it a bit for our long-anticpated 2009.1 release
<kirkland> cjwatson: okay, init script it is
<Viper550> we're switching to libzypp from APT-RPM
<Viper550> and heck it even works with rpm5
<cjwatson> Viper550: we should be able to do just that with karmic - load X when we're currently loading the splash screen, near enough
<cjwatson> and that's definitely what we're shooting for
<ogra> without reinventing an init system though :)
<Viper550> so are we gonna minimalize the splash screen?
<ogra> we already did that before
<cjwatson> well, the init system is involved
<cjwatson> what does "minimalize the splash screen" mean?
<ogra> 2x2 px splash ? :)
<slangasek> meh, NBS is such a mess right now
<Viper550> as in...remember Windows Vista changed it to just a progress bar?
<cjwatson> Viper550: it's already just a progress bar plus a background ... from my point of view, "whatever"
<ogra> the plan is to be fast enough to not have a splash at all
<cjwatson> I don't really care that much what the art guys do with it :)
<sladen> Viper550: karmic+1 should have no visible splash (except in the case of fsck).  Some of the stuff might land sooner
<Viper550> on 7 its just an animated "pulsing" progress bar with "Starting Windows..." below it
<dtchen> slangasek: speaking of NBS, feel free to kill libpulsecore9
<Viper550> maybe just a basic logo and throbber for the installed system on kamic.
<sladen> Viper550: that's what usplash is, right?
<ogra> just to see it flashing by ?
<ogra> if you boot fast enough you dont need a splash
<slangasek> dtchen: done.  is there an lpia build failure there that's being worked on?
<Viper550> no, ours has a big logo and a thin progress bar
<dtchen> slangasek: looking
<cjwatson> Viper550: feel free to get in touch with the art folks about that
<sladen> Viper550: what is that different?  ("ours" == fedora?)
<Viper550> ubuntu has a big logo/thin progress bar
<ogra> it wont anymore if there is no splash anymore
<sladen> Viper550: it actually as a huge logo--- eg. 1024x768.  Most of it is black though
<ogra> if your boot is fast enough you dont need a splash at all, you just start X
<ogra> and thats the target
<Viper550> but for the slower computers...it would still be good to have at least some indicator rather than a black screen. blank screens scare noobs.
<Viper550> I think for karmic, just a greyed out ubuntu logo with a small circular throbber in it on the bottom-center
<ogra> they will likely just have X with an idle cursor
<ogra> not a black screen
<sladen> Viper550: when you turn on the computer, you get ~10-15 seconds of black whilst the monitor warms up/syncs, and the initial bootstrap code loads.  ~3-5 seconds is alot less than that
<Viper550> I got an lcd monitor
<ogra> and your PC has a BIOS, doesnt it ?
<ogra> common bioses take 5-20sec
<Viper550> on 4 of our computers. and my bios on my HP in my room has a blue screen not a black one.
<ogra> where you are at a black screen
<Viper550> in between end splash and loading X
<dtchen> slangasek: yes, lp #375595. chasing now.
<ubottu> Launchpad bug 375595 in libcap2 "libcap2 FTBFS for lpia" [Undecided,New] https://launchpad.net/bugs/375595
<sladen> Viper550: pretend that the splash wasn't there, and that same second of couple black was between grub and X
<cjwatson> we'll certainly still have the facility to start usplash in various circumstances (e.g. fsck, dm-crypt), so running it on slow computers as well is basically an implementation detail AFAICS
<Viper550> woah...
<cjwatson> and I think that would indeed be a desirable thing to do
<cody-somerville> slangasek, I'll fix that
<sladen> <sladen> Viper550: karmic+1 should have no visible splash (except in the case of fsck)
<Viper550> but for karmic,
<cjwatson> sladen: whence "karmic+1"?
<cjwatson> sladen: the plan of record is to do that for karmic
<Viper550> it would be good to start on the right direction
<sladen> Viper550: how most of these progress bars work, is that you allow a period of time, which is the maximum a user is comfortable with, without seeing any movement (eg. 100msc, or .5 second, or 3 seconds, depending on the situation).  And then at that point you poke/rotate the icon/progress bar/throbber
<sladen> Viper550: in the case of boot, people are already used to seeing ~3 second black screens at X transition, and considerably more at the BIOS/pre-Grub.  Therefore, there's a 3 second budget before you have to poke the throbber/progress bar
<Viper550> sladen, also one thing I noticed, last time I used ubuntu (yes, the computer I speak of, currently runs freedos for no appearant reason), there is always this part of the bootup where the progress bar "ping pongs" before it actually does anything
<sladen> Viper550: so you can safely allow 3 seconds, and if X hasn't loaded by then, then you can fire up usplash
<sladen> Viper550: it ping pongs until it's possible to estimate the 0-100% progress
<cjwatson> Viper550: it turns out that we have sufficiently little idea in practice of how long the initramfs is going to take that displaying a throbber ("ping pong") there is better than a hopelessly inaccurate bar
<cjwatson> we used to try to display a monotonic progress bar there; it didn't work out so well
<Viper550> gOS (last version with Enlightenment I beleive, ubuntu based), I think, took about 24 seconds to boot through usplash (though it also had a rather ugly theme, BRIGHT GREEN BOOTUP FTW)
 * ogra hugs stgraber ... thanks for getting us a "usable" LTSP for A2 :)
<cjwatson> timings are meaningless without context :-) There are already machines that boot Ubuntu to a fully usable desktop in 12 seconds or so
<Viper550> my computer has 256mb ram, and a P3 equiv
<sladen> Viper550: yes, 25 seconds is about right for a recent *buntu
<Viper550> its an athlon thunderbird
<Viper550> and it has an older ATI graphics card (it replaced a Nvidia card it used to use, that started suffering from "scan line syndrome". We actually BOUGHT A NEW MONITOR cause we thought it was the monitor)
<stgraber> ogra: well, I haven't tested that code on a clean install yet so who knows :) but it can't be worse than before anyway
<ogra> i'd like to know if its as slow on real HW
<ogra> my vbox surely had enough ram allocated
<stgraber> I have a Core2Duo here as test thin clients, if it takes longer than 8s, then it slower than Jaunty :)
<ogra> heh
<ogra> if it takes less than 2min to boot i'm happy :)
<ogra> (at least until mount --union comes)
<soren> slangasek: I'm curious... When we build Hardy images after Hardy's released, do we still use the livecd-rootfs and cd building code that was in use when Hardy was released or do we use whatever's current?
<slangasek> soren: we use what's current, though we're careful to guard any relevant code changes that are incompatible with hardy with a distroseries check
<soren> slangasek: Interesting. Thanks.
<calc> slangasek: it currently looks like fixing the symlinking issue will be fairly hard, i found the spot in the code that does it but due to us having a separate -l10n source i have to determine how to make it actually work properly with that
<slangasek> calc: ok - not critical for alpha-2, so therefore not worth the risk of an upload right now
<calc> slangasek: currently it looks in ooo-common and anything in that and also in the l10n-XX package gets a symlink, but i think for the l10n package the ooo-common no longer exists at all due to changing over to dh_install
<slangasek> ah
<calc> so i'm not sure how to fix it atm, will definitely be interesting, heh
<calc> i delay my next upload until after a2 release and try to get the l10n size issue fixed as soon as i can determine how to, may be after my next upload though
<calc> er i'll delay
<maxb> Why does the apport retracer remove CoreDump.gz attachments? Is the rationale one of potential privacy issues?
<slangasek> yes
#ubuntu-devel 2009-06-10
<Viper550> wait GRUB2?
<Viper550> and are we ever going to use gfxboot on an install/
<cody-somerville> Viper550, we're getting rid of usplash
<cody-somerville> Viper550, We think we can boot so quickly we don't need anything like that
<TheMuso> cody-somerville: its not going away entirely, it will be used for fsck/dm-crypt password entry.
<cjwatson> soren,slangasek: I think livecd-rootfs actually runs in a hardy chroot for hardy CD builds, and we use the hardy version of it; however the ISO building code is central and so has to be guarded as slangasek says
<slangasek> ah
<slangasek> does that mean we could trim the hardy exceptions in the current version of livecd-rootfs? :)
<cjwatson> slangasek: check with Adam, but I think so
<Cameron> hi.. i'm trying out grub2, and managed to get it to work on jaunty, both chainload and native.  This was done using a separate hdd for /boot since my root partition is ext4 on lvm.  Now, I wish to test using /boot on my root partition.  I reconfgured /boot to be a normal folder, and ran this : grub-install /dev/sda  I received this error "error: Unknown metadata header" followed by grub-probe: error: no mapping exists for `Ubuntu
<Cameron> -jaunty'
<Cameron> then this Auto-detection of a filesystem module failed.  Please specify the module with the option `--modules' explicitly.
<Cameron> cjwatson: you about ?
<shaya> wondering if others are getting spammed like crazy by apport retracing service today on old bugs?
<TheMuso> shaya: Yes, I am.
<maco> aye
<cjwatson> Cameron: about to go to bed, please do file a bug though - not many people have tried grub2 on lvm root yet (at least not in Ubuntu) and we clearly need to sort some things out
<Cameron> cjwatson: shall do, thanks
<Cameron> cjwatson: fyi the bug is here https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/385428
<ubottu> Launchpad bug 385428 in grub2 "grub2 boot from lvm Auto-detection of a filesystem module failed" [Undecided,New]
<Cameron> thanks ubottu :)
<AnAnt> Hello, is gdm2 available in any PPA ?
<AnAnt> gdm 2.26 that is
<Hobbsee> AnAnt: #launchpad for ppa questions.
<persia> Hobbsee, Including content search?  I thought that was beyond the scope of that channel as well.
<Hobbsee> persia: you're probaby right there.  Unless they can point him to where the search over ppas actually is
<persia> I remember hearing about the PPA search tool recently, but I understood it to be external to LP itself.
<nhandler> persia: You are probably thinking about http://ppa-search.appspot.com/
<AnAnt> I thought maybe the ppl working on the new GDM were here, that's why I asked
<persia> nhandler, Quite possibly, indeed.
<AnAnt> yup, found it, thanks
<poolie> hi, i'm running karmic with an intel gm965
<poolie> in the last couple of days the screen has started sometimes going irretrievably blank
<poolie> can anyone give me a pointer or should i just file a new bug?
<persia> poolie, Have you experimented with the xorg-edgers repo?  It may break things more, but it may break them less.
<poolie> yeah lifeless just suggested that
<persia> (they don't call themselves the "Xorg Crack Pushers" for nothing.
<poolie> it feels a bit like randomly changing things
<poolie> i'd rather have some tea
<persia> It *is* randomly changing things.
<persia> But theoretically, if you have an issue, and it's fixed by the crack, that's valuable information to provide in the bug.
<poolie> yes
<poolie> i'll file a bug then try it
<Hobbsee> poolie: oh yeah, i've been noticing that.  it's a pain
<poolie> ok bug 385448
<ubottu> Launchpad bug 385448 in xorg "i965 hangs with black screen" [Undecided,New] https://launchpad.net/bugs/385448
<poolie> hello Hobbsee
<Hobbsee> poolie: heya!
<nixternal> come on, accept kdebindings binaries already :p
 * nixternal needs python-kde4 to continue working
<poolie> so there seem to be no karmic builds in
<poolie> deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu jaunty main
<lifeless> deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main
<ScottK> nixternal: I'd love to help you, but the package has mono stuff in it.
<ScottK> ;-)
<nixternal> lol
<nixternal> w/o kdebindings getting in, anything with pykde will not work
<nixternal> things such as ubiquity, gdebi, printer, and so forth
<ScottK> nixternal: I'm looking at it for binary New now.
<lifeless> https://edge.launchpad.net/~xorg-edgers is the one : it has the git builds that lead into what will land in ubuntu
<ScottK> nixternal: Accepted.  You should have the binary in ~90 minutes.
 * nixternal hugs ScottK 
<poolie> lifeless: thanks, i think that's a bit too scary atm
<poolie> or rather, beyond the depth i want to get into this
<poolie> at least til bryce asks
<lifeless> poolie: so, bryce has asked somewhat generally :). But thats ok - I'm sure he will
<pitti> Good morning
<nixternal> and good morning to you sir
<pitti> hey nixternal
<\sh> moins
<\sh> slangasek: thx...I solved it in a more sane way..."do not install menu.lst manually, but call update-grub -y, so it installs a newly created menu.lst"
<slangasek> that would also do it
<slangasek> "sane" - it discards any existing settings in menu.lst, so it's not usually my first recommendation
<\sh> slangasek: the problem was during initial installation...so it doesn't have any changes :)
<slangasek> ok
<StevenK> Blink
<StevenK> Where did the udev rules go ....
<pitti> StevenK: to /lib/udev/rules.d/ ?
<StevenK> Sigh. Nice if /etc/udev/rules.d was a symlink to that, but dpkg doesn't like that situation
<pitti> nah, it shouldn't
<pitti> /etc/udev/rules.d is for local customization
<dholbach> good morning
 * pitti hugs dholbach
 * dholbach hugs pitti back
<StevenK> pitti: Ah, so I can drop a rule in /etc/udev/rules.d and it will override what is in /lib/udev/rules.d for say, that particular SUBSYSTEM ?
<pitti> StevenK: AFAIK they are executed in addition
<maxb> same-named files override
<maxb> or at least, that's what the manpage claims
<pitti> "Files in /etc/udev/rules.d/ have precedence over files with
<pitti>        the same name in /lib/udev/rules.d/."
<pitti> right
<\sh> unsubscribe ubuntu-devel-discuss
<\sh> done
<ttx> slangasek: created likewise-open5 bug 385475
<ubottu> Launchpad bug 385475 in likewise-open5 "[Karmic] Likewise-Open 5 fails to authenticate users" [Undecided,New] https://launchpad.net/bugs/385475
<jamesh> pitti: hi.  there was a bit more discussion about the Erlang packages that it seems you weren't CC'd on.  I've just forwarded you an email with the current status.
<\sh> releases.ubuntu.com
<\sh> down?
<\sh> argl...damn telemaxx carrier
<iulian> \sh: Seems so.  It failed to connect here as well.
<\sh> iulian: from my home carrier (kabelBW) it works
<iulian> Huh?  That's odd.
<iulian> It fails to connect here.
<\sh> iulian: which ip address do you get for releases.ubuntu.com?
<\sh> 130.239.18.163 or 130.239.18.137 ?
<\sh> looks like that it's a dns caching problem .. good to know that my DNS on my rooty is configured properly and not doing wile things
<\sh> s/wile/wild/
<iulian> \sh: releases.ubuntu.com has address 130.239.18.163
<\sh> iulian: and that's wrong..dns caching issue...
<soren> cjwatson: Ok. Thanks for clarifying.
<\sh> I just kicked our DNS admin to do his job
<nixternal> pitti: re: apport - should I look at implementing the features that GTK has compred to Qt? is there a reason they aren't implemented already?
<nixternal> also, re: apport-qt - it will be rewritten in PyKDE4 - which is what I am messing around with now
<AnAnt> Hello, why is wine in Ubuntu different than in Debian ?
<AnAnt> I mean that Ubuntu doesn't use Debian's wine package
<directhex> YokoZar, customer for you
<YokoZar> directhex: oh?
<directhex> AnAnt, (yokozar is in a yank timezone, so best to ask when america is awake)
<directhex> oh. erm...
<directhex> YokoZar, AnAnt's query
<YokoZar> AnAnt: Because our Wine package provides more integration stuff and isn't split into useless subpackages
<AnAnt> aha, ok
<AnAnt> YokoZar: so, will wine 1.1 be in karmic ?
<AnAnt_> sorry, I got d/c
<AnAnt_> YokoZar: so, will wine 1.1 be in karmic ?
<YokoZar> AnAnt_: 1.2 might be released in the Karmic timeframe
<YokoZar> I don't want to hold people back on 1.0 for another release
<AnAnt_> YokoZar: do you mean, that it is either 1.0 or 1.2 ?
<YokoZar> So i've been pushing pretty hard upstream to have 1.2 out
<YokoZar> 1.1 are development releases that aren't regression tested
<AnAnt_> is 1.1 an unstable release ?
<YokoZar> Yes, very much so
<AnAnt_> aha, ok, thanks
<nixternal> pitti: I am heading to bed, go ahead and highlight me with a response so I can work on it when I get up and about, thanks!
<AnAnt_> oh, yes they are in experimental ! my bad !
<YokoZar> I may need to pick a 1.1.x version and regression test it heavily around feature freeze if it looks like wine 1.2 isn't coming out in time
<tjaalton> asac: hey, do you have plans to upload the fix to bug 220628 to jaunty-proposed?
<ubottu> Launchpad bug 220628 in libxcb "[MASTER] firefox-3.0b5 received an X Window System error: 'BadIDChoice'" [Unknown,Fix released] https://launchpad.net/bugs/220628
<cjwatson> pitti: Am I right in thinking that valid mount options have to be hardcoded into devicekit-disks - there's no mechanism for filesystems to ship fdi files or equivalent to override that? This is prompted by http://launchpadlibrarian.net/27592171/ntfs-3g_2009.4.4-1ubuntu1.patch (attached to bug 349569) which includes the changelog entry "Don't install HAL fdi file. Mounting is done via devkit-disks now."
<ubottu> Launchpad bug 349569 in ntfs-3g "Please merge ntfs-3g 2009.4.4-1 (main) from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/349569
<cjwatson> pitti: but the fdi file was added as a workaround because the kernel driver doesn't support locale=
<asac> tjaalton: oh right.
<asac> tjaalton: if you want, go ahead ;)
<tjaalton> asac: ok :)
<cjwatson> lamont: I don't suppose you could have a look at bug 319656 (presumably wearing your Debian hat)? I can't reproduce the problem here and don't know nmap well enough to want to guess
<ubottu> Launchpad bug 319656 in nmap "nmap script engine error" [High,In progress] https://launchpad.net/bugs/319656
<Ampelbein> cjwatson: I can reproduce the issue with nmap. I sorted out the various "not a file" errors by copying the missing scripts to /usr/share/nmap/scripts, but still get http://paste.ubuntu.com/192405/
<cjwatson> Ampelbein: I think it's probably best if lamont deals with it anyway, since he's the Debian maintainer :)
<Ampelbein> cjwatson: ok, just in case you (or lamont) need a "victim" to test fixes on: I'm here. ;-)
 * cjwatson belatedly remembers that during a soft freeze is a silly time to be catching up on main sponsorship. *blush*
<dholbach> cjwatson: do *verse sponsorship instead! :-)
<dholbach> unfortunately there's enough to choose from
<cjwatson> already am ;-)
<dholbach> although we're slowly catching up
 * dholbach hugs cjwatson
<chrisccoulson> hey pitti / cjwatson - i just saw the comment on bug 349569
<ubottu> Launchpad bug 349569 in ntfs-3g "Please merge ntfs-3g 2009.4.4-1 (main) from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/349569
<chrisccoulson> you had any thoughts about that yet?
<pitti> jamesh: ah, thank you
<pitti> nixternal: what's still missing in the qt version? It should be on feature parity now, AFAIK
<pitti> chrisccoulson, cjwatson: looking (just returned from appointment, sorry for delay)
<chrisccoulson> piit - no hurry. i was just wondering if you already discussed it or not
<chrisccoulson> **pitti
<chrisccoulson> lol
<directhex> seb128, ping - do you think it's preferable for banshee's magnatune plugin to spawn a web browser for purchases, or take people's credit card details straight in the app? rhythmbox does both (window for downloads, web page for cd purchases)
<seb128> directhex: hello, no real opinion on that I think both are fine, maybe better to ping mpt to get some design team advice though
<seb128> directhex: I would tend to say that using the website in a browser we are in a known environment security wise
<seb128> so it makes things easier
<directhex> seb128, i agree - but it's less "integrated"
<directhex> so damned if you do, damned if you don't
<seb128> that's why I say "no real opinion"
<seb128> I think both options will do
<seb128> so whatever somebody is wanting to do
<stgraber> pitti: hey, about the numlockx MIR, what do you mean by the two questions from comment 1 ? Didn't I answer them in the following comment (and in the MIR wikipage itself) ? or did I miss something ?
<pitti> cjwatson: I asked on the upstream ML
<pitti> stgraber: right, I see now that you mentioned the Xsession.d file in the MIR; are you going to look after the package then?
<directhex> seb128, a clicky button which spawns "xdg-open https://magnatune.com/buy/choose?sku=XXXXXXXXXXX&sitePrefix=" is the easy option - assuming one can retrieve the value for XXXXXXXXXXXX somehow, without downloading & searching the full site database client-side. i've mailed magnatune to ask foir suggestions
<directhex> looks like jamendo's api is miles better
<seb128> ok
<cjwatson> pitti: thanks
<stgraber> pitti: yeah
<\sh> cjwatson: are you interested in some theories that the udev.postinst is quite dangerous at some time? :)
<siretart`> If I'm reading udev.postinst right, then a dpkg-reconfigure udev will instantly kill /sbin/udevadm
<\sh> cjwatson: actually a well configured udev is available then you just do out of couriosity a dpkg-reconfigure -a -f noninteractive and /sbin/udevadm is just gone
<siretart`> which is rather bad :-)
<stgraber> pitti: btw, didn't I also answer this question in the reply to your comment ? (in-line)
<pitti> stgraber: I don't see it anywhere
<stgraber> "Oh, thanks for spotting this. I'll update that part of the MIR.
<stgraber> I'm fine maintaining it in Ubuntu as I'll be the main user of it anyway."
<pitti> ah, heh
<lamont> cjwatson: I'll get a look at it this week
<cjwatson> \sh: -> Keybuk
<cjwatson> lamont: thanks!
<Keybuk> \sh: why would you ever dpkg-reconfigure udev?
<\sh> Keybuk: tbh...it is an accident of lazyness ;)
<ogra> heh, accidential lazyness ? sounds funny
<\sh> Keybuk: but nevertheless, if someone would call dpkg-reconfigure -a or dpkg-reconfigure udev he/she will run into this very problem and has a system which can't update any kernel/initramfs anymore
<Keybuk> \sh: can't see a bug about it
<\sh> Keybuk: I'll file one...
<cjwatson> I agree that the current code looks wrong
<ogra> accidential lazyness ;)
<cjwatson> (although it's a corner case)
<\sh> cjwatson: sure :)
<Keybuk> cjwatson: any idea for a fix?
<cjwatson> Keybuk: wrap the contents of enable_udevadm with if [ -e /sbin/udevadm.upgrade ]; then ... fi
<Keybuk> cjwatson: seems sane
<Keybuk> though you wouldn't want to restart udevd either
<Keybuk> in fact
<Keybuk> at a quick glance, none of configure is appropriate
<cjwatson> DEBCONF_RECONFIGURE=1 is set in the environment during reconfigure, if you want to guard it
<Keybuk> that's probably the easiest
<\sh> hmmm...
<Keybuk> \sh: bug #366185
<\sh> Keybuk: bug #366185 looks just the same...
<ubottu> Launchpad bug 366185 in update-manager "dpkg-reconfigure udev deletes udevadm" [Medium,Triaged] https://launchpad.net/bugs/366185
<\sh> Keybuk: I see you just renamed it :)
<Keybuk> yeah, just read through the bugs
<\sh> Keybuk: thx for taking care :) do you think it's worth an -proposed/-updates upload?
<\sh> for jaunty
<Keybuk> I always say no until someone says otherwise ;)
<\sh> Keybuk: I'd say yes, 2 1/2h of debugging is a lot of time..and time is money ;)
<Keybuk> I meant someone in ubuntu-release ;)
<\sh> Keybuk: oh I forgot that ;)
<stgraber> pitti: thanks
<lifeless> should evince be able to print pdf's?
<liw> lifeless, I do it frequently
<lifeless> ctrl-P is not working and thereis no 'print' in my evince menu...
<lifeless> buggeration time
<pitti> hm, I print from evince all the time
<lifeless> It works if I adda print button to the toolbar
<lifeless> just the hotkey and menu item are awol
<pitti> lifeless: hm, both work for me, in jaunty and karmic
<pitti> weird
<lifeless> this is jaunty
<soren> lifeless: What are you trying to print?
<lifeless> soren: a pdf
<soren> lifeless: Clever.
<soren> :p
<lifeless> that was sent to me to print out and sign
<soren> lifeless: Is it something that is likely to be marked "don't print"?
<soren> lifeless: Ah.
<soren> Ok, then probably not :)
<lifeless> soren: see above, adding a toolbar icon let me print
<soren> lifeless: Yes, I saw. I was just trying to figure out if *that* was the bug.
<pitti> lifeless: do you also get it on /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf ?
<soren> Truth be told, I don't know how evince deals with "non-printable" PDF's.
<liw> lifeless, if it is the same PDF I was sent, my evince shows a print item in the menu just fine (jaunty)
<lifeless> pitti: same behaviour
<lifeless> liw: from the isle?
<lifeless> liw: if so, yes.
<lifeless> foo
<lifeless> E [10/Jun/2009:22:40:11 +1000] PID 20891 (/usr/lib/cups/backend/ipp) crashed on signal 6!
<lifeless> the above however makes it hard to actually get the paper out of the print
<lifeless> er
<sabdfl> Setting up linux-restricted-modules-common (2.6.28-13.17) ...
<sabdfl> update-rc.d: warning: /etc/init.d/linux-restricted-modules-common missing LSB information
<sabdfl> update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
<sabdfl> is that normal?
<ogra> sabdfl, if the maintainer didnt update the initscript to newer LSB yet, yes ... its just a warning though
<ogra> doesnt do any harm
<sabdfl> doesn't look like something we should have in a kernel package, though
<ogra> agreed
<sabdfl> pgraner: ^?
<mok0> sabdfl: ah, yes, it's missing all that header stuff
<mok0> ... but it does use the proper lsb functions
<mok0> Isn't the init system going to be transitioned anyways?
<wgrant> mok0: That's been happening next release since Edgy :P
<ogra> if Keybuk makes it in time :)
<mok0> Heh, ok
<mok0> That header information is supposed to give some kind of dependency... allowing stuff to be started in parallel
<mok0> wgrant: btw, the science team is dwindling
<cjwatson> sabdfl: bug 3055878
<ubottu> Error: Launchpad bug 3055878 could not be found
<cjwatson> oops
<mok0> wgrant: only 4 members left :-(
<cjwatson> sabdfl: bug 305587
<wgrant> mok0: So it seems. :(
<ubottu> Launchpad bug 305587 in linux-restricted-modules "[Jaunty] warning: missing LSB information " [Undecided,Confirmed] https://launchpad.net/bugs/305587
<sabdfl> thanks colin
<Keybuk> ogra, mok0: upstart will still use those LSB headers
<Keybuk> in fact, we'll probably start to rely on them
<Keybuk> so them being missing or wrong is a bug for Ubuntu
<mok0> Keybuk: see sabdfl's question in the scrollback
<ogra> well, for karmic :)
<ion_> mok0: The more important thing is that their ordering can be automated. If new package baz must start before rc2.d/S20foo and after rc2.d/S20bar, the maintainer must discuss it with two other maintainers, and if 20foo is changed to 21foo and 20bar to 19bar, *that* may have repercussions for an indefinite number of other packages. Thatâs why Debian is trying to transition to automatic ordering based on LSB headers.
<ogra> in jaunty its only cosmetic ... while it will do harm in karmic
<Keybuk> mok0: what was sabdfl's question?
<ogra> sabdfl> update-rc.d: warning: /etc/init.d/linux-restricted-modules-common missing LSB information
<ogra> <sabdfl> update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
<ogra> <sabdfl> is that normal?
<Keybuk> right, it's not normal, it's a bug
 * Keybuk thought he covered that ;)
<mok0> Well, back to the old drawing board :-)
<mok0> terminal window, rather
<Keybuk> our sysv-rc doesn't use them
<Keybuk> but when we drop sysv-rc, we will
<ogra> and its already drawn :)
<mok0> bug 305587
<ubottu> Launchpad bug 305587 in linux-restricted-modules "[Jaunty] warning: missing LSB information " [Undecided,Confirmed] https://launchpad.net/bugs/305587
<Keybuk> my whiteboard appears to have a picture of a duck on it
<Keybuk> don't ask me why
<mok0> Keybuk: Ask Pat Robertson
<ogra> not walt disney ?
 * liw votes for Don Rosa
<mok0> ogra: Pat Robertson claims that gay marriage leads to sex with ducks :-P
<mok0> http://www.poormojo.org/pmjadaily/archives/026958.php
<ogra> aww
<mok0> Of course Jon Steward had a field day with that on TDS
<directhex> yay ducks
<Keybuk> mok0: http://andrewsullivan.theatlantic.com/the_daily_dish/2008/11/the-cosequences.html
<mok0> Keybuk: :-D
<ogra> asac, its back ! (klicking Keybuk's link got me broken fonts again)
<wgrant> ogra: Broken how?
<ogra> wgrant, http://people.ubuntu.com/~ogra/ff_fonts.png like that
<ion_> liw: Have you had a chance to look at my comments? No hurry at all, just curious to hear whether they are even remotely sane. :-P
<wgrant> ogra: That's probably a -intel bug.
<wgrant> There was one filed on fd.o a while ago... let's see if I can dig it up.
<ogra> wgrant, we werent sure yesterday ...
<ogra> that'd be cool
<ogra> it isnt really reproducable, just shows up after some time
<wgrant> Right.
<wgrant> I find it happens more when I close windows.
<ogra> and only in FF
 * ogra doesnt use windwos :P
<ion_> Every time someone talks about (non-)reproducable bugs, i canât help being reminded of the xkcd strip.
<asac> ogra: i was quite sure yesterday that its a driver bug ;)
<asac> file it against -intel
<ogra> lets see if we can link it to an upstream bug right away ;)
<ogra> if wgrant finds it
<wgrant> ogra: I can't seem to find it :(
<liw> ion_, nope, sorry, still digging myself out into the clear air
<liw> ion_, try again tomorrow :)
<ion_> :-)
<wgrant> Fedora bug #495323 looks relevant.
<ubottu> Error: Launchpad bug 495323 could not be found
<wgrant> Seems it was a kernel bug?
<wgrant> redhat 495323
<wgrant> fedora #495323
<cjwatson> (I find it sometimes copes better with URLs)
<wgrant> https://bugzilla.redhat.com/show_bug.cgi?id=495323
 * wgrant grumbles.
<ubottu> bugzilla.redhat.com bug 495323 in xorg-x11-drv-intel "text corruption with intel kms driver" [Medium,Closed: rawhide]
<wgrant> Aha! It lives.
<ogra> yeah, looks the same
<wgrant> - Add drm-intel-set-domain-on-fault.patch to fix random gem object corruption when swapping (495323 and probably others).
<wgrant> From their kernel changelog.
<Sarvatt> ogra, if you want to use UXA it needs a kernel update which went upstream a few weeks ago
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=21790
<ubottu> Freedesktop bug 21790 in Driver/intel "xf86-video-intel: pixmap corruption in the font glyph cache" [Major,Resolved: fixed]
<wgrant> Ah, that's the bug I was trying to find.
<ogra> Sarvatt, i'm running karmic, uses UXA by default
<Sarvatt> 2.6.30-8.9?
<asac> pitti: slangasek: StevenK: wonder if you would want to unsubscribe ubuntu-archive from 352968 for now as there will be some traffic now that i fix the build depends up-front
<ogra> bug 385561
<ubottu> Launchpad bug 385561 in xserver-xorg-video-intel "broken fonts in firefox with kms enabled" [Undecided,New] https://launchpad.net/bugs/385561
<Sarvatt> the fix is in karmic kernel 2.6.30-8.9 which is why I was asking if you were using that incase you weren't for some reason
<ogra> oh, wait, i use -7 still ...
<Sarvatt> if you are it could use going upstream because it didnt get fixed in your case
 * ogra curses the update-manager behavior once again
<Sarvatt> ahh that'd explain it
<ogra> let me update manually
<StevenK> asac: Done.
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<tkamppeter> pitti, I have a problem with applying the CUPS changes.
<pitti> tkamppeter: I saw your mail
<pitti> tkamppeter: Debian didn't take the change?
<pitti> tkamppeter: can we apply the change without the new option for now?
<pitti> tkamppeter: so that all these regressions will be fixed in both Debian/Ubuntu
<pitti> (I get tons of Debian bug reports as well)
<pitti> tkamppeter: and then we can upload an Ubuntu-specific cups with the -origpagesizes option
<pitti> tkamppeter: and sync back once Debian takes it
<tkamppeter> pitti: Debian did not touch my bug report yet (I hope the maintainer comes around with it before our FF).
<tkamppeter> What I have done now is to change the patch to make ./configure autodetect the presence of -origpagesizes and to build with it only if it is present.
<pitti> tkamppeter: so if you could apply the bulk of the patch to bzr, and then just do an -ubuntu1 upload with the additional -origpagesizes patch, that would be best
<pitti> tkamppeter: oh, great
<pitti> that's even better
<tkamppeter> pitti: So this means I put this bulk into the BZR and do an Ubuntu upload with a versioned Poppler build AND binary dependency in debian/contro;
<pitti> tkamppeter: no, you can commit everything to bzr then; you don't need a versioned poppler dependency at all then
<pitti> tkamppeter: (pdftops --help 2>&1| grep -q -- -origpagesizes ?)
<pitti> tkamppeter: or how do you detect this?
<tkamppeter> Yes, I check whether the help message of pdftops contains -origpagesizes.
<pitti> cool
<tkamppeter> But I do it at build time, so if the build server already switched to the new pdftops but the user not yet, the filter will fail.
<pitti> tkamppeter: I have an idea how to fix this; please commit your's to bzr, I'll do the substvars magic
<asac> anyone uses bfilter?
<tkamppeter> pitti, OK.
<Keybuk> WTF
<Keybuk> my phone just declared that "a BaseBand Core Dump is in Progress"
<liw> Keybuk, thanks
<liw> I've been tempted by an evil phone today again, now I'm all better
<liw> (and now I can go back to drooling for a freerunner)
<ion_> My phone has been automatically changing its timezone to UTC+1 recently.
<persia> As "phones" become "computers", we can only expect the quality of service to change to match the functionality.  Long live the ATT Model 500!
<slangasek> ttx: thanks, added to https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview (which, btw, you're free to edit directly ;)
<ttx> slangasek: will do, next time :)
<asac> doko: classpath build deps not installable? http://paste.ubuntu.com/192655/
<doko> dpkg: unrecoverable fatal error, aborting:
<doko>  fork failed: Cannot allocate memory
<doko> E: Sub-process /usr/bin/dpkg returned an error code (2)
<doko> what does this have to do with classpath?
<ion_> Do you have an ulimit that might have something to do with that?
<asac> doko: err. well, the problem is that it cannot install the build-deps
<asac> let me retry
<doko> asac: classpath really should be updated to the 0.98 release
<asac> doko: but you spotted it  ;)
<ogra> must be the new java implementation of dpkg :P
<asac> doko: well. i fix the libxul-dev depend now
<asac> to be xulrunner-dev
<doko> asac: not an oem task ;-p
<asac> thats why i am doing it ;)
<asac> so gcj conflicts now gcjdoc.
<asac> what a mess
<asac> err gcj-jdk conflicts gcjdoc
<asac> lets see if moving build depend to that helps ;)
<Aquina> hy
<Aquina> aa-logprof and aa-genprof ask for usernames and passwords after creation or before reading logs. Unfortunately the server cannot be contacted.
<asac> superm1: wanna upload new bluez?
<asac> (after alpha2)
<superm1> asac, i'm actually thinking i'm gonna sync to debian
<mterry> slangasek: BTW, I've seen several packages in Debian that use dep5 already while I've been merging.  Might be larger use that you think
<superm1> i've been reviewing all the delta between us
<mterry> slangasek: (I remember you suggesting nobody uses it yet)
<superm1> but sure, i'll either sync or upload a new version post alpha2
<asac> superm1: ok. great. do you think pulse is up to date enough? i would like to call for testing after we updated all the pieces for testing (with the gnome-bluetooth thing)
<superm1> asac, i'm not sure the status of that pulse bluetooth plugin, dtchen, can you comment?
<superm1> but yeah, a call for testing would be very good
<asac> superm1: following the bluetooth-stack spec
<asac> superm1: right. i just think we should have all the latest pieces because things seems to be still moving - especially on pulse freont
<superm1> <nods>
<asac> ok so lets check after alpha2 is out
<superm1> ok sounds good to me
<slangasek> mterry: no, I'm sure there are some people using it; I just think it's premature because the spec is still subject to *significant* changes before it reaches anything approaching consensus in Debian
<mterry> slangasek: OK, well just be assured that there's dep5 love out there.  Though some were using very pre-dep5 versions and the like
<slangasek> "pre-dep5 versions" - yeah, I don't count those
<asac> superm1: what bluetooth hardware do you have?
<persia> The trick to using DEP5 (or a predecessor) is to be sure to specify the *precise revision* of the page that one complies with.  Most users should expect to be non-compliant for their next upload.
<slangasek> no one's going to write a parser to handle 300 revisions of a wiki page, chosen at random by the uploaders :P
<mterry> slangasek: Meh.  pre-dep5 versions is just an early dep5
<superm1> asac, i've  got a variety of dell bluetooth chips, a keyboard mouse stereo headset and mobile phone
<persia> slangasek, That something happens to be compliant with a given URL doesn't mean it's compliant with the *goals* of the effort :)
<slangasek> persia: that sounds like you may be violently agreeing with me
<persia> slangasek, I think the only point of disagreement is that I don't mind if someone happens to use something in that format, and will happily review it against the revision they specify, rather than asking "Why?".
<slangasek> oh, I don't mind if someone happens to use something in that format
<persia> Well then, yes, I am violently agreeing :)
<slangasek> but I don't think it's worth doing validation, visual or otherwise, against arbitrary wiki revisions
<ogra> .oO( all that violence here today )
<persia> Oh.  I do it mostly to make sure that the person preparing the file is consistent with their claims, rather than just cargo-culting, but perhaps I tend to review packages in a different stage.
<asac> doko: http://paste.ubuntu.com/192694/ ... does this still make sense in karmic? or rather vm commands?
<persia> (and I don't want to reject just because the spec changed *again* since the last time they edited debian/copyright)
<asac> (for 0.98)
<slangasek> persia: right - not validating against arbitrary wiki revisions --> not validating at all :)
<doko> asac: afaic classpath can be used with cacao or jamvm
<persia> slangasek, Not even validating to ensure that it complies with current policy?
<asac> ok thanks
<slangasek> persia: policy compliance, sure
<slangasek> that's separate
<persia> Ah.  I understand.  Yes, I think that's the right choice from the archive-admin viewpoint.
<slangasek> doko: I was wondering what to do with pycairo, btw; the Debian package has switched to python-support, is there an equivalent to DH_PYCENTRAL=include-links for python-support that we need to worry about?
<nxvl> NCommander: can you please take a look at ug #385605
<nxvl> Bug #385605
<ubottu> Launchpad bug 385605 in hardy-backports "Please update pidgin 2.5.2" [Undecided,New] https://launchpad.net/bugs/385605
<directhex> doko is about? woo!
<doko> slangasek: no, python-support doesn't have this
<slangasek> doko: is python-support's behavior consistent with what we're trying to achieve with include-links?
<slangasek> doko: btw, did you file those bugs against python-support?  I don't have the bug numbers
<mvo> slangasek: no include-links in pysupport
<mvo> slangasek: but it seems like the links are now kept during upgrades
<doko> slangasek: not yet, will try later.
<mvo> (i.e. python-foo keeps working after --unpack but before --configure)
<slangasek> doko: ok
<slangasek> mvo: alrighty, then I can turn that into a sync
<slangasek> mvo: thanks
<asac> doko: sorry, but now gjdoc --version gives nullpointer exception :(  http://paste.ubuntu.com/192709/ ... do you know which .properties files its looking for there?
<doko> asac: no. gjdoc should work (used in the gcj-4.4 build to build the libgcj docs)
<asac> doko: yeah. but i get null pointer like above on --version
<asac> classpath 0.98 seems to check version in configure ... and it fails because of this
<slangasek> doko: should we transition away python2.4 support in python-stdlib-extensions, btw?  The structuring of that package makes it difficult to tell if the reverse-deps need python 2.4 support
<yuriy> calc: ping
<\sh> hmm...anyone with more initramfs knowledge then me, could explain what tool inside the initramfs would like to create e.g. /var/run/.ramfs ?
<\sh> during bootup that is
<doko> slangasek: yes, that's one of the things I want to do next week, together with 2.5
<slangasek> oh, then I'll leave it for you :)
<doko> does somebody know if today's live images are installable?
<ogra> tomorrows should be :)
<doko> hmm, no lpia images at all
<pitti> doko: yesterday's was fine, anyway; haven't tried today's yet
<ogra> and its unlikely you'll see any lpia ones
<persia> Wasn't the intent to not have lpia images, intentionally?
<ogra> the intent was intentionally, yes :)
 * persia scores redundancy points, and seeks a acetylcholine refresh
<ogra> *g*
<calc> yuriy: hi
<yuriy> calc: got my email from a week ago?
<calc> yuriy: let me see, i had a huge amount of email to deal with so it might have been overlooked
<calc> yuriy: ah ok, i'll look into what should be done, and let you know
<calc> yuriy: we have a human project setup i might be able to expand it to include your icons as well
<calc> yuriy: taking to privmsg
<asac> robbiew: who will own foundations-karmic-eclipse-update ?
<sabdfl> rickspencer3-afk, jono: dx call?
<rickspencer3-afk> heh
<rickspencer3-afk> I just dropped off a few minutes ago
 * rickspencer3-afk calling
<sabdfl> dbarth is moving house, but i'd like to hear from jono re couchdb and rickspencer3-afk re firefox
<calc> yuriy: did you see my messages?
<jono> sabdfl, oh, dialling in
<ogra> Keybuk, oh, have you seen http://mjg59.livejournal.com/111453.html ? "... The Pre uses upstart as its init application. In contrast to mainstream Linux distributions that still mostly use upstart in sysvinit emulation mode, the Pre appears to be almost entirely based on native upstart events..."
 * Keybuk knows ;)
<ogra> way cool
<slangasek> Keybuk: making a little scratch on the side doing upstart consulting, hmm? :)
<Keybuk> I've known for a while in a don't-tell-anyone-but kind of way
<Keybuk> slangasek: hah, I wish
<Keybuk> then I'd be the one with the 73" HDTV
 * slangasek grins
<robbiew> lol
<ogra> haha
<Keybuk> Maemo uses it natively too
<ogra> yeah
<ogra> but only to fire off hildon
<robbiew> asac: don't think we will do the eclipse update
<asac> robbiew: well. we have to do something, because it blocks bug 352968
<ubottu> Launchpad bug 352968 in pcmanx-gtk2 "remove xulrunner 1.8 and all left over rdepend binaries from karmic archive." [High,In progress] https://launchpad.net/bugs/352968
<asac> robbiew: we cant keep xul 1.8 in the archive for another round. its just too far eol with too many security issues
<robbiew> doko: ^^^
<robbiew> doko: any suggestions?
<asac> maybe we can rebuild eclipse without the feature that requires gecko?
<seb128> if we have an outdated and buggy version and nobody works on it just drop it until somebody does the job to update it?
<robbiew> seb128: hmm...you make a good point
<asac> seb128: well, that was my idea for those rdepends left on xul 1.8, but archive admins didnt like the idea. see the bug
<doko> robbiew: need to email some people about eclipse. did talk to somebody from the eclipse foundation last week
<seb128> asac: try to convince slangasek ;-)
<asac> my idea was: remove xul 1.8; respin all rdepends and if nobody steps up fixing the build failures, remove them from archive
<robbiew> doko: okay
<asac> seb128: he commented twice on the bug ;)
<seb128> I agree we should make some efforts to try to fix those
<seb128> but in the eclipse case if it's outdated for cycles and nobody want to work on it
<seb128> it doesn't benefit our user anyway
<seb128> users
<asac> seb128: i am doing that and i planned to do that, i just think it would be easier to get community contributions when we make those build depends fail
<seb128> and it can be uploaded again when somebody wants to do the update
<seb128> talk to slangasek on IRC ;-)
<robbiew> I recall someone sending an email requesting we update eclipse...
 * robbiew looks
<slangasek> asac, seb128: I was just backing up StevenK
<seb128> might be either that to convince him there than by bug tracker
<slangasek> pointing out that nothing had changed
<slangasek> I don't have a strong feeling about it :)
<asac> slangasek: sure. i might have not communicated the idea appropriately
<seb128> let's talk to StevenK to see how strongly he believes about that not being right
<seb128> I doubt anybody will object to do that early in the cycle
<robbiew> asac: seb128: FWIW, we did receive an email some months ago from a journalist mentioning that he was hearing from some people that only having Eclipse 3.2 in Ubuntu is "driving them nuts"
<robbiew> but apparently it's not nuts enough to get them to contribute :)
<asac> robbiew: yeah. wonder if its better to not have it than to have such an outdated version.
<robbiew> right
<ogra> it should live in a PPA
<robbiew> that might be the way to go
<ogra> and find a maintainer team
<robbiew> we should probably wait on doko's email
 * doko has some email and other backlogs ... :-/
<asac> doko: so seems the old gjdoc thing had a version.properties in a jar. the new thing doesnt have that so --version fails
<asac> doko: maybe its because i have messed up alternatives for some java stuff? how can i reset all alternatives to something reasonable?
<asac> (strace showed that it picked up rt.jar from the sun jdk)
<cody-somerville> doh
<cody-somerville> my wireless isn't working in karmic anymore
<asac> cody-somerville: chipset?
<cody-somerville> asac, BCM4322 802.11a/b/g/n
<superm1> cody-somerville, if it was by 'wl', then see bug 381682, bug 381683, bug 381678, bug 381687 bug 381686 and bug 381684
<ubottu> Launchpad bug 381682 in bcmwl "Need to produce bcmwl-modaliases package" [Medium,Triaged] https://launchpad.net/bugs/381682
<ubottu> Launchpad bug 381683 in jockey "Jockey needs to depend upon broadcom modaliases package" [Medium,Triaged] https://launchpad.net/bugs/381683
<ubottu> Launchpad bug 381678 in jockey "Jockey needs to install bcmwl-kernel-source when enabling broadcom" [High,Fix committed] https://launchpad.net/bugs/381678
<ubottu> Launchpad bug 381687 in casper "Jockey should offer broadcom wireless if it's available on the live cd" [Undecided,Fix released] https://launchpad.net/bugs/381687
<ubottu> Launchpad bug 381686 in ubuntu-meta "bcmwl-kernel-source should be installable from the CD" [Undecided,Fix released] https://launchpad.net/bugs/381686
<superm1> some of them are taken care of, but the rest need to happen for jockey to be able to offer support now
<doko> asac: did you set a java home?
<cody-somerville> I'm pretty sure I
<superm1> in the interim, you should be able to manually install bcmwl-kernel-source and then blacklist ssb and b43 for now
<cody-somerville> Okay
<cody-somerville> Thanks :)
<superm1> np
<asac> doko: my env doesnt have a JAVA_HOME
<asac> doko: are those bits in gcc-defaults assembled manually?
<doko> no
<asac> doko: i cannot find anything in the sources that looks like it produces this gjdoc thing
<cody-somerville> superm1, w00t
<cody-somerville> superm1, worked like a charm
<superm1> cody-somerville, great.  if you want to give a go at solving bug 381682 since rtg hasn't had a chance yet, can get it more OOTB experience for jockey to offer and what not...
<ubottu> Launchpad bug 381682 in bcmwl "Need to produce bcmwl-modaliases package" [Medium,Triaged] https://launchpad.net/bugs/381682
<asac> doko: so gcc-defaults it build depends on gcj-jdk ... but that package it produced by gcc-defaults itself. sounds like its a bootstrapping thing (manually?)
<doko> asac: where is gjdoc --version used?
<asac> doko: by classpath configure script
<asac> (0.98)
<asac> doko: i can patch that check out and assume all is good, but that doesnt sound right. gcj-jdk should ship the version.properties imo
<asac> doko: previously  (in gjdoc) the version.properties was in /usr/share/java/gnu-classpath-tools-gjdoc.jar
<asac> doko: build failure is: http://launchpadlibrarian.net/27733377/buildlog_ubuntu-karmic-i386.classpath_2%3A0.98-0ubuntu1~asac1_FAILEDTOBUILD.txt.gz
<doko> asac: please attach a patch for gcj-4.4. gjdoc shouldn't use this file, but just using the method like other classpath tools
<asac> doko: whats the source package?
<doko> asac: gcj-4.4
<asac> doko: there is nothing in there ;)
<doko> run debian/rules patch, then you'll find the tools stuff in src/libjava/classpath/tools
<asac> (outside of debian)
<doko> gjdoc was recently added, so I assume the version handling stuff is still the old one
<asac> doko: http://paste.ubuntu.com/192773/
<doko> asac: dpkg-checkbuildeps?
<asac> aye
<asac> doko: i dont think i understand whats the _new_ way of doing it would be.
<asac> the current getGjdocVersion does what i expect: open version.properties and get the version properties from there
<doko> asac: look at how e.g. gjavah gets the version information
<asac> k
<stefanlsd> pitti: During UDS there was a discussion on https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-overview re the syncing of Debian security of to Ubuntu. It was mentioned you had a tool or an idea about this?
<pitti> stefanlsd: first time I hear about it
<stefanlsd> pitti: oh ok. The notes say - automated Debian-security fetch/try/build system (mom, ubuntuwire (rcbugs), pitti may have some)   -  Not sure who volunteered you :)
<jdstrand> pitti: we talked about it
<kees> stefanlsd: that was my idea, but there's no code.  :(
<pitti> ah, I remember that being mentioned over lunch
<jdstrand> it was kees' idea, but he wasn't there that day. we talked about using MoM or rcbugs and I thought you mentioned some scripts that could conceivably help
<pitti> anyway, can we talk tomorrow? I need to leave for Taekwondo now
<stefanlsd> yeah. np.
<pitti> jdstrand: indeed, MoM would be ideal for this
<pitti> jdstrand: or, alternatively, adapting http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
<pitti> anyway, bye everyone (sorry, gotta run)
<jdstrand> pitti: I think that was the script you mentioned
<jdstrand> bye pitti, have fun! :)
<asac> doko: so this part? http://paste.ubuntu.com/192792/
<asac> or are you asking to move the whole gjdoc thing to the new ClasspathParser?
<doko> asac: yes, gjdoc maybe should use that as the default
 * calc wishes old bugs were archived or something to that effect where people can't comment on them anymore
<\sh> I wonder which piece of software sets $RAMRUN for /lib/init/mount-functions.sh  or /etc/init.d/mountkernfs.sh
<\sh> aha...default rcS
<puff> hi, I'm not sure this is the right place, but before I submit this brainstorm suggestion, I wanted to ask aroudn abou tit.
<puff> I want to suggest that when a package is removed or renamed, that attempts to install (or even search for) the old package should get some sort of useful response, along the lines of "that package has been renamed to foo" or even "that package has been removed, see bug http://etcc"
<robbiew> superm1: ping
<superm1> robbiew, pong
<mterry> evand1: Did you want any help with karmic installer stuff?  Like the ubiquity slideshow or something?
<directhex> has there been a definitive answer to the question "was the audio from UDS recorded?"
<slangasek> cody-somerville: do you know why xubuntu livefs builds are still failing due to libgoffice-gtk-0-6 being gone?  I'm not finding any references to that package
<slangasek> cody-somerville: n/m, just found it in livecd-rootfs
<evand1> mterry: slideshow is going to be mostly marketing, but help with the oem-config stuff, and other installer tasks that crop up (if that's what you're more interested in), would be fantastic.
<mterry> evand1: Sure.  I don't want to cause more work in figuring out what to give me, but if you point me at a buglist, maybe I can claim some?  Or however you'd like to do it
<evand1> mterry: sure, I'll follow up to Robbie's email tomorrow with more concrete ideas.
<mterry> evand1: Cool
<ZachD> hello
<ZachD> im here to give u guys suggestions on ubuntu and improvements!
<ZachD> w00t
<cody-somerville> oh joy
<ZachD> lol your welcome
<directhex> doko, seems ironpython 2 works fine in sid's mono, so that blocker on updating is gone
<doko> directhex: yes, it is supposed to work with 2.6
<directhex> doko, rudimentary testing seems fine on 2.4 - testing the ipy 2.0.1 stable release, not the ipy 2.6 beta
<ZachD> _._
<ZachD> -.-
<ZachD> whooops
<doko> directhex: I'd rather go on with 2.6
<directhex> doko, mono 2.6 or ipy 2.6?
<sladen> Keybuk: ha.  So the first people using a full native upstart system are ... Palm
<Keybuk> sladen: not true, others are doing so before them
<Keybuk> from this we can discern two things
<Keybuk> assumedly they're using 0.3 natively (based on /etc/event.d)
<Keybuk> so the first thing is that they deserve a medal for getting any kind of useful native boot to that
<Keybuk> and the second thing
<Keybuk> I deserve a complimentary Palm Pre
<Keybuk> ,g>
<sladen> Keybuk: planning on moving to CDMA land to use it? ;-)
<Keybuk> sladen: good point
<puff> Anybody here know the guts of apt, dkg, etc?
<puff> er, dpkg.
<puff> I'm typing up a suggestion for brainstorm.ubuntu.org and I'd like to bounce it off somebody.
<sladen> puff: you could try asking anyway.  There are people here who do know those parts of the stack /extremely/ well.  They might, or might not see it, so no promises
<Nafallo> either that or it might not be as much of the guts that you fear :-)
<puff> Two things, really.
<puff> The real suggestion  is that when packages are removed or renamed, the package management system should clue you in, rather htan you being mystified, trying to remember if you spelled it right, googling like crazy and eventually finding the bug report where they discuss why kdiff3 was removed because we upgraded to kde4 and kdiff3 isn't kde4 compatible yet and you can compile it by hand, etc.
<puff> Instead, when you enter "sudo apt-get install kdiff3" it should simply say "kdiff3 has been removed from the repositories, see ubuntu bug #11343141, http://etc."
<ubottu> Error: Ubuntu bug 11343141 could not be found
<puff> The second would be adding annotations to the installed packages;  apt or whatever would prompt the user for a reason, so you know who installed it and why, and whether it was installed as a result of a dependency or deliberately.
<cjwatson> puff: it seems like the sort of thing that could fit better higher up the stack, perhaps in the "appcenter" idea that's being kicked around at the moment
<cjwatson> (but I'm not really here)
<puff> cjwatson: The first or the second?
<Keybuk> both
<puff> The second suggestion would particularly aid in situations where you have multiple folks managing multiple boxes, although heck, I've had instances where I was trying to remember to myself why I installed something.
<cjwatson> the first; I'm not sure about the second, we do already have a record of whether something was installed as a result of a dependency or deliberately
<cjwatson> although no more than that single bit of information
<cjwatson> (see apt-mark(8) etc.)
<puff> The first seems like it should be more at the repository level, since multiple tools use that.
<cjwatson> the reason it belongs higher up is that it's the sort of thing that we might want to add richer information to after the fact
<cjwatson> and it would be better for it not to be in the repository since that tends to be harder to change
<puff> I guess I can see the reasoning there, but I think it's an 80/20 thing.  80% of the value is in simply knowing that the repository changed in a not-backward-compatible way.  Once you figure that out, it's much easier to hunt down *why* it changed via bug tracking, ubuntu forums, etc.
<cjwatson> well, you know *that* due to Provides/Replaces/etc. if people are setting dependency relationships correctly
<puff> But until you know that you're looking for something that isn't there anymore, it's kind of a crazy-making situation.
<cjwatson> but the fact is that people don't :)
<puff> It's bitten me at least twice, which is why I'm making the suggestion.
<cjwatson> so it's probably better to have it separate, purely for practical maintenance reasons
<cjwatson> right, and I'm applying ten years of experience with this kind of system to direct the suggestion to where it seems most likely to work ;-)
<cjwatson> I agree that it would be useful
<puff> Ah, I see... put the data somewhere that is less gate-keepered, so more folks canhelp keepit up to date.
<cjwatson> but I don't honestly think it's likely to work well in the package metadata itself, even though in some theoretical sense that is the *correct* place
<cjwatson> right, exactly
<puff> I guess the simplest thing then would be to extend aptitude so it can query some sort of aptwiki-ish thing.
<puff> Hm, or maybe just build an ubuntu aptwiki and a simple little aptitude-flavored CLI to it.
<puff> With everything keyed by package names, etc.
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/software-library is the design work happening on this at the moment
<puff> Cool.  I will read and cogitate.
<cjwatson> I don't know that your specific suggestion has been taken into account there
<cjwatson> but it probably ought to be!
<cjwatson> in some sense it comes under error-tolerant search but I think it's probably not quite the same
<puff> I like adding GUI tools but I prefer it when they complement, not supersede, the underlying tools.
<cjwatson> oh, I agree, I don't believe appcenter is intended to replace apt
<cjwatson> mpt is the guy coordinating this, although he's not around right now
<puff> I'll read up and try to catch up with him.
<robbiew> puff: http://wiki.ubuntu.com/AppCenter
<puff> Hm, this might dovetail with another idea I've had, which is to factor in platform-specific feedback.
<cjwatson> it seems useful for that kind of thing to have a lower-level interface, of course; much of AppCenter is UI design and there are lots of places where the underlying tools are going to have to be extended a bit, or new tools written
<cjwatson> e.g. the support lifetime for a package is going to have to be encoded somewhere
<cjwatson> there's been talk of using debtags, which is potentially fairly flexible
<cjwatson> still has the problem of the index files being frozen at release but I think debtags can use alternative data sources too
<cjwatson> I suspect annotations belong lower down
<cjwatson> since that doesn't involve any kind of interaction with us, it's purely local to the system
<puff> Yeah, that I was thinking belonged in the dpkg records, somewhere.
<puff> Or in a database "alongside" the installed packages stuff.
<cjwatson> probably apt, I have this pesky desire to keep dpkg simple
<cjwatson> and apt already has the auto/not-auto stuff anyway
<cjwatson> (and apt would have to tell dpkg about it anyway so ...)
<ebroder> Anybody with main upload bits willing to look at my fix for bug #362691? It's been sitting there for 3 weeks now, and includes a change to the version in jaunty-proposed
<ubottu> Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Medium,Confirmed] https://launchpad.net/bugs/362691
<cjwatson> ebroder: probably better to ask outside a soft freeze
<ebroder> Oh, right. Forgot about that
<puff> cjwatson: Well, obviously I need to learn more about this whole topic, apt, dpkg, repos, what info's kept where.
<puff> I've been bit several times by issues like this and things like problems with suspend/resume cropping up after dist-upgrading.  It seems really silly for something as cool as ubuntu to have problems like this (not silly for it to have problems, silly for people to be caught unaware by them)
<puff> Especially since it's mainly a matter of communicating to the community, which ubuntu is pretty good at.
<puff> Okay, thanks, I will go off and do my homework now.  Ciao.
<cjwatson> puff: oh, don't take me as saying that there aren't bits of existing dependency relations that could be used - as I say I think there's some value in interpreting Conflicts/Replaces, Provides, etc.
<sladen> cjwatson: is the actual example given (of removal of kdiff3) covered.  It was presumbly removed because there wasn't a replacement (although it should have said this in the list)
<cjwatson> sladen: I don't know that that particular example is covered by package relationship fields, and I think it's pretty hard to cover there, which is one reason I explicitly wasn't suggesting shoehorning everything into package relationship fields
<puff> kdiff3 was apparently removed for a while (and then re-added) due to some ubuntu general switchover to kde4, or something:  https://bugs.launchpad.net/ubuntu/+source/kdiff3/+bug/260326
<ubottu> Launchpad bug 260326 in kdiff3 "I can't install kdiff3 on Intrepid (Broken dependecy)" [Undecided,Fix released]
<puff> Previously I ran into something similar where some podcast downloading tool, I think ipodder, mysteriously disappeared (mainly because apple threatened a lawsuit over trademark infringement).
<puff> And I've run into problems where I upgraded to a new ubuntu release and fundamental stuff like suspend/resume broke, and then when I went researching it, only *then* did I find out that it was a major known issue with that architecture .
<cjwatson> ipodder was replaced by castpodder, but the project kind of petered out AFAICT (at least as far as getting packages was concerned) and I'm not sure if the replacement castpodder ever made it into the archive
<lizthegrey> what's the proper procedure for recruiting backport testers for a package and deeming the backport sufficiently tested?  I'm trying to get sudo 1.7.0-1ubuntu1 from karmic backported to dapper and hardy - https://bugs.launchpad.net/hardy-backports/+bug/384100
<ubottu> Launchpad bug 384100 in hardy-backports "Please backport sudo 1.7.0-1ubuntu1" [Undecided,Confirmed]
<lifeless> kees: how does one debug/fix apparmor profiles: cups is breaking when apparmor is on, on my laptop
<mathiaz> lifeless: https://wiki.ubuntu.com/DebuggingApparmor
<lifeless> thanks
#ubuntu-devel 2009-06-11
<slangasek> superm1: do you recall how it is that mythbuntu liveCD builds get their task lists?
<slangasek> I don't seem to be able to persuade the buildds to put grub-pc in the livefs
<mathiaz> cjwatson: are you subscribed to partman-auto-raid bugs?
<slangasek> https://bugs.launchpad.net/ubuntu/+source/partman-auto-raid/+bug/385754 -> "also notified" -- nope
<ubottu> Launchpad bug 385754 in partman-auto-raid "Can't have a partition outside the disk! error on a preseeded i386 install" [Undecided,New]
<mathiaz> slangasek: right - so I don't think cjwatson is notified
<slangasek> appears not
<superm1> slangasek, they were via meta packages i thought
<superm1> is grub-pc not working in just mythbuntu disks, or all?
<superm1> we're the only one that does meta packages though, tasks pulled in too much because of the order of dependency resolution
<slangasek> superm1: it was missing from all the disks; now I've got it included everywhere but mythbuntu
<superm1> slangasek, interesting...
<superm1> it should come as a recommend to ubiquity
<slangasek> I guess it's possible that mythbuntu is only getting grub at all because it's a Recommends: of linux-image, and that's being resolved first and satisfies ubiquity's recommends
<superm1> why is grub still a recommends of the kernel anyway though?
<superm1> is that just some legacy thing?
<sharms> can someone point me to documentation on what is different about lpia vs. i386?  Ie if I want to compile a package for it, its just extra gcc flags right?
<superm1> UNR looks to be built the same way as mythbuntu - without a task but instead a meta.  is it having the same problems?
<slangasek> superm1: no, UNR is fine
<slangasek> superm1: the bootloader is a recommends of a kernel because that's the correct relationship; the wrong bootloader is recommended because we didn't even notice until today that grub-pc wasn't on the CD at all... :)
<slangasek> (it was working for people, but only with network available at install time)
<superm1> hmm i see
<superm1> considering the kernel is installed before ubiquity for the cases, i'm perplexed how any of the other builds dtrt then
<superm1> oh - it looks like for some reason in the standard ubuntu build grub actually gets removed in favor of grub-pc though http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/20090610.1/livecd-20090610.1-i386.out
<slangasek> superm1: because grub-pc is explicitly part of the task
<slangasek> hrmm, removed?  so grub-pc does conflict with grub now?
<superm1> it always has
<slangasek> hmm, ok
<superm1> which task is it explicitly part of for standard? I looked through ubuntu.karmic's seeds, and didn't see it mentioned in anything but dvd
<slangasek> pitti: I'm sure you'll see this in your highly efficient email processing anyway :), but I've followed up to bug #201114 - I basically can't reproduce the problem at this point
<ubottu> Launchpad bug 201114 in openoffice.org-l10n "-help packages need alternate language-support- dependencies" [High,Fix released] https://launchpad.net/bugs/201114
<slangasek> superm1: platform.karmic
<slangasek> superm1: the boot seed
<superm1> ah. i wonder if by using meta's for mythbuntu we don't properly inherit things from the boot seed then even though we have an include platform.karmic
<slangasek> I'm not sure, but I definitely don't see any mythbuntu metapackages that depend on grub, which was already part of said seed
<slangasek> so there is a disconnect somewhere
<superm1> slangasek, i'm rather perplexed on where the disconnect is myself, but i suspect that it's probably something related to us not using tasks.  for now, would adding it to ship-live do the trick?
<superm1> and as a long term plan, try to get things switched to using tasks so weird disconnects like this don't happen
<slangasek> if you want to add it to ship-live, that would do it, yes
<TheMuso> asac: Ok, bluetooth audio with pulse for the most part works. I have a headset that can do stereo playback, or headset/microphone mode, i.e the 2 different audio profiles. With the gnome-volume-control-pulse applet, I can't switch between the profiles yet, but I can move a stream to the headset.
<TheMuso> asac: I still have to use pavucontrol to adjust the profile for the bluetooth headset, but its only a matter of fixing up the gnome volume pulse applet UI to deal with profiles, which afaik is coming anyway.
<TheMuso> asac: SO there is in fact not much to do in this area.
<superm1> slangasek, okay so i've added it to ship-live, so i'd expect Next build to be OKish
<slangasek> superm1: that'll be mythbuntu-meta 0.39?
<superm1> slangasek, i dont think i need to do a new meta to adjust ship-live
<superm1> isn't that part pulled in by ubuntu-cdimage?
<slangasek> superm1: nope, it's pulled in via livecd-rootfs, which is what pulls in the meta packages :)
<superm1> well are we talking about the same thing though? i'm not saying the live seed which is used to build mythbuntu-live meta package, i'm saying the ship-live cd that builds the on-cd-repo
<slangasek> oh
<slangasek> you're putting it on the CD but not in the livefs, right
<superm1> right at least for now, until i can sort out the tasks problem
<slangasek> that can work
<superm1> we've got the space for it still at least
<slangasek> in that case, building now
<superm1> cool thx
<slangasek> superm1: ah, nope, doesn't work because germinate sees grub-pc already in the live seed, so thinks it doesn't need to duplicate it in ship-live :)
<slangasek> superm1: so it'd need a meta respin here
<superm1> <shrug> okay, i'll fire up the machine with the meta source and respin
<GNUix> quick question with this whole paper cut idea and the CDROM eject stuff. In GNU/Linux we mount and unmount volumes .. it isn't really tech speak.. its what we do, wouldn't trying to make it operate more like windows just confuse the crap out of people more.. "I can't eject my CDROM" .. "Well have can you unmount the volume in the command line?" "WTF is mount what.. you sicko!"
<StevenK> If you right click on the CD icon on the desktop there's a Eject item?
<GNUix> StevenK: Thats the proposal.. and to create a resource wasting icon in the notification area like you get on windows..
<StevenK> Proposal? It already works like that.
<GNUix> StevenK: Yes, but you also get "unmount" which is correct, apparently this is confusing people
<superm1> slangasek, okay 0.39 is in and should have it
<persia> GNUix, Well, there exist cases where one wishes to unmount without ejecting.  Should we make this deliberately hard?
<GNUix> persia: Let me clarify.. I think the way things work right now are fine. What I don't want it all the terminology being changed on my desktop because some people are confused by mount/unmount
<TheMuso> Don't forget that if nothing is accessing the CD/DVD drive, you can press the button on the drive and the disk will eject.
<persia> GNUix, You don't have an "eject" option?
<persia> Or perhaps I misunderstand.  Where is this proposal?
<GNUix> persia: nevermind.. I was refering to a blog post that mentioned this idea of 'paper cut' type bugs to fix small stuff supported by the big C .. one of the ideas is to remove the unmount option from removable media because 'umount' is tech speak..
<persia> Oh, just in a blog post.  Probably better to note use cases that break this in a comment in the post.
<GNUix> persia: well its not just a blog post, its 'officially' supported and there are bugs in launchpad for this stuff.
<persia> Commenting in the bugs is the best way to present reasons why something oughtn't be done for those things where there are bugs filed.  I'm unsure what you mean by "officially supported".
<ScottK> 100 paper cuts is a spec for Karmic.
<persia> Are each of the paper cuts being identified in the spec?
<StevenK> I don't believe so
<persia> I'm not sure I understand the point of having a spec in that case, but OK.
<StevenK> I don't think unmount actually meets the definition of a paper cut, either
<persia> Anyway, I still maintain that if there are bugs being filed about changes that would break some use cases, it's a good idea to identify the use cases to be broken in those bugs.
<nixternal> pitti: I have ported apport-qt to apport-kde for better integration into the Kubuntu desktop - I have pushed it to lp:~nixternal/apport/apport-kde
<superm1> nixternal, i think generally a merge request is better than an IRC ping so it's not easily overlooked :)
<nixternal> that is there as well
<superm1> okay, cool
<Vantrax|Work> I have a query about newer kernels being added to the 8.04 repositories
<macvr> hi all... has anyone used the e4defrag?
<superm1> slangasek, looking at http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/mythbuntu/ it seems that the livefs wasn't even attempted since the new ISO was made. is the livefs still on autopilot, or does it need the magic prod that only slangasek can provide :)?
<dholbach> good morning
<nixternal> w00t, tied in apport-qt and easily changeable with apport-kde in all KDE ... Help->Report Bug... menus...hold on to your socks LP, the bug reports will be a coming :)
<nixternal> KDE will be a bit happier that people aren't filing Kubuntu bugs on KDE Bugzilla now :)
<persia> nixternal, So you can now do the "report a problem" menu items?
<nixternal> persia: yes
<persia> Excellent :)
<slangasek> superm1: we're in the "manual builds only" milestone zone, sorry - building one now
<nixternal> all KDE apps will be able to do that now :)
<nixternal> as long as they are utiling the KHelpMenu class
<nixternal> which everything in kde* for us does
<slangasek> superm1: though I'm far from the only person who can trigger the builds; the release team set has more than one member :)
<lizthegrey> what's the procedure for recruiting people to test backports and/or declaring a backport sufficiently tested to go into backports?
<persia> lizthegrey, There's no set procedure.  If the bug doesn't get enough, posting to one's blog, adding a request in the forums, trolling in #ubuntu, microblogging, etc. may work.
<mneptok> persia: don't forget PayPal
<persia> Extra points if you can help extend the team of backport testers to test all the backport candidates.
<StevenK> slangasek: ITYM, -cdimage ?
<persia> mneptok, PayPal is for *after* you have identified the potential recruits.  Payment before presentation of the request is underhanded at best.
<slangasek> StevenK: well, perhaps - I wasn't presuming that -cdimage members who aren't on the release team would feel comfortable respinning on their own :)
<lizthegrey> persia: hah.  okay :)
<StevenK> slangasek: Hehe
<lizthegrey> is it customary to provide binary packages for testers to install or to point them at prevu?  I'm worried about asking too much of people to Just Trust Me (tm)?
<lizthegrey> the package in question is sudo, so...
<persia> I'm not on the backports team, but my memory of the answer to the question in the past is that the intiial backport testers are encouraged to use prevu (or similar tools) for testing.
<lizthegrey> yeah, I built my packages using prevu :)
<persia> I suspect that's more an attempt to limit testing to people who can recover after breaking their system than an actual requirement, but I don't know the actual policy.
<lizthegrey> ah.
<pitti> Good morning
<lizthegrey> ï»¿ï»¿I'll gpg sign the binaries, so since I'm relatively plugged into the WOT people can go after me with pitchforks should things not be on the up and up :)
<StevenK> Morning pitti
<lizthegrey> bug in question is https://bugs.launchpad.net/hardy-backports/+bug/384100 in case one is curious :) - I'm trying to get sudo 1.7.0 from karmic backported to dapper and hardy since being able to #include a sudoers file fragment is a lot easier/more scalable than mangling the sudoers file programatically :)
<ubottu> Launchpad bug 384100 in hardy-backports "Please backport sudo 1.7.0-1ubuntu1" [Undecided,Confirmed]
<pitti> nixternal: oh, nice! will take a look at it
<pitti> hey StevenK
<pitti> slangasek: right, saw your reply; nice to hear
<slangasek> pitti: well - have I reached the right conclusion? :)
<slangasek> maybe there's still a bug but we've misdiagnosed?
<pitti> slangasek: I'll check it in a minute, when I get to that mail
<slangasek> okie
<slytherin> Does anyone have any idea about this error when trying to setup texlive-base - dpkg-trigger: dpkg-trigger must be called from a maintainer script (or with a --by-package option)
<soren> Using dpkg-reconfigure?
<soren> slytherin: ^
<slytherin> soren: the problem is occurring on powerpc buildd. I haven't tried local build yet.
<soren> If so, it's bug 198421
<ubottu> Launchpad bug 198421 in debconf "DPKG_MAINTSCRIPT_PACKAGE not set by dpkg-reconfigure causing dpkg-trigger to fail" [Medium,In progress] https://launchpad.net/bugs/198421
<soren> slytherin: Ah. Then I don't know.
<slytherin> perhaps kees has any idea. He is the latest uploader of texlive-base.
<TheMuso> slytherin: I think that bug was fixed. I retried a build the other day that had something similar, and the build worked, so I'd suggest try to update.
<slytherin> TheMuso: The bug is with latest package as well AFAIK. I will still try rebuild and report back.
<slytherin> TheMuso: build still failing with same error. The package in question is tuxguitar.
<TheMuso> slytherin: hrm ok hang on a sec.
<TheMuso> slytherin: is this on the buildds?
<slytherin> TheMuso: yes, powerpc buildd. I didn't find time to try a local build.
<TheMuso> ok
<TheMuso> slytherin: This is very weird, as its building for me locally. I guess since my local mirror hasn't been updated, there is no new breakage...
<slytherin> TheMuso: I will try building locally time with fully updated karmic chroot and report back.
<TheMuso> ok
<pitti> slangasek: nack, apt-get install language-support-de still pulls in openoffice.org-common openoffice.org-core
 * pitti investigates
<pitti> slangasek: ah, it's -thesaurus
<pitti> slangasek: bug updated
<pitti> evand1: hm, does usb-creator work for you? I just wrote the current karmic desktop amd64, and when booting it just drops me into initramfs, with lots of "cannot find image on /dev/sr0"
<evand1> pitti: yikes, checking now
 * pitti tests in kvm
<pitti> evand1: .iso works in kvm, so I think it's not generally broken
<evand> okay
<pitti> geser: argh, seems that the recent pkg-create-dbgsym whitespace fix broke things: http://launchpadlibrarian.net/27762179/buildlog_ubuntu-karmic-i386.dictd_1.11.1%2Bdfsg-2_FAILEDTOBUILD.txt.gz
<pitti> geser: I'll write test cases for bug 384597 and the new breakage
<ubottu> Launchpad bug 384597 in pkg-create-dbgsym "pkg_create_dbgsym doesn't cope with multi-line Depends, Suggests, etc." [Medium,Fix released] https://launchpad.net/bugs/384597
<cjwatson> slytherin: that's been on my list to look at, but it's completely non-obvious ...
<cjwatson> slytherin: it's unlikely to be texlive-base's fault, and the code in dpkg *looks* ok
<slytherin> cjwatson: right. Unfortunately I didn't find time since we last discussed this issue. I will try to find time sometime this week.
<pitti> tkamppeter: hm, seems I can't find your patch on http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=poppler, which bug was that?
<seb128> pitti: what patch are you looking for? I sponsored some poppler changes a week ago
<seb128> ie bug #335397
<ubottu> Launchpad bug 335397 in poppler "Poppler's pdftops fails to convert a PDF file to PostScript" [Medium,Fix released] https://launchpad.net/bugs/335397
<seb128> bug #382379
<ubottu> Launchpad bug 382379 in cups "pdftops CUPS filter has several problems" [High,Fix committed] https://launchpad.net/bugs/382379
<seb128> pitti: ^
<pitti> seb128: I know, I thought Till already created a Debian bug for it
<seb128> ok ignore me then that was in case the information was useful ;-)
<pitti> but nevermind, it's fixed upstream; it'll land there eventually, and until then I do a small hack in cups
 * pitti hugs seb128, merci
 * seb128 hugs pitti
<Keybuk> cjwatson: you remember I was asking how to declare an extern array in a header file?
<Keybuk> I remember why I didn't think that was correct, now
<Keybuk> tests/com.netsplit.Nih.Test_object.h:23: error: array âmy_interfacesâ assumed to have one element
<Keybuk> looks like it has to be explicitly extern
<cjwatson> Keybuk: explicitly extern is what I said, I think
<Keybuk> yeah it was
<Keybuk> sorry, I was attempting to confirm what you said in a strange way :p
<cjwatson> ah :)
<pitti> lool: any chance to upload current poppler 0.11.0 to Debian? Otherwise I have to jump through some hoops in cups
<pitti> tkamppeter: ^ you bumped libpoppler-dev to >= 0.11 for the new pdf filter
<ogra> pitti, he's travelling this week, i doubt he has much time for package maintenance work
<pitti> oh, ok
<ogra> (or much connection)
<Keybuk> cjwatson: I'd assumed since it was in an extern "C" { ... } block, that'd be enough
<Keybuk> but, of course, that's C++ :p
<tkamppeter> pitti, I did this for the addition of the pdftoopvp filter which I did last week.
<tkamppeter> pitti: ^ the libpoppler-dev >= 0.11 dependency
<pitti> tkamppeter: I know
<pitti> I'll mail you shortly with some details
<tkamppeter> pitti, is lool the Debian maintainer of Poppler?
<pitti> tkamppeter: yes (one of them)
<seb128> debian doesn't track unstable series though
<seb128> ie they don't use 0.11
<seb128> not sure if that makes a different for what you want to do
<pitti> oh, I see
<pitti> tkamppeter: how urgent is it to get the pdftoopvp filter?
<tkamppeter> pitti, I simply got the filter from the upstream developer Koji Otani from OpenPrinting Japan. Japanese printer manufacturers, like Canon for example, want to have this filter.
<pitti> tkamppeter: so if 0.12 doesn't get released soon, we have to do another dynamic check at build time
<pitti> but for now I just disable it, in order to get the fixed cups to debian/ubuntu ASAP
<tkamppeter> Poppler 0.11.0 has API additions developed by Otani to make the pdftoopvp filter possible
<tkamppeter> So 0.11 is a development series, like an odd-numbered kernel?
<seb128> similar to GNOME naming scheme
<tkamppeter> pitti, can we perhaps make this filter Ubuntu-only for the case that 0.12 does not make it into Debian before our FF?
<pitti> tkamppeter: yes, see above
<pitti> but I'd really like to upload -3 right now
<pitti> tkamppeter: you have mail now
<tkamppeter> OK. Thanks.
<tkamppeter> Is lool on vacation?
<seb128> pitti: new poppler stable will be in one month apparently
<seb128> or that's the schedule they work on
<persia> tkamppeter, Earlier backscroll said he was travelling, but didn't specify purpose.
<pitti> cool, that should fit
<seb128> tkamppeter: no, but he's in the US this week I think
<ogra> asac, about bug 385325, will TB beta be in karmic in time ?
<ubottu> Launchpad bug 385325 in thunderbird "[armel] thunderbird-bin crashed with SIGSEGVI" [Medium,Confirmed] https://launchpad.net/bugs/385325
<ogra> s/beta/3/
<asac> ogra: we had this discussion with NCommander in #ubuntu-mozillateam
<asac> ogra: i wouldn't count on it. upstreawm has no strict commitment
<asac> ogra: so i told him how to do a proper debug build and we can check what we can do for tbird 2. but most likely its more than one patch
<pitti> cjwatson: what was the tool again to display X.org resource usage? (for memleaks, etc.)
<ogra> xrestop ?
<Ampelbein> cjwatson: hi. now that gpsd is built on sparc, could you retry the viking build at https://edge.launchpad.net/ubuntu/+source/viking/0.9.8-2/+build/1068859 ? thanks.
<tkamppeter> pitti, Otani has also provided two patches for Poppler 0.10.x to make it supporting pdftoopvp.
<tkamppeter> pitti: One is to make Poppler build. It is simple, around 10 lines. The other is to add color management support. Could be an alternative approach for Debian.
<pitti> tkamppeter: right, let's talk to lool when he's back
<cjwatson> pitti: xrestop was indeed the one I mentioned a while back
<pitti> seb128: ^ might help you to check memleak
<pitti> cjwatson: thanks!
<seb128> ok
<cjwatson> Ampelbein: done
<seb128> brb
<Chipzz> http://git.gnome.org/cgit/evolution-data-server/commit/?id=d17494da8ebaba8673a581f256efc8a1d41e1e40
<Chipzz> *grin*
<ivoks> Chipzz: lol
<james_w> how are you supposed to update debian/applied-patches/ when doing a merge?
<seb128> james_w: patch -p<n> < change?
<james_w> seb128: apply them again?
<seb128> again?
<seb128> the idea is to have the patches in the debian directory for things not using a patch system, ie having changes in the diff.gz
<seb128> it makes easier to know the changesets
<james_w> yeah
<seb128> or rather a copy of the patches applied to the diff.gz
<james_w> but now I've just merged with Debian
<james_w> so the patches there are out of date
<seb128> well update those with the changes you applied
<james_w> yes
<james_w> but how?
<seb128> or clean those if some are not applied in the new version
<seb128> diff -u file.debian file.ubuntu?
<james_w> that assumes they are separated by file though
<seb128> no, that assume you have a logical order
<seb128> you start from debian
<seb128> reapply a changeset
<seb128> diff and put that in a patch
<seb128> copy the dir and reiterate
<seb128> ie
<seb128> source
<seb128> cp -R source source.debian, work in source to apply the first changeset you work on, diff -Nur source.debian source, copy the patch
<seb128> and iterate that way for each successive change?
<james_w> well, I'd rather have 3-way merge, and not have to do all that by hand, so I think I'll just delete them all
<seb128> *shrug*
<seb128> which means next time we have no idea of the logical changesets
<james_w> well, the aim would be that next time there are no changes
<james_w> and I'll make bzr branches anyway
<persia> I think the best strategy here depends on the class of package.  For those packages where we *always* carry a change (e.g. branding, menu cleanup, launchpad integration) it makes sense to logically differentiate the patches, even if this makes merging different, because that way we can easily reapply the stuff that always needs to be applied.
<persia> For those packages where we *can* be in sync with Debian, keeping track of all that is just overhead, because we ought to get the right stuff into Debian anyway.
<ion_> liw: So... :-)
<liw> ion_, still digging, but I'm seeing light at the end of the tunnel already
<ion_> :-)
<ion_> Already got the amulet of Yendor from the bottom?
<asac> james_w: so where can i find your latest daily build tools?
<liw> that would be a reference to the game I played for an hour without realizing it had more than one level
<james_w> asac: bzr-builder on launchpad
 * asac checks that
<asac> thx
<ion_> Heh
<cjwatson> sbeattie: I can't manage to reproduce bug 250400; simply unsetting HOME and running make-ssl-cert in the same way as ssl-cert.postinst runs it doesn't seem to be sufficient. Obviously this is holding me up from uploading a fix. I don't suppose you might have a moment to see if you can reproduce it?
<ubottu> Launchpad bug 250400 in ssl-cert "make-ssl-cert fails if HOME is unset or empty" [High,Fix released] https://launchpad.net/bugs/250400
 * macvr wonders if any dev is working on a gui for sound the equalizer ...
<wip> still many problems with the RT-kernel
<persia> Indeed.  It doesn't even boot properly.  Of course, if I didn't already know that, your report wouldn't be helpful in that format, but you've already left :)
<ogra> heh
<ogra> he does that once a week
<ogra> i wonder if its a script :P
<persia> Hard to say.  I suspect -rt would be more likely to work if there had been more communication earlier.
<ogra> or at all :)
<ogra> beyond a guy joining here once a week, saying a sentence and signing off .... post-release :)
<persia> Oh, that was about jaunty?  I thought it was about karmic.  The jaunty -rt worked the last time I tried it (although that may have been a late alpha, rather than a beta).
<ogra> well, the last times i saw him here he complained about jaunty rt
<ogra> always signing off immediately after that :)
<mterry> slangasek: OK, so I'm going to look into getting rid of acpi-support's ac.d and battery.d unless you cry foul
<persia> Right.  Internet Relay Microblogging.
<ogra> heh
<superm1> slangasek, i'm still frazzled, that meta package now explicitly calls out grub-pc, but the livefs still came out with grub and grub-common
<superm1> slangasek, oh wait, nvm, grub-common is there and grub-pc is, not normal grub. so it's right this time
<robbiew> james_w: ping
<james_w> hey robbiew
<robbiew> james_w: are u still waiting on feedback on the kerneloops stuff?
<james_w> robbiew: yeah, I'm interested if my idea is the right way to go about it
<james_w> well, firstly if indirecting through apport is the right thing to do
<james_w> and then if that's the right way to do it
<robbiew> james_w: FWIW, I think so, but cjwatson is probably a better person to ask :P
<robbiew> technically speaking
<james_w> there's no real rush though
<robbiew> okay
<cjwatson> it's open in my browser, in my queue of stuff to review
<robbiew> james:w: just didn't want you blocked on a response from me
<james_w> thanks
<robbiew> heh...my browser queue got so long, firefox crashed...that is when I had to split the blueprints based on priority :P
<cjwatson> I'm just trying to get my own specs written before reviewing everyone else's, plank in one's own eye etc. :-)
<james_w> heh
<alex-weej> about 3 nights ago Apport did some serious email spammage removing coredumps from bug reports -- anyone know what that was all about?
<alex-weej> actually it was 2 nights ago
<seb128> alex-weej: it was about removding coredumps from duplicates
<seb128> alex-weej: they take space and can contain sensible informations
<alex-weej> ah ok
<alex-weej> (you mean sensitive btw :P)
<directhex> alex-weej, both!
<alex-weej> ;)
<tkamppeter> seb128, about bug 258421
<ubottu> Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,Fix released] https://launchpad.net/bugs/258421
<tkamppeter> seb128, saw your last comment now, thanks.
<kees> whoa.  vte corrupted "N" (upper-case n)
<sbeattie> cjwatson: re bug 250400 I have a vague recollection of being unable to reproduce it as well.
<ubottu> Launchpad bug 250400 in ssl-cert "make-ssl-cert fails if HOME is unset or empty" [High,Fix released] https://launchpad.net/bugs/250400
<sbeattie> but I'll give it another go.
<cjwatson> cking: can you get us anything more on bug 385916? we can't do anything with it as it stands. If you can reproduce it, the files we actually need from the running installer are /var/log/syslog and /var/log/partman
<ubottu> Launchpad bug 385916 in ubiquity "ubiquity install failure, auto-resize, karmic alpha " [Undecided,New] https://launchpad.net/bugs/385916
<cking> cjwatson: I will reproduce it and attach the appropriate logs
<cjwatson> thanks
<cking> it's kind of hard to know what to attach. Maybe next time I tar up all of /var/log..
<cjwatson> in general, for installer bugs we only need /var/log/syslog /var/log/partman and possibly /var/log/installer/debug
<cjwatson> everything else is duplicated or useless
<cjwatson> to a first approximation anyway
<cking> OK. Will note that down.
<cjwatson> shame apport failed, could be the filesystem is a bit busted
<cking> I'm worried it's due to re-sizing an already existing ext4 fs
<cjwatson> cking: you said it was near the end though, wouldn't that be after partitioning?
<cjwatson> or was that not what you meant?
<cking> oh yes. I didn't think that through
<cjwatson> well, depends what you meant by "end" I guess :)
<cjwatson> could be 385995 although I'm surprised at that causing ubiquity to blow up like that rather than display a "help me" dialog
<cjwatson> oh, actually it might
<cking> ..reproducing this is taking sometime.. hopefully done in 10 more mins
<cking> bother.. did not reproduce it that time. Trying again.
<slytherin> cjwatson: tuxguitar builds fine locally. So the texlive-base issue that causes FTBFS for tuxguitar is surely powerpc buildd problem.
<mterry> apw: Can you give me some pointers on how pm-powersave is supposed to be called with our new devicekit-power overlords?  I gather it used to be called by gnome-power-manager?
<apw> mterry, i though pre devicekit that gnome-power-manager sends out dbus requests, which hal picks up and runs the pm-* stuff
<apw> not sure how that is changed by devicekit
<mterry> apw: Correct
<mterry> apw: OK.  Current g-p-m seems to no longer call anything similar.  Trying to trace it down.
<mterry> apw: I'm assuming that pm-utils still has a place in this new scheme?
<apw> as i understand things it is still called to suspend stuff, right now devkit isn't passing in the quirks i believe
<mterry> apw: Yeah, OK.  There are analogous Suspend and Hibernate calls in dk-p that call pm-suspend and pm-hibernate.  Just seems that SetPowerSave is missing.  I'll ask upstream what the intention is
<ion_> The open source driver for my new laptopâs WLAN adapter doesnât support this model, but is still able to upload the firmware to it. The proprietary driver âworksâ, but seems unable to upload the firmware. rc.local: modprobe (free driver), modprobe -r (free driver), modprobe (evil driver), and i can has networking. :-D
 * hyperair claps. now, did we really need to know that?
<sbeattie> cjwatson: commented on bug 250400, I managed to reproduce manually.
<ubottu> Launchpad bug 250400 in ssl-cert "make-ssl-cert fails if HOME is unset or empty" [High,Fix released] https://launchpad.net/bugs/250400
<cking> cjwatson: log files attached to bug report
<mterry> slangasek: ping about power management when you get the chance.  I'm curious if pm-utils is an accepted part of the new world order, or if we want to move all of its power.d scripts to be some part of udev
<slangasek> mterry: yes, pm-utils isn't supposed to go away
<tkamppeter> pitti, can you have a look at bug 385606?
<ubottu> Launchpad bug 385606 in ubuntu-meta "Print test page gives an error message "unsupported format: application/postscript"" [High,Triaged] https://launchpad.net/bugs/385606
<tkamppeter> pitti, seems that ghostscript-cups needs to be added to one of the seeds, so that it gets pulled into updates of both desktop and server.
<mterry> slangasek: OK, cool.  So, do you happen to know much about devicekit-power and its lack of calling pm-powersave?  It's not in the dbus API.  Thinking we'll have to call pm-powersave in acpi-support now
<slangasek> mterry: we definitely shouldn't be calling it in acpi-support, which is slated for execution.  You might want to check with pitti about where it's supposed to wind up
<mterry> slangasek: Well.  OK.  Where are the bits of acpi-support that are 'methods of last resort' when a power-manager isn't running slated to end up?
<slangasek> mterry: when we get to the point that those are the only thing left, we should be able to unseed acpid and acpi-support from the desktop
<slangasek> arguably there should be some console-friendly power manager to replace them, that also hooks in via devicekit
<slangasek> but I don't know that anyone's working on this
<mterry> slangasek: Agree, but I'm not writing it.  :)
<pitti> mterry: hm, sounds worth an upstream bug report, I think
<pitti> mterry: it sounds like something dk-power could handle, but I'm not 100% sure
<mterry> pitti: Yeah.  I was going to ask the mailing list.  There's the fear that it might be intentional and dk-p won't do it.  I need upstream clarification
<pitti> mterry: devkit-devel@ is a great place to ask, too
<pitti> mterry: I'm not a DK guru yet myself, I'm afraid
 * pitti -> off again
<mterry> slangasek: We can drop it from the seed once the user is never left w/o a manager.  I assume that means when we switch to new GDM?
<slangasek> mterry: yeah, I suppose so
<slangasek> (right, GDM, argh)
<tkamppeter> pitti, you are aware that if you make cups depending on ghostscript-cups, you create a circular dependency?
<pitti> tkamppeter: eww, why does ghostscript-cups depend on cups? that sounds backwards
<infinity> pitti: Because it's useless without it, I'd assume?
<pitti> *shrug* /me demotes to Recommends
<tkamppeter> ghostscript-cups provides PPD files, so it updates PPDs of existing queues. For updating PPDs of existing queues cups and cups-client are required.
<infinity> pitti: Not that circular deps in such low priority packages are a huge deal.  dpkg will just randomly unroll the loop.
<pitti> yeah, but still..
<pitti> I still think it's more logical for cups depends: ghostscript-cups and ghostscript-cups recommends: cups
<infinity> pitti: If it actually calls cups bits, it kinda needs to be a dependency, policy-wise.
<tkamppeter> pitti, but what happens than on a distro upgrade (or any update where both cups and ghostscript-cups get updated)? Will the CUPS daemon be running when the postinst script of ghostscript-cups is run?
<infinity> Oh eww, if they need to be configured in a specific order, then you can't have a loop. :/
<pitti> tkamppeter: yes, with the dependencies being this way around
<infinity> pitti: Which way around?
<pitti> g-cups depends: cups
<pitti> and cups recommends: g-cups
<infinity> pitti: Ahh, you wrote it the other way above.
<pitti> cups' postinst doesn't do anything magic wrt. detection, so that should be fine
<pitti> infinity: right, it would seem more logical the other way round
<tkamppeter> pitti, CUPS itself does not need ghostscript-cups, if you have only PostScript printers and/or printers using Foomatic, you do not need ghostscript-cups.
<pitti> but the other drivers also use this order
<pitti> tkamppeter: okay, so recommends makes sense
<pitti> similar to cups-driver-gutenprint
<tkamppeter> So I would then rather add a "Depends: ghostscript-cups" to all CUPS Raster drivers, currently splix, gutenprint, and hplip-cups.
<tkamppeter> The reporter of bug 385606 most probably uses splix, and so the dependency in splix wiull pull ghostscript-cups for him.
<ubottu> Launchpad bug 385606 in ubuntu-meta "Print test page gives an error message "unsupported format: application/postscript"" [High,Triaged] https://launchpad.net/bugs/385606
<tkamppeter> pitti, so put a Recommends: into cups, leave ghostscript-cups alone, and I add a Depends: to the CUPS raster drivers.
<tkamppeter> pitti, for updates the default-installed CUPS Raster drivers will pull ghostscript-cups then ...
<mterry> slangasek: What's the deal with Debian's and Ubuntu's versions of acpi-support?
<ogra> they should die die die ?
<mterry> :)  I mean, they seem different?  Are they downstream from us?
<ogra> no, slangasek reworked most of it in jaunty ...
<ogra> we once were upstream (mjg59 was upstream ... he moved to RH and the package upstream moved to debian ...)
<ogra> iirc
<slangasek> mterry: they're not a very participitory downstream.
<cjwatson> sbeattie: thanks!
<calc> shtylman: good job! just saw your post to ooo-build :)
<shtylman> calc: thanks...yea...I hit a wall and needed someone with a bit more installation experience...once they figure that out I can finish up the last few details
<calc> shtylman: ok :)
<calc> shtylman: i need to get the oxygen icon set integrated soon as well, maybe by the time i have time to do the next upload both will be ready :)
<shtylman> calc: that would be cool
<shtylman> calc: do you have a fixed day for that...I can try to aim to get this work done by then...(other things aside)
<calc> shtylman: no just whenever after alpha 2, preferably before alpha 3
<calc> rickspencer3: hi
<shtylman> k
<rickspencer3> calc: hi
<XCP> hi. fresh install of ubuntu 9.04 here. and update-motd runs every 10 minutes on my computer. how ridiculous is this? is this intended?
<ryanakca> XCP: Just a stab in the dark, but could it be to update the MOTD to include ``X updates available, Y security updates available"?
<XCP> ryanakca: cat /etc/motd does not reveal this kind of information. it does not seem to have any variable part at all.
<persia> That shouldn't have to run every 10 minutes.
<directhex> how about every 11?
<XCP> the reason why I brought this up in the devel channel is because maybe it's something that has been forgotten and could be fixed.
<persia> XCP, /etc/motd is just output.
<geser> isn't update-motd responsible for the updates?
#ubuntu-devel 2009-06-12
<kees> ryanakca: check with kirkland -- it should be trivial to get update-motd to include it.
<cdE|Woozy> according to the manpage of update-motd, this behaviour is intended
<XCP> yes, but you can disable it. the question is, why is Ubuntu running needless services in the background?
<XCP> by default, that is.
<XCP> you could of course argue that someone might need the motd to be updated, but then he can activate update-motd manually. the same way you don't run apache by default on every machine just because *some* are going to host a website.
<persia> Running the service has some value.  Running every 10 minutes by default might be a bit agressive.  I'd suggest filing a (wishlist) bug, and building some discussion about the best frequency.
<XCP> hmm ok.
<persia> XCP, I'd argue that running it at least daily makes sense (and there's plenty of stuff that runs out of cron.daily.)
<persia> For me, hourly is borderline, and 10 minutes is insane.  For others, the values may be different.
<virtuald> why should it be in motd and not bashrc?
<TheMuso> .c
<slangasek> superm1: do we have folks to test the mythbuntu alpha-2 candidates?
* slangasek changed the topic of #ubuntu-devel to: Archive: open | karmic alpha-2 released | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ebroder> Anybody with main upload bits willing to take a look at bug #362691?
<ubottu> Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Medium,Confirmed] https://launchpad.net/bugs/362691
<ebroder> (The actual patch is in comment 37)
<StevenK> Not until alpha 2 releases
<ebroder> "Topic changed to Archive: open | karmic alpha-2 released"
 * StevenK shakes his fist at slangasek 
<StevenK> :-P
<ebroder> Haha
<slangasek> StevenK: it's ok, you can go ahead and pretend I didn't say that if you wish :)
 * StevenK grins
<StevenK> asac: So, can you help me look at a xulrunner induced build failure?
<calc> anyone used dircproxy or bip before?
<StevenK> I'm using bip now
<directhex> bip bip bip bip
<directhex> -directhex- VERSION bip-0.7.4
<calc> ok that settles it, two crazy people on bip, so me too ;-)
<calc> any gotchas in setting it up?
<StevenK> directhex is the crazy one.
<calc> StevenK: heh :)
<holoway> calc: I've used znc for a while
<directhex> calc, only gotcha is the auto-scrollback feature is intensely annoying when applied to /msg, as the behaviour of it varies depending on irc client and internet speed
<calc> ok
<calc> i'll have to see how it goes
 * calc primarily needs a way to have regular irc client plus privmsgs that show up as alerts somehow, probably pidgin
<superm1> slangasek, i'll send some pings out
 * calc hopes he can get pidgin to work without having 500 windows open for all the channels i am on
<calc> directhex: do you know if it works well to always get the channels in the same order in eg irssi?
 * TheMuso uses bip also.
 * Hobbsee shakes fist at karmic xorg.
 * Hobbsee is getting bored of it locking up her machine at random.
<superm1> bored? isn't aggravated a better description?
<lifeless> Hobbsee: runnong edgers?
<Hobbsee> lifeless: nope.  I'm thinking that might be a good idea, as it might be more stable.
<superm1> calc, bip bip bip. if you still need help i can point a reference config
<lifeless> Hobbsee: cworth blogged a couple of days ago
<lifeless> Hobbsee: you need the latest kernel release for many of the bugfixes.
<calc> superm1: i copied it out of usr/share/doc and working on it now
 * calc notes this netbook's broken spacebar is really annoying, only the left side works
<superm1> calc, cool. i got mine from kirkland initially. i think he started convincing a lot of people to use it
<Hobbsee> lifeless: looking for it
<calc> superm1: ah
<lifeless> http://www.google.com/reader/shared/03159273885318971096
<lifeless> Hobbsee: ^
<lifeless> third post
<Hobbsee> lifeless: oh, i was looking on the wrorng planet.  Thanks :)
<lool> pitti, tkamppeter_: Right, I'm in SF still; travelling back tomorrow but will be jetlagged and tired; I can make some tim to push poppler 0.11.x to experimental if noone can do it
 * calc goes back to using his laptop
 * Hobbsee takes the plunge, and reboots
<Hobbsee> if you see an explosion down south, you'll know what it was....
<Hobbsee> hm, no explosion.
<TheMuso> heh
<robert_ancell> TheMuso: lifeless: Do you know who manages ubuntu-dev-tools?  I've found a trivial bug, who has commit access? (I'd like to avoid filing bugs and commit directly)
<Hobbsee> robert_ancell: it's in bzr
<Hobbsee> so i presume you can do a merge (i think the branch is owned by ~ubuntu-dev)
<StevenK> And if you don't, you can push to a branch you own and request a merge using LP
<robert_ancell> Hobbsee: I think I'm not in ubuntu-dev, any idea how to become?
<robert_ancell> StevenK: yeah, I'm trying to avoid that :)
<StevenK> But that's the Proper Way if you can't commit directly?
<Hobbsee> robert_ancell: what StevenK said
<robert_ancell> yeah, I'm just too lazy though :)
<StevenK> Don't make us go over there
<StevenK> :-P
<robert_ancell> But it's a one character fix!  Someone will find it eventually...
 * robert_ancell attempts to annoy everyone until they commit it themselves or give me ubuntu-dev membership :)
 * StevenK searches for his checkout
<StevenK> robert_ancell: Good, then I won't feel bad when I beat you up :-)
 * TheMuso can put his hands on a checkout now if StevenK can't.
<robert_ancell> StevenK: Such violence! Won't someone think of the children?
<StevenK> Whose children?
<robert_ancell> TheMuso: Add the missing % on line 56 of lp-set-dup :)
 * StevenK continues to wait for bzr pull
 * TheMuso has to pull the latest changes also
<robert_ancell> ASDL not so good away from the CBD?
 * StevenK kicks robert_ancell 
<TheMuso> robert_ancell: my python is not great, I don't see where a % sign is needed...
<robert_ancell> needs a percent after the closing quote
<robert_ancell> i.e. substitute these variables into the string %=substitute operator
 * StevenK can't see lp-set-dup in his u-d-t pull
<TheMuso> robert_ancell: does there need to b e a space between the quote and the %?
<robert_ancell> TheMuso: Not required, but I'd put one there to match the others
<TheMuso> ok
<robert_ancell> TheMuso: thanks
<TheMuso> got it
<robert_ancell> StevenK: what do you have checked out?
<robert_ancell> laziness was the winner on the day
 * robert_ancell returns to his soul crushing attempts at rationalizing the 600+ compiz bug reports
<TheMuso> heh
<TheMuso> ok pushed.
<sanket> this is regarding APT, I wish to discuss an idea I have in mind
<persia> sanket, Have you written up your idea for review?
<sanket> Nopes, where to do that ?
<persia> Well, there's a few options.
<persia> brainstorm.ubuntu.com is a handy resource to get initial discussion of an idea and refine it a bit.
<persia> Once there's some understanding of how one might do it, one might write it up in more detail on the wiki.
<persia> Then it's easy to point to a URL on IRC or in a mailing list post to invite discussion and criticism.
<persia> Of course, if it's a small idea, a bug works nearly as well.  And if it's really small, just asking on IRC can be enough :)
<sanket> the idea relates to developing a tool to help automate the process of building custom( maybe partial ) mirrors for custom distro's supporting APT tool kit.
<persia> That's complex enough that I'd recommend outlining it on a wiki, at least.  Depending on how deeply you're familiar with apt and mirroring, you may even want to use brainstorm to help refine it first.
<sanket> just to make sure, such an idea is not impl or in progress... else i wud rather contribute :)
<sanket> does such project already exist ?
<persia> I don't happen to know of anything, but I'm just one person.  Documenting the outline of which sort of tool you're talking about would help others to determine if it matches some existing tool.
<sanket> cool enough, i will file the idea asap
<superm1> slangasek, from the feedback i'm hearing, it seems a bunch of those mesa bugs that i spent eons fixing in 9.04 have returned for nvidia and intel hardware, i'm trying to get the guys to register the stuff on isotracker, but it's sounding like we might have to skip a2 since these are kinda big things
<tjaalton> superm1: mesa and nvidia? they shouldn't have anything in common
<superm1> tjaalton, well this is the exact symptoms we were seeing in 9.04
<superm1> -nv driver using swrast
<superm1> and only getting stencil output with mythtv
<tjaalton> oh, that
<superm1> did some patch get dropped?
<superm1> or some upstream change that you know about that went on causing this?
<tjaalton> uh oh, yes
<tjaalton> I don't exactly know why
<tjaalton> let me check the git logs
<tjaalton> superm1: wait, it's still there
<tjaalton> 105_glXWaitX_segfaults.patch
<superm1> there was that one and one more
<superm1> 104_swrast_fbconfigs.patch
<superm1> are we sure it was applied upstream?
<tjaalton> it wasn't in jaunty
<superm1> hm. i'll have to dig up some nvidia hardware and look if things work with the jaunty mesa or where things are messed up then
<tjaalton> patch 104 was dropped late March, since it was included upstream
<superm1> hmm then
<slangasek> superm1: ah, doh
<superm1> took long to get "functional" live disks in the first place, so didnt leave much time to look at this stuff
<superm1> little installer gaf's earlier on and what not
<dholbach> good morning
<calc> hmm the way pidgin interacts with bip isn't exactly optimal but i suppose it works good enough for the moment
<calc> if i close the irc window it quits all of the channels on my proxy for me as a 'feature' apparently
<lifeless> \o/
<persia> calc, bip works well with xchat and irssi, although I'm not sure either of those interfaces work for you.
<lifeless> kill -9 ?
<calc> and with lots of channels always open in pidgin it makes it fairly hard to see when people private message me
<calc> persia: i need something to work with pidgin due to management request
<lifeless> calc: you hasve to use pidgin?
<calc> lifeless: i need something that will prod me about private messages immediately
<persia> calc, patch pidgin to not close windows when disconnecting?
<calc> persia: that might work assuming pidgin doesn't actually alert me about every message in every channel
<persia> xchat can be configured to provide various sorts of notifications, including audible notification.
<lifeless> calc: ah. I tell folk to SMS me if they ever want an 'immediate' guarantee, cause I close IRC and email and all notifications when focusing on stuff
<persia> calc, My memory is that pidgin has a notifications plugin that lets you configure when to provide notifications, and when to shut up.
<calc> ah hmm i'll have to look at it closer then
<TheMuso> c/
<pitti> Good morning
<pitti> tkamppeter: right, sounds like a plan; the cups recommends alone should also pull it in on upgrades
<pitti> lool: hi! poppler> I'm happy to prepare a package if you want
<\sh> moins pitti
<jamesh> pitti: hi.  Thanks for the help with the erlang related packages.
<jamesh> pitti: the couchdb package that got uploaded misses some dependencies though -- I only discovered this yesterday.
<pitti> jamesh: I saw; I'll upload your corrections; thanks for following up with Debian
<dholbach> jamesh: do you think you could forward the dependency changes of rabbitmq-server to Debian too?
<dholbach> the rabbitmq folks were keen to have the same versions in ubuntu and debian
<jamesh> dholbach: sure.
<dholbach> nice  thanks muchly
<tkamppeter> pitti, hi
<tkamppeter> pitti, I have made all CUPS Raster drivers depend on ghostscript-cups and also prepared a debdiff for the lsb package to depend on ghostscript-cups, as CUPS Raster is an LSB requirement.
<tkamppeter> pitti, see bug 385606
<ubottu> Launchpad bug 385606 in lsb "Print test page gives an error message "unsupported format: application/postscript"" [High,In progress] https://launchpad.net/bugs/385606
<Ng> so in this brave new world where hal is being deprecated, where should I poke a bug about my suspend hotkey (Fn-F4) not working while the screen is locked? (my argument being that a hotkey like that should always work, and I'm pretty sure it used to)
<ogra> Ng, if it isnt already, it should be handled by devicekit-power afaik
<Ng> hmm
<persia> sladen, A long long time ago you commented on bug #109446.  Do you have any further thoughts on the policy decision you mentioned then?
<ubottu> Launchpad bug 109446 in gnome-power-manager "Need /proc/acpi/wakeup tweaks to enable mousepad and USB to wake up from suspend" [Wishlist,Confirmed] https://launchpad.net/bugs/109446
<pitti> Ng: sounds like gnome-power-manager
<Ng> pitti: ok, ta
<asac> StevenK: still there?
<slytherin> does anyone know of any way for requesting a package to be rebuild on Debian buildds just to see if it has same FTBFS as Ubuntu.
<seb128> if it has been built nobody will do a rebuild just to see that
<cjwatson> slytherin: if you're talking about texlive-base/powerpc I *seriously* doubt it's buildd-specific. I know you can't reproduce it on your hardware but that's not the same thing
<cjwatson> slytherin: last time somebody claimed a problem was buildd-specific I bet against it and won 10 euro off them, so be warned :-)
<slytherin> cjwatson: no, this is different package
<cjwatson> ok, nevertheless you quit before I could reply to you yesterday
<slytherin> cjwatson: laptop battery was down and no electricity at home.
<slytherin> seb128: the package in question is arch:all, so it was uploaded with binaries. There is no build on Debian buildd.
<seb128> well debian do binary uploads ...
<directhex> boo @ binary uploads
<cjwatson> just try it in a chroot.
<slytherin> seb128: yes, and I have been fixing problem like this in Ubuntu fore more than 1 year. :-)
<slytherin> The reason for build failure is that the build process can not get internet connection. AFAIK, such problems do not occur in local chroot.
<slytherin> cjwatson: by the way, if there are more than one packages failing because of texlive-base, then does that mean it is buildd problem?
<cjwatson> uh? we know it's failing consistently *on the buildd*; that doesn't mean it's a buildd problem
<cjwatson> "buildd problem" means a problem that's exclusive to the buildd, something to do with the specialised software it runs
<slytherin> cjwatson: I am sorry. I meant chroot problem.
<cjwatson> I'm not sure how that's significantly different
<cjwatson> you mean that the stock chroot unpacked at the start of each build on the buildd might be wrong?
<cjwatson> I suppose that's possible; I might be in a position to check that
<slytherin> No. I mean that may be manual intervention will solve the problem. Like login into the chroot and see why texlive-base setup is failing consistently.
<cjwatson> if the chroot is actually broken then that might be the case, yes
 * cjwatson attempts to drive manage-chroot.py
<cjwatson> I don't see anything *obviously* wrong with the chroot
<cjwatson> there are no triggers awaiting processing AFAICS
<cjwatson> texlive-base isn't installed, of course
<slytherin> hmm
<slytherin> there are more than one packages failing for same reason on powerpc. But I have no idea why it is failing.
<cjwatson> anything you can think of that might be an observable reason for that failure?
<cjwatson> I have the chroot unpacked in front of me, although not on a powerpc machine
<persia> I have a powerpc machine if the chroot is transportable.
<slytherin> nothing, except it is same error everywhere.
<cjwatson> should be
<slytherin> can the chroot be recreated?
<cjwatson> http://people.ubuntu.com/~cjwatson/tmp/karmic-powerpc.tar.bz2
<cjwatson> 57.6MB
<slytherin> soren pointed to bug ï»¿198421 yesterday. Not sure how relevant it is.
<cjwatson> don't let me stop you, of course, but looking at the code it didn't look so much like a chroot problem, more like a libc problem specific to that particular class of hardware
<cjwatson> but that was just a guess
<cjwatson> 198421 is unrelated
<cjwatson> installing packages in the buildd chroot doesn't use dpkg-reconfigure
<nutz> hi everybody
<nutz> is someone in here really familiar with the alsa-setup in ubuntu?
<persia> nutz, A few people, but this isn't really a channel for support.  Why do you ask?
<slytherin> nutz: user questions in #ubuntu please.
<nutz> i'm trying to set up alsa with S/PDIF  on another distro, but i couldnt find any changes between the working ubuntu-setup and the not so well working gentoo setup. now i was wondering if there were patches in the alsa-drivers in ubuntu
<slytherin> cjwatson: So only two options remain 1. try using chroot somewhere else. 2. recreate the chroot. Am I right?
<nutz> it's not really support i'm after, i just want to know if there were patches to have passthrough work better
<cjwatson> slytherin: I don't see a reason to recreate the chroot unless it's demonstrated that that's where the problem lies
<cjwatson> slytherin: 1) seems like a useful thing to do
 * persia is performing #1 currently, with limited success (the chroot is *very* minimal, so needs help to be able to talk to apt)
<slytherin> persia: thanks for that. If you can not make it work, I will try it over weekend.
<persia> slytherin, The issue is that it breaks trying to install texlive-base, right?
<slytherin> persia: right
<nutz> more precisely: in the alsamixer in ubuntu all i had to do was unmute "IEC958". however in gentoo i don't get sound (from a regular signal, not talking about hwdts or hwac3 which works fine) until i put something like this: pcm.!default " plug:iec958"  in my alsarc
<nutz> neither of those distros have a /etc/asound.conf in the beginning
<slytherin> you can try building tuxguitar if you wish because I know for sure that it succeeded in my own chroot
<persia> `apt-get install texlive-base` didn't work, which is enough to be interesting.
<persia> slytherin, Can you point me at a specific build log?
<slytherin> persia: https://edge.launchpad.net/ubuntu/+source/tuxguitar/1.1-1/+build/997760/+files/buildlog_ubuntu-karmic-powerpc.tuxguitar_1.1-1_FAILEDTOBUILD.txt.gz
<persia> Hrm.  I got a different error.  I suspect I didn't do enough tweaks to make it work in my environment.
 * persia tries again.
<nutz> WTF... okay... i sort of "fixed it"
<nutz> if anybody cares: i just installed vanilla-sources-2.6.29.4  instead of the previously tested 2.6.30. now it works JUST like in ubuntu.
<nutz> no config-files etc.   so it's an alsa-version thing
<nutz> oki - have a nice one. bye
<TheMuso> I can have a look at the powerpc chroot/texlive stuff tomorrow if persia doesn't track anything down, about to go and enjoy some DVDs for the evening...
<TheMuso> so don't want to do it right now. :)
<persia> OK. `apt-get install texlive-base` worked.  Resetting, and trying `apt-get build-dep tuxguitar`
<amitk> soren: got time for a few stupid kvm questions?
<amitk> soren: how do I tell if kvm is running fully virtualised? On upgrading to karmic, my kvm windows-xp image is taking 100% cpu.
 * persia points at #ubuntu-virt
<amitk> thanks
<liw> is there an easy way to see how much security updates there are for an LTS release? my best approach would be to install one in the VM, and then see how much apt would download, but perhaps there's a faster way
<liw> I'm interested in the number of megabytes to be downloaded, and an approximation is fine
<persia> liw you could just check the contents of the hardy-security archive.
<persia> Packages.gz there might even have all the information you need.
<cjwatson> yeah, that plus grep-dctrl plus numsum
<slytherin> liw: or if you have access to the LTS installation, just to apt-get upgrade and it will tell you how much MB it is going to download.
<cjwatson> slytherin: I think that's what liw said
<cjwatson> "my best approach would be to install one in the VM, and then see how much apt would download, but perhaps there's a faster way"
<liw> oh, d'oh, that was silly of me: I only remembered the Installed-Size
<persia> which grep-dctrl+numsum is.
<slytherin> Oh. I thought he was actually planning to download everything.
<ion_> cjwatson: numsum, huh? Thanks, i hadnât stumbled upon num-utils before.
<cjwatson> it superseded the 'total' shell script I previously had
<cjwatson> (which is pretty trivial: 'total=0; for num in $(cat); do total="$(($total + $num))"; done; echo "$total"')
<liw> numsum could do with some manual page love
<liw> "numsum - numsum program file" is not a good NAME section :)
<ion_> :-)
<liw> hmm, Size is in bytes, not kilobytes
<persia> TheMuso, It's all yours.  I can't replicate in my environment: I get a successful install.  My process was untar chroot, edit sources.list & resolv.conf, bind-mount /dev and /proc, chroot, apt-get update, apt-get install texlive-base | apt-get build-dep tuxguitar.
<liw> I get about 1.7 *gigabytes* of security updates for hardy
<persia> liw, You may want to do your comparisons on a per-flavour basis, just to reduce the totals.
<liw> nah, I'm happy with a big number :)
<ion_> :-)
<StevenK> asac: Am now
<asac> StevenK: you wanted some input on xul?
<StevenK> asac: It's broken!
<StevenK> asac: Or something :-P
<asac> StevenK: i guess i need some background on what you are doing and what is broken
<StevenK> asac: http://paste.ubuntu.com/194242/
<asac> StevenK: which package is that?
<ion_> liw: Any thoughts about my comments yet? :-)
<StevenK> asac: kazehakase
<StevenK> asac: No-change rebuild from what's in the archive.
<liw> ion_, I'm processing the wiki page now
<asac> StevenK: when was the last build?
<StevenK> asac: Heh, intrepid
<StevenK> asac: I daresay it probably does require source changes, but I have no idea what.
<asac> StevenK: http://paste.ubuntu.com/194255/
<asac> g++-4.4
<asac> vs 4.3
<ogra> hmm, i'm sure i had glade3 installed in jaunty ...
 * ogra wonders where that went
<asac> StevenK: just do export CXX=g++4.3 in debian/rules ;)
<asac> and build depend on it ;)
<StevenK> Oh, argh
<StevenK> asac: So xulrunner doesn't like 4.4? :-P
<asac> well. we build a bunch of stuff against it with 4.4
<liw> ion_, dpkg-repack: it should be used, I think apt-sync already does; zsync looking into gzipped data: of course; apt method to support unpacked debs: interesting idea, we should discuss that for the next phase
<asac> more likely the way kaze uses it
<asac> StevenK: i am checking if its better with xulrunner-1.9.1-dev now
<ion_> liw: Whatâs the benefit of using dpkg-repack? It seems to have a 4Ãâ10Ã time overhead over plain tar c.
<liw> ion_, dpkg-repack should be used to construct a .deb for zsync to work on, if the user does not have a .deb already
<ion_> liw: Mostly due to gzipping, but thereâs also overhead over tar c | gzip
<ion_> liw: zsync could just as well get a tar as an inputfile, since it contains almost entirely the same data as a deb in an unpacked form.
<persia> liw, Do we preserve enough metainformation for dpkg-repack to be likely to have similar (compessed) binary chunks to a new .deb?
<liw> ion_, I'm mainly interested in optimizing the actual transfer, since that's the big bottleneck; further optimizations can happen later
<liw> persia, ask me again after I have done some benchmarks, but basically, zsync should be able to handle things well enough
<ion_> How about the idea under âHow method 0 could be implementedâ?
<asac> StevenK: so it builds with 1.9.1 ;)
<asac> but it crashes :(
<liw> ion_, it would seem to require fairly big changes to how .debs are generated, and that's not an option at this stage
<liw> and now I need to go see someone, back later
<ion_> At the very end of https://wiki.ubuntu.com/AptSyncInKarmicSpec in case anyone else wants to see my insane ramblings as well. :-P
<persia> liw, I expect if you can teach zsync about ar, it won't matter: mostly just a magic number thing.
<liw> ion_, damn, I just overwrote that
<liw> persia, yes, that is the plan
<ion_> No problem, https://wiki.ubuntu.com/AptSyncInKarmicSpec?action=recall&rev=12
<liw> ion_, sorry about that, but I need the spec to be useful for this cycle, and your ideas, while good, are too early for this cycle, but if this experiment goes well, then next cycle we can start doing more adventurous stuff
<ion_> âHow method 0 could be implementedâ â there would be no overhead of 0) dpkg-repack gzipping an inputfile, 1) zsync gunzipping the combination of the fetched data and inputfile, 2) zsync gzipping the resulting deb, 3) apt-get gunzipping that.
<ion_> gzip takes a *loooong* time.
<ion_> But itâs alright, i can wait for a later cycle. :-)
<ion_> Just thought that might as well make it right from the beginning.
<cjwatson> persia: why would zsync need to be taught about ar explicitly? ar is very little more than cat with a few header bits
<cjwatson> persia: the overhead of syncing the extra control data will be pretty small
<ion_> cjwatson: zsync would look inside the gzip within tar, so it needs to find the tar.gz within the ar archive.
<cjwatson> liw: thing to remember, you'll need to know which compression method the .deb you're syncing uses for its data.tar
<ion_> inside the tar within gzip
<cjwatson> ion_: ah
<cjwatson> ok, if you're going to uncompress it anyway it probably doesn't matter
<ion_> But with my idea, you wouldnât need to teach zsync about ar. Just put tars inside ar and gzip the deb. :-P
<ion_> The client wouldnât need to gzip anything, just do a single gunzip pass.
<XCP> do Ubuntu developers actually work on the kernel/application/driver code or do they just collect and package all the applications?
<ion_> When using zsync in the look-inside-gzip-inside-ar mode, thereâs also the problem that when zsync re-gzips the deb for apt, *it might not get the gzip right* and the checksum wouldnât match. My idea wouldnât have that issue either.
<ion_> xargs -d'\n' tar c -C / --no-recursion </var/lib/dpkg/info/"$package".list >inputfile.tar; zsync -i inputfile.tar http://archive/.../foo.deb.zsync would fetch parts of http://archive/.../foo.deb.gz, gunzip the data and pass apt a deb that contains debian-binary, control.tar, data.tar within ar. (dpkg already seems to support that format)
<cjwatson> XCP: both
<persia> ion_, That would require a deep change, and possibly a rebuild of all the apps.  Basically passing something like -9fn as unconditional arguments to gzip.
<persia> (during .deb creation)
 * ogra wonders if there is a way to make debootstrap more verbose during "Installing core packages..." in stage2
<ogra> ... without actually hacking debootstrap ...
<ion_> A rebuild wouldnât be needed. The initial fetch would either just download the entire deb.gz because the inputfile ar contains tar.gz, not tar, or you could detect that the old package in cache contains tar.gzs and force the creation of the inputfile from installed files.
<ion_> The initial fetch of a newly packaged deb.gz, that is.
<ion_> s/packaged/built/
<persia> I don't really like the idea of .deb.gz files, but it's about whether the compression result has a consistent checksum
<persia> Passing -nf to gzip enforces this.  Not passing it makes it a matter of luck, in many ways.
<persia> Specifying a compression level just avoids issues if two environments have different default compression levels.
<StevenK> asac: I'll build it with 4.3, thanks.
<persia> (note that this doesn't address differently compressed data tars)
<maxb> Why is -f mentioned here, surely the -9n are the options that matter
<cjwatson> why not adapt pristine-tar to cope with adjusting things like timestamp if necessary?
<cjwatson> seems a hell of a lot easier - we certainly aren't going to change the archive to have all .debs uncompressed there
<ion_> Making sure every single deb is always built with gzip --rsyncable -9nf, you could use zsync with a do-not-look-inside-gzip mode, get the major benefits, and the client would only need to gzip data if thereâs no older version in cache.
<ion_> Youâd *always* get the right deb with the right checksum.
<cjwatson> dpkg-deb always uses -9, but currently never --rsyncable. If you want that, you'd need to get dpkg changed, preferably upstream.
<cjwatson> you don't need to worry about the possibility of .debs not built using dpkg-deb
<ion_> Whatever the implementation is, iâd really prefer not having to have the client do a gzip pass on every single deb being updated. Itâs so slow.
<persia> maxb, Because it's conceivable that different gzips might make different choices on what needs to be compressed or not without -f.
<SiDi> Hey people. Has Ekiga been removed from karmic's default installs ?
<ion_> (See the gzip/dpkg-repack time overhead table under the title âSome benchmarkingâ at https://wiki.ubuntu.com/AptSyncInKarmicSpec?action=recall&rev=12)
<slytherin> SiDi: Why do you think so?
<SiDi> slytherin: i heard it'd be removed from the ISO to save some space. And it takes me some time to download it and check, so i thought i'd ask
<slytherin> SiDi: I heard? Where?
<ogra> it was removed from the seeds, yes
<SiDi> ogra: so no more SIP app by default ?
<asac> StevenK: thanks. we will port it to 1.9.1 or drop the -gecko part during karmic cycle anyway. so dont put much work into it ;)
<ogra> SiDi, no idea, i just saw it being removed, i guess emapthy will replace it
<slytherin> But does empathy have full audio/video support for SIP?
<slytherin> and does it have the long range of codec support as ekiga?
<slytherin> codec as in audio codecs (gsm, speex etc)
<SiDi> i actually think ekiga is a very important app as it is the most mature alternative to the proprietary skype. I'd be sad to see it disappear
<seb128> SiDi: why would it disappear?
<directhex> from the default install, presumably
<directhex> i've been promised by a friend at collabora that epiphany's audio/video UI is VASTLY improved in the next version, so there's some convergence there
<directhex> personally i never got ekiga working
<seb128> directhex: thanks but I guessed that, the question was rethorical for SiDi not for other people to jump in to add random comments
<seb128> directhex: you probably mean empathy there?
<directhex> erm, yes
 * directhex should sleep more
<seb128> still it's not a sip solution, doesn't have all the codecs from libopal etc and doesn't have an UI optimized for softphoning
<kenvandine> pitti: that telepathy-glib bug should be fixed today and included in today's upstream release
<\sh> cjwatson: hmmm...if I change on an installed ubuntu system some new debconf db entries for console-setup, and do a dpkg-reconfigure -f noninteractive console-setup, /etc/default/console-setup is not properly regenerated with the new debconf values
<cjwatson> the canonical source for configuration is the filesystem, not debconf
<cjwatson> if they differ the filesystem wins
<cjwatson> just change the configuration file directly
<\sh> cjwatson: well...I just deleted the console-setup and the postinst script creates a new one ... I wasn't sure if that behaviour is intended or if it was just a hickup
<cjwatson> yes, it does ensure that one exists at the end
<cjwatson> but in that case there's no configuration in the filesystem, so it can't win
<\sh> cjwatson: my plan was to update those files with new values from debconf...anyways..problem solved...thx :)
<cjwatson> change debconf + dpkg-reconfigure -f noninteractive is just not the correct way to change console-setup's configuration, though. Either dpkg-reconfigure (interactively) or edit /etc/default/console-setup directly
<cjwatson> the behaviour you're asking for would have the problem that an administrator who changed /etc/default/console-setup in the most straightforward and obvious way would be surprised when a later upgrade overwrote their changes
<\sh> cjwatson: well...idea behind that was: install some system with non-tweaked default values, and push later a new debconf db and dpkg-reconfigure -a -f noninteractive to regenerate all the config files with the new values...
<cjwatson> \sh: not going to work in general I'm afraid
<cjwatson> debconf is not a registry (tm)
<\sh> hehe for sure :)
<\sh> cjwatson: thx for the heads-up
<amitk> hmm.. why does my apport "Report Problem" button not work?
<ogra> because you have no problems ?
<ogra> (apport is so clever ;) )
<maxb> wgrant: Are you planning to upload your en-PPA-ed changes to xserver-xorg-input-synaptics soon, ooi? Do you need further testing
<wgrant> maxb: I should probably prepare an upload and find a sponsor, yes... I'll do that tomorrow.
<pitti> kenvandine: great to hear
<amitk> ogra: apport popped up in the first place when nautilus crashed :-/
<ogra> ouch
<Pici> Regarding the note on the Alpha2 testing page, is HAL being completely depreciated, or only for power management?
<persia> I heard it was dead upstream, but it's probably incremental to pull it out (hopefully within karmic)
<evand1> devicekit-disks is in place as well, so it's already more than just power management.
<calc> which is better xchat or xchat-gnome (they seem to be forked?)
<Ampelbein> !best | calc
<ubottu> calc: Usually, there is no single "best" application to perform a given task. It's up to you to choose, depending on your preferences, features you require, and other factors. Do NOT take polls in the channel. If you insist on getting people's opinions, ask BestBot in #ubuntu-bots.
<LaserJock> calc: xchat-gnome is from devil ;-)
<NCommander> LaserJock, I thought the devil ran xchat-win32
<calc> is it possible to join multiple bip connections through a single xchat?
 * calc thinks it would look to xchat like just trying to connect to the same irc server multiple times
<robbiew> slangasek: ping
<directhex> calc, it would indeed look like that
<directhex> calc, you just configure multiple duplicate irc servers to join, and have a different connection string configured on each
<mterry> robbiew: Heads up that I probably don't have the right raid hardware after all.  I don't have any non-netbook or non-laptop machines, so the only thing way I can get two identical hard drives is with thumb drives, but I don't believe they work with dmraid (though apparently you can use them with mdadm)
<robbiew> mterry: hmm...okay
<robbiew> dendrobates: around?
<mterry> robbiew: I'm confirming with Luke
<slangasek> robbiew: pong
<robbiew> slangasek: I can't make the first hour (perf review)...and Colin needs to leave early, so could Foundations move up the queue?
<slangasek> ok
<robbiew> thanks
<robbiew> cjwatson: ^^
<tkamppeter> Anyone around who can help on a package dependency problem?
<tkamppeter> See bug 141641
<ubottu> Launchpad bug 141641 in lsb "installing lsb requires postfix" [Unknown,In progress] https://launchpad.net/bugs/141641
<tkamppeter> The package lsb depends on mail-transport-agent and mail-transport-agent is provided by very many packages, including postfix and ssmtp. Currently the heavy daemon-loaded postfix gets autro-installed. How I can change priorities so that ssmtp gets auto-installed by default?
<cjwatson> slangasek: cheers
<\sh> tkamppeter: lsb-core needs mailx, and mailx needs bsd-mailx and bsd-mailx depends on postfix|mail-transport-agent...so correct...without a MTA mailx would be useless ;)
<tkamppeter> \sh, I have successfull replaced postfix by ssmtp.
<tkamppeter> \sh, what I want now is that ssmtp gets chosen in the first place.
<sebner> \sh: it's funny, is it just me or are you more often online than *before* the baby was born *ehehe* ;-P
<\sh> tkamppeter: right..the problem is, if no MTA is installed...it will choose postfix as prio 1 but if something else providing mail-transport-agent is installed, it won't install postfix
<tkamppeter> \sh, can I make ssmtp the one being automatically chosen if no MTA is there?
<\sh> sebner: I'm always on..but depending on workload and interesst I'm active or not ;)
<sebner> ehehe
<LaserJock> tkamppeter: I've got a printing question for you. Do you know of any bugs where printing large pdfs cause the printing dialogs to freeze up?
<\sh> tkamppeter: that's a foundation thing...postfix is the default MTA for ubuntu...I don't know if there is a plan for desktops to install a lightweight replacement, cjwatson or whoever is the right person
<tkamppeter> cjwatson, ping
<cjwatson> meeting
<cjwatson> lsb should probably depend on default-mta | mail-transport-agent as documented on ubuntu-devel recently rather than explicitly on postfix
<cjwatson> I don't think we should change default-mta to ssmtp
<\sh> cjwatson: bsd-mailx is the bugger, which is pulled in by mailx (a dep of lsb-core)
<tkamppeter> LaserJock: No, did not know about large PDFs freezing the printing dialog (they can perhaps freeze the filter chain), but I have an idea: evince (at least as of Jaunty and older) produces rather huge print output. So for long PDFs with many pictures the transfer of a job from evince to CUPS can take very long.
<LaserJock> tkamppeter: well, what happens is in acroread or evince when I hit the Print menu item the dialog box never really comes up or takes forever
<LaserJock> tkamppeter: so before it actually gets to the actual "send it to the printer" bit I think
<LaserJock> I'm having to print my dissertation from OS X presently because I haven't been able to in Jaunty :/
<tkamppeter> cjwatson, \sh: I want to avoid the problem that if a user installs a distro-independent package (LSB-packages) that a daemon (postfix) gets automatically installed. Especially this should not happen on desktop systems.
<tkamppeter> cjwatson, \sh: Especially we will have many manufacturer-supplied printer drivers in the form of LSB packages. It would be very bad to get an MTA daemon only to make the printer working.
<tkamppeter> LaserJock: This looks like bugs in the applications, as at that point the printing system is only asked for available printers and this does not depend on the job size.
<LaserJock> tkamppeter: ok, thanks, that gives me something to hunt for
<cjwatson> tkamppeter: I don't see why that's "very bad".
<tkamppeter> cjwatson, adding a daemon is once a potential security problem and second takes resources. Typical LSB-packaged applications and printer drivers do not need a mail server on the local box.
<\sh> tkamppeter: postfix by default listens only on 127.0.0.1 and on the ipv6 equivalent of localhost
<cjwatson> what he said.
<\sh> tkamppeter: there is no harm when there is postfix installed on desktops
<tkamppeter> \sh, but it is still taking resources and when one installs postfix the user is asked which type of mail server he wants, not very nice for users who have connected a new printer to their box.
<cjwatson> I don't think IRC is the right place for this discussion; it's too complicated. It belongs on the mailing list
<cjwatson> and you're saying "must" a lot; please stop, there's more to the question of what default-mta is than this specific requirement
<tkamppeter> pitti (or any security expert), WDYT about a printer driver installation pulling postfix?
<cjwatson> Martin has already commented on the bug
<cjwatson> really, it's not obvious that fixing this specifically in Ubuntu rather than in LSB upstream is the right thing to do
<cjwatson> see the upstream bug
<pitti> it's a pretty br**** LSB requirement with no obvious solution right now, except for fixing LSB
<cjwatson> ssmtp is not going to be any good for the basic requirement of sending status mail which is apparently why sendmail was included in the LSB in the first place
<pitti> or vendors not depending on lsb, but on e. g. lsb-printing
<cjwatson> lsb-printing depends: lsb-core depends: postfix | mail-transport-agent
<pitti> oh, it's even in -core now? darn
<pitti> so this seems FUBAR to me :(
<tkamppeter> pitti, cjwatson: Are the lsb-... subpackages standardized in the LSB? Or is this Ubuntu-specific?
<cjwatson> all I'm saying is that the place to start with this is not "how do we get ssmtp made the default". You need to back up a bit.
<cjwatson> LSB Core is an upstream concept
<cjwatson> as are the other modules
<pitti> tkamppeter: a good place to argue for this is the upstream bug IMHO
<pitti> it didn't get much traction yet :(
<tkamppeter> cjwatson, pitti, can one perhaps make the situation of Karmic at least a little bit more user-friendly, for example letting postfix automatically install with a default configuration, without asking the user anything?
<cjwatson> ask lamont, but I'd support that
<pitti> tkamppeter: it's not a problem in karmic per se, just with third-party packages
<tkamppeter> lamont, ping
<mpt> asac, hi
<mpt> asac, I've just been asked: "mpt, if I want Ubuntu to get the wireless driver issues to be sorted out; where would the best place be to donate money?"
<mpt> and I have no idea what to answer :-)
<asac> mpt: its probably not the "where to donate money", but "where to not spend money" :)
<mpt> asac, I found the answer, <http://madwifi-project.org/wiki/Donations>
<azeem> mpt: euh
<asac> mpt: err. thats madwifi ;)
<mpt> asac, I know hardly anything about wireless drivers, so whatever you're implying, it's going over my head with a whoosh
<asac> mpt: i say that donating there wont help to resolve general driver issues on linux ;)
<asac> mpt: i might be wrong, but are trying to get a away from madwifi drivers
<mpt> asac, so is there a human-readable summary somewhere of what people should and shouldn't spend money on?
<johanbr> mpt: http://linuxwireless.org/en/users/Devices
<mpt> johanbr, thanks, I was hoping for something a little easier to understand :-)
<mpt> but that looks fairly comprehensive
<johanbr> unfortunately manufacturers change chipsets without changing the name of their devices
<johanbr> so you pretty much have to know the PCI id to tell whether a given device will work, that's why it gets a bit complicated
<mpt> http://linuxwireless.org/CertificationIdeas looks nifty
<al-maisan> hello james_w, re. the merged ibus package .. the "[Control+space]" localisation strings were commented out in the more recent debian debian package
<al-maisan> the ubuntu patch brings them back in
<james_w> hi al-maisan
<james_w> do you know why they were commented?
<al-maisan> hello james_w, no, I don't.
<al-maisan> Let me dig around a little bit.
<james_w> thanks
<james_w> we could ask LI Daobing of course
<al-maisan> james_w: yes, his comment is just "* new upstream release."
<al-maisan> james_w: I can email him and ask; is that a good course of action?
<james_w> I'd be tempted to just wait until Monday morning and see if they are around
<james_w> or email, yes
<al-maisan> OK, great, will do that then and see how far that gets us :)
<james_w> cool, thansk
<maxb> kirkland: Hi, I just noticed screen-profiles has re-entered Karmic from Debian. I've reopened bug 374162 - if you're around perhaps you could add (or not) your core-dev ack that archive admins will presumably want to see
<ubottu> Launchpad bug 374162 in screen-profiles "Please remove screen-profiles from karmic (renamed to byobu)" [Medium,New] https://launchpad.net/bugs/374162
<kirkland> maxb: yeah, will do ... screen-profiles should not be added to karmic as a functional package
<kirkland> maxb: though a meta depends on byobu or something might make sense
<maxb> Transitional packages built out of the byobu source package, possibly?
 * maxb doesn't know if apt is clever enough to migrate based on replaces/provides/conflicts etc. alone
<kirkland> maxb: let's try pinging mvo
<kirkland> (who isn't around atm)
<kirkland> maxb: i'll subscribe him to the bug
<maxb> A different bug, perhaps, since the archive admins will close that one after processing it?
<Amaranth> maxb: apt will not automatically fetch a package that Replaces a package on the system already
<Amaranth> maxb: You'll have to make your new package provide a transitional package
<maxb> ah, of course - /me not thinking clearly
<slangasek> pitti: hmm, so in light of bug #384511, I guess we should drop hotkey-setup straightaway
<ubottu> Launchpad bug 384511 in hotkey-setup "Toogle display key not working anymore" [Undecided,Incomplete] https://launchpad.net/bugs/384511
<ion_> liw: How about this? pe143956 < ion_> Making sure every single deb is always built with gzip --rsyncable -9nf, you could use zsync with a do-not-look-inside-gzip mode, get the major benefits, and the client would only need to gzip data if thereâs no older version in cache.
<liw> ion_, see the spec as I last edited it; I will run benchmarks comparing various ways of compressing .debs and see what the results are; I'm not really interested in debating which options would be best until I've done the benchmarks
<ion_> liw: In my benchmark (in my comments), using --rsyncable and zsync in raw data mode, there only was a 3% transfer overhead for a 454k change in a 30M file. Having to do even a single gzip pass for every single package thatâs being updated seems to cause a huge difference in processing time. With --rsyncable and raw data mode, that could be avoided for every package that already exists in apt cache.
<ion_> liw: 3% against the look-inside-gzip mode and no --rsyncable.
<ion_> liw: But yeah, better do more extensive benchmarking.
<ion_> liw: That just seems like the next best choice (mostly great speed *and* almost the same benefit in fetch size), and it should be without major infrastructure changes â just make dpkg-deb use gzip --rsyncable -9nf.
<ion_> liw: Oh, and importantly: with zsync in raw data mode, thereâs a 100% certainity that the checksum matches (without additional processing), because no re-gzipping is involved in clientside. Itâs certainly possible to make the client-side gzip launched by zsync do precisely the same thing as dpkg-deb in the builder, though.
<rish> Dell Studio, Jaunty, No sound coming. Touchpad Acting Wierd. Anyone can help??
<maxb> rish: Hi, this is a channel for Ubuntu development. For support, try #ubuntu
<rish> means people here r open source developers/
<rish> how to become an ubuntu developer?
<Aquina> Hy! Can one of you lovely geeks tell me please why "SUBDOMAIN_MODULE_PANIC" is set to "XXX" in /etc/apparmor/subdomain.conf?
<Aquina> Shouldn't it at least be set wo "warn" or "build"?
<Madkiss> hi folks.
<Madkiss> If ivoks comes back online, please tell him I didn't mean to be rude by not answering. I was just not in front of my computer :)
<Viper550> okay, can ubuntu's installer resize ntfs partitions?
<ScottK> Viper550: Yes.
<Viper550> oh cool
#ubuntu-devel 2009-06-13
<slangasek> pitti: I don't see any equivalent to the micro-star infinity keycodes from /usr/share/hal/fdi/information/10freedesktop/30-keymap-misc.fdi in udev-extras; I thought all of those were supposed to have been carried over?
<Caesar> kees: you around?
<slangasek> pitti: maybe udev-extras should Conflict: hotkey-setup to force its removal on upgrade?
<kees> Caesar: yup, what's up?
<Caesar> kees: can I get you to look at a glibc bug and tell me if you think it's got the potential to be exploitable?
<Caesar> I have a sample program that should reproduce the problem
<Caesar> At least I can reproduce the problem on everything up to Hardy's glibc
<kees> Caesar: sure, email me: kees@ubuntu.com
<Caesar> kees: sent
<kees> Caesar: cool, I'll look at it
<Caesar> thanks
<kees> Caesar: -> privmsg
<grndslm> excuse me, but i'm trying to figure out which motherboard would be better for compatibility with ubuntu, as NOBODY in the regular channel knows what the current state of development is like...
<grndslm> so if your options were these two -- Intel board:  G45 + ICH10 + GMA X4500HD ---OR--- Nvidia board: GeForce 9300 + nForce 730i + GeForce 9300.... which one would you pick??
<directhex> grndslm, officially, off-topic. unofficially, the latter setup works fine with the properitary nvidia driver (but good luck doing audio over digital); the former setup should work fine, but the intel driver may need tweaking to not be slow
<grndslm> directhex:  thanks, i think i'll try the nvidia board for once
<directhex> i use a MSI P7NGM-Digital with that chipset
<directhex> for my mythbox
<zarocon> hi
<Ryan52> does anybody happen to have a backport of debhelper >= 7.0.50 (supporting override_dh_foo targets) for hardy? it depends on dpkg-dev 1.14.19, but hardy only has 1.14.16.6ubuntu3. and hardy-backports only has debhelper 7.0.13.
<Ryan52> ugh, tried forcing it to install and now I get "Undefined subroutine" errors which seem to be completely unrelated. /me gives up.
<lifeless> !
<lifeless> because version dependencies are really just made to make life difficult.
<progesterone> Where can I download the Ubuntu source code?
<directhex> good news! we've shaved another 5 meg from tomboy's on-disk footprint in debian
<ion_> Neat
<ianw> Hello all, I'm doing an assignment for my MBA on Ubuntu and wanted to know what motivates developers to develop for Ubuntu?
<ianw> Nap time?
<ianw> :)
<Nafallo> weekend
<ianw> Of course
<ianw> Why am I working then!?  :)
<ivoks> ianw: probably every dev different motivation
<ivoks> i'm missing 'has'
<ivoks> (except the desire to rule the world, of course)
<ianw> Can I guess a few: Money, Contributing to a good project, Gaining and improving skills, can do it from home, just a hobby, hate microsoft ... can you think of any others or am I completely off track?
<ianw> Desire to rule the world... of course :)
<borrell> they are the ones that spring to mind
<Nafallo> kudos from the community
<Nafallo> fame
<Nafallo> great people to work with
<Nafallo> (i.e. community)
<ianw> Kudos and fame... aahhh, nice. How do you measure kudos and fame?
<borrell> resume padding :p
<geser> supporting FLOSS
<Nafallo> people get bored doing nothing. this is something to do.
<Nafallo> why would you need to measure it? isn't having them enough?
<ivoks> you can messure fame by counting your name in blog entries :)
<ianw> Who would you say has the greatest active contributor?
<Nafallo> what's the alternatives?
<ianw> I'm really not sure what I'm asking here... maybe what I'm asking is when you think of kudos and fame in the Ubuntu community what names come to mind for you?
<ivoks> bad question :D
<ianw> Hmmm. Probably is.
<ianw> :P
<Nafallo> I don't really want to hilight a lot of the individuals in this channel...
<ianw> Oooohh... lurking :)
<ianw> OK how about this... Why contribute to Ubuntu and not something else?
<Nafallo> friendly community, low entry level were the main ones for me back then.
<ivoks> clear objectives
<Nafallo> logical thinking
<Nafallo> i.e. if the hardware doesn't work without binary blobs, let's just include them,
<Nafallo> rather than "screw you then" attitude
<ianw> Do you encounter a "screw you" attitude elsewhere? Why do you think that it is not encountered within Ubuntu?
<ivoks> you misunderstood Nafallo
<ivoks> ubuntu will accept binary blob, even though we hate that, if that's the only way to make hardware work
<Nafallo> sure. all the distributions that put freedom before usability. that might have been more true previously, I'm haven't been using a lot of other distros lately ;-)
<ianw> Aaaah.
<Nafallo> ivoks: that's not a missunderstanding on might part.
<ivoks> Nafallo: ianw didn't understand what you said
<ianw> True.
<directhex> ianw, free software is about "scratching an itch" - making something better for yourself. other people may also benefit as a side-effect. i run ubuntu on my machines, so i gain from improving it
<Nafallo> directhex++
<ianw> Well put directhex
<ivoks> well, nowdays, people get paid to scratch others people itches :)
<directhex> i may not have much time or respect for people telling me how to do so - certainly people who *consume* rather than *provide* freedom.
<directhex> i.e. if you ain't paying me, then i pick the itches
<ianw> So it provides you with a greater sense of control.
<directhex> ianw, were you one of the people at UDS who was studying developers?
<ianw> Well I should say thanks to all of you. I've been using Ubuntu since Dapper and you make it possible, I'll try and deposit my assignment that I'm doing somewhere so anyone can check it out.
<ianw> directhex, no I wasn't. I'm doing my MBA and writing an essay on Intellectual Capital Management and have used Ubuntu as a case study.
<ianw> Really interesting case too.
<ianw> The assignment is all about how projects and organisations are structured to make best use of knowledge and information flows.
<ianw> Ubuntu seems to do it well, from my POV
<ianw> Anyway, I had better stop bothering you all.. thanks very much for you time, both now and for developing Ubuntu!
<ianw> See ya!
<ivoks> take care
<directhex> ianw, be careful about sharing your assignment - your institution may claim copyright over it which forbids you from doing just that
<ianw> Thanks for your suggestion directhex, I've had to check that for another assignment. I have copyright.
<Quintasan> sorry if I'm asking in wrong channel. I'm trying to make a Ubuntu remix but I can't mount squashfs file -> http://pastebin.com/f348b2700
<Sarvatt> you need squashfs-tools 4.0
<Quintasan> Sarvatt: hmm in repositiories I have squashfs-tools 3.3, that means I should compile them myself, right?
<mac9416> Hello, is this a good place for me to ask a simple question on the inner-workings of Add/Remove Programs? Any devels from that project here?
<pochu> mac9416: that's called gnome-app-install, #ubuntu-desktop would be a better place to ask I think
<mac9416> pochu, OK, thanks. It's a rather technical question. I'll try there, though.
<pochu> mac9416: that's a technical channel :)
<mac9416> Ah cool. Thanks :-)
<bluefoxicy> hey I just fixed my internet speeds
<bluefoxicy> transmission was set to limit uploads to 25k/s
<bluefoxicy> I undid that, and you know what?  Things got faster!
<bluefoxicy> It seems Transmission is somehow limiting bandwidth use system wide
<Nafallo> bluefoxicy: you have a weird definition of "internet speed". just saying.
<Nafallo> :-)
<bluefoxicy> Nafallo:  yeah I'm just babbling right now.
<bluefoxicy> I mean, with transmission limiting my bandwidth, browsing the web is really slow.  Give it unlimited bandwidth, and I can download e-mail and browse the web normally again.
<bluefoxicy> This only makes sense if it limits the bandwidth system wide, and then promptly saturates it.
<bluefoxicy> This doesn't make sense, of course.
<Nafallo> bluefoxicy: so all in all you shouldn't be cheap with your bandwidth in the first place? :-)
<bluefoxicy> unless there's a kernel networking bug where whatever transmission does (blocks on recv/send?) causes all of the TCP/IP stack to block
<bluefoxicy> Nafallo:  well, I'm on a shared connection that can get up to 2.0M/s
<bluefoxicy> what I do affects everyone here
<mbana> i want to use the old notification.  i've tried apt-get remove notify-osd, but then i need to remove ubuntu-desktop.
<hyperair> bug #379615
<ubottu> Launchpad bug 379615 in notify-osd "notify-osd cannot be removed without removing ubuntu-desktop." [Undecided,New] https://launchpad.net/bugs/379615
<mbana> way to go
<mbana> thanks for the link
<mbiebl> doko: around?
<ebroder> Is there any way I can suppress libnotify notifications from a particular application?
<ebroder> For our site, I want to kill the notifications from system-config-printer because print jobs are all spooled to a remote CUPS server
<ebroder> So it's popping up notifications saying the job has completed printing, when really it's just finished spooling to another cupsd
<ebroder> I've kind of briefly skimmed the notify-osd bit that handles incoming dbus messages, and I didn't see any kind of filtering capability
<e0n`> Has anyone produced a lpia hardy build?
<e0n`> well alternate installer/live I see all the lpia binaries for hardy just no livecd
<ebroder> Anybody care to provide advice on what to do about bug #371581?
<ubottu> Launchpad bug 371581 in erlang "erlang-base conflicts with old erlang-doc-html" [Undecided,Confirmed] https://launchpad.net/bugs/371581
#ubuntu-devel 2009-06-14
<soreau> Can someone please fix this? http://pastebin.com/m14c52dca
<soreau> This happened in Intrepid too, same package. -unsupported was 0.7.6 but Intrepid shipped with compiz-0.7.8 and mvo fixed it
<soreau> Obviously, since they're not the same versions the plugins provided by the package simply do not work
<tormod> soreau: please file a bug
<slangasek> hrm, is there no way to unsubscribe a team from a blueprint?
<pwnguin> well, you could implement it :)
<phil_ps> I'm writing a program that needs binutils-dev, specifically BFD
<phil_ps> debian says not to link against the libbfd
<phil_ps> do I keep the source of bfd with my source
<slangasek> pwnguin: huh?
<pwnguin> it was a joke, but maybe i misunderstood
<pwnguin> doesn't implementing a blueprint eventually retire it?
<slangasek> oh, implement the blueprint
<slangasek> I have no idea, I assume I'm now stuck subscribed to the blueprint indefinitely
<Hobbsee> slangasek: i presume you have to unsubscibe fomr the bug linked to the blueprint
<slangasek> Hobbsee: there's no linked bug; someone subscribed ubuntu-release to https://blueprints.launchpad.net/ubuntu/+spec/karmic-fedora-directory-server-inclusion and there's no 'undo' button
<Hobbsee> slangasek: yeah, I noticed that yesterday.  There is a linked bug, i'll look it up.
<Hobbsee> slangasek: the related bug is at https://bugs.edge.launchpad.net/ubuntu/+bug/27463 which pitti has unsubscribed us (again, i think) from.
<ubottu> Launchpad bug 27463 in ubuntu "[needs-packaging] Fedora Directory Server for Ubuntu" [Wishlist,In progress]
<Hobbsee> slangasek: i suspect that blueprint unsubscription is automatic, when you get unsubscribed from the bug that's sending you the mail fo the blueprint
<Hobbsee> hrm, that bug is linked to a different spec.
<Hobbsee> darn.  i don't know
<Hobbsee> slangasek: yeah, you're stuck.  https://launchpad.net/bugs/50875
<ubottu> Launchpad bug 50875 in blueprint "It is not possible to unsubscribe a team from a blueprint" [Low,Triaged]
<slangasek> Hobbsee: yeah :/
<iulian> ScottK: Hey.  I'm trying to merge python-qt4 with Sid but I'm a bit confused because of libqt4-phonon-dev.  You mentioned in the changelog that you replaced libphonon-dev with libqt4-phonon-dev but the current Karmic version still has libphonon-dev in B-D.
<iulian> ScottK: Am I missing something?
<ScottK> iulian: I may have neglected to actually make the change.  We do want to build-dep on libqt4-phonon-dev
<ScottK> iulian: We may need a newer qscintilla first (look at the Debian bugs on python-qt4).
<iulian> ScottK: Hmm, I cannot find anything about qscintilla...
<iulian> ScottK: There's only one bug opened in Debian against python-qt4.
<mohan_> hi.. i am using ubuntu jaunty 64bit..
<mohan_> where can i get Realtime Kernel?
<lamont> tkamppeter: afk
<lamont> ack, even
<tkamppeter> lamont: hi
<c3o> assallmaua'laikum brohter...
<c3o> hai all
<c3o> any hacker on this room brother... am need to talk
<c3o> http://www.google.co.id/search?hl=id&client=firefox-a&rls=com.ubuntu%3Aen-US%3Aunofficial&q=bridge+management+system&btnG=Telusuri&meta=
<c3o> am need develop it can help me....
<c3o> NEED HLEP
<ikonia> c3o: stop
<ikonia> c3o: this channel is for development discussion
<ikonia> not a "help" channel, and the way you are addressing the channel is not helpful
<c3o> yup am now that brohter..
<c3o> from kubuntu am get this room for discussion
<c3o> about bms
<ikonia> ok - so stop screaming "HELP"
<ikonia> and discuss it
<c3o> did you now that? am need develop it with kubuntu / ubuntu
<c3o> :D
<ikonia> yes
<c3o> let start :D
<ikonia> so disuss
<lamont> tkamppeter: you had postfix questions for me?
<c3o_> any script for run bms application for bridge management system
<ikonia> no
<c3o_> wow...
<c3o_> ikonia, can  you tell me some room for newbee like me...
<c3o_> am want lean ubuntu / kubuntu
<ikonia> c3o_: #ubuntu
<ikonia> #kubuntu
<c3o_> thanks brother...
 * lamont wanders off
<tkamppeter> lamont, the problem is described in bug 141641 and in http://bugs.linuxbase.org/show_bug.cgi?id=2407
<ubottu> Launchpad bug 141641 in lsb "installing lsb requires postfix" [Unknown,In progress] https://launchpad.net/bugs/141641
<ubottu> bugs.linuxbase.org bug 2407 in Core-generic "Consider dropping sendmail as a required core component" [Normal,Assigned]
<c3o_> wine we need develop the best wine for emulator exe ?
<c3o_> any ide ?
<tkamppeter> lamont, the lsb package, required byu all third-party packages based on the LSB, including desktop apps and printer drivers, pulls postfix. This leads to an MTA daemon running which is often not needed and it also requires from users who want to install a desktop app or a printer driver to answer the debconf question which kind of mail server they want to have.\
<c3o_> nice
<ScottK> tkamppeter: Sounds like an LSB question, nothing directly to do with Postfix.
<ikonia> c3o: this channel is not for that sort of discussion, I suggest you leave it and join #ubuntu
<c3o> hai.. any time we mush give the sort discussion. what the hell it
<tkamppeter> ScottK, it is already under discussion on the LSB mailing list ...
<ScottK> OK
<ikonia> c3o: this channel is for ubuntu development discussion - you're not developing on ubuntu, you want to learn how to use it, this channel is not the right place,
<c3o> oke brother oke am out
<c3o> fuck of ubuntu
<c3o> all brother not care with me
<ikonia> thank you
<directhex> ikonia, could have been worse!
<ikonia> very true
<lamont> tkamppeter: and that's why lsb-base is so much sweeter as a dependency than lsb-core, and why we dropped lsb-core from the default install back in, oh, hoary or breezy, iirc
<lamont> as in, what cares about lsb core these days, and why?
<lamont> because, unless it's Linux Server Base, there's no good cause for there to be an MTA in it
<lamont> and even then, it's questionable
<lool> kirkland: Heya, you might be interested in this OOPS with ecryptfs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/387073
<ubottu> Launchpad bug 387073 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000000000000228" [Undecided,New]
<lool> kirkland: There are two other oopses against linux with ecryptfs, they have differing backtraces though
<Quintasan> hmm, anyone knows which version of squashfs-tools is used to generate squasfs system on livecd? I'm having problems mounting it
#ubuntu-devel 2010-06-14
<Drakeson> is there a guideline or some such that explains what the client-side-decorations patch (against libgtk2.0) does and what APIs have changed?
<SoftwareExplorer> I bzr get'ed the softwareproperties source and fixed two depreciation warnings. Then I did a commit, but now I'm a little confused how I would publish my branch to launchpad. My launchpad username is erik-b-andersen.
<CynthiaG> SoftwareExplorer: Do you have a branch?
<CynthiaG> Registered for yourself on Launchpad, I mean.
<wgrant> SoftwareExplorer: You can just say 'bzr push lp:~erik-b-andersen/softwareproperties/SOME-DESCRIPTIVE-NAME'
<SoftwareExplorer> I do have a launchpad account. I think I figured out how to do the bzr push thing. (Thanks wgrant for the advice though) Now I'm wondering what the official process is to get my branch merged.
<CynthiaG> go to your branch page and hit "propose for merge", then link it to the bug reports it's meant to fix
<SoftwareExplorer> CynthiaG: I didn't report a bug, I just noticed the bug and thought I might be able to fix it since it was in python, got the source and fixed it. Should I try to find a bug or file one?
<CynthiaG> for such things as warnings, I don't know if you should file a bug or just propose the merge
<CynthiaG> post about it on ubuntu-devel-discuss or wait here ~7 hours for someone at Canonical to be there (Euro timezone and start of the work week)
<SoftwareExplorer> CynthiaG: What would happen if I propose a merge. Then if I find a bug can't I just mark my branch as fixing it?
<CynthiaG> you could do that
<CynthiaG> in the bug report, there's also a "link to a branch" option, so you would hit that and add a comment saying "the linked branch fixes this bug"
<SoftwareExplorer> CynthiaG: Ok, thanks. I think that's what I'll do then.
<CynthiaG> SoftwareExplorer: mk :)
<CynthiaG> Wait a minute
<CynthiaG> Do you mean "if I find a bug" about the DeprecationWarning, or "if I find a bug" about anything related to softwareproperties?
<SoftwareExplorer> CynthiaG:I meant if I find a bug about the two depreciation warnings.
<CynthiaG> ok, good - that was just me getting confused a bit
<andersk> Are new Debian packages being synced into Maverick automatically, or only updated existing packages?
<ScottK> andersk: New ones too, but it's a seperate process that is done less frequently.
<hagabaka> Is anyone associated with x-edgers? I am trying to enable r300 gallium on ubuntu using https://launchpad.net/~xorg-edgers/+archive/ppa/ , but after installing the packages and restarting, glxinfo still doesn't say anything about gallium.
<Sarvatt> hagabaka: #ubuntu-x
<Sarvatt> i run the ppa, will help you out over in that channel
<CynthiaG> I just tried the Maverick daily from 2010-06-11 to speed-test it, and the laptop won't boot it :(
<mneptok> CynthiaG: #ubuntu+1 please
<CynthiaG> Well, this was on-continuous-topic from my prior development on the LiveCD optimisations
<CynthiaG> Sorry though
<mneptok> CynthiaG: are you looking for support, or to debug it yourself and submit a fix?
<CynthiaG> I'm not looking to do anything, because in the time it took me between downloading the daily and trying it out, things may have changed
<lifeless> mneptok: CynthiaG is doing dev
<lifeless> mneptok: for all that it sounded a bit +1ish :P
<CynthiaG> if you want to take a look at what I'm doing, see bug 589629 :)
<ubottu> Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
<CynthiaG> cjwatson gave the daily builds the bootchart package, and I was starting Maverick-20100611 to see that
<CynthiaG> unfortunately it didn't start
<mneptok> CynthiaG: there's no need for that. your initial comment is precisely the kind of support questions -devel gets, and shouldn't.
<CynthiaG> Am I off to a bad start in here then?
<mneptok> CynthiaG: not in the least.
<CynthiaG> Cool :)
<mneptok> CynthiaG: there's coffee, donuts, and some half-baked x86 assembly on the table in the corner. help yourself. ;)
<CynthiaG> And now re-reading the mksquashfs order file, I see that I have a gnome-specific entry in there; I ideally want this optimisation to work equally well in gnome, kde and xfce :\
<pitti> Good morning
<CynthiaG> I'm not that fond of coffee :) Thanks for the donuts and the x86 assembly, though! Careful, however, because I might want to optimise it with SSE2 :P
<CynthiaG> Good morning pitti
<pitti> lifeless: because we switched over to lp:ubuntu/pm-utils-powersave-policy and dropped the custom branch
<mneptok> CynthiaG: pfffft ... all the cool kids use PNI
<dholbach> good morning
<CynthiaG> mneptok: then I must not be a cool kid :) and AcronymFinder isn't helping much with this one
<hrw> morning
<lifeless> pitti: so the vcs-bzr line should say lp:ubuntu/pm-utils-powersave-policy
<lifeless> pitti: it *still has* a vcs location, doesn't it ?
<pitti> lifeless: but that's the implied default anyway?
<lifeless> pitti: not AFAIK
<lifeless> pitti: apt-get source looks at the header
<pitti> all packages are supposed to be available like that
<pitti> well, many aren't, but that's a bug, not by design
<lifeless> pitti: I know, but partner etc won't be
<pitti> right
<lifeless> pitti: was dropping the header discussed at UDS? I think this needs more thought if it wasn't.
<pitti> I don't think it was
<pitti> but for packages where we never had a custom branch and just started using the canonoical one we didn't add it either
<lifeless> pitti: I'm quite sure our toolchain doesn't default to lp:ubuntu
<pitti> apt-get source doesn't, right
<lifeless> pitti: could you raise this on ubuntu-devel/u-d-d, or would you like me to ?
<pitti> OTOH modifying all packages with a valid import to have a vcs-bzr: seems like a huge effort
<pitti> lifeless: sure, go ahead
<pitti> but there must be a better way than adding a canonical vcs-bzr everywhere
<pitti> unmodified packages have vcs-* from Debian, etc.
<pitti> it'd probably be more elegant if a branch could somehow be marked as "valid" or "being used" by a developer, and apt-get source could check that
<pitti> a lot of auto-imports are obsolete/broken, those wouldn't be marked then
<pitti> OTOH this could be automated as well
<pitti> debian/changelog first line -> match version on LP
<pitti> lifeless: FYI, for the particular case of pm-utils-p-p it doesn't really matter, the pacakge will be obsoleted by the next pm-utils upload
<pitti> cjwatson: WDYT about http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/casper/maverick/revision/817 ? please feel free to revert if you don't like it
<lifeless> pitti: well we can look at a script ;)
<lifeless> pitti: checkout; commit; done, for branch in lp:ubuntu/
<lifeless> pitti: and the unmodified vcs-bzr from Debian is a really interesting thing to consider.
<CynthiaG> not much improvement. should a 6-second improvement on boot over 2 minutes be pursued?
<pitti> CynthiaG: two minute boot time sounds like a bug on itself
<pitti> CynthiaG: I have the slowest possible hard disk on earth and it takes 50s for me (including logging into gdm and ecryptfs)
<CynthiaG> pitti: even despite the commonly-known weakness ... oh wait
<CynthiaG> you're talking about hard drives
<CynthiaG> I'm talking about the LiveCD itself
<pitti> ah, I see
<CynthiaG> "even despite the commonly-known weakness ... of CD drives when it comes to seeking"
<CynthiaG> boot is very noisy, even after changing the order of files around
<pitti> CynthiaG: 6 s> I'd say it depends on how much effort it is; a two-minute fix in one package sounds like worth it; reengineering 30 packages for it doesn't
<CynthiaG> pitti: it's about bug 589629, which I've been testing lately. It affects one file in livecd-rootfs, plus cjwatson's reordering of the squash file within the ISO so it falls to the end (edge) of the disc
<ubottu> Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
<mneptok> CynthiaG: PNI = Prescott New Instructions = SSE3
<CynthiaG> mneptok: Ah :) I knew SSE3, but not PNI
<mneptok> :)
<lool> doko_: Around?
<cjwatson> pitti: casper change is fine by me - wasn't there a bug report asking for that, in fact?
<pitti> cjwatson: I tried to look at https://edge.launchpad.net/ubuntu/+source/casper/+bugs?batch=300 but didn't spot it
<apw> can someone remind me which package had the volume key 'sticky-ness' work arounds in it
<ScottK> pitti: Would you please rescore kdebase-workspace kdeedu (only affects ia64)?
<cjwatson> apw: does the omap support in linux/maverick supersede the linux-ti-omap source package?  should we be removing linux-ti-omap from maverick, and rebuilding d-i against the omap flavour of linux?
<apw> cjwatson, i believe that to be correct yes, let me confirm with ogra
<pitti> ScottK: done
<apw> cjwatson, yes we should be dropping the separate omap source package in maverick
<Q-FUNK> doko_: so you feel that the real issue is with the eglibc build scripts then?
<Q-FUNK> doko_: the discussion on the FC bugzilla is convoluted, but did I uderstand this right that eglicb's build scripts are simply more efficient than average at passing optimization flags all the way down to GAS than most other libraries?
<pitti> cjwatson: ok, new langpack-locales with using archive and updated scripts uploaded; works fine here, let's see what breaks :)
<cjwatson> pitti: cool, thanks!
<buxy> cjwatson, seb128: http://lists.debian.org/1276511250.4912.18.camel@seb128-laptop
<seb128> buxy, ?
<buxy> do you know what kind changes are needed and if/when they can be done?
<seb128> buxy, the cdbs changes we have?
<buxy> you make it sound like a big blocker
<seb128> well, a reason for having diff over debian at least
<seb128> right know if works well with cdbs when gnome.mk is used
<seb128> because we modify the cdbs gnome.mk in ubuntu for what we need
<seb128> which means no source change to do
<seb128> but we can't do that with dh7
<seb128> there is no standard include we can change this way
<seb128> the code there basically do a few things like adding gettext domain to desktop entries
<seb128> or cleaning gconf schemas
<buxy> seb128: can you open some official launchpad bug and make sure someone is going to offer a solution for dh7 too?
<seb128> buxy, we have a workitems from UDS for this already
<seb128> so it's tracked
<seb128> I'm just not sure how we can solve that in an elegant way though
<buxy> "dh --with gnome"
<seb128> buxy, one issue I've there is that changing the packaging system is not required when you take something packaged from Ubuntu and upload to Debian
<seb128> buxy, well that would require having a sort of "gnome" debian would use for something yes
<seb128> then to modify that rules in ubuntu
<seb128> or to add a diff in ubuntu "--with gnome"
<buxy> seb128: even if only an empty placeholder in debian for a start, I think it's fine
<buxy> also I have submitted wishlist bugs against dh to be able to add new sequences without modifying the rules (just modifying the environment)
<seb128> ok
<buxy> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570935
<ubottu> Debian bug 570935 in debhelper "debhelper: possibility to enable an addon with an environment variable" [Wishlist,Open]
<buxy> seb128: can you give me a pointer to the work item in question?
<seb128> buxy, I don't find it now, I think it was in the desktop team workflow changes for maverick discussion we had which didn't get converted in a proper spec, I will have it filed today and give you the bug number
<buxy> seb128: thanks
<mdeslaur> hmm...while running lucid, "update-manager -d" doesn't give me the update to maverick button...does anyone know why that is?
<soren> win 8
<zul> mdeslaur: did you talk nicely to it?
<mdeslaur> soren: win 9, I win
<mdeslaur> zul: I whispered into it's ear
<pitti> hm, doesn't work here either
<pitti> I bet it's because mvo is on holiday
<cjwatson> I imagine it needs somebody to create an entry in the meta-release file
<cjwatson> (on changelogs.ubuntu.com)
<ogra> Keybuk, hey ... i recently get ureadahead OOM messages on boot with omap beagleboards (it boots fine otherwise and there isnt anything out of ram post-boot) any idea what that could be ?
<smoser> hi. i'm looking to pull in a new package 'ebsmount'.  it comes from turnkey linux, it has a (easily removable) dependency on "turnkey-pylib".
<smoser> i'd like to remove that dependency and have support from the upstream to do it (replacing it with code in ebsmount itself)
<smoser> mostly i just don't want to pull the package in. i'm wondering how dirty that seems to other people and if i should just bite the bullet and pull in both, and file both MIR eventually (as I want them into cloud utils)
<smoser> s/cloud utils/cloud images/
<Keybuk> ogra: yeah, the kernel picks on ureadahead sometimes
<hrw> hi
<qense> directhex: Could you take a look at bug #592706, if you have some spare time?
<ubottu> Launchpad bug 592706 in indicator-application (Ubuntu) "apps using the mono bindings fail to load" [High,Triaged] https://launchpad.net/bugs/592706
<directhex> qense, without looking in detail, it looks like the indicator-application C ABI has changed
<seif_> tedg, u there?
<seif_> i need u with indicator appler
<seif_> applet
<tedg> seif_, Yup.  What's up?
<seif_> hmmmmm
<seif_>  i need a custom applet
<pitti> mr_pouit: I'd like to package the current xfce4-power-manager (with upower support), and alongside this https://edge.launchpad.net/libxfce4ui (new requirement; I understand this supersedes the old libxfce4gui)
<tedg> seif_, Perhaps #ayatana is a better channel for that though.
<seif_> how do i do that
<seif_> ok
<pitti> mr_pouit: whom should I coordinate with for this?
<kees> pitti: I think 587055's eglibc version is going to collide with -security
<kees> pitti: or... i am confused and the bug title confused me
<mr_pouit> pitti: you want to package it for maverick?
<mr_pouit> pitti: anyway, there's already a package in the xubuntu-dev ppa. But it requires libxfce4ui, which is still a development release, so I would rather not put it in an ubuntu release
<akheron> I'm using cowbuilder-dist on karmic and trying to build a lucid package; the builder cannot install debhelper, what's wrong?
<akheron> is it not possible to build for newer ubuntu versions with cow/pbuilder-dist?
<Chipzz> smoser: I just googled ebsmount and looked at its page
<Chipzz> now while I don't know the implementation details
<Chipzz> that configfile is just... it smells like an fstab line, it quacks like an fstab line, but it's a configfile?
<Chipzz> pls tell me I shouldn't facepalm? :P
<smoser> config file ?
<smoser> ebsmount.conf is not a fstab entry, no.
<Chipzz> http://www.turnkeylinux.org/blog/ebsmount , Default configuration
<Chipzz> I know it's not
<Chipzz> but from how that config file looks, it sounds like it should be?
<smoser> the basic intent of the package is to take action on attach or detach of a volume
<smoser> its udev rules and then something that implements the hook.
<Chipzz> I know I should look at the source code first, but when I see sth like that I pre-emptively take out my biggest cluebat :P
<Chipzz> that just looks... horribly misguided
<smoser> thats reasonable, yeah.  but it is intended to provide "autorun" like function for EBS devices.
<smoser> i'm working with the upstream folks to  make it better.  and we're not opposed to input.
<Chipzz> wait, what?
<Chipzz> I looked over the biggest SNAFU it appears
<Chipzz> "Once a filesystem is mounted, EBSmount will execute scripts located in MOUNTPOINT/.ebsmount in alpha-numeric ordering."
<Chipzz> now I REALLY am going to facepalm
<Chipzz> "This provides a very powerful mechanism. In its simplest form, the user might want to symlink the mountpoint to a more accessible path, for example:"
 * Chipzz facepalms moar
<ion> Haha
<Chipzz> is. that. not. what. udev. is. supposed. to. do.
<Chipzz> ???????
<Chipzz> this makes me want to shoot ppl, and I haven't even looked at the source code yet
<Chipzz> so basically anyone with write-access to the root of that fs can root your system on the next reboot
<Chipzz> congrats, you just made yourself one hell of a security hole
<kees> that's ... not in Ubuntu, right?
<Chipzz> no, but smoser was proposing it
<Chipzz> smoser: pls note that having write access to the root of the fs is not unlikely (I'm guessing)
<Chipzz> since we're talking about EBS, it's very like you'll want to mount the partition as, say, /srv for your ftp daemon or apache
<cjwatson> kees: if you have a chance to review bug 582189, I'd really appreciate it; I'm pretty close to being blocked on it
<ubottu> Launchpad bug 582189 in libisofs (Ubuntu) "MIR: libisoburn, libisofs, libburn" [Undecided,New] https://launchpad.net/bugs/582189
<Chipzz> now assume your ftp daemon has a bug, you have sloppy permissions, ftp daemon gets exploited and dumps a file in that special dir
<Chipzz> next reboot you're rooted
<Chipzz> privilege escalation
<kees> cjwatson: yup, was going to do an MIR pass today
<cjwatson> thanks
<smoser> Chipzz, i had realized that that should be disabled by default.
<smoser> we'll have to address that somehow.
<smoser> regarding "thats what udev is for".. yes, there are udev rules that invoke the mount behavior. the package installs them.
<smoser> i completely understand your concerns. i'm interested in suggestions on how to make things safer, yet still provide some of that functionality.
<Chipzz> smoser: udev can create symlinks so you have stable device nodes to mount
<Chipzz> not sure how exactly ebs works, but it seems that's what should be done
<smoser> you're suggesting via udev ?
<smoser> the intent is largly to simplify that, and do something with no effort from the user.
<Chipzz> like I said, I don't know the exact implementation, but yes
<Chipzz> are you serious?
<Chipzz> you're proposing opening up a gigantic security hole for the sake of user convenience?
<Chipzz> this software is supposed to be installed on a server
<Chipzz> if you're administering a server, you're supposed to have some amount of clue
<Chipzz> "convenience" should be a non-issue
<smoser> i absolutely dont want to open a huge security hole.
<smoser> and agree, that as it is, it is open to exploit.
<ion> Personally, iâd rather have Upstart run the arbitrary set of commands i want to happen when a certain partition is mounted.
<smoser> that said the argument of "this is for a server, some things are difficult" is not valid.
<Chipzz> I'm not a udev expert, but may I suggest you talk to Keybuk? He can probably help you beat this piece of missoftware into a usable shape
<ion> start on mounted MOUNTPOINT=/foo, task, exec touch /foo/bar
<Chipzz> although from what I read on that page, you're probably better off starting from scratch
<Chipzz> not much to salvage I figure
<smoser> Chipzz, thanks for your input
<Chipzz> smoser: really, mount/fstab/udev provide all the pieces of the puzzle
<qense> upower detects brightness keys?
<smoser> i agree completely.
<Chipzz> it just seems upstream lacked the necessary insight and made a kludge of it
<smoser> there really isn't much there.  except a bit of config and udev rules written to call something.
<smoser> but saying the pieces provide all the functionality doesn't mean that its obvious how to put them together, and the upstream package intent is to put them together for easier use.
<smoser> ie, awk, ls, find provide all the functionality for 'du'.
<smoser> "upstream" is using those tools.
<Chipzz> and opening a gigantic security hole, and depending on python which probably isn't necessary at all, in the progress
<smoser> i hardly find "depending on python" to be a concern.
<Chipzz> it may be for debian
<Chipzz> where you can have a very minimal install without a lot of packages
<Chipzz> in case you would ever want to get this functionality into debian
<smoser> i find the security concerns more than reasonable, but i'm not teribly concerned aobut a python dependency.
<smoser> apt-cache show ubuntu-minimal | grep python
<smoser> i'm being serious, though, thank you for your input.
<Chipzz> yw
<Chipzz> (if depending on python is not a concern to you, maybe the extra package is. but you already mentioned it is :))
<ScottK> smoser: python isn't in minimal in Debian, so it is more of a concern there.
<Chipzz> btw, I think your comparison to du is the wrong way around :)
<Chipzz> smoser: that's exactly what what upstream is doing - implementing du on top of awk, ls, etc...
<smoser> thats what i was saying.
<smoser> that you were arguing "you have the tools to write 'du', why would you want to include that package itself"
<Chipzz> it should just depend on coreutils instead
<Chipzz> nevermind, enoughof this conversation already :)
<Chipzz> it's 9PM and I'm tired :)
<Janey0305> Do Yall know ubuntu?
<Chipzz> I think there's room for one last facepalm though ;P
<ion> Never heard.
<Janey0305> ubuntu/linux
<Janey0305> Nobody knows
<Janey0305> ?
<Chipzz> don't you mean gnu/ubuntu? :)
<ion> I donât think so.
 * Chipzz runs :)
<Janey0305> Well does anybody know a computer expert
<Janey0305> I can chat with
<Janey0305> FOR FREE!
<Janey0305> lol.
<Janey0305> cause I have a issue with sims 2
<Janey0305> and i really wanna play it
<Chipzz> yes, they're in #windows ;P
<Janey0305> but I cant
<Janey0305> where do I find that?
<Janey0305> im new on here
<Chipzz> Janey0305: this channel is about the development of ubuntu, it's not for user support
<Chipzz> for user support, if your question is even related to ubuntu, pls join #ubuntu
<dobey> anyone around that can do a quick REVU uh, review?
 * lamont needs the name of a package uploaded/synced to maverick in the last 2 hours, and doesn't want to dig through his email... anyone got a name?
<ion> Does http://blog.gmane.org/gmane.linux.ubuntu.devel.changes.maverick help?
<ScottK> lamont: https://launchpad.net/ubuntu/maverick/+source/userconfig/0.9.0-0ubuntu5
<lamont> yep. thanks all
<pygi> cjwatson, I would have really appreciated at least a poke on bugs like this:
<pygi> https://bugs.launchpad.net/ubuntu/+source/libisoburn/+bug/582189
<ubottu> Launchpad bug 582189 in libisofs (Ubuntu) "MIR: libisoburn, libisofs, libburn" [High,In progress]
<pygi> I know that you all laughed when I recommend those a few years ago, but yea....
<pygi> *sigh*
<pygi> I'd recommend communicating with upstream in the future if possible :-/
<JanC> pygi: that's not really a bug, but just a task/proposal to move those packages from universe to main inside ubuntu?
<pygi> JanC, yes, whatever you call it
<antonpiatek> Anyone know if there is a way to extract a single file from a source package (without unpacking the entire archive)?
<james_w> antonpiatek: there isn't really, as you may have to patch the file, overwrite it with one from elsewhere etc.
<james_w> it's not as easy as just poking inside an archive
<antonpiatek> james_w, thanks - thought it might be like that
<JanC> well, you can extract the unpatched file of course
<mathiaz> jcastro: hi!
<mathiaz> jcastro: working on bug 471468
<ubottu> Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/471468)
<mathiaz> jcastro: I've created and linked the bug to the upstream bug tracker
<mathiaz> jcastro: what do you recommend to set the Ubuntu bug status to?
<mathiaz> jcastro: Fix committed?
<jcastro> mathiaz: I would just leave it triaged until you sync next
<jcastro> you haven't really committed it to ubuntu per se
<mathiaz> jcastro: right - in that case it wouldn't be a sync since it's not reported to Debian, but rather the upstream tracker
<mathiaz> jcastro: right - i seem to recall that the desktop team was doing something similar
<jcastro> do you get it directly from upstream or from debian?
<mathiaz> jcastro: hm - what do you refer to by *it* ?
<jcastro> nagios I mean
<mathiaz> jcastro: ah - nagios is a package in debian
<mathiaz> jcastro: (is that what you meant?)
<jcastro> Do you get nagios from debian or do we package it directly from upstream?
<mathiaz> jcastro: we get nagios from Debian
<jcastro> right, so I think leaving the Ubuntu task "triaged" until the next time it gets synced from Debian that includes that fix makes the most sense
<jcastro> mathiaz: basically, how you have it now
<mathiaz> jcastro: ok - how do you unsubscribe the review team?
<mathiaz> jcastro: (since the patch has been reviewed)
<jcastro> mathiaz: I think only someone from the review team can unsub them
<mathiaz> jcastro: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
<mathiaz> jcastro: ^^ says to not unsubscribe the team
<jcastro> nigelb: what do we do now?
<jcastro> mathiaz: let's just ask him, heh
<mathiaz> jcastro: I've read https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
<mathiaz> jcastro: It seems clear to me what needs to be done
<mathiaz> bdmurray: hi
<mathiaz> bdmurray: is there an API in LP that lists the packages for which a team is a bug contact for?
<bdmurray> mathiaz: could you give me an example of a bug contact for a package?
<mathiaz> bdmurray: or screen scraping https://bugs.launchpad.net/~ubuntu-server/+packagebugs is still the only option?
<mathiaz> bdmurray: ubuntu-server is a bug contact for the apache2 (src) package
<mathiaz> bdmurray: I'm working on the following WI: Write script to automatically match ubuntu-server bug contact packagelist with ubuntu-server package set
<mathiaz> bdmurray: from https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-uds-seed-review
<mathiaz> bdmurray: the goal is to use the packagesset list as the list of bugs the ubuntu-server team should be a bug contact for
<mathiaz> bdmurray: may be (or may be not) LP should do that automatically
<mathiaz> bdmurray: but for now I'd like to write a script that does that semi-automatically
<bdmurray> mathiaz: if you had a list of packages I believe you could just use addBugSubscription for all of them and it would do the right thing wrt to subscribing you to new ones
<mathiaz> bdmurray: I can already get a list of packages (using the packagesets API)
<mathiaz> bdmurray: however I'd also like to prune the list
<mathiaz> bdmurray: ie remove packages that are *not* in the package set
<mathiaz> bdmurray: to do that I'd like to have the list of packages the ubuntu-server team is currently a bug contact for
<bdmurray> mathiaz: right, well you can't yet move from people to all of their subscriptions
<mathiaz> bdmurray: ok - I'll keep screen scraping https://bugs.launchpad.net/~ubuntu-server/+packagebugs
<mathiaz> bdmurray: is there a bug filed about adding such an API call?
<mathiaz> bdmurray: if not - where should I filed it?
<bdmurray> mathiaz: I'm looking
<bdmurray> mathiaz: I'm pretty sure bug 331039 covers it
<ubottu> Launchpad bug 331039 in Launchpad Bugs "packagebugs not being exposed through API" [Medium,Triaged] https://launchpad.net/bugs/331039
<mathiaz> bdmurray: agreed - thanks for the info!
<mathiaz> bdmurray: I've looked at https://bugs.edge.launchpad.net/~ubuntu-server/+patches
<mathiaz> bdmurray: this is really cool!
<mathiaz> bdmurray: how do you select the list of bugs?
<mathiaz> bdmurray: are you using the list of packages to which the team is a bug contact?
<bdmurray> mathiaz: yes
<mathiaz> bdmurray: \o/
<mathiaz> bdmurray: another reason to get the packageset synced with the bug contact packages
<ajmitch> hopefully exposing IPerson.getBugSubscriberPackages() is enough
<bdmurray> mathiaz: I'm not sure where the term 'bug contact' comes from.  I think of it a subscription to bugs about that package.
<CynthiaG> The bug contact for a package is the person or team which is automatically marked as subscribed to all bug mail about the package
<CynthiaG> Other people may be subscribed to bug mail, but the bug contact is always subscribed
<bdmurray> I don't believe there is a singular bug contact though
<CynthiaG> Well, different packages and Launchpad projects are going to have different bug contacts yeah
<bdmurray> For example https://edge.launchpad.net/ubuntu/+source/apache2 contains multiple bug subscriptions
<CynthiaG> None of those are the bug contact
<CynthiaG> Oh. Perhaps "bug supervisor" is meant here.
<CynthiaG> And "security contact", the person or team notified of private security-related bugs for the package
<CynthiaG> bdmurray, mathiaz: ^
<CynthiaG> Never mind, bug 331039 *is* about all subscribers to bugs for a certain package, not the "bug contact"
<ubottu> Launchpad bug 331039 in Launchpad Bugs "packagebugs not being exposed through API" [Medium,Triaged] https://launchpad.net/bugs/331039
<CynthiaG> +packagebugs, etc.
<CynthiaG> so for https://launchpad.net/ubuntu/+source/apache2 you would be scraping https://bugs.launchpad.net/ubuntu/+source/apache2/+packagebugs , since the API has nothing about this
<CynthiaG> no, wait. you'd be scraping /~USERNAME/+packagebugs
<ajmitch> the fix is to extend the API for it :)
<CynthiaG> I think there was just confusion over the term 'bug contact' though
<ajmitch> this started off at where we are, asking if there was an API equivalent of +packagebugs
<mathiaz> kees: hi!
<mathiaz> kees: do you have script or know of a lP page that given a source package gives the list of binary packages with their component (main, universe,...)?
<kees> mathiaz: I feel like you asked me this in the past.  :)
<kees> mathiaz: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/annotate/head:/security-tools/bin-details
<mathiaz> kees: great - thanks!
<kees> mathiaz: np :
<kees> )
<mneptok> the question so nice you ask it twice.
<kees> mneptok: heh.
<ajmitch> mathiaz: btw, I found there was a branch for that +packagebugs API issue created a few hours ago, so it might get into LP sometime :)
<mathiaz> ajmitch: right - I noticed that as well
<mathiaz> ajmitch: thanks for linking the branch to the bug
<ajmitch> np, I stumbled across it when figuring out how to implement it myself
#ubuntu-devel 2010-06-15
<akgraner> rickspencer3, ping - just wanted you to know - I went through the surveys from SELF yesterday - many of them mentioned your Quickly session as their highlight
<rickspencer3> akgraner, sweet
<akgraner> and I had people asking me day Saturday and Sunday about Dev and App Dev week
<akgraner> all day I meant
<akgraner> rickspencer3, Thank you again!
<mneptok> rickspencer3: see? pays to go shirtless and oiled when giving presentations.
 * rickspencer3 shudders
 * akgraner rolls my eyes at mneptok :-P
<mneptok> you rolled a 6. missed saving throw.
<akgraner> mneptok, I couldn't get that database to work you told me about - will you have some time tomorrow to help me trouble shoot it
<mneptok> akgraner: sure thang
<RoAkSoAx> away gone
<m3ga> i'm booting lucid on a tablet device. in windows the tablet has a working wifi device, but in ubuntu, neither lspci nor lsusb list anything that looks like a wifi device.
<m3ga> any clues as to what to look for?
<StevenK> m3ga: It could be a SD device?
<m3ga> StevenK: how would i figure that out?
<StevenK> I was still trying to work that one out
<m3ga> :-)
<ScottK> IIRC SD devices show up under USB.
<StevenK> I thought that depended on the USB HCD?
<ScottK> Could be.
<m3ga> StevenK: there is a wifi enable button on the side. i've messed with it but it still doesn't show up. maybe the button needs driver code to enable the chip before it can be listed with lspci.
<ScottK> m3ga: Did you boot with the button enabled?
<m3ga> since all the other hardware on this is intel, i suspect the wifi will also be intel
<ScottK> I've seen kernel issues with wifi switches were they didn't work if they weren't on at boot.
<TheMuso> m3ga: In windows, did you check in device manager how it connects? Devices can be viewed by how they are connected, available from the view menu.
<m3ga> its not a toggle button, just a momentary contact. i'll try booting while holding it down.
<m3ga> TheMuso: i know close to nothing about windows. completely baffles me :-)
<TheMuso> m3ga: Ok do you know how to get to device manager? If not, let me know what version of Windows you are using and I'm happy to talk you through how to open it.
<m3ga> holding the button while booting didn't help.
<m3ga> rebooting to windows (windows 7 btw TheMuso)
<TheMuso> m3ga: Ok, getting to device manager will be easy then.
<m3ga> it boots windows rrrreeeaaalllllyyyyyy slow
<TheMuso> heh
<m3ga> ok booted
<TheMuso> Ok, to get into device manager, simply open the start menu, and type device manager (if the device has a keyboard). If not, we will have to take a longer route
<TheMuso> If typign device manager is possible, you should see it appear as an option. You should be able to click on it to open it.
<m3ga> easy. have usb keyboard connected
<TheMuso> ah ok that helps.
<TheMuso> Once in device manager, open the view menu, and choose "view devices by connectin", I think thats what its called.
<TheMuso> Then its a matter of expanding the tree view to find the wifi device
<m3ga> wow, wireless is usb. "3DSP Wireless 802.11 B+G  Adaptor"
<TheMuso> and going back through the tree view to see how the device connects to the system.
<TheMuso> wow
<m3ga> ok, i can google that
<m3ga> some old stuff from 8:10 : http://ubuntuforums.org/showthread.php?t=1234213
<TheMuso> I have no idea at this point sorry, I just know that WIndows device manager can help in working out how a device connects.
<m3ga> thank Luke!
<TheMuso> np
<JanC> device manager can also show you the usb ids
<m3ga> ah yes, i should grab those
<Sarvatt> VID_05E1&PID_0100
<Sarvatt> according to google
<m3ga> Sarvatt: yes, confirmed
<Sarvatt> its a syntek device, found a manual http://www.stk.com.tw/driver/Wireless/STA-UI-A0037S_USB_User's_Manual.pdf
<Sarvatt> http://www.stk.com.tw/product-01.asp?Product_Type=58
<Sarvatt> lucid drivers there too, downloading to see what they are :)
<m3ga> Sarvatt: lspci output here http://pastebin.com/Uw9tRzsv
<m3ga> would like to get wifi and X working, but need lunch. back in an hour.
<nixternal> jcastro: forgot to say thanks in MI before closing out. stuck using a GUI IRC client right now :/
<ajmitch> nixternal: you've had some bad luck there
<nixternal> just a little
<nixternal> though, i have to admit..that server was a frankenstein box with components from the 90s
<ajmitch> held together with duct tape & prayers?
<nixternal> need to find a system that uses very little power to do what it did. all it was used for was IMAP/Mutt, Irssi, and my SSH gateway to my home
<nixternal> actually, held together with dust
<ajmitch> oh one of them - the type you should never try & clean
<nixternal> but my big puters bit the dust as well...now I am just a netbook luser :)  you can't do much with a netbook, except surf the intertubes
<micahg> nixternal: I might have a box that would work for that soon
<nixternal> micahg: yeah, a lil POS box is all I need. though I am thinking of a little crap box from tiger direct
<nixternal> $80
<nixternal> gotta love the community though. i forgot i had one of those donation buttons on my site..someone donated $50, but I refunded it. don't want to be that guy
<nixternal> damn, tiger direct doesn't have that lil $80 crap box anymore :/
<micahg> nixternal: well, I might be able to save you that if you can wait till the weekend
<zzcranjo> Hey all, I am looking to get into programming, specifically helping with the ubuntu devel process. What is the primary language that ubuntu is coded in? Sorry if these are stupid questions, but I have never tried programming before...
<jmarsden> zzcranjo: Ubuntu is programmed in many many languages.  As a beginner, maybe start with Python.  See http://wiki.python.org/moin/BeginnersGuide
<zzcranjo> thanks :D I am no stranger to python as I use blender quite frequently
<jmarsden> You're welcome.
<zzcranjo> So in theory, python can be used to program anything in ubuntu/linux? Is it optimised for certain types of programs?
<m3ga> zzcranjo: python is really only useful for user space programming. all the drivers and a large proportion of low level user space daemons are written in C.
<m3ga> all the kernel is also in C
<zzcranjo> ok. Thats ok as at first i would like to be able to see what i program :D
<m3ga> with a very small amount of assembler
<zzcranjo> ty
<hyperair> m3ga: there are some python daemons too.
<zzcranjo> Also, how easy is it to actually contribute source code to the ubuntu project? is it vetted by mods?
<m3ga> there are also some in ocaml and haskell, but most are written in C, followed by C++.
<m3ga> zzcranjo: best to submit to the upstream project rather than ubuntu.
<m3ga> ubuntu and debian prefer not to modify upstream sources too much. they figure that upstream knows their project better.
<zzcranjo> upstream?
<zzcranjo> (sorry, im new :D)
<m3ga> eg postfix is the mail daemon in ubuntu. the upstream project is http://www.postfix.org/
<zzcranjo> what is upstream? what does it mean?
<m3ga> similarly, for the samba server http://www.samba.org/
<zzcranjo> oh so upstream is just the different programs that come with ubuntu
<m3ga> upstream means the people who actually do the coding on that project
<zzcranjo> oh ok
<m3ga> yes.
<m3ga> ubuntu/canonical do some development work, but more than 90% of the distro has a separate upstream that is used by all the distros and freebsd and other unices
<zzcranjo> so once I get decent knowledge of python, I would be an upstream developer of whatever program I chose to make. Is there a filtering process to get into the sources like there is for itunes apps?
<m3ga> nowhere near as bad as apple.
<zzcranjo> thats good to know :D
<m3ga> most stuff that is in ubuntu is there because it is in debian. ubuntu packages are mostly just slightly tweaked debian packages.
<m3ga> as for debian, getting a package in is pretty easy as long as the license is ok.
<zzcranjo> ok
<m3ga> once its in debian, it will automatically show up in ubuntu some time later
<zzcranjo> So I license something how i want? I can choose whether it is proprietry, open source etc?
<zzcranjo> btw thanks for your help m3ga :D
<m3ga> open source license and it will almost certainly be accepted. some proprietary stuff is also accepted into debian's non-free section.
<m3ga> sorry, gotta go. back in an hour :-)
<zzcranjo> ty cya
<dholbach> good morning
<zzcranjo> good afternoon ;)
<pitti> Good morning
<pitti> mr_pouit: we need it for an OEM project, but yes, my intent was to package it for maverick and backport it from there
<pitti> kees: oh, will there be another security upload of eglibc?
<hyperair> m3ga, zzcranjo: *free* licenses will certainly be accepted. especially if it fulfils Debian's Free Software Guideline
<hyperair> zzcranjo: you can't go wrong with GPL ;-)
<zzcranjo> gpl is free, but closed source?
<hyperair> GPL is free and open source
<pitti> mr_pouit: oh, seems it's all done in the PPA already
<hyperair> zzcranjo: check out the DFSG, for the definition of "free"
<zzcranjo> dfsg?
<hyperair> Debian Free Software Guideline
<zzcranjo> oh ty
<hyperair> !dfsg
<zzcranjo> !dfsg
<hyperair> hmm damnit
<hyperair> there isn't anything
<zzcranjo> lol
<hyperair> well the first few things on google should be correct
<hyperair> wiki even
<hyperair> http://www.debian.org/social_contract
<zzcranjo> I actually have a vague recollection of something like that
<zzcranjo> ty will check it out
<ericm-afk> pitti, so far no response from ubuntu-sponsors for bug 427805, the bug is affecting many people actually, anything else I can help?
<ubottu> Launchpad bug 427805 in libusb (Ubuntu) "usb_find_devices() crashed with SIGSEGV in free()" [Medium,In progress] https://launchpad.net/bugs/427805
<hyperair> zzcranjo: there are some commonly used licenses in /usr/share/common-licenses/ which you might like to check out
<zzcranjo> ok ty
<zzcranjo> very sorry if this is not supposed to be in this room, but does anyone know how I can change how long notifications(music, empathy etc) stay on screen? Is it in ccsm?
<pitti> ericm: so there are three patches on that bug, and the first one changes autoconf all over the pplace
<pitti> ericm: what do I actually need to apply?
<ericm> the first one changes autoconf so that the legacy package can build
<pitti> ericm: and it breaks debian/control
<pitti> - libusb-dev
<pitti> + libusb-1.0-0-dev
<ericm> the 2nd one actually fixes the problem
<pitti> this is not libusb-1.0
<pitti> oh, the first one is the upower port
<pitti> nevermind
<ericm> pitti, Grrrr... that's not from me, so only the 2nd one please
<pitti> ericm: what's the third one? http://launchpadlibrarian.net/49434737/libusb.patch
<ericm> the 3rd one actually came from fedora mailinglist and seems to me it fixed some potential bug, but not this one
<ericm> so at this moment, only the 2nd one is significant
<pitti> alright, thanks
<ericm> the 3rd one tested to be no side effect so far at my side, should be a plus - but may not be suitable for a SRU
<pitti> ericm: ok, I'll sponsor the second one for now, and followed up upstream
<ericm> pitti, thanks man - a lot duplicated bugs and many mac users are affected
<ericm> strange enough - it seems so far to affect mac users only (who cares, :-)
<zyga> good morning
<hrw> morning
<ericm> pitti, another general question in my mind - as we don't actually maintain libusb-0.1, what's the process to deal with such fixes in the future? (to me it's easy way like subscribe ubuntu-sponsor, yet I'd like to know a bit more detail)
<pitti> that's pretty much it
<pitti> we just need to patch it on our own, but more importantly, port stuff over to -1.0
<pitti> ericm: uploaded to maverick; preparing lucid SRU now
<ericm> pitti, thanks, I'll try my best do it, that needs to be involved in upower upstream, and have that special usb device or something
<pitti> ericm: upower is already ported
<ericm> pitti, got you - so the best practice is to have a upower branch and get it tested and merged?
<pitti> I'll package it shortly
<zzcranjo> anyone know when gnome3/gnome-shell is going to be implemented in a release as the default gnome wm?
<ericm> pitti, thanks
<ericm> pitti, confusing - https://launchpad.net/upower - Upower is a next generation boot splash system for Linux
<hyperair> huh?
<hyperair> upower = bootsplash?
<hyperair> wasn't upower the devkit-power rename..
<pitti> it's most certainly not a splash :)
<pitti> the description would match plymouth
<hyperair> indeed
<hyperair> the website linked doesn't exist.
<hyperair> nanofreesoft.org, i mean
<pitti> oh, seems it was indeed a different project
<hyperair> Usermode graPhical pOWER.
 * hyperair facepalms
<hyperair> what kind of name is that?
<pitti> bah
<hyperair> there's no code either
<hyperair> it's just a project page with nothing on it
<ericm> hyperair, pitti, and interesting, a lot upowerd related bugs subscribe this upower as the source package, doh!
<hyperair> which is obviously wrong.
<hyperair> is there a way to unmark the link between this upower and upower in ubuntu?
<pitti> or rename this project..
<pitti> can someone poke #launchpad about this?
<ericm> bzr clone lp:upower
<ericm> bzr: ERROR: Invalid url supplied to transport: "lp:upower": upower has no default branch.
<hyperair> https://bugs.launchpad.net/upower/+bug/133181/comments/1
<ubottu> Launchpad bug 133181 in upower "Progress bar stall when turning on system" [Undecided,Won't fix]
<ericm> but the version number of this upower seems consistent with the one in my lucid system
<hyperair> take a look
<hyperair> upower's a dead project that has been merged into usplash and splashy
<dholbach> ericm: lp:ubuntu/upower
<ericm> https://launchpad.net/ubuntu/+source/upower/0.9.4-2, see packages built by this source
<ericm> dholbach, ah sorry
<dholbach> ericm: the difference is: "lp:upower" means "default trunk of an upstream project registered in launchpad"
<ericm> dholbach, I see
<dholbach> ericm: "lp:ubuntu/upower" means "source package branch of development release"
<ericm> dholbach, now it's fetching
<dholbach> ericm: in case you knew this already, ignore me :)
<ericm> dholbach, I pretended to know this already - since I was embarrassed :-)
<dholbach> haha, almost got away with it ;-)
 * dholbach hugs ericm
 * ericm has red face
<dholbach> it IS confusing
<ericm> so it really looks strange about this upower project - maybe just the title is incorrect and actually we reused the original dead project
<dholbach> I'm still waiting for the "bzr fix-bug 1234567" plugin :)
<ubottu> Error: Could not parse data returned by Launchpad: 1234567 (https://launchpad.net/bugs/1234567)
<dholbach> sorry ubottu
<ericm> hehe
<dholbach> the people in #launchpad would know how to reset it or change it if it'd make sense to change things now
<ericm> so far it looks like only the title is wrong, the cloned code is all right
 * ericm has to be offline for a while
<dholbach> alright
<ajmitch> dholbach: is that like the bzr do-magic-stuff plugin?
<dholbach> ajmitch: okâ¦ "bzr let-me-fix <bugnr>"
<ajmitch> so lookup the appropriate project/package, branch it, and present you with a nice working tree ready to fix stuff?
<dholbach> yeah, and maybe set the push location already
<dholbach> oh and "bzr pbuild" :)
<ajmitch> and maybe even fill in some of debian/changelog? we could dream, but I think you'd run into problems with multiple bug tasks for a bug #
<dholbach> yeah, that's right
<ajmitch> apart from that, it sounds possible
<dholbach> it could be reportbug-esque, check the list of open ubuntu tasks only that are not in progress or fix committed yet and present you with a list *shrug* :)
<dholbach> I could imagine that "bzr pbuild" would have more users :)
<ajmitch> so, got time to hack on it? :)
<ajmitch> by pbuild, do you mean using pbuilder from a bzr branch?
<dholbach> I should at least file a wishlist bug about bzr pbuild
<dholbach> yes
<ajmitch> I think that's possible with some magic at the moment
<dholbach> basically   bzr bd -- -S -us -uc && sudo pbuilder build ../<some dsc file that matches>    :)
<dholbach> (and for that I wouldn't care if the output is a native package or not)
<ajmitch> you can set the default builder command in the config, I think
 * ajmitch just has to find where he'd set that up
<dholbach> I think it'd be useful for people new to the process who want to fix their favourite bug and just bzr branch; <edit>; bzr pbuild; bzr commit; bzr push; bzr lp-open
<ajmitch> isn't groundcontrol meant to help with the same problems, just from a gui perspective?
<ajmitch> the main problem I've had this week with trying to fix stuff in bzr is the speed of getting branches from LP
<dholbach> yes, from a gui perspective, although I'm not sure how well it copes with source package branches and related stuff
<ajmitch> having bzr branch take > 3 hours was a bit painful, but apparantly the bzr launchpad plugin could support some mirroring, with some work on the plugin & the LP side
<dholbach> holy cow
<dholbach> how far's the lightweight checkout stuff?
<ajmitch> it was virtualbox-ose, it wasn't lightweight :)
<dholbach> I meant the bzr lightweight checkout stuff :)
<ajmitch> yeah I know, I didn't try it
 * ajmitch should check up on whether it's safe to do the virtualbox-ose merge
<ajmitch> though I don't know if it's updated to work as a guest with 2.6.35 & the version of X in maverick
 * cjwatson genuinely has no idea why pygi seems upset (in scrollback), and will take it to e-mail
<htorque> hello, can it be considered a bug that booting with an attached usb card reader (empty) moves the only internal hard disk from /dev/sda to /dev/sde? didn't happen with lucid.
<soren> htorque: Stuff like that is exactly why we boot based on UUID's.
<soren> htorque: Device names are non-deterministic. Don't rely on them.
<soren> htorque: In short, no, this is not likely to be considered a bug.
<htorque> soren: k, thanks
<soren> htorque: Sure.
<Nailor_> Hi. I'm running in problems with pbuilder. It's unable to install debhelper to my hardy chroot when building packages. I'm using Lucid
<pip> Hello, I can't share the swap partition of ubuntu with another linux distribution , I guess its due to the encryption reason of that swap
<hrw> btw - how much buildd power amd64 arch has?
<amitk> hrw: https://edge.launchpad.net/builders
<hrw> thx
<stvo> ping pitti
<lool> cjwatson: Pushed xdeb with a couple trivial tweaks from the testing I did this week-end, will you be in a position to NEW it, or should I make sure someone else does?
<cjwatson> lool: somebody else ought to do it since I've been heavily involved
<lool> Right, that's what I thought
<lool> james_w: Would that be something you would have the time to do?
<james_w> yes
<james_w> it's there now?
<james_w> (yes)
<james_w> lool: done. The description could use some love.
<lool> james_w: Thank you
<lool> james_w: http://paste.ubuntu.com/450072/
<lool> james_w: thanks!
<james_w> lool: better, thanks
<pitti> stvo: pong
<smoser> Riddell, around ?
<Riddell> smoser: afternoon
<smoser> :)
<smoser> so, ofr ebsmount, you think i probably need to get a new upstream tarball with more consitent file headers
<smoser> is that right?
<Riddell> smoser: yes, with files under a free licence and a full copy of the licence text included in the tar
<smoser> the debian/copyright file is in the original upstream tarball (and commited to their git repo) so it does seem reasonable.
<Riddell> smoser: I wouldn't be happy accepting it since it disagree with what the actual source files say
<smoser> yeah, thats fine.
<smoser> i agree, it should at least be consistent.
<buxy> seb128: did you find the time to file the dh7 enhancement request we discussed yesterday?
<seb128> buxy, not yet sorry but it's still on my todolist, I've only a bunch of items before it so I think I will get to it today
<buxy> great
<chrisccoulson> kees - are you there?
<kees> chrisccoulson: hello!
<chrisccoulson> hi kees. i'm just working on the firefox 3.6.4 update for karmic, and going through my packaging branch reviewing all of the changes that have flowed from lucid. one of these changes is the addition of hardening-wrapper as a build-depend
<chrisccoulson> is this something we want to keep in karmic?
<kees> chrisccoulson: yes, please.
<chrisccoulson> kees - ok, thanks
<kees> chrisccoulson: np.  let me know if it causes any problems (it shouldn't, though).
<psusi> ahh, kees, just the man to ask since you made this commit... I'm confused by http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/lvm2/maverick/revision/46
<psusi> it says merge from debian... so I would expect to see to parent commits... r45, and the debian branch that was pulled from... but that doesn't seem to be what is there...
<psusi> s/to/two
<kees> psusi: the bzr tree for lvm2 was unusable for a bzr-based merge.
<kees> psusi: I didn't do anything with the bzr tree as a result, because it was a total mess.
<psusi> so... what is this commit telling me?
<kees> psusi: lvm2 got upgraded in the past to an intermediate upstream (total fork from Debian), and then upstream merged devmapper into lvm2, so Debian followed that, so really it's 3 bzr trees into 1.
<psusi> it looks like it shows two parents, but I would expect one of them to be revision 45 and neither seems to be
<kees> I have no idea -- I didn't actually perform that commit.  I think it was automatic.
<psusi> weird
<kees> it was the nastiest merge I have ever done.  :)
<psusi> well, wherever you merged from, doesn't ONE of the parents have to be the previous revision?
<kees> anyway, based on the "Revision ID" you can see it was done as part of the bzr auto-sync (james.westby@...)
<cjwatson> those merge icons are just the merges from other branches
<cjwatson> r45 is implicit
<kees> psusi: nope, that's what I mean.  Ubuntu's version was totally different from Debian's, and Debian's was totally different from the Ubuntu fork point.
<psusi> ohh... ok.... so this is a merge that pulls from two other branches onto r45...
<cjwatson> probably one via the other
<psusi> ok... so if I want to see the history of the debian branch this merge pulled from, how do I do that?  I would expect that to happen if I click on the 3.1.8 squeeze link, but it doesn't seem to be what I get...
<cjwatson> psusi: the "Changes" tab at the top
<psusi> hrm... ok... I guess I actually am looking at the squeeze history... just through the looking glass of this branch... rather than looking at the branch that was pulled from...
<cjwatson> once a branch is merged, its full history is available in the branch it was merged into, with dotted revision numbers
<cjwatson> the web interface may not be the easiest way to get that level of detail though
<psusi> right... I see that now... was just confusing... I wanted to be looking at the other branch
<psusi> the other night I had tried updating to the latest upstream sources and most of the patches didn't apply... and most of them have no comment header describing what they were created for
<psusi> so now I'm trying to find where they were added in bzr and read the commit message...
<psusi> and am having a hell of a time
<ion> tseliot: It might be nice if the nvidia and fglrx packages had a dependency on xorg-video-abi-$n just like xserver-xorg-video-* have. If i were to get around to making a patch, would it be accepted?
<tseliot> ion: a dependency or something like Provides: xserver-xorg-video-6
<tseliot> ?
<tseliot> as nvidia does that already
<ion> A dependency. The drivers would block the upgrade of xorg which would introduce an ABI incompatibility until versions of the driver packages supporting the new xorg appear.
<pitti> it sohuld be a provides, not a depends
<pitti> the xorg server already conflicts to -video-6
<pitti> which DTRT
<ion> Ah, indeed.
<pitti> ion: in our setup, drivers Provides: the abi number and xorg depends on it
<pitti> kind of unintuitive and backwards, but I guess they had their reasons
<ion> So, only fglrx needs a change to provide xserver-xorg-video-$n.
<pitti> seems like it
<tseliot> yes, that would be easy to do
<hallyn> mathiaz: is there anything else i am supposed to do to re-request sponsoring for https://code.edge.launchpad.net/~serge-hallyn/ubuntu/maverick/qemu-kvm/update-to-12.4/  ?  (I dont' see any "feedback addressed" option by your previous feedback that I can hit)
<mathiaz> hallyn: if you go on the merge proposal page: https://code.edge.launchpad.net/~serge-hallyn/ubuntu/maverick/qemu-kvm/update-to-12.4/+merge/27293
<mathiaz> hallyn: on the left side you'll see a resubmit proposal link
<mathiaz> hallyn: I've also added kirkland as a reviewer
<hallyn> mathiaz: thought i'd hit that already...  but jsut hit it and it seemed to work - thanks
<hallyn> (thought i'd hit it 3 times!)
<hallyn> (glad i asked then)
<mdz> doko, lool, cjwatson: if there's more to talk about regarding the toolchain, we can do it here
<doko> mdz: could we do this later this week? running out of time today, and I'd like to get some performance data (benefits) on ix86. For now the test packages are available in https://edge.launchpad.net/~ubuntu-toolchain-r/+archive/ppa
<mdz> doko: sure
<geser> pitti: just reading the irclogs for the TB meeting: isn't !sru the factoid for the wiki page for SRUs? so reusing it for the panic button might trigger several false positives till everyone adapts to its new meaning
<maco> it changed?
<maco> so now how do we direct people to the wiki page?
<geser> maco: not yet
<maco> so at some point its going to sneak up on me? :(
<lool> james_w: Mind NEWing xdeb in binary NEW as well?  (sorry!)
<geser> maco: the is a plan to eventually change it (see the todays TB meeting logs)
 * maco hopes its at least being replaced. was a useful factoid
<pitti> geser: oh, it was just a strawman; we could call it !regression or !stable-alert or whatever
<hallyn> kirkland: regarding https://wiki.ubuntu.com/StableReleaseUpdates and bug #588293, should i actually butcher the original bug description to add that info, or is it ok to just add it in follow-on comments?
<ubottu> Launchpad bug 588293 in qemu-kvm (Ubuntu) "Memory leak" [Medium,Triaged] https://launchpad.net/bugs/588293
 * hallyn luvs bots
<geser> pitti: might be better unless you want to get pinged when someone wants to point somebody else to the SRU wiki page :)
<geser> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<geser> pitti: ^^ see
<maco> pitti: !omgsru
<komputes> Is anyone interested in repackaging blt with the patch on this Bug #359857 (it is currently unstable, last stable version was in hardy). Once patched and tested this would be proposed as an SRU in Lucid.
<ubottu> Launchpad bug 359857 in blt (Ubuntu) "blt does not work as currently packaged" [Undecided,New] https://launchpad.net/bugs/359857
<kirkland> hallyn: better to add it at the bottom of the bug description, you can enclose your section in ==== =====
<kirkland> hallyn: descriptions are editable, comments are not
<kirkland> hallyn: and it's not a big deal in small bugs like this, but some bugs have hundreds of comments, and the SRU notes can get lost eaisly
<hallyn> kirkland: will do thanks
<hallyn> (alas i built 64-bit packages but only have a 32-bit lucid install to test on, waiting for re-build :)
<hallyn> oh there we go
<hallyn> kirkland: is ubuntu-sponsors the right list to use for requesting merge review for the qemu-devel fix branch?
<kirkland> hallyn: yes, for stuff in universe
<kirkland> hallyn: sorry
<kirkland> hallyn: yes, for stuff in MAIN
<kirkland> hallyn: ubuntu-universe-sponsors for stuff in UNIVERSE
<hallyn> there's a separate 'ubuntu-sponsors-main'
<kirkland> oh, hm...
 * kirkland looks
<kirkland> hallyn: well, i'm not sure any more ... jcastro ?
<jcastro> kirkland: not sure
<jcastro> I thought sponsorship got merged?
<nixternal> https://edge.launchpad.net/~ubuntu-sponsors
<nixternal> the teams have been merged into one now
<nixternal> hallyn: ^^
<hallyn> nixternal: thanks
<hallyn> kirkland: thanks
<kirkland> nixternal: ah, cool, i forgot about that, i guess, thanks.
<nixternal> hehe, no problem
<zyga> does anyone remember a bzr command that would update the debian changelog in native packages in one shot?
<pitti> zyga: it's usually better to do it the other way round: edit debian/changelog and then use debcommit
<pitti> which will pull out the message, parse out the LP/debian bugs, and so on
<zyga> oh, debcommit
<zyga> that's what I was looking for, thanks
<pitti> zyga: and then dch -r/debcommit -r for an upload
<pitti> debcommit == â¥
<pitti> -r will tag, generate an appropriate message, and commit this as a "release"
 * mathiaz agrees with pitti 
 * zyga goes to read man and use it
<zyga> thanks guys
<apw> pitti, who would the right person be to talk to about a firewire stack change ?
<directhex> Keybuk is officially the best person ever (via twitter)
<pitti> apw: not sure actually; we don't integrate it very much in the UI, except for things like kino talking to cameras, and of course firewire based block devices (which won't change API-wise, I guess)
<apw> pitti, so if the kernel switches from old to new stack by default you don't see userspace exploding ?
<pitti> apw: some bits certainly will :)
<pitti> in particular, kino and friends used to talk to /dev/raw1394, i. e. might be sensitive to abi changes there
<pitti> but *shrug*
<apw> pitti, if we wanted to do that, is there anything other than telling ubuntu-devel@ (which we already have) that we should do ?
<pitti> awolfson: u-devel@ sounds fine to me
<ScottK-droid> pitti: would you please rescore kdepimlibs kdegraphics (only affects armel)
<pitti> ScottK-droid: nudged
<ScottK-droid> pitti: Thanks.
<mr_pouit> Riddell: "we sync automatically from debian"â¦ of course, I know that. The question is: when? I've some packages that are in unstable since around may 25 and are still not imported. And they won't probably be imported before thursday, and I'll have to do lots of paperwork after feature freezeâ¦ This is the reason why I filed the bug report, to be sure it would be synced!
<ScottK-droid> Thursday isn't feature freeze.
<Riddell> mr_pouit: it's a fair question, new syncs from debian are run manually and it's a fairly tedious process involving filtering out any packages we don't want
<Riddell> mr_pouit: do you have any examples of packages which should be synced but which aren't?
<mr_pouit> Riddell: e.g. parole, in unstable/testing
<mr_pouit> *g*, it has been synced this afternoon
<mr_pouit> okay, bad example :)
<Riddell> mr_pouit: see when I'm on archive duty, things happen :)
<mr_pouit> okay, okay ^_^
<james_w> lool: does the package follow the python policy?
<superm1> apw, could you also CC ubuntu-mythtv@l.u.c about the firewire stack change?  hopefully at least someone on there can help to test myth* userspace
<apw> superm1, thanks for the heads up
<lool> james_w: Python policy for xdeb, yes, it build-deps on the relevant stuff and ends up with the proper runtime deps; it has a ./usr/share/python-support/xdeb.private telling it about the private dirs too
<kirkland> slangasek: around?
<slangasek> kirkland: hi
<kirkland> slangasek: feel free to tell me to go away (or elsewhere)
<kirkland> slangasek: but I'm looking for someone with some knowledge of the Desktop Live seed, preferably who's online now :-)
<slangasek> ok
<kirkland> slangasek: so I'm trying to put together a UEC LiveISO seed
<kirkland> slangasek: so I started with the "live" seed, copied it to live-uec
<kirkland> slangasek: dropped all the langpack stuff, and ubiquity
<kirkland> slangasek: and now i'm trying to blacklist openoffice, games, video, graphics, sound, etc.
<kirkland> slangasek: i guess i was looking for any tips/pointers
<kirkland> slangasek: i'm sure i'm not doing it the most efficient way possible
<slangasek> you can't blacklist packages in seeds
<slangasek> seeds are whitelists by nature; the blacklist directive only lets you throw an error when something creeps in that you didn't want
<kirkland> slangasek: hmm, i was trying something like:
<kirkland> == Blacklist ==
<kirkland> libavcodec cannot be shipped on CDs (cf. Ubuntu technical board resolution 2007-01-02).
<kirkland>  * !libavcodec*
<slangasek> yes; all that does is cause an error *if* something pulls in libavcodec
<kirkland> slangasek: ah, bumemr
<kirkland> slangasek: okay ... hrm
<kirkland> slangasek: so would it be better for me to create my deal as a meta package in ubuntu-meta ?
<slangasek> ehm, the contents of those metapackages are entirely autogenerated from the seeds :)
<kirkland> slangasek: heh, okay ........
<kirkland> slangasek: okay, let's simplify the question ....
<kirkland> slangasek: let's say that I wanted to create a seed, call it live-uec, that is basically the same as the live desktop cd, except it removes openoffice-* and adds eucalyptus-*
<kirkland> slangasek: how would you recommend i go about doing that
<slangasek> for my part, I question whether it's really so important to keep these applications out of the live-uec seed
<slangasek> but, the way to do it is this:
<slangasek> - identify the bits that are common between your new seed and the existing one
<slangasek> - move those packages into a new seed
<slangasek> - restructure the 'live' seed to depend on the new seed
<slangasek> - create your new live-uec seed, also depending on this new common seed
<kirkland> slangasek: okay, thanks
<james_w> lool: well, I was meaning "should it install the modules in a public location?"
<kirkland> slangasek: okay, so i have what i think might be a reasonable seed ... is there a tool i can run (germinate or something) to see what all it will bring in?
<kirkland> slangasek: and ideally build an ISO locally?
<slangasek> germinate is packaged, yes
<slangasek> building an ISO> awkward to achieve for live CDs
<ScottK-droid> Would an buildd  admin please rescore kdebindings.
<slangasek> cjwatson: bug #594839> didn't you fix this already?
<ubottu> Launchpad bug 594839 in plymouth (Ubuntu) "Plymouthd SIGSEGV on Lucid Xen Instance" [Undecided,New] https://launchpad.net/bugs/594839
#ubuntu-devel 2010-06-16
<lool> james_w: I think not, these are not public python modules, just implementation details
<lool> james_w: It's not python-xdeb, but really just xdeb
<fqh> Hi, If I install OS from 10.10's daily build iso, it means that I get a latest 10.04?
<fqh> I install one system from 10.04's ISO, then it should be updated immediately. And I install another system from 10.04's iso,  then I will do the update work too. I want to get a latest 10.04's ISO directly.
<kirkland> slangasek: okay, i think i'll work on a monolithic file first, get that working, and then work on the seed separation into common components
<slangasek> fair enough
<cjwatson> fqh: um, no, if you install the OS from a 10.10 image then you get whatever state the thing that's to become 10.10 is currently in :-)
<fqh> cjwatson: Thanks, got it
<cjwatson> slangasek: maybe something kind of similar - doesn't look quite the same?
<cjwatson> ScottK: done
<slangasek> cjwatson: huh, ok; I thought this was one that was fixed already
<cjwatson> slangasek: I don't think I have any unsubmitted patches for plymouth at the moment
<cjwatson> slangasek: actually, it does look like one I have
<slangasek> oh; submitted upstream but not pushed to the package?
<cjwatson> slangasek: http://paste.ubuntu.com/450352/ is what's in my local tree and seems similar
<slangasek> cool
<cjwatson> may not be in the package yet
<cjwatson> yes, and that went upstream as c859e580a197a121bb5666fe2628b38ec88da9e4
<cjwatson> it was the day before 10.04 released so wasn't worth shoving in
<slangasek> right :)
<cjwatson> kirkland: it'd make my life so much easier if our qemu packaging matched Debian's a little more :-(  specifically, if there were a /usr/bin/qemu-system-i386 somewhere
<kirkland> cjwatson: understood, will be happy to comply
<cjwatson> want a bug?
<kirkland> cjwatson: hallyn should be owning qemu-kvm + libvirt this cycle, and I'll help out
<kirkland> cjwatson: yes, please
<cjwatson> mkay
<cjwatson> thanks
 * cjwatson patches grub2 in the meantime.  it could probably do with a configure check or something
<kirkland> cjwatson: we're hoping to get to basing qemu-kvm on debian
<kirkland> cjwatson: unfortunately, they didn't base their qemu-kvm package on ours
<kirkland> cjwatson: so there is a some diff
<kirkland> cjwatson: i gotta get to the bottom of that
<ScottK> cjwatson: Thanks.
<kirkland> cjwatson: i'd like to create a live-uec seed (per our discussion at UDS, and per a work item i have for Alpha2)
<kirkland> cjwatson: this is my first crack at it: http://paste.ubuntu.com/450355/
<kirkland> cjwatson: as slangasek suggested, i'd like to prune the commonalities between this one and the desktop one into a common seed
<kirkland> cjwatson: and then desktop could add openoffice, langpacks, multimedia, etc.
<kirkland> cjwatson: and this one would add eucalyptus-*
<cjwatson> I'd actually rather not have a common seed there
<cjwatson> I think it will wind up being kind of artificial and hard to maintain
<cjwatson> I know we do use common seeds in some places, but they work best when there's a clear concept of what they mean, and worst when they just exist to be a sort of set intersection and nothing else
<cjwatson> and I think this would end up being more of the latter
<cjwatson> I don't really see anything wrong with listing things explicitly here
<cjwatson> it would be pretty confusing for the desktop folks, because they'd need to know about what belongs on live-uec images in order to work out where to add packages, you see, and I don't think they should have to know that
<cjwatson> your approach seems OK, though I think there are some header tweaks that could stand to be made, like adding eucalyptus-simple-cluster or something to the Task-Key: list
<kirkland> cjwatson: okay, fair enough
<kirkland> cjwatson: can i push this in its current form, as an untested draft, safely to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.maverick/ ?
<kirkland> cjwatson: ie, will it automatically get "picked up" by anything?
<cjwatson> mm, best to use a private branch I think
<cjwatson> the archive works off that branch automatically
<kirkland> cjwatson: can do
<cjwatson> make sure to add an entry to STRUCTURE as well (and not at the end - put it in some place that sort of matches its depth in the dependency tere)
<kirkland> cjwatson: alright, so how do I "test" this?
<cjwatson> *tree
<cjwatson> man germinate, you can run it off a local directory quite easily
<cjwatson> the man page should be enough to work it out; if not, file a bug :-)
<kirkland> cjwatson: http://paste.ubuntu.com/450362/
<cjwatson> you'll get a pile of output files in the current directory, and you can look at the one called 'live-uec'
<kirkland> cjwatson: okay, i was toying with germinate
<cjwatson> that seems fine but how come it doesn't inherit from uec?
<cjwatson> oh, not quite fine
<cjwatson> you should also make some other seed (worst case, 'supported') inherit from live-uec, otherwise it's kind of orphaned and packages in it aren't guaranteed to be considered for main
<kirkland> cjwatson: good call, should inherit uec
<m3ga> Sarvatt: found a driver for the touchscreen of that tablet. its another crappy binary only driver, but if i can get it working in can snoop the usb and write a real driver.
<TheMuso> m3ga: Any luck with the wifi?
<m3ga> no, i'll tackle the wifi after i get the touchscreen working. it also has a crappy binary only driver that should be easy to reverse engineer by snooping the usb.
<TheMuso> ah ok.
<micahg> ScottK: is there a reason you're not in -motu?
<ScottK> micahg: Yes.  See the ubuntu-motu ML.
<micahg> ah, k, will check, sorry
<ScottK> No problem.
<micahg> ScottK: ah, can I ask you about something in here then that you previously discussed with me
<ScottK> micahg: Certainly.
<micahg> ScottK: k, do you remember discussing timeout with me?  apparently there's a buildd bug 594916 that seems to require a transitional package in timeout until it's fixed, what do you think?
<ubottu> Launchpad bug 594916 in Launchpad Auto Build System "buildd doesn't correctly check versioned ORed build-dependencies" [Undecided,New] https://launchpad.net/bugs/594916
 * ScottK looks
<ScottK> micahg: You didn't have a new enough coreutils on armel yet.
<ScottK> (you do now)
<ScottK> Versioned provides are unsupported (and that's a long standing issue).
<micahg> ScottK: in Lucid there isn't a high enough version
<ScottK> That error is on Lucid?
<micahg> ScottK: yes, the idea is to have one build for all versions
<micahg> that works with a transitional package for maverick for timeout
<micahg> or the versioned build deps
<ScottK> Where's your package?
<micahg> ScottK: this is for chromium: https://code.edge.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head
<ScottK> micahg: I don't see coreutils or timeout in http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/annotate/head:/debian/control
 * micahg wonders what happened
<micahg> ScottK: http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.beta/annotate/head:/debian/control
 * micahg had the wrong branch
<ScottK> Looking again
<ScottK> micahg: It's a bit late here, but I'd have thought that would work.
<micahg> ScottK: me too :)
<ScottK> Maybe wgrant has a suggestion.
<micahg> ScottK: thanks
<ScottK> No problem.
<ScottK> Wish I had a proper answer.  It's just been a while since I had to wrestle through one of these.
<micahg> ScottK: np, it might be a moot point now that I think about it, he wants to drop the test suite that requires the binary
<micahg> that's why it wasn't in .head
<wgrant> micahg: Can't you just flip it to 'timeout | coreutils (>= 8.0)'?
<micahg> wgrant: I think he tried it both ways
<micahg> wgrant: I think there's a bug in the buildd, bug 594916
<ubottu> Launchpad bug 594916 in Launchpad Auto Build System "buildd doesn't correctly check versioned ORed build-dependencies" [Undecided,New] https://launchpad.net/bugs/594916
<wgrant> There is a bug, yes.
<wgrant> It's been around for a long time.
<wgrant> But you should be able to work around it by swapping the disjuncts.
<micahg> wgrant: will pbuilder behave differently than the buildds
<wgrant> It depends on which resolution algorithm you configure pbuilder to use.
<wgrant> Launchpad uses a modified version of sbuilds from a few years ago.
<wgrant> Well, a modified version of DSA's sbuild-from-five-years-ago's algorithm.
<micahg> wgrant: what options do I need?
<wgrant> I haven't used pbuilder in a long time.
<wgrant> I'm not sure if it has anything comparable.
<wgrant> You could try uploading the other option to a PPA.
<micahg> wgrant: a better idea :), thanks
<lifeless> I can has sponsor ?
<lifeless> https://code.edge.launchpad.net/~lifeless/ubuntu/maverick/pyrex/fixdepends/+merge/27667
<lifeless> just a drive by, its trivial, and I'm about to forget it now ;)
<ScottK> lifeless: I'd do it if you'd give me a .dsc.
<lifeless> ScottK: what makes a dsc better for you?
<ScottK> dget foo.dsc gets me what I need without having to remember any UDD stuff I can never remember
<lifeless> if dget supported the url I pasted above, would you be happy?
<lifeless> (note that bzr does - bzr branch https://code.edge.launchpad.net/~lifeless/ubuntu/maverick/pyrex/fixdepends will get effectively the same thing a dsc would)
<lifeless> ScottK: ^
<ScottK> Probably, although the answer is slightly more complex as I usually apt-get source package first, then get the proposed package so I have them to diff and I know I have the tarball with the correct md5sum from the archive.
<ScottK> Obviously the diff is provided through the web U/I in this case.
<lifeless> ScottK: for reference, the same workflow in bzr is:
<lifeless> bzr branch lp:ubuntu/pyrex; cd pyrex
<ScottK> (and presumably I could bzr diff too, but that would require me to think)
<lifeless> bzr merge https://code.edge.launchpad.net/~lifeless/ubuntu/maverick/pyrex/fixdepends
<lifeless> I'd like to have this expressed in a CLI that you find easy to use
<ScottK> It's not at all clear from that URL, pulling the branch would get me a Debian format package.
<lifeless> ScottK: anything with /~person/ubuntu/... in the url gets you the debian packaging
<lifeless> unless folk are being silly, and if they are its up to us to show them where they can put there upstream branches; but you have to try pretty hard to accidentally put upstream source in the Ubuntu namespace
<ScottK> lifeless: What that branch doesn't get me is pyrex_0.9.8.5.orig.tar.gz
<lifeless> ScottK: bzr bd will make that on the fly
<ScottK> I need that from the archive if I'm going to have something up upload.
<lifeless> bzr bd -- -S
<lifeless> pristine-tar at work
<ScottK> Right, so the more fundamental answer to your question is that the branch is not as good as a .dsc until all the UDD stuff is easy enough to be usable for the casual user.
<lifeless> ScottK: the question is though, is it? Certainly with your deep experience of dsc-based-workflow, they are not comparable. But for someone with no particular experience at all, I'm not sure which is easier.
<ScottK> For someone with a deep investment in bzr stuff, the UDD stuff is probably easier.
<lifeless> ScottK: I think its totally fair to say that udd isn't as nice as .dsc's up until new users find udd easier; I'm not sure that comparing 6 or 10 years knowledge of one toolchain with a new one you haven't learnt yet is entirely effective
<ScottK> It depends on the case for comparing.
<ScottK> In this case you asked to get sponsored and so the fact that you asked in a way that makes it harder for me to help you is, IMO, entirely fair.
<lifeless> anyhow, even if udd was totally easier than dscs across the board, we can still make it easier.
<ScottK> The other point is that UDD stuff is Ubuntu specific, so if I'm going to move to it, it needs to have enough advantage to be worth me dealing with two workflows.  One for Debian and one for Ubuntu.
<ScottK> Obviously for people who only work in Ubuntu, that's not an issue.
<ScottK> lifeless: What is bzr bd short for?  I apparently don't have something installed.
<lifeless> bzr-builddeb
<lifeless> there is a bd-do
<lifeless> or bzr builddeb
<lifeless> phone just rang, bbiab
<ScottK> lifeless: What release are we on?
<lifeless> maverick
<lifeless> oh damn, lol - sorry
<ScottK> No problem.
<lifeless> thanks for sponsoring it
<ScottK> FWIW, I think the bzr builddeb interface needs to be much closer to the dpkg-buildpackage interface.
<ScottK> (There is a bug I filed on this)
<ScottK> I think the bit about before -- you're talking to bzr builddep and after the -- you're talking to dpkg-buildpackage business is full of fail.
<lifeless> yeah
<lifeless> its a bit awkward
<lifeless> bzr builddeb should do a small frontend perhaps
<slangasek> hmm; I find it better than any of the commandline interfaces to date for VCS dpkg-buildpackage wrappers
<lifeless> bzr-buildpackage, which can do the munging to bzr builddeb -- -S etc for you
<slangasek> e.g., svn-buildpackage
<ScottK> slangasek: For me bzr builddeb isn't competing with the other VCS wrappers, so that's interesting, but not germane.
<micahg> wgrant: no go: http://launchpadlibrarian.net/50412899/buildlog_ubuntu-lucid-i386.chromium-browser_5.0.375.70~r48679-0ubuntu4~ppa1_MANUALDEPWAIT.txt.gz
<slangasek> er, what's it competing with then?
<ScottK> dpkg-buildpackage
<ScottK> Or debuild
<slangasek> for completely VCSless package builds, then?
<ScottK> Yes.
<ScottK> "The old fashioned way"
<wgrant> micahg: That's, um, interesting.
<wgrant> There's something special here.
<wgrant> It normally works.
<micahg> wgrant: I filed a bug :)
<wgrant> I saw.
<wgrant> But I'll probably be the one to triage it...
<micahg> wgrant: k, let me know if I can do anything to help
<ScottK> slangasek: If UDD/No more source packages is going to get traction, IMO the tools need to be at worst no more complex/confusing that what they replace.
<slangasek> ScottK: I think UDD is sufficiently more powerful that it pays for a bit more complexity.  That doesn't mean it shouldn't be as simple as possible, of course
<ScottK> slangasek: I think that's true for full time developers.  For people who use the tools more occasionally, it's much less so.
<RAOF> Could I get someone to accept the Lucid task on bug #563100?  This has a small, upstream patch for a serious usability problem with some dual-screen setups.
<ubottu> Launchpad bug 563100 in xorg-server (Ubuntu) "Mouse movement corrupted with Xinerama enabled" [Medium,Fix released] https://launchpad.net/bugs/563100
<ScottK> RAOF: done.
<dholbach> good morning
<RAOF> ScottK: Thanks muchly!
<pitti> Good morning
<ddecator> morning pitti
<james_w> ScottK: fwiw I've been working on your bug, it's just a pain as the debuild/dpkg-buildpackage interface is so arcane
<james_w> I agree with the principle though, so I'll get there
<tseliot> cjwatson: can you approve my upload of xorg-server in lucid-proposed, please? (LP: #563100)
 * maxb wonders why the ubuntu-mozilla-security PPA is building langpacks
<pitti> maxb: it has a major new ffox version and thus also needs the new ffox translations
<maxb> aha! :-)
<asac> i remember vaguely that we had some magic that replaces duplicated files in /usr/share/doc or something with sym links to safe space. does that ring a bell? is that just on CD or are we doing that in some package helper for all packages?
<cjwatson> it's only in cdbs
<asac> ah
<seb128> buxy, hi
<seb128> buxy, I've opened bug #595008 and assigned it to our desktop team
<ubottu> Launchpad bug 595008 in debhelper (Ubuntu) "should port the Ubuntu cdbs custom rules to dh7" [Wishlist,New] https://launchpad.net/bugs/595008
<cjwatson> tseliot: done
<Laney> Does the SRU team need more manpower? Stuff seems to be stalling in the queue
<cjwatson> yes
<cjwatson> pitti is off doing other things this cycle and it shows
<pitti> well, I still do some SRU bits, but I can only do so much
<tseliot> cjwatson: thanks a lot
<ScottK> james_w: Thanks.  I can understand it's not easy.
<james_w> ScottK: tedious rather than tough. Explaining that "-s can take one of a d or n" when building a source package, or other things when building a binary, and explaining what the letters mean takes time.
<Laney> cjwatson: Perhaps you should call for one or two more members on u-d@?
<james_w> ScottK: I'd like to provide a good interface for those that haven't got years of experience either.
<buxy> seb128: thanks
<didrocks> cjwatson: I have also three SRU waiting for being accepted (f-spot, empathy, quickly), when you get some time to approve themâ¦
<ScottK> james_w: Also reasonable.
<siretart> is someone already working on getting libvpx promoted to main?
<siretart> I've just uploaded ffmpeg 0.6 to maverick, and I think it would be a real shame to miss VP8 support in main.
<seb128> siretart, I don't think so no
<seb128> siretart, you are welcome to write a mir for it though
<seb128> cjwatson, hey, just pointing bug #595008 in case you are interested to subscribe, it might lead to debhelper ubuntu diffs and I think you spoke against doing that before
<ubottu> Launchpad bug 595008 in debhelper (Ubuntu) "should port the Ubuntu cdbs custom rules to dh7" [Wishlist,New] https://launchpad.net/bugs/595008
<siretart> seb128: I've already spent more time than I actually should have to get 0.6 released upstream and packaged, so I'd really appreciate if someone could pick that up. otherwise I'd see to find some time to do so this week
<cjwatson> joeyh tends to have a go at us when we do anything substantial.  please consult explicitly with him
<siretart> cjwatson: small ping on the libfaac issue?
<cjwatson> if it's done with his involvement and consent then I don't need to worry
<cjwatson> siretart: you can ping, but I have no time at the moment for it, sorry :-(
<siretart> ok
<cjwatson> it's still somewhere on my list
<siretart> no problem, just wanted to check
<seb128> cjwatson, ok, buxy is sort of helping to reach something which work fore debian and us there so I guess we should stay on track, I was just pointing it in case you were interested by the changes or commenting
<cjwatson> surely file a Debian bug
<seb128> cjwatson, thanks
<cjwatson> the only thing I'm worried about is stripping upstream changelogs for *everything*; that seems overkill and I hope we can come up with something better than that
<seb128> siretart, ok, I will see if we can find somebody interested, I first want to debug why totem is not able to play lot of formats starting with avi in maverick
<seb128> cjwatson, right...
<siretart> seb128: just a guess in the blue, try rebuilding gst-ffmpeg against the (new) system ffmpeg 0.6, or against it's internal ffmpeg copy
<seb128> siretart, ok, will do, thanks
<SpamapS> james_w: ping
<james_w> hi SpamapS
<james_w> how's it going?
<SpamapS> james_w: quite well thanks. :) so.. libmemcached2
<SpamapS> james_w: I'm not sure if there's been a discussion that I missed out on regarding libmemcached ... but this is pretty important for one of my alpha2 specs.
<SpamapS> <-- clint-fewbar  ;)
<james_w> SpamapS: no discussion, just standard practice
<james_w> libmemcached2 is "obsolete", not built from any source package any more, and so a maintainence pain. We try to have everything use the same version of a library by release
<SpamapS> james_w: Right.. long term we want to stamp it out and kill it.. but the API was in absolute upheaval during 2009 and has only stabilized the last 6 months.. many upstreams haven't had time or even reason to update to 0.40's massively incompatible API
<james_w> if something needs an old SONAME, and can't be ported then an acceptable interim solution is to reupload the old source with a new name to provide the old SONAME.
<james_w> it's preferred to port everything though.
<SpamapS> yes, at issue is the language bindings..
<SpamapS> its easy to port gearman-job-server.. I will probably do that myself as I've contributed code to it in the past.
<SpamapS> but the perl bindings, for instance, just don't implement any of the 40+ new functions and implement the old ones dead wrong.. its going to take time. :-/
<SpamapS> also we can at least draw a line in the sand and say *only* v0.31 will be used, since it is in lucid..
<SpamapS> and its probably reasonable to suggest that it will be dropped after 11.04
<SpamapS> james_w: ok so I think I understand. :)
<james_w> SpamapS: good :-)
<james_w> SpamapS: do you have any idea if Replaces should be used?
<SpamapS> james_w: not sure if you saw my "please fork" bug... I've been working with Monty Taylor on it.
<james_w> SpamapS: I haven't, bug against what?
<SpamapS> james_w: libmemcached
<SpamapS> james_w: its just a bug to do what you're talking about.. upload the old version
<james_w> SpamapS: great, thanks for your efforts
<SpamapS> james_w: I figured Replaces makes more sense than Conflicts as it will eventually lead to the removal without automatic removal... but I do like the idea that a simpler control file could be used w/o replaces all over the place.
<apw> pitti, has somethign changes with apport such that ubuntu-bug alsa-driver now reports no such package even though there is such a package in the archive?
<SpamapS> james_w: libmemcachedutil0 would need it as they do have files that are the same, and its ok for the new version to replace the old one.
<james_w> SpamapS: well, you don't want removal :-)
<james_w> SpamapS: yes, that's a case for Conflicts/Replaces, but if they are co-installable and you want both to be installed then I think just removing Conflicts is enough
<SpamapS> james_w: right, I'll give it another look and see if we can't make the control file a bit leaner. :)
<SpamapS> james_w: thanks!
<james_w> SpamapS: great, thanks
<pitti> apw: alsa-driver doesn't exist
<pitti> apw: ubuntu-bug works with binary packages, not source packages
<apw> pitti, so what do the package_hooks for source_* do ?
<pitti> apw: they apply to any binary of that source
<apw> pitti, ahh ok
<apw> i must have missreembered
<lianj_> hello, where should i report a typo of the get-ubuntu/download website?
<jpds> lianj_: launchpad.net/ubuntu-website-content/+filebug
<dholbach> lianj_: https://launchpad.net/ubuntu-website/+filebug
<dholbach> oh, sorry, maybe jpds is right
<lianj_> nice thx! the mac's "iso to usb stick cmd help-text is wrong"..
<lianj_> can someone logged in to launchpad please report this?  i only care because i told someone to install ubuntu and follow the instruction on your site, now he still calls me ;)
<lianj_> its the hdiutil command of the mac help on get-ubuntu/download. it must be "hdiutil convert -format UDRW" instead of "hdiutil convert-format UDRW"
<lianj_> its tiny but beginners might have a hard time to figure it out.. :)
<jdstrand> dholbach: hey, how does one use harvest these days (wiki page is fine)? I go to http://daniel.holba.ch/harvest/ and it tells me it is offline
<lianj_> bye
<dholbach> jdstrand: it's offline, we're working very hard to get the new version online
<jdstrand> dholbach: k, thanks
<dholbach> jdstrand: do you need the fedora patch list?
<jdstrand> dholbach: yes, for libvirt
<pitti> jdstrand: http://cvs.fedoraproject.org/viewvc/devel/libvirt/ FYI
<pitti> looks like they don't have any?
 * Daviey *sobs*
 * dholbach hugs Daviey
<Daviey> \o/
<jdstrand> pitti: yeah, I see that. guess I am on my own then :)
<jdstrand> pitti: thanks
<hrw> hi
<Keybuk> oh, right, something wants to read a file off disk ... so now Linux has to slow to a crawl and all my apps have to go B&W
<Keybuk> *sigh*
<Keybuk> most interestingly, it's not just reading off disk - reading from NFS has the exact same effect on the system
<tseliot> hardware failure?
<apw> Keybuk, which kernel is that ?
<Keybuk> apw: the Linux kernel ;-)
<Keybuk> I've never yet encountered a Linux kernel that doesn't behave this way
<apw> Keybuk, i think i'll ignore you
<apw> :)
<Keybuk> all 2.6 versions do
<apw> Keybuk, think i've found that bug with init=
<apw> very subtle ... just about to test ... if it works i'll get you and updated kernel
<Keybuk> apw: kk, what was it?
<apw> a subtlty with left and right of an &&, ie no longer executing code for obselete parameters
<Keybuk> Don't feel too bad though, empirical testing suggests that Mac OS X's kernel suffers from the exact same problem
<apw> which init= is one of
<Keybuk> (just Google for "mdworker" to see)
<apw> heh nice
<Keybuk> and Windows' kernel can't move the mouse and multi-task, let alone do I/O :p
<apw> heheh its still a bit shit
<Chipzz> Keybuk: I've heard great things about this thing called Windows... ;P
 * Chipzz runs
<apw> Chipzz, thats called marketing
<Keybuk> apw: I assume that it's something to do with all I/O calls still being fundamentally blocking - and I/O being prioritised highly
<apw> Keybuk, there is some stuff about cfq being utterly broken since 2.6.27 which isn't helping
<ogra_cmpc> Keybuk, do you have any idea why ureadahead and plymouthd would OOM on boot ?
<ogra_cmpc> (i also have seen it for ureadahead only)
<ion> Souldnât /etc/init/procps.conf call sysctl with -e? procps postinst failed while i happened to be running an older kernel that didnât have one of the variables, kernel.ptrace_scope i think.
<Keybuk> ogra_cmpc: the kernel likes to pick on ureadahead
<ogra_cmpc> hmm, k
 * cjwatson wonders if ureadahead should be oom_adjusted, or if that would just result in real unkillable out-of-memory sometimes
<Keybuk> cjwatson: dunno; in theory the memory is shared between apps
<Keybuk> ureadahead will only open a file that was read in during boot
<Keybuk> though that can result it in loading files which have since been closed
<Keybuk> and you don't want the kernel OOM killing something else
<Keybuk> if anything, ureadahead should be the *first* choice of OOM
<cjwatson> mm, true
<cjwatson> maybe we should just hide the evidence if that happens
<mathiaz> cjwatson: hi
<mathiaz> cjwatson: I was wondering how the ubuntu-server package set was generated?
<mathiaz> cjwatson: is it generated from the seeds?
<mathiaz> cjwatson: or is there something else involved in the selection of packages to be included there?
<cjwatson> mathiaz: yes, it's from the expansion of these seeds: platform/supported-misc-servers platform/supported-server ubuntu/dns-server ubuntu/lamp-server ubuntu/openssh-server ubuntu/print-server ubuntu/samba-server ubuntu/postgresql-server ubuntu/mail-server ubuntu/tomcat-server ubuntu/virt-host ubuntu/eucalyptus-cloud ubuntu/eucalyptus-walrus ubuntu/eucalyptus-cluster ubuntu/eucalyptus-storage ubuntu/eucalyptus-simple-cluster ...
<cjwatson> ... ubuntu/eucalyptus-node ubuntu/server ubuntu/server-ship ubuntu/uec
<cjwatson> minus whatever's in "core", below it
<mathiaz> cjwatson: ok - so to add a package to the package set it just need to be added to one of the seed?
<mathiaz> cjwatson: I was working on the ubuntu-server package and noticed that apache2 (for ex) wasn't included
<mathiaz> cjwatson: yet apache2 is in server-ship
<mathiaz> cjwatson: or lamp-server
<cjwatson> mathiaz: apache2 is (correctly) in core
<mathiaz> cjwatson: would it make sense to have *also* included in ubuntu-server?
<cjwatson> actually wait, let me check that
<cjwatson> no, it would not.  packages that are in core are never in other sets
<cjwatson> that's a fixed rule, much like packages that are in main aren't also in universe
<mathiaz> cjwatson: what's the reason for including in the core set then?
<cjwatson> it's hideously deep in everything's build-dependency tree
<cjwatson> I'm just trying to trace it
<mathiaz> cjwatson: that would also explain why mysql is not in the ubuntu-server package set
<mathiaz> cjwatson: given that a lot of packages in core are linked against libmysqlclient
<cjwatson> one path is apache2 <- subversion <- tcltk-defaults <- xapian-bindings <- apt-xapian-index <- ...
<cjwatson> yes - the design is that if you get upload access to ubuntu-server then you shouldn't be able to cause serious damage to things other than server
 * mathiaz nods
<cjwatson> and people good enough to upload the stuff that's way down in build-dependency webs should probably be core-devs anyway
<mathiaz> cjwatson: is core self-contained?
<cjwatson> yes
<mathiaz> cjwatson: so core-dev isn't going away with the archive reorg?
<cjwatson> no
<mathiaz> cjwatson: core-dev will have upload privileges to core?
<cjwatson> yes
<cjwatson> s/will have/does/
<cjwatson> well, we did make some explicit exceptions for certain core desktop packages because the people who were in practice maintaining those weren't core-dev and it seemed to make better sense that way, e.g. kdebase -> kubuntu
<mathiaz> cjwatson: ok - there are always exception
<mathiaz> cjwatson: anyway - thanks for the explanation
<cjwatson> we can consider exceptions for server in some cases, but I think I would have to ask that there should be a history of people who aren't core-dev but are in ubuntu-server competently maintaining the packages in question
<mathiaz> cjwatson: oh - where/how did you track the apache2 dependency?
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.maverick/rdepends/apache2/
<cjwatson> plus
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.maverick/boot.build-depends (one file where I noticed apache2 showing up)
<mathiaz> cjwatson: ok - where is the mapping of ubuntu-server package set <-> list of seed defined?
<cjwatson> in code you probably can't see, sorry
<cjwatson> I need to push it somewhere sensible
<mathiaz> cjwatson: ok - thanks for the help :)
<cjwatson> you might find it on chinstrap:~cjwatson/packageset/
<cjwatson> (bzr branch)
<cjwatson> try not to be too violently ill, the intent was always to disassemble that and move the bits somewhere else
<gumis> I need invite to demonoid.com
<Pici> gumis: That is not on-topic for either this or any Ubuntu channel.
<cjwatson> gumis: you are off-topic for this channel
<mathiaz> cjwatson: while upgrading grub-pc on maverick I get a prompt about grub not being installed on any hard drive (or something like that)
<ogra> omg, the merge from hell ...
<ogra> cjwatson, wow how long did initramfs-tools take you ? :)
<mathiaz> cjwatson: afterward while trying to upgrade linux-virtual I ran into that error: http://paste.ubuntu.com/450674/
<cjwatson> mathiaz: second one being fixed at the moment
<mathiaz> cjwatson: ok
<cjwatson> mathiaz: the previous one isn't new, it's been around in lucid and I haven't dared to change the code yet, but I'll be rewriting all of that :-/
<cjwatson> ogra: about two days, on and off
<mathiaz> cjwatson: ok - selecting no wasn't working
<mathiaz> cjwatson: so I had to select yes (ie not install grub) to move on
<cjwatson> mathiaz: right, that's one of the known problems
<mathiaz> cjwatson: great - I won't report any bug then
<cjwatson> the loop logic is wrong, it incorporates upgrade logic each time round which fails after the first time
<cjwatson> make sure that, ultimately, you've run grub-install somewhere.  grub-pc/install_devices shouldn't be blank, unless you have a really special case
<mathiaz> cjwatson: right - the system is a vm and was already running before (ie grub was installed)
<cjwatson> mathiaz: you can get past the second error by applying http://paste.ubuntu.com/450678/ to /usr/sbin/grub-mkconfig
<cjwatson> mathiaz: that doesn't follow - the interface between grub2's core and its configuration file is not yet stable, so you have to configure things such that grub-install is run on each upgrade
<mathiaz> cjwatson: oh ok
<cjwatson> mathiaz: otherwise, you are practically guaranteed to have very confusing problems sooner or later, which won't be fixable any other way than running grub-install, so you might as welll
<cjwatson> *well
<cjwatson> it's suboptimal but so are all the alternatives
<mathiaz> cjwatson: great - applied the patch above - and the linux-virtual upgrade proceeded correctly
<mathiaz> cjwatson: and I ran grub-install manually afterwards
<cjwatson> mathiaz: ok, I suggest also running   dpkg-reconfigure grub-pc   to get the auto-install configuration set up properly
<cjwatson> ogasawara: heads-up on bug 595178, you're probably going to see a few dups of that while my fix percolates through the buildds
<ubottu> Launchpad bug 595178 in grub2 (Ubuntu) "package linux-image-2.6.35-2-generic 2.6.35-2.3 failed to install/upgrade: subproces installed post-installation script gaf een foutwaarde 1 terug" [High,Fix released] https://launchpad.net/bugs/595178
<ogasawara> cjwatson: ack, thanks
<cjwatson> the "Invalid parameter, 2.6.35-2-generic" bit in the dpkg terminal log is the relevant one
<ogasawara> JFo: ^^ fyi
<cjwatson> upstream patch that snuck in without my noticing
<smoser> Riddell, if your around, could you review ebsmount 0.92 upload ?
<Riddell> smoser: k
<smoser> thank you.
<apw> can anyone tell me what update-manager uses under the covers to download things?  it seems to be avoiding the apt proxy configuration
<slangasek> apw: it uses python-apt; apt proxy configuration is a known headache; there are specs about this in the past couple of cycles
<apw> slangasek, hrm, another reason to avoid it ... and there i was trying to be a real user
<slangasek> apw: there may already be a known solution, I'm not sure
<slangasek> I have no proxy
 * apw uses an apt-cacher ... saves me hours
<slangasek> I just have a local mirror :)
<apw> slangasek, thats just sooo expensive to maintain compaired to the ammount of it i need
<apw> Keybuk, http://people.canonical.com/~apw/init-all-params-maverick/  <-- replacement kernels are uploading to there as we speak, should be about another 10 mins before you have the i386 kernel
<Keybuk> okies thanks
<debfx> kirkland: hi, could you please have a look at this qemu-kvm patch for the upstart job: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/292588/comments/40
<ubottu> Launchpad bug 292588 in virtualbox-ose (Ubuntu) "VirtualBox can't operate in VMX root mode." [Medium,Triaged]
<BlackZ> debfx: I think the channel #ubuntu-reviews would be the most appropiate for the patch review
<SpamapS> get-orig-source did not create pylibmc_1.1.1.orig.tar.lzma
<SpamapS> anybody familiar with bzr-buildpackage know why its looking for .tar.lzma?!
<slangasek> SpamapS: it doesn't normally do that.  Is there some reference to lzma compression under debian/source?
<SpamapS> slangasek: this particular package has no source directory
<slangasek> SpamapS: then it sounds like a bug - but not one that I see with the bzr-builddeb package in the archive
<SpamapS> this is on 2.4.2, running on maverick
<ari-tczew> when is planning the next sync-work by archive admins?
<seb128> ari-tczew, there is no schedule for this, next time an archive admin has a free slot to do it usually
<ari-tczew> aha ok
<seb128> ari-tczew, syncs are done every few days usually
<seb128> is there anything you specifically need?
<ari-tczew> seb128: not specifically, just wonder of using syncpackage by sponsors on have got sync-in-launchpad. quick response!
<mathiaz> bdmurray: is there a way to subscribe a team to a source package via the API?
<ajmitch> mathiaz: addBugSubscription should accept a team, I think
<mathiaz> ajmitch: and how do I get the Launchpad Structure from a source package?
<ajmitch> it ought to have it, let me tinker for a minute & see if I can do it
<mathiaz> ajmitch: oh you're right
<mathiaz> ajmitch: there is an addBugSubscription on a src package object
<cjwatson> based on Debian bugs, latest grub2 in maverick may be broken if you have root on LVM
<cjwatson> so just a warning ...
<cjwatson> have started investigation but it will take a while
<ajmitch> mathiaz: hello.addBugSubscription( subscriber=launchpad.me )
<ajmitch> where 'hello' is a source package, it seems to have worked for me
<mathiaz> ajmitch: right - now do I have to check if the team is already subscribed to the package?
<mathiaz> ajmitch: it seems that this is not possible yet (as we've already discussed something similar)
<ajmitch> I don't think so, it doesn't fail if I run it again
<mathiaz> ajmitch: what are the getSubscription(s) methods supposed to doÃ
<mathiaz> ajmitch: ?
<mathiaz> ajmitch: calling them doesn't return anything
<mathiaz> ajmitch: I would have hoped it would return the list of people subscribed to bugs for a package)
<ajmitch> it returns the subscription, you can get the subscriber property from that it seems
<mathiaz> ajmitch: yop
<SpamapS> mathiaz: hey, with needs-packaging bugs.. do I still need to submit debdiffs or can I just link my branch containing the initial release?
<mathiaz> SpamapS: hm - good question
<mathiaz> SpamapS: I would link it to the bug report
<mathiaz> SpamapS: it should get linked automatically actually
<mathiaz> SpamapS: if you're refering to the LP bug number in the debian changelog in your bzr branch
<mathiaz> SpamapS: and push your branch to LP
<mathiaz> SpamapS: so it's equivalent to a debdiff
<mathiaz> SpamapS: unfortunately LP doesn't support (yet?) commenting on bzr branches in a similar way to merge proposal
<mathiaz> SpamapS: which what I'd like to really do in that use case
<mathiaz> SpamapS: so for the time being I'd use the bug to conduct the review
<kirkland> cjwatson: hi
<kirkland> cjwatson: okay, i am able to run germinate on the uec-live seed I created
<kirkland> cjwatson: i think I'm at a point where I'd like to try building an ISO from it and see what happens
<kirkland> cjwatson: i've pushed it to lp:~kirkland/ubuntu-seeds/ubuntu.maverick.live-uec
<kirkland> cjwatson: perhaps you can review, and tell me how to get a trial ISO built next
<achiang> RAOF: ping
#ubuntu-devel 2010-06-17
<RAOF> achiang: Pong
<jturek_> whoohoo thanks for fixing emacs  gtk in maverick guys :)
<RAOF> Well, not so much fixed as had the GTK patch that was breaking it dropped.
<jturek_> ahh
<jturek_> (catching up on the launchpad bug report now)
<ajmitch> by breaking it, you mean the spam on the console?
<jturek_> ajmitch, lp bug 585196
<ubottu> Launchpad bug 585196 in emacs23 (Ubuntu Maverick) "emacs fails to start: X protocol error" [Undecided,Confirmed] https://launchpad.net/bugs/585196
<RAOF> No, the BadMatch error as soon as emacs tried to display a window.
<ajmitch> ah, shame
<jturek_> not admitting i am an emacs addict or anything ;)
<RAOF> The spam on the console is a theme issue.
<RAOF> At least, I think it is.
<ajmitch> bug 538499 is the one I was thinking of
<ubottu> Launchpad bug 538499 in light-themes (Ubuntu) "warning spam on stdout: CRITICAL **: murrine_style_draw_box_gap: assertion `height >= -1' failed" [Medium,Triaged] https://launchpad.net/bugs/538499
<jturek_> thanks ubottu ;)
<m3ga> err, where is Xorg.conf in lucid?
<m3ga> it should be /etc/X11/xorg.conf shouldn't it?
<lifeless> /etc/X11/xorg.conf
<RAOF> If you've got one; you probably don't.
<m3ga> lifeless: yea, thats what i expectedi don't
<m3ga> RAOF: no it don't
<m3ga> should i have?
<RAOF> No.
<lifeless> no
<m3ga> ok, so how do i bash xorg round the head to use my mouse device?
<RAOF> You can create an xorg.conf and add just a Device section.  I still think that if the kernel isn't presenting it as an input device you're likely to be out of luck.
<m3ga> kernel finds this : input: AVAGO TECHNOLOGIES AVAGO USB OFN Device as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/input/input4
<m3ga> generic-usb 0003:192F:0000.0001: input,hiddev96,hidraw0: USB HID v1.01 Mouse [AVAGO TECHNOLOGIES AVAGO USB OFN Device] on usb-0000:00:1a.1-1/input0
<nigelb> jcastro: a bit too late, but I haven't logged into this session for a while
<nigelb> Don't unsubscribe reviewers team after a review is done, it helps for statistical purposes
<dholbach> good morning
<pitti> Good morning
<ddecator> morning pitti
<pitti> hello ddecator
 * pitti finsihes a new-binary-debian-universe run to clean up NEW somewhat
<pitti> seb128: d-conf NEWed as well, in case you are waiting for it
<pitti> and the new kernel
<seb128> pitti, oh, thanks
<seb128> pitti, I newed it but it was only built on amd64 the other day when I did I think
<ricotz> pitti, hello, i want to ask about the pending docky sru in lucid-proposed
<ricotz> https://bugs.edge.launchpad.net/docky/+bug/574003
<ubottu> Launchpad bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Fix committed]
<pitti> ricotz: it fixes 19 bugs, but none got any feedback so far
<pitti> ugh, who accepted that?
<ricotz> pitti, there are feedbacks on the bug reports itself
<pitti> Riddell: did you accept docky into lucid-proposed?
<pitti> none of them have ubuntu tasks, or are set up for SRU
<pitti> ricotz: I opened a sample of 4 bugs, and none of them have an "please test the SRU" question or even a SRU request
<pitti> and feedback about the lucid-proposed version
<ricotz> https://bugs.edge.launchpad.net/docky/+bug/555562/comments/16
<ubottu> Launchpad bug 555562 in docky (Ubuntu Lucid) "crash accessing Gnome keyring in Lucid" [Critical,Triaged]
<pitti> ricotz: ok, I marked that one as verified; 1 down, 18 to go..
<pitti> well, we probably don't need all 18, but for an update as big as this we need much more than "1"
<ricotz> pitti, like i wrote in my comment on the sru bug, it is impossible to get all reports
<ricotz> i have linked some comments here https://bugs.edge.launchpad.net/docky/+bug/574003/comments/9
<ubottu> Launchpad bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Fix committed]
<pitti> but at least the bugs should have ubuntu tasks, tell the maverick status, and ask people to check the lucid-proposed version
<pitti> ricotz: ok, I'll mark those as verified
<Laney> I don't know who set it up for an SRU, but when I did the previous version I made sure to open all Lucid tasks
<pitti> except that they didn't actually test the ubuntu package
<pitti> since by that time it wasn't even in the package
<pitti> ricotz: ^
<pitti> folks apparently tried some vcs head snapshot or so?
<ricotz> pitti, yes, like i wrote in my comment, we backport commits to the stable branch, if there are regressions they should prevent the inclusion while there are so many bugs fixed
<ricotz> docky 2.0.2 is from the current view very broken and is not able to please peoples needs in some ways therefore they perhaps stop using it
<pitti> that's why we usually ask for testing the proposed package in all the bugs
<pitti> which will reach the bug reporters
<pitti> I can do that with a script
<pitti> but it should never have been accepted this way in the first place
<ricotz> yes, but in this case most of the reporters would have switched to the ppa in the meantime
<pitti> so they could switch back..
<ricotz> this is unlikely cause there were major packaging changes and new dependencies for upcoming 2.1.0
<ricotz> i understand your point to verify these bugfixes, but it also hard for us to get confirmation for more recently reported bugs
<pitti> ricotz: hm, the changelog doesn't even mention bug 574003
<ubottu> Launchpad bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Fix committed] https://launchpad.net/bugs/574003
<pitti> ricotz: oh, I'm not primarily blaming you; it's just that the current state of this SRU is so poor (how it was accepted and the bugs prepared) that it will have a very low chance of being tested
<pitti> ricotz: ok, I'm sending out calls for testing to the bugs
<ricotz> this bug should be in the changlog for 2.0.3
<Laney> it wasn't uploaded with -v
<pitti> so it should be fixed in maverick
<pitti> (there are no ubuntu tasks to keep track of the state)
<pitti> so, let's see whether we'll get some responses
<ricotz> yes
<pitti> ricotz: I also subscribed ubuntu-sru to all the bugs
<ricotz> pitti, thank you
<pitti> but whoever accepted this, please don't in the future; it's causing a lot of extra work
<ricotz> pitti, on the other hand, it is a bit unpleasant for upstream devs who do spend a lot of work to maintaining a stable release besides a development branch, it seems hard to get an sru for an application like docky which has no rdeps
<pitti> ricotz: no, not really; it just takes some care to prepare the bugs accordingly (not necessarily by you)
<ricotz> perhaps packages could be categorized to make a sru easier for universe one?
<pitti> ricotz: the actual changes seem quite appropriate for an SRU
<pitti> it's just that due to the way the SRU was handled, we would not get any feedback
<pitti> and the SRU team didn't even know about this, since they weren't subscribed to any of those
<pitti> we put new upstream microversions into LTSes all the time
<ricotz> ok, but a least this one bug was subscribed to the sru team, alright
<ricotz> pitti, i am trying to push this a bit, cause i am planning to release docky 2.0.5 very soon
<pitti> ricotz: once we get a handful of testing on the proposed package, we can move it
<ricotz> pitti, thank you, i hope the will be some responses soon
<apw> with the new debian 3.0 formats available do we have a feeling on whether we are keen for existing packages to migrate to it or not ?
<pitti> there's no particular hurry, I think
<apw> pitti, is it recommended?
<pitti> we should certainly start doing new packages that way
<pitti> and once we touch a package anyway, and you feel like it, you can as well do it
<pitti> but I wouldn't touch packages just for that
<apw> pitti, thinking about the kernel where we are obviously touching them most of the time
<pitti> apw: that sounds rather easy, given that you don't actually use orig.tar.gz's and patches for that, right?
<apw> pitti, we do use origin.tar.gz's against the upstream version yes once released of course
<pitti> ah
<apw> i have prototyped it with the 3.0 (quilt) format which looks to work but trying to work out where it is available
<pitti> apw: but then you'd need to do proper patches instead of changing inline, which is what you tried to avoid, I thought?
<apw> pitti, seems that in that mode any diff from the tarball to 'here' is turned into an automatic patch for you
<apw> so i think it works fine for us
<pitti> ?
<pitti> apw: it's the other way around
<pitti> apw: debian/patches/* is automatically applied to the source on unpack
<pitti> all inline modifications to the upstream source are _ignored_ when building the source package
<pitti> you only have a debian.tar.gz
<apw> right ... but on dbuild -S if you have an orig then it diffs everything but debian and makes a patch out of those and puts it in debian/patches, then it makes the debian tarball
<pitti> apw: oh, I didn't know that
<pitti> how do you do that?
<apw> it just happens automatically
<pitti> ah, I see
<apw> as far as i can tell it applied the patches in debian/patches, then diffs the result, and adds a new patch ... something like that
<pitti> I actually don't like that at all, but seems to be that way
<pitti> seems you'd still get weird patches with spurious config.guess stuff etc. that way
<apw> pitti, yeah seems so ... as far as i can see the only real advantage is you get stuff in debian as you intended, zero length files and permission maintained
<pitti> so it still doesn't obsolete the need for separate build-tree/
<apw> pitti, no i think not
<apw> pitti, actually it does say 'upstream paths' are diffed
<apw> so perhaps its only the ones in the tarball not new files
<apw> no that wouldn't work either
<pitti> no, I guess it'll do the whole thing
<pitti> with {bzr,git}-buildpackage you avoid this random clutter, so I stopped worrying about it long ago
<cjwatson> apw: yeah, I don't know how useful 3.0 (quilt) is for you, unless you write something that automatically serialises the git tree into a set of quilt patches
<cjwatson> which might be an interesting and useful project, but doesn't seem terribly urgent :)
<cjwatson> (I think somebody may have been working on something like that for git-buildpackage, not sure)
<apw> cjwatson, in its basic form it seems usable as a replacement for orig/diff format in a similar way ... with the advantage that debian/* is correclty maintained permissions etc wise ... not sure if that enough of a reason to switch tho.
<cjwatson> apw: I don't think there's a great deal of point in using 3.0 (quilt) in the mode where you just have it automatically spit out a single patch
<cjwatson> permissions and binaries and the like are I suppose mildly useful
<apw> no unless 1.0 is going to go away
<cjwatson> it's not
<cjwatson> you might want to declare 1.0 in debian/source/format if you're going to stick with it though
<apw> yeah at least the archive knows i chose that way
<cjwatson> don't get me wrong, I think 3.0 (quilt) is fantastic and I use it for all my packages, but I think that's more the case if you actually use it for maintenance work rather than just have the package spat out that way automatically
<cjwatson> well, all my packages that aren't 3.0 (native) anyway :-)
<apw> yeah i can see that, if there is no advantage to switching to that mode for the archive, i suspect there is little for us
<cjwatson> http://upsilon.cc/~zack/stuff/dpkg-v3/ <- graph of 3.0 format adoption in Debian
<apw> cjwatson, do you have any idea why one has to specific (native)/(quilt) given older formats could work it out ... just seems to make life difficult
<cjwatson> apw: it was actually often a problem that the older formats worked it out; it was quite common for people to upload native packages by accident when they'd actually just misnamed the .orig.tar.gz
<cjwatson> the vast majority of packages don't intend to switch back and forward between native and non-native
<apw> fair indeed
<buxy> pitti: clean is supposed to remove clutter so that they don't end up in automatic patches, and now you can also stick supplementary files to ignore in debian/source/options with --extend-diff-ignore
<pitti> buxy: ah, --extend-diff-ignore sounds nice
<pitti> buxy: right, but some packages do really nasty stuff like updating config.guess in the clean target
<pitti> unfortunately this used to be in the dh-make template
<pitti> but well, I disgress..
<buxy> I know, recommendations have changed over time but many are still polluting the diff due to that
<seb128> you often have no easy way to clean
<seb128> like if you run autoreconf at build time
<pitti> for those, bzr bd or git-buildpackage just DTRT
<buxy> seb128: there's dh-autoreconf (for dh7/cdbs) but I'm not sure IÂ like it
<buxy> (i.e. it's somewhat overkill for the purpose)
<pitti> does anyone see what I'm doing wrong here? apt-get source -o DPkg::options::="--require-valid-signature" pmount   -> --require-valid-signature is never passed to dpkg-source
<buxy> pitti: I think Dpkg::options:: is only for "dpkg" not dpkg-source
<pitti> ah
<soren> pitti: You can tweak Dir::Bin::dpkg-source instead.
<soren> pitti: change it to "dpkg-source --require-valid-signature" and you should be fine.
<pitti> soren: to point to a locally modified dpkg-source
<pitti> ?
<pitti> soren: ah, nice
<soren> pitti: No, just pass the extra arguments.
<soren> It's concatenated with "-x blah.dsc" and passed to system.
<soren> system(3), that is.
<apw> pitti, did i ask you about the apparent leakage of red and green out of the top of our bars on the burn-down charts for A2 ?
<pitti> apw: you didn't
<pitti> indeed, looks weird
<pitti> apw: perhaps it's related to the bug I'm currently chasing
<pitti> I've been getting tons of ZeroDivisionError exceptions from cron
<pitti> but whenever ran the damn thing by hand it of course worked
<pitti> so I added some extra debugging, but never got a cron mail since then :-/
<apw> hrm, thats a bit mad, does it fail if you run it via at ?
<pitti> it started perhaps a week ago, so something in the data must have changed
<pitti> apw: haven't tried
<pitti> the other reports (a3, entire cycle) seem to look just fine
<pitti> so it seems that's the one which might upset it
<apw> pitti, fyi its the same in firefox and chromium so i assume its real
<pitti> yes, I don't think it's an svg problem; it's somewhere in pychart
<pitti> apw: I'll keep that on my radar; I take it it's not OMGblocking you?
<apw> no not at all, its just an oddity
<apw> pitti, one which seems familiar ... i have the feeling its been about before and gone away
<pitti> apw: also, it looks alright again from June 14 on, which could be about the time when I added the debugging stuff
<apw> pitti, somewhat peculiarly it seems to have sorted itself in the last 4 days results
<apw> but arn't the whole report rebuilt each time
<pitti> yes, it is
<pitti> I removed the debugging stuff again
<apw> so it must still be in the old data somehow ... hrm
<pitti> let's see whether it fails again next time
<apw> so one assumes the issue is collector side not reporter perhaps
<pitti> apw: or if the chart data has a particular shape, like bunny ears for example
<apw> can anyone point me to the i686/cmov discussion so i can confirm we are in line with it
<apw> cjwatson, ^^
<cjwatson> apw: foundations-m-686-compile, but it's waiting for doko to write it up
<apw> cjwatson, ahh yes thanks ... so we shouldn't be reacting kernel wise as yet then
<cjwatson> there's probably an audio file of the UDS session if you're desperate :-)
<apw> cjwatson, heh no not desperate, just wondering if we should be doing somethign for maverick.  but seening as there isn't even a uds write up for it, i suspect doing anything is pre-emptive
<apw> cjwatson, there don't seem to be any work-items on that spec which is concerning given it implies a rebuild does it not?
<cjwatson> apw: we're not going to rebuild everything just for that, no
<doko> cjwatson: yes, still to write :-/
<zul> can someone from the foundations team review the upstart job: https://bugs.edge.launchpad.net/ubuntu/+source/tgt/+bug/574554
<ubottu> Launchpad bug 574554 in tgt (Ubuntu Maverick) "tgtd needs init script or upstart job" [Medium,Triaged]
<apw> doko, was a definative decision made?  there seems to be some feedback requests on there ...
<doko> apw: about what?
<apw> doko, about which options we were going to require for that blueprint
<doko> apw: "options to require?"
<apw> doko, did we determine the minimum required cpu features we would support going forward, under the auspecis of the blueprint: foundations-m-686-compil
<doko> apw: yes, i686. but I didn't look at the nop problem yet, if it's just a glibc local thing, or if this is seen generally)
<smoser> Riddell, "ebsmount upload of the day" is ready.  i ran 'licensecheck' this time. sorry for not having done that before.
<Riddell> smoser: upstream did another new release?
<smoser> well, sort of.
<smoser> those files didn't come from upstream, but from another turnkey project. they ammended the turnkey-pylib files (which i had copied)... i mentione dthis in a mail yesterday.  those files were written by debian/patches.
<smoser> Riddell, ^
<Riddell> smoser: and that turnkey-pylib project has files which say they're GPL and not "all rights reserved"?
<smoser> correct.  the patch references the git repo and commit level
<smoser> http://github.com/turnkeylinux/turnkey-pylib/tree/master/pylib/
<Riddell> smoser: lovely, accepting
<smoser> thanks for your time Riddell
<kirkland> pitti: ping
<pitti> hey kirkland, how are you?
<kirkland> pitti: not bad :-)
<kirkland> pitti: who's handling SRUs in your place now?
<kirkland> pitti: i wanted to see about getting https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=qemu-kvm accepted to lucid-proposed
<pitti> kirkland: it's in between cjwatson, slangasek, and me
<pitti> jdong and ScottK help out as well
<ScottK> (all I can do is hit the accept button on stuff jdong has approved)
<kirkland> pitti: cool, thanks
<jdong> *looks*
<jdong> ACKed :)
<ogasawara> doko: do you have an ETA for when you'll have the foundations-m-686-compile spec written up.  I'm the one with the Alpha2 work item assigned and if something needs to get into the Alpha2 kernel it needs to happen by mid next week.
<doko> ogasawara: ok, will try to do it today
<ogasawara> doko: thanks
<doko> ogasawara: I thought you already did drop the i386 variant
<ogasawara> doko: we did
<pitti> mr_pouit: same question for exo; it can use gio as well now, so I'd drop the build/binary hal depends
<pitti> mr_pouit: I have both exo and thunar prepared now, and working great
<ScottK> kirkland: Accepted.
<pitti> mr_pouit: I'm also uploading three packages to build against exo-1 instead of the exo-0.3, to avoid two ABIs; hope you don't mind?
<mr_pouit> pitti: exo-1 isn't stable either...
<pitti> mr_pouit: ah, so you prefer stuff to be built against -0.3 for now?
<mr_pouit> thunar(-gio) isn't ready at all
<mr_pouit> it can't remember file associations for example
<mr_pouit> and no volume auotmounting
<pitti> mr_pouit: I'm currently working on an automounting solution, FYI
<mr_pouit> you should tell that to upstream then :)
<pitti> mr_pouit: but ok; I'll delete the xfce4-terminal transition from the xubuntu-dev PPA again, sorry about that then
<mr_pouit> ah in, the ppa ?
<mr_pouit> fine then
<mr_pouit> I thought in was for the archive
<mr_pouit> *it
<pitti> nah, xubuntu-dev PPA
<pitti> which has the new exo
<mr_pouit> yeah, so no problem
<pitti> mr_pouit: I have xfce4-{settings,terminal} for exo-1 (simple patch)
<mr_pouit> xfce 4.8 will probably get delayed of several months, that's why I was a bit nervous if you wanted to upload that to maverick ;>
<pitti> mr_pouit: I could do it for our own project only, but from our POV it'd make more sense to work in the xubuntu-dev PPA and all work on the same stuff?
<pitti> but your call, of course
<mr_pouit> no no, the ppa is fine if it's easier for you
<pitti> ok, great
<pitti> mr_pouit: I updated https://wiki.ubuntu.com/Halsectomy a bit
<pitti> great to see progress on the XFCE side :)
<pitti> and saves two seconds boot time
<mr_pouit> pitti: fyi, the three panel plugins (volstatus, governor, cddrive) you put on the list are (more or less) unmaintained upstream, so it's very very low priority
<pitti> *nod*
<pitti> mr_pouit: "governor" is for CPU clock, I suppose?
<pitti> there should be little reason to fiddle with this manually these days
<mr_pouit> yeah, I wanted to remove it from the archive, but some people complained ("it works, why remove it")
<kirkland> ScottK: jdong: thanks
<mr_pouit> pitti: I'll try to complete a bit the halsectomy page, because some programs/plugins (e.g. xfce4-places-plugin) rely on libthunarvfs for {un,}mounting partitions, whereas other only for file management. So it's not obvious to know which ones need to be halsectomied without grepping the code.
<pitti> mr_pouit: libthunarvfs seems to be obsolete entirely, right?
<mr_pouit> yep
<mr_pouit> anyway, gtg, thanks for your work on that :)
<pitti> mr_pouit: thanks, enjoy
 * LucidFox wishes pbuilding GTK and Qt applications didn't involve installing half of X...
<cjwatson> cking: re https://wiki.canonical.com/ColinKing/EFIAndGrub2-IntelDevelopmentKit - I arranged for GRUB to read most of the kernel and initrd in one single EFI call today, and (to my surprise) it didn't actually improve the time perceptibly
<cjwatson> cking: this was reading from an iso9660 filesystem, so the files were contiguous
<cjwatson> cking: the only thought I have is that using the block I/O layer rather than the disk I/O layer would avoid some copies, but that requires GRUB to handle alignment itself - and I already avoided at least one full copy of the data by turning off disk caching and that didn't seem to make any difference
<cjwatson> cking: this was with OVMF under emulation, though
<cjwatson> cking: but it's interesting to hear that you had similar performance problems on bare metal
<cjwatson> cking: if you want to try my changes, they're here: http://paste.ubuntu.com/451197/
<kirkland> cjwatson: odd ...  running "status ssh" on my lucid box exits 0, prints nothing;  sshd is in fact running though
<kirkland> cjwatson: maybe an upstart hiccup
<EtienneG> Question: is there any way we can force installation of a restricted driver at install time, through preseeding?  Would invoking "jockey-text -e nvidia" as a late_command be sufficient?
<superm1> EtienneG, a little more complicated, but this solution will work http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=ubuntu-fid.git;a=blob;f=framework/scripts/chroot-scripts/fish/01-jockey-drivers.py;h=6c693af7255f0fc21b6b5695906d2be52e9752cc;hb=HEAD
<superm1> (if the rest of the env is setup right for the late command that is)
<EtienneG> superm1, thanks a bunch
<smoser> hey all, i have a python package that is dynamically loading modules, via __import__(modname). i'm wondering where would be the right place to put the modules in a package, and subsequently, how to look up that path in python
<smoser> so far, i have found that uso far, module name 'a' is loading plugins.  i'm able to load them by sys.path.insert(0,a.__path__[0] + "/handlers")
<Sarvatt> lool: go figure binutils got uploaded *right* after your oprofile upload, needs a rebuild :)
<ScottK> smoser: I'd suggest ask for assistance in #debian-python on OFTC.
<hallyn> mathiaz: kirkland: process question.  It only just came to my attention that the lxc package is a straight debian package.  I'd like it updated to 0.7.0.  Do we (a) send email to the package maintainer requesting update, (b) create a debian bug to ask for it, (c) create our own temp 0.7.0 package, or (d) just wait patiently?
<mathiaz> hallyn: (d) is the prefered solution
<mathiaz> hallyn: depending on how important it is to get the new upstream version (c) is also possible
<mathiaz> hallyn: is there a specific blueprint or milestone target for lxc to be updated to 0.7.0?
<geser> hallyn: depending on when the new upstream got released you could contact the DD and ask if he needs/wants help with the package
<hallyn> mathiaz: i'd be nice to have it for alpha2, so next week
<hallyn> (it's in the blueprint, yes, and would just be nice)
<hallyn> now 0.7.0 just came out today...
<hallyn> so i'm certainly being unreasonable, but still was wondering whether we usually try to email the DD or not
<hallyn> i'll wait a day or two, thanks
<lool> Sarvatt: Tss :-)
<lool> Sarvatt: uploaded
<hallyn> geser: i assume you mean "if it's been a long time since the upstream release"
<geser> hallyn: yes, something longer than a few hours :)
<hallyn> geser: drat!
<hallyn> thanks :)
<mathiaz> hallyn: right - helping the DD is also welcome
<mathiaz> hallyn: you could look at the debian changelog and infer how responsive the DD is
<mathiaz> hallyn: you could also push a package to a PPA
<mathiaz> hallyn: to get more testing done
<hallyn> mathiaz: yup, i've got my own bzr branch (and package on its way to ppa) - bc man, the ubuntu lxc template works GREAT
<mathiaz> hallyn: \o/
#ubuntu-devel 2010-06-18
<mathiaz> bdmurray: hi
<mathiaz> bdmurray: https://code.edge.launchpad.net/~mathiaz/+patches?start=50&batch=50
<mathiaz> bdmurray: why is bug 32521 being listed?
<ubottu> Launchpad bug 32521 in gallery (Debian) "purge doesn't remove all config files" [Unknown,New] https://launchpad.net/bugs/32521
<mathiaz> bdmurray: same thing for bug 33940
<ubottu> Launchpad bug 33940 in mysql-dfsg-5.0 (Debian) "mysql_setpermission broken" [Unknown,New] https://launchpad.net/bugs/33940
<bdmurray> mathiaz: why on your page?
<mathiaz> bdmurray: yes - and given they're fixed released in ubuntu
<mathiaz> bdmurray: they're not fixed in debian though
<bdmurray> mathiaz: I'm not certain off the top of my head
<mathiaz> bdmurray: the bug link points to the debian project in LP thoughy
<bdmurray> mathiaz: you could try staging and switch the debian task to fixed and see what happens
<mathiaz> bdmurray: so I guess it's because it's still opened in debian that the patch shows up
<mathiaz> bdmurray: you're right
<mathiaz> bdmurray: I've set the bug to fixed released in Debian on staging and it was removed from ~mathiaz/+patches list
<bdmurray> mathiaz: well, you'd guess it
<mathiaz> bdmurray: should I file a bug?
<bdmurray> mathiaz: I don't think so.  There is no context for +patches, imagine if you were a debian developer...
 * mathiaz agrees
<mathiaz> bdmurray: well - I'm still interested to have the list of patches in ubuntu though
<bdmurray> ubuntu/+patches then ?
<mathiaz> bdmurray: https://code.edge.launchpad.net/~mathiaz/ubuntu/+patches?
<bdmurray> mathiaz: so from ~me/+patches you want to filter on projects?
<mathiaz> bdmurray: yes
<bdmurray> mathiaz: no I meant launchpad.net/ubuntu/+patches ;-)
<mathiaz> bdmurray: I'd like to have a list of patches I could help with while working on Ubuntu sponsoring
<mathiaz> bdmurray: ubuntu/+patches gives me way too many patches
<bdmurray> mathiaz: okay, a bug seems reasonable but it'd be challenging
<bdmurray> mathiaz: but to be fair I'm new there ;-)
<mathiaz> bdmurray: :)
<mathiaz> bdmurray: that's perfect: some challenge for a newbie ;)
<Sarvatt> the kernel needs a rebuild against the new binutils now too for linux-tools, why are we building all of these packages linking to the shared binutils again?
<pitti> Good morning
<dholbach> good morning
<pitti> lool: bonjour Loic
<pitti> lool: would you mind if I NMUed debian bug 586261? I'd like to sync it to maverick then, to unbreak calibre
<ubottu> Debian bug 586261 in python-cssutils "calibre: CSS error on conversion to EPUB" [Normal,Open] http://bugs.debian.org/586261
<lool> pitti: are you DPMT?  if you are just commit it there
<pitti> lool: DPMT?
<pitti> lool: I didn't see a git branch for it in collab-maint, if you mean that?
<lool> Debian Python Modules Team
<pitti> lool: no, I'm not
<pitti> lool: but last time I uploaded it to Ubuntu only someone came back to me and said "you should have uploaded it to Debian right away"
<pitti> or perhaps s/upload/commit/, I don't remember for sure any more
<lool> pitti: Yes, I was Cc:ed to that discussion
<pitti> I know about the collab-maint git trees, but it's not there
<lool> pitti: So it's relatively easy to get access to this SVN repo which has packaging for many python packages, I'd recommend you consider asking to be included, you could state you don't intend to maintain any particular pcakage but just try to commit Ubuntu fixes where you can
<lool> pitti: it's in svn+ssh://svn.debian.org/svn/python-modules/packages
<lool> 328 packages ATM
<lool> or probably more in fact
<pitti> lool: oh, I'd probably effectively maintain cssutils with calibre
<lool> pitti: I'd love if you'd adopt cssutils then
<lool> pitti: I packaged cssutils as a dep of a package which is slowly going away, and have no strong interest in it
<lool> pitti: Ideally, request DPMT access, and just add yourself to uploaders?
<pitti> lool: ok, will do
<pitti> lool: I'll mail the list for that?
<lool> pitti: I think so, but you could also ping the admins on IRC
<lool> pitti: Ah the watch file didn't allow upstream versions to use letters in versions
<pitti> I had to fix something else, but by and large it was a straightforward update
<pitti> lool: uh, I'm not that fancy subscribing to the ML, though
<pitti> I don't want to get bug reports for _all_ python modules
<lool> pitti: That's fine, I just PTS subscribe to the package
<lool> pitti: It's kind of a mini-collab-maint, the way I see it
<pitti> lool: I mean for asking for commit access
<pitti> yeah, I suppose
<pitti> lool: whom could I ping on IRC?
<lool> pitti: If POX is around, that would be a good match
<lool> pitti: /join #debian-python@oftc?
<buxy> lool, pitti: all DD have write access to the DPMT svn repository
<lool> buxy: Oh right, had forgotten about that change
<pitti> ah, nice
<lool> pitti: do you want me to do the new upstream release?
<pitti> lool: I'll commit it there, and you upload?
<pitti> lool: committed, and new tar is on http://people.debian.org/~mpitt/cssutils_0.9.7~b2.orig.tar.gz
<lool> pitti: thanks, looking now
<lool> pitti: Hmm they are changing the new APIs in the developer releases still, so I hope they are close to 0.9.7
<lool> pitti: Do you want to be in uploaders?
<pitti> lool: I'd like to be, yes
<lool> pitti: Uploaded; thanks for preparing the new upstream release
<pitti> lool: merci beaucoup
<pitti> lool: so I can upload the next one by myself
<lool> pitti: Sure, any time
<Shai_o> hi all
<cjwatson> pitti: could you review my parted upload to lucid-proposed when you get a moment, please?
<pitti> cjwatson: sure, will do right now
<pitti> ugh, quite sizable queue
<cjwatson> I got behind :(
<pitti> cjwatson: if you are currently attacking it, shall we start on both ends and work towards the middle?
<pitti> I can spend some time on it now
<cjwatson> ok :) which end are you attacking?
 * pitti flips a coin and says "end"
<cjwatson> you mean newest?
<pitti> oldest, end on https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1
<cjwatson> ok
<pitti> but I don't particularly midn
<cjwatson> no that's fine
 * cjwatson tries queuediff for a change
<wgrant> cjwatson: Is there something wrong with the LP-generated diffs, or is queuediff just nicer?
<pitti> don't forget -b, for the full love :)
<pitti> wgrant: queuediff is using those now
<wgrant> Ahh.
<pitti> wgrant: but it also parses out the bugs, opens them in the browser, and generates an appropriate sru-accept.py line
<wgrant> Oh, right, yes.
<pitti> I even have a wrapper on top of that which does
<pitti> exec queuediff -b "$@" | view -
 * pitti likes looking at patches in vim
<cjwatson> er, wow, what, the gdm diff is weird
<pitti> cjwatson: ^ how so?
<pitti> structurally the diff seems to be correct?
<pitti> cjwatson: NB that the previous gdm is still in -proposed
<pitti> but I think it's about ready to go to -updates
<cjwatson> './queuediff -s lucid-proposed gdm'
<cjwatson> has huge piles of weird differences, like lots of deletions from debian/changelog
<cjwatson> the diff in LP looks right though
<pitti> -s lucid (or just skip it)
<pitti> cjwatson: it doesn't even accept -s lucid-proposed any more, is that really from bzr head?
<cjwatson> oh, I shouldn't be using that?
<cjwatson> I wasn't quite up to date, am now
<pitti> cjwatson: LP just generates the diff to the latest version in whichever pocket, so I dropped the pocket bit; it's just release now
<pitti> in some cases that's wrong, of course
<pitti> but in the vast majority it's the right thing
<cjwatson> yeah, that's fine
<pitti> majority ... of cases..
<wgrant> If you can work out a better ancestor, give me a yell.
<Shai_o> do you have any spare info about building a live cd without a package designed for this task ?
<Shai_o> i mean from scratch :D
<pitti> cjwatson: does the parted SRU require a d-i/ubiquity upload to pick it up?
<cjwatson> no
<lool> In the last weeks, I saw a lot of packages pending a build on sparc; I just got an upload error with one of them (oprofile)
<lool> 2010-06-17 22:18:35 ERROR   Exception while accepting:                           Unable to find source package oprofile/0.9.6-1ubuntu8 in maverick               -> http://launchpadlibrarian.net/50512886/oFLBwGIJoMxnRKhJUeWGfwllX3o.txt
<cjwatson> looks like there was a new upload shortly afterwards, but the sparc build had already been scheduled
<cjwatson> the 0.9.6-1ubuntu9 build for sparc has already succeeded and been installed
<cjwatson> so I think you can ignore that
<lool> cjwatson: Indeed, seeing 0.9.6-1ubuntu9 now, the upload failure was 0.9.6-1ubuntu8; thanks
<cjwatson> pitti: I fixed queuediff to handle package names like 'gtk+2.0'
<pitti> ah, thanks
<pitti> needs some escaping, I figure
<cjwatson> two levels
<seb128> whoever is doing sru review thanks
<seb128> cjwatson, did you move the previous gdm sru to updates before accepting the new one?
<cjwatson> no ...
<cjwatson> bugger, let me see if I have time
<seb128> ok, don't worry otherwise we can get the new version tested and move in a week
<cjwatson> two out of five bugs verified?
<seb128> well I talked with pitti about it yesterday
 * cjwatson looks
<seb128> 2 of those non verified ones are variants of the one EtienneG confirmed fixed
<pitti> haven't checked yet, but most of them should be easy to verify
<seb128> ie triggering events on autofs user dirs
<seb128> or nfs ones
<pitti> autofs is one of the harder ones; I meant the ones sourcing ~/.Xresources etc.
<seb128> pitti, that one was not listed in the changelog
<seb128> pitti, the .Xresources bug was fixed in lucid already IIRC
<pitti> ah, ok
<seb128> pitti, your fix just enabled to do the ".xsession" session
<seb128> which we didn't include in that upload
<pitti> I thought we needed a patch for ~/.xinitrc or similar
<pitti> -ETOOMANYDOTFILES
<spenguin[work]> anyone here use the displaylink drivers?
<seb128> bug #586503 is not fixed in the sru
<ubottu> Launchpad bug 586503 in gdm (Ubuntu Lucid) "/etc/gdm/PostLogin/Default file not run if automatic login is enabled" [Low,Fix committed] https://launchpad.net/bugs/586503
<cjwatson> right, I was just going to say
<seb128> the bug is about postlogin scripts not being run and the fix was one for init scripts
<cjwatson> so how about I copy this, and then you reopen that bug?
<seb128> so similar issues but not quite the right one
<seb128> cjwatson, would work for me ;-)
<cjwatson> damn, I'm sorry, it won't let me
<seb128> ok, don't worry
<pitti> cjwatson: not even with -e?
<cjwatson> 2010-06-18 09:12:02 ERROR   Could not find source 'gdm/2.30.2.is.2.30.0-0ubuntu1' in Primary Archive for Ubuntu: lucid-PROPOSED
<seb128> there was no hurry for those fixes
<cjwatson> pitti: I tried that first
<pitti> ok, let's just test the new one then
<seb128> let's wait another week and test the new version
<seb128> I just want it in lucid
<seb128> I just want it in lucid .1
<seb128> it can wait another week in lucid-proposed
<pitti> . o O { can we please replace gdm with an xsetbg, readline, and startx shell script? }
<seb128> I'm pondering if I should limit the bug numbers in the changelog to things easy to test in next upload though
<seb128> we have often issues because 6 of the 8 fixes are tested
<seb128> but the update doesn't move because it's not all green
<cjwatson> it certainly makes it less obvious during processing
<seb128> even if it fixes 6 bugs and doesn't have any issue
<cjwatson> I have to actually read
<cjwatson> and think
<cjwatson> (fx: sad trombone)
<cjwatson> didrocks: should the main task on bug 33288 still be open?  I gathered this was an upstream fix, and maverick has a newer upstream version
<ubottu> Launchpad bug 33288 in poppler (Ubuntu) "Evince doesn't handle columns properly" [Medium,Triaged] https://launchpad.net/bugs/33288
<didrocks> cjwatson: it has been merged in trunk and should be in maverick now, let me see
<pitti> maverick just got 0.14
<seb128> cjwatson, didrocks: right, it can be closed
<pitti> last time I checked it wasn't in maverick yet, so I kept it open
<seb128> I uploaded the new poppler yesterday
<pitti> but 0.14 should have picked up all those, I hope?
<cjwatson> pitti: second opinion on ubuntuone-client: it's a new upstream release, so I'd normally say "please backport instead", but it looks to me as if the new release was entirely driven by the listed bugs
<didrocks> cjwatson: confirmed, it can be closed
<seb128> pitti, it did, there is only one change left in the debian patches for the new version
<cjwatson> didrocks: ok, please do
<didrocks> done
<pitti> cjwatson: process-wise that seems ok, they usually wrap up fixes in new microreleases
<didrocks> thanks :)
<pitti> cjwatson: want me to take a look at the diff?
<cjwatson> no, that's ok
<cjwatson> pitti: skipping landscape-client for now as there's at least one private bug in there that I can't see
<pitti> cjwatson: ok; I guess that goes for the older release SRUs as well
<cjwatson> if they want an SRU they can follow the policy and subscribe the SRU team to the bugs :P
<cjwatson> didn't check
<pitti> I now hit the kernel package mess
 * pitti starts with mvl-dove
<pitti> smb: can you please upload a meta for linux-fsl-imx51 in lucid-proposed? (just accepted)
<smb> pitti, There is none needed. Licid's fsl-imx51 is based on 2.6.31 (Karmic) which had no ABI bump
<pitti> smb: ah, I see
<smb> ti-omap (2.6.33) would not have needed normally, but had some changes that made it necessary. Its fun. ;-P
<pitti> smb: I'll accept the metas once the kernels are built and NEWed
<pitti> smb: or do they build-depend on something with the new ABI, so that they'll just depwait?
<smb> pitti, Perfect, thanks.
<smb> pitti, No I don'T think, yet
<didrocks> pitti: cjwatson: thanks for the sru reviews :)
<pitti> smb: OOI, is there any chance linux-ec2 goes away at some point? it doesn't change anything different than the linux source itself
<pitti> and frankly I don't have enough time to slam an additional set of 3 tasks (ec, fxl-imx51, ti-omap) to a million bugs, since I think we won't individually verify them anyway on arms
<pitti> so I just send out calls for testing to the architecture specific bugs (i. e. not the ones which were already fixed in the linux SRUs); hope that suits you?
<smb> pitti, I cannot say for sure. I might speak wit John about that. But as it also decouples ec2 from the main kernel uploads, I guess it will stay
<pitti> uh, and qcm-msm as well
<pitti> smb: do you know why http://launchpadlibrarian.net/50319468/linux-ti-omap_2.6.33-502.8_source.changes refers to bug 576274  again?
<ubottu> Launchpad bug 576274 in linux-ti-omap (Ubuntu) "ti-omap: unable to build due to abi-check failures" [High,Fix released] https://launchpad.net/bugs/576274
<smb> pitti, qcm-msm will actually goe away
<smb> pitti, I only did that upload one more time because apw spend some work on that. But otherwise its dead
<pitti> smb: also, most of the maverick tasks are still open; can you guys please have a look at https://bugs.edge.launchpad.net/~ubuntu-sru/+subscribedbugs?field.searchtext=linux at some point and close out the ones which are still unfixed in maverick? (and actually upload the outstanding fixes to maverick)
<smb> pitti, The reference might be a laps in me cleaning the changelog
<pitti> smb: ok, I'll ignore 576274 then, thanks
<pitti> it piled up some 370 open bugs which have been fixed in SRUs, but never in the development release
<smb> pitti, Ok, I have a look on that list later
<pitti> which violates not only the SRU policy, but also keeps a high potential for regressions
<pitti> smb: thanks
<pitti> would be nice to make that list actually useful again :)
<smb> pitti, Understandable. :)
<pitti> smb: will qcm-msm need a -meta?
<smb> pitti, No, that is another branch based on 2.6.31
<pitti> cjwatson: ok, please keep the linux-meta stuff until the kernels were built and NEWed
<vish> pitti: thanks for the SRU round :)
<pitti> cjwatson: are you looking at empathy?
<pitti> cjwatson: seems to be the last one in the lucid queue now
<cjwatson> just accepted
<pitti> \o/
<pitti> cjwatson: so, should I go on with looking at the kernel bits in karmic, and you perhaps take hardy?
<seb128> cjwatson, pitti: thanks for cleaning the sru queue!
<cjwatson> pitti: ok (hardy kernel too?)
<pitti> oh, hardy has one as well?
<pitti> didn't look into the hardy queue yet
<cjwatson> wgrant: the chkrootkit diff in the hardy queue was generated against 0.47-1.1 in hardy, rather than against 0.47-1.1ubuntu0.1 which is in both hardy-security and hardy-updates
<cjwatson> wgrant: (I've accepted it now; hopefully I haven't destroyed the evidence)
<cjwatson> hardy queue emptied
<wgrant> cjwatson: Ah, yeah, it only looks in $uploadpocket and RELEASE.
<wgrant> It should probably know about the... sorta hierarchy.
<cjwatson> yeah
<lool> Daviey: Hey
<lool> Daviey: I started working on screen before you attached your branch, but did the same fix along others; thanks for the branch though!
<Daviey> lool: bah..
<Daviey> lool: I guess i won the race. right, right :)
<Daviey> cjwatson: Can i do the verification for bug #
<Daviey> bug 583698
<ubottu> Launchpad bug 583698 in apache2 (Ubuntu) "[SRU] If /usr/sbin/apache2 is set -x, upgrades fail" [Low,Triaged] https://launchpad.net/bugs/583698
<Daviey> I thought it had to be someone from ~sru-verification ?
<seb128> no
<pitti> Daviey: not really, anyone is welcome to help testing
<seb128> you are welcome to confirm that upgrades work
<Daviey> hmm.. ok https://wiki.ubuntu.com/ArchiveAdministration#Standard case
 * Daviey really feels doc's and policy for SRU isn't clearly defined
<pitti> Daviey: https://wiki.ubuntu.com/StableReleaseUpdates#Verification says that anyone can help
<pitti> and so do the "please test" emails that we send to the bugs
<Daviey> pitti: Will this confirms that policy isn't clear, as AA's are working from a different procedure to the rest of us.. And also doesn't make it clear the purpose of ~sru-verification
<seb128> there is a sru-verification team?
<pitti> AAs aren't dont verification
<pitti> sorry
<pitti> tAAs don't do verification
<pitti> not with their AA hat on
<Daviey> pitti: oh i agree.. but according to their page.. they shouldn't be moving from -proposed to -updates unless someone from ~sru-verification has ack'd
<pitti> Daviey: as soon as a bug is v-done, they can move it
<Daviey> pitti: ok, thanks
<ScottK> Daviey: We went through this issue a while ago and tried to clarify that anyone can test and mark v-done.  If there's documentation that's still unclear, let's fix it.
<Daviey> ScottK: ok
<Daviey> cjwatson: bug 583698 is marked verification-passed FYI :)
<ubottu> Launchpad bug 583698 in apache2 (Ubuntu) "[SRU] If /usr/sbin/apache2 is set -x, upgrades fail" [Low,Triaged] https://launchpad.net/bugs/583698
<cjwatson> Daviey: thanks - I just need to wait for it to build everywhere
<Daviey> cjwatson: Super, thanks
<manjo> cjwatson, have you changed landed in todays iso ?
<cjwatson> no
<cjwatson> I'm in the process of putting them together at the moment
<cjwatson> I keep getting dragged off for other stuff though
<verwilst> upstart-related question if i may
<verwilst> trying to create a puppet upstart script
<verwilst> but service puppet start always hangs while polling sa_family=AF_FILE, path=@"/com/ubuntu/upstart"},
<ari-tczew> does DebianImport working?
<Daviey> cjwatson: No change rebuild - bug 595978, should be hitting the hardy NEW queue shortly; can you fast track that through when you copy apache*0.17 from -proposed to -updates please?
<ubottu> Launchpad bug 595978 in apache2-mpm-itk (Ubuntu) "No-change rebuild to handle updated apache source." [Undecided,New] https://launchpad.net/bugs/595978
<cjwatson> NEW, not UNAPPROVED?
<Daviey> erm, yes -s orry
<Daviey> cjwatson: Will that be going straight to -updates, or do you want it to land in -proposed first?
<cjwatson> -proposed please
<Daviey> cjwatson: dammit, just been upoaded with the -updates pocket
<cjwatson> please reupload, I really don't like accepting things straight to -updates unless it's some absolutely horrible emergency
<Daviey> cjwatson: ok
<warnec> hey there I have a question about Glipper
<warnec> I just finished translating it to Polish
<tgardner> jdstrand, when do sysctl's get applied if the module to which they apply has not been installed by initramfs? For example, net.netfilter.nf_conntrack_acct=1. I figured you might know something about this because of your ufw work.
<warnec> and would very much like my translation to be incorporated in the package
<warnec> unfortunately, Glipper's upstream hasn't been active for something like ~2 years now
<warnec> so I figured it would be better to ask the one who packages Glipper for Ubuntu (since there is no to little chance for new Glipper release)
<warnec> is anyone responsible for Glipper here? Synaptic simply reports ubuntu-devel as maintainer.
<jdstrand> tgardner: that is a good question. I would think it would trigger a module load, but I don't know. if ufw is enabled, it ends up loading the modules it needs before running sysctl, so I've not run into this
<tgardner> jdnf_conntrack can get loaded becasue of kvm et al, but I'm not sure /etc/sysctl.conf is reexamined.
<tgardner> jdstrand, ^^
<jdstrand> tgardner: there isn't anything particular magical about /etc/sysctl.conf. it is 'sourced' in /etc/init/procps.conf after the system. if nothing is calling sysctl on that file in initramfs, I wouldn't expect the change to be available will in initramfs
<jdstrand> s/system/leaving initramfs/
<tgardner> jdstrand, I'm thinking that in the kvm example host side NAT is not started until the user launches his VM.
<tgardner> so nf_conntrack won't get installed until way after the usual startup has completed
<jdstrand> tgardner: well, if you have libvirt installed, it will add some NAT rules, so it'll be there
<jdstrand> I can fire up a vm and see
<tgardner> I wonder about the oddball case where someone just wants to hack in some iptables rules.
<jdstrand> $ sudo sysctl -w net.netfilter.nf_conntrack_acct=1
<jdstrand> [sudo] password for jamie:
<jdstrand> error: "net.netfilter.nf_conntrack_acct" is an unknown key
<jdstrand> tgardner: ^
<cjwatson> Daviey: last architecture being published now ...
<Daviey> cjwatson: great!
<tgardner> jdstrand, thats the exact problem. the key doesn't appear until _after_ the module is installed.
<jdstrand> tgardner: so it won't load the module. I guess if someone is going to do what you are suggesting, they need to add their iptables rules, then apply the sysctl
<cjwatson> Daviey: nothing in hardy-proposed yet?
<jdstrand> tgardner: yeah
<Daviey> cjwatson: really?
<Daviey> should be.. /me pokes
<cjwatson> Daviey: is the apache2-mpm-itk upload vital to have at the same time?
<Daviey> cjwatson: well yes.. apache2-mpm-itk is statically built and if it doesn't go out.. a case of SRU breaking apache sites
<Daviey> (if people use apache2-mpm-itk)
<cjwatson> meh
<cjwatson> err
<cjwatson> Daviey: you uploaded it to -updates again
<Daviey> cjwatson: i had it sponsored.. guess they didn't bzr pull
 * Daviey quietly gets frusated with sponsorship.
<cjwatson> Daviey: point me at the bzr branch
<Daviey> cjwatson: lp:~davewalker/ubuntu/hardy/apache2-mpm-itk/lp595978
<Daviey> barely worth it :/
<jdstrand> tgardner: yeah, just to satisfy my own curiosity and to be 100% sure, I can say definitively that sysctl.conf is not examined after module load
<jdstrand> tgardner: but, on the plus side net.netfilter.nf_conntrack_acct defaults to '1' in maverick, but you probably already knew that ;)
<tgardner> jdstrand, thats pretty much my finding. I think I'll ask this question on the ubuntu-devel mailing list
<cjwatson> Daviey: I think you forgot to pushs
<cjwatson> push
<cjwatson> apache2-mpm-itk (2.2.6-01-1build3.9) hardy-updates; urgency=low
<Daviey> cjwatson: Quite right, my bad.
<Daviey> (done now)
<cjwatson> Daviey: nope.  I have revno 24
<Daviey> cjwatson: Odd, i had pushed
<Daviey> "Pushed up to revision 25."
 * Daviey branches.
<Daviey> Branched 25 revision(s).
<cjwatson> oh, there it goes
<cjwatson> uploaded
<Daviey> cjwatson: rocking, thanks for your time
<cjwatson> so just need to get that built everywhere (I'll score it up), check that it hasn't exploded, then copy
<Daviey> cjwatson: Okay, assume you won't need verfication?
<cjwatson> "check that it hasn't exploded"
<tedg> pitti, Can I configure apport to report stacktraces on crashes on a per-package basis or is it all or none?
<cjwatson> Daviey: any chance of a quick check of the apache2-mpm-itk build to see that it still basically works?  it's published now
<BlackZ> could somebody please sponsor bug #596034 ? thanks in advance
<ubottu> Launchpad bug 596034 in apache2 (Ubuntu) "Please merge apache2 2.2.15-5 (main) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/596034
<micahg> BlackZ: wasn't that already uploaded?
<BlackZ> micahg: seems not
<dim3000> Hello everyone, I have a few projects, particularly a certain game that I would like to clean up (make GPL friendly, etc...) and possibly have it included in the repos. What steps should I take?
<micahg> BlackZ: was uploaded about 25 minutes ago
<BlackZ> oh, 1 hour ago
<BlackZ> I didn't noticed
<BlackZ> :)
<BlackZ> marking as 'Fix released' then
<micahg> BlackZ: if the bug isn't in the changelog
<BlackZ> micahg: hm?
<micahg> BlackZ: LP will auto close if the bug # is in the changelog
<BlackZ> micahg: I know but it's not
<BlackZ> :)
<micahg> BlackZ: right, so yes to your question then :)
<jjardon> Hello, is there any reason because the latest glade is still not packages in maverick? Should I file a bug?
<seb128> jjardon, hi, which one is that? does it require to have gtk3?
<jjardon> no
<jjardon> seb128, indeed that is no glade package in maverick
<jjardon> http://packages.ubuntu.com/search?keywords=glade
<micahg> jjardon: p.u.c doesn't have maverick yet
<jjardon> micahg, p.u.c?
<micahg> jjardon: it has the same version as Lucid ATM
<micahg> jjardon: packages.ubuntu.com
<jjardon> ah, ok
<jjardon> well, the latest release (3.7.1) doesnt depend on GTK+3
<jjardon> but 3.7.2 will depend on it
<seb128> right
<seb128> that's why we don't update
<seb128> (yet)
<seb128> we will likely update when gtk3 is packaged later on
<jjardon> seb128, makes sense
<jjardon> BTW, I requested the GTK+3 package for Debian, maybe you are interesed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585385
<ubottu> Debian bug 585385 in wnpp "RFP: gtk+3.0 -- the GTK+ 3.0 user interface library" [Wishlist,Open]
<zyga> unity clock is off by one minute
<zyga> it seems to be updated just several seconds before each minute
<LucidFox> Okay, just posted a debdiff for messaging indicator support in Liferea: bug #540490
<ubottu> Launchpad bug 540490 in liferea (Ubuntu) "liferea should be added to the indicator applet" [Undecided,Confirmed] https://launchpad.net/bugs/540490
<LucidFox> It calls autogen.sh, though. Would it be better to include autoreconf changes as a (bloody huge) separate patch?
<seb128> zyga, there is a bug open about it on launchpad I think
<zyga> seb128, ah, good then
<seb128> jjardon, thanks, the issue is not to have a bug opened though but somebody doing the work
<seb128> jjardon, I've been watching what happens there since we want gtk3 in the next weeks, we will help getting there if that's done yet
<seb128> jjardon, slomo has been starting some changes in the debian pkg-gnome svn and there is a launchpad ppa some build as well it seems...
<seb128> zyga, check indicator-datetime bugs
<seb128> upstream product not ubuntu one
<LucidFox> And seb128, you're probably busy with more urgent matters, but I remember a promise to review the xchat-gnome debdiff :)
<jjardon> seb128, ok, thanks for the info.
<seb128> LucidFox, I don't think I promised, I probably said I would check on it
<LucidFox> Ah, makes sense
<seb128> LucidFox, but the diff is non trivial and we turned rgba off for now
<seb128> I was sort of letting upstream a chance to review it ;-)
<seb128> I was just about to close IRC and enjoy my evening now so not today in any case but I will review it later on
<seb128> jjardon, you're welcome
<LucidFox> Speaking of which, I'm concerned about the state of xchat-gnome upstream - it's apparently a hairline away from releasing 0.26.2, which will include my userlist patch, yet the latest git commit was two months ago
<LucidFox> And okay, it can wait!
<BlackZ> seb128: do you remember bug #590094 ? slomo said it builds in debian
<seb128> we will git those changes in maverick if they don't roll a tarball
<ubottu> Launchpad bug 590094 in bug-buddy (Ubuntu) "bug-buddy FTBFS on maverick" [High,In progress] https://launchpad.net/bugs/590094
<seb128> BlackZ, I do, I'm not sure why he would build though
<seb128> BlackZ, I'm about to go now so I've no time to check but it's likely he didn't test correctly
<BlackZ> seb128: please reply to the bug report when you can :)
<seb128> will do
<seb128> but if you have a change to solve the issue you can add it there as well
<BlackZ> if so, a bug in debian should be reported (if there's not yet)
<BlackZ> sure, I will do
<philsf> hi, I'm trying to recompile evolution, to test a new patch from upstream, but the patches are not being included. I'm just using 'dpkg-buildpackage' from the source tree, should I be using another program, or some specific parameters instead? I don't see any mention to patches in the man
<seb128> philsf, how do you try to apply the change?
<philsf> seb128, I just found out the patch is trying but failing. it's probably for a newer version
<seb128> ok
<philsf> thanks
<Daviey> cjwatson: Sorry for teh slow RTT.. done, and passed verification.  bug 595978
<ubottu> Launchpad bug 595978 in apache2-mpm-itk (Ubuntu Hardy) "No-change rebuild to handle updated apache source." [Undecided,Fix committed] https://launchpad.net/bugs/595978
<cjwatson> thanks, will process in a sec then
<cjwatson> Daviey: all done now.  sorry for the mess we ended up with
<Daviey> cjwatson: Oh, we arrived at the destination in the end :)
<mathiaz> kees: hi!
<mathiaz> kees: bug 523354
<ubottu> Launchpad bug 523354 in libpam-ccreds (Ubuntu) "[MIR] libpam-ccreds" [Wishlist,Triaged] https://launchpad.net/bugs/523354
<kees> mathiaz: oh! thanks for the reminder... reading
<mathiaz> kees: ^^ does it have the approval to move it main?
<kees> hm, minimum_uid=1000 seems wrong to me.
<kees> shouldn't that be loaded from /etc/login.defs ?
<kees> i.e. it should use UID_MIN by default when minimum_uid isn't specified?
<ccheney> how do i get a grub menu to pop up in maverick?
<micahg> ccheney: shift?
<ccheney> doesn't seem to work for me
<ccheney> just hit shift, or hold it down?
 * micahg thinks hold it down, but not sure
<ccheney> ok
<cjwatson> hold it.  it doesn't work on all systems though :-/
<ccheney> ok now it worked :)
<ccheney> i think i held it too early
#ubuntu-devel 2010-06-19
<javanix> hey everyone, who should i talk to (and where do i find them) if i want to help out with development?
<blueyed_> javanix: join #ubuntu-motu and look at wiki.ubuntu.com for starters - try also googling for "ubuntu development". Also, there are bugs tagged "bitesize" on launchpad.net/ubuntu.
<javanix> alright, i'll check them out
<javanix> thanks
<blueyed_> javanix: great, you're welcome. have fun.
<njin> Someone can help me assembling my pc
<BlackZ> njin: ? this is a channel related to the ubuntu development
<njin> Yes, but is an empty chan full of experts
<BlackZ> njin: hm? however we can't help you on that, sorry - if it's a question related to the ubuntu development it's OK but if it's not you're in the wrong place :)
<njin> Ok
<bilalakhtar> Hey there, please see bug #596062 and the attached patch.
<ubottu> Launchpad bug 596062 in landscape-client (Ubuntu) "broken python-pycurl dependency" [High,Triaged] https://launchpad.net/bugs/596062
<bilalakhtar> anyone here?
<bilalakhtar> bdrung: Hello there! bug #596062
<ubottu> Launchpad bug 596062 in landscape-client (Ubuntu) "broken python-pycurl dependency" [Medium,Triaged] https://launchpad.net/bugs/596062
<nigelb> !weekend | bilalakhtar
<ubottu> bilalakhtar: It's a weekend. Often on weekends the paid developers and a lot of the community may not be around to answer your question. Please be patient, wait longer than you normally would or try again during the working week.
<bilalakhtar> nigelb: oh, forgot its the weekend. Not a weekend in here, though.
<BlackZ> hey nigelb :p
<nigelb> bilalakhtar: *blink* which part of the world are you in?
<nigelb> BlackZ: heya
<bilalakhtar> nigelb: saudi arabia, weekends on thursday and friday
<nigelb> ahhhh, forgot
<BlackZ> bilalakhtar: however it'd be better to indicate the file which you have modified
<BlackZ> e.g: * debian/control: added foobar in build-depends, fixes the foo (LP: #12345)
<bdrung> bilalakhtar: why do you depend on python2.6-pycurl instead of python-pycurl?
<bilalakhtar> bdrung: that was done in previous packages as well.
<BlackZ> oh bdrung, you can read in my mind :p
<bilalakhtar> bdrung: if I see the lucid package.
<BlackZ> I was just asking
<bdrung> BlackZ: i don't think that having debian/control in the changelog is required for dependency changes
<BlackZ> bdrung: so "Added foobar to the build-depends for fix the bar (LP: #12345)" would be enough, or am I wrong?
<bdrung> why does this package have this weird naming scheme?
<bilalakhtar> bdrung: god knows
<bilalakhtar> BlackZ: my changelog entry is "Fixes unspecified dependency on python2.6-pycurl (LP: #596062).
<bdrung> BlackZ: yes, because it's obvious that dependencies are declared in debian/control.
<BlackZ> bilalakhtar: I seen, but I'd add "Added python2.6-pycurl in build-depends for fix bar (LP: #596062)"
<BlackZ> BTW, it's a your choice
<bilalakhtar> BlackZ: well, this is the first time I am fixing a bug on a main package.
<bilalakhtar> so I am a noob in this case ^^
<bdrung> bilalakhtar: it's irrelevant where the package is. if you can maintain a package in universe, it's the same for it in main.
<bilalakhtar> bdrung: well, one needs to be more careful with main.
<BlackZ> bdmurray: are you working on the freemind merge?
<bdrung> bilalakhtar: you need to be careful with universe, too ;)
<BlackZ> ops, I meant bdrung
<bdrung> BlackZ: currently not - i got one request.
<BlackZ> sorry bdmurray, tab mistake
<bilalakhtar> BlackZ: That's what I was thinking. Why will Brian work on merges?
<BlackZ> bilalakhtar: why can't he?
<bilalakhtar> BlackZ: he is the bug manager, right
<bilalakhtar> ?
<BlackZ> bilalakhtar: yes, so?
<BlackZ> bdrung: OK, so could I start to work on it?
<bilalakhtar> BlackZ: Ok, my mistake.
<bdrung> BlackZ: yes (maybe we can sync the package)
<bilalakhtar> ok, devels, I am leaving.
<bilalakhtar> happy developing!
<BlackZ> bdrung: I will take care of the changes to see if they're still relevant
<bdrung> BlackZ: will you need a sponsor?
<BlackZ> bdrung: yes
<bdrung> BlackZ: ping me once you are ready
<BlackZ> bdrung: I will, thanks :)
<ScottK> slangasek: Would you have a moment to binary promote libpackagekit-qt-14.  It only landed in Main on i386 for some reason.
<slangasek> ScottK: and on armel - fixed for the others
<ScottK> slangasek: Thanks.
#ubuntu-devel 2010-06-20
<Sangeeth> How can i contribute to development in Ubuntu?..
<micahg> !development | Sangeeth
<ubottu> Sangeeth: Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment
<Sangeeth> Actually, I look forward to join the Kernel Team...
<micahg> Sangeeth: so, in that case, #ubuntu-kernel would be a good place to hang out
<Sangeeth> micahg : But, I found no one to reply me in that room :(
<micahg> Sangeeth: well, there's not too much activity on the weekend in some channelse
<micahg> slangasek: BTW, a new version of aptitude was uploaded to unstable today which takes care of the dep wait problem that the current version is happening due to a component being in universe
<wireshark> at #ubuntu noone can help me with my problem
<wireshark> i can't install the media plugin, could anyone tell how to install it?
<wireshark> i am trying to install it about a week  but i can't install it
<tsdgeos> anyone knows why the poppler package for maverik does not include the poppler-cpp library?
<ScottK> tsdgeos: Was it there before?
<tsdgeos> ScottK: it's a new library
<ScottK> tsdgeos: The package changelog says "    - don't build the cpp wrapper for now".  seb128 uploaded it, so I'd suggest ask when he's around.
<slangasek> micahg: hmm, I was figuring all of those universe dependencies to be candidates for MIR
<slangasek> micahg: but merging is probably easier than doing that paperwork (I hope... that was a painful merge to get right :/)
<micahg> slangasek: well log4cxx was dropped as an rdepends, so one less MIT
<micahg> *MIR
<slangasek> right
<slangasek> actually, that was the only sourceful promotion needed, so that's definitely a win :)
<micahg> slangasek: k, sorry, I wish I had time to help with that
<slangasek> no worries
<superm1> slangasek, could you poke the mythbuntu cd builds?  i've been seeing 'W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/maverick/main/binary-amd64/Packages.bz2  Hash Sum mismatch' for several days now (but the livefs is generating fine)
#ubuntu-devel 2011-06-13
<ion> Huh. Why is a beta version of Firefox 5 in natty-proposed?
<micahg> ion: to build the new language packs and for extended user testing, natty getting Firefox 5 as a security update on June 21
<micahg> it's more of an RC, but it's from the "beta" channel
<ion> Upgrading Firefox 4 to Firefox 5 is guaranteed not to break anything? All extensions will be compatible?
<micahg> ion: no, but we have no choice
<lifeless> ion: upstream are not supporting 4
<ion> How nice
<lifeless> ion: and backporting security fixes from 5 to 4 is ... an interesting proposition
<micahg> ion: last number I saw was 76% extension compatibility
<micahg> Lucid and Maverick will be upgraded in the future as well, but for the moment 3.6 is supported
<directhex> okay. i've isolated the thing that breaks mono on arm.
<directhex> well, "isolated"
<cjwatson_> slangasek: given that debconf switched to git somewhere in there, perhaps the best strategy is either something like rebase-foreign, or else stitch something together with import-dsc; I expect it will be somewhat manual in any event ...
<jamespage> morning
<directhex> gcc 4.6. specifically ubuntu's gcc-4.6
<jamespage> please could a member of the archive admin team reject 'libpam4j' from the new upload queue - thanks
<cjwatson_> jamespage: done
<jamespage> cjwatson: thankyou
<cjwatson> slangasek: I've applied the GtkAssistant patch to debconf upstream now, for the next release
<directhex> cjwatson: afaik both gcc 4.5 and 4.6 on ubuntu should target the same thing, right? i see the same --with-arch, --with-mode and --with-fpu flags for both
<cjwatson> I hadn't heard of target changes there, which doesn't necessarily mean there are none
<directhex> i see a few removed flags as the only differences (--enable-gold --enable-ld=default --with-plugin-ld=ld.gold)
<directhex> i want to be absolutely sure that i've done everything possible on my side - but i can't see much more I can do with my area of competence than say "an unmodified upstream tarball is okay with ubuntu gcc-4.5, and 4.6 on all arches except arm, so I think the issue is gcc-4.6 on arm"
<cjwatson> directhex: have you tried building with -O0 on armel?
<directhex> cjwatson, no. i'll do that next. see you in some hours!
<cjwatson> directhex: if that works, bisect optimisation flags to try to narrow it down
<cjwatson> similarly if you're using any -fthingy options then play with those
<cjwatson> directhex: there's no way to do anything incrementally?
<directhex> cjwatson, not in a way i trust. it's "successfully" building the runtime, but the built runtime is "bad" and won't execute code properly. and i don't want to only partially rebuild when i don't know which thing is choking
<cjwatson> directhex: *nod*
<cjwatson> frustrating.
<directhex> when you've been at it since friday morning, mostly waiting for builds to finish, yeah
<directhex> anyone got a super fast ARM board to mail me?
<debfx> cjwatson: http://people.canonical.com/~ubuntu-archive/seeds/kubuntu.oneiric/ doesn't seem to get updated from the branch
<cjwatson> hmm
<Daviey> pitti: Am i correct in saying with http://bugs.debian.org/616318 , you were expecting the Depends to remove dpkg-dev (Ubuntu delta) and NOT the Build-Depends which the DM has done?
<ubottu> Debian bug 616318 in dpkg-repack "dpkg-repack: Please drop unnecessary dpkg-dev dependency" [Normal,Fixed]
<cjwatson> debfx: fixed, sorry about that - thanks for the report
<directhex> cjwatson, the complete build isn't finished, but it looks like the -O0 build is okay
<cjwatson> OK, so now you get to figure out which optimisation broke it :-/
<directhex> is O1 worth trying? i know it's the same as O2 on some compilers, i don't remember if that includes gcc
<cjwatson> -O1 is not the same as -O2 and is worth trying
<cjwatson> gcc.info has the list of exactly which optimisations each one turns on
<directhex> look like about 27 extra -ffoo flags from o0 to 01, and same from o1 to o2. so really, o1 is a bisect anyway :p
<cjwatson> directhex: sure, it's just the first obvious-and-useful bisect
<directhex> i just wish this process were faster :p
<speakman> http://askubuntu.com/questions/120/how-do-i-avoid-the-s-to-skip-message-on-boot
<speakman> Looks like nobootwait doesn't work
<directhex> cjwatson, getting there. O1 seems fine.
<pitti> jelmer: any SRU needs a corresponding bug to track, so subscribing ~u-sru to the bug will do
<pitti> jelmer: u-sru does sponsor the odd upload, but it's not its primary role indeed
<jelmer> pitti: ok
<pitti> Daviey: correct; it doesn't matter as a build dependency
<jelmer> pitti: Thanks, I'll link a bug
<smoser> in a modified debian package, should Vcs-* be changed ? it seems there are a fair amount of different solutions
<smoser> XS-Debian-Vcs-* , Xs-Vcs-*, XSBC-Original-Vcs-*
<smoser> the '-Debian' seems to make the most sense to me, but google doesn't seem to find anything clear cut on what we should be putting
<smoser> other than this thread: https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023332.html but doesn't look like anything completely decided there.
<cjwatson> smoser: we settled on XS-Debian-Vcs-*, but I don't have a reference for you
<smoser> so should that always be changed if there is a change made ?
<cjwatson> smoser: generally I think so, but it's not vital or anything
<apw> does anyone have oneiric nerwork manager working with wifi ?
<apw> and is the branding all sick or is something wrong with my install
<jibel> a
<jibel> apw, bug 796286
<ubottu> Error: Launchpad bug 796286 could not be found
<jibel> apw, it's private subscribing you
<apw> jibel, thanks
<apw> pitti, is the apport retracer working ok ?
<apw> pitti, the bug above seems to be marked for retracing, but 22 hours has gone past ... hmm, suspect not so well
<mterry> doko__, got a mir for you when you get a chance: bug 491644
<ubottu> Launchpad bug 491644 in deja-dup (Ubuntu) "[MIR] deja-dup and friends" [Wishlist,New] https://launchpad.net/bugs/491644
<mterry> kees, same for you -- I subscribed you to librsync in that bug  ^
<micahg> mterry: kees is off this week
<mterry> micahg, ah, thanks
<directhex> cjwatson: bisecting is slow, but yielding results. it's one of these: -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fschedule-insns
 * Daviey has come across 2 packages today where the only Ubuntu delta is dropping Depends on locales-all.. Why don't we have this?
<Daviey> would it be cheaper to have a locales-all meta package to locales, than maintaining this?
<slangasek> locales-all and locales aren't the same thing; locales-all is a package that contains pre-generated locales for all packages
<slangasek> what packages have a dependency on this in Debian?
<Daviey> slangasek, i just saw python-django... and there was another one i uploaded yesterday... lemme check
<slangasek> a quick look at stable shows only openoffice.org-l10n packages, gforge-web-apache2, and libc6
<slangasek> python-django> no earthly reason that should depend on locales-all in Debian either
<slangasek> and I don't see that it *does* in unstable or stable
<Daviey> slangasek, is your search returning build-depends aswell?
<slangasek> oh, you didn't say build-depends ;)
<Daviey> sorry
<slangasek> locales-all as a metapackage depending on locales *definitely* wouldn't satisfy a build-dep
<slangasek> packages that need locales at build time should really generate them themselves
<slangasek> that's in both Debian and Ubuntu, I mean
<Daviey> Hmm
 * Daviey is looking for the other example
<Daviey> Gah, can't find it - i was certain i saw another.
<slangasek> Daviey: well, python-django in unstable seems to have added a build-dep alternative on the en langpack, so it looks like that delta could be dropped now
<slangasek> also, I've just looked up the correct env vars and commandlines to use a locale from a local directory, so I'll probably submit that as a patch to python-django and blog the recipe for later use
<Daviey> slangasek, I'll watch out for that, thanks.. Kinda frustrated i can't find the other package i saw it.
<slangasek> Daviey: libapache2-mod-perl2? php5?
<Daviey> slangasek, was just looking at php5 :)
<Daviey> locales-all. -- Now has alternative language-pack-de for use in tests. <--
<Daviey> but yes, the one i was thinking of was libapache2-mod-perl2
<Daviey> thanks
<smoser> Daviey, slangasek i had tried building python-django, tihnking it might just build
<smoser> but http://paste.ubuntu.com/626043/
<Daviey> slangasek: So, it seems the delta with python-django was never needed.. Seems that it was really an issue with sbuild's dep handling.
<slangasek> Daviey: ah, heh
<Daviey> (works in pbuilder, fails in smoser's sbuild)
<slangasek> right
<Daviey> guesing, http://bugs.debian.org/403246
<ubottu> Debian bug 403246 in sbuild "sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable" [Important,Fixed]
<micahg> that's a config option for sbuild IIRC, works fine in LP
<micahg> as long as it's not a versioned build-dep first
<Daviey> bah, it shouldn't matter
<micahg> Daviey: in Debian, only the first alternative is used, so it makes sense as a default
<Daviey> micahg: you are saying that it is OK for this to FTBFS, Build-Depend: foo (>=X) | bar ?
<micahg> Daviey: no, that's due to LP using an old hacked version of sbuild IIRC, I have a bug filed for it
<Daviey> ah, i see
<slangasek> bug filed for what?
<micahg> slangasek: versioned alternative build-deps failing
<Daviey> against soyuz i assumed.
<slangasek> oh, ok
<micahg> bug 594916
<ubottu> Launchpad bug 594916 in Launchpad Auto Build System "buildd doesn't correctly check versioned ORed build-dependencies" [High,Triaged] https://launchpad.net/bugs/594916
<Daviey> oh joy.
<smoser> but this is not versioned.
<smoser> so we should be fine on this as a sync at least.
<micahg> smoser: so your local sbuild has a config option for that
<Daviey> smoser: bah, we were quite happy spinning off on a tangent then.
<Daviey> smoser: Yeah, switch to a sync please :)
<smoser> micahg, oh? well i just built sbuild from oneiric for my natty system
<smoser> so that will "just work" also i would hope
<Daviey> smoser: lets see :)
<smoser> although it failed, wanting me to run : sbuild-update --keygen
<smoser> which is still waiting on some entropy
<micahg> smoser: look for this line in /etc/sbuild/sbuild.conf: #$check_depends_algorithm = "first-only";
<Daviey> i'm gonna dput the debian package to a PPA just to satisfy my curiosity, as i'm not sure i can wait for the sync. :)
<smoser> so that needs to be 'alternatives', eh?
<smoser> so is that bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403246 not valid ?
<ubottu> Debian bug 403246 in sbuild "sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable" [Important,Fixed]
<micahg> smoser: it is fixed, just not the default :)
<smoser> ah. but it was fixed in 0.62, which was still > my natty version
<Daviey> smoser: we'll see what happens: https://launchpad.net/~davewalker/+archive/junk/+sourcepub/1772041/+listing-archive-extra
<smoser> i need 279 bytes of freaking entropy
<smoser> oln my headless sytem
<smoser> damamnana
<Daviey> smoser: you need an entropy key :)
<smoser> jdjdjdjdksadf
<smoser> salkfirirmenw
<sbeattie> smoser: does it have a working tpm chip?
<smoser> wonder why i never had to do this before
<smoser> probably not, sbeattie
 * smoser apologizses for random keys to channel
<mdeslaur> hehehe
<nigelb> smoser: cat on the keyboard? :)
<mdeslaur> smoser: those are the exact same random keys I use!!
<smoser> yeah, every one can now guess my keys.
<smoser> darn.
<smoser> will start again
<Daviey> smoser: if you still can't find enough entropy, let me know the details you want and i'll generate it here and email it across.
<Daviey> (Don't worry, i'll encrypt the private key before emailing it!)
<smoser> well, i did get enough.
<smoser> i did the same thign on my laptop here.
<smoser> but then ran into another issue... that sbuild doesn't seem to happy on natty.
<jono> is ldm safe to use in Oneiric yet?
<stgraber> jono: ldm has been perfectly usable for years ;) (ldm == LTSP display manager)
<jono> stgraber, :-)
<jono> LightDM :-)
<stgraber> jono: now, for lightdm, I'm using it and it "works for me"
<jono> stgraber, how do I enable it instead of GDM?
<stgraber> jono: in my case I just tried it with: sudo stop gdm && sudo start lightdm
<saamm> hello, what does mouse polling rate = 0 mean in Ubuntu?
<stgraber> jono: not sure how to change the default though (but I got prompted when installing lightdm, so it's probably some debconf magic)
<jono> thanks stgraber
<LaserJock> would a dpkg-reconfigure gdm work?
<stgraber> I'd think so, yes
<stgraber> jono: np
<saamm> is there a wiki page on mouse polling rate?
<lynxman> ping slangasek
<slangasek> lynxman: hi there
<lynxman> slangasek: hi o/
<slangasek> I assume you got my email :)
<lynxman> slangasek: I've just got your email yeah :)
<lynxman> slangasek: would it be okay if I fix all these issues and upload a new version tomorrow?
<slangasek> lynxman: certainly
<lynxman> slangasek: excellent, thank you very much for the email :)
<slangasek> lynxman: when you've done so, please ping me to have another look at the package, so it doesn't just end up at the end of the queue for whichever archive admin next processes NEW
<lynxman> slangasek: I'll do so, thanks :)
<slangasek> lynxman: do you agree that it's ok to combine these plugins into a smaller number of packages, or are there reasons that we want one binary package per plugin?
<slangasek> I'm assuming it's possible to enable/disable plugins at runtime using a config file
<lynxman> slangasek: there's architectural reasons for it
<lynxman> slangasek: exactly!
<lynxman> slangasek: and each plugin has its own set of dependencies
<slangasek> ok
<slangasek> well, most of the plugins don't have interesting dependencies
<slangasek> half of them depend on puppet and only puppet
<lynxman> slangasek: hm yeah, I just copycatted the way they've done it upstream
<lynxman> slangasek: I have direct contact with the author though, and he's in UK time
<lynxman> slangasek: so I'll ping him tomorrow morning and see what he says about the suggestion as well, it sounds more than reasonable
<slangasek> ok, let me know what you guys decide either way
<lynxman> slangasek: will let you know as soon as I know as well ;)
<slangasek> Daviey: Debian bug #630421, fwiw
<ubottu> Debian bug 630421 in python-django "python-django: please build needed locale at runtime instead of build-depending on locales-all" [Wishlist,Open] http://bugs.debian.org/630421
<directhex> -frerun-cse-after-loop
<cjwatson> pitti: so, live-build seems to have saved a couple of megabytes, but it's obscured by (a) libegl1-mesa (b) python3.2 and (c) mono 2.10 (as warned by directhex) having eaten a chunk of space between them
<cjwatson> pitti: unfortunately cdimage was ENOSPC for a couple of days so comparison data is hard to come by
<directhex> once i've beaten this armel thing i can focus on getting mono apps and their disk usage back under control
<directhex> this is my confirmation build right now as to the problem flag
<cjwatson> pitti: you can look at successive livefs builds on http://cardamom.buildd/~buildd/LiveCD/oneiric/ubuntu/ from the DC - 20110613.2 is the first live-build one there
<broder> cjwatson: +1, congrats, etc :)
<Daviey> slangasek: looks elegant!
<RAOF> What's pulling libegl1-mesa onto the CD?
<RAOF> Ah, cairo.
<slangasek> ah, python3 has found its way on now, has it?
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/rdepends/ALL/libegl1-mesa
<bryce> RAOF, cairo??
<slangasek> cairo?  sounds like a bug then :)
<cjwatson> slangasek: lsb-release
<bryce> RAOF, leftover from wayland?  (*small tear*)
<slangasek> cjwatson: heh, ok
<RAOF> slangasek, bryce: I don't think it's a bug; the ARM guys were porting the cairo gl backend to autoselected gl/egl.  If that's landed then I'd expect a dep on both.
<slangasek> RAOF: "a dep on both" - I would certainly consider that a bug, intended or not
<slangasek> I would expect an egl dep on armel, and a gl dep elsewhere
<RAOF> Oh.  Ra raw.  Hello memory usage bugs on nvidia!
<slangasek> or at most, an ORed dep satisfied by the sensible alternative on each arch
<RAOF> slangasek: That would require cairo backends to be loadable; they aren't.
<slangasek> no, it would just require us to build for the sensible backend on each arch :)
<slangasek> who needs an egl backend on x86?
#ubuntu-devel 2011-06-14
<RAOF> Wayland :)
<slangasek> sigh
<lifeless> gl is overrated
<slangasek> RAOF: well I don't see wayland on the CD either, so let's split it into a separate Conflicts/Replaces/Provides: libcairo2 build? :)
<RAOF> slangasek: Things will undoubtebly have versioned depends on libcairo2.  I guess we could rebuild all the rdepends, though.
<ohsix> is there a way to get aptitude to say what source a package is from, like -proposed or whatnot
<ohsix> also theres a new debdiff on #651931 sponsors was only just removed not long ago, can someone look and see if it's appropriate to re-add them?
<ScottK> appropriate to readd is you think so.
<ohsix> ok, wasn't sure; don't want to annoy the subscribers :]
<ohsix> and sponsors is already back on there, so nevermind me
<broder> i don't think anybody gets e-mailed directly from being on ~ubuntu-sponsors
<broder> but subscribing sponsors causes it to show up on the sponsorship queue (http://reports.qa.ubuntu.com/reports/sponsoring/index.html)
<ohsix> ok good to know
<basix> can someone please take a look at this bug? https://bugs.launchpad.net/unity/+bug/791660 It needs triaging.
<ubottu> Ubuntu bug 791660 in unity (Ubuntu) "Dual-Screen setup broken in Unity (natty)" [Undecided,New]
<micahg> basix: #ubuntu-bugs is generally for bug triage
<basix> micahg, thanks
<fattire> holy crap...  this 9 year old issue is STILL  not patched https://bugzilla.gnome.org/show_bug.cgi?id=86382
<ubottu> Gnome bug 86382 in window list "Fix window list on vertical panels (with possible rotation)" [Major,New]
<fattire> nothing big-- just vertical gnoem-panels.
<fattire> "new" hah
<charlie-tca> That's Gnome bugzilla, new doesn't always mean "new"
<ScottK> That and you probably want to troll in #gnome or wherever they hang out.
<ScottK> There are bugs I filed in the mozilla bugzilla in the 90s that are still open.
<ScottK> Or pre mozilla 1.0, whatever decade that was in.
<ajmitch> back when it crashed every 30 seconds
<ScottK> No.  Pre-mozilla 1.0, not pre-firefox 1.0.
 * ajmitch is remembering the mozilla milestone releases, long before firefox was around
<ScottK> OL
<ScottK> OK
<ajmitch> I probably still have them on an old computer
<ScottK> It seemed reasonably stable to me, but that was a long time ago and I was probably comparing it to IE.
<ajmitch> this was also when I was building KDE from CVS HEAD & using it as my main desktop
<ajmitch> the days of being young & foolish
<micahg> pitti: BTW, the retracer never made it to my lightdm bugs
<pitti> apw: I restarted it
<pitti> cjwatson: oh, thanks! we can still compare them to the regular daily ones on cdimage, or are they disabled now?
<pitti> micahg: presumably these are for oneiric? we don't have an oneiric retracer yet, and apport disabled still
<micahg> pitti: ah, yes, when do the retracers for oneiric get started?  I figured apport's disabled because you don't want a flood of crashes, but if one enabled it retraces would occur
<pitti> micahg: mostly because in the first weeks of a release, the maintenance of the chroots is quite horrible, and not worth the effort
<pitti> micahg: we usually enable them around alpha-2
<pitti> before that, the daily churn of updates is so high that we often get fixes before even seeing reports
<micahg> pitti: hmm, what should I do in the mean time, lightdm keeps crashing :)
<pitti> you can still report it with a locally generated stack trace
<micahg> robert_ancell: ^^^
<robert_ancell> micahg, ah, that explains it
<robert_ancell> micahg, are you still getting crashes in 0.3.7-0ubuntu2?
<micahg> yep
<robert_ancell> micahg, :( I'm in the process of finishing off 0.4.0.  Has a few small fixes and lots more paranoid code.  Hoping this will help, if not need those stack traces!
<micahg> robert_ancell: k ,I'll close the bugs and wait for 0.4.0, if I still get the crash, I"ll retrace locally and file, BTW, I gave you a bug on icons earlier
<robert_ancell> micahg, yeah I think the icons have moved around in GNOME3, haven't looked into it yet
<pitti> micahg: oh, does it stop crashing if you install gnome-icon-theme-full?
<micahg> pitti: idk, I can install that and see what happens
<pitti> cjwatson: congrats for getting live-build working! yay for shared code
<didrocks> good morning
<dholbach> good morning
<geser> tkamppeter: Hi, is it expected in oneiric that my printer stops printing until I modify the queue to have the uri contain the serial number?
<apw> pitti, thanks
<pitti> RAOF, directhex: hmm, is libmono-dev obsolete? I can't install cli-common-dev and libmono-dev at the same time now, but packages like launchpad-integration b-dep on both
<RAOF> pitti: Yes.  It's now libmono-2.0-dev.  But launchpad-integration shouldn't really b/d on it; it's for apps which *embed* a mono runtime.
<RAOF> And I presume that launchpad-integration doesn't embed a JIT engine :)
<StevenK> ... it might
<StevenK> :-)
<RAOF> pitti: libmono-cil-dev contains mono.pc, for those cases where libraries want to go âdo I have a mono runtime, should I build CIL bindings?â.
<pitti> RAOF: ah, that's the one that Breaks: libmono-dev (<< 2.10~)
<pitti> but libmono-dev is NBS, so there is no 2.10 version
<pitti> so that Breaks: looks wrong
<RAOF> Well, it contains a file conflict, so it declares a Replaces: libmono-dev (<< 2.10~), but it doesn't actually provide the things that libmono-dev provides (ie: the ability to link to the JIT engine).
<pitti> RAOF: right, but mono stopped building libmono-dev
<RAOF> Yeah.  It got renamed to libmono-2.0-dev
<pitti> RAOF: ah, thanks; I'll update l-i's b-deps then
<RAOF> Anything that *actually* build-depends on libmono-dev as an embed-mono-into-my-app library isn't satisfied by libmono-cil-dev, and should go to libmono-2.0-dev.  Anything that build-depended on libmono-dev to pick up mono.pc should build-depend on libmono-cil-dev.
<apachelogger> robert_ancell: ping
<cjwatson> pitti: compare> live-build images *are* the regular daily builds now
<robert_ancell> apachelogger, hi
<apachelogger> robert_ancell: ahoy, is LightDM covered by the canonical contributor agreement?
<robert_ancell> apachelogger, no
<apachelogger> robert_ancell: ever going to be?
<robert_ancell> apachelogger, no
<apachelogger> ok, thanks :)
<robert_ancell> apachelogger, the greeter we develop will be afaik, but the rest of it now
<robert_ancell> now
<robert_ancell> no
<robert_ancell> ignore those extra w's
<apachelogger> robert_ancell: http://lists.kde.org/?t=130799239200004&r=1&w=2
<apachelogger> robert_ancell: you might have a comment on http://lists.kde.org/?l=kde-core-devel&m=130803242022398&w=2
<RAOF> slangasek: Incidentally, rock on the multiarch.  Mesa works very nicely.
<seb128> ev, hey, let me know when you are around to speak about cheese
<seb128> pitti, so new cheese depends on the clutter stack as you noticed, we wouldn't really need it in main out of the fact that ev wants to use it in ubiquity to take user pictures
<pitti> *nod*
<ev> hi seb128, I'm around now
<seb128> hey ev
<seb128> ev, the discussion shifted a bit since, new totem will use clutter-gst as well and empathy will use libcheese in at least an optional way
<pitti> tseliot: hm, I just fixed the FTBFS of xorg-options-editor-gtk, and converted to dh7+dh_python2, but it's still broken
<pitti> tseliot: it depends on libpolkit-gnome0 (which was dropped ages ago), and uses glade, etc.
<pitti> this would need some serious porting
<pitti> is it actually still useful? we don't even have binaries of this package for any supported release, last upload was in jaunty
<tseliot> pitti: probably not. bryce should write a better tool for failsafe-x
<pitti> tseliot: so it seems we should just remove the source instead?
<pitti> it wouldn't actually change anythign visible for users, as there are no .debs anyway
<ev> seb128: okay, I'll pay close attention to that thread on warthogs.
<tseliot> pitti: yes, that would be fine
<pitti> tseliot: ok, doing; thanks!
<ev> seb128: ultimately we need this functionality, whether it comes from cheese or not.
<tseliot> pitti: thanks for your help
<seb128> ev, right
<ev> I talked to the design team yesterday (John Lea) and he said it was a requirement for their ongoing work
<ev> okay
<seb128> ev, well clutter is probably fine for your usecase
<seb128> we have 2 discussions to have there, one being a CD space one for clutter, the second one being about whether we consider clutter going enough to handle our video rendering
<ev> right
<Daviey> cjwatson: thanks for attacking the sync queue.
<cjwatson> np
<tkamppeter> pitti, Mike Sweet accepted my USB URI migration patch and my patch to support USB-to-parallel adapters.
<geser> tkamppeter: Hi, is it expected in oneiric that my printer stops printing until I modify the queue to have the uri contain the serial number?
<tkamppeter> geser, no. It should simply print.
<tkamppeter> geser, if you have a cheapo laser from HP, you will need an additional foo2zjs update depending on your configuration.
<geser> tkamppeter: no, a Kyocera FS-1010
<geser> the printer got stopped because the "usb backend failed", the cups log suggested to readd the queue to get the serial number added
<geser> and after modifying the queue the printer started to print again
<geser> the queue changed from "usb://Kyocera/FS-1010" to "usb://Kyocera/FS-1010?serial=..." (can diff the printers.conf again when I'm home again)
<mdeslaur> !pilot in
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<pitti> tkamppeter: oh, nice!
<juliank> sabdfl: Could oneiric + 1 include penguin in the name please?
<juliank> That's a chance you don't get every time.
<ogra_> heh
<juliank> ogra_: I just don't want to wait until "tinkering tux"
<lynxman> ping Daviey
<sabdfl> juliank: maaaayybe
<smoser> stgraber, was i mistaken ? i thought you had loaded x2go client into the archive.
<stgraber> smoser: I have python-x2go in the archive, not x2goclient (yet)
<smoser> i was under the impression that python-x2go sat on top of x2go-client.
<stgraber> nope, it uses python-paramiko for ssh and nxproxy for the X rendering part
<Cas07> hi im trying to backport a PPA to lucid and karmic but i get this error in buildlog
<Cas07> dh clean --with python2; dh: unable to load addon python2
<OdyX> Cas07: dh_python2 has not been backported yet.
<tumbleweed> Cas07: dh_python2 hasn't been backported to lucid yet (bug 788524), and won't be backported to karmit (out of support)
<ubottu> Launchpad bug 788524 in python-defaults (Ubuntu) "backport dh_python2 to lucid (and maverick if appropriate)" [Undecided,In progress] https://launchpad.net/bugs/788524
<Cas07> hrmm
<Cas07> thanks for that, OdyX, tumbleweed
<Cas07> the old package used --with quilt what is the difference?
<tumbleweed> Cas07: two, unrelated changes. First it must have switched from using quilt explicitly to source format 3.0 (quilt) where the patching is handled by dpkg-source. Second: it switched from (presumably) python-support to dh_python2
<Cas07> ahh silly me
<Cas07> so if i add python-support as a build dep and just remove python2 is should be ok
<tumbleweed> Cas07: it may easily be more complicated than that, I'm afraid
<Cas07> is there any way to test the build other that sending to launchpad?
<Cas07> oh i suppose if i make those changes it would complain on my system if it was wrong
<tumbleweed> Cas07: you can test build on your own hardware, yes
<Cas07> how would i get that same error for karmic or lucid builds? as they build the debs fine for me
<Cas07> obviously i now know the issue but its more for the future
<tumbleweed> Cas07: about time to move this out of #ubuntu-devel, I think. #ubuntu-packaging?
<Cas07> oh sorry
<lynxman> ping slangasek
<frafu> Hi pitti. We have an error building onboard (trunk) with dist-utils-extra and we are wondering whether we should work around it or whether dist-utils-extra is going to be adapted. marmuta, who is working on onboard left a comment about it in a bug thread marked as fixed: https://bugs.launchpad.net/python-distutils-extra/+bug/746565 Could you please have a look at it if you have time? Thanks.
<ubottu> Ubuntu bug 746565 in python-distutils-extra (Ubuntu Natty) "Ignore explicitly relative 'from' imports when scanning for dependencies" [Undecided,Fix committed]
<pitti> frafu: hi
<pitti> frafu: if it's a regression in -proposed, then we'll fix it of course (and not publish it to -updates)
<frafu> The problem is happening also in oneiric.
<pitti> right, because the change landed in oneiric first
<frafu> pitti: Do you need more information to fix it? In that case, I will tell marmuta to provide it in the bug thread mentioned above.
<pitti> frafu: this can be reproduced just by trying to build onboard in oneiric?
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> frafu: if it requires more steps, a reproduction recipe would be appreciated
<slangasek> lynxman: hi there
<lynxman> slangasek: morning :)
<lynxman> slangasek: I uploaded a new package to the ppa with all the corrections, let me know what you think
<lynxman> slangasek: https://launchpad.net/~lynxman/+archive/ppa
<slangasek> lynxman: sorry, what ppa is that?  The package I was reviewing was in the Ubuntu NEW queue... ah :)
<lynxman> slangasek: that's where zul got the one that he sponsored from :)
<frafu> pitti: Yes, it is reproducible by simply trying to build a checkout of the trunk of onboard. Thanks for fixing it when you have time.
<pitti> frafu: https://code.launchpad.net/~onboard/onboard/main?
<frafu> pitti: yes
<free`> hello anyone using bzr merge-upstream?
<free`> I'm trying to run a command like "bzr merge-upstream --version 0.18.1+bzr393 ../storm-0.18.1+bzr393.tar.gz" but it looks I don't get tags created properly
<free`> http://pastebin.ubuntu.com/626639/
<free`> maybe I'm doing something wrong?
<free`> (see "upstream-0.18.1+bzr393 ?" I assume it should be "upstream-0.18.1+bzr393 1.1.5")
<ondrej> Hi, when and how is new Debian packages pulled to Ubuntu?
<ondrej> I wonder why golang hasn't been picked up yet.
<free`> nevermind, solved, I had to commit the packaging head
<mterry> doko, heyo, sorry if this is a repeat, but I'd like a MIR review for bug 491644 when you get a chance
<ubottu> Launchpad bug 491644 in deja-dup (Ubuntu) "[MIR] deja-dup and friends" [Wishlist,New] https://launchpad.net/bugs/491644
<doko> mterry: yes, seen. yesterday was bank holiday. will do it later today
<mterry> doko, yar, figured
<mterry> doko, thanks!
<pitti> mterry: it actually is oneiric-alpha-1, just the betas lose the code name :)
<mterry> pitti, guh!
<pitti> mterry: I fixed your spec harder
<mterry> pitti, :)  thanks.  Seems confusing?  Is there a reason we don't accept either form?
<pitti> mterry: it's just what LP defines
<pitti> look at the spec's milestone selector
 * mterry grumbles
<pitti> https://launchpad.net/ubuntu/oneiric, see "Milestones"
<Kaleo> I get an error during the setup of the 'at' package in an Oneiric freshly created chroot: chown: invalid user: `daemon:daemon'
<pitti> oh-uh -- daemon is a static uid
<Kaleo> the schroot was created with debootstrap on lucid
<pitti> debootstrap should create it
<mterry> pitti, I would almost accept that there is some method to that madness (like, a progression from development to 'baked') if the updates weren't called oneiric-updates
<pitti> mterry: oh no, that would be consistent!
<Kaleo> pitti: what's even more odd is that there is no user daemon on the host machine
<Keybuk> IP=`ifconfig  | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'|head -n 1`
<Keybuk> kirkland: seriously, you put ^ *that* in a shell script this year?
<kirkland> Keybuk: not *I*
<kirkland> Keybuk: just shit I found
<kirkland> Keybuk: in packages I've reviewed
<Keybuk> hey, it's in your branch ;)
<Keybuk> http://bazaar.launchpad.net/~kirkland/principia/oneiric/musica/trunk/view/head:/hooks/website-relation-joined
<kirkland> Keybuk: right, from SpamapS :-)  which is the straw that broke the camels back, and forced me to post https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033459.html
<kirkland> Keybuk: so yes, i duplicated the mistake
<Keybuk> tsk tsk
<kirkland> Keybuk: on purpose to demonstrate the need for a better, unified utility
<Keybuk> re: your mail - again, any utility written this year should not default to IPv4
<kirkland> Keybuk: here's what I want to use: http://people.canonical.com/~kirkland/ipaddr
<kirkland> Keybuk: i agree with supporting ipv6;  but by default?  i question the utility of that
<Keybuk> kirkland: well, otherwise I'd have to go around and edit all the scripts that don't pass -6 to your utility
<Keybuk> if you're writing a tool to "return the address of the interface" it should return the address(es) of the interface
<Keybuk> if the interface only has IPv6, it should return it
<kirkland> Keybuk: right and then we're back in piping to awk/sed :-)
<Keybuk> since the IPv4 address space is nearly exhausted, you have to assume at this point that any new servers are going to be 6 only
<kirkland> Keybuk: since the utility is not yet in the archive, you're already "going around and editing all the scripts"
<kirkland> Keybuk: to use the utility
<Keybuk> kirkland: actually, I'm mostly just deleting them
<micahg> kirkland: apparently broder found a utility that already does most of what you're looking for
<Keybuk> it turns out that all the tools that want your IP address don't need it
<Keybuk> and that it's already a bad sign if they do
<kirkland> micahg: it does not detect the default route
<Keybuk> and that there's a *great* tool for determining an interface name
<Keybuk> it's called DNS
<Keybuk> ;-)
<kirkland> Keybuk: okay, what if the tool *required* either a -4 or a -6 parameter?
<kirkland> Keybuk: and dumped you to a usage statement with out it
<kirkland> Keybuk: 'ipaddr -4'
<kirkland> Keybuk: 'ipaddr -6'
<kirkland> Keybuk: 'ipaddr -6 wlan0'
<Keybuk> portal has IPv6 address 2600:3c01::f03c:18a9:0524:3620
<kirkland> Keybuk: 'ipaddr -4 eth1'
<Keybuk> kirkland: then the tool would be mis-used by all the scripts
<Keybuk> and again, pointless
<Keybuk> all the scripts would call it with just -4
<Keybuk> ^ no IPv4 address for this machine
<kirkland> Keybuk: great, then the tool should return the ipv6 address if there is no ipv4 address
<kirkland> Keybuk: DWIMNWIS
<james_w> why would anything care which type of address it got? Is the most likely reason that it doesn't support v6 yet?
<Keybuk> kirkland: I think with -4 it should only return v4, with -6 it should return only v6
<Keybuk> without arguments, it should examine many factors to determine the best address
<Keybuk> and it may well be the IPv6 address rather the IPv4 if it's a global scope address
<kirkland> Keybuk: i can go with that
<Keybuk> because you can *use* the IPv6 address to access both v6 and v4 hosts
<kirkland> Keybuk: again, i'm good with that
<Keybuk> if you returned the v4 address in that situation, you'd be cutting yourself off from the v6 Internet
<Keybuk> (default configured inet6 addresses have a Link scope - if someone has a Global scope v6, it means they really can do v6)
<kirkland> Keybuk: taking a step back, do you agree with the usefulness/mission of such a utility?
<Keybuk> kirkland: well, I'm not sure why things want the IP
<Keybuk> if things want the IP, having a tool to return it would be useful
<Keybuk> it may be better as a patch to "ip" mind you, but ...
<Keybuk> but maybe all those things that think they want the IP really really don't
<kirkland> Keybuk: configuration, setup of server utiltiies
<cjwatson> the notion that you have a single one true IP address is wrong
<Keybuk> kirkland: what configuration requires the IP?
<lool> right, if they query the IP once on startup, what will happen if you reconnect and get a different one, or get additional ones for random reasons
<cjwatson> a sane server default is usually just to listen on all interfaces, not to try to figure out the IP address in advance and listen on that
<Keybuk> cjwatson: yeah, certainly by default
<Keybuk> listening on selected interfaces is not a good default
<Keybuk> and as for communicating between ports on the server
<Keybuk> e.g. one service talking to each other
<Keybuk> that's *WHY* we have a files nsswitch
<Keybuk> use "http://localhost/..."
<Keybuk> localhost will be magically resolved to MAGIC
<cjwatson> other IPC methods may well be better than IP for that anyway
<Keybuk> (in my server's case ::1, in other's maybe 127/8 somewhere)
<Keybuk> cjwatson: sometimes; though there are lots of services that use HTTP to each other
<Keybuk> e.g. the whole Web 2.0 stack, where it's your Javascript making HTTP requests to your Node.js backend making HTTP requests to your database server, etc.
<cjwatson> yeah
<micahg> kenvandine: if folks only had a diff of the vcs-bzr, why was it a merge?
<kirkland> Keybuk: in several examples, we have a number of different services (cobbler, puppet, eucalyptus) that provision systems, and need to tell those systems (by serving a configuration file, or a preseed) where some resource lives; that location is the IP address of the server providing that configuration or preseed
<Keybuk> kirkland: no, that location should be "localhost"
<kirkland> Keybuk: sorry, no
<Keybuk> kirkland: sorry, yes
<kirkland> Keybuk: localhost then on that node will be its dumb self
<Keybuk> yes
<kirkland> Keybuk: rather than the server that it needs to federate against
<Keybuk> if you have two servers A, and B
<kirkland> Keybuk: server A provides service foo
<Keybuk> there is NO WAY for server A to know what IP address server B needs to contact it
<Keybuk> the only correct and canon way to do that is for server A to contact server B
<Keybuk> and then server B to note the IP address that server A appears as
<Keybuk> running a shell script on server A does not work
<Keybuk> let me give you a simple example that doesn't even require a 1-to-1 NAT
<Keybuk> I have three interfaces
<Keybuk> lan0, wan0, wan1
<Keybuk> wan0 and wan1 both have public IPs
<Keybuk> and both have default routes with different metrics
<Keybuk> lan0 has a private IP
<Keybuk> which IP do I give to the other server?
<cjwatson> my concern about trying to promote a standard way to get your IP address is that it takes the case of a weird multi-server setup that's making assumptions about everything being on the same subnet, and promoting it as a correct and reasonable thing to do in general
<cjwatson> in most cases where you think you need to get your IP address, it's better to redesign
<Keybuk> another example (common)
<Keybuk> I have two IPs
<Keybuk> one is a multi-homed IP which is the public address of the server
<Keybuk> this same IP is configured on 1,000 different boxes
<Keybuk> and I have a private IP which is the address of the host
<Keybuk> which IP do I give to the service?
<Keybuk> and then obviously there's the 1-to-1 NAT example, which is pretty much the defacto configuration of most data centers
<cjwatson> even on private subnets: my little house server has four interfaces one might care about, but if you're talking about stuff on a private network, there are two: one wired, one wireless, different IP addresses.  there's no useful way to say which one is more relevant without knowing what it's going to be doing
<kirkland> cjwatson: Keybuk: geez guys, I know that there are an infinite number of non-standard scenarios;  I'm simply trying to do what we do in Ubuntu all day every day -- offer a reasonable default when some other 3rd party package *requires* an ip address to be functional
<Keybuk> kirkland: no, these are *standard* scenarios
<Keybuk> "I have one true IP address that never changes" is the *non-standard* scenario
<cjwatson> your reasonable default is better handled by redesigning, honestly
<cjwatson> not by presenting a tool that fundamentally can't handle many real-world situations and never could
<cjwatson> if we present such a tool, lots of things will likely start using it instead of doing their network configuration properly
<cjwatson> and in particular this is very likely to produce things that don't work properly on v6
<infinity> The majority of times something thinks it needs to know any/all of the local IPs, it's just plain wrong on that score.
<cjwatson> I am *happier* with nasty shell hacks for non-standard servers that can't be fixed in other ways, than with presenting a standard tool that misleads people as to the right way to write network service
<cjwatson> s
 * kirkland renames his tool nasty_shell_hack_for_non_standard_servers
<cjwatson> sigh
 * cjwatson goes and eats dinner, which is going to be more productive
<kirkland> perhaps this is a matter of setting expectation
<kirkland> sometimes knowing a) the default route, and b) the ip (v4 or v6) is sufficient to accomplish a particular task
<cjwatson> honestly this is something I would leave alone.  it's better to have fundamentally dirty things look dirty, rather than putting a veneer of cleanliness over them
<kirkland> things that we're doing in ec2 all the time
<kirkland> i'm admitting i'm wrong, and retracting my suggestion to recommend this to all of Ubuntu
<cjwatson> see also the theory that proofreading badly-written wikipedia pages isn't always actually a good thing to do, because spelling errors can be a quick cognitive sign of a deeper problem ...
<kirkland> lool: agreed;  and for that reason, I regret suggesting this for general purposes
<kirkland> lool: but for an ec2 instances that's going to live a few minutes or hours ....
<kirkland> lool: and lots and lots of similar instances
<kirkland> lool: that have identical (or nearly identical) networking configurations
<lool> cjwatson: haha
<psusi> Keybuk: are you still maintaining the upstream ureadahead?  or is it basically defunct and I should just merge my changes into lp:ubuntu/ureadahead?
<lool> kirkland: perhaps the cases you mention need a bigger hammer like ensemble?
<kirkland> lool: ensemble is a place where knowing your ipaddress is necessary
<Keybuk> psusi: there isn't an upstream ureadahead
<kirkland> lool: in fact, writing an ensemble formula is the trigger for this conversation
<Keybuk> and there never has been a maintainer
<Keybuk> ureadahead is a tarball of code that worked for me once
<Keybuk> and I've always said, if others can do better, they should go right ahead
<kirkland> lool: I need to do the following, at the end of my formula:
<kirkland> relation-set ip=$IP port=80 hostname=`hostname -s`
 * lool isn't intimate enough to understand what this means
<lool> I actually need to disappear; I'll come in a couple of hours check whether my machine burnt building OE
<psusi> Keybuk: launchpad.net/ureadahead seems to be the upstream.. so you are saying just merge it into the ubuntu branch and don't worry about lp:ureadhead?
<Keybuk> psusi: if you like
<psusi> Keybuk: I'd be happy to push it upstream if you're still maintaining it... that's what I'm trying to figure out...
<Keybuk> psusi: well, there isn't an upstream
<Keybuk> as I said
<psusi> Keybuk: then what is lp:ureadahead?
<psusi> sure looks like an upstream
<Keybuk> psusi: I'm lazy and didn't like typing lp:ubuntu/
<Keybuk> and lp:ubuntu/ branches have a habit of vanishing
<Keybuk> or being replaced with something that wasn't your branch
<Keybuk> with totally different file-ids
<psusi> so is lp:ureadahead defunct?
<Keybuk> psusi: no, I'd say you should use lp:ureadahead as prime
<Keybuk> because anything you commit to lp:ubuntu/ureadhead might be replaced at any moment with something else
<Keybuk> <-- does not trust james_w's importer anymore
<Keybuk> I lost far too many branches to it
<juliank> On this side, would adding support for patching ltmain.sh files in dh-autoreconf be useful? http://anonscm.debian.org/gitweb/?p=collab-maint/dh-autoreconf.git;a=commit;h=f390910194262610cd7f059c17224989a192c965
<directhex> CFLAGS="-O1 -fcse-follow-jumps -frerun-cse-after-loop -g"
<directhex> cjwatson: reckon that's minimal enough for a bug report?
<directhex> cjwatson: those two flags together cause failure... but i haven't looked through what -O1 includes yet
<lool> haha and I thought I was kidding kernel: [17077.066227] CPU3: Core temperature above threshold, cpu clock throttled
<cjwatson> directhex: well, I don't actually deal with gcc bug reports, but I guess it's a good start
<directhex> maybe i should be asking a gcc maintainer instead... doko?
<cjwatson> directhex: they may need a rather more reduced version of the code triggering it ...
<directhex> cjwatson: reducing the signal handler in a jitter? @_@
<cjwatson> directhex: are you planning to upload mono to use -O1 on armel in the meantime?
<directhex> cjwatson: is that what you'd suggest? i can do that
<cjwatson> yes
<directhex> hm, an updated gcc within the past few days. i should update & re-test
<pseudonymous> Anyone know of any guides for UCK (ubuntu customization kit)? I'm trying to remaster from a Ubuntu Mini image (no X, down to 160mb) but neither UCK nor the mini ubuntu image site actually finds it worthwhile to describe how one would go about remastering a ubuntu livecd which has not X install
<ahasenack> hi guys, quick version comparison question
<ahasenack> I have a package versioned 11.06~bzr331-0ubuntu0.10.04
<ahasenack> it's 11.06, but not final yet
<ahasenack> in another package, I need to have that 11.06~bzr331-0ubuntu0.10.04 or higher
<ahasenack> so how would the depends look like? using >> 11.06~bzr331-0ubuntu0.10.04?
<ahasenack> or just >> 11.06?
<ahasenack> I mean, >=
<ahasenack> not >>
<tumbleweed> >= 11.06 won't watch that. but >= 11.06~ will
<ahasenack> ah, a trailing ~
<ahasenack> tumbleweed: thanks
<micahg> 11.06~bzr331~ should be sufficient if you're looking for that bzr version, if there's something in the packaging, then use the whole version, also, I'd suggest adding a .1 at the end of that version string in case you need to update it
<tumbleweed> err *match. Yes one often uses trailing ~ when you want to be able to match backports
<jelmer> 'evening
<bdrung> ahasenack: 11.06~bzr331 should do it.
<bdrung> a backport would only modify the debian revision
<bdrung> for example, we use >= 1.2.3 (no ~) and >= 1.2.3-0ubuntu3~ (with ~)
<tumbleweed> basically depend on the minimum version you need, and if it may have a ~ at the end, then include one
<Daviey> stgraber: around?
<stgraber> Daviey: yep (though I guess you noticed that from the discussion in -server) :)
<Daviey> heh... stgraber two things... Do you plan to merge nbd.. and do you know how the translations got changed in the last merge?
<Daviey> (i'm happy to do it, just wanted to check with you first as i see you have history with it)
<stgraber> Daviey: I was planning on quickly doing it last week, then I noticed that the package currently in Debian seems to be a bit of a mess :)
<stgraber> Daviey: it's really a trivial merge except the mess with the latest orig tarball, so if you have time, feel free to go ahead
<Daviey> stgraber: i noticed the tarball seemed a bit whacky
<Daviey> If it is on your radar, i'm happy to leave it..   The "fix data corruption" looked worthwhile.
<stgraber> Daviey: Now that I finally got the new arkose out, I should have some time to go through the two pending merges I have (nbd and something else). I'll probably have to poke Debian to figure out exactly what happened :)
<Daviey> stgraber: super!  thanks
<broder> hmm...it looks like usb-creator expects an ISO using grub to have a core.img and boot.img. how is the core.img supposed to be generated, though? grub-mkrescue doesn't seem to create one...
<bdrung> tumbleweed: can you  review https://code.launchpad.net/~broder/ubuntu-dev-tools/debian-backport/+merge/64318 too?
<soren> Is the server side of our rmadison thing having problems?
<tumbleweed> bdrung: I had issues with the first version, but it looks much better now. Haven't read it in detail / tested it, yet
<soren> cjwatson: ISTR this being part of (one of) your (many) area(s) of expertise? ^
<bdrung> tumbleweed: please do so. if you have time, please add online tests
<soren> cjwatson: Sorry, seems to have been transient. I coulnd't connect for about three minutes, now it's snappier than ever.
<soren> cjwatson: Ah, no, now I'm asking about a different source package, and it's hanging for a whole minute (so far).
<soren> Meh. /me goes to bed instead
<d_ed> apachelogger: you about?
<apachelogger> d_ed: and already a bit drunk
<d_ed> oh, well that's fair enough. I'll start drinking soon. I was just replying to the kde-core-devel ML.
<d_ed> I'm not on kde-core-devel,what's the general feedback been like?
<apachelogger> d_ed: doomed
<apachelogger> well
<apachelogger> first they were ranting away as usual, until I jumped in and let my insane verbosity of arguments out, we are on a good way to discussion now
<d_ed> I found a web link with people just bitching about bzr.
<apachelogger> d_ed: generally I believe that everyone who contributed to the discussion (that is me, mgraesslin and sreich) agrees that a first option should be to try get KDM to do awesomeness
<d_ed> you agree the first option should be to try and get KDM to do awesomeness?
<d_ed> I can see why sreich does - he's writing KDM Plasma.
<apachelogger> d_ed: well, yes, as upstream developer I do from a reliability and code control POV
<apachelogger> d_ed: I do not know nearly enough about DMs to make educated decisions really, all I can do is argue about the advantages and disadvantages of both and then draw a conclusion from the overall picture outlined by everyone in the discussion
<d_ed> ok
<apachelogger> to that extent I believe that there is no actually solid technical reason for not using LightDM, equally there is no solid technical reason for not trying to fix KDM
<d_ed> fair.
<d_ed> I'm 100% with the "go with whichever is better" argument.
<d_ed> and right now, that is KDM
<apachelogger> yeah, I am not sure KDM is fixable to the degree that it can actually compete with the other pre-login experiences though, perhaps the plasma stuff will help with that (power management, visual appeal, accessibility and what not)
<apachelogger> maco might have an opinion on KDM and accessibility ^^
<maco> apachelogger: last i checked you couldnt use an onscreen keyboard with kdm. don't know about getting kaccessible to work with it
<apachelogger> well, it is qwidgets, so that should be possible, on screen should also be possible with weird hackery *brrr*
#ubuntu-devel 2011-06-15
<d_ed> apachelogger: gah, posted but I'm stuck in teh moderation approval queue
<d_ed> I even signed up to the ML just before-hand.
<apachelogger> yeah, you need to be whitelisted for core-devel which usually happens after some sane mails
<apachelogger> d_ed: you could poke dfaure, though he probably is in bed already
<d_ed> no rush.
<nemo> I'm moderately confused by https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/217997
<ubottu> Ubuntu bug 217997 in Nautilus "Incorrect icons displayed for mimetypes installed in hicolor theme only" [Critical,Fix released]
<nemo> is it supposedly fixed?
<nemo> 'cause I just retested in Natty and I'm still getting that behaviour
<nemo> http://hedgewars.googlecode.com/hg/share/hedgewars/Data/misc/hedgewars-mimeinfo.xml
<nemo> basically, if I specify a generic-icon it overrides icon
<nemo> leading to less usefully identified files
<nemo> I'd retested to see if I could uncomment generic icon, but it seems it is still an issue
<nemo> the other possibility is I misunderstood the bug
<pitti> Good morning
<didrocks> good morning
<bryce> hi
<\sh> moins
<dholbach> good morning
<\sh> dholbach, good morning :) how's life in berlin? :)
<dholbach> \sh, very good very good - how about you?
<\sh> still trying to recover from our holidays in cameroon...thrilling time over there and a great country ...
<abhinav-> dholbach: good morning :) just installed tomboy 1.7 and noticed my name in the list of contributors :)
<dholbach> abhinav-, good work! :)
<dholbach> that's awesome
<abhinav-> thanks :)
<lifeless> bdrung: around ?
<bdrung> lifeless: for short
<lifeless> https://code.launchpad.net/~arnegoetje/old-lp-translations/po2xpi-devmodefix/+merge/18739
<lifeless> can you change that to 'rejected' ? the bug it was for was marked invalid
<lifeless> and its on a dead project but shows up in the lp team work queue
<bdrung> lifeless: done
<lifeless> brilliant
<lifeless> thanks
<bdrung> np
<tkamppeter> geser, hi
<geser> tkamppeter: Hi
<tkamppeter> geser, I have found a bug in the CUPS USB backend yesterday which I introduced when fixing a potential segfault. I have fixed it in 1.4.6-9 and pitti has uploaded this version around 3 hours ago. So update and your printer should work with the old URI.
<tkamppeter> geser, and thank you for reporting the problem.
<seb128> slangasek, hey, do you have libgtk2.0-0-dbg(sym) installed?
<seb128> slangasek, you need the debug symbols to be able to break on gdk_x_error
<slangasek> seb128: oh, huh - ok, installing, please close my bug :)
<seb128> slangasek, ok ;-)
<slangasek> (or maybe the error message should be extended to point at -dbgsym?)
<seb128> slangasek, could be, you are the first one to raise the issue I think ;-)
<slangasek> heh
<slangasek> nobody else gets x errors anymore, just me :(
<seb128> slangasek, so people do but in a racy way on login which makes it hard to debug :-(
<slangasek> ah, well this one happens at random when I switch virtual desktops, so I'll catch it eventually
<seb128> slangasek, ok, please install gnome-settings-daemon-dbgsym as well
<seb128> slangasek, oh, and libglib2.0-0-dbg(sym)
<slangasek> ack
<seb128> so the stacktrace if you get one is useful ;-)
<jelmer> pitti: hi
<jelmer> pitti: we have a pending SRU for bzr pending for natty-proposed, is there anything I can do to help move it forward?
<pitti> jelmer: not much more than poling SpamapS or me to process it
<pitti> we don't process the queue every day
<pitti> as we aren't right after a release, so this stuff is usually not super urgent
<jelmer> pitti: ah, ok - thanks
<cjwatson> soren: it's just a CGI script, I don't think it's changed lately - seems fine in a quick test here?
<cjwatson> broder: grub-mkrescue does create a core.img, just under the hood; look for grub-mkimage calls
<lynxman> slangasek: hey did you find the package now proper? :)
<mont> hi
<mont> i am the developer of imagemagick on debian
<mont> please sync it as written in https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/797595
<ubottu> Ubuntu bug 797595 in imagemagick (Ubuntu) "Imagemagick 8:6.6.0.4-3 debian testing" [Undecided,New]
<mont> it will avoid you big pain due to so bump after this revision
<cjwatson> There are several Ubuntu changes; it will need somebody to review and merge them if necessary
<cjwatson> and please don't make your bugs sound like a threat!
<mont> it will be pain
<mont> we had some pain on debian side
<mont> sorry to be rude nevertheless
<cjwatson> I suppose I'm the last one to have uploaded it in Ubuntu (even if trivially), so I'll have a look
<mont> expect breakage
<mont> do you have a release team for so bump transition on unbuntu side ?
<Daviey> cjwatson: When you suggested Applied-Upstream addition for dep3, were your thoughts that it could be used multiple times if you are folding a few commits into a single patch?
<cjwatson> Daviey: for me it was really just a "you can drop this patch at the next merge" thing
<cjwatson> mont: yes.  is this http://release.debian.org/transitions/html/imagemagick4.html ?
<cjwatson> that doesn't look overly painful
<cjwatson> mont: is it more than just a soname bump?
<mont> more
<mont> some package depend of n-2 lib
<cjwatson> I don't understand that
<mont> where n is imagemagick4
<mont> lib
<cjwatson> can you point me to documentation or bug references or whatever?
<Daviey> (ta)
<mont> see  http://release.debian.org/transitions/html/imagemagick4.html
<cjwatson> I already pointed to that URL, just above
<cjwatson> so you might reasonably conclude that I've seen it
<mont> the problem is depend on libmagick9-dev
<cjwatson> it doesn't provide any explanatin
<cjwatson> *explanation
<mont> previous version provide:  libmagick9-dev (old stable)
<mont> and we broke this
<cjwatson> so I'd hope that in general we can deal with this by syncing packages from that transition list from Debian (which should already have happened automatically, unless there are Ubuntu modifications), or by doing rebuild-only uploads in the case where we'd already synced them and they'd managed to build
<cjwatson> all I'm asking is whether it amounts to more than that
<soren> cjwatson: Yeah, it seems fine now. *shrug*
<cjwatson> mont: it's unfortunate that we had 6.6.2.6 in natty, but there you go
<tkamppeter> geser, is your printer working now?
<geser> tkamppeter: I'm at work right now, will test when I'm back home and let you know
<Riddell> mvo: we were discussing your query with getting merges on the software-centre packaging branch in the UDD meeting, does this help?  bug 797688
<ubottu> Launchpad bug 797688 in Launchpad itself "Ubuntu Packaging Branches Should be Labaled Clearer" [Undecided,New] https://launchpad.net/bugs/797688
<mvo> Riddell: definitely, thanks for this
<mvo> Riddell: I think its a good first step to help with the problem
<ev> mdz, cjwatson, keybuk, kees: might I ask one of your to approve my message to the TB mailing list?  Thanks.
<cjwatson> ev: doing a moderation pass now
<ev> cjwatson: cheers
<cjwatson> done
<fta> doko_, are the oneiric toolchain changes described somewhere?
<doko_> fta: which ones?
<fta> doko_, linker, compiler, ..
<doko_> fta: gcc: see the news file, if pitti didn't remove that too
<pitti> nope, only changelogs :)
<doko_> afaict there are no new features for binutils
<nobuto> cjwatson: I have a question about translations of a debian-installer component, pkgsel. In Japanese language, it contains wrong translations related Landscape(specifically Ubuntu patched translations). How can I fix that?
<nobuto> cjwatson: Just branch this, fix translations then submit merge proposal is enough? http://bazaar.launchpad.net/~ubuntu-core-dev/pkgsel/ubuntu/view/head:/debian/po/ja.po
<cjwatson> nobuto: get it fixed in Debian
<cjwatson> nobuto: I can't take Ubuntu-specific translation fixes
<cjwatson> oh, wait
 * cjwatson rereads
<cjwatson> nobuto: is it fixed in LP translations already?
<nobuto> cjwatson: Yes.
<cjwatson> nobuto: then no need for a merge proposal, I'll update from LP translations
<nobuto> cjwatson: OK. Thank you.
<cjwatson> thanks for the note
<cjwatson> (I can only do this for strings that aren't in Debian at all)
<mr_pouit> cjwatson: hey, do we have to do something on our end for the new live cd build system? Because current xubuntu dailies don't contain any xfce package apparently ;-)
<cjwatson> mr_pouit: you shouldn't have to do anything particular
<cjwatson> that is odd, I think perhaps it's failing to look at universe or something
<cjwatson> I'm doing rather too many things at once right now, but I'll clear a couple off and then have a look, thanks
<mr_pouit> okay, thanks!
<fta> doko_, well, can't find it in the NEWS file. I've spent a lot of time tracking a regression in chromium on oneiric where all versions had the html5 <video> tag broken. it happened to be a linker issue, where the position of a -lfoo led to that lib beeing silently ignored in the resulting shared lib
<cjwatson> fta:
<cjwatson> http://wiki.debian.org/ToolChain/DSOLinking
<cjwatson> also https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
<cjwatson> it was done for a large part of the natty cycle - it was just switched back temporarily for the natty release, and then turned on again for oneiric
<fta> cjwatson, thanks, now i can properly document it, and try to convince upstream to follow
<cjwatson> (it sounds like --as-needed to me, at least)
<fta> cjwatson, it's just weird that it says it's now following gold which was not impacted - but has its own problems making it unusable for chromium
<cjwatson> gold did --no-add-needed (aka --no-copy-dt-needed-entries), but not --as-needed
<doko_> fta: --as-needed was announced as a change for natty, but then reverted for the final release.
<Daviey> doko_: Is the same likely to happen near oneiric release?
<doko_> Daviey: no
<Daviey> super
<Daviey> doko_: BTW, i did start looking at the sysvinit merge.  It really is not a fun one.
<RoAkSoAx> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RoAkSoAx
<cjwatson> mr_pouit: it's a live-build bug - I'll fix it shortly
<lamont> jamespage: spring-build shows as published when I dig around...
 * jamespage goes to take another look
<jamespage> lamont: it does indeed - must have happened between when I emailed and now
<lamont> ok
<lamont> nfc what took it so long
 * lamont recloses
<apw> does the package importer _always_ wack your branch?
<apw> or is there some way you can stop it doing so?
<cjwatson> pitti: is there still a way to adjust the burndown start point of http://status.ubuntu.com/ubuntu-oneiric/canonical-foundations.html ?  I approved a couple of specs today that had been mistakenly left in Discussion, resulting in 15 new WIs
<pitti> cjwatson: yes, there is; as the setup moved to IS, we now need to commit changes to a branch: https://code.launchpad.net/~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config
<pitti> cjwatson: we still have an open RT to make this "the" config branch
<pitti> cjwatson: the WI developers and canonical-ubuntu-platform can commit there
<pitti> cjwatson: we'll announce status.u.c. once that RT is done
<cjwatson> OK, thanks
<janimo> dholbach, is there a document descibing the various package versioning possibilities in one place including -buildX, ubuntuX, +git etc
<janimo> wanted to double check that build1 should be followed by ubuntu1 if there is a change this time, but could not find a description
<dholbach> I don't think there's a comprehensive look up list
<dholbach> but yes, Xbuild1 â Xubuntu1
<janimo> dholbach, thanks
<directhex> is there an ubuntu equivalent to debian release team's transition tracker? e.g. http://release.debian.org/transitions/html/poppler.html
<Laney> yes
<Laney> http://people.canonical.com/~ubuntu-archive/transitions/
<directhex> Laney, who do i need to poke to get a mono tracker in there to duplicate the one in debian?
<Laney> i can do that
<Laney> got the file?
<Laney> never mind, doing it
<directhex> Laney, which file?
<Laney> directhex: http://bazaar.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker/view/head:/ubuntu/monitor/mono.ben like that
<Laney> should appear around the top o'the hour
<directhex> Laney, ta. couldn't work out where release.d.o was storing them
<tkamppeter> Anyone knows what went wrong here: bug 797724?
<ubottu> Launchpad bug 797724 in cups (Ubuntu) "package libcups2 1.4.6-5ubuntu1.2 failed to install/upgrade: erreur lors de l'Ã©criture de Â« <sortie standard> Â»: SuccÃ¨s (dup-of: 797723)" [Undecided,New] https://launchpad.net/bugs/797724
<ubottu> Launchpad bug 797723 in cups (Ubuntu) "package libcups2 1.4.6-5ubuntu1.2 failed to install/upgrade: erreur lors de l'Ã©criture de Â« <sortie standard> Â»: SuccÃ¨s" [Undecided,New] https://launchpad.net/bugs/797723
<Laney> directhex: ries:/org/release.debian.org/www/transitions/config/
<directhex> Laney, how come you know all this stuff and i don't?
<Laney> because i was involved in creating that ubuntu instance :-)
<directhex> hax!
<Laney> ghc don't transition itself (very unfortunately)
<cjwatson> Laney: speaking of, feel free to fix the haskell-asn1-extra FTBFS :)
<Laney> cjwatson: already did in debian
<cjwatson> haskell-asn1-data I mean
<cjwatson> oh, ok, was that today?
<Laney> yeah
<cjwatson> the agda entry is due to an arch: all binary, safe to ignore I think
<Laney> no OOD binaries for arm?
<Laney> if so, yeah
<cjwatson> it's an uninstallable arch: all binary rather than OOD armel ones
<cjwatson> I nuked the armel ones
<Laney> sounds fine to me then
<cjwatson> not sure about the rest of those, there are a few more since I last checked, but I think it was mostly the ASN.1 stack
<Laney> yeah there was some fallout due to a regex-tdfa sync i think
<cjwatson> ah, ok
<Laney> not too bad though
<Laney> just the usual low level noise
<lool> mterry: Hey!  would you by any chance have some time to check LP #797160?
<ubottu> Launchpad bug 797160 in linux-linaro-vexpress (Ubuntu) "[MIR] Please promote linux-linaro-omap and linux-linaro-vexpress to main" [Undecided,New] https://launchpad.net/bugs/797160
<mterry> lool, sure
<lool> mterry: Basically it's not meant to be supported, but it's required due to d-i b-deping on stuff in main
<geser> tkamppeter: I've tested the current cups and my printer prints with an uri without the serial. Thanks
<kennydude> Hi, I'm stuck commiting a bugfix in unity
<GrueMaster> ev: http://www.intel.com/support/motherboards/desktop/D525MW/sb/CS-031615.htm
<ev> cheers
<tkamppeter> geser, thanks for the test.
<lool> mterry: thanks!
<RoAkSoAx> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<SpamapS> Hmm.. I wonder why txaws doesn't show up on this transition tracker: http://people.canonical.com/~ubuntu-archive/transitions/dh-python2.html
<SpamapS> $ perl -nle 'if (/(^| )(python|python-dev|python-all|python-all-dev)( |$)/){ print }' < txaws/debian/control
<SpamapS> Section: python
<SpamapS> Build-Depends: debhelper (>= 7), python
<SpamapS> Ahh, the old one does not match
<SpamapS> Build-Depends: debhelper (>= 7), python-support (>= 0.6), python-central (>= 0.5), python, cdbs
<soren> SpamapS: Good question. I have at least one package in a similar situation.
<SpamapS> barry: ^^ note that the "Affected" line may need work
<SpamapS> It maybe should be /(^| )(python|python-dev|python-all|python-all-dev)\s*(,|$)
<soren> SpamapS: Hey,you can sync stuff, right?
<SpamapS> soren: have the rights, but not the blessing / training. ;)
<soren> Darn it.
<SpamapS> which reminds me I need to put some time in on SRU's.. :p
<soren> Handling this one: https://bugs.launchpad.net/ubuntu/+source/libcloud/+bug/797360 would fix one of the ones on that transition tracker.
<ubottu> Ubuntu bug 797360 in libcloud (Ubuntu) "Sync libcloud 0.5.0-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
<soren> But meh. No rush.
<barry> SpamapS: thanks, cjwatson ^^ (he has access to tweak that)
<soren> Just one of those "speaking of which" things.
<nxvl> Daviey: ping
<micahg> \o/ we got a tracker for the python stuff :)
<charlie-tca> moinmoin desktop edition on there? It requires python 2.6 now. (I could not make it use 2.7)
<micahg> charlie-tca: no, this is for the migration to dh_python2
<Daviey> nxvl:
<nxvl> Daviey: augeas, you submited a FTBFS patch to debian, i applied, and it's FTBFS on a test on sudoers, did it builded in ubuntu?
<Daviey> nxvl: yeah it did :/
<nxvl> Daviey: hmm, weird
<Daviey> nxvl: https://launchpad.net/ubuntu/+source/augeas/0.8.1-1ubuntu1
<Daviey> nxvl: how awesome.
<nxvl> Daviey: on debian it's complaining about sudoers :S
<nxvl> really weird, ok, thanks
<Daviey> nxvl: I'll try and reproduce on sid here.
<cjwatson> SpamapS: oh yeah
<cjwatson> SpamapS,barry: fixed, thanks
<cjwatson> (updates hourly or so)
<barry> cjwatson: thanks!
<Daviey> nxvl: odd, PASS: lens-sudoers.sh
<Daviey> (on sid chroot)
<nxvl> Daviey: what?
<nxvl> Daviey: FML
<nxvl> Daviey: ok, thanks
<Daviey> nxvl: I just built the oneiric package on sid... now trying to reproduce adding the patch and building on sid again.  (it should be the same delta)
<nxvl> Daviey: http://pastebin.ubuntu.com/627621/
<nxvl> Daviey: that's the delta i have
<Daviey> nxvl: how odd :/
<Daviey> nxvl: BTW, you have the longest maintainer name ever :)
<Daviey> nxvl: confirmed that it built on sid for me :/
<nxvl> how odd
<nxvl> Daviey: btw, doesn't test-interpreter takes like forever to finish?
<Daviey> nxvl: feels like it :)
<nxvl> Daviey: oneiric package also fails on my sid vm
<Daviey> nxvl: bah, it builds in my chroot.
<nxvl> Daviey: evil debian
<RoAkSoAx> Daviey: create a clean one :)
<Daviey> RoAkSoAx: already done :)
<RoAkSoAx> Daviey: weird then.. :)
<nxvl> Daviey: https://pastebin.canonical.com/48540/
<nxvl> Daviey: do know how to fix that?
<Daviey> nxvl: chmod -R 777 / ?
<Daviey> :)
<RoAkSoAx> nxvl: Daviey maybe what is broken is not the package, but the builder software...
<RoAkSoAx> that happened to us few weeks ago
<Daviey> nxvl: Is $USER in the sbuild group?
<RoAkSoAx> packages FTBFS for some error in the chroot's
<nxvl> Daviey: yup
<nxvl> RoAkSoAx: i'm using a clean debian vm
<Daviey> nxvl: Outside sbuilder, with build-dep's installed, does "debian/rules binary" produce a package?
<nxvl> running
<Rioting_Pacifist> is there an easy way to monitor upstart events? e.g see what is sent along with net-device-* and when they are sent by network manager?
<slangasek> Rioting_Pacifist: 'initctl log-priority' and watch syslog
<slangasek> I should say, 'sudo initctl log-priority info'
<Rioting_Pacifist> thanks slangasek
<broder> slangasek: does that get arguments to events?
<broder> Rioting__Pacifis: note that networkmanager doesn't send net-device-* events. those come from the upstart-udev-bridge
<slangasek> broder: I don't recall
<broder> Rioting__Pacifis: you may want to read http://manpages.ubuntu.com/manpages/natty/man7/upstart-events.7.html
<broder> slangasek: i don't recall them showing up
<slangasek> seems like a bug to me
<broder> i certainly think they'd be useful
<Rioting__Pacifis> broder: thanks
<broder> ugh. somebody is circulating an example upstart job for node.js that has "start on startup"
<broder> there's another variant that has "start on started"
#ubuntu-devel 2011-06-16
<directhex> i need a no-change rebuild of antlr for the current mono transition. i lack upload powers for it, since it's only marginally monoish
<Viper550> Does anyone know how exactly to change the gtk theme on lightdm?
<Rioting_Pacifist> am i right in thinking pre-up and pre-down are no longer called in 11.04?
<Laney> directhex: ajmitch can do such!
<directhex> Laney: why hasn't he done it already? >8\/
<TheMuso> directhex: I'll take care of it for you.
<directhex> TheMuso: thanks
<directhex> TheMuso: i've test-built it, so it should be fine & dandy with just a rebuild
<TheMuso> directhex: What should I be mentioning in the changelog? You said its for the mono transition, but do you want anything more specific?
<TheMuso> I'll test build again to be sure.
<directhex> TheMuso: the Mono CLR 4.0 class library, more specifically. or something along those lines. just make sure it has "4.0" in it somewhere
<TheMuso> urm ok. I'm trying to parse that with lttle success.
<TheMuso> little
<ajmitch> Laney: eh what?
<Laney> ajmitch: just trolling you
<Laney> carry on :)
<ajmitch> :(
 * Laney cuddles you
<ajmitch> directhex: sorry I'm too slow to help you
<directhex> clearly!
<Laney> what in the world is going on
<Laney> a huge crowd of people have descended upon the street
<Laney> they appear to be filming something
<TheMuso> directhex: Ok, I see what change with the rebuild, and your message makes sense now. Will upload.
<TheMuso> directhex: Done.
<Laney> cd ..
<Laney> oops
<directhex> TheMuso: thanks
<directhex> TheMuso: that should make a dent on the transition
<TheMuso> Cool.
<pitti_> Good morning
<maco> ev: can you re-review that merge proposal? i made the requested changes. users in bug report are getting all smart-alecky *sigh*
<ScottK> Is smart alecky users going to slow him down or speed him up?
<maco> ScottK: not sure. they're being smart alecky at me not him though
<maco> "fix it or find someone smart enough to do so" they say
<maco> zomg its been two whole weeks
<maco> yeah yeah i closed a 4-digit bug 2 weeks ago
<ubottu> Error: Launchpad bug 2 could not be found
<maco> sheesh, a bit of perspective...
<ScottK> Right, so I'm confused how he's supposed to find that motivational?  He might just get popcorn and enjoy the show.
<micahg> can I get an AA to reject the rdscli in the queue, smoser has made some changes that I asked for and I'm waiting for one more before uploading
<micahg> it's in NEW for oneiric
<ScottK> Looking.
<ScottK> micahg: Done.
<micahg> ScottK: thanks
<ScottK> You're welcome.
<RoAkSoAx> is the archive admin that rejected rdscli around?
<RoAkSoAx> micahg: ideas.. you commented on it
<ScottK> RoAkSoAx: Read the backscroll.
<RoAkSoAx> ahh i just read
<RoAkSoAx> micahg: well I reviewed it and IMHO it could have been accepted with the warnings
<RoAkSoAx> ScottK: od you have time to review resource-agents and fence-agents
<RoAkSoAx> please
<RoAkSoAx> :)
<ScottK> No.  Just about to go to bed.
<RoAkSoAx> ScottK: no worries then, thanks ;)
<micahg> RoAkSoAx: I didn't see a second ACK, so I thought I'd review it since you uploaded it already, it needed some fixing and we weren't near a freeze, so I thought fixing before hitting the archive was a good idea
<RoAkSoAx> micahg: yeah well warnings are not a big of a deal atm .. I'm not in my main computer but they were only manpages and few spelling errors that seemed to not being fixable
<RoAkSoAx> but from my point of view no reason to reject the upload
<micahg> RoAkSoAx: right, some were debian/control fixes, also, no instructions on how to update the package
<RoAkSoAx> micahg: yeah 1 spelling one description might be too short which I thought that the description couldn't get any bigger
<RoAkSoAx> because there was nothing more to say
<RoAkSoAx> but no deal breaker IMHO
<RoAkSoAx> :)
<micahg> RoAkSoAx: yeah, I wasn't worried about that one, more the duplicate depends fields, build-dep on quilt, and various other things, if we were near a freeze, I would agree, but it's good practice for the packager to learn these things :)
<RoAkSoAx> micahg: the source format is 3.0 quilt, it doesn't need quilt as a dependency :)
<micahg> RoAkSoAx: right, but it had one before :)
<micahg> also, apparently the depends list was short, his second version has a lot more
<RoAkSoAx> micahg: i guess the weird thing is that I dind't see all those warnings that were showed to you :S
<micahg> RoAkSoAx: I have an alias called super_lintian that I run for new packages: lintian -iIEv --pedantic
<micahg> I run it on the source and binary packages
<RoAkSoAx> micahg: k, will recheck that tomorrow
<micahg> RoAkSoAx: could you get it to build in a clean env on i386 oneiric?
<micahg> that was the one thing troubling me, I got it to build on my amd64 machine, but in my oneiric i386 sbuild I get JavaVM initialization errors
<RoAkSoAx> micahg: yeah it was working fine for me
<micahg> k, I figured as much
<RoAkSoAx> micahg: i'll recheck everything tomorrow on clean pbuilders
<micahg> RoAkSoAx: k, ACK from me once it has README.source
<RoAkSoAx> micahg: thanks for reviweing it btw... :)
<micahg> RoAkSoAx: no problem
<micahg> RoAkSoAx: and sorry, I should have subscribed you to the bug so you knew what was going on
<RoAkSoAx> micahg: no worries :)
<RoAkSoAx> micahg: i was just surprised of all those lintian warnings that you saw which i didn't
<micahg> I also ran it with oneiric's lintian since that's where I built it, normally would've been on natty
<RoAkSoAx> micahg: maybe that's the difference cause I did it in natty
<RoAkSoAx> my external screens are kind amessed up with oneiric
<RoAkSoAx> since I work from external monitors
<micahg> ah, I'm on laptops at the moment
<RoAkSoAx> micahg: yeah me too, one running natty and one oneiric
<RoAkSoAx> and a thjird one as a oneiric home server
<micahg> yep, that's what I have
<RoAkSoAx> I usually work remotely since the oneiric one external display ability is broekn
<RoAkSoAx> micahg: but anyways, im off to bed
<RoAkSoAx> have a good one
<diwic> doko_, apw asked me to ping you about bug 789031
<ubottu> Launchpad bug 789031 in gcc-4.5 (Ubuntu) "Built-in ASM constraint "rm" does not work" [Undecided,New] https://launchpad.net/bugs/789031
<apw> doko_, i have this odd feeling we've seen this either a fix in the kernel to work round it, or i saw it on a gcc upload, can you remember
<apw> diwic, does the code work ok on the 4.6 compiler ?
<diwic> apw, let me check
<diwic> hmm, 4.6 does not ship with natty it seems
<apw> diwic, sadly not, there are onieiric chroots on tangerine
<diwic> apw, perhaps you could give it a shot quicker than I, there is a test.c in the bug
<apw> diwic, i cannot trigger the error on any version of the compiler right now
<apw> diwic, can you confirm you gcc-4.5 version for me ?
<apw> Package: gcc 4:4.5.2-1ubuntu3
<diwic> apw, really? It triggers here with gcc 4.5.2-8ubuntu4
<apw> diwic, 64 or 32 bit ?
<diwic> 32 bit
<diwic> works fine on amd64
<apw> diwic, better, ok
<diwic> at least this example (amd64 has more registers)
<diwic> apw, yeah, that's the same package version as I have here
<apw> diwic, ok 4.6 shows the same behaviour
<diwic> ok
<apw> diwic, and gcc-4.4 in lucid too
<diwic> seems doko_ is not around atm
<diwic> doko_, actually in pulseaudio the problem was worse, it allocated one "r" and one "rm" into the same register, so it compiled it but generated faulty code :-(
<diwic> apw, ok but I guess I've done what I can now? Just want to make sure that someone looks at the bug at some not too distant point in the future
<apw> diwic, yep
<dholbach> good morning
<dholbach> RoAkSoAx, Happy Birthday! :)
<seb128> slangasek, hi, could you copy the xerror message you get with that g-s-d issue?
<seb128> oh, it's in the gtk bug you opened yesterday
<ev> maco: sure thing, on it now
<ev> maco: done. It'll go out with the next ubiqutiy
<brendand_> does anyone know what NetworkManager state 'locally connected' 50 means
<brendand_> i guessed at local ip available but no global ip
<brendand_> but if i connect to my router when it has no internet connection i still get 70 back
<brendand_> global connection
<doko> jhunt_: libnih now built on armel. not sure if you want to build upstart with standard compiler flags too
 * ogra_ hugs doko for that 
<mr_pouit> cjwatson: looking at *.manifest files, xfce packages are here, so I guess your fix worked. Thanks!
<aditya> hi there
<aditya> e
<aditya> unity geeks ther?
<abhinav-> aditya: may be #ayatana will be a better place
<aditya> no problems
<aditya> thanx
<cjwatson> mr_pouit: good good
<aditya> any new issues guys?
<abhinav-> aditya: what are you looking for ?
<aditya> am new to this group , just want to get into ubuntu development
<abhinav-> ah ok. Welcome :)
<aditya> thanks
<aditya> any group talks going on presently?
<abhinav-> aditya: there will be Ubuntu Developer Week in July, that is very helpful for new comers to Ubuntu development
<aditya> ok
<aditya> are you abhinav upadhyay by any chance?
<abhinav-> yes
<aditya> k
<abhinav-> aditya: you might want to go through this to set up your development environment. dholbach even did a video on ustream for this, you may search for it. It's a good place to start with
<abhinav-> https://wiki.ubuntu.com/MeetingLogs/devweek1007/GetStarted
<aditya> thanx
<vish> !development | aditya
<ubottu> aditya: Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment
<smoser> micahg, i'll add a README.source file.
<aditya> thanx ubottu
<smoser> if you, or anyone, can write a uscan that parses output of http://s3.amazonaws.com/rds-downloads/ that would be what needs to be done.
<smoser> i think the issue i ran into before was that there are no line breaks.
<bdrung> whom should i ask to get a proposed package accepted?
<Laney> how long has it been?
<persia> smoser: You could create a small AWS service that did XSLT on that to make it standard uscan input format :)
<bdrung> Laney: a few days
<bdrung> two to be precise
<smoser> indeed.  i would think i could probably add support to uscan, but it would be very limited in use (other than the half a dozen or so packages from amazon that do this).
 * mok0 is damned annoyed that installing drupal6 forces mysql to be installed. I use postgresql
<persia> For sourceforge, I think the conclusion was that it was easier to create a translation service than to add parsing to uscan, but you may find the converse to be true.
<doko> jamespage: just to clarify, were the fop dependencies included in the MIR review?
<seb128> cjwatson, bug #797669, I'm just pointing it in case you didn't notice it, should probably be milestoned for the next alpha?
<ubottu> Launchpad bug 797669 in casper (Ubuntu Oneiric) "No autologin on live session with lightdm" [High,Triaged] https://launchpad.net/bugs/797669
<jamespage> doko: I've not reviewed the additional dependencies added to the MIR since SpamapS raised the original bug report
<jamespage> thats batik, libsaxon-java and xmlgraphics-commons
<doko> yes, set to incomplete for now
<cjwatson> seb128: ok
<ntr0py> I am trying to get proftpd to authenticate users against a postgresql db and i am missing "mod_sql_passwd.c" for "SQLPasswordEngine" directive... Does somebody know where it did go?
<directhex> ntr0py, you have proftpd-mod-pgsql installed?
<ntr0py> yes
<directhex> mod_sql_passwd.so is in the proftpd-basic package
<ntr0py> directhex: for maverick it is not in there...
<directhex> this isn't an end-user support channel, and maverick isn't really something anyone's thinking about anymore in development terms
<ntr0py> directhex: ok thanks i found it in natty package, i will try to compile it for maverick
<maco> ev: thanks
<RoAkSoAx> dholbach thank you!!!
<bdrung> cjwatson: can you have a look at the vlc sru upload?
<bdrung> cjwatson: and set this branch to merged: https://code.launchpad.net/~druke/ubuntu/natty/g15daemon/bug-657598/+merge/64168 ?
<ubottu> Ubuntu bug 64168 in kdebase (Ubuntu) "KDE clipboard used with Openoffice does not support Umlauts" [Low,Fix released]
<cjwatson> both will have to wait until this CD has synced so I have bearable bandwidth again
<cjwatson> I'm doing minimal-bandwidth things in the meantime ...
<bdrung> cjwatson: even for setting a merge proposal status?
<cjwatson> bdrung: well, the page ain't loading, so apparently so
<goof2092> pitti: when you have the please review Language Pack bug report #796591 for Bemba
<mterry> poolie, heyo, are you still involved with librsync at all?
<pitti> hello goof2092
<pitti> goof2092: I replied in the bug
<jcastro> ev: any chance you have screenshots the screens that come after each of the choices in the installer? Basically a step by step for each available choice a user can pic?
<mterry> barry, to port a package to dh_python2, all packages that put files into the same toplevel module need to be ported at the same time?
<barry> mterry: yep, all subpackages of the same namespace package must be ported at the same time.  e.g. all lazr.* or zope.*
<mterry> barry, ok.  Then I need to do futz with the dependencies to make sure that a user doesn't only get half the upgrade?
<barry> mterry: good question.  i think if you upload all the ported packages at the same time, there'll be only a small window where they could get screwed, which probably isn't enough to worry about.  but maybe i'm missing something
<seb128> barry, yeah, you miss partial upgrades
<mterry> seb128, you're saying we don't worry about those?
<seb128> like users doing an apt-get install binary and not a dist-upgrade
<barry> seb128: ah, yeah thanks
<seb128> mterry, I'm not saying that ;-)
<barry> seb128: how do you suggest we handle these upgrade dependencies?
<seb128> well ideally you would Breaks:.... on all the things you actually break
<mterry> seb128, that sounds more like you  :)
<seb128> not sure how practical it is for that python transition
<barry> mterry: i guess it's a good question to ask on ubuntu-devel and see what people think.  i'm working on a critical bug atm so don't have time to do that.  could you?
<mterry> barry, sure
<barry> mterry: thanks!
<mterry> doko, the ubuntuone python package set is a big, lockstep upgrade to dh_python2.  How about I trade you 2 other packages for ubuntuone-couch?  :)
<doko> mterry: I don't mind if it's now. just be aware that it stays on your radar
<doko> barry, seb128: well, we don't support partial upgrades, or did that change?
<seb128> I don't know if we have an official position on that
<seb128> I usually try to get things to not break in partial upgrades for desktop but I'm not sure if we say that we support those or not
<cjwatson> doko: I've never heard any official statement that we don't support partial upgrades.  IMO it's silly *not* to support partial upgrades to at least some extent because somebody's bound to run into it and file a bug and why wouldn't we want to avoid that?
<cjwatson> not supporting systems that are half karmic and half maverick or something is a different matter, but that's a much weaker statement
<cjwatson> bdrung: marked that g15daemon branch as merged now
<bdrung> thanks
<mterry> pitti, thanks for the awesome dh_python2 tip
<cjwatson> bdrung: looks like somebody dealt with the vlc SRUs?
<pitti> mterry: glad that I could recycle it :)
<bdrung> cjwatson: no, i was talking about 1.1.9-1ubuntu1.2
<cjwatson> bdrung: http://people.canonical.com/~ubuntu-archive/pending-sru.html isn't showing any vlc package in -proposed and nothing in any of the upload queues, so you're going to need to give me more detail if you want me to do something, I think
<cjwatson> pitti: I'm reviewing the status of the grub2/lupin SRUs
<bdrung> cjwatson: https://launchpad.net/ubuntu/natty/+queue?queue_state=1&queue_text=
<cjwatson> pitti: bug 610898 has now been verified on both lucid and maverick, and I've marked it v-done
<ubottu> Launchpad bug 610898 in Wubi "grub-pc upgrade renders computer unbootable when Wubi is installed to partition other than Windows" [High,Triaged] https://launchpad.net/bugs/610898
<cjwatson> pitti: I think the testing there is almost certainly sufficient to cover bug 695290 and bug 742967 as well; do you agree?
<ubottu> Launchpad bug 695290 in grub2 (Ubuntu Maverick) "10_lupin case problem with ntfs UUIDs" [High,Fix committed] https://launchpad.net/bugs/695290
<ubottu> Launchpad bug 742967 in Wubi "Wubi grub prompt on install" [Undecided,New] https://launchpad.net/bugs/742967
<cjwatson> pitti: then we can unblock bug 687501 and we're good to go
<ubottu> Launchpad bug 687501 in OEM Priority Project "when installer is multipath aware, grub fails to install" [High,New] https://launchpad.net/bugs/687501
<pitti> cjwatson: yes, for regression testing that's certainly more than we usually get, so I'm fine with moving this to -updates
<cjwatson> excellent, I'll mark those bugs then
<cjwatson> lupin has to move at the same time
<cjwatson> bdrung: looking now, then
<cyrildz> hi all
<cyrildz> I'm new here
<cyrildz> I'm an ubuntu user and I want to start programming
<cyrildz> I don't know where  nor how to start
<cyrildz> If I am on the wrong place , please let me know
<cyrildz> I 'm very interested in C/C++
<cjwatson> bdrung: OK, approved, thanks
<cyrildz> I have learnt stuff on C/C++ , I like the Object Oriented approche of C++ and now I want to jump ahead a do something real
<cyrildz> a bit of help to where to look  would be welcome
<cjwatson> cyrildz: this isn't really a help-you-get-started-programming channel - perhaps try #ubuntu-app-devel, or a specialist C or C++ channel (though I can't recommend one)?
<cyrildz> thanks , I will have a look a this
<bdrung> cjwatson: thanks
<jibel> cjwatson, latest alternate build failed to install see bug 798306. I filed it against debian-installer but from the error it looks more like debconf. It is reproducible.
<ubottu> Launchpad bug 798306 in debian-installer (Ubuntu) "unable to install the selected kernel with oneiric-alternate-i386 20110616.1" [Undecided,New] https://launchpad.net/bugs/798306
<smoser> persia, https://code.launchpad.net/~smoser/ubuntu/oneiric/devscripts/lp-798293/+merge/64857 is to add S3 bucket listing support to uscan
<cjwatson> jibel: thanks, I'll have a look.  I think I probably need to seed debconf-i18n
<persia> smoser, Heh.  That was fast.  Nice!
<Daviey> ls
<Quintasan> :D
 * Quintasan does that way too often
<jdstrand> Daviey: fyi, I am finalizing the patch to fix bug #795800. I should be uploading it to Ubuntu today (tomorrow at the latest) as well as submitting the patch upstream
<ubottu> Launchpad bug 795800 in libvirt (Ubuntu Oneiric) "virsh save fails on oneiric when the apparmor security driver is enabled" [High,In progress] https://launchpad.net/bugs/795800
<Daviey> jdstrand: Ah super.. I understand zul was looking at the libvirt merge, but wanted you to peer review it? :)
<jdstrand> Daviey: last I heard, I reviewed hallyn's merge, uploaded it and then zul was asked to test said merge against Ubuntu Cloud
<zul> jdstrand: yeah there is a newer version in debian now though
<jdstrand> Daviey: if he is doing an 0.9.2 merge, I can review it and add my patch to fix the bug to it during the review
<Daviey> sounds like a plan!
<zul> jdstrand: ill talk about it to you later, im kind of in a buffer overflow situation right now :)
 * Daviey cycles zul 
<jdstrand> zul: it is unlikely I could put real review time in until monday anyway, so no worries
<zul> jdstrand: ack :)
<Daviey> peer reviews rock my world.
<jdstrand> I'll still get my upload in though
<micahg> jdstrand: is there a reason why linux-any is dropped from the merge?  AFAIK launchpad understands that now
<jdstrand> micahg: all I see in the merge from hallyn is 'remove [linux-any] from all dependencies'
<jdstrand> zul: fyi ^
<zul> no idea
<pitti> cjwatson, kees, sabdfl, Keybuk: TB meeting reminder in 10 mins
<micahg> jdstrand: right, was just wondering if you knew why, I guess I should talk to hallyn about it
<jdstrand> zul: no I meant you may want to leave it in next time :)
<zul> jdstrand: heh ok
<micahg> zul: another thing to keep in mind is that we still have python2.6 in oneiric, even if not though, if the python-dev-all package doesn't have a python version, I don't think you need to worry about X-Python-Version being older
<hrw> I have small C code which compiles on amd64 but fails on armel
<ev> jcastro: Apols, somehow I didn't see your message until now
<jcastro> no worries, it's not urgent or anything
<ev> I don't have up to date ones, sadly. There are olds ones on people.c.c/~Evans
<ev> Evand
<ev> Damn iOS
<jcastro> ta, that should put me on the right track
<jdstrand> zul: what is happening with libxen-dev-- has it been approved in the MIR? your libvirt upload won't build cause it isn't available
<zul> jdstrand: ill go check
<zul> jdstrand: MIR has been aproved
<zul> so i guess they need to be promoted
<jdstrand> zul: ok, then I'll promote it. what is the bug number?
<zul> 790854
<jdstrand> zul: the bug states that the server team will do security support-- can Daviey or someone else comment in the bug that that will happen?
<zul> jdstrand: sure
<zul> Daviey: ^^^
<jdstrand> support really means testing here, as I read it
<zul> jdstrand: but that will probably end being me anyways
<jdstrand> (like euca, iscsi, etc where we don't have the testing infrastructure for it)
<zul> jdstrand: wha? you guys dont want to use xen? :)
<bdmurray> slangasek: I've about 24 open bug reports where update-initramfs has failed due to lack of space and plan to open a new bug suggesting that update-initramfs should deal with this better (make the existing ones duplicates of that new one)  and write a bug pattern to prevent further reports.  Does that seem reasonable?
 * Daviey looks
 * Daviey is not having with oneiric desktop atm
<Daviey> zul: is xenstore needed as a build dep?
<zul> Daviey: yeah it pulls it in when you install libxen-dev
<Daviey> ah
 * micahg thought libxenX was renamed libxenstoreX
<nxvl> cjwatson: ping
<cjwatson> nxvl: yes?
<nxvl> cjwatson: did you have somewhere a magic regexp that will match a valid ubuntu version?
<cjwatson> nxvl: define "valid ubuntu version"?
<nxvl> cjwatson: 0.8.4-1ubuntu2stuff4 will facil
<nxvl> cjwatson: however 0.8.4-1ubuntu2 or 0.8.4-1 will pass
<cjwatson> I don't understand why the first should fail
<nxvl> cjwatson: because the use case i need, should fail
<cjwatson> I do not have a magic regexp that matches requirements I do not have. :-)
<nxvl> cjwatson: ok, thanks!
<cjwatson> from Ubuntu's point of view, valid version numbers are those defined in policy 5.6.12, and version numbers with the substring 'ubuntu' inhibit autosync from Debian; that'sal
<cjwatson> *that's all
<nxvl> cjwatson: that will help, you surely have that on a regexp in a script somewhere, right?
<cjwatson> buried in the archive somewhere, I can't remember when I last had to care
<Daviey> the secret sauce. :)
<cjwatson> re_valid_version = re.compile(r"^([0-9]+:)?[0-9A-Za-z\.\-\+~:]+$")
<cjwatson> says Launchpad
<nxvl> cjwatson: awesome!, thank you!
<cjwatson> (that's in lib/lp/archiveuploader/utils.py)
<slangasek> bdmurray: sounds great to me!
 * nxvl HUGS cjwatson 
<bdmurray> cjwatson: I found an announcement about not ps3 isos for natty was there a similar one for powerpc isos?
<cjwatson> powerpc ISOs were never stopped
<cjwatson> they weren't *released* because they didn't get tested, but the daily builds are still going
<bdmurray> ah, thanks!
<jdstrand> zul, Daviey: fyi, libxen-dev and libxenstore3.0 (and 'xen' source) have been promoted and I uploaded libvirt 0.9.1-1ubuntu4
<zul> jdstrand: cool thanks
<jdstrand> zul: fyi, one of the two patches can be dropped in 0.9.2, but the other not until 0.9.3 (see the cahngelog)
<jdstrand> zul: ie, of the 2 I just uploaded
<zul> jdstrand: gotya
<Daviey> jdstrand: rocking!
<poolie> mterry, hi, i haven't touched librsync for a long time
<poolie> idon't know if it's very active at all
<mterry> poolie, that's what I've gathered.  Last comment by an ex-maintainer was 2006
<mterry> poolie, was in reference to a MIR (deja-dup->duplicity->librsync)
<mterry> poolie, seems stable, just unmaintained
<poolie> yeah, pretty much stable
<poolie> i'd kind oflike to do something on it
<poolie> i'm sure there is room for improvement, but not many bugs
<poolie> remarkably few actually
<bdmurray> slangasek: so there are a lot of dist-upgrades with this error too but update-manager has its own free space calculator for /boot.  I think those should probably be a separate bug.  Do you agree?
<slangasek> bdmurray: the two bugs being 1) poor error message when you're out of space, 2) update-manager's free space calculator needing help?
<bdmurray> slangasek: right - it looks to like update-manager just uses the following
<bdmurray> KERNEL_INITRD_SIZE = 19 * 1024 * 1024
<bdmurray> 19 seems kind of random to me
<slangasek> heh, yes
<broder> i don't know...
<broder> ebroder@warwick:~$ ls -lh /boot/initrd.img-2.6.38-8-generic  | awk '{print $5}'
<broder> 20M
<broder> though i've thrown a bunch of random crap into my initrd
<broder> looks like stock natty is 13M or so
<slangasek> well, a much better predictor would be to check the size of the initrd for the current kernel
<broder> yeah, sure. i was just surprised how close mine was to the magic number :)
<directhex> how frequent is the pull from debian unstable?
<cjwatson> daily
<cjwatson> assuming I'm around anyway
<cjwatson> (it's a cron.cjwatson kind of thing)
<cjwatson> why, are you looking for something in particular?
<directhex> cjwatson: i've been uploading fixes to sid which ought to also apply to the mono transition in oneiric
<directhex> i wondered what time the cronjob runs, so i can check the ben page for added green ticks
<cjwatson> right, it's not a cron job, it's "Colin usually runs this when he starts work in the morning"
<cjwatson> I can run it now if you'd like
<directhex> no, don't do it on my account. that's close enough to a number
<directhex> i'm busy migrating from ejabberd to prosody tomorrow anyway, hopefully it means i won't have time to look at non-work things in work hours
<cjwatson> actually, I think I'll do one now anyway - with the exception of powerpc, the buildds are fairly quiet and it's good to space things out so that they're more responsive when people need them
<cjwatson> typing screen commands into firefox is not helpful
<directhex> note to self: do packagecraft after less wine.
#ubuntu-devel 2011-06-17
* bradm changed the topic of #ubuntu-devel to: Wiki.ubuntu.com upgrade in progress | Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<RAOF> What?  Gah!  There should be an easier way of testing armel builds than failing on the buildd.
<slangasek> there's a porter machine
<slangasek> and there's qemu
<RAOF> Yeah, there's the porter machine.
<slangasek> RAOF: apt-get install qemu-user-static; /usr/sbin/qemu-debootstrap -aarmel [...]
<RAOF> The buildds take *8 hours* to build mesa; a local build would still be going from yesterday.
<slangasek> there's a cross-compiler package :)
<RAOF> I've got an armel schroot, and for things smaller than mesa it's very nice :)
<RAOF> This typo was in the install target of debian/rules though, soâ¦ urgh.
<directhex> slangasek: an ubuntu porter machine?
<slangasek> you've inspired me to check whether I can get away with cross-installing all the mesa build-deps with mulitarch
<slangasek> directhex: a Canonical ubuntu porter machine, sorry :/
<slangasek> shell access in the DC, company policy, etc etc
<directhex> yeah, that's fine. i've never encountered an arm bug on ubuntu's smp omap4 target that i haven't hit on a single-core efikamx
<directhex> no, wait, the opposite of what i just said
<slangasek> the porter machine isn't an smp omap4 anyway
<directhex> winnar
<RAOF> When will multiarch stop killing update-manager?
<RAOF> :)
<slangasek> RAOF: oh, how's it killing it for you?  It works for me! :)
<directhex> i'm sure i can badger access to a pandaboard in the office if i need to (note: this is a lie)
<RAOF> Hm.  Last time I tried it would kinda refresh the apt cache and then die with an inscrutable error message.
<RAOF> And I went back to apt-get update && apt-get dist-upgradeâ¦
<RAOF> I'll try again once apt's finished :)
<slangasek> RAOF: so as of the last u-m changes before the natty release, all those issues have been resolved for me
<RAOF> I'll try again, and this time report bugs when they fail.
<slangasek> yay :)
<RAOF> So, does this mean we're actually quite close from being able to drop mesa from ia32-libs?
<RAOF> What's left before i386 is a default foreign arch?
<slangasek> we wouldn't drop mesa from ia32-libs, we would want to drop ia32-libs itself from the archive
<slangasek> "what's left" - we need to be satisfied that turning on i386+amd64 isn't going to carry so much a penalty in index download time that it makes it (more) painful to run apt-get update
<RAOF> Hm.  Looks like update-manager's perfectly happy now.
<RAOF> Yeah.  I'm now downloading ~50MB of apt indexes.
<RAOF> slangasek: Ah.  The partial-upgrade tool seems be spinning indefinitely.  Is there any debugging information I can nab before killing it?
<slangasek> RAOF: mm, no idea on that, sorry
<RAOF> Not something you've run into?
<RAOF> Ok.  Well, I'll file a bug and see.
<slangasek> RAOF: nope, not run into it that I can recall
<RAOF> slangasek: bug 798478
<ubottu> Launchpad bug 798478 in update-manager (Ubuntu) "Partial upgrade spins indefinitely in âPreparing to upgradeâ with multiarch" [Undecided,New] https://launchpad.net/bugs/798478
<RAOF> Ah, need to update the title.  It doesn't spin indefinitely, it waits for you to submit a bug and then throws up an error message :)
<slangasek> heh :)
<Keybuk> slangasek: http://online.wsj.com/article/SB10001424052702304066504576345782284098222.html?KEYWORDS=telecommuting+tax
<Keybuk> ouch
<Keybuk> which state is Canonical Inc incorporated in, again? :)
<directhex> isle of man, iirc?
<Keybuk> directhex: that's Canonical Ltd
<micahg> New York and New Jersey have extremely punitive tax codes
<Keybuk> http://www.manta.com/c/mtvfcjz/canonical-usa-inc
<directhex> Keybuk: handy. maybe there's more reason for collabora.ca than i thought
<Keybuk> directhex: well, .ca has that law that defines the difference between an employee and a contractor, right?
<directhex> dunno, but we have plenty of contractors on the payroll :p
<Keybuk> there is, I believe, also a Canonical Canada Ltd
<Keybuk> it's funny how sladen stopped his Canonical tax accounting stalking when he joined ...
<directhex> it's also funny that he's not a DD
<micahg> hehe
<Keybuk> it's also funny that he eats ice cream with chopsticks
<amit> Hello all. Seeking assistance in finding procedure for updating /etc/motd w/o reboot:
<amit> distro: ubuntu server 10.04
<amit> /etc/motd gets modified to the value of /etc/lsb-release:DISTRIB_DESCRIPTION. But this only takes effect after rebooting (more specifically, I think it's already modified before the reboot, when switching to RUNLEVEL 1).
<amit> Can /etc/motd be auto-modified w/o a reboot?
<micahg> amit: you might want to try #ubuntu-server
<amit> micahg: ok, 10x.
* bradm changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bradm> ubuntu wiki upgrade is done, please let us know if there are any troubles
<micahg> bradm: login seems to be taking forever
<slangasek> kees: Canonical, USA is incorporated in Delaware, like all corporations worth their salt
<slangasek> eh
<slangasek> kees: not you, the Keybuk who dodged :P
<pitti> Good morning
<pitti> hmm -- wiki, where are thou?
<StevenK> pitti: It was upgraded, do you have an issue?
<pitti> trying to login, it times out
<pitti> anonymous viewing works
<nigelb> I can duplicate that
<pitti> SpamapS: darn, lucid's launchpadlib doesn't yet work with the launchpadlib queue count; I reverted that change to screenscraping again to get the queue counts back on pending-sru.html
<dholbach> good morning
<pitti> WTH -- does https://wiki.ubuntu.com/ReleaseTeam/Meeting/Agenda work for anyone?
<pitti> I get redirected to some http://www.releaseteam.com commercial page
<micahg> pitti: broken wiki redirect
<micahg> pitti: just asked in #is
<mvo> pitti, dpm: I'm just looking at the merge of myspell-hr and the only change is to add a (or) dependency to language-support-writing-hr. it appears like this is the only of hte hypen packages doing this, can we drop that delta and sync the pkg?
<hrw> morning
<dpm> hey mvo, I'm not sure, I'll let pitti answer that one
<pitti> mvo: confirmed
<pitti> language-support-* are gone
<mvo> pitti: thanks, I will request the sync
<cjwatson> pitti: some discussion on the internal foundations list raised an interesting possibility: purge .pyc files from the live filesystem, and have ubiquity byte-compile them after copying the filesystem
<cjwatson> pitti: .pyc files are about 12MB right now
<cjwatson> we have to be careful to avoid making installed systems inconsistent between d-i and ubiquity, but if that can be avoided it does seem worth pursuing
<pitti> cjwatson: indeed, that came up recently
<pitti> cjwatson: but as the .pyc files are generated at package install time, and not shipped in the .debs, it should not be more inconsistent than a live vs. alternate install already is?
<cjwatson> well, if you removed them from the live filesystem and didn't have ubiquity do the byte-compile step, nothing would ever generate them until the packages in question are upgraded
<cjwatson> if ubiquity does that work, though, it's feasible
<pitti> right, that's what I meant
<pitti> I meant that it shouldn't matter much whether it was live-builder or ubiquity which triggers the pyc building
<cjwatson> it costs a bit of extra time at installation; but 12MB isn't small change
<pitti> even compressed that should be some 5 MB perhaps
<cjwatson> I'm quoting the compressed size
<cjwatson> it's more like 40MB uncompressed
<pitti> !
<pitti> by the looks of man pycompile, we wouldn't even need to iterate over all packages, it seems it can build them all
<cjwatson> $ sudo find /mnt -name \*.pyc | xargs cat | gzip -9c | wc -c
<cjwatson> 11812952
<cjwatson> I'll check out exactly what dh_python2 etc. causes to happen, to make sure it matches
<pitti> thanks!
<cjwatson> we might want to trigger a fake python runtime update or something rather than calling pycompile directly
<pitti> oh, that indeed seems easier
<pitti> interesting that it doesn't seem to differ between pysupport, pycentral, and dh_python2
<pitti> oh, wait
<cjwatson> those three have quite different .rtinstall files
<pitti> it only seems to rebuild its own pycs, not for all python-* packages
<cjwatson>         for hook in /usr/share/python/runtime.d/*.rtinstall; do
<cjwatson>             [ -x $hook ] || continue
<cjwatson>             $hook rtinstall python2.7 "$2" "$version"
<cjwatson>         done
<cjwatson> is basically what python does to byte-compile stuff
<cjwatson> I'll check safety with doko
<DktrKranz> mvo: hi! I implemented some new features in gdebi, I plan to upload to experimental soon, then sync it in oneiric. Does it sound good to you?
<lag> Why do random applications (browser, instant messenger etc) keep greying out and locking up?
<pitti> this often happens if you do heavy I/O, such as copying big files, rsyncing cd images, etc.
<pitti> if not, then the browser/IM is just busy (which is a bug, as it shoudln't stop responding to the UI)
<lag> pitti: The browser is doing nothing, but has locked
<lag> pitti: When the IM locked up, it was doing nothing
<lag> pitti: They just become unresponsive and lock
<pitti> bugs
<lag> pitti: My mail client does the same, again whilst doing nothing
<pitti> it's not "desired behaviour" of course
<lag> pitti: Must be a Ubuntu bug, can't be all these different applications
<cjwatson> check syslog in case you have a disk device that's returning I/O errors
<ogra_> might be a hint from your system that you should probably stop doing nothing then :P
<micahg> I get it when I have incredibly high i/o wait
<lag> ogra_: HA - jerk!
<micahg> !coc | lag
<ubottu> lag: The Ubuntu Code of Conduct is a community etiquette document to which we ask all Ubuntu users to adhere, and can be found at http://www.ubuntu.com/community/conduct/ | For information on how to electronically sign the CoC, see https://help.ubuntu.com/community/SigningCodeofConduct
<lag> ogra_: My terminal is extremely busy (but it's not failing)
<pitti> micahg: the problem with Linux is unfortunately that merely doing an rsync or copying 2 GB around already counts as "incredibly high" :(
<lag> micahg: I'd love to open it, but my browser is locked ;)
<lag> micahg: Why did you send that to me?
<ogra_> lag, see, that supports my theory ;)
<apw> lag, i find i get the same greying with no load, things grey out one by one, resolving when an OSD message finally spits out
<micahg> lag: we don't tolerate insults here
<lag> micahg: ogra is a good friend of mine - he knows I was joking
<apw> somehow they cause a log jam which can even affect gnome-terminal ... which makes no sense, but its happened often enough that i've mannaged to killall the notifier to confirm its definatly that thats causing the blockage
<lag> apw: I am used to momentary greying out, but when these go, they are perm and the only way I can resolve is to kill the app
<apw> and its always for me an xchat OSD thats trying to display
<lag> apw: I haven't seen an OSD message for ages
<lag> apw: Let me try
<apw> how long is perm, i see minutes of grey during which a restart of notify-osd fixes it
<psurbhi> jhunt, I am trying to stop a job on "stopped udev"
<apw> not that anyone believes me
<psurbhi> but this never happens
<apw> psurbhi, udev runs all the time doesn't it?
<psurbhi> so, I put post-stop script ; echo "in post stop"; end script
<cjwatson> udev doesn't stop (except on shutdown)
<psurbhi> and i cant see that either
<psurbhi> cjwatson
<psurbhi> exactly
<lag> apw: As long as I am patient enough to leave it - I need my browser and mail client, so I guess I've left it for 10-15 mins
<psurbhi> but i want to do something similar in the initramfs
<psurbhi> and somehow i cant see udev in the "stopped" case
<psurbhi> it always reaches "stopping" and thats it
<cjwatson> ah, I'll leave you alone then, not sure what that would be
<psurbhi> i want to stop upstart-udev job on "stopped" udev
<psurbhi> and then run the pivot command
<psurbhi> right now, to achieve the same effect
<psurbhi> i am stopping the upstart-udev-bridge
<lag> cjwatson: Just checked syslog, looks like I have problems!
<psurbhi> on stopping udev
<cjwatson> pitti: could you ack my debian-installer/lucid-proposed upload, please?
<psurbhi> and then in the post-stop of upstart-udev-bridge, i execute kill all udev
<cjwatson> lag: busted disk?
<cjwatson> lag: past time to check those backups :)
<lag> cjwatson: Seemingly: https://pastebin.canonical.com/48644/
<psurbhi> jhunt ^^
<pitti> cjwatson: diff looks fine, accepted
<lag> cjwatson: I'm all backed up ;)
<cjwatson> pitti: ta
<psurbhi> i was wondering if anyone has seen that udev really stops on shutdown
<psurbhi> atleast?
<jhunt> psurbhi: how do you know it only reaches stopping?
<psurbhi> because i have put echos in the scripts
<cjwatson> oh good, it's so rare that I say that and it's actually true
<pitti> lag: doesn't seem related at all to IO errors; it just says that your keyboard has unknown keys
<psurbhi> i.e post-stop script
<psurbhi> and pre-stop script
<jhunt> psurbhi: where are the echoes going?
<psurbhi> and also, the job that should execute on stopped
<psurbhi> never gets executed
<psurbhi> running upstart in --debug mode
<psurbhi> never shows udev in the "stopped" state
<pitti> lag: by any chance, does the blocking start when you press a particular key?
<psurbhi> it says "stopping" udev
<cjwatson> lag: yeah, those don't look like serious disk problems to me either
<psurbhi> but i did not see anything more than that
<pitti> lag: we had that problem with many Samsung laptops, they have a BIOS bug which needs to be worked around
<cjwatson> some filesystem consistency problems, but not I/O
<psurbhi> jhunt?
<pitti> lag: try pressing Ctrl+Alt+F1, then Ctrl+Alt+F7 (or F8, whatever gets you back to the graphical desktop), and check whether it's gone
<psurbhi> i did not get the question - where are the echoes going
<psurbhi> sorry
<pitti> lag: then find out whether pressing that magic Fn+something key triggers it
<lag> pitti: I was referring to the 1587 ext2 errors I have in there
<lag> pitti: Jun 17 10:48:14 system1 kernel: [11052.251178] EXT2-fs (sdb1): error: ext2_lookup: deleted inode referenced: 3268621
<ogra_> wow
<apw> lag, is that an internal drive?  cirtainly needs unmounting and checking properly
<ogra_> that doesnt look good
<cjwatson> yeah, worth unmounting and doing a manual fsck
<lag> Not at all :(
<lag> Yes, it's mounted at /home/lag/
 * apw suggests crossing anything you have more than one of
 * lag lols @ apw
<apw> lag, well we know there is nothing in there thats important :)
<lag> Right, BBS (if all goes well)
<lag> apw: You lot are rude!
<lag> ;)
<apw> lag, is my job
<lag> apw: Quite
<lag> Right, I'm off to fsck
<apw> heres hoping its your git trees, as most files in there are regenerrable :)
<lag> apw: /home/lag/projects are mounted separately ;)
<psurbhi> jhunt, i can see the echoes in the pre-stop scripts for mountall.conf and udevd.conf
<psurbhi> but i cant see the echoes in the post-stop script
<jhunt> psurbhi: I've just done a test and I have a simple job which successfully starts on "stopping udev".
<psurbhi> jhunt - yes that works
<psurbhi> but can you try starts on "stopped udev"
<psurbhi> the stopping clause works
<psurbhi> but the "stopped" doesnt for me
<jhunt> psurbhi: I think just aren't seeing the messages - rsyslog stops on the same condition as udev - try logging to the console/serial device
<psurbhi> jhunt, the job does not start too
<psurbhi> :-/
<psurbhi> can you please let me know if the job starts on "stopped udev" ? for you?
<apw> psurbhi, how can you tell if its not started if the logging output is not logged>
<psurbhi> jhunt, yes, i am getting the messages on the serial console
<psurbhi> apw, you could stop the logging on "stopped udev"
<psurbhi> instead of "stopping udev"
<jhunt> works for stopped udev too...?
<apw> still too late though right as your job also starts then
<psurbhi> jhunt, does your job work?
<psurbhi> apw, then you can stop logging after stopping your test-job
<jhunt> psurbhi: it runs, so yes :)
<psurbhi> ok!
<psurbhi> jhunt, thanks
<psurbhi> i will probably send you the initramfs
<psurbhi> can you please let me know what you think is wrong in there?
<jhunt> psurbhi: can you show me your .conf file?
<apw> i had to log directly to /dev/.foo i think the only reliable way to get diagnostics, when i was playing with the vesafb stuff
<psurbhi> yes, exactly
<jhunt> psurbhi: (from other channel) - yes, lets take this offline now...
<cjwatson> yeah, I've always logged to /dev/.initramfs/<something> when trying to debug this kind of thing
<cjwatson> (/run will reduce typing ...)
 * ogra_ wonders what changed in upower recently ... i get battery discharge notifications every few mins since my last upgrade
<hrw> ogra_: maybe your battery started dying?
<hrw> ;D
<ogra_> its brand new
<ogra_> charged for the first time yesterday
<nigelb> bad purchase? :)
<ogra_> nah
<ogra_> it was fine before the upgrade
<nigelb> well, mine started showing zero recently, but it ever had a good battery. Like its totally drained. I thought that was a bug fixed to show it correctly ;)
<nigelb> *never
<cjwatson> mvo: have you seen bug 774999?
<ubottu> Launchpad bug 774999 in update-manager (Ubuntu) "[i865G] Upgrade should warn user about lack of support for old 8xx intel hardware" [High,New] https://launchpad.net/bugs/774999
<cnd> I was hoping to upload a package to ubuntu today, but I tested in a pbuilder and found that it failed to install build deps due to bug 775546
<ubottu> Launchpad bug 775546 in tex-common (Ubuntu) "/usr/sbin/update-language-def: line 779: printf: missing unicode digit for \u" [Undecided,Confirmed] https://launchpad.net/bugs/775546
<mvo> cjwatson: no, sorry, I have a look now
<cnd> should I upload it anyways? or should I wait until the bug is fixed?
<cjwatson> mvo: np, thanks
<cjwatson> cnd: is that actually the reason it's failing?  that bug suggests that it's cosmetic
<cnd> cjwatson, yeah, I think you are right after I googled some more
<cnd> let me pastebin the error message I see
<cnd> I just assumed that was the reason since it was the first error/warning message I saw
<cnd> cjwatson, here's what I believe is the relevant snippet: http://paste.ubuntu.com/628382/
<cjwatson> cnd: right, I was actually in the middle of a test live filesystem build to track that down, since it broke those too
<cnd> cjwatson, ok
<cnd> so should I hold off on uploading packages until it's fixed?
<cnd> or should I upload now, and just retry builds as necessary?
<cjwatson> it doesn't *hugely* matter; if you don't hold off, you'll have to retry
<cjwatson> I wouldn't worry too much about it
<cjwatson> if you have relevant upload privileges, retrying isn't too much of a hassle
<cnd> ok, thanks!
<YokoZar> What's the best way to have a package build with gcc 4.4 on Lucid, 4.5 on maverick (whose default is 4.4), and 4.5 on natty?
<directhex> a big ol' conditional in debian/rules
 * Laney conditions directhex goooooooooood
<YokoZar> directhex: so I take it we don't provide some sort of gcc-latest symlink?
<directhex> YokoZar, nafaik, just gcc as a symlink to the default
<Daviey> Anyone else noticed archive builds failing for odd reasons atm?
<cjwatson> Daviey: see discussion with cnd above, perhaps
<cjwatson> I'm just trying to pinpoint it with a livefs build here, since the logs are awkwardly unhelpful (failure distant from cause)
<directhex> what's the deal with powerpc right now? buildds seem backed up
<Daviey> cjwatson: ok, thanks
<cjwatson> it would probably help if dpkg rejected packages with syntactically invalid triggers files at unpack time rather than later
<cjwatson> Daviey: however, can you point to a build log to make sure we're looking at the same thing?
<Daviey> https://launchpad.net/ubuntu/+source/cvs/2:1.12.13+real-5ubuntu1/+build/2575050
<Daviey> cjwatson: that is the second build attempt
<Daviey> first one failed for "sh: gcc: not found"
<Daviey> sadly, i didn't save the log
<cjwatson> "sh: gcc: not found" appears in lots of build logs due to something being run in the wrong chroot, and isn't normally fatal
<Daviey> I also saw one of slangasek's builds fail a few hours ago, but worked locally here - so hit rebuild and it worked.
<Daviey> (seeing this on i386 and amd64)
<cjwatson> anyway, yeah, that's the same thing that I'm looking at
<cjwatson> though perhaps a livefs build isn't the most efficient way to do it, but I might as well wait for it now ...
<Daviey> rocking
<mvo> DktrKranz: gdebi> thats fine of course, many thanks for working on it, I noticed a bunch of fixes :)
<cjwatson> slangasek: hmm, looks like multiarch+triggers breaks world
<cjwatson> $ cat chroot/var/lib/dpkg/triggers/Unincorp
<cjwatson> aspell-autobuildhash dictionaries-common:all
<cjwatson> aha, I think it's a non-updated trigdeferred.c
<seb128> cjwatson, the gtk3 cpp bindings landed in debian unstable, should be on ubuntu on next new-source run then
<seb128> cjwatson, it might make easier the work for the gparted guys, dunno what distro they run
<hrw> jdstrand: can I get my armhf cross toolchain from NEW?
<jdstrand> hrw: yeah, I am going to be working on it today
<jdstrand> hrw: what are the packages?
<hrw> jdstrand: cool, thanks
<hrw> jdstrand: all with armhf in name: armhf-cross-toolchain-base, gcc-4.[456]-armhf-cross, gcc-defaults-armhf-cross
<hrw> jdstrand: I will take care of build order once they will be out of NEW
<cjwatson> seb128: thanks
<stgraber> win 39
<stgraber> oops
<slangasek> cjwatson: doh, sorry for the mismerge; are you fixing/uploading, or do you need me to do something?
<cnd> cjwatson, do you have a bug number for the bug we were hitting with the Unincorp trigger?
<cjwatson> Daviey,cnd: new dpkg should fix it
<cjwatson> cnd: no
<cjwatson> I couldn't see a reported bug anywhere particularly obvious, so just fixed it
<cnd> ok, knowing it's a dpkg bug is good enough :)
<cjwatson> slangasek: done now.  oddly, I couldn't see anything in your upload that should have broken it
<slangasek> huh
<cjwatson> trigdeferred.c was out of date in the same way in the old version too
<cjwatson> and the changes to trigcmd.c that tickled it were in the old version
<cjwatson> but meh, I tested my change and it fixed the problem in my chroot
<slangasek> ah, an out-of-date generated file rather than a missing merge, doh
<cjwatson> slangasek: merry hell to find
<Daviey> cjwatson: awesome, thanks
<apw> mdeslaur, you about?  seems the fix for kernel 3.0 version issue in lm-sensors-3 (bug #797001) is only good for 3.0, i've re-fixed it up and pushed a branch to the bug ... testing is in the bug ... perhaps you could review
<ubottu> Launchpad bug 797001 in lm-sensors-3 (Ubuntu) "sensors-detect won't recognize 3.0 kernel" [Medium,In progress] https://launchpad.net/bugs/797001
<mdeslaur> apw: hold on a sec
<mdeslaur> apw: ah, yes, that makes more sense
<mdeslaur> apw: I'll upload it in a sec
<apw> mdeslaur, thanks
<jelmer> barry: hi
<mdeslaur> apw: uploaded, thanks
<apw> mdeslaur, thank you
<pitti> charlie-tca: oh, your goal is to not ship libgtk-3-0?
<ogra_> vs porting the whole of xfce on his own ? :)
<pitti> charlie-tca: I thought you were using evince and other GNOME apps
<seb128> not using gtk3 is not going to work
<ogra_> hmm ?
<ogra_> you think all of universe will be ported by release date ?
<seb128> it's going to hard to find a gtk application to use
<seb128> no, but I think if you want to get ride of gedit, eog, file-roller, evince, etc it's not a win
<ogra_> ah, yeah
<seb128> well you can but you will corner yourself at shipping applications which don't have an active upstream
<seb128> because those who have one will be ported
<seb128> it's not really a winning option
<ogra_> but what do you do if your DE upstream doesnt move ?
<seb128> you ship 2 gtk versions
<RoAkSoAx> cjwatson: howdy!! I was wondering if you managed to look into providing some kind of file with info in the Ubuntu mini.iso after discussing it at the UDS (with kirkland as well)
<seb128> we do that for Ubuntu...
<seb128> you can have a shell on gtk2 and application on gtk3
<seb128> that's basically what oneiric is
<kirkland> RoAkSoAx: grab that bug number, i think cjwatson upped it from won'tfix to triaged, as i recal
<seb128> well until next week when unity-gtk3 lands
<ogra_> sure, but that eats CD space
<cjwatson> RoAkSoAx: I closed that bug with an explanation of what I'd done
<cjwatson> bug 765254
<ubottu> Launchpad bug 765254 in debian-installer (Ubuntu Oneiric) "MiniCD needs a .disk/info structure" [Wishlist,Fix released] https://launchpad.net/bugs/765254
<seb128> ogra_, welcome to our world ;-)
<ogra_> heh
<cjwatson> I guess you don't read your bug mail either? ;-)
<seb128> ogra_, you just summarize oneiric :p
<ogra_> (me hugs his ARM world for not having these restrictions)
<RoAkSoAx> cjwatson: ah cool!! I somehow missed that :) Thanks!!
<RoAkSoAx> kirkland: Will now get the import with cobbler to automatically detect it
<kirkland> cjwatson: thanks
<apw> cjwatson, i am wondering if this was the message which was the dpkg bug: bug #798800
<ubottu> Launchpad bug 798800 in libcanberra (Ubuntu) "package libcanberra-gtk-module 0.28-0ubuntu5 failed to install/upgrade: ErrorMessage: syntax error in triggers deferred file `/var/lib/dpkg/triggers/Unincorp' at character `:' midline" [Undecided,New] https://launchpad.net/bugs/798800
<SpamapS> pitti: hah, ok, I was just thinking you had been really good about getting them all done. OOPS!
<pitti> SpamapS: well, I still did quite a few of them this mornign :) basically all that could be accepted, there were some which need further discussion or wait for the current proposed pacakge
<smoser> slangasek, ping.
<slangasek> smoser: ohai
<smoser> bug 798803
<ubottu> Launchpad bug 798803 in atkmm1.6 (Ubuntu) "package libatkmm-1.6-1 2.22.5-1 failed to install/upgrade: ErrorMessage: syntax error in triggers deferred file `/var/lib/dpkg/triggers/Unincorp' at character `:' midline" [Medium,Confirmed] https://launchpad.net/bugs/798803
<smoser> i'm thinking its related to your dpkg upload/merge
<slangasek> smoser: already fixed in the preceding dpkg upload by cjwatson
<smoser> well there ya go. i'm slow.
<hallyn> bug 798798 looks unrelated to libcap.  First error comes from tex, and the rest all seems somehow unicode related.  Not sure what to target the bug at.
<ubottu> Launchpad bug 798798 in libcap2 (Ubuntu) "package libcap2-bin 1:2.21-1 failed to install/upgrade: ErrorMessage: syntax error in triggers deferred file `/var/lib/dpkg/triggers/Unincorp' at character `:' midline" [Undecided,New] https://launchpad.net/bugs/798798
<hallyn> ah
<hallyn> same as smoser's
<hallyn> i'll just mark it as a dup then
<slangasek> yes please
<smoser> i just moved mine to dpkg, and marked fix released.
<slangasek> sorry for the breakage :/
<hallyn> oh feh it was the same guy :)
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
<slangasek> Daviey: do you know why my one-line edit of debian/control has broken builds of libapache2-mod-perl2? :)
<cjwatson> apw: yes
<nigelb> heh
<Daviey> slangasek: developers not testing uploads? ... :)
<apw> cjwatson, is there a master bug to dup it to?
<cjwatson> apw: not that I know of
<slangasek> Daviey: that's orthogonal! :)
<Daviey> slangasek: heh.. no - it was an interim issue.. NFI what caused it.. built locally here, so i fired rebuild.. and it worked
<slangasek> Daviey: I didn't test that it still built because I only edited a Recommends to a Suggests :-)  ok
<apw> ok i'll just cloose it off
<apw> cjwatson, actually it looks like bug #798803 is becoming the master
<ubottu> Launchpad bug 798803 in dpkg (Ubuntu) "package libatkmm-1.6-1 2.22.5-1 failed to install/upgrade: ErrorMessage: syntax error in triggers deferred file `/var/lib/dpkg/triggers/Unincorp' at character `:' midline" [Medium,Fix released] https://launchpad.net/bugs/798803
<Daviey> slangasek: seems to be unreleated to the dpkg issue. :/
<Daviey> it just needed some pixie dust i think
<cjwatson> apw: feel free to make it so then
<cjwatson> I couldn't find one when I was fixing it
<apw> cjwatson, that one has a couple of dups now, but yeah i think yours was first, duped, thanks
<cjwatson> I posted recovery instructions to that bug - it can be tricky to get out of
<cjwatson> and off for the weekend, please somebody else field any followup :)
<smoser> anyone able to review/sponsor https://code.launchpad.net/~smoser/ubuntu/oneiric/rsyslog/merge-debian-5.8.1-1/+merge/63761
<Daviey> smoser: request a review from ~ubuntu-sponsors :)
<smoser> Daviey, well its already on the sponsorship queue
<Daviey> so it is.
<Daviey> smoser: You really need to be uploading this stuff yourself.
<Daviey> :)
<slangasek> RAOF: ok, all the build-deps of mesa are fixed up now to be multiarch-installable in unstable except for one :)
<micahg> apw: sorry about that partial fix for lm-sensors-3, the upstream ML actually has a slightly better one that ignores the extra parenthesis, so it's still a one line fix, I'll get it uploaded next week
<astraljava> Hey all, I know this is a bit out of the scope for this channel, but since none of the "support" channels can help in this, I wonder whether any developer could spare a couple of their brain cycles and tell me where I can save applications into a session, the functionality that used to be in Startup Applications. This is natty we're talking about.
<hv> What does cannonical/ubuntu use for conference planning?
<hv> what software or service, that is
<slangasek> which aspects of planning are you referring to?
<slangasek> there's the summit.ubuntu.com software
<slangasek> most of the logistical planning of the conferences themselves is done in wetware, not software :)
<hv> umm, I am looking for a simple but good conference planning (at least, should handle online registrations + payments)
<broder> hmm...who's responsible for http://reports.qa.ubuntu.com/reports/sponsoring-stats/? the most recent data point on # of entries in the queue is 10 or so. while that would be *awesome*, there are actually about 70 things in the queue
<hv> is summit.ubuntu.com available for external use (possibly paid)?
<slangasek> hv: Ubuntu conferences have no associated registration fees, so I don't think that'll be much help :-)
<broder> hv: maybe look at what linux plumbers is using?
<broder> theirs definitely does online registration + payments
<hv> slangasek, broder: thanks
 * hv wishes academic conferences do away with registration fees ...
<nigelb> hv: summit.ubuntu.com code is open source
<nigelb> If you want to run it for your own conference that's totally fine
 * nigelb reads scrollback.
 * hv bzr branches summit ...
<nigelb> hv: #ubuntu-website would be the right place to ask for doubts/questions you may have
<hv> nigelb: thanks.
<jono> it seems GNOME Settings Daemon is broken in Oneiric - is this known?
<RoAkSoAx> jono: what's your issue?
<seb128> jono, no
<RoAkSoAx> cjwatson: in the mini-disk info file, http://pastebin.ubuntu.com/628555/, will the release always appear as "oneiric" or will it be "Oneiric Ocelot" and the arch will always be i386 or "Beta i386" as it shows with the regular server ISO?
<Ampelbein> hi! I'm trying to find the cause for a FTBFS on current oneiric, the package in question is gridsite. This is the log: http://paste.ubuntu.com/628557/ - The package builds fine on debian/unstable. Can someone give any hints on what might be wrong?
<micahg> Ampelbein: looks like an --as-needed failure
<slangasek> I don't see how
<slangasek> these are from libcrypto, which is on the commandline
<slangasek> btw, someone seems to have typoed '-D_LARGEFILE64_SOURCE' :)
<Ampelbein> micahg: hmm, you are right. with -Wl,--no-as-needed it works... but... why?
<micahg> Ampelbein: with --as-needed order of the arguments matter, http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
<slangasek> true, but -lgridsite -lssl -lcrypto is the correct order :)
<slangasek> so why does *this* fail?
<slangasek> oh, no
<slangasek> it's that gridsite-storage.c doesn't need libcrypto, libgridsite.so does
<slangasek> so -lcrypto needs to be passed when linking *libgridsite.so*
<slangasek> it's a mislinked library, which gets exposed when trying to link against it
<slangasek> (and also, btw, in a dpkg-shlibdeps warning that's been in the log output for several years before this I'm sure)
<slangasek> oh, it's an entirely new package, so scratch the "several years" part :-)
<Ampelbein> slangasek: I was about to say that it never actually built in ubuntu ;-)
<Ampelbein> micahg, slangasek: thank you, with your help I found the error.
<Ampelbein> I think
<Ampelbein> ok, yes. so the root of the problem was that http://paste.ubuntu.com/628565/ made libgridsite.so not correctly linked with crypto (and xml2). adding -lcrypto and -lxml2 AFTER the objects made the compile succeed. Thanks again micahg and slangasek!
<slangasek> sure :)
<Daviey> slangasek: I've seen you mention this a few times, so i wanted to clarify something.. regarding calling an upstart reload... I understand in package maintainer scripts should invoke-rc.d.. but what about debian/*logrotate scripts?
<Daviey> Is it ok for them to call "reload" directly?
<slangasek> Daviey: it's ok, but it does increase the delta with Debian
<slangasek> Daviey: '/etc/init.d/$service reload' should do the same thing in both Debian and Ubuntu, with an insignificant increased overhead for Ubuntu
<Daviey> slangasek: TBH.. one line change in a fairly hunky delta anyway, doesn't make me cry so much :)
<slangasek> yeah... general principle though :)
<smoser> you should drop that change though
<smoser> yeah.
<smoser> i just assumed that 'reload' wasn't going to do anything for upstart... or that there was some other reason that it was like it was.
<Daviey> smoser: it's your merge proposal!
<smoser> yes, and i will admit that i'm wrong.
<smoser> or that i should have dropped that.
<Daviey> smoser: Oh no, i wasn't pointing fingers.
<smoser> but i dont tihnk it ever should have been added.
<Daviey> smoser, agreed - but there is clearly some uncertainity about handling upstart in scripts.
<smoser> i can modify my proposal if you want
<Daviey> So the original delta introduction wasn't evil either.
<smoser> that was one of the only things that wasn't straight forward to me.
<Daviey> smoser: I don't really care TBH.. both work, and 1 line isn't a big deal.. especially as it's not totally /wrong/
<smoser> if we drop it, and theres no regression due to it, then the next person wont be confused or have to think about it.
<Daviey> as we seem to have no clear policy on this
<smoser> well, the policy that is clear is "don't change debian just because"
<Daviey> heh
<Daviey> smoser: there are two uses of that, that changes everything... do it!
<smoser> Daviey, revision 43 pushed up
<Daviey> ta
<smoser> oh shoot
<smoser> yea...
<smoser> so Daviey , slangasek debian now has:
<smoser>  invoke-rc.d rsyslog rotate
<smoser> not 'reload', but 'rotate'.
<slangasek> that's not a standard argument at all
<smoser> and they have a target for that in the init script that sends -HUP
<smoser> right
<smoser> so we have a delta in that file one way or another
<slangasek> do they have a different definition of 'reload' in the init script?
<smoser> and 'reload rsyslog' will send -HUP
<smoser> no, they dropped the 'reload'
<smoser> only 'force-reload' now, which does 'stop; start'
<slangasek> ...
<smoser> its in their changelogs too... i knew i had some reason for this to be left as it was
<Daviey> smoser: i thought i saw rotate, i was *just* checking that
<smoser> rotate was in the merged stuff from debian
<smoser> it changed between that.
<smoser> so then... i ask slangasek, i think. we're back to having a choice between:
<smoser> reload rsyslog
<smoser> or
<smoser> invoke-rc.d rsyslog reload
<smoser> where the invoke-rc.d path is still delta from debian
<slangasek> smoser: I think the init script should ditch this silly non-standard option, and the logrotate script should call 'kill -HUP $(cat /var/run/rsyslogd.pid)' directly in Debian, which would happen to work right in Ubuntu as well
<slangasek> and we should never call invoke-rc.d from logrotate scripts
<Daviey> smoser: sounds to me that leaving it as it was makes better sense, and raising a debian bug suggesting reload does a -HUP :)
<Daviey> slangasek: ok?  why never call invoke-rc.d from logrotate scripts?
<slangasek> Daviey: the reason not to do a HUP with reload in the init script is that it doesn't actually reload the configs, so doesn't fit the definition of the target (Debian bug #580897, Policy 9.3.2)
<ubottu> Debian bug 580897 in rsyslog "rsyslog: doesn't update all rules on reload" [Normal,Fixed] http://bugs.debian.org/580897
<slangasek> Daviey: because invoke-rc.d is used to apply a local admin policy on whether maintainer scripts are allowed to start and stop services, which is entirely irrelevant to the question of whether a running daemon needs to reopen logfiles after rotation
<slangasek> at best, invoke-rc.d is a no-op; at worst it causes you to lose your log data
<Daviey> *sigh*
<smoser> ok.
<smoser> i'll push up the revert of that.
<slangasek> no-op compared to direct invocation of the init script, I mean
<Daviey> slangasek: yeah, thanks for that
<Daviey> smoser: BTW, your regular commit approach makes it much easier to review (and presumably useful to peeps in the future).  Thanks.
<smoser> pushed again
<natschil> Hello. I made a kind of custom ubiquity (i.e. added one or two lines), and I was wondering if anyone could tell me whether ubiquity is run as root or not, as the code in question needs to mount stuff and thus would need to run with certain privilidges
#ubuntu-devel 2011-06-18
<apw> micahg, i assume we may as welll leave things as they are till debian takes it and we can just sync with them
<cjwatson> RoAkSoAx: I won't add "Beta" or similar.  For the release name, what would you prefer?
<sebashtemp> Hi, am right here for help? I am building my first .deb and I have and the software builds a .so but it's not really intended to be used by other programs. Where should I put this thing? still /usr/lib ?
<tumbleweed> sebashtemp: /usr/lib/$packagename/ ?
<moystard> hello everyone
<charlie-tca> !hi | moystard
<moystard> currently having a look on how to contribute :)
#ubuntu-devel 2011-06-19
<RoAkSoAx> cjwatson: the way the .disk/mini-info is just fine. Was just checking too make sure that the parsing I'm doing would work in any case. Thanks
<broder> tumbleweed: ping? are you around? i'm working on https://code.launchpad.net/~broder/ubuntu-dev-tools/fix-785854 and trying to figure out why it's failing pylint
<broder> i get http://pastebin.ubuntu.com/629564/, which is weird, since i should be explicitly filtering those errors
<tumbleweed> broder: pylint can't infer types around subprocess (you'll find pylint supressions around lots of subprocess calls)
<tumbleweed> it's a known upstream bug
<broder> tumbleweed: i know that, but why isn't my suppression working?
<tumbleweed> oh, you used a regex
<tumbleweed> hrm
<tumbleweed> broder: passes for me on wheezy
 * broder shrugs
<broder> maybe natty's pylint is just confused. i'll go ahead and re-propose, then
#ubuntu-devel 2012-06-11
<vibhav> micahg: You there?
<micahg> vibhav: yes
<vibhav> micahg: Firstly thanks for reviewing my debdiff. Could you please tell me the unnecessary changes for the debidiff in https://bugs.launchpad.net/ubuntu/+source/libjpeg6b/+bug/1011177 ?
<ubottu> Launchpad bug 1011177 in libjpeg6b (Ubuntu) "Please merge libjpeg6b 6b1-3 from Debian Unstable" [Undecided,Incomplete]
<vibhav> (I think its the multi-arch support)
<vibhav> But is there something more to be removed?
<micahg> vibhav: it's part of the multiarch stuff in debian/rules, also take a look at debian/control
<vibhav> sure, let me take a look
<vibhav> micahg: Could a sync work?
<micahg> vibhav: I don't think so, let me take another look
<micahg> vibhav: no
<vibhav> fine, let me prepare a merge
 * micahg wonders where the -Bsymbolic-functions change went
<larsduesing> Good morning
<vibhav> micahg: Pre-Depends: multiarch-support in debian but Pre-Depends: ${misc:Pre-Depends} in ubuntu , what should I do?
<larsduesing> Could anybody have a look over https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-apport-fix please?
<micahg> vibhav: the Ubuntu version is correct with the proper debhelper build dep
<siretart> apachelogger: oh, seems that I touched the wrong bug. I need to apologize
<didrocks> hey doko_, can I get your opinion on https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035310.html ?
<didrocks> infinity: I experience g-s-d exiting, I wonder if it's not due to the rebuild with the gnome-desktop ABI breakage
<dholbach> good morning
<didrocks> guten morgen dholbach :)
<dholbach> salut didrocks
<tsdgeos> what's the process to get openjpeg 1.5 into quantal instead of old 1.3 ?
<RAOF> tsdgeos: Looks like that's a sync from Debian; if Debian has 1.5 then we'll get that in the next autosync. If Debian *doesn't* have 1.5 then that's the best way to get it into quantal at this point.
<RAOF> An insufficiently lazy person might also upload it direct to Quantal, but they'd be being inefficient âº
<tsdgeos> RAOF: it's in debian experimental, i guess that's not enough?
<RAOF> Ah, the other option.
<RAOF> That means it's a sync away, if it's appropriate.
<micahg> needs a transition, not sure if it's API compatible
<RAOF> ie: if it's in experimental because it's crack we might not want it. If it's in experimental because Debian's about to freeze and they didn't want to play the rdepends game, that's ok :)\
<tsdgeos> my other question is: how much work it takes for it to go to main so poppler can use it?
<tsdgeos> it = openjpeg
<RAOF> That somewhat depends; https://wiki.ubuntu.com/MainInclusionProcess is the process.
<RAOF> By and large it shouldn't be too arduous for a library. Although you probably need to be more security concious than normal, given it's playing with untrusted data.
<tsdgeos> sure
<tsdgeos> that's why we need 1.5
<tsdgeos> so it doesn't crash :D
<RAOF> But openjpeg's not in main yet, right?
<tsdgeos> nope
<tsdgeos> what you get now is the "worse" poppler jpeg2000 decoder
<tsdgeos> that has its fair share of problems
<RAOF> Aah.
<tsdgeos> and obviously noone wants to touch given openjpeg is there
<RAOF> That should make it reasonably easy, then.
<tsdgeos> maintained and done by people that actually understand what it does
 * micahg doubts openjpeg would be allowed in main, it's not even popular enough with browsers
<tsdgeos> micahg: so you're going to maintin poppler's jpeg2000 decoder instead?
<tsdgeos> the rationale is kind of wird
<tsdgeos> because main has poppler
<tsdgeos> and poppler has a worse jpeg2000 decoder
<tsdgeos> so not including openjpeg it just means bigger holes are there
<larsduesing> Hmm, would be https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1001432 a SRU-Candidate or even Security-Update-Candidate? (It is no "bug", but loss of confidentiality and integrity)
<ubottu> Launchpad bug 1001432 in aiccu (Ubuntu) "apport doesn't deliver aiccu.log but sensitive information with bug reports" [Undecided,Fix committed]
<larsduesing> (and yes, I know, it is atm not in quantal, but in state of proposal for that...)
<larsduesing> (just preparing for the next steps)
<micahg> tsdgeos: I don't do the security reviews, so idk which is better :)
<tsdgeos> micahg: i do
<micahg> tsdgeos: well, just make sure you include the pertinent info if you end up filing the Main Inclusion Request
<RAOF> Is this understanding of arm madness correct: armv5 code will run on armv6 & armv7, but (obviously) not visa versa.
<cjwatson> ev: heh, speaking of doubling up I'd just started on apt-clone ;-)
<cjwatson> ev: happy to give it up - want my branch?
<ev> sure, I'll take it off your hands
<cjwatson> ev: lp:~cjwatson/apt-clone/py3, have fun
<ev> cjwatson: cheers!
<cjwatson> only ten minutes' worth of work
<jodh> cjwatson: morning - what would you like me to look at?
<cjwatson> jodh: fancy figuring out what's involved with producing a python3-newt?
<jodh> cjwatson: I'll give it a shot :)
<cjwatson> ... glad it's not just me who read 9 UTC and assumed 9am
 * jodh is coffee-deprived yet keen.
<vibhav> What is the difference between Pre-Depends: ${misc:Pre-Depends} and Pre-Depends: multiarch-support while building a package for multiarch?
<cjwatson> vibhav: The former is what should be written in source packages, and is expanded to the latter in binary packages
<cjwatson> man dh_makeshlibs
<cjwatson> jodh: please add yourself to https://wiki.canonical.com/UbuntuEngineering/Foundations/Python3PortingSprint if you're taking that bit
<jodh> cjwatson: done.
<vibhav> cjwatson: Im merging libjpeg6b from sid, the orignal control says "Pre-Depends: multiarch-support" while the ubuntu control says "Pre-Depends: ${misc:Pre-Depends}" (while both are built for multiarch) what should I do?
<cjwatson> vibhav: While the latter is normally preferable, there's no point keeping an Ubuntu delta for it
<cjwatson> So just use the Debian side
<vibhav> cjwatson: Why was "-Bsymbolic-functions" from LDFLAGS removed from the ubuntu build then?
<vibhav> (there is a delta for it too)
<cjwatson> If you don't understand it, pick something else
<cjwatson> Merges aren't actually an easy introductory task
<vibhav> Not that hard though
<cjwatson> They can be
<vibhav> cjwatson: see https://merges.ubuntu.com/libj/libjpeg6b/libjpeg6b_6b1-2ubuntu1.patch
<cjwatson> Why don't you try building the Debian version and see what happens?
<cjwatson> Also, there's a note in the changelog about why that was removed
<cjwatson> +  * debian/rules: Remove "-Bsymbolic-functions" from LDFLAGS, as this flag
<cjwatson> +    breaks the libjpeg use by HPLIP and pxljr, in both cases for printing
<cjwatson> Did you not see that bit?
<cjwatson> +    on the HP Color LaserJet 3500/3550/3600 (LP: #777670).
<vibhav> ah yes
<vibhav> So should we still have a delta for it?
<cjwatson> Why would we not?
<cjwatson> You must have an active reason to discard a delta
<vibhav> SO, Ill remove the multiarch stuff from the merge?
<cjwatson> Probably; I haven't looked at it in any detail
<vibhav> libjpeg6b (6b1-3) unstable; urgency=low
<vibhav> * Add multiarch support (similar to libjpeg8). closes: #642079
<cjwatson> The reason the -Bsymbolic-functions change might not be in Debian is that having -Bsymbolic-functions in LDFLAGS by default is specific to Ubuntu's packaging toolchain
<cjwatson> So Debian would probably not have seen the need to remove it
<cjwatson> mvo: http://changelogs.ubuntu.com/meta-release-development looks a bit malformed - "Name:  Quantal Quetzal'"
<cjwatson> (trailing apostrophe)
<cjwatson> mvo: And ReleaseNotesHtml isn't HTML for lucid and maverick there - is that deliberate?
<cjwatson> mvo: Seems to cause trouble running the tests
<cjwatson> mvo: Generally I seem to find it rather hard to get the u-m test suite to consistently pass on my machine :-/
<mvo> cjwatson: right, what tests are failing for you currently? happy to have a look
<jamespage> vibhav, pong (but I think I know why...)
<cjwatson> mvo: test_private_ppa_transition and test_html_uri_real - http://paste.ubuntu.com/1035212/
<mvo> cjwatson: thanks, looking now
<apachelogger> siretart: I am not sure, seems to me apport didn't really know what to do with 2 errors in the same log and marked it duplicate of libav, while there is also a bug regarding kdegames
<apachelogger> pitti: could you have a look at bug 1011310 to check whether what apport did was behavior as expected
<ubottu> Launchpad bug 1011310 in kdegames (Ubuntu) "package kdegames-card-data-extra 4:4.8.3-0ubuntu0.1 failed to install/upgrade: trying to overwrite '/usr/share/kde4/apps/carddecks/svg-oxygen-air/11.png', which is also in package kdegames-card-data 4:4.8.3-0ubuntu0.1" [Undecided,New] https://launchpad.net/bugs/1011310
<siretart> apachelogger: I didn't check too closely either
<apachelogger> siretart: k :)
<pitti> apachelogger: not really the right thing in this case, of course
<pitti> I think apt takes the first failure and uses that as the identifying one
<pitti> because very often, the failures below it are just a consequence of the first one, and not really bugs of their own
<apachelogger> pitti: not always though, so I wonder if the apport bot shouldn't just add a comment and hint that the bug might be a duplicate of #123 instead of marking it ... for logs that exhibit multiple errors anyway
<pitti> right, not always, but often enough
<apachelogger> otherwise valid data on a valid bug other than the first choice duplicate might get lost unless someone manually follows the bot
<pitti> it's imperfect no matter how you do it :(
<pitti> so yes, I don't mind changing this, but it will lead to a lot of unidentified/unclosed real dupes then
<apachelogger> *shrug* marking them is a bit of a gamble as the now burried bug might get reported invidually and compensate for the lost information, or it might not... since I don't have data on how well the gamble works out I couldn't not say anything but "not burrying data > burring data"
<vibhav> dholbach: thanks for sponsering my upload!
<vibhav> sponsoring*
<vibhav> jamespage: Nevermind, I just wanted to ask wether I could prepare a merge for jffi since you were the last guy to touch it in Ubuntu
<jamespage> vibhav, yeah - I spotted - no problemo
<mterry> mpt, hello!  A few weeks ago you mentioned that the icon in Software Updater windows should all be the updater application icon.  But there's also bug 510212 in which (a while ago) you suggest it should be the Ubuntu icon.  Was there a change of heart and we should close that bug?
<ubottu> Launchpad bug 510212 in update-manager (Ubuntu) "update-manager: no branding. Is it legit?" [Medium,Triaged] https://launchpad.net/bugs/510212
<mpt> mterry, well spotted
<mpt> I had forgotten about that one
<mterry> mpt, thank Timothy Arceri, who added it to the blueprint
<mpt> mterry, I really don't know. On one hand there's the rationale described in that bug report. On the other hand, it's maybe not so good for the Ubuntu logo to be associated with administrative work.
<mpt> mterry, what do you think?
<mterry> mpt, I don't think it would bother me to use the Ubuntu logo.  What do other platforms do?  I'm assuming Windows splashes its logo all over Windows Update.  What about Mac?
<mpt> mterry, Windows Update uses a Windows retail case with a halo around it, but not prominently. <http://en.wikipedia.org/wiki/File:Windows_Update.png> OS X has a distinct application icon. <http://www.maclife.com/article/howtos/disabling_specific_software_updates>
<vibhav> the halo looks more like a revolving planet
<mterry> mpt, well, Windows Update at least has the brand name in there.  But the Mac one only says Software Update and also doesn't have any other Mac branding.  So I'd assume they'd have the same considerations in that bug that we woul
<mterry> d
<vibhav> mterry, mpt: We could improvise the Update Manager logo by putting a ubuntu logo on the "box"
<mterry> But I've never heard of people being confused or not trusting that dialog (though not sure I would hear...)
<vibhav> s/improvise/improve (or "legitize")/
<mpt> vibhav, yeah, we need a new logo anyway, the current logo is rather boring
<mpt> (where I am awkwardly using "we need" to mean "I would really like to see")
<vibhav> mpt: What about a ubuntu logo with a plus above?
<mpt> or something like that
<vibhav> hmm
<mpt> an Ubuntu logo with arrows on it, or a magic wand over it, or a cloth and washbucket, or...
<vibhav> What about some typography?
<mpt> mterry, I will discuss this with ivanka tomorrow, because she raised a similar issue with me earlier (the use of an Ubuntu logo in the whoopsie error alerts)
<vibhav> What about http://icondrawer.com/img/Mac-update-icon.jpg (Replacing the M with the Ubuntu Logo in which the arrow is attached with the corcle of friends)
<vibhav> circle*
<mterry> mpt, cool
<mpt> mterry, but I suspect the answer will be something like what vibhav suggests
<mpt> Adding the Ubuntu logo to the application icon in some way
 * mterry eagerly awaits new art assets
<vibhav> And the apport icon could look like a Ubuntu Logo bandages on it
<mpt> vibhav, we may remove the Ubuntu logo from the error alerts altogether, for reasons described in <http://uxmag.com/articles/your-logo-is-making-me-sick>
<infinity> didrocks: Could be.  Or couls be entirely unrelated. :P
<didrocks> infinity: it was ;) I fixed it this morning
<infinity> didrocks: Shiny.
<infinity> didrocks: Fixed in which package?
<didrocks> infinity: gnome-desktop itself, it was not related to the ABI itself, but was part of the same migration/upgrade
<infinity> Ahh.
<vibhav> What is the difference between gettext and gettext:any ?
<vibhav> I was merging a package in which the change in ubuntu had been incorporated into debian too
<vibhav> (Which was adding gettext to build-depends)
<infinity> vibhav: The latter is a hack to hint at apt that gettext from any arch can satisfy the build-dep.
<vibhav> infinity: That is what the ubuntu delta has, while the debian version has just gettext , Should I file a syncrequest
<vibhav> Since thats the only change
<vibhav> The packge I am talking about is attr
<infinity> vibhav: We added all the :any intentionally last cycle.  I don't recall, of the top of my head, if we still need them.
<infinity> cjwatson / slangasek: ^-- ?
<vibhav> https://merges.ubuntu.com/a/attr/
<infinity> s/of/off/
<cjwatson> infinity: We do.
<cjwatson> vibhav: Do not drop changes if you don't understand them.
<cjwatson> I cannot stress this too much!
<cjwatson> You should NOT file a sync request in this case.  Doing so will obstruct our progress towards cross-building Ubuntu.
<vibhav> cjwatson: Actually, I havent dropped them
<vibhav> I was abit confused
<cjwatson> You just proposed doing so
<cjwatson> Unfortunately, we cannot push these changes back to Debian yet, since Debian's buildds don't support them.
<cjwatson> So we have to carry them as deltas.
<vibhav> cjwatson: So, I am going to prepare a merge, right?
<infinity> cjwatson: Curious that Debian's don't and ours do, given that ours do nothing special here.
<cjwatson> vibhav: Have you talked to the person who touched it last, to ensure that you aren't duplicating work?
<cjwatson> infinity: They're running apt on an older base system, I think.
<infinity> cjwatson: Or do you mean it trips up wanna-build's auto-dep-wait magic?
<infinity> Oh, right.
<cjwatson> Or maybe w-b, yes, not sure.
<infinity> No, it's probably apt.
<cjwatson> Steve was going to look nto it.
<vibhav> or wait, the only change is adding gettext as a dependency
<infinity> I ditched the whole "external apt" thing ages ago, cause it drove me nuts.
<vibhav> So, No merge
<infinity> vibhav: It could be a no-nop merge that just merges the changelog, to keep us from having MoM bug us.
<vibhav> infinity: How does one do that?
<cjwatson> One does a merge.
<vibhav> Also, http://packages.debian.org/changelogs/pool/main/a/attr/attr_2.4.46-7/changelog
<vibhav> cjwatson: Yeah, but what do I write in the changelog?
<cjwatson> The same as you would for any other merge.
<infinity> Same thing as always.
<cjwatson> We have changes we have to retain, and you would list them.
<vibhav> ah, got it \m/
<infinity> "Remaining changes: s/gettext/gettext:any/, made package better, added cheese, sprinkled paprika on top, etc"
<cjwatson> The 1:2.4.46-7 changelog is Debian reverting the change we sent them because it broke on Debian buildds.  But that doesn't mean it would be correct to drop that change from Ubuntu.
<cjwatson> slangasek: ^- Did vibhav talk with you about this merge in advance?
<vibhav> nope
<vibhav> I was going to ask him
<slangasek> vibhav: I have no objection to you taking it; I hadn't been bothering because there's nothing new to merge from Debian, it would just be to make MoM happy, but as long as the changes aren't dropped, I don't mind :)
<infinity> It was mother's day recently; keeping MoM happy is a good thing.
<yolanda> hi, have this package in queue: https://launchpad.net/ubuntu/quantal/+queue?queue_state=0&queue_text=underscore
<yolanda> i wanted to ask an archive admin to take care of it and review it
<vibhav> slangasek: Have you seen the 2011 section http://packages.debian.org/changelogs/pool/main/a/attr/attr_2.4.46-7/changelog ?
<slangasek> vibhav: yes
<slangasek> vibhav: the maintainer merged the Ubuntu changes then reverted them again in Debian.  We should not be reverting them in Ubuntu.
<vibhav> Ah , I was wondering why a ubuntu distroseries was there in a debian changelog
<vibhav> Should I add a "Makes MoM happy" to the changelog?
<slangasek> I wouldn't
<vibhav> :P
<vibhav> slangasek: Done: https://bugs.launchpad.net/ubuntu/+source/attr/+bug/1011639
<ubottu> Launchpad bug 1011639 in attr (Ubuntu) "Please merge attr 1:2.4.46-7 from Debian Unstable" [Undecided,New]
<doko> directhex, chrisccoulson: http://gcc.gnu.org/wiki/Cxx11AbiCompatibility  don't know what the best thing is. build libsig++ twice? I agree that it will be pain to find all these libraries
<larsduesing> pitti: Short question, do you know since which release apport in ubuntu is enabled by default?
<pitti> larsduesing: since 12.04 LTS
<pitti> I'm lobbying for turning it off for 12.04.1, though
<larsduesing> oh
<pitti> the precise (and even current) version are still getting in the way very often, and I've heard a lot of angry complaints from users
<larsduesing> ok
<larsduesing> so there is no sense in adding apport-hooks for versions before 12.04 ?
<larsduesing> (even for a security-update?)
<pitti> very little, unless they make sense for manual bug reports
<larsduesing> it sends login-data to launchpad-bugreports if a run of "apt* install" fails...
<larsduesing> so it happens only on automated reports
<larsduesing> thanks
<jbicha> pitti: yes, please turn it off :)
<jbicha> I've read "reviews" where people think precise is more buggy than previous releases because of the annoying popups
<jbicha> I would have thought that System Settings>Privacy>Diagnostics>Send error reports to Canonical would have done the same thing as editing /etc/default/apport but it doesn't work that way
<hippiehacker> What process is used to create the official 12.04 images? Is it livecd-rootfs + live-build, if so what versions and configs?
<Sweetshark> jbicha: then we should enable apport only in the pre-LTS release and make it generate some fake reports. LTS will then be perceived as rock-solid.
<mterry> pitti, speaking of automated reports, some bugs like bug 1011293 (a crash in gnome-settings-daemon) are private and I can't make them public.  Is this a new policy for automated bugs?
<ubottu> Error: Launchpad bug 1011293 could not be found
<Sweetshark> pitti: fixed my bzr launchpad problem. It was an id-10-T issue.
<pitti> mterry: none that I'm aware of; I am able to make them public
<jbicha> Sweetshark: then everyone will run the LTS's instead which may not be a bad thing :)
<pitti> Sweetshark: nice to hear; whatever an id-10-T issue is :)
<jbicha> lol
<mterry> pitti, hmm.  I wonder what team is doing that for you.  Is there a way to find out?
<pitti> mterry: the $1M question!
<mterry> pitti, similarly, there was a question on the mailing list about who gets to see the data from errors.ubuntu.com
<pitti> I'm sure thousands of people have wondered about things like that
<pitti> mterry: I'm not entirely sure; I guess ~ubuntu-crashes-universe? ev?
<ogra_> that looks like a (bad) news headline
<ev> jbicha: /etc/default/whoopsie
<ogra_> universe collapsing, ubuntu is at fault !!!
<awe> so dramatic ogra_!  ;)
<ogra_> :)
<highvoltage> no the universe is ever expanding!
<pitti> highvoltage: that's still not proven :)
<slangasek> vibhav: thanks, I'll have a look at that a little later today
<ev> pitti, mterry: ~canonical + ~ubuntu-bug-control
<pitti> ah, thanks
<ogra_> highvoltage, dont trust news headlines !
<seb128> mterry, what happens when you try to put that bug public?
<mterry> ev, do you happen to know why I wouldn't be able to adjust the privacy of a bug?
<mterry> seb128, I don't even see the 'edit' icon to change the privacy
<mterry> seb128, it just says it's private
<ev> mterry: no idea - definitely not a change that I've introduced
<ev> mterry: ask in #launchpad-dev?
<mterry> k
<pitti> seb128: can you see the edit button?
<seb128> mterry, you don't have a label "This report contains User Data information" on the top right followed by a yellow round icon?
<seb128> pitti, ^
<seb128> click on it
<seb128> you should get a list
<pitti> from my part it might be anything between ~ubuntu-core-dev or ~techboard
<seb128> it's the new merge of security & private status
<seb128> pitti, mterry: http://blog.launchpad.net/general/how-bug-information-types-work-with-privacy
<mterry> seb128, no I don't see it
<seb128> mterry, the one one those screenshots?
<seb128> mterry, ok, I see it, maybe you are lacking privileges or something but that seems weird
<pitti> mterry: are you in ~ubuntu-bug-control?
 * mterry is ~canonical and ~core-dev, what more do I need
<seb128> pitti, do you have the ui?
<pitti> seb128: yes, I do
<pitti> mterry: that should suffice
<mterry> OK, so sounds like a bug maybe.  I've asked in #launchpad-dev, will report back
<seb128> mterry, you should ask on #launchpad I guess
<seb128> mterry, cool
<seb128> mterry, bug #1007588 btw is your issue
<ubottu> Launchpad bug 1007588 in gnome-settings-daemon (Ubuntu) "cannot set displays on dual monitor: No such interface `org.gnome.SettingsDaemon.XRANDR_2" [High,Confirmed] https://launchpad.net/bugs/1007588
<seb128> mterry, and it's quite "popular" recently on quantal, bonus point if you figure it out, g-s-d didn't change afaik, nor did gtk
<mterry> seb128, that looks like the same trace, but I'm just on my laptop.  No external monitor
<mterry> seb128, I've had it for a while, really annoying, so I started looking into it  :)
<mterry> The weird thing is that it's crashing in @plt, which is a weird technical detail of shared libraries.  It's not even hitting libgdk
<seb128> mterry, right, the title was confusing, I just changed it, it turned out that the underlining reason for the xrandr error was "g-s-d is not running"
<mterry> seb128, ah, makes sense
<mterry> seb128, guess I'll mark the other one as a dup
<seb128> mterry, yeah, I blame the toolchain, I don't think the GNOME stack changed
<seb128> mterry, I just did that
<mterry> kthx
<mterry> Well, a simple rebuild didn't fix it (and g-s-d has been rebuilt already in quantal anyway).
<mterry> doko, do you know much about "@plt" (procedure linkage table)?
<seb128> slangasek, pitti: could somebody accepted my mail from today to the tb list?
<pitti> seb128: can do
<seb128> pitti, danke
<doko> mterry, we have a new expert for glibc and dynamic loading ;) /me waves at infinity
<mterry> infinity, hi!  When you have a few moments, can you help me with bug 1007588?
<ubottu> Launchpad bug 1007588 in gnome-settings-daemon (Ubuntu) "[mouse]: gnome-settings-daemon SIGSEGV in gdk_device_manager_list_devices@plt()" [High,Confirmed] https://launchpad.net/bugs/1007588
<doko> didrocks, how ready is oneconf for Python3?
<didrocks> doko: well, I'll need to do the porting at the same time than software-center
<didrocks> doko: as it's imported from it
<didrocks> doko: will be quite easy, few days
<didrocks> doko: btw, I asked you a question this morning here
<didrocks> doko: it was about chris email on ubuntu-devel for sigc++
<chrisccoulson> doko, thanks
<chrisccoulson> did you mean to direct that at didrocks too?
<chrisccoulson> seems it went to the wrong person :)
<didrocks> I didn't receive anything if something was sent :)
<chrisccoulson> didrocks, ah, you were offline
<chrisccoulson> <doko> directhex, chrisccoulson: http://gcc.gnu.org/wiki/Cxx11AbiCompatibility  don't know what the best thing is. build libsig++ twice? I agree that it will be pain to find all these libraries
<didrocks> chrisccoulson: my internet connection dropped for 5 minutes, yeah
<chrisccoulson> ^didrocks
<didrocks> thanks :)
<doko> answering on the list. libstdc++ builds code for c++98 and c++11 in the same library. not sure if this is possible for other libs as well.
<didrocks> doko: ok, we are totally in that case (the first one of the new M_size member)
<didrocks> doko: oh, and we ship both?
<doko> no, it's in the same shared object
<arges> Are other people getting a lot of 'Hash Sum mismatch' messages on precise amd64 when installing packages? I've updated/upgraded, but still am getting them. Any suggestions?
<didrocks> doko: oh nice, is there a recipe to ensure to take the right functions then, can you give some links?
<doko> didrocks, no I don't have any :-/
<didrocks> I think we'll need a way for sigc++ for this
<cjwatson> arges: usually a transparent proxy getting in the way - find appropriate Release/Release.gpg/Packages URLs and wget --no-cache them
<didrocks> doko: do you think you will have some time allocated for looking at this? it seems you are the most knowledgeable for this
<arges> cjwatson, ok i'll try that
<hippiehacker> http://blog.init.hr/?p=183 # at the bottom they describe building the cloud-live iso from a launchpad branch... is there a similar launchpad branch for the 12.04 desktop isos?
<doko> didrocks, will do after our virtual Python3 sprint (which ends Wed).
<didrocks> doko: thanks :)
<hippiehacker> more specifically I'd love to find the ppa / live-build config that created http://hwe.ubuntu.com/uds-q/dellxps/
<infinity> mterry: I'm in the middle of a sprint right now, but I can help look at it in a couple of days, if you're still stuck.
<mterry> infinity, more likely I can just wait.  :)  I'm at the limit of my domain knowledge here, not productive to spin cycles without a pointer.  But there's no rush
<hippiehacker> I'm trying to create a custom iso for the xps13/sputnik project... does anyone know if there is a bzr/git repo for the live-build config that generated the http://hwe.ubuntu.com/uds-q/dellxps/ isos ?
<superm1> vanhoof: ^
<hippiehacker> superm1: thanks, I'll reach out to him
<superm1> sure
<infinity> mterry: Where's this u-m branch of yours without a-u-t?
<mterry> infinity, https://code.launchpad.net/~mterry/update-manager/drop-auto-tester
<infinity> mterry: Danke.
<mvo> mterry, infinity: stgraber was asking about this earlier too, please sync to ensure to not dupe work :)
<mterry> mvo, about the auto-tester stuff?  Or the crasher in @plt?
<mvo> mterry: the auto-tester
<mvo> mterry: not sure I know about the crasher
<mterry> mvo, yar no biggie, it was just something infinity and I talked about a few minutes ago.
<mterry> mvo, OK.  stgraber: I've got a branch already to drop auto-tester, if you were looking into that.  Same for release-upgrader
<mterry> mvo, I've got branches for your review, man!
<mterry> They're piling up
<stgraber> mterry: yeah, I've just gone through all the remaining changes in the u-m branch and merge them into auto-upgrade-testing as we certainly don't want to loose these
<mterry> stgraber, ah awesome.  I was under the impression that lp:auto-upgrade-testing was more-up-to-date.  Thanks for the catch
<stgraber> mterry: it partly was, which made the merge "interesting" :)
 * cjwatson whines idly about the practice of splitting things off without finishing the job :)
<infinity> mterry: Alright.  stgraber's merged u-m into a-u-t, and I've merged dropping a-u-t back into our py3 u-m branch, so that should all be tidied now.
<infinity> mterry: What's this about release-upgrader getting the same treatment? :P
<cjwatson> Not finishing the job there is especially irritating since I've been piling up the commits there pretty rapidly.
<cjwatson> I mean, I vaguely knew about the split, but I had to pick one side or the other to commit on ...
<stgraber> yeah, I somehow assumed that it was dropped from u-m when split to auto-upgrade-testing, so commited my own changes to lp:auto-upgrade-testing for the past few weeks (though not in a python3 compatible way, fixing that now... );)
<infinity> stgraber: But I'm correct in assuming that you've merged whatever changed we had in the py3 branch back to lp:auto-upgrade-testing?
<infinity> stgraber: (Well, everything up to the commit where I removed it all)
<stgraber> infinity: yes
<cjwatson> mvo: Does http://paste.ubuntu.com/1035684/ look right?  Fixes tests for quantal per http://www.piware.de/2012/05/pygobject-3-3-1-released/
<mterry> infinity, https://code.launchpad.net/~mterry/update-manager/split-release-upgrader
<mvo> cjwatson: it is, and yet I can't say I'm impressed by this upstream decision, if it should be bound to python object attributes, why is that not done in the python-gi wrapper?
<mvo> cjwatson: so that its not a API change
<mvo> cjwatson: but I guess you are not the right perosn to ask this question :)
<mvo> pitti: ---^ ?
<infinity> mterry: Check, found it.  Do we already have a new project and source package for release-upgrader?
<mterry> infinity, (paired with https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/split)
<mterry> infinity, I was waiting on review before pushing to ubuntu
<ScottK> Daviey: re pyyaml - I gave my thoughts in the mail, but I think it's up to someone @canonical.com to decide if the will take cython in Main.
<mvo> cjwatson: except for this its fine, I think that will break more of my stuff as I use get_data/set_data quite a bit in various of my projects :/
<pitti> mvo: that actually was (and still is) the plan indeed
<pitti> mvo: I wasn't aware that anyone actually uses this
<pitti> it seemed like a very unusual thing to use from Python
<cjwatson> mvo: I agree and I whined in the upstream bug
<cjwatson> mvo: But we might as well avoid it anyway
<mvo> fair enough
<infinity> mterry: Kay.  Well, the whole thing depends on the other branch I just merged out-of-band, so we'll wait until we merge our py3 stuff back into the mainline branch, and them I might look at your release-upgrader split.
 * pitti waves good night
<mterry> infinity, yeah, the release upgrader split is more complicated
<infinity> mterry: Looks like, yeah.
<larsduesing> good night, pitti :-)
<slangasek> mvo: hi, where do we sit now as far as an apt update for quantal?  I understand that aptdaemon's python3 support requires a fix to apt-key; is there anything that should block me from doing an apt upload?
<slangasek> mvo: I know you mentioned a while ago that you had staged the merge, but it still seems not to be uploaded to quantal :)
<maca> Hola
<maca> Me gustarÃ­a colaborar arreglando bugs. No tengo experiencia en programaciÃ³n. Y no sÃ© por donde empezar. Me gustarÃ­a que vosotros me orientaran
<infinity> slangasek: It's possible that the apt merge depends on my dpkg merge.  (I don't know this to be true, but it seems plausible)
<vibhav> maca: Realmente podrÃ­a ayudar si usted puede hablar en InglÃ©s :)
<maca> ok, I thought that channel was Spanish
<maca> Let see
<slangasek> you're in #ubuntu-devel, English is the common language here :)
<slangasek> infinity: you're just fishing for a reason for the dpkg merge to be on topic for the python3 sprint, aren't you ;)
<infinity> slangasek: Maaaaaybe.
<vibhav> Could anybody have a look at https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1011693 ?
<ubottu> Launchpad bug 1011693 in audit (Ubuntu) "Please merge audit 1:1.7.18-1.1 (universe) from Debian sid (main)" [Undecided,New]
<maca> I would like to contribute fixing bugs, but I don't have experiences on programming. And I don't know how to start. So, I wondered if you can give me a way to learn fixing bugs...
<infinity> slangasek: Actually, I was thinking it may depend on dpkg --assert-multi-arch (which it does), but I forgot that our dpkg has that bit.
<slangasek> infinity: right
<infinity> I see no other obvious "new dpkg" dependencies in the new apt, so I withdraw my previous guesses.
<slangasek> mvo: btw, the prepare-release script throws an xmllint usage error in lp:~ubuntu-core-dev/apt/ubuntu/ because there are no translated xml files present, only .po files... am I doing something wrong?
<slangasek> mvo: oh, perhaps the prepare-release hook assumes that I'm not doing a -S build ;)  ok, ignoring
<Daviey> ScottK: Yeah, i spoke before i read -devel.. I haven't responded.. but have been thinking about it.. I can't see that server product requires it.. and without another flavour requiring it; if the delta is cheaper to maintain than cpython (i'm betting it is).. i think diverge
<Daviey> ScottK: what do you think?
<ScottK> The downside is you end up not regenerating the generated sources and you may discover later you need an SRU/security fix and you can't do it.
<ScottK> IIRC it's used in the cloud images, so it's serverish.
<Daviey> ScottK: It's currently blocking (dep-waiting) something else IIRC.. so perhaps we sould diverge until we define if we need it?
<ScottK> By the time we know, it'll be too late if it's after release.
<Daviey> ScottK: Maybe i am being dumb.. but what does it bring to the table?
<ScottK> Which?
<Daviey> ScottK: using cpython with this package
<Daviey> (you know this package far more than i do :)
<ScottK> The file ext/_yaml.c is generated from _yaml.pxd and _yaml.pyx.
<ScottK> Or one of them.
<ScottK> In any case, when you patch one of those files you need to regenerate _yaml.c.
<ScottK> You need cython to to that.
<ScottK> If you don't regenerate it each time you build it, then you really have no idea if you can or not.
<ScottK> So you can end up in a situation where it's very difficult to fix any issues that come up post release (you end up patching generated source).
<Daviey> ScottK: Hmm, i know with eucalyptus there was a tool to generate some of the code.. and that was used outside of packaging..
<Daviey> So really, as a developer.. i can have cpyton on my machine.. regenerate _yaml.c... and upload, with a new patch?
<ScottK> Also if you haven't generated the _yaml.c that you're shipping the in the binary then there's freeness questions related to distributing the preferred form of modification.
<ScottK> If it works with the current cython, yes.
<ScottK> When it's in the package build you find out each time you do an archive rebuild.
<Daviey> I think generating a file on a workstation vs. generating in the archive, using the same tools eradicates the licencing questioning IMO
<ScottK> As long as you can.
<Daviey> (IANAL, etc)
<ScottK> Although I'm an Ubuntu developer, I'm really much more like in the position of a normal Debian developer here.  I don't know how pyyaml gets used in Ubuntu, so it's hard to advise.
<Daviey> ScottK: In any case, i'd be able to do an SRU/Sec upload.. by /somehow/ generating a new file on my workstation, rather than archive.. right?
<ScottK> The technically correct answer is promote cython.  Now someone has to decide.
<ScottK> If it was possible to generate it with the cython version in the archive.  Until you tried, you'd have no idea.
<Daviey> ScottK: and generating it from one outside of the archive?
<ScottK> I guess.
<Daviey> ScottK: I'm really not keen to advocate a MIR that we can avoid, as we have already put too much burden on Security team for the last few cycles as is.
<Daviey> That said, if there is another flavour wanting it.. then i'm all for it.
<slangasek> there was the discussion @ UDS regarding archive reorg where we said that ideally we would stop having to do MIRs for things that are just build-dependencies
<Daviey> The question remains to me, is what is best use of time.. maintaining a delta and the risk of some tomfoolery to do uploads.. or maintaining something i'm not sure we need.
<slangasek> but that requires new tooling as a prereq
<Daviey> slangasek: the moment you said, archive-reorg, that added 2 years to the blueprint... you should have left that string out.
<ScottK> Daviey: If someone else wants to maintain a diff, I don't object, but I think it's not technically the best answer.
<slangasek> um
<jtaylor> somewhat related, is it a good idea to build two packages from the same source? one in main one in universe, context is fftw3 which now adds mpi
<Daviey> jtaylor: good idea?  if you are using the same src upload, you can have some binaries in main, and others in universe.. but the whole build-dep list still needs to be in main... but i guess you knew that.
<Daviey> jtaylor: I think you'll need two src uploads to do what you want.
<jtaylor> thats the issue
<jtaylor> it has a build dep on mpi
<Daviey> slangasek: Do you have thoughts on this pyyaml issue?
<slangasek> jtaylor: we've been stripping mpi support out for years to avoid pulling it into main, fwiw
<slangasek> Daviey: only that I wish archive reorg was farther along so we could sidestep it
<slangasek> I don't think cython should be a major support version in any case
<jtaylor> striping out is one option
<jtaylor> but I'd like to over it
<jtaylor> (providing that mpich2 gets fixed in quantal)
<slangasek> Daviey: so would tend to prefer keeping the cython build-dep in and promoting to main
<slangasek> but that's for the MIR team to decide...
<Daviey> slangasek: right, but the MIR team will surely want an advocating team to take on bug subscriptions..
<Daviey> and i'm trying to work out if my team want to advocate it :)
<slangasek> I don't think that's true
<slangasek> I've had many an MIR approved where I said "we aren't looking at bugs on this, we're in sync with Debian"
<Daviey> slangasek: ok, fair enough.. It seemed to me that having a team care for a package had turned into almost mandated criteria.
<slangasek> well, some team would have to "own" it being in main, but that doesn't actually translate to doing anything with it, in many cases
<slangasek> I suppose you have to decide how you feel cython showing up under the server team's name given that pyyaml is yours, yes :)
<Daviey> slangasek: well this is what i am saying?!
<slangasek> no, you said something about bug subscriptions
<Daviey> own == advocate ..
<slangasek> "own" == "you're the go-to people if there's a problem"
<slangasek> but if you think there'll never be a problem?
<Daviey> Yes.. and this is what i am trying to convey.
<ScottK> jtaylor: Have a look at boost1.49 and boost-mpi-source1.49 to see what fun you can have due to MPI
<jtaylor> ScottK: you mean that as just an example or negative example why not do do it?
<ScottK> It's an example.
<ScottK> You may look and run screaming or decide "meh, I can do that".
<jtaylor> k, I'll probably do that then
<jtaylor> fftw3 is no 46mb source package :)
<jtaylor> though that means that its probably me who has to fix mpich2 ._.
<micahg> jtaylor: libav and libav-extra is another example
<jtaylor> libav has mpi bindings o_O
<Daviey> ScottK, slangasek: I'm going to open a MIR tracking bug, although i'm not strongly advocating it.. but we should have it referenced there.
<Daviey> mdeslaur: I'd like the security teams input on there aswell, to give the MIR team as much info as possible to decide.
<ScottK> Daviey: It would, in theory, be possible to briefly promote cython to Main to get past the depwait and then demote it again.  Then you get past the block and there's no diff.
<mdeslaur> Daviey: sure
<Daviey> ScottK: ooo, good point.. but doing that dance for SRU/Security sounds REALLY nasty :)
<ScottK> Daviey: Agreed. I was just thinking about getting past the current blockage while the MIR is decided.
<Daviey> *sigh*.. MIR team are going to hate me.. I already have 10 pending MIR's
<Daviey> Oh, ffs.. this issue is academic.. it already has an approved MIR .. bug 299870
<ubottu> Launchpad bug 299870 in cython (Ubuntu) "MIR for cython" [Undecided,Fix released] https://launchpad.net/bugs/299870
<Daviey> 2008.. but i assume it still holds true..
<ScottK> If it was in Main before it can be repromoted, no problem.
<Daviey> mterry/doko: you agree
<Daviey> ?
<infinity> I have no issues promoting it if it was in main previously.
 * mterry reads back
 * micahg would think it would depend if the code was totally rewritten or not (possible new security concerns) (has been in universe since at least lucid)
<Daviey> mterry: Approved MIR from 2008, fell out of Main.. happy for it to be repromoted based on that?
<infinity> Looks like it's just incremental versions from way back when.
<mterry> Daviey, yeah sure.  2008 is quite a while ago, so it's possible it could have gotten worse maintained...  but we're in sync with Debian, seems fine
<Daviey> super, thanks
<mterry> No crazy bugs in Debian that I can see
<lifeless> fwiw
<lifeless> bzr uses pyrex/cython
<lifeless> so having cython in main could be quite nice
 * infinity makes it so.
<cousteau> interesting, didn't know
 * cousteau should take Cython again
<micahg> infinity: problem is that cython needs python-support, someone needs to remove that before it can be promoted
<Daviey> infinity: you just promoted ?
 * micahg took a look at it, but got stuck over the weekend
<infinity> micahg: Oh, well.  Pls fix. ;)
<micahg> ScottK: ^^ can you fix?
<xnox> Daviey: what is pyyaml used in again? and didn't like pyyaml was on the way out of server responsibility due to "donât use yaml to marshall data in and out of zookeeper"
<micahg> ScottK: or are you just the pyyaml person?
<xnox> from the juju scaling excercise
<ScottK> micahg: Just the pyyaml person.
<ScottK> I think jtaylor should fix that and push it upstream.
<micahg> sounds good to me :)
<micahg> jtaylor: I have a starter debdiff if you like
 * infinity hovers over the "demote again" button.
 * Nafallo hovers over infinity 
<micahg> infinity: well, if you only promoted cython and not python-support, it's fine, the first person who wants to build it has to fix it :)
<infinity> micahg: s/build/install/
<micahg> infinity: hrm, that too :(, I guess it doesn't work
<infinity> micahg: It's going to pop python-support on component-mismatches, so there'll be plenty of yelling about that. :P
<Daviey> xnox: blame smoser.
 * micahg takes another quick look
<Daviey> xnox: cloud-init is at least one consumer that jumps out at me.
<ScottK> Actually I bet barry might fix cython.
<xnox> Daviey: ok
<smoser> well, clearly anything that fell out of favor in juju should be stricken from the universe.
<micahg> well, one of the issues is that it doesn't seem dh_python2 ready (installs in site-packages still)
 * cousteau doesn't know what Cython is used for, other than Sage, Bazaar, and, well, his own bachelor thesis
<micahg> cousteau: http://paste.ubuntu.com/1035926/
<cousteau> wow...  that kinda sums all up
<micahg> cousteau: reverse-depends src:cython -b (from ubuntu-dev-tools)
<cousteau> anyway, I don't see any project I know about there, other than bzr
<cousteau> (and maybe compizconfig)
<arges> pitti, hello. I have a debian patch for pyppd that fixes a ftbfs build issue with python3. http://people.canonical.com/~arges/plusone/pyppd_python3_build_fix.debdiff  . Let me know if you'd like to see changes or have questions. thanks
<Laney> doko: Would you be overly unhappy if I switched mono to gcc-4.6 to fix the armel ftbfs?
<Laney> "fix"
 * micahg wonders if infinity made any progress on that ^^
<Laney> Also, I want to look at dropping a .la file. Is there any better than manual way of checking rdeps?
<micahg> Laney: lintian lab grep?
<Laney> don't you need binaries?
<slangasek> mterry: ping
 * micahg thought the lintian lab had the binaries as well
<Laney> maybe it does
<Laney> broder: does it? If so, can I have access please? :-)
<infinity> Laney: Does switching to 4.6 magically make it happy?
<slangasek> mterry: xnox has pointed out that libconfig in Ubuntu carries a delta to Debian for a .symbols file, apparently as a result of https://bugs.launchpad.net/ubuntu/+source/libconfig/+bug/730760/comments/2
<ubottu> Launchpad bug 730760 in libconfig (Ubuntu Natty) "[MIR] b-d for libffado" [High,Fix released]
<Laney> infinity: The test build is in progress, so we will see
<Laney> but it has progressed past the previous point of failure
<infinity> Laney: If it does, I'm okay with that as a temporary solution.  It also gives me a bit of a pointer as to where to look later for what's gone wrong.
<slangasek> mterry: can you clarify where this requirement comes from?  I don't find .symbols files mentioned in the MIR wiki pages, and although I'm a staunch advocate of .symbols files as part of responsible library maintenance, I think this is a silly thing for us to carry a delta from Debian over
<Laney> we'll be able to compare the test suite summaries too
<micahg> oh wait, infinity was looking at ghc, not mono :)
<infinity> micahg: I'm looking at neither right now, but both are on my "to be grumpy about" list.
<doko> Laney, what was the context?
<mterry> slangasek, sorry, was afk.  reading
<micahg> infinity: well, the whole haskell stack is not installable at the moment in quantal, is there someone else with a shorter to be grumpy about list that can poke at ghc?
<Laney> doko: That mono fails with 4.7 on armel but looks to be OK using 4.6
<Laney> I thought you might be interested in knowing.
<doko> ugh, and works on armhf?
<infinity> micahg: That's only on armel.
<Laney> builds at least.
<Laney> apparently it is busted in some important ways, but I am not sure that is related to the compiler
<micahg> infinity: yes, but as you'll need a rebuild anyways to fix armel, any rebuilds now is just a waste
<Laney> the new GHC which is going to experimental soon is supposed to work properly on arm
<Laney> I don't know if that extends to the failures we're seeing
<micahg> Laney: is it close enough to just wait?
<infinity> Laney: The failure we're seeing doesn't directly relate to GHC, I suspect.
<Laney> indeed
<mterry> slangasek, I usually block a MIR on either a .symbols file or argument-less -V to dh_makeshlibs.  On the theory that it makes less trouble for main as a whole vs the delta effort (and usually we don't end up carrying such a delta for long -- Debian likes such patches)
<infinity> Laney: I just need a few spare cycles to look at it. :/
<Laney> I was also going to try the 4.6 trick there
<mterry> slangasek, that's standard MIR practice as far as I know.  Though it may not be written in the Requirements bit
<Laney> but the FTBFS looks like something that an ARM-head would be able to make something of
<slangasek> mterry: if it's not written in the requirements, I don't think it's standard ;)  And I don't think this requirement is grounded in Ubuntu best practices...
<slangasek> like I said, .symbols are the right thing to do, but they should be done upstream in Debian
<slangasek> it's not worth a delta over
<infinity> Laney: The FTBFS for ghc in Ubuntu is very much Ubuntu-specific.  I just haven't had time to figure out why.
<Laney> OK
<Laney> we previously had to have it prod different options into llvm
<mterry> slangasek, I didn't make the practice up.  Can't remember who I got it from.  If it's a matter of the Debian maintainer refusing the patch and it being the only delta, I'd tend to agree.  But there's no harm in carrying the delta for a while until Debian does
<slangasek> mterry: I'm confused as to what problems you expect to be solved by .symbols/dh_makeshlibs in practice
<infinity> Laney: Wait, does Debian's ghc package know about Ubuntu?
<infinity> Laney: As in, is it guessing that ubuntu/armel is armv7 and then doing Very Bad Things?  If so, the failure is obvious.
<slangasek> mterry: well, I think whoever you got it from should've been responsible for adding it to the MIR Process wiki pages! :-)
<infinity> Laney: I hadn't looked that far yet, I just scratched my head over the same source working in Debian/armel but not Ubuntu/armel.
<Laney> infinity: nope
<Laney> http://anonscm.debian.org/cgi-bin/darcsweb.cgi?r=pkg-haskell/ghc;a=headblob;f=/rules (what is up with that syntax highlighting?)
<mterry> slangasek, well, you must know some of the problems they solve, since you say they are a good idea, but in my words, it's good for people updating the package to ACK API additions (and more importantly drops!), and it's good for users upgrading packages because having maintainers manually handle the correct versions is prone to failure.  And possibly some other benefits I'm not entirely aware of at an archive-admin level
<infinity> Laney: Where is the "use llvm instead of gcc" decision made?  I don't see that in rules...
<mterry> slangasek, and it's in general a symptom of a well-maintained package, which is always a signal the MIR team likes to see (and if we add it, whether Debian maintainers accept it is a good signal)
<slangasek> mterry: right, presence of symbols --> well-maintained, but the converse does not follow :)  In this case we have a delta only for the .symbols file; and the ABI is being well-maintained upstream (in fact, it's an ABI transition due to a new soname)
<slangasek> mterry: what do you advise in this case?
<mterry> slangasek, (right, but as I said, if Debian accepts our patch in good order, that's a hindsight-verification of good maintainership)   :)   I haven't looked at this specific case yet.  (will do so in a sec)  Have we passed the patch to Debian?
<slangasek> mterry: the patch has been sent to Debian but not integrated
<Laney> infinity: AFAIK LLVM support is built if you have opt/llc when building GHC, and is the default backend on arm
<slangasek> I think we're better off dropping the delta for now, since that makes busywork for us, and taking the discussion about .symbols to Debian
<Laney> so all Joachim did was add it as a build-dep
<infinity> Laney: Ahh, it's just autodetected if it's in the chroot.  I see.
<infinity> Laney: (In that case, you should build-conflict llvm on !arm)
<Laney> Why? We want the LLVM backend to be available there.
<infinity> Laney: While I'm all for hunting this down and fixing it soonish, was there a reason to switch from a compiler that doesn't suck to llvm for only one arch? :P
<Laney> it only changes the default on ARM
<infinity> Laney: Eh?  Only arm build-deps on llvm, that means you want !arm to not have it, or it'll use that by default.
<Laney> on other arches you get an extra backend, selected by -fllvm
<infinity> Oh.  I guess I've not found where that's happening.
<infinity> Laney: Oh, ffs.
<infinity> Laney: I think it's as simple as the package doing detection based on uname.
<infinity> Laney: All our buildds are armv7.  The Debian armel buildds are armv5.
 * infinity head->desks.
<infinity> That should be simple enough to hunt and fix.
<mterry> slangasek, we also tend not to require them for C++ just because that adds to the burden, not diminishes it.  I see this is at least partly C++.  And if we might to waive the requirement for one of the bindings, seems even less reasonable to make the C-bindings do it.  Sure, sync it up.
<infinity> Laney: Or maybe not.  *scratch head*
<infinity> Laney: I dunno, I'll look at it a bit later.
<mterry> slangasek, I'm not convinced it's a bad idea in general though to carry a delta for symbols
<mterry> slangasek, I believe the last time the MIR team talked about it at a UDS, it was considered an appropriate thing to require
<slangasek> mterry: well, it doesn't seem to have ever made it into the documentation and been subjected to wider scrutiny as an enforced requirement... I'd definitely like us to be able to fix that
<slangasek> mterry: who should I pester into leading a public discussion about that?
<Laney> infinity: I'll leave it in your capable hands :P
<slangasek> xnox: ^^ regardless, mterry seems to be saying here that a sync is ok for libconfig
<infinity> Laney: My hands appreciate your vote of confidence.  The rest of me, not so much.
<infinity> slangasek, xnox: synced. ;)
<Daviey> slangasek: it's something we've done numerous times for MIR.
<mterry> slangasek, let me ask the rest of the MIR team to double-confirm that I'm not off the rails here.  :)  If it is an undocumented nigh-requirement, I can email ubuntu-devel and raise your concern that it be vetted
<Daviey> i seem to remember debian always taking it tho
<mterry> Yeah, usually they love it.  Who wouldn't
<mterry> slangasek, I would just add it to the wiki, but you seem like you feel it's an unreasonable ask?
<Daviey> mterry: pls give us a mir-review script :)
<slangasek> Daviey, mterry: I'm perfectly fine with an MIR requirement that we push a patch to Debian for the .symbols... I just don't think we should be carrying a delta for this as an MIR requirement
<slangasek> mterry: yes, I want a public discussion so that I can have it on record why I think this isn't a good thing ;)
<mterry> Daviey, I did just create a wiki page for MIR team members to help unify practices.  It might be useful to know the kind of things we look at: https://wiki.ubuntu.com/MIRTeam
 * Daviey dusts off his soap box and passes it to slangasek 
<slangasek> though we're also rapidly approaching the point of diminishing returns by discussing it ;)
<infinity> doko: Want to reactivate me in ~ubuntu-mir, and I'll totally sort them out. :)
#ubuntu-devel 2012-06-12
<skunk> did you guys see the new Macbook pro??
<ScottK> jtaylor: If you dh_python2 cython, I'll sponsor it.
<pitti> arges: can you please forward that upstream?
<pitti> arges: it built fine with python3 in quantal, do you have the error?
<pitti> arges: I mean what did you do to get that error?
<vibhav> debfx: ping
<pitti> arges: ah, ignore me
<pitti> arges: yes, I'll apply it in Debian, and update my merge proposal for upstream
<vibhav> Why was the version of debhelper in build-depends of libqaculate was lowered in 0.9.7-6ubuntu1 ?
<vibhav> debfx: ^
<micahg> vibhav: did you ask before looking at the merge? (and that doesn't look like the right name)
<micahg> oh, I see the package now
<vibhav> Actualyy I have not started the merge now
<vibhav> But it is likely that we will not drop this change
<vibhav> micahg: For now I am not dropping the change
<micahg> vibhav: yes, but before you start working on a merge, you should ask the person who touched it last if they're working on it or if you can take it so as not to duplicate work
<micahg> and debfx is usually pretty up to date with his merges
<vibhav> I had sent him an email a while ago
 * SpamapS finally comes back to bug 986892 .. weeks later than he'd have liked
<ubottu> Launchpad bug 986892 in apparmor (Ubuntu) "mysql-server postrm breaks apparmor profile for later versions on purge" [Undecided,Triaged] https://launchpad.net/bugs/986892
<infinity> pitti: Heh.  Good morning. :P
<infinity> pitti: (I love watching the "wait, how the, what, oh, you're right, yeah" ping responses first thing in the morning)
<pitti> infinity: I didn't see the pyppd FTBFS mail for some reason, and it builds fine locally
<pitti> so I indeed was a bit confused
<micahg> pitti: you don't get FTBFS mail for Debian syncs ATM
<pitti> oh! that'd explain it
<micahg> pitti: fails in my quantal schroot
<pitti> yes, I can replicate it
<pitti> building with LANG=C
<pitti> open() in text mode defaults to the system encoding when decoding files
<pitti> that's something I still need to get used to in py3
<pitti> already fixed in git
<pitti> upstream answered in the MP with another bug, I'll fix that as well and reupload to Debian/sync
<infinity> I really need to get around to doing the lp-build thing I planned to do that would take a .dsc and jam it through a local "as close to lp-buildd as you can get" environment.
<infinity> So people can stop guessing.
<micahg> pitti: one's +synchronised-packages page is an easy way to watch for those failures (from Debian syncs)
<StevenK> infinity: Including buildd-manager? :-P
<pitti> the thing that's hardest for me to replicate are apport's test failures in the package tests, though
<infinity> StevenK: No. :P
<pitti> i. e. the buildds do have a defaultroute (i. e. pretend to have network), but in a very limited/strange way
<infinity> StevenK: buildd-manager may break all sorts of things, but it doesn't affect builds, thankfully.
<infinity> pitti: They have a network, but are firewalled from hitting anything outside their subnet and, more entertainingly (and this is the one that messes people up), they have DNS, but it only resolves to the local network.
<infinity> pitti: Could easily replicate the entire setup in an lxc container.
<pitti> yeah, I'm trying to think of a way how a test can detect whether it's running in such an environment
<pitti> ATM the tests skip if there is no defaultroute
<infinity> pitti: Just try to resolve some well-known address?
<infinity> pitti: Unless you're writing testcases for a DNS resolver, I guess. :P
<pitti> infinity: so I could check if ddebs.ubuntu.com resolves, instead of checking for a default route
<pitti> or better, in addition to
 * micahg would suggest something that might not go away in the future...
<infinity> pitti: Yeah.  Or keep it intentionally very external (and very unlikely to fail) like, said, www.google.com
<infinity> s/said/say/
<pitti> well, I only actually use archive.u.c. and ddebs.u.c. in the tests
<pitti> so I guess I should test for those
<infinity> I think "www.google.com doesn't resolve, you probably don't have external DNS resolution" is a test trigger that's likely to be five-nines accurate.
<pitti> *nod*, thanks
<vibhav> Could anybody have a look at https://bugs.launchpad.net/ubuntu/+source/libqalculate/+bug/1011937 ?
<ubottu> Launchpad bug 1011937 in libqalculate (Ubuntu) "PLease merge libqalculate 0.9.7-7 from Debian sid" [Undecided,New]
<micahg> vibhav: you should really talk to the kubuntu folk about that merge
<micahg> I see at least 2 things that could be dropped depending on their needs
<infinity> The libqalculate4 replaces is no longer needed.
<micahg> infinity: if they're backporting to precise, it might be good to keep
<micahg> hence why I said "depending on their needs"
<infinity> I suppose there's that possibility, yeah.
<micahg> and SONAME versioned libs really shouldn't be breaking each other, but that's for another time I guess
<SpamapS> hrm
<SpamapS> http://paste.ubuntu.com/1036655/
<SpamapS> mysql-server-5.1 is "replaced" by mysql-server-5.5 ...
<SpamapS> but those 5_1 files are not in mysql-server-5.5 ..
<SpamapS> so how do I kill those and trigger dpkg's "ok its actually been replaced, purge all" ?
<SpamapS> do I stub those into 5.5?
<SpamapS> is this what dpkg-maintscript-helper does? :-/
 * SpamapS is confused and out of time. :-P
<SpamapS> I guess so since really those conffiles have just been renamed
<infinity> SpamapS: Replaces overwrites files, it doesn't replace packages.
<SpamapS> infinity: right, I understand that..
<infinity> SpamapS: If you want to purge the package, purge it. :P
<SpamapS> infinity: but when all the files have been overwritten, the old one is purged
<infinity> There's nothing to "trigger".
<infinity> You have it in a removed state, that's all.
<infinity> Sure, when a package no longer has conffiles, remove==purge.
<SpamapS> infinity: thats what happens to anybody who dist-upgrade's from oneiric/lucid to precise with mysql-server installed.. they have a removed but not purged mysql-server-5.1
<infinity> But, you could also just purge.
<infinity> SpamapS: (This is why I dist-upgrade with --purge...)
<SpamapS> caused only by those files :-P
<SpamapS> ok, so .. just "fahgedaboudit" :)
<SpamapS> I can do that
 * infinity nods.
<SpamapS> this bug is going to be a bear
<SpamapS> have to update debhelper in lucid and oneiric..
<SpamapS> then nochange rebuild update mysql 5.1 in those
<micahg> hrm, doesn't purging mysql have bad side effects?
<SpamapS> micahg: only if you've told it to delete /var/lib/mysql
<SpamapS> which .. is interesting actually
<SpamapS> since we've transferred ownership of that dir
<SpamapS> the postrm should not touch it
<infinity> But it sure will.
 * SpamapS does not want to look at that scenario right now
<infinity> This isn't exactly a new bug, though.
 * SpamapS should get sleep before losing sleep over that
<infinity> It's been like this since the 4.x packaging.
<infinity> And I don't recall any complaints that people upgraded, purged the old, and had an oops.
<infinity> So, they're either smart enough to pick the right Debconf options, or too embarrassed to complain about it when they didn't.
<SpamapS> infinity: seems like it would be easy enough to have each package "claim" the dir on postinst and only purge it if you are the one who claimed it.
<infinity> SpamapS: A bit hard to do retroactively.
<infinity> SpamapS: But perhaps not a terrible idea in the future.
<SpamapS> oh even more fun.. no dh_apparmor in lucid.. so I have to fix it in mysql-dfsg-5.1 directly :p
<infinity> What's the bug?
<infinity> And how was "updating debhelper" a sane solution?
<SpamapS> infinity: dh_apparmor creates a postrm that will remove the "local" files in the event that another package has replaced its conffiles
<SpamapS> bug 986892
<ubottu> Launchpad bug 986892 in mysql-5.1 (Ubuntu Oneiric) "mysql-server postrm breaks apparmor profile for later versions on purge" [Undecided,Triaged] https://launchpad.net/bugs/986892
<SpamapS> infinity: the fix is simple. If the main conffile still exists on purge, that means another package has claimed it.. so leave the files in place.
<SpamapS> this is the bug of a thousand tasks
<infinity> SpamapS: Oh, that's just special.
<SpamapS> I'm pretty sure its got quite a few duplicates actually
<SpamapS> probably from people doing dist-upgrade --purge
 * infinity wonders if any other multi-versions-claiming-apparmor-profiles issues exist.
<infinity> psql, perhaps.
<SpamapS> since the purge method shouldn't be called otherwise
<infinity> SpamapS: Well, you can also manually purge, post-upgrade.  Which I tend to do, both for tidiness and bughunting.
<SpamapS> yeah
<SpamapS> the dupes we're getting are all package install errors from 5.5
<infinity> (After a do-release-upgrade, I'll 'dpkg -l | grep ^rc' and go to town)
<SpamapS> because it fails to start.. because apparmor is all forked up
 * infinity should probably sleep.
<infinity> SpamapS: I take back my knee-jerk "fixing debhelper isn't sane" reaction.  That's a pretty icky bug.
<infinity> SpamapS: Hopefully, the exposure is low (as in, hopefully, packages taking over each others' apparmor profiles is a rarity)
<SpamapS> infinity: I believe it is a rarity
<SpamapS> infinity: but worth fixing nonetheless
<SpamapS> in an SRU I mean
<infinity> The DHCP rename could have had the same effect.
<micahg> SpamapS: sbeattie is doing an apparmor SRU, you should talk to him
<SpamapS> micahg: will do
 * micahg taps his foot waiting for the launchpad diff
<SpamapS> I think actually I don't need to SRU apparmor
<SpamapS> dh_apparmor was only moved into apparmor in precise
<infinity> SpamapS: Could be more, but off the to of my head, I'd suggest having a quick look at versioned psql packages, and dhcp3*->isc-dhcp*
<micahg> umm, aren't we talking about precise?
<SpamapS> micahg: yes but the problem lies in mysql 5.1 .. from << precise
<infinity> SpamapS: The problem's also in 5.5 in precise.
<infinity> SpamapS: At least, it will be there, once there's a >> 5.5 in a later release. :P
<SpamapS> its there.. true we will need that whenever 5.6 arrives, which should definitely be before 14.04 :)
<infinity> So, fix it in precise now, before you forget about it. ;)
<micahg> SpamapS: I assume you used the VCS for apparmor?
<SpamapS> micahg: I did tho I refrained from pushing since all the other commits were done by the package importer ;)
<SpamapS> have not touched precise's apparmor hyyet
<micahg> SpamapS: umm, what does Vcs-Bzr show for you on apparmor?
<SpamapS> wait
<SpamapS> its not ubuntu:apparmor ?
<SpamapS> WTF
<micahg> UDD is not everything
<SpamapS> fail
<SpamapS> I never check Vcs-*
<SpamapS> thery're wrong 99% of the time
<micahg> SpamapS: that's a big fail, especially for stuff in main
<pitti> 99% must be a gross overstatement
<pitti> all ubuntu-desktop Vcs-Bzr: are right
<infinity> They're generally correct in main.
<pitti> well, most of the time
<micahg> as should be the Mozilla stuff
<SpamapS> when's the last time I touched ubuntu desktop ?
<infinity> Generally.
<SpamapS> :P
<pitti> Debian's Vcs-Git: are not correct for Ubuntu, of course
<pitti> but Vcs-Bzr: on LP is almost always correct
<SpamapS> we basically do not use them in server stuff at all
<micahg> pitti: well, except for the stuff in ubuntu maintained in Debian :)
<SpamapS> but the big fail there..
<pitti> micahg: yeah, I wish we had a standard flag that says "don't change this in Ubuntu, talk to $NAME instead"
<SpamapS> is that you can *change* the official lp:ubuntu/... to point at it
<SpamapS> Why aren't people using lp:ubuntu/* ?
<micahg> pitti:  if $VCS ~ /ubuntu/ then edit here :)
<SpamapS> this is just maddening
<pitti> SpamapS: fully agree on the maddening part
 * SpamapS isn't sure whether to feel annoyed or guitly
<pitti> there is no one true way
<SpamapS> but I ask, *why*
<SpamapS> I suspect mistrust of the package importer
<infinity> It's not hard to mistrust it.
<infinity> It's not done much to earn mine.
<SpamapS> it has ruined my branches enough times that I am a-feared of it
<pitti> UDD is making things ridiculously complicated and error prone, and a lot of branches are out of date
<SpamapS> I've struggled pretty hard to keep branches up to date for the server stuff
<pitti> which is why so many people rather use the good old debian/ only custom branches with e. g. bzr-builddeb
<SpamapS> meh ok
<infinity> pitti: Say, did you have any plans to fix the .symbols files for cups on arm*?
<infinity> pitti: It's been FTBFS for weeks.
<pitti> infinity: apw looked at it last week, but I guess he stopped in the middle or so
 * pitti really tries to detach himself from the printing stuff, but that is very sticky
<pitti> currently fixing pyppd..
<pitti> infinity: it's also completely mysterious to me; but I guess I'll just add this new weird symbol as optional and stop worrying about it
<infinity> pitti: Welcome to C++ symbols?
<pitti> infinity: it's not just that; it built fine on Debian's arm
<infinity> pitti: 4.7
<infinity> pitti: Was Debian's still 4.6?  Same version of QT?
<pitti> so 4.7 on arm on Ubuntu is special somehow
<pitti> infinity: haven't checked that; sid has been on 4.7 for quite some time, though; Qt might have been different
<infinity> pitti: I see gcc/g++ 4.6 in the build logs for your cups uploads in sid.
<SpamapS> infinity: good news, it appears MySQL 5.5.25 works fine with gcc 4.7
<SpamapS> infinity: so I think we can drop the build-dep on 4.5 this week
<infinity> pitti: Unless sbuild is lying, which it might be.
<infinity> SpamapS: \o/
<infinity> SpamapS: We dropped the 4.5 build-dep for u-boot too.
<infinity> SpamapS: Shame we couldn't do it in precise, but oh well.
<SpamapS> stubborn people unwilling to fix their code will probably thank us for that
<micahg> pitti: gcc on arm in Debian is 4.6 still
<pitti> micahg: ah, how helpfully inconsistent; optional symbols it is then :)
<micahg> pitti: well, I think doko pushed the envelope as far as he could with the freeze looming :)
<SpamapS> hm ok well digging through apt-file searches, I think mysql is the only versioned package that owns an apparmor profile
<dholbach> good morning
<apw> pitti, ahh yess i have that cups fix in a branch, i came to pass it to you and you were offline (gasp) and i forgot about it!
<apw> pitti, this branch is the cups fix i was proposing, dispite the base that launchpad _thinks_ its against it i actually based on yur bzr.debian.org branch: https://code.launchpad.net/~apw/debian/sid/cups/trunk-fix-armel-ftbs
<pitti> apw: ah, thanks!
<apw> pitti, i hope that was evidence of you having a vacation :)
<pitti> apw: yeah, I took Thu/Fri off, and for four days I rather disconnected IRC
<apw> pitti, that is probabally the first time i have seen you offline in 4 years, about time
<pitti> heh
<pitti> apw: I did disconnect myself over summer and christmas holidays
<apw> pitti, well all grow up eventually :)
<apw> pitti, if you have comments etc just yell and i can change and retest
<skunk> hi all. Question: Will 12.04 improve on performance?
<skunk> you know as updates come in over the months?
<apw> skunk, that is a really hard question to answer, cirtainly for me it is not slower than what we had before
<skunk> apw: i wish I could say the same thing, 10.04 was alot faster in boot then 12.04
<skunk> I know i am comparing an old os to a new though
<apw> skunk, there may have been some regression there, more likely any regression of that nature will get fixed in later releases, but if its a lot it may be worth investigating, bootchart is a tool to profile boots which if you have the old and new to compare may help understand whether its something easily fixable
<pitti> apw: thank you! merged with dropping the -1 suffixes from the .symbol
<skunk> okay apw. one last question. I might sound like a noob.. but i really want some clarification
<skunk> if we optimized ubuntu to work really fast on HDD, would it automatically make thing faster if runnign on SSDs??
<skunk> make it faster***
<apw> skunk, not necessarily.  ureadahead for instance detects which you have and changes behaviour based on the disk type, because each has different optimal access patterns
<skunk> and of course readahead can be used on both SSDs and HDDS
<skunk> eh?
<apw> yes readahead is used on both types, how it does its readahead is modified
<skunk> okay makes sense.. sorry for my typos btw. its the middle of the night here in Canada
<skunk> apw, this might be a stupid question
<skunk> How do u set up readahead? Ive been using linux for years and I always read about it here and there..
<apw> it is setup by default on ubuntu
<skunk> oh so theres nothing I could do right now?? Readahead is running??
<apw> skunk, should be indeed
<skunk> apw, thanks.
<vibhav> mterry: ping
<dholbach> ajmitch, happy birthday! :)
<ajmitch> heh, thanks
<mvo> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mvo
 * dholbach hugs mvo
<vibhav> yay!
<vibhav> dholbach: Done: https://bugs.launchpad.net/ubuntu/+source/predict/+bug/1012006
<ubottu> Launchpad bug 1012006 in predict (Ubuntu) "Please merge predict 2.2.3-3.1 from Debian Sid" [Undecided,New]
<iulian> dholbach: Where did you know that from? You're not spying on him, are you? :)
<iulian> ajmitch: Happy birthday! Having a party? Free food, free booze? Can I join?
<dholbach> iulian, facebook :)
<iulian> Ah, that does make sense now. :)
<dholbach> vibhav, I'm a bit busy with some other things right now - can you subscribe ubuntu-sponsors?
<vibhav> mvo: Are you busy?
<mvo> vibhav: medium busy :) what can I do for you?
<xnox> mvo: pushed lp:~dmitrij.ledkov/apt-btrfs-snapshot/py3 addressing your merge review comments
<mvo> xnox: very nice, thanks
<xnox> mvo: it now works with python-mock 0.7 ;-) checked in precise pbuilder
<mvo> xnox: very nice, looks great, merged
<xnox> mvo: \0/
<xnox> =)
<xnox> mvo: do a release / upload to quantal?
<mvo> xnox: yes, I can do that now
<xnox> mvo: \\0//^2
<mvo> :)
<nigelb> soren: Happy Birthday! \o/
<soren> nigelb: Thanks :)
<xnox> mvo: it FTBFS... *sigh*
<mvo> :(
<cjwatson> mvo: Your update-manager r2457 only seems to solve the problem in one site out of several affected - what do you think of http://paste.ubuntu.com/1036971/ ?  Works at least back to python-apt 0.7.93.1, which is already within our dependency range
<mvo> cjwatson: looks good but I think we should add super() in the DistUpgradeView*.py stuff as well
<mvo> cjwatson: you are right, my fix only touched update-manager itself
<mvo> cjwatson: otherwise it looks good
<nigelb> Daviey: around?
 * mvo is away for some minutes to get lunch
 * nigelb leaves a message for Daviey in PM.
<cjwatson> Oh, I see that OpProgress uses the percent=None pattern, so I should follow that I guess
<cjwatson> Seemed kind of an odd approach to me but whatever
<Daviey> nigelb: o/
<nigelb> Daviey: left you a PM!
<cjwatson> mvo: So maybe http://paste.ubuntu.com/1036990/ ?
<cjwatson> mvo: Er, sorry, http://paste.ubuntu.com/1036991/
<dholbach> soren, happy birthday! :)
<xnox> mvo: pushed a branch to fix FTBFS
<soren> dholbach: Thanks! :)
<mvo> cjwatson: thanks, that looks great
<mvo> xnox: ta, let me merge
<cjwatson> mvo: ta, committed in r2460
<vibhav> mvo: Sorry for being AFK, If you are not busy, could you please have a look at https://bugs.launchpad.net/bugs/1012006 ?
<ubottu> Launchpad bug 1012006 in predict (Ubuntu) "Please merge predict 2.2.3-3.1 from Debian Sid" [Undecided,New]
<vibhav> "The fact that it's actually pretty social, and I get to call people names, is just a bonus." -- Linus Torvalds
<vibhav> whoa, wrong channel :(
<Riddell> vibhav: voila (on qalculate), thanks for helping ubuntu
<vibhav> Riddell: You uploaded it?
<Riddell> vibhav: yes
<vibhav> thanks man
<vibhav> Riddell: You dropped the Breaks/Replace and the debhelper version diff?
<Riddell> vibhav: yep
<vibhav> So, the only changes were in the debian/rules right?
<Riddell> vibhav: yep
<vibhav> cool
 * vibhav hugs Riddell 
<Riddell> mmm
<mvo> vibhav: sure, I check it out
<vibhav> thanks!
<dholbach> can an archive admin review ubuntu-packaging-guide and pkgme please (new)? :)
<vibhav> dholbach: You are an archive admin, right?
<dholbach> no
<vibhav> I thought you were one
<dholbach> no, I don't have that particular set of keys :)
 * vibhav hugs mvo
<vibhav> cjwatson: You were the last guy to touch libept in Ubuntu, Could I preapre a merge for it or do you want to do it?
<doko> Sweetshark, for issue 1007616, did you try to build on amd64 as well?
<cjwatson> vibhav: I would prefer to leave it to mvo or to whoever's dealing with the apt merge.
<vibhav> apt merge?
<cjwatson> Yes.
<vibhav> What is that?
<cjwatson> The merge of apt.
<vibhav> ah, got it
<xnox> apt the next generation DVCS
<cjwatson> apt tends to change its ABI on significant version changes and require packages to be rebuilt against it; libept is one of those packages, so might as well do that at the same time.
<vibhav> fine, Ill see for another package
<cjwatson> The Ubuntu delta to libept can be discarded rather than merged when the time comes.
<vibhav> cjwatson: What about libedit?
<cjwatson> vibhav: I would prefer that you didn't take any of my merges.
<cjwatson> I'm able to cope with them.
<vibhav> fine
<cjwatson> Thanks all the same
<cjwatson> (Synced libedit now.)
<xnox> jdstrand: what apport version will be released with quantal?
<xnox> i have made a python2/3 bilingual merge proposal to lp:apparmor
<pitti> xnox: I really don't know yet
<xnox> but I now noticed the the /2.8 and /2.7 branches, with quantal having 2.7
<pitti> apport versioning is pretty much up to my mood
<pitti> oh, ITYM apport -> apparmor?
<xnox> yes
<xnox> above lines should be apparmor =)
<ogra_> what ? they arent the same ?
<xnox> pitti: sorry for confusion
<ogra_> :P
<pitti> xnox: np :)
<xnox> jdstrand: what *apparmor* version will be released with quantal? =)
<ogra_> both are for iOS, right ? since they start with the name "app"
<ogra_> :P
<xnox> ogra_: now you are confusing apparmor with iArmor and iApport
<pitti> nah, can't; apport actually tells you what's going on :)
<ogra_> oh, indeed :)
<vibhav> infinity: You there?
<ScottK> I think infinity is getting his beauty sleep.
<vibhav> When one becomes a Contributing Developer, he becomes an Ubuntu Member too, right?
<Laney> that is, in fact, the point of contributing developer
<xnox> vibhav: yes.
<SpamapS> infinity: spoke too soon.. still segfaulting on i386 w/ gcc 4.7 :(
<Sweetshark> doko: yes, but that buildd failed due to running out of fs space IIRC, so I canceled it ...
<nemo> Hey, how would I find out if Ubuntu has picked up https://bugzilla.gnome.org/show_bug.cgi?id=673749 ?
<ubottu> Gnome bug 673749 in GtkStatusIcon "Error Message When Creating Tray Icon" [Normal,Resolved: fixed]
<nemo> 'cause those notification daemon crashes in 12.04 are driving us all nuts
<nemo> I've been googling launchpad, but not found anything yet
<Sweetshark> hmm, anyone recently tweaked around libmysqlclient-dev? it seemed to have installed just fine on i386, but failed to install on amd64 with "libmysqlclient-dev : Depends: libmysqlclient18 (= 5.5.25-0ubuntu1) but it is not going to be installed" ?
<jibel> doko, I did too. It builds on amd64.
<jibel> then make check failed with a java segfaults and a DisposedException but that's another story
<Sweetshark> hohum, mysql 5.5-0ubuntu1 is just 6 hours old ...
<cjwatson> It failed to build on i386.
<cjwatson> That'll have meant that any Architecture: all packages are out of sync.
<cjwatson> Hopefully SpamapS will have notice; he got mailed.
<cjwatson> *noticed
<doko> jibel, that is LO?
<jibel> doko, yes
<SpamapS> indeed I think we'll have to continue to build it w/ gcc 4.5 until it can be figured out
<Laney> he just said a few lines above :-)
<cjwatson> Yeah, I didn't have context for what was segfaulting
<SpamapS> indeed I got the build failure and I believe its an old upstream bug unfortunately
<SpamapS> Not one we can keep dodging .. I wonder if we can patch this
<SpamapS> upstream seems pretty uninterested in addressing it :-/
<SpamapS> http://bugs.mysql.com/bug.php?id=61509
<SpamapS> Thats the issue btw.. upstream seems to think it was resolved but I think not. :-/
<SpamapS> hm, no, its this issue http://bugs.mysql.com/bug.php?id=65432
 * ScottK glares at SpamapS.
<ScottK> (mysql just caused my soprano upload to FTBFS on !i386)
<SpamapS> ScottK: working on it
<SpamapS> looks pretty nasty
<ScottK> Thanks.
<SpamapS> I may have to disable some tests just to get the archive back in order
<ScottK> That would certainly solve my problem.  The soprano build doesn't actually use mysql, I just need it installable so  librdf0-dev is installable.
<SpamapS> yeah libmysqlclient-dev is currently the wrong version because i386 failed
<SpamapS> I think I'll disable those tests.. I have Norvald Ryeng from Oracle helping me with the upstream issue.. but thats not going to be solved in a short time period
 * SpamapS opens critical bug first
<SpamapS> ScottK: test rebuild has commenced, time for breakfast. ;)
<ScottK> Excellent.
<xnox> mvo: did you have a chance to look at https://code.launchpad.net/~ev/apt-clone/python3/+merge/109672 ?
<slangasek> mvo: hi, which "our own code" do you think might still need porting to the python-apt 0.8 api?
<mvo> slangasek: some bits and piece in the quirks code of the release upgrader code I could imagine, I think we are well covered by now but double checking is a good idea
<cjwatson> I'm fairly sure I've got most of it
<cjwatson> I went over the output of /usr/share/python-apt/migrate-0.8.py with a fine tooth-comb
<cjwatson> (Wait, that must be "fine-tooth comb".  Doesn't make a lot of sense hyphenated the other way.)
<mvo> xnox: not yet, can have a look now
<mvo> cjwatson: aha, excellent!
<cjwatson> mvo: update-manager itself is runnable with python3 now, although the upgrader will need some more work
<mvo> cjwatson: yeah, I managed to get the text frontend of the release upgrade to a certain point, but there were some oddities around some of the input handling and I did not looked further
<cjwatson> Input handling?
<cjwatson> mvo: I'm about to rearrange the gettext stuff in an attempt to make it not nightmarish to port to py3 :)
<slangasek> tooth combing is a lost art
<slangasek> mvo, cjwatson: cool, sounds like I can just pull the Debian python-apt in then
<ogra_> bryceh, hey, so during our foundationd py3 porting sprint i ported xdiagnose, i can fire it up from a terminal and get a nice gtk window, is there anything else i could test to make sure the py3 porting didnt break it ?
<ogra_> *foundations
<barry> pitti: hi.  did i see that you completed the port of foomatic-db-compressed-ppds?  has it been uploaded?  (i want to turn that row of the spreadsheet green)
<roaksoax> does anyone have any experience packaging javascript?
<xnox> roaksoax: there is js policy, generally the package should be names libjs-yetanotherjquery and ship stuff in the /usr/share/libjs/yetanotherjquery
<xnox> or something like that
<xnox> roaksoax: look at the, e.g. jquery-* packages? =)
<roaksoax> xnox: yeah I already saw that, though I have a depereusttons when it comes tto versioning
<xnox> roaksoax: 1-1, is always good =)
<xnox> roaksoax: next upload into debian 2-1
<roaksoax> xnox: lol... didn't mean that
<xnox> works like a charm ;)
<xnox> roaksoax: my dictionary didn't parse depereusttons by the way
<roaksoax> xnox: I mean as in "XYZ needs to access the patch in a way like js/js-version/build/"
<roaksoax> xnox: however it installs as in: "js/*.js"
 * xnox hides
<roaksoax> s/patch/path
<roaksoax> xnox: hehe :)
<infinity> SpamapS: So, MySQL?
<slangasek> crunchy and good with drop tables
<infinity> SpamapS: I figured you'd have uploaded a quick compiler revert by now or something. :P
<ScottK> infinity: About an hour ago: [10:27:04] <SpamapS> ScottK: test rebuild has commenced, time for breakfast. ;)
<infinity> Bah.  People and their breakfast.
<micahg> SpamapS: how about gcc-4.6 for mysql?  gcc-4.5 was about to drop out of main and I was going to get rid of it (obviously if 4.6 doesn't work, that's fine too)
<bryceh> ogra_, sweet.  if the gui comes up that covers a lot of the code.  one other thing to test would be the test suite - ./run-tests.  That'll verify the apport hooks generate bug reports and so on.
<SpamapS> micahg: I'll try that if Oracle can't figure it out, but they've agreed to look at it now that we can reproduce
<SpamapS> re-running the test suite *again* ugh
<doko> chrisccoulson, replied to the c++ compat issues. can nux/unity built in c++98 mode?
<chrisccoulson> doko, thanks
<doko> SpamapS, I think it did fail with 4.6 as well
<chrisccoulson> doko, unity / nux isn't really my call, but i think they're already using C++11 features
<doko> chrisccoulson, this will be a pain in the ass to fix for all packages :-/
<SpamapS> It appears to be something with the hand-optimized yassl code
<chrisccoulson> yeah, i can imagine
<SpamapS> I wonder if we can just switch i386 to use the "portable" version and let gcc optimize it
<doko> yeah, that would be nice
<cjwatson> pitti: Do you know the status of ubuntu-drivers-common for Python 3?  It seems to be kind of halfway there
<doko> SpamapS, http://pkgs.fedoraproject.org/gitweb/?p=mysql.git "Fix several strcpy calls to check destination size" sounds suspicious, however I don't know which of these patches are in Debian or upstream
<vibhav> mterry: ping
<mterry> vibhav, hi
<SpamapS> doko: fedora doesn't use the bundled SSL of MySQL IIRC.. they link to openssl.. so theyw on't be affected by this
<doko> SpamapS, and why don't we do this?
<doko> Sweetshark, I see you build LO in c++11 mode as well. Don't do that ...
<SpamapS> doko: I've not looked at it very closely. In the past it caused issues with the test suite.
<vibhav> mterry: AFAIK, you were the last guy to touch bcov in Ubuntu. Since Debian has released a new version, Are you comfortable with me preparing a merge?
<vibhav> Or Do you want to do it?
<SpamapS> doko: If we can't resolve this issue it might be an option, but not one I want to choose lightly.
<mterry> vibhav, I wasn't planning on getting to it soon, so if you're game, that'd be swelL!
<vibhav> sure, thanks
<seb128> hum, my system is using 3G of memory according to top but I closed almost everything running and top sorting show no big users
<seb128> does anyone know how to figure what's going on?
<seb128> that seems to happen regularly after I build gtk or glib on my precise system, the box gets really slow at everything it's doing as well
<seb128> I'm wondering if that's a kernel issue but I'm unsure what infos would be useful
<vibhav> seb128: Have you checked the processes via the system monitor?
<seb128> vibhav, it's not different from top
<vibhav> ah
<vibhav> what kernel?
<vibhav> the one in the repos or a custom compiled
<seb128> vibhav, stock precise from the archive with SRus applied
<vibhav> do you have an old kernel installed, try that too
<vibhav> mterry: Done: https://bugs.launchpad.net/ubuntu/+source/bcov/+bug/1012238
<ubottu> Launchpad bug 1012238 in bcov (Ubuntu) "Please merge bcov (0.2-1.2) from Debian Unstable" [Undecided,New]
<hippiehacker> cjwatson: are you around? I'm looking for some clarification around the 12.04 image build process, https://answers.launchpad.net/ubuntu/+source/live-build/+question/200206
<ogra_> bryceh, ah, awesome, thanks, seems i still have some more work to do :)
 * ogra_ got two tracebacks during the tests
<bryceh> ogra_, I'm happy to lend a hand if needed
<ogra_> ah, i'll get along i think, but a review in the end would be nice indeed :)
<bryceh> ogra_, ok great
<Sweetshark> doko: could you elaborate? I guess upstream wants to go to c++11 ASAP anyway ...
<cjwatson> hippiehacker: answered briefly; I'm in a sprint until Wednesday so not a lot of time
<hippiehacker> cjwatson: thanks again
<SpamapS> ugh.. disable the tests that fail one time.. and a few intermittent failures start showing up
<doko> chrisccoulson, cnd: woult it be possible to construct a test case for the std:list issue, like the one from the referenced GCC report?
<cnd> doko, what do you mean?
<SpamapS> ugh I'm trying like 6 different things to fix this silly i386 issue
<SpamapS> patching out the Pentium Optimizations.. building with gcc 4.6 ..
<SpamapS> building with 4.5 ..
<infinity> SpamapS: Building with 4.5 doesn't "fix" it? :/
<SpamapS> infinity: takes an hour to figure that out even on good hardware :-P
<SpamapS> and I'm out of good CPU's .. now u sing EC2 instances ;)
<infinity> SpamapS: Wait, we're using a bundled openssl?
<SpamapS> no
<SpamapS> bundled yassl
<SpamapS> which is what almost all mysql users use
<infinity> Well, a bundled something SSL. :P
<SpamapS> yeah
<SpamapS> I will also try an openssl linked build
<SpamapS> but I hate diverging from upstream :P
<infinity> I'm fond of the archive being installable. ;)
<ogra_> boring :P
<SpamapS> ok, gcc 4.6 still shows the problem
<SpamapS> so does patching out the hand optimized taocrypt stuff
 * SpamapS gets his gdb on
<jtaylor> why does a foreign glib-dev pull in a foreign python?
<jtaylor> via recommends, kind of dangerous as it conflicts with native python and breaks your system when not aborted
<SpamapS> damn, gcc 4.5 does fix it :-/
<slangasek> jtaylor: why don't you have Install-Recommends disabled in your development environment? :)
<jtaylor> well I'm familiar with the issue, but many others aren't
<jtaylor> unfortunately glib is at the bottom of many dependency chains
<jtaylor> bug 1012229 for a recent example, if seen others stumbling over that too
<ubottu> Launchpad bug 1012229 in Ubuntu "installing 32bit dev packages on 64bit OS frequently fails" [Undecided,New] https://launchpad.net/bugs/1012229
<slangasek> right, well, I don't see at a glance what's pulling in python... but the right answer isn't to remove valid Recommends
<jtaylor> apt-cache depends glib2.0-dev | grep python
<jtaylor> oh you meant what in glib needs it
<jtaylor> would it make sense to make python m-a foreign?
<cjwatson> It's the canonical case where that's difficult.
<slangasek> absolutely not
<cjwatson> Quite literally - it's in the spec.
<cjwatson> Hey, we can start deploying M-A: allowed in Depends now though, can't we?
<cjwatson> Modulo stuff like germinate maybe.
<cjwatson> :any, I mean.
<cjwatson> (For those unfamiliar: we couldn't use the full syntax in precise, because it would have broken upgrades from lucid.)
<slangasek> ooh yes
<cjwatson> Patch to germinate welcome ;-)
<cjwatson> At least to make it ignore it and follow down the same arch.  Bonus points if you can figure out how to make it work with lucid's python-apt for Launchpad, which is what I got stuck on last time I tried.
<cjwatson> Although maybe that doesn't matter too much./
<infinity> SpamapS: If gcc-4.5 "fixes" it, can we get that uploaded ASAP?
<SpamapS> infinity: yes I'm just verifying that it doesn't break anything else
<infinity> It can't possibly make things worse than they are now. ;)
<SpamapS> build shoudl be done in 15m
<SpamapS> infinity: btw, the reason we don't link mysqld to openssl is that Debian believes it is not allowed.
<SpamapS> I don't know why fedora/rh think it is.
<micahg> did they get permission?
<infinity> SpamapS: I thought MySQL has an openssl exception in the license...
 * infinity might be misremembering.
<xnox> infinity: community edition or the proprietary one....?
<infinity> xnox: Community.
<SpamapS> IIRC the problem isn't mysql not wanting openssl, but openssl not granting MySQL an exception
<infinity> We used to maintain a libmysqlclient fork specifically for this reason, I thought.  So one could link OpenSSL and one not, for GPL applications that needed libmysqlclient but couldn't link openssl.  But.  I'm getting old.  I could actually be entirely forgetting why we did all that.
<infinity> SpamapS: openssl doesn't have to grant exceptions, only the other way.
<infinity> SpamapS: It's the openssl license that violates the GPL without a linking exception.
<infinity> But, maybe someone decided it was all just not worth the hassle.
<infinity> And using another SSL implementation doesn't bug me all that much, it's just irksome that it's embedded.
<micahg> http://dev.mysql.com/doc/refman/5.5/en/secure-using-ssl.html seems to imply that mysql wants to allow linking against openssl
<SpamapS> Yeah, I was given the impression that openssl's license made that a no-no
<infinity> micahg: It could just be that the Debian MySQL maintainers gave up with the transitive issue (GPL applications linking libmysqlclient, linking openssl)
<SpamapS> but mysql's exception does allow linking with openssl
<SpamapS> http://bugs.mysql.com/bug.php?id=8249
<SpamapS> infinity: RIGHT that is likely it.
<SpamapS> double ugh
<infinity> SpamapS: I do so love when people link bugs with my name in the log.  It's nostalgic.
<SpamapS> ok so there is a giant mass of inline assembly in yaSSL that gcc 4.6 and later seem to not like
<micahg> wait, so based on that bug, why doesn't Debian just use openssl?
<SpamapS> micahg: transitive?
<micahg> hrm, I guess I"ll have to read the 8 year old thread about it
<infinity> micahg: MySQL allowing an exception to link is fine, right up until you link another GPL application to libmysqlclient, then that application ALSO needs an exception.
<micahg> ah, right
<infinity> Which, actually, isn't that bug at all.
 * SpamapS tries building with TAOCRYPT_DISABLE_X86ASM defined
<infinity> The bug SpamapS was referencing was when they changed the library from LGPL to GPL, thus cutting off non-GPL applications from linking, and they had to give an exception for that.
<infinity> (Which made no sense, IMO, given that the end result of the GPL+linking exception more or less turned it into the LPGL, in practice)
<infinity> But whatever.
<infinity> Licenses are hard.
<mdeslaur> we should just stop upgrading gcc, life would be so much simpler :)
<infinity> SpamapS: Upload something using gcc-4.5, then keep hunting the problem? :P
<infinity> Or I can...
<infinity> But since you tested... And presumably have sources.
<SpamapS> infinity: I'm waiting for my 4.5 test build to finish, not waiting on my other solutions
<infinity> Ahh.  I thought you implied up there that it worked.
<SpamapS> The tests that failed before did not this time
<SpamapS> but they are run with several different arguments..
<SpamapS> and I want to make sure nothing else broke so I can upload and then go take a nap ;)
<SpamapS> ok tests passed
 * SpamapS prepares to upload
<SpamapS> ok, uploaded
 * infinity scores up mysql-5.5...
<davidcalle> ev, hi, I see you are taking care of the videos lens py3 port, I was waiting for libdee to be fixed on py3 to do it. Thanks ! :)
<utlemming> packaging question: if a package needs relies on a kernel module being loaded on boot, is the proper way to put the module in /etc/modules?
<BenC> utlemming: Check qemu-kvm package for how to makes sure to load the correct kvm module
<utlemming> BenC: thank you kindly :)
<BenC> utlemming: You should not touch /etc/modules for sure (packages can't modify conffiles of another package)
<BenC> utlemming: No problemâ¦hint, qemu-kvm uses an init script, so it loads the modules at boot
<utlemming> that's what I figured....I'm pulling the code now
<SpamapS> infinity: TAOCRYPT_DISABLE_X86ASM seems to solve the problem with gcc 4.7
<infinity> SpamapS: At a pretty unfortunate performance loss, I'd assume.
<hallyn> hi - any chance i coudl get someone to take a peek at bug 1010069 ?
<ubottu> Launchpad bug 1010069 in eglibc (Ubuntu) "bits/fcntl.h does not define AT_EMPTY_PATH" [Medium,Triaged] https://launchpad.net/bugs/1010069
<infinity> If only we had an asm-tuned SSL library that we knew worked...
<SpamapS> infinity: yeah, I reckon 2x actually.. doing some further tests now :-/
<infinity> hallyn: *raise brow*
<infinity> hallyn: That would be broken on precise too, then.  Unless kvm didn't need those defines in precise?
<hallyn> it is
<hallyn> in precise we worked aroudn it by manually defining it
<SpamapS> Ugh, try 4x slower.. :(
<hallyn> i'd like to stop doing that :)
<infinity> hallyn: If we knew about it in precise, why didn't someone tell me then? :P
<infinity> hallyn: Anyhow, will look into it.
<hallyn> infinity: I didn't understand the cause of th eproblem then
<infinity> SpamapS: Not shocking.
<SpamapS> so has some kind of convention changed in 4.6/4.7 that requires asm writers to adapt?
<hallyn> infinity: I did raise it a few times, think I brought it up in ubuntu-kernel, and there was another bug oepned
<infinity> SpamapS: I'd say not that I know of, but I guess obviously yes. :P
<infinity> SpamapS: (Or, rather, something got more strict, and bad inline breaks, I assume)
<infinity> hallyn: Alright.  Well, thanks for hunting it down.  I'll probably add this to my pending SRU as well as fixing it in Q.
<hallyn> infinity: thanks!
<ScottK> barry: Any chance you'd have time to convert cython from python-support to dh_python2?  Cython's in Main now, so it needs doing.
<barry> ScottK: possibly, but not today.  can you open a bug on it and assign it to me.
<ScottK> Will do.   Thanks.
<barry> ScottK: np
<ScottK> Done.
<tkamppeter> Anyone expert about apt-get and package repositories? In bug 995111, comment #18, why does cups 1.5.3-0ubuntu2~ppa3 not get installed? What does the user have to do here?
<ubottu> Launchpad bug 995111 in cups (Ubuntu Precise) "Print failure since upgrade to 12.04" [High,Fix released] https://launchpad.net/bugs/995111
<slangasek> tkamppeter: that looks like they have apt pinning in place on their system (/etc/apt/preferences) which forces the ppa version to not be considered a candidate
<tkamppeter> slangasek, thanks, can you comment on the bug telling the user how to proceed? Thanks.
<BenC> Anyone know if python-support is planned for main inclusion?
<BenC> Seeing as cython depends on it
<micahg> BenC: barry has a bug for it, it's not meant to be in main
<doko> BenC, no, please use dh_python2
<micahg> BenC: and thanks for all the powerpc fixes :)
<BenC> I'm just trying to fix some build failures for packages that depend on cython, and python-support is the reason it's uninstallable for build-deps
<BenC> micahg: no problem
<barry> jtaylor: submitted a debdiff on bug 1012331 but i won't be able to do anything about it today.  if someone wants to beat me to it...
<ubottu> Launchpad bug 1012331 in cython (Ubuntu Quantal) "Needs to be converted to dh_python2" [High,Triaged] https://launchpad.net/bugs/1012331
<BenC> What's the proper fix here?
<BenC> Ah
<BenC> barry: I'm on it...
<micahg> ah, I forgot the -dbg package when I tried it :)
<barry> BenC: awesome, thanks
<skunk> how do you modify default window dimensions?
<killown> how can I deal with this issue https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/973610 since I need install ubuntu 12.04 and nouveau driver don't let me do that
<ubottu> Launchpad bug 973610 in xserver-xorg-video-nouveau (Ubuntu) "Flickering Screen - X Display Problem Nouveau DRM [12.04 Beta2]" [Undecided,Confirmed]
<killown> it would at least fallback to vga mode...
#ubuntu-devel 2012-06-13
<SpamapS> oh I just love test suites that assume code will never survive past 2010
<SpamapS> this is the second time I've seen such nonsense
<SpamapS> especially when they've made a release as recent as 2008
<StevenK> SpamapS: We had a bug in the LP testsuite that used to assume a blueprint created in 2011 was in the future.
<SpamapS> in the yeaar two thousaaaaaannndd
<StevenK> I had successfully not thought about that song for years until you said that.
<SpamapS> http://www.youtube.com/watch?v=LQRmkoBpi28
<BenC> My lp-bug mojo is a little rustyâ¦.how do I link a bug to a Debian bug?
<ajmitch> 'also affects distribution', select debian & paste the debbugs url in, iirc
<BenC> Thanks, just figured it out :)
<lifeless> or just past the url into a comment
<ajmitch> lifeless: that adds the debian task automatically?
<lifeless> it adds a watch automatically, which is the key thing
<ScottK> SpamapS: Thanks for fixing mysql-5.5 sufficiently that I'm not required to care anymore.
<infinity> ScottK: Thanks for fixing cython, and congrats on cleverly avoiding TILM by puppeting Ben. :P
<ScottK> I actually managed to not do any work on it at all.
<ScottK> Major victory.
<ScottK> Mission accomplished by whining.
<infinity> ScottK: Ahh, he misattributed the patch.  I'm sure jtaylor is crushed.
<ScottK> I didn't get get the barry card.  He was going to look at it tomorrow, but now he doesn't have to.
<ScottK> Yeah.
<ScottK> I mentioned it in the bug.
<infinity> All that hard work changing four lines. ;)
<ScottK> The work avoided by not being TIL is potentially infinite.
<infinity> Heh.
<micahg> and I already had all that except for cython-dbg in debian/rules
<ScottK> jtaylor should be happy though.  Now he can apply guilt on BenC when he wants a core-dev endorsement.
<infinity> Ben's immune to guilt.
<infinity> He does respond well to nicotine and cartoons, however.
<BenC> and jaeger
<BenC> Combinations of the three in creative ways are welcome
<infinity> Heh.
<infinity> BenC: You really need to come hang out at some conferency gathering soon.  Haven't seen you in ages.
<BenC> infinity: I tried to get to quantal UDS but it didn't work out. I am 94.7% sure I will make UDS-R though
<ScottK> I hope the hold it in some place cool enough that I'll feel like it's worth wanting to go.
<ScottK> I mean Oakland?
<broder> i liked that it was close
<broder> but yeah, meh
 * BenC is still hoping for the cow-pasture-uds
<BenC> Will give BoF a new meaning
 * micahg wonders what interesting locations there are
<StevenK> I'd say Sydney, but infinity would stab me.
<infinity> We've been.
<StevenK> Only once. UDS has been in *Florida* more than that.
<infinity> It's also hideously expensive to do anything other than Europe or North America.
<infinity> StevenK: Yeah, and Florida was a mistake every time. :P
<ScottK> Boston was nice.
<StevenK> Florida was slightly better than Dallas.
<infinity> UDU (Sydney) was actually pretty good.  The hotel was fun, etc.  But that was back when the distro team was 15 people.
<ScottK> Yes.
<infinity> Cool little venues like that don't work anymore. :(
<infinity> And Sydney's large conference venues are just as soulless as anyone's.
<ajmitch> but they're closer for some of us
<infinity> Not many of us. :P
<ScottK> Chicago would be fun for a US location.
<micahg> \o/
<StevenK> ScottK: I'd like to see Chicago, actually.
<infinity> If it didn't come right back around to the "hideously expensive" point, I'd vote for Manhattan.
<micahg> infinity: they managed DebConf there somehow
<infinity> micahg: Yeah, but DebConf doesn't mind begging universities for lecture halls.
<infinity> micahg: We annex entire conference centers.
<ScottK> Precisely.
<infinity> micahg: Those don't come cheaply.
<ScottK> Except in Florida.  There they are so huge we only get a little piece of one.
<infinity> ScottK: Heh.
<ScottK> I've never been to Warsaw.  How would that be?
<infinity> Bleak.
<infinity> Culturally awesome, love the people, the music, the food.  But man, the architecture makes me want to stab myself repeatedly.
<ScottK> Are you arguing for or against?
<infinity> I'm not sure. ;)
<ScottK> That's just good street theater for some.
<infinity> I actually pretty much never say no to former Eastern Block sorts of locations.
<infinity> Cheap beer, fun people, an inexplicable obsession with doilies.
<micahg> awesome, powerpc is doing better than i386 with build failures (not depwaits)
<vibhav> good morning
<vibhav> http://consumerist.com/2012/06/newegg-installing-linux-on-your-computer-is-basically-the-same-as-breaking-it.html
<vibhav> geser: you there?
<pitti> Good morning
<pitti> barry: yes, foomatic-db-compressed-ppds py3 is in the archive; I keep my WIs as "in progress" until they are really in ubuntu
<pitti> cjwatson: u-d-common> my new code is py3 compatible, but the old nvidia-common bits are not; tseliot is on that (he ported python-xkit, which is a dependency)
<pitti> barry: apport got binNEWed, so the py3 version is in quantal now
<geser> vibhav: yes, I'm now here
<pitti> cjwatson: further porting u-d-common is yet another case of "blocked by aptdaemon"
<pitti> once we get that in, we can port apturl, language-selector, u-d-common, software-properties, etc.
<ScottK> I got slightly lost trying to figure out why dnspython is in Main and if any python3 porting was blocked on it.  I just uploaded dnspython3 to Debian.  If lack of that is blocking anything, please let me know and I'll do a direct upload to Ubuntu too.
<dholbach>  good morning
<cjwatson> pitti: Yeah, it's the nvidia bits that matter here.
<cjwatson> pitti: aptdaemon is, I hear, very close
<pitti> yes, it's by and large working in trunk
<pitti> the new apt is through binNEW now, I thought that was a prerequisite
<cjwatson> Yes
<pitti> python-apt is the next and last step, AFAIR
<mvo> @pilot out: mvo
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<mvo> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> pitti: python-apt went into -proposed along with apt
<cjwatson> I think that's in quantal now too, though I haven't upgraded yet today
<pitti> ah
<pitti> yes, it is
<cjwatson> And if we don't get update-manager in today I'll be slightly annoyed :)
<cjwatson> soooooo close
<pitti> cjwatson: do you know if anyone already discussed extending DEP-8 to add a source package header? (like "XS-Has-Tests: true"); if not, I'll do that now
<pitti> once that's in the standard, we could make dpkg-source add that header automatically
<pitti> but at least add it manually for the time being, to drop the hardcoded list from jenkins
<cjwatson> pitti: We talked about it and I was going to propose it, but I don't think I actually did formally (I may have spoken to Ian about it informally); if you'd like to bring it up on wherever the discussion list for DEP-8 is, feel free
<pitti> cjwatson: ok, doing; I was going to mail the three drivers on http://dep.debian.net/deps/dep8/, CC'ing debian-devel@ (not sure if the latter is appropriate)
<cjwatson> pitti: Should be
<seb128> bdmurray, slangasek, SpamapS, RAOF: could we some precise SRUs through today or tomorrow? the queue has around 30 items, some waiting for 3 weeks...
<tkamppeter> seb128, pitti is really missing in the SRU team.
<seb128> tkamppeter, hey, yes he is ;-)
<RAOF> Is updating the bug description with a reasonably simple template *really* that much to ask for SRUs?
<tkamppeter> seb128, I have talked to the people you were trying to talk to here on #ubuntu-release. I got mainly quick help from cjwatson, but also from slangasek.
<seb128> RAOF, I share the sentiment, though some people already things that having to provide a debdiff is work they shouldn't need to do, especially some upstream would like to be able to point to a patch and have us to take it...
<seb128> tkamppeter, thanks, I know they are all busy and I'm not especially blocked on one SRU, I mostly wanted to point that we are accumulating backlog
<vibhav> geser: Are you still here?
<geser> vibhav: yes
<seb128> yofel_, Riddell, ScottK: hey, is somebody looking at the calligra armhf,armel ftbfs in quantal?
<seb128> yofel_, Riddell, ScottK: asking because it's showing up on http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
<xnox> emacs24 for quantal?!
 * xnox uses emacs a lot, and has been using ~weekly emacs24 snapshots. I haven't done emacs24 packaging before myself
<Riddell> seb128: it's somewhere on the list of things to be done yes
<seb128> Riddell, somewhere high or somewhere low? ;-)
<Laney> xnox: see if Rob is planning to do it?
<Laney> it would make me happy too
<Riddell> seb128: high enough that it'll get done but not this week
<seb128> Riddell, ok, thanks
<xnox> Laney: which Rob? =)
<Laney> the maintainer :P
<cjwatson> Browning, I should imagine
<Laney> that's the badger
<xnox> what's his irc nickname?
<Laney> laney@raleigh> finger rlb@db.debian.org | grep IRC                                                                         ~
<Laney> IRC nickname: rlb
<RAOF> seb128: Incidentally, ubuntu-sru had a meeting this morning about how to get into a position where there isn't a backlog; expect to see things improve ;)
<pitti> RAOF: do you want to do something similar to the "archive admin of the day" roster?
<RAOF> That was one of the outcomes, yeah.
<seb128> RAOF, great ;-)
<cjwatson> Riddell: Speaking of calligra, there's a calligra-transitional package pending autosync which fails to sync because:
<cjwatson> calligra-transitional_1 is trying to override modified binary koffice-l10n-ca_2.3.2-0ubuntu1.  OK (y/N)?
<cjwatson> Riddell: What should be done about that?
<Riddell> hmm
<Riddell> cjwatson: ignore it for now until I get a chance to look at it properly
<Sweetshark> jibel: hey, I am getting spammed by the jenkins bot. awesome!
<jibel> Sweetshark, only when it fails :)
<Sweetshark> jibel: this is really neat.
<jibel> Sweetshark, latest build it with gcc 4.6 and no dependency issue on mysql.
<Sweetshark> jibel: Ive seen this failure on the ppa too. most curious: the test seem to succeed completely, yet ./debian/rules seems to think there is an error. Maybe something going wrong with the returncode-foo.
<Sweetshark> ah, no. this one has an error.
 * Sweetshark checks.
<Sweetshark> jibel: is gdb installed on that machine?
<jibel> Sweetshark, yes
<Sweetshark> jibel: good
<jibel> let me know if there is a specific setup for gdb. I'm not familiar with it.
<Sweetshark> jibel: it should be good. usually no specific setup needed.
<Sweetshark> jibel: am I supposed to open the link at the top of the mail? just asking because it times out here ...
<jibel> Sweetshark, ah, here is the link with the public address https://jenkins.qa.ubuntu.com/job/quantal-pkg-libreoffice/ARCH=amd64,label=albali/33/
<Sweetshark> jibel: thx ;)
<ev> pitti: any objections to an apport release? That core pipe brokenness appears to be pretty bad: https://errors.ubuntu.com/api/most-common-problems/Ubuntu%2012.10/today
<pitti> ev: I just did an upstream 2.2.2 release and are prepping a quantal upload (test suite running ATM)
<ev> pitti: awesome, thanks!
<pitti> ev: I didn't notice it in the previous upload as the test suite runs with the system /usr/share/apport/apport for the crashes *duh*
<pitti> so, no actual crashes today :)
<ev> heh
<pitti> I also fixed some other bugs (just G+'ed about one), now the tests shoudl all succeed again
<pitti> if it wasn't for xvfb segfaulting, that is :) (but works fine with APPORT_TEST_NOXVFB=1)
<ev> it turns out that missing counts for today might be some brokenness in the counters, as jodh helpfully points out that we don't have anything for 11.10 either
<ev> I'll investigate after the python3 porting sprint
<Laney> do upgrade failures get submitted to errors.u.c too?
<hallino1> Evening!
<hallino1> I've got a small problem when i write debuild binary.. -> http://paste.ubuntu.com/1038740/
<ev> Laney: it's planned, but nothing currently implemented
<hallino1> I'm new with packaging.. Anyone can help me please?
<Laney> ev: ok, thanks
<ev> Laney: which incidentally is why mpt came up with the error tracker name. Application crashes, package install failures, application hangs, debconf prompts, etc.
<mpt> ev, have you seen <http://askubuntu.com/questions/135540/what-is-the-whoopsie-process-and-can-i-remove-it>?
<cjwatson> A friend of mine has been objecting to the name every chance he gets
<cjwatson> It seems to freak him out
<cjwatson> Supplying a man page would probably have soothed him since I think that was the first thing he reached for
<StevenK> cjwatson: Why, is he Frank Spencer? :-P
<cjwatson> Er, no
<cjwatson> (Long time since I saw that)
<StevenK> cjwatson: I had to go and look it up because I couldn't remember the name of the actor or the character.
 * xnox likes the comment "No, just apt-get rid of it."
<vibhav> geser: REALLLY SORRY for being AFK, Since you were the last guy to touch dracut in ubuntu, are you comfortable with me preaparing a merge for it?
<geser> vibhav: sure, feel free to take it
<vibhav> thanks!
<vibhav> geser: By the way, why did you add docbook-xsl to Build-Depends ?
<vibhav> oh wait, its already added in debian
 * vibhav files a syncrequest
<geser> vibhav: the unmodified package FTBFS: https://launchpad.net/ubuntu/+source/dracut/018+32+geb6e141-1/+build/3469665
<vibhav> geser: Since dookbook-xsl was added to Build Depends in Sid, I have filed a sync request: https://bugs.launchpad.net/bugs/1012641
<ubottu> Launchpad bug 1012641 in dracut (Ubuntu) "Sync dracut 019+9+g521c57a-1 (universe) from Debian sid (main)" [Undecided,New]
<ev> mpt: I had not. I did manage to get this one in yesterday though: http://askubuntu.com/questions/140379/how-can-i-track-a-bug-that-caused-a-crash-and-was-reported-via-apport-whoopsie/149455#149455
<vibhav> doko: ping
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<barry> hi pitti fantastic, thanks
<ev> mpt: replied: http://askubuntu.com/questions/135540/what-is-the-whoopsie-process-and-can-i-remove-it/150332#150332
<vibhav> cyphermox: ping
<herton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton, mdeslaur
<vibhav> wow
<mpt> ev, Nanne has a point: What's the way to turn it off on the server?
<stokachu> To disable it on Ubuntu Server, edit theÂ /etc/default/whoopsieÂ file and changeÂ report_crashes=Â tofalse, then runÂ sudo stop whoopsie.
<Laney> It'd be nice if there were a manpage explaining such things
<stokachu> or maybe just added to readme for package
<pitti> lamont: do you happen to plan to update util-linux to the latest upstream version by any chance?
<pitti> lamont: I just tried for an hour to fix wipefs, but the vfat fix is not backportable at all, and my own attempt of quickfixing it in 2.20.1 went badly
<ev> Laney: you're more than welcome to write one :)
<vibhav> herton: are you busy?
<Laney> ev: I would if I knew what to write :P
<herton> vibhav, hello, what's up?
<ev> Joking aside, there is an outstanding bug report for it. I've had more pressing problems to solve.
<vibhav> herton: If you are not occupied , could you have a look at https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1012666 ?
<ubottu> Launchpad bug 1012666 in libisofs (Ubuntu) "Please merge libisofs 1.2.2-1 from Debian Unstable" [Undecided,New]
<herton> vibhav, hi, I can't, I can look only at kernel bugs for now
<herton> vibhav, may be mdeslaur can help you
<vibhav> mdeslaur: If you are not occupied , could you have a look at https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1012666 ?
<ubottu> Launchpad bug 1012666 in libisofs (Ubuntu) "Please merge libisofs 1.2.2-1 from Debian Unstable" [Undecided,New]
<lamont> pitti: I should do that
<mdeslaur> vibhav: sure, I have a couple of things queued up, but I'll take a look after them
<mdeslaur> vibhav: i'll get to it in about an hour
<lamont> pitti: I think time would be better spent on getting the latest version there, rather than just pulling over fixes one at a time
<lamont> I'll see how this weekend does for getting that and nmap happier
<pitti> lamont: yes, I've come to the same conclusion
<pitti> lamont: it just doesn't seem easier; it doesn't have split-out patches, so wading through the monolithic diff seems to be a bit of a challenge
<pitti> lamont: do you have a magic way of updating that?
<ogra_> pitti, is bug 1007826 an issue on the apport side or is that the way the function was called ? i''m currently porting xdiagnose to py3 and get similar output in the testsuite
<ubottu> Launchpad bug 1007826 in apport (Ubuntu) "crash with AssertionError: file stream must be in binary mode when trying to save report to file" [Undecided,New] https://launchpad.net/bugs/1007826
<ogra_> (if its the way the function is called i'll happily fix it)
<pitti> ogra_: right, I sent a warning about this to planet and u-devel@
<pitti> ogra_: https://www.piware.de/2012/05/apport-api-users-watch-your-data-types-python-3-porting/
<ogra_> ah
 * ogra_ goes reading
<ogra_> uuuh !
<ogra_> "Dieser Verbindung wird nicht vertraut"
<ogra_> :)
<mvo> barry: is xapian a target for the py3 porting sprint too ? I think its the last missing dependency for software-center :)
<smoser> anyone know... lp:debian/sid/euca2ools is out of date. i'm not accustomed to that happening for debian, but usually only after i've screwed something up in the lp:ubuntu branch.
<smoser> how can i get my local branch of lp:debian/sid/euca2ools updated? is there an easy way to suck in the debian package?
 * smoser is embarrased. after typing bzr import-<tab> he sees "import-dsc"
<mterry> mvo, does update-manager not use code reviews?  Should I just be committing directly?
<mvo> mterry: it does, its just that the set of reviewers is really tiny and that the py3 sprint is also going on at the same time
<mvo> mterry: I'm sorry that its a bit of a hassle right now
<mvo> mterry: I think its ok if you go wild and take it over for now
<mterry> mvo, no it's fine.  I wasn't complaining, just curious
 * mvo nods
<mterry> mvo, I didn't see it on https://wiki.ubuntu.com/UbuntuEngineering/12.04/UpstreamDevelopment/ProjectTracking either
<mterry> mvo, not sure why that URL is dated for 12.04.  Presumably it's an ongoing list
<mterry> rickspencer3, ^ ?
<rickspencer3> hi mterry
<xnox> does anyone have a snippet for quiltrc to correctly choose between series / series.ubuntu based on dpkg-vendor?
<mterry> rickspencer3, does that ProjectTracking page have a non-12.04-specific URL somewhere?
<rickspencer3> mterry, I dunno
<rickspencer3> I'm not actually familiar with it ;)
<mterry> rickspencer3, wait what?  i thought that was your baby
<barry> mvo: it's on the list, but i don't think anyone's attacked it yet.  i'll ping the team
<rickspencer3> mterry, well, I guess it was at one point, yeah
<rickspencer3> but babies grow up and leave home
<mterry> rickspencer3, this one refuses to leave the warm embrace of 12.04
<mvo> barry: awsome
<seb128> mterry, who can blame it? the lts rocks ;-)
<mvo> mterry: hrm, its indeed missing there
<pitti> tseliot: hey Alberto
<pitti> tseliot: want me to review https://github.com/tseliot/ubuntu-drivers-common/pull/3 ?
<pitti> tseliot: or do you want to?
<pitti> tseliot: it looks mostly good to me, I just don't particularly like the "from __future .. absolute import" stuff
<mterry> mvo, well anyway, I'll leave the branches as is instead of cowboying them in.  No rush really
<vibhav> dholbach: ping
<tseliot> pitti: feel free to approve the merge request. I feel the same way about the absolute import stuff but it's for backwards comaptibility
<dholbach> vibhav, pong
<pitti> tseliot: I mean, I'd rather change it to "import Quirks.quirkreader" or so
<tseliot> pitti: ah, sure, that would definitely look better
<vibhav> dholbach: If you have any free time could you please write your testamonial on https://wiki.ubuntu.com/VibhavPant/UniverseContributorApplication ?
<vibhav> testimonial*
<dholbach> vibhav, I bookmarked it - I'm currently in the middle of 5 other things :)
<vibhav> thanks!
<vibhav> jamespage: You there?
<jamespage> vibhav, I am
<jibel> pitti, crash files are now deleted before adt-run runs and saved as artifacts after
<jibel> pitti, for apport there are 2 crash files
<jibel> https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-apport/15/ARCH=amd64,label=albali/artifact/results/
<pitti> jibel: thanks
<pitti> jibel: oh, did it run now for 2.2.2?
<pitti> jibel: ah, that's for 2.2.1 apparently
<vibhav> jamespage: Can I prepare a sync for gettext from Debian Sid? (Since you were the last person to touch it in ubuntu)
<vibhav> s/sync/merge/
<pitti> jibel: ah, no, looks like yet another problem; I'll trawl through that, thanks!
<jibel> pitti, run 15 tested 2.2.2, isn't it ?
<pitti> right
<mpt> ev, I saw your previous answer via <http://www.reddit.com/r/Ubuntu/comments/uwf19/awesome_explanation_on_how_the_ubuntu_crash/>
<jamespage> vibhav, be my guest!
<jamespage> (and thanks for asking :-))
<vibhav> thanks!
<pitti> xnox: OOI, how did you test u-d-common?
<pitti> xnox: I'm currently running: PYTHONPATH=.:~/upstream/aptdaemon python3 tests/run
<smb> pitti, doko, While trying to fix up something which gcc-4.7 is more picky about, I noticed that running the same package compile with precise will invoke gcc with some additional options which look a bit like hardening (-fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security). In quantal those are not there. Just wondered whether that is expected...
<pitti> xnox: aside from the PackageKit failures I also get some errors from the quirk reader
<xnox> pitti: hmm I will look
<xnox> pitti: i was running tests with $ python3 -m unittest discover
<xnox> with extra flags
<xnox> pitti: why are tests files *not* called tests/test_*.py ?
<pitti> xnox: no particular reason, I guess; tests/run doesn't care
<xnox> pitti: it looks like tests/run has been modified to filter out settings.py and other stuff
<pitti> xnox: also, with your merge the tests now fail
 * xnox generally doesn't like tests/run scripts. It should IMHO just work with unittest discover runner
<pitti>   File "/home/martin/ubuntu/ubuntu-drivers-common/tests/ubuntu_drivers.py", line 29, in <module>
<pitti>     from . import fakesysfs
<pitti> ValueError: Attempted relative import in non-package
<xnox> awesome
<xnox> that is fail
 * pitti sees to fixing this
<infinity> pitti: Were you planning on adding those new symbols to Debian's cups at some point soon, or should we just fix it in Ubuntu to get it off our radar?
<pitti> infinity: it's already fixed in Debian's bzr
<pitti> infinity: I have another RC bug I need to fix, then I wanted to do another upload
<infinity> pitti: Ahh, kay.
<pitti> xnox: pushed two fixes to trunk which should be better again; tests now work again with py2, and the imports should be fine for py3 as well (PYTHONPATH=. python3 ./quirks-handler)
<xnox> pitti: thank you. I will check them out.
<pitti> xnox: I also pushed a fallback for packagekit.enums, but that's again blocked on aptdaemon (just tested against upstream trunk, can't change the Depends: yet)
<xnox> pitti: yeap, I'm about to upload python3-packagekit to branch / ppa for testing
 * xnox building in pbuilder
<pitti> xnox: anything wrong with glatzor's PPA?
<xnox> pitti: what's glatzor's PPA?
<infinity> rsalveti: Do you know anything about the gles/glew sadness that's causing build failures?
<pitti> xnox: https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035297.html
<pitti> xnox: he already provided test packages
<infinity> rsalveti: (See callibra in quantal, grep the log for 'conflicting declaration')
<xnox> pitti: that doesn't have packagekit, or does it?
<xnox> pitti: there was more work done on the aptdaemon
<xnox> after the ppa
<pitti> xnox: no, I doubt that packagekit has been ported already
<pitti> xnox: argh; ignore me
<pitti> xnox: I got confused
<xnox> pitti: it has been upstream. well the python-packagekit
<xnox> not all the helper scripts
<pitti> xnox: u-d-common falls back to aptdaemon.pkenum for now (as that is already available in aptdaemon, but we haven't had a python3-packagekit so far)
<xnox> pitti: you will in a second =)
<mterry> tremolux, if software-center says to check the logs because it can't submit a review, where do I look?
<tremolux> heyy mterry!! it's here: ~/.cache/software-center/software-center.log
<tremolux> that message is pretty useless :/
<rsalveti> infinity: nops, let me check
<mterry> tremolux, thanks!
<tremolux> mterry: yw, thank you too!
<tremolux> mterry: there is an open bug on this, may be the same, let me find it
<tremolux> mterry: bug 778070
<ubottu> Launchpad bug 778070 in software-center (Ubuntu) "Failed to submit report/review in software-center" [Medium,Confirmed] https://launchpad.net/bugs/778070
<infinity> rsalveti: Maybe we just need a new mesa to go with glew1.7?  I dunno.  I haven't looked into it deeply, and I suspect no one else has yet either, cause it only (so far) affects ARM.
<tremolux> mterry: server-side fix in-progress
<rsalveti> there was some important changes for gles support at glew1.7 afaik, so need to make sure it's all properly enabled I guess
<mterry> tremolux, I have the same trace as comment #8, but not sure that's what that bug was originally about
<mterry> tremolux, but if the server-side fix will get #8, I'm good
<rsalveti> infinity: why are we still building for armel?
<tremolux> mterry: right, the original probably described something that has long since been fixed (server churn, client churn) but the bug not updated/noticed, and the current problem seems to be as described in #8, and that is the one being fixed
<tremolux> mterry: #8 is the one that people are hitting now, and it seems recent (and it revived the bug)
<mterry> tremolux, cool
 * mterry looks forward to reviewing again
<infinity> rsalveti: It's complicated.
<rsalveti> infinity: :-)
<tremolux> mterry: :D reviews ftw!!
<barry> kenvandine: ping
<kenvandine> barry, pong
<barry> kenvandine: hi, how are you today?  i wanted to chat a bit about the py3 port of whatever parts of gwibber are going to be on the 12.10 desktop image.  when i last looked, it was gwibber and gwibber-service.  what's the current status of the code, and any py3 porting work you're aware of?
<barry> kenvandine: foundations team is sprinting on py3 support and i figured since i'd previously looked at this, i'd take another look at it today
<kenvandine> i haven't done anything yet, was hoping for a solution for libpeas
<kenvandine> barry, has anything been figured out there?
<barry> kenvandine: ah libpeas.  i don't think so, but i will look into that today
<kenvandine> we want to switch to using libpeas for handling the service plugins
<kenvandine> instead of the hacky stuff we have now
<kenvandine> but libpeas and py3 was a ???
<kenvandine> switching to libpeas would simplify the port to py3 if that worked with py3
<mterry> kenvandine, libpeas has gir support
<barry> kenvandine: so gwibber doesn't currently use libpeas?
<kenvandine> barry, no
<dobey> mterry: it does, but that's mostly irrelevant
<kenvandine> mterry, yeah but not py3 yet
<dobey> mterry: the python loader only uses the python2 runtime
<mterry> kenvandine, ah, internally it only supports py2 plugins?  bummer
<dobey> it should be easy to fix though
<dobey> it just needs a py3 loader, and code to avoid loading both the py2 and py3 loaders (which are shared objects in libpeas itself)
<vibhav> jamespage: done : https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/1012705
<ubottu> Launchpad bug 1012705 in gettext (Ubuntu) "Please merge gettext 0.18.1.1-9 from Debian Unstable (main)" [Undecided,New]
<barry> dobey, kenvandine, mterry: so, it sounds like it's more useful for me to look into libpeas right now
 * kenvandine hugs barry
<henrix> infinity: hi! could you please copy the precise kernel pkgs into -updates? (bug #1003534)
<ubottu> Launchpad bug 1003534 in Kernel SRU Workflow "linux: 3.2.0-25.40 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1003534
<dobey> barry: right. and it's required to fix a lot of other things as well (rhythmbox, gedit, etc)
<infinity> henrix: Yeahp.  Are armadaxp and ti-omap4 also ready, or just linux/lbm/meta?
<barry> dobey: ack.  i'll put it next on my list
<henrix> infinity: they should be ready, but not sure. let me check...
<infinity> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1004555
<ubottu> Launchpad bug 1004555 in linux-ti-omap4 (Ubuntu) "linux-ti-omap4: 3.2.0-1414.19 -proposed tracker" [Medium,In progress]
<infinity> ti-omap4 looks ready
<infinity> henrix: armadaxp lacks a tracking bug, https://bugs.launchpad.net/eilt/+bug/1006217 is as close as it gets.
<ubottu> Launchpad bug 1006217 in The Eilt project "[public] SBP (Static Branch Prediction) problem - disable it" [Undecided,In progress]
<henrix> infinity: yeah, ti is ok but not armadaxp
<infinity> henrix: Can you get those folks to do tracking bugs in the future?  I find them wildly useful for the rather complex kernel SRU workflow.
<xnox> pitti: so while aptdaemon is in progress there is now bug 1012703 which needs/review sponsor
<infinity> henrix: (For this one, though, I'm happy to let it slide, if someone can just verify the kernel is sane
<ubottu> Launchpad bug 1012703 in packagekit (Ubuntu) "please add python3-packagekit package" [Wishlist,Triaged] https://launchpad.net/bugs/1012703
<infinity> )
<xnox> infinity: =))) way to go for me to break your )
<henrix> infinity: sure, give me 1 minute to figure out what's going on
<infinity> xnox: Hrmph.
<henrix> infinity: it looks like armadaxp *does* have a tracking bug: #1004556
<ubottu> Launchpad bug 1004556 in linux-armadaxp (Ubuntu) "linux-armadaxp: 3.2.0-1603.6 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1004556
<infinity> henrix: But not mentioned in the changelog?  Argh.
<henrix> infinity: hmm... interesting. still trying to figure out what's going on with armadaxp...
<infinity> henrix: I'm guessing no one told janimo about the tracking bug. :P
<infinity> henrix: Hence, he didn't include it in the changelog.
<henrix> infinity: that's a possibility :)
<henrix> infinity: anyway, thanks for the heads up. i'll go sort that out
<infinity> henrix: Cool.  linux (et al) and ti-omap4 (and meta) are done.
<henrix> infinity: great, thanks
<infinity> henrix: To be clear, I don't want anyone doing anything silly like re-uploading aramdaxp and restarting the verification process, just to fix the changelog. :P
<infinity> henrix: Just some followup to the bug that *is* in the changelog (and a mention of the tracking bug in that same bug log, so we can go dot our Is and cross our Ts) would be fine.
<henrix> infinity: ack, thanks
<henrix> infinity: i still see the "promote-to-updates" task as 'confirmed'. any idea why?
<henrix> infinity: (btw, the issues with armadaxp are being sorted out)
<infinity> henrix: D'oh.  Because LP timed out when I was updating the bug and i didn't notice. :)
<infinity> henrix: Fixed.
<henrix> infinity: heh cool! :)
<henrix> infinity: thanks
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach back
<SpamapS> seb128: we're going to start doing a daily rotation, and today is my day. I'll spend a few hours doing SRU's, not tow orry. :)
<seb128> SpamapS, taht's great news, thanks!
<SpamapS> seb128: btw thanks for clearing up the gnome MRE :)
<seb128> SpamapS, no worry, it's going to make my life easier as well ;-)
<BenC>  // Define if compatibility should be provided for -mlong-double-64.
<BenC> #define _GLIBCXX_LONG_DOUBLE_COMPAT 1
<BenC> doko: How important is that on powerpc?
<BenC> doko: like will it break c++ ABI if it gets disabled
<BenC> doko: if it just break backward compatibility pre-2006, then I'd like to vote to disable it on powerpc
<BenC> It's marked "GLIBCXX_ABI Deprecated"
<infinity> BenC: Is it causing you issues?
<BenC> infinity: it's the cause of most build failures for things like gdc, aspectc++, and a few other things
<BenC> if I #undef that one line, all those things compile and are happy
<BenC> fixes about half a dozen FTBFS and countless dep-waits
<infinity> BenC: That's... Odd.  It shouldn't, on its own, be causing any problems, really.
<BenC> infinity: it's notâ¦it's the "inline namespace" that gets exposed because of it
<infinity> BenC: Unless those packages are also passing -mlong-double-64
<BenC> ...c++config.h:336: error: invalid declaration near token `namespace'
<BenC> That "invalid" is "inline" and it's in the block of code used to get the -mlong-double-64 compatibility
<BenC> I realize it's not really invalid, and that c++config.h isn't really broken, but all of these things build on x86 because it doesn't have this define, and I can't fix it anywhere else but in c++config.h
<infinity> Well, we've probably been long-double-128 by default for over half a decade, but it might be worth sorting out how to scan the archive to make sure that dropping compat doesn't break anything.
<BenC> It's the default for alpha, powerpc, sparc and s390 for this compatibility
<BenC> At the very least, I'd like to modify c++config.h so that it can be disabled with a -D or similar
<BenC> infinity: This was easier than I thoughtâ¦adding -mlong-double-64 to these problematic program's CFLAGS might be the more unobtrusive fix
<infinity> BenC: Oh.  As in, they're breaking when building with the default mld128, but work with 64?
<infinity> BenC: That's kinda special.  But a simple enough fix.
<BenC> infinity: right, but only because it avoids the "inline namespace" verbiage, but I'm happy with that
<infinity> BenC: And one that will fail in very obvious ways if the backward compat ever goes away, so it's not like you're introducing scary.
<BenC> Yeah, and considering these things never really built well on powerpc to begin with, one that won't break existing usage
<slangasek> pitti: hi, who manages http://changelogs.ubuntu.com/?  It seems we're not getting updates, is this a known issue?
<seb128> slangasek, somebody mentions it was a disk out of space issue with a RT filed
<slangasek> ah, ok
<seb128> slangasek, <mvo>	mdeslaur: yes, changelogs.ubuntu.com has a full disk
<seb128> slangasek, that was on june 6, maybe you can help the rt to get moving? ;-)
<slangasek> seb128: sure, as soon as I find the RT :)
<seb128> slangasek, msged to you
<slangasek> seb128: ta
<mterry> barry, for a package that delivers the DistUpgrade module, should it's name be python-DistUpgrade, python-distupgrade, or python-dist-upgrade?
<mterry> ahem, "its" not "it's"
<ScottK> python-distupgrade.
<ScottK> No case in package names.
<mterry> ScottK, yar I figured case would be bad.  OK, thanks!
 * ScottK wonders if he missed the memo about International Talk Like A Pirate Day?
<mterry> ScottK, I'm just stuck :)
<SpamapS> hmm.. thats weird
<SpamapS> juju was synced from Debian even though it already had a -0ubuntuX version
 * barry concurs
<SpamapS> 0.5+bzr538-0ubuntu1
<SpamapS> should have blocked the sync, no?
<ogra_> did debian have a -1 version by chance ?
<SpamapS> 0.5+bzr539-1 was synced
<ogra_> yeah, -1 > -0ubuntu1
<SpamapS> but the existence of an ubuntu version should have stopped that
<lifeless> why ?
<SpamapS> Because that should require a merge
<lifeless> not if the debian changelog contains 0ubuntu1 in it.
<SpamapS> wha?
<lifeless> [caveat, I haven't checked the code]
<SpamapS> we just blindly throw away Ubuntu delta?
<lifeless> but there is a merge graph
<SpamapS> it hasn't happened with mysql-5.5
<lifeless> SpamapS: is there a delta in this case?
<SpamapS> which was at 5.5.22-0ubuntu1 when Debian got 5.5.24+dfsg-1
<SpamapS> lifeless: yes, though its fairly innocuous and unimportant
<SpamapS> I was planning on syncing them actually
<SpamapS> so its possible somebody decided to just do it
<ogra_> well, theoretically if the debian package contains the version thats current in ubuntu one should be able to assume that the code is contained
<ogra_> so there theoretically cant be a delta
<SpamapS> ogra_: it was my understanding that *any* -XubuntuX would force a manual merge or sync
<SpamapS> This must have been a manual sync
<debfx> it is a manual sync: https://lists.ubuntu.com/archives/quantal-changes/2012-June/002527.html
<SpamapS> Actually it was, quantal-changes says Jeremy Bicha
<ogra_> well, why would you merge it if the changelog says it is already merged ?
<SpamapS> ogra_: the changelog does not say it is already merged
<ogra_> i thought the changelog caontained the -0ubuntu1 version in the debian package
<SpamapS> I'm guessing Jeremy just looked at the diff and realized it was fine (which it seemingly is) and just synced
<SpamapS> ogra_: no definitely not
<BenC> infinity: is there a better way to get a rebuild of a package (for the sake of it using a newer library) other than uploading a changelog-only source?
<ogra_> ah, then i misread
<ScottK> BenC: No.
<SpamapS> the debian package has but one entry in the changelog.. for the 0.5+bzr539-1 .. since it was NEW'd only yesterday
<ogra_> ah
<SpamapS> I had intended to sync it myself.. *after* testing it :-P
<ogra_> yeah, that shouldnt autosync indeed
<SpamapS> Hopefully our daily package builds still work.
 * SpamapS tries the recipes now
<ScottK> But it didn't autosync.  jbicha sync'ed it.
<cjwatson> mterry: Remind me of the new dist-upgrade branch?  I guess I have a ton of patches to sync over.
<ScottK> (AIUI)
<SpamapS> ScottK: right, it was just an eager syncer. ;)
<cjwatson> mterry: I was kind of hoping to do an update-manager upload before trying to split out the upgrader, though, because I'm tantalisingly close to having it py3-ready.
<cjwatson> lifeless: Autosyncing is purely based on whether the version number contains the "ubuntu" substring.  -0ubuntu1 isn't special.
<mterry> cjwatson, I've been working on integrating your new patches
<SpamapS> ok, n/m.. nothing to see here. :)
<mterry> cjwatson, I know, I didn't realize all this python3 stuff would happen before my branch got merged
<cjwatson> mterry: The reason I'm reluctant is that I just finished doing a full test matrix this morning
<mterry> cjwatson, U-M side is https://code.launchpad.net/~mterry/update-manager/split-release-upgrader
<cjwatson> And I kind of don't want to do that all again tonight
<mterry> cjwatson, new package is https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/split
<cjwatson> Can we leave it until after the first update-manager py3 upload?
<mterry> cjwatson, we can sure.  I'm in no rush
<cjwatson> That shouldn't make it any more difficult.
<cjwatson> And then I get to be a bit more stepwise about things
<lifeless> cjwatson: thanks
<cjwatson> mterry: Any reason that branch isn't just in lp:ubuntu-release-upgrader?
<cjwatson> Oh, pending merege
<cjwatson> *merge
<mterry> cjwatson, yar, so it can be reviewed
 * ScottK imagines mterry with an eye patch again.
<cjwatson> mterry: Since lp:ubuntu-release-upgrader is currently just a copy of lp:update-manager, rather than cherry-picking patches, it would make more sense to pull the lot into lp:ubuntu-release-upgrader first
<cjwatson> That preserves history better as well
<cjwatson> Maybe if we start that from 1:0.163 once it's uploaded
<tgm4883> ev, can I bug you for a sec regarding errors.ubuntu.com
 * slangasek waits for mterry to start teaching command-not-found about avast-get and avast-cache
<mterry> cjwatson, hm?  how am I losing history?  if it's all in lp:u-r-u, you don't get a nice LP review, right?
<cjwatson> mterry: Why would I care?  Everything in lp:update-manager since then is either trivial or has already been reviewed.
<cjwatson> mterry: lp:u-r-u -> current tip of lp:update-manager is a pure fast-forward merge (in git terms).
<cjwatson> So we should do that first rather than cherry-picking a bunch of stuff that's textually identical but that now has a load of new commits.
<mterry> cjwatson, right, and I just synced them again.  But to be able to review my split...
<cjwatson> Your branch is a mixture of stuff you've done and stuff I've done
<cjwatson> AFAICS
<cjwatson> Either that or we duplicated things by coincidence; I'm only going by the web diff
<mterry> cjwatson, ah, well if you refresh you'll just seem my stuff.  I just re-sync'd lp:u-r-u from lp:u-m
<cjwatson> Ah, r2457 is an actual bzr merge
<cjwatson> So I guess that's OK, but it would still be easier to review if we just pulled lp:u-r-u from lp:u-m first
<mterry> cjwatson, right.  It's just a branch.  I'm doing this goofy stuff because LP can't support merge reviews across products
<cjwatson> Then the review would be of your split, not of your split + nearly everything since 1:0.161
<mterry> cjwatson, it will still just be my split.  Because lp:u-r-u is up-to-date
<ev> tgm4883: what's up?
<cjwatson> Oh.  It wasn't ten minutes ago when I looked!
<cjwatson> I swear
<mterry> cjwatson, right I know.  But I tried to tell you that I just re-synced a moment ago
<cjwatson> Ah - understood now, sorry, I thought you meant the merge in your split branch
<tgm4883> ev, I'm bugging slangasek about it (regarding adding logs to be gathered), and it appears it's just not possible yet
<mterry> cjwatson, well that too.  :)
<ev> tgm4883: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-bucketing-improvements
<cjwatson> Talking at cross-purposes.  Sorry.
<tgm4883> ev, thanks, I'll subscribe to that
<mterry> cjwatson, but anyway, back on topic, keep doing your awesome python3 stuff and don't worry about my branch.  :)
<mterry> I'll re-merge after your release
<kees> smb`: quantal has the disabled the forced flag exports in the build. however, those particular flags are already enabled by default. the only difference might be the presence/absence of the -O level
<smoser> is there a proper way to reference a bug in a debian/changelog that does not make it magically 'fix-released' ?
<smoser> i'm wanting to point to a bug in debian/changelog as reason for ubuntu delta
<smoser> ie, its already fixed but i dont want every subsequent upload to think "oh, that bug is fixed now" (or maybe it would just not do that because of fix-released)
<ScottK> Leave out the # and it won't trip the regex.
<seb128> smoser, if the bug is already closed in launchpad further uploads should not create any activity on the bug
<smoser> ok. thanks seb128 ScottK . i guess i'll just leave it proper (LP: #XXXX) style and since they're fix-released it should be ok.
<BenC> infinity: Is it correct that the buildd's run "debian/rules build" as opposed to "debian/rules build-arch"?
<BenC> infinity: Mainly because I've seen several build failures where override_dh_auto_build-indep is being called for things like doxygen, which is in build-dep-indep, so it isn't installed
<cjwatson> smoser: I generally use "LP #nnnnnn" for such things.
<infinity> BenC: They call dpkg-buildpackage -B (which does build, then binary-arch)
<soren> smoser: What cjwatson said. It's the general pattern people use for that. To specifically answer your question, though, the regex in question is applied by dpkg-parsechangelog on your machine when you "dpkg-buildpacakge -S". It finds the closed bugs and adds a Launchpad-Bugs-Fixed field to your .changes file. That's what Launchpad uses to close bugs.
<soren> smoser: So, you could remove that field from your .changes, re-sign it, and upload, and you woulnd't trigger anything in Launchpad.
<soren> smoser: ...but since the bugs are already closed, it'll be a no-op anyway.
<smoser> ah. thanks.
<seb128> soren, mdz, kees, cjwatson: do you read the techboard list? is there anything I need to get replies from tb members on the SRU emails? only pitti and mark replied so far
<seb128> the meeting this week seems to have not been happening as well ... should I try to add an agenda item for the next meeting?
<Laney> I also saw that the TB meeting didn't happen, and someone said that there was nothing on the agenda. Somehow those topics from the mailing list probably should have made it there, probably?
<seb128> Laney, ;-)
<Laney> :P
<seb128> the techboard seems not very functional atm :-(
<Laney> stgraber: ^ too
<kees> seb128: reading now...
<cjwatson> seb128: oh, yeah, sorry about that - I've replied now
<seb128> kees, don't take it wrong, but are you subscribed to the list? important issues getting ignored over weeks by most tb members don't seem a good situation, I'm wondering what went wrong there
<seb128> cjwatson, thanks
<kees> seb128: I don't have a good habit of reading the list.
<kees> seb128: I'll re-arrange my filters to help
<seb128> kees, was that the wrong way to raise those issues?
<seb128> kees, I really though those items would get on the next week agenda if not addressed on the list
<kees> seb128: normally if you want something discussed at the meeting, it needs to get added to the wiki page by the interested party.
<seb128> kees, cjwatson: as an outsider the experience is pretty disappointing to see the list ignored and the meeting to go "no topic, no need to have a meeting"
<seb128> kees, ok, thanks, I will do that for the next meeting in 2 weeks if those issues are still stalled
<cjwatson> One of the standing items on our agenda is to review the list, so it's an oversight if that didn't happen
<cjwatson> Unfortunately due to the foundations sprint this week I missed this week's meeting
<tjaalton> are there 12.04.1 installer builds available yet?
<seb128> cjwatson, kees: thanks for the replies ;-)
<kees> seb128: np. I'll get future stuff into my inbox directly now. :)
<seb128> kees, great ;-)
<cjwatson> It does go into my inbox already, but so does way too much other stuff :-(
<Laney> can someone moderate seb128's mail that kees replied to?
<seb128> SpamapS, RAOF, bdmurray, slangasek (i.e SRU team): https://lists.ubuntu.com/archives/technical-board/2012-June/001300.html
<stgraber> tjaalton: we have daily builds on cdimage.ubuntu.com/precise
<tjaalton> stgraber: I only see the release image there
<tjaalton> oh wait
<tjaalton> wrong dir, got it now
<tjaalton> thanks
<tjaalton> stgraber: do these have packages from -proposed as well, or just -updates?
<stgraber> just -updates AFAIK
<stgraber> tjaalton: a quick grep in the cdimage branches seems to confirm that we have updates enabled but not proposed
<tjaalton> stgraber: ok
<tjaalton> there should be a new kernel in -updates soon.. need to get that tested to see if it fixes some nasty display bugs
<infinity> BenC: Gah.
<infinity> BenC: Don't use -Nubuntu1 versioning for rebuilds.
<BenC> infinity: Ah, what should I use in the future?
<infinity> BenC: Should be -Nbuild1
<jtaylor> doko: is there much point in keeping this diff: http://launchpadlibrarian.net/86710012/mpich2_1.4.1-1build1_1.4.1-1ubuntu1.diff.gz
<BenC> Ok, thanks
<jtaylor> doko: blcr is broken since natty anyway
<infinity> BenC: I just noticed because my build1 upload of libextractor was rejected because your ubuntu1 got there first. ;)
<infinity> BenC: But this means now that we need to manually watch for Debian revisions to those uploads and sync, since we don't sync over *ubuntu* versions.
<micahg> BenC: dch -R for rebuilds
<slangasek> kees: so you seem to have given us a bootstrapping problem for MREs. ;)
<BenC> infinity: sorry about that
<BenC> micahg: thanks
<infinity> BenC: I'll get over it some day. :)
<slangasek> dpkg-checkbuilddeps: Unmet build dependencies: xvfb
<slangasek> hmm, echan
<kees> slangasek: MREs were never supposed to skip SRU quality controls.
<kees> slangasek: they were created to avoid busy-work for the SRU team when there was a historical precedent (and sufficient checks in place to assure future quality) such that the SRU team didn't have to bother reviewing a given package.
<slangasek> kees: that's not my understanding of what's been proposed here
<slangasek> also, it's very hard to establish a historical precedent of successful SRUs following the existing SRU policy for these things because the scale of review involved in actually doing it by the book is too onerous
<kees> slangasek: hence my suggestion that perhaps the SRU process needs to be adjusted.
<slangasek> in the specific case of libreoffice, we do have a history of successful point release updates... natty, oneiric, precise all have point-release SRUs
<infinity> I review pretty much everything I accept, except for mozilla.org and libreoffice, and even those, I give a cursory glance.
<slangasek> are these not sufficient?
<kees> slangasek: ah, I either missed that, or it wasn't mentioned in the request.
<verwilst> kees, ping
<kees> slangasek: I think it may help to have an SRU team member speak up on behalf of MRE requests in the future, actually.
<kees> verwilst: pong
<verwilst> oh :)
<verwilst> kees, i would like to monitoring-default-off.patch :)
<verwilst> uh "talk to you about"
<slangasek> kees: so you think that it should be a judgement call of the SRU team to decide whether we should rely on upstream regression testing as sufficient verification for an SRU?
<kees> verwilst: yeah, seems to have caused problems for ivoks too
<verwilst> kees, the "activation/monitoring=0 is incompatible with clustered Volume Group "test": Skipping." i presume
<slangasek> kees: right, perhaps it didn't get mentioned... anyway, libO does have a bit of precedence here
<kees> slangasek: I think that if it makes sense for that package and Ubuntu, yes. I think there are 3 distinct situations: "single fix SRU", "upstream point release SRU", and "MRE"
<verwilst> it's not an issue on centos though, and no dmeventd running there
<kees> slangasek: and I can see how that latter two seem similar.
<micahg> slangasek: kees: there was also a failed SRU in oneiric for LibreOffice for which there is no plan to fix it, I would hope that if an MRE is granted, it's made clear that regressions do need to be addressed
<micahg> it's in -proposed, so it's not that big of a deal to drop I guess
<kees> slangasek: but the MRE, IMO, was designed more for blessing a package so it doesn't have to the SRU team doing extensive examinations.
<slangasek> kees: where is category 2 defined?
<kees> slangasek: it isn't -- it's what you've just described, and what is being discussed here.
<slangasek> ah
<kees> slangasek: there appears to be a need for "there are so many changes here, SRU team must depend on upstream to declare it okay"
<infinity> slangasek: I think kees is implying that the middle category goes through the same level of review and rigor, while we let the latter "slide".
<slangasek> https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases is what we currently have AIUI
 * kees re-reads https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<kees> hrm, yeah, I guess the "history of successful SRUs" isn't in there at all.
<verwilst> kees, i guess i'm interrupting? :)
<kees> verwilst: I'm actually reading the history of this patch now to refresh my mind...
<verwilst> oh, sweet :)
<kees> verwilst: the problem appears to be that we cannot have a requirement that dmeventd be running.
<kees> verwilst: the problem ivoks ran into seems to be that the patch accidentally makes it so you can _never_ talk to dmeventd. :P
<kees> verwilst: so, I think, solving that is what's needed here.
<kees> verwilst: does that match what you're seeing?
<verwilst> euh
<verwilst> dmeventd isnt running on my precise either
<verwilst> but vgchange --monitor y works
<kees> weird
<verwilst> if /etc/lvm/lvm.conf has monitoring=0 by default for example, shouldnt that stop lvm from talking to the mythical dmeventd as well?
<verwilst> because now it seems to ignore that setting
<herton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<verwilst> it also breaks the init script when using clustering, since i had to add --monitor y after every vgchange myself there
<kees> verwilst: right, the bug appears to be ignoring that config item.
<kees> verwilst: we need to be able to run the lvm commands without /etc/lvm/lvm.conf (in very minimal environments), so the binary default needs to stay off, but the config should be respected.
<verwilst> kees, makes sense
<verwilst> but that sounds like quite some custom coding inside lvm
<verwilst> can't your minimal env have an empty lvm.conf? :D
<kees> verwilst: it can, but it shouldn't need to, is my point. right now, the bug is that the config value isn't being respected. that's the distinct bug here, IMO.
<verwilst> true
<verwilst> kees, what would be the best way to proceed?
<verwilst> since this bug is blocking my environment, i'm more than willing to help out :)
<kees> verwilst: is https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368 the same situation?
<ubottu> Launchpad bug 833368 in resource-agents (Ubuntu) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress]
<kees> verwilst: I think ivoks has been looking at it, but trying to adjust the patch to do the right thing with regard to config settings is the next step
<kees> verwilst: so if that's the right bug, subscribe to it, and check with ivoks or SpamapS
<kees> verwilst: otherwise, open a new bug and ping SpamapS :)
<kees> verwilst: though strictly speaking, it's really slangasek's problem ultimately, so maybe check with xnox. :)
<xnox> hello people
 * xnox reading backlog
<kees> xnox: I know you're working on mdadm, but this is in lvm2. not sure if that's under your umbrella or not.
<kees> xnox: basically, the lvm2 commands aren't reading a config setting correctly, due to a patch I wrote to change things.
<kees> in a pinch, I can try to work on it, but I have no idea how soon that'll be.
<slangasek> lvm2 is, but so far the cluster stuff has been the server team's department
<kees> slangasek: it's on the fence, really, since the patch was there for udeb-ish situations, which isn't the server team's problem, etc.
<slangasek> yes it is ;)
<slangasek> rather, let's say it's a shared responsibility
<verwilst> i think that's the correct situation kees
<slangasek> scrollback is long; is there a bug ref?
<kees> https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368
<ubottu> Launchpad bug 833368 in resource-agents (Ubuntu) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress]
<verwilst> i even made 2 useless comments at the bottom ( hey, it was very late.. :P )
<kees> slangasek, verwilst: I've tried to summarize the requirements in a comment there now
<xnox> kees: slangasek: I am happy to look at that at some point. Seems to be a valid bug.
<lepagee_> Hi, I am trying to package something for launchpad, but I get "rmdir: failed to remove `obj-i686-linux-gnu': No such file or directory" on out build system. When I copy the debian dir in my project, it work fine. We use a custom build script, http://pastebin.com/5vzSVJGE Any idea what is wrong with it?
 * verwilst cheers for xnox, kees and slangasek!
<xnox> kees: slangasek: about the SRU of micro point release. I want to SRU e2fsprogs micro-release, and SRM mdadm micro-release, which I will be discussing with 12.04.1 release team meeting tomorrow.
<xnox> as those fix serious bugs, and they are purely bugfix releases.
 * xnox goes to subscribe
<slangasek> xnox, kees: it shouldn't be too high up the todo list for foundations... I'd really rather someone (e.g. ivoks) who's actually using clustered LVM2 tell us what's needed
<kees> xnox: seems like an easy one for the SRU team to +1
<kees> slangasek: yeah, agreed
<xnox> kees: I am still to prepare a reports.
<xnox> kees: I'm hoping to bump btrfs-tools with a ~2year update as an SRU, that one might be a bit tricky, but I have a case for that as well.
<xnox> lepagee_: rm -rf your friend? clean runs before build, so you should assume that everything might be clean already. Run clean twice locally and make sure it is fine.
<slangasek> backport please
<xnox> slangasek: and what shall I do with bugs that precise kernel is out-of-sync with btrfs-progs, and machines fail to boot because of that?
<slangasek> xnox: it doesn't meet SRU policy to bump btrfs-tools, no matter how un-featureful the current version is; so please use precise-backports
<slangasek> really?
<xnox> slangasek: =)))))
<xnox> slangasek: althought, it's fixables with symlinking btrfs.fsck to /bin/true as a minimal SRU, or removing it at all =)
<xnox> in precise
<slangasek> why do they need to be in sync at all?  it's not like btrfs.fsck does anything :P
 * xnox you didn't hear that ;-)
<slangasek> sigh
<xnox> slangasek: 'your filesystem has features not supported by this version of btrfs. exit 1'
<xnox> because for some bizaer reason they do?!
<verwilst> maybe the udeb scripts can use --ignoremonitoring?
<lepagee_> xnox: The script does a git checkout, this should clean everything, the problem is probably elsewhere
<xnox> slangasek: now it actually does something vague on the useful side of the fence
<slangasek> xnox: if users set pass to 0 in /etc/fstab, does the problem go away?
<xnox> slangasek: will test tomorrow now that I have 4x1TB drives to play around with stuff =)
<slangasek> xnox: because frankly I like that option much better... less work for you, and less risk of giving users the accidental impression that btrfs is something well-supported in the world (let alone in precise)
<xnox> slangasek: well have you seen ubuntu-planet http://www.jorgecastro.org/2012/06/04/playing-with-btrfs/ ?
<slangasek> xnox: heh
<slangasek> xnox: don't listen to that guy, he builds all his code with -fruit-rollups
<xnox> slangasek: both old and newer btrfs.fsck get killed with OOM on 1TB drives. latter version gets kill later than the former.
<slangasek> xnox: you're really not selling me on the value of an SRU here ;)
<xnox> slangasek: ok, I will settle for btrfs-tools backport ;-)
<micahg> xnox: only 3 rdeps, so should be easy enough
<micahg> and one of those is a meta package, so 2
<Laney> micahg: while we're on backports, I think some of Yolanda's stuff got ready
<Laney> fancy taking a look? â¦
<micahg> Laney: how are you uploading the stuff without ubuntu diff with the broken backportpackage script?
<Laney> broken?
<micahg> Laney: I can a bit a later, I have to get some stuff done today :)
<Laney> I'm running out of bzr if that makes a difference
<micahg> bug 1007042
<ubottu> Launchpad bug 1007042 in ubuntu-dev-tools (Ubuntu) "[backportpackage] errors out on packages with no ubuntu revision" [Undecided,Confirmed] https://launchpad.net/bugs/1007042
<Laney> oh, probably because I have DEBEMAIL=iain@orangesquash.org.uk when building backports usually
<verwilst> xnox, if you need help testing, a shoulder to cry on, etc about the lvm bug, let me know! :)
<xnox> verwilst: noted.
<micahg> Laney: that's one solution I suppose :), but I like to have my Ubuntu address in debian/changelog
<hallyn> does the following mean anything to anyone?
<hallyn> objcopy:debian/qemu-kvm/usr/bin/stKSZjR6: cannot create debug link section `debian/qemu-kvm-dbg/usr/lib/debug//usr/bin/qemu-x86_64': Invalid operation
<xnox> Laney: yoanda doing progress. Good, need to catch up on that.
<Laney> deps are getting there
<Laney> is the actual package nearly ready to be sponsored?
<xnox> Laney: not sure =) I have been busy looking for a house to live in. Otherwise I will be homeless on the 4th of July =)
<Laney> an interesting form of independence
<xnox> Laney: last time I spoke with yolanda, I gave a guide on plenty things to do.
<micahg> Laney: I guess no one will freak if I use a different address for a few backports
<xnox> tell me about it =)
<xnox> micahg: nope =) we know where to find you?
<Laney> micahg: A reasonable solution would be to unset DEBEMAIL when building the source package in backportpackage
<micahg> Laney: nope, then user@host is used :)
<Laney> used for what?
<micahg> it just needs to be unset for the debuild part
<Laney> the changelog is already generated then
<Laney> yes
<Laney> building the source package
<micahg> ah, that's what you meant :)
<micahg> yes, I thought I suggested that
<xnox> micahg: btw I'm having two thunderbird icons in quantal right now: a normal unity one with the badge & ugly pixelated bamf one for each window
<micahg> xnox: as chrisccoulson :)
<micahg> *ask
<xnox> chrisccoulson: ^^^ see my last message to micahg
 * xnox should really look on launchpad for a bug....
 * micahg thought he saw a report for that as well
 * xnox is tempted to finally port all of my email identities to gnus-alias and move away from thunderbird, because of that bug =)
<chrisccoulson> xnox, yes, there is already a bug on launchpad for that
<xnox> chrisccoulson: do you have a bug # or a search keyword?
 * xnox wants to subscribe to it
<xnox> bug 1012158
<ubottu> Launchpad bug 1012158 in thunderbird (Ubuntu Quantal) "Unity launcher icon now only launches TB, additional icon(s) open to control" [Undecided,Fix committed] https://launchpad.net/bugs/1012158
<xnox> found it!
<Laney> micahg: proposed a branch. Maybe give it a go when you process your next backport?
<micahg> Laney: ok
<micahg> stgraber: did that newt get away from you?
<stgraber> micahg: I know
<stgraber> micahg: I was just mentioning it in another channel
<stgraber> micahg: I need to teach dput to allow the target to be given as the last arg :)
<micahg> heh
<stgraber> anyway, it's ~ppa1 just because I wanted to make sure it builds on the buildd before uploading, the package itself is archive-ready
<stgraber> micahg: btw, you're really low latency today ;) I really just had time to see it go wrong in my shell, complain about dput in #pyjam, then saw your hilight :)
<micahg> stgraber: just happened to be looking there I guess :)
<cjwatson> Laney: techboard mail> done
<Laney> tidy
<doko> jtaylor, well, get the patch into debian
<ScottK> doko: Speaking of getting things into Debian ... how about python2.7/3.2 updates?
<Bluefoxicy> so
<Bluefoxicy> I have an idea to derive a C library from {BSD|GNU} awk that supplies a handful of functions to:
<Bluefoxicy> 1) initialize an 'awk' object from a string containing an awk script (including copying the script to its own memory space--compiling it to bytecode etc)
<Bluefoxicy> 2)  Allow the calling of awk as if it were continuously executing against a stream by passing char* strings acting as lines (or multiple lines) of a stream
<Bluefoxicy> 3)  Check the status of awk (did it terminate, i.e. by eof or exit command)
<Bluefoxicy> 4)  Destroy the awk object
<Bluefoxicy> This is all mainly irrelevant here except for one detail
<Bluefoxicy> I'm sure nobody wants to maintain a package for something called 'libcawk' so what should I call this thing?
<JontheEchidna> there does exist a "libkok" (though not in Ubuntu) http://maemo.org/packages/view/libkok/ :P
<ScottK> libobjawk
<Bluefoxicy> heh
<Bluefoxicy> ScottK has the best one I think
<Bluefoxicy> it even has the advantage that, at a glance, it's not clear what in the hell the name is supposed to mean or how you're supposed to read it :P
<ScottK> I came up with libkibi for bdrung too.
#ubuntu-devel 2012-06-14
<kees> infinity: eglibc ping :)
<infinity> kees: "I'm not ignoring you, I've just been busy" pong.
<infinity> kees: (I also have a few other things lined up for eglibc, so I'm going to make a day of it at some point)
<kees> infinity: cool; thanks :)
<infinity> ScottK: What's with the ksplosion of kthins moving to universe on component-mismatches?
<ScottK> infinity: I'd guess Kubuntu not driving stuff to Main landed.
<ScottK> That's in the plan.
<ScottK> But that's a guess.
<cjwatson> ScottK: I haven't landed that yet.
<cjwatson> Hm, it's a fair bit, but I'm not sure it's enough for that.
<micahg> cjwatson: any chance components-mismatches suddenly got smart about versions?
<cjwatson> You'd see it in lp:ubuntu-archive-tools if it had.
<infinity> micahg: "smart about versions"?
<micahg> infinity: straw grasping due to low glucose :) (the basic premise is to drop it out of main if the version doesn't satisfy something, but it doesn't make much sense)
<infinity> Oh, hallelujah, the armel GCC build finally finished...
<infinity> I wonder how that took 13 hours longer than armhf...
<ScottK> infinity: Then I'll go with KDE is half 4.8.3 and half 4.8.80 or 90 and stuff is confused.
<infinity> ScottK: Yeah, that's possible.  I'm certainly not knee-jerk demoting anything tonight.
<infinity> I know some AAs are a bit more militant about just demoting everything on the list, but hopefully everyone will take pause at the size of the list and not do so. :P
<infinity> Cause it's annoying to have to promote half of it the next day...
<micahg> BenC: did you test scilab on i386?
<BenC> I did, but I don't think it rebuilt configure like it was supposed to
<micahg> ah, ok, I was waiting for the diff, but saw the failure first
<BenC> scilab was FTBFS on everything !amd64 already, so it's def not a regression :)
<micahg> right :), but that's the same thing that happened when the last person sync'd :)
<BenC> I'll refix it
<micahg> BenC: thanks
 * infinity fixes calligra...
<infinity> Mostly because it's annoying me that it's blowing up quantal_probs...
<BenC> I wonder if anything else can brag about 3Gigs of installed size for it's build-deps
 * BenC tips his hat to sdcc
<StevenK> BenC: Libreoffice? :-)
<mwhudson> that did seem the obvious suggestion
<StevenK> Build-Depends: all of main. At once.
<BenC> byte of source to byte of build-dep, I suspect sdcc wins this one though :)
<infinity> BenC: Making build-indep only get run as a dependency of binary-indep means it all happens under (fake)root.
<infinity> BenC: Not a huge issue, I suppose, since we use fakeroot and not real root, but not ideal.
<BenC> infinity: Hence the reason I said, "not ideal"
<BenC> But it was a toss up of "force the buildd's to install 3Gig of build-deps" or "generate docs as (fake)root on i386 only"
<BenC> I may be biased in that I didn't want the ppc buildd's to install all those damn build-deps :)
<infinity> There's a theory some day that dpkg-buildpackage -B will eventually change to call "clean ; build-foo ; binary-foo", but that's going to require a critical mass of packages in the archive actually supporting separate build-{arch,indep} targets. :/
<infinity> Since suddenly making half the world RC buggy is unpleasant.
<BenC> I was under the impression that this was already the caseâ¦it's really odd to me that I don't remember this class of FTBFS being a major issue until now
<infinity> -B has always done "build ; binary-arch"
<BenC> At least, all the packages I create have "build: build-arch build-indep" :)
<infinity> And -b does "build ; binary"
<BenC> All these years, Build-Depends-Indep was just tease
<infinity> This class of FTBFS almost never shows up in Debian because arch:all packages are built on maintainer machines, so no one ever bothers to test if they fail when built in a pristine environment.
<BenC> That's the thing, this is causing failures when not building with arch: all as a target
<infinity> Oh, hah.
<BenC> I would have thought it would show up in Debian too
<infinity> Yeah, that also is a uniquely Debian build failure. ;)
<infinity> Because, again, it will work for the maintainer.
<infinity> And he'll ignore the buildds failing, cause hey, his works.
<BenC> Right, so the maintainer will keep saying "but it's under build-indep"
<BenC> Damn social problems
<infinity> Actually, hrm.  Debian may have switched.
 * infinity wonders if his pending dpkg merge will change this...
 * infinity sees a "debian/rules build-arch" in a Debian build log.
<BenC> Does Debian install Build-Depends-Indep on all builds?
<infinity> BenC: If you're running into more of these, you might want to hold off for a bit.
<infinity> BenC: No, BDI is never installed on Debian buildds (since none of them build arch:all)
<infinity> BenC: But if you check the logs for sdcc on sid, they show a call to build-arch.
<BenC> infinity: Unfortunately, most of the ones I've seen are causing a slew of dep-wait and other FTBFS, so the cascade of fixing it does makes me impatient :)
<infinity> BenC: So maybe this changed VERY recently in dpkd.
<infinity> dpkg*
<infinity> BenC: Well, I'm merging dpkg tomorrow.  Let me look right now to see if this behaviour will be changed by that.
<BenC> Ok
<micahg> \o/ new dpkg will solve a few more depwaits :)
<BenC> I don't know of any others right now, but if I see any, I'll note them for rebuild later
<infinity>   * Update dpkg-buildpackage to use the "build-arch" (for -B) and
<infinity>     "build-indep" (for -A) targets unless "make -qn" says that they do not
<infinity>     exist. Closes: #229357
<infinity> BenC: Yeah, looks like my merge will let you stop doing these fixes.
<BenC> Ah, that's great fix
<infinity> I like the age of the bug that closed.
<infinity> Not 5-digit, but still back a bit.
<BenC> 8 year old bugs...
<infinity> Hey, this is why I'm against auto-expiry of bugs.  "We'll get to it eventually..."
<BenC> I may have still been in the Uploaders list back then
 * micahg still loves how powerpc is doing better than i386 ATM
<infinity> Give me to the end of the week to resolve that oversight. :P
<micahg> a new dpkg and debhelper would probably tip the scales
<infinity> Is our dh lagging too?
<infinity> That's a much easier merge.
<micahg> yes, --extreme or something like that
<infinity> dpkg is pain.
<BenC> I dunnoâ¦if you can dislodge all the ppc dep-waits, I think I can keep up :)
<infinity> micahg: No, that's dpkg.
<infinity> micahg: That's just passed unfiltered to dpkg-deb.
<infinity> BenC: If ross wasn't unhelpfully sitting at a yaboot prompt without a keyboard or serial console attached, PPC might be a bit happier. :/
<BenC> No wonder I keep getting "Build will start in 39182913 hours, you tool"
<micahg> infinity: hrm, http://packages.debian.org/changelogs/pool/main/d/debhelper/current/changelog#version9.20120513, http://packages.debian.org/changelogs/pool/main/f/fonts-aoyagi-soseki/current/changelog, people seem to be doing this slightly backwards
<BenC> infinity: pay someone to walk over to it with a usb keyboard
<StevenK> Hah, USB keyboard on a Xserve
<BenC> Please tell me it doesn't use an ADB port
<micahg> hehe, ADB port, now I'm getting nostalgic
<infinity> micahg: Well, merging debhelper too won't hurt.
<infinity> micahg: And gets the default udeb compression for free.
<BenC> shaweet, scilab built on something != amd64
<infinity> BenC: Pretty sure there's no ADB bus on any G5 system. :P
<micahg> BenC: awesome, now let's see if sylvestre takes the patch :)
<BenC> ccvjbsmt.s:285077: Error: operand out of range (0x0000000000008000 is not between 0xffffffffffff8000 and 0x0000000000007fff)
<BenC> My math may be a little rusty, but I suspect that error is incorrect
<infinity> BenC: Heh.
<BenC> At the same time, I suspect half a million lines of assembly would confuse the best assembler
<BenC> Bug #1012976
<ubottu> Launchpad bug 1012976 in spatialite (Ubuntu) "FTBFS: PowerPC build fails choking on half a million lines of assembly" [Undecided,New] https://launchpad.net/bugs/1012976
<pitti> Good morning
<pitti> slangasek: changelogs.u.c.> functionally that's mvo's, but out of disk is RT matter
<pitti> yay for python3-ified aptdaemon!
<glatzor> morning pitti and slangasek
<pitti> hey glatzor
<glatzor> pitti, may I ask you about the status of the aptdaemon/packagekit plugins? They are already available for Python 3?
<pitti> glatzor: I'm porting ubuntu-drivers-common as we speak
<pitti> glatzor: and language-selector is also on my list today
<pitti> glatzor: I don't know about the software-center plugin
<glatzor> great news.
<pitti> do we have others?
<pitti> glatzor: aptdaemon now landed, this blocked pretty much else on my list before :)
<glatzor> I am not aware of any further plugins.
<glatzor> pitti, I just wrote an email to slangasek that I am ok with an upload :)
 * glatzor seems to be late
<glatzor> Thanks for the upload slangasek
<pitti> glatzor: argh, seems we missed some bits
<pitti> /usr/share/aptdaemon/tests/fake-polkitd.py
<pitti> #!/usr/bin/env python
<pitti> that's causing test failures
<pitti> oh, I see that all scripts except gtk3-demo.py stil run with "env python" in trunk
<pitti> glatzor: so I guess the package converts those?
<glatzor> pitti, hm. but the fake-polkitd should still work if python 2 is installed. have you already remove python2 completely from your disk?
<pitti> glatzor: it works fine in my normal system, but u-d-common shows ImportErrors when building in a pbuilder
<pitti> glatzor: the pbuilder doesn't have python-dbus, only the python3-dbus build dep
<pitti> curiously even the fake polkitd keeps all tests succeeding
<pitti> it seems aptdaemon doesn't actually query polkit, or ignores if it's not there
<pitti> so I think we can ignore that for now
<glatzor> pitti, I used the demo scripts to test the python 2 interaction since at the python 3 port release time update-manager, s-c and friends would still be python 2 based
<glatzor> pitti, Hm. I will have a look at the policykit thing
<pitti> glatzor: if it becomes a problem, I'll just add (temporarily) a python-dbus build dep
<glatzor> pitti, without a working or always denying fake-polkitd the test suites hangs here
<pitti> let's see how it behaves on the buildds, but it worked fine in my pbuilder
<pitti> glatzor: so perhaps a workaround would be to start the fake polkit like Popen([sys.executable, 'fake-polkit.py', ...], ...) ?
<pitti> in aptdaemon.test
<pitti> so that it always runs with the same python version as your test
<slangasek> pitti: yes, I was asking about the implementation because I think we should be garbage-collecting some of these changelogs... instead of letting them accumulate without limit
<glatzor> pitti, I just replaced the shebang in trunk
<slangasek> why would we need to keep changelogs around indefinitely?
 * slangasek waves to glatzor - you're welcome :)
<pitti> glatzor: wouldn't that cause the opposite problem then?
<slangasek> glatzor: and thank you for doing all the hard work on the port
 * pitti moves python3-xkit to main, to relieve u-d-common from its depwait
<pitti> slangasek: changelogs> indeed; they are still on LP for the historians
<pitti> cjwatson: I pushed your language-selector py3 branch to lp:~ubuntu-core-dev/ubuntu/quantal/language-selector/python
<pitti> cjwatson: so that we can work on it together
<micahg> fun, colliding meta uploads :)
<pitti> micahg: urgh, did you update it as well? sorry about that
<pitti> fun, I've never seen that happen before in 8 years
<micahg> pitti: no, but slangasek did after you, I'm surprised how that worked
<pitti> I uploaded 1.272, slangasek 1.273
<micahg> right, but they're the exact same changelog
<pitti> with exactly the same changelog
<pitti> slangasek: so it seems we both had exactly the same idea at the same time? so it must be good!
<pitti> cjwatson: err, I mean lp:~ubuntu-core-dev/ubuntu/quantal/language-selector/python3
<pitti> cjwatson: (i. e. the changed branch name in the blueprint work items is correct)
<pitti> cjwatson: now the test suite works with python3 (except test_package_lists_good, which has failed for years; but as this part, just like most of language-selector, is being deprecated, I don't bother much)
<dholbach> good morning
<pitti> glatzor: when I run language-selector with Python 3, I get
<pitti> TypeError: update() takes exactly 2 arguments (1 given)
<pitti> Error in function update
<pitti> glatzor: is that something that rings a bell to you? it's not something I do in language-selector itself
<pitti> /usr/lib/pyshared/python2.7/apt_pkg.so contains "Error in function", anyway
<pitti> glatzor: nevermind; apparently apt.progress.base.OpProgress.update() now gets called with one argument sometimes (not in python2); I added support for this and pulse() the progress bar in that case
<glatzor> pitti, sorry I was away
<glatzor> pitti, right there is now an optional argument
<pitti> cjwatson: I tested PYTHONPATH=. python3 ./gnome-language-selector fairly well now, seems to work fine
<pitti> cjwatson: so I'll switch the whole thing to #! python3 and merge
<verwilst> hm, precise has a 2-year old lvm2 package, i wonder why it hasn't been upgraded for the LTS
<pitti> cjwatson: uploaded l-s now; thanks for your porting work!
<pitti> gnagh, dear debhelper, stop calling setup.py through "python" explicitly
<cjwatson> pitti: wow, that was quick, thanks
<cjwatson> pitti: debhelper needs to do that, surely
<pitti> cjwatson: yeah, it's nice to have a package that doesn't need millions of bytes-> str conversions for a change :)
<cjwatson> I mean, aside from its general lack of python3 support
<pitti> cjwatson: yeah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597105 all over again
<ubottu> Debian bug 597105 in debhelper "add support to build python3-* packages" [Wishlist,Open]
<pitti> I did that for a number of other packages, I'm mostly just grumbling because I keep falling into that trap
<cjwatson> but it needs to be called for each supported interpreter, and IIRC it needs to be called with python rather than python2.7 or #! lines come out wrong ...
<pitti> cjwatson: btw, you ignore jockey on the py3 sprint, right?
<cjwatson> pitti: Yeah
<cjwatson> More didn't even consider it because there was so much else ;-)
<cjwatson> mvo: Thanks for the command-not-found merge.  Shall I roll a new Ubuntu package?  How do you pick version numbers, as setup.py seems to be out of date?
<cjwatson> mvo: And do you by any chance have an opinion on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656288?
<ubottu> Debian bug 656288 in python3-apt "python3-apt: difficulties with non-UTF-8-encoded TagFiles" [Normal,Open]
<xnox> verwilst: we didn't get around to updating lvm2 in time. It is updated in quantal.
<pitti> cjwatson: so it seems this is really going well, great! the two biggest things that worry me are ubuntuone and system-config-printer
<cjwatson> (Scroll to the end, I think)
<pitti> xnox: good morning
<xnox> pitti: that's for pushing u-d-c =)
<pitti> xnox: thanks for your work there; I mopped up the remaining bits, and uploaded now; I had a quick discussion with glatzor about the "import dbus" failure from the fake polkit, but it doesn't hurt for now
<xnox> pitti: yeap, I reread on irclogs.ubuntu.com ;-)
<seb128> pitti, is it worth spending time porting system-config-printer if we plan to deprecate it?
<seb128> pitti, well, we will still need the service, but the ui part might be not worth spending time on it
<pitti> seb128: right, that's what I meant
<pitti> we at least need to port the bckend
<pitti> seb128: it seems Fedora is going py3 as well, so maybe it even already happened; I don't know
<pitti> I wouldn't worry about the frontend, and rather spend the time helping Lars with fixing the GNOME frontend enough
<seb128> right
<seb128> though I doubt Lars will have any time for that this cycle
<seb128> but we will change before the next LTS for sure
<pitti> well, if we don't switch this cycle, we'd have to port the GUI to py3 as well, which seems like a waste? I thought the GUI was already very close
<pitti> seb128: I thought GNOME upstream's printer panel would already talk to s-c-p, doesn't it?
<seb128> pitti, it does
<pitti> nice
<mvo> cjwatson: I can do a new version but either way is fine, I had hoped that rookery is fixed so that we get updated command-not-found data for quantal with the new release too
<doko> didrocks, online?
<didrocks> doko: yes
<seb128> doko, infinity: do you have an idea if bug #1007588 could be a toolchain issue? not sure what those @plt are, but the code didn't change since precise (out of being rebuilt with the new toolchain) and the segfaults don't happen when building with gcc-4.6
<ubottu> Launchpad bug 1007588 in gnome-settings-daemon (Ubuntu) "[mouse]: gnome-settings-daemon SIGSEGV in gdk_device_manager_list_devices@plt()" [High,Confirmed] https://launchpad.net/bugs/1007588
<hrw> hi
<hrw> can someone tell me how to specify two arches in apt sources.list for one repo? for one arch it is simple: "deb [arch=armel] http://repo" but tried "[arch=amd64,i386]" and it still tries to find armel there
<hrw> ok, [arch=amd64 arch=i386] looks like working
<hrw> chrisccoulson: do you have plans to provide quantal packages for thunderbird-next ppa?
<cjwatson> mvo: I hadn't seen much sign of rapid movement on getting rookery fixed ...
<hrw> nope, only solution is duplication of lines ;(
<hrw> ogra_: do you know why ddebs.ubuntu.com does not have armel/armhf ddebs for quantal?
<doko> mvo, online?
<mvo> doko: yes
<seb128> doko, hey, did you see my ping before?
<seb128> doko, should we just build gnome-settings-daemon with gcc-4.6?
<doko> seb128, no, didn't look yet
<seb128> doko, let me know if,when you have some time to look at it, that's hitting quite some quantal users
<chrisccoulson> seb128, ooh, that bug looks interesting ;)
<seb128> chrisccoulson, lol, you like toolchain issues right? ;-)
<chrisccoulson> lol
<chrisccoulson> "like" is a bit of a strong word ;)
<seb128> chrisccoulson, do you want to have a look to it?
<chrisccoulson> seb128, sure, i don't mind
<seb128> chrisccoulson, thanks!
<verwilst> xnox, , i guess an upgrade of lvm2 will never be allowed in precise? :)
<xnox> verwilst: i have enquired about that and the conclusion is that no precise will stay at it's current revision as it's too high of a jump and we do not have sufficient regression testing in place to catch unforeseen problems. A backport on the other hand....
<Bluefoxicy> buh.  Ejecting the kindle from Ubuntu doesn't make it drop out of USB drive mode and charge while in use
<xnox> verwilst: individual bugs, can and should be fixed/lumped together in an SRU
<Bluefoxicy> I think because it ejects /dev/sdc1 but not /dev/sdc?
<verwilst> xnox, a backport of that one patch the redhat guy mentioned?
<Bluefoxicy> that should be looked into
<Bluefoxicy> if you hit 'eject' and nothing on that device is mounted after unmounting, eject the base device itself
<Bluefoxicy> (I just manually ejected /dev/sdc, kindle data is /dev/sdc1; it worked)
<Bluefoxicy> bleh I'll file a bug after work.
<xnox> verwilst: the whole thing. Plus quntal is at .88, so it needs to be fixed in quantal. Debian is at .95 so it should/does affect debian as well.
<xnox> verwilst: .96 just got released.
<verwilst> i guess quantal can just get an upgrade to .96
<xnox> Bluefoxicy: unless you want to repartition the drive. or connected to the yellow always on port....
<Bluefoxicy> yellow always on port?
<Bluefoxicy> xnox:  this could be serious you know :P
<Bluefoxicy> what if you're using a (moron-developed) USB hard drive that expects a proper eject command to know to flush cache?
 * Bluefoxicy jumping jacks on tatami, then goes to work.
<Bluefoxicy> (I'd imagine a well-designed external drive will flush cache as soon as nothing else is going on, and immediately park the heads awaiting power drop, rather than needing commands for all this)
<pitti> jibel: I so love the adt tests
<pitti> jibel: that upower regression detected an actual bug
<scarneiro> exit
<scarneiro> exit
<jibel> pitti, Great. If only cloning VMs concurrently could be reliable. I'll spend some time on it tomorrow.
<Daviey> jibel: How are you currently cloning ?
<Daviey> jibel: if you have a consistent base image, and want lots of duplicates.. using qemu to create an image with a 'backing' image might be wise...
<jibel> Daviey, with vm-clone from vm-tools which uses kpartx but sometimes it doesn't find the loopback devices
<Daviey> jibel: qemu-img create -f qcow2 -b base.img test-runner.img .. might be what you want?
<jibel> Daviey, yes but then I must change the config inside the VM hence the use of kpartx
<Daviey> jibel: If you can add cloud-init to the image, you can use that 'stanalone' without a metadata service.. it's quite a gentlemanly way of injecting arbitrary code.
<Daviey> (create an iso image, which is attached to the machine, and cloud-init reads from there)
<Daviey> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/nocloud/README
<jibel> Daviey, nice. That looks like a solution. I'll try it. Thanks!
<Daviey> super
<ogra_> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogra_
 * dholbach hugs ogra_
<dholbach> ogra_, lots to choose from :)
<ogra_> :)
<pitti> seb128: I updated the test case on bug 984944, FYI; it's working for me here
<ubottu> Launchpad bug 984944 in apport (Ubuntu Precise) "Reject crashes that happen right after upgrade" [Medium,Fix committed] https://launchpad.net/bugs/984944
<seb128> pitti, thanks, I will give it a try it a bit
<pitti> but right now I only tested on quantal
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogra_, mterry
 * dholbach hugs mterry
<mterry> ogra_, ah hello!  You're piloting too?  In the interest of avoiding the ones you're looking at, should I look at the bottom or top of the sponsor report?
<mterry> dholbach, morning (for me)!
<ogra_> mterry, i started in the middle :)
<ogra_> (bottom of yellow)
<ogra_> planned to work upwards through it
<mterry> ogra_, heh, OK.  I'll do some of the newer ones at the bottom then
<cjwatson> juliank: Do you have any thoughts on my latest patch sent to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656288 ?  I'd really like to unblock this.
<ubottu> Debian bug 656288 in python3-apt "python3-apt: difficulties with non-UTF-8-encoded TagFiles" [Normal,Open]
<juliank> cjwatson: I'll comment on that later. I have to go now.
<ScottK> bryceh: It looks like xdiagnose is getting called to run in python3 now and 'bad' things happen.  See Bug #1013171 .
<ubottu> Launchpad bug 1013171 in xdiagnose (Ubuntu Quantal) "xdiagnose run in python3, but not ported" [Critical,Confirmed] https://launchpad.net/bugs/1013171
<xnox> ScottK: it has been ported.... during python jam monday->wednesday
<xnox> ogra_: ^^^ bug 1013171
<ubottu> Launchpad bug 1013171 in xdiagnose (Ubuntu Quantal) "xdiagnose run in python3, but not ported" [Critical,Confirmed] https://launchpad.net/bugs/1013171
<ScottK> xnox: Something's gone awry then because those are python print statements in that bug, not python3.
<ogra_> xnox, oooh, thanks !
<ScottK> xnox: Actually it looks like the update isn't uploaded as the current package is weeks old
<ogra_> thats not the ported version
 * ScottK isn't sure why it's getting run in python3, but it is.
<ogra_> (note that part of the porting is to wrap brackets around all print stanzas)
<ScottK> Multiple dupes too.
<ScottK> Yep.
<ogra_> i'm pretty sure the ported code wasnt merged yet
<xnox> ScottK: is update-manager calling that or aptdaemon or something like that?
<ScottK> No idea.
 * ScottK hasn't been following it until his ubuntu bug mailbox started filling up this morning.
 * ogra_ added the branch to the bug and the bug to the changelog ... should be fixed once the merge is uploaded
<ogra_> ScottK, ^^^
<ScottK> ogra_: Thanks.  It'd be good to get it done since it's hitting multiple people.
<ogra_> yeap, bryceh knows about the branch, i guess he will merge and upload asap
<ogra_> ogasawara, hmm, just looking at bug 183076 ... seems your fix is upstream since ages and also in all supported releases, how about closing the bug so it drops of the patches list :)
<ubottu> Launchpad bug 183076 in tsclient (Ubuntu) ""enable bitmap caching" option in tsclient doesn't work properly" [Undecided,Confirmed] https://launchpad.net/bugs/183076
<ogasawara> whoa, 2008
<ogra_> :)
<ogasawara> ogasawara: I'll close it
<ogasawara> bah
<ogasawara> ogra_: ^^
<ogra_> great
 * ogra_ giggles
<ogasawara> ogra_: now I fully understand how I steal your pings
<ogra_> hehe
<cjwatson> ScottK,ogra_,pitti: Doesn't the presence of /usr/share/python3/runtime.d/apport.rtupdate suddenly mean that all apport hooks are required to be Python 3-compatible?
<cjwatson> xdiagnose is very far from unique.
<ScottK> That sounds reasonble.
<pitti> cjwatson: by and large, yes
<ogra_> oh, indeed
<pitti> as the GUI is now running as py3
<pitti> s/as/with/
<cjwatson> So isn't this going to require about a bazillion Breaks?
<hyperair> RAOF: ping
<cjwatson> I mean, I understand it, but it'll all need to be exhaustively handled
<xnox> emergency porting all apport hooks to python3?
<seb128> cjwatson, pitti: change the hooks dir to avoid the breaks?
<seb128> it will just reduce the debug infos for a bit
<seb128> but at least it will not trigger reports
<seb128> like version it "3" or something?
<pitti> I don't like changing the hooks dir; it should not be rocket science to fix the few hooks that we have that aren't already workign with py3 anyway to work with both 2 and 3
<cjwatson> Few?
<cjwatson> http://paste.ubuntu.com/1040874/
<cjwatson> A lot of those are symlinks to source_xorg, I guess
<seb128> yes, I was going to say
<cjwatson> But I do think we'll need the Breaks, otherwise we'll get mid-upgrade reports
<cjwatson> And possibly crashes
<pitti> right, most of them are symlinks to source_xorg.py; that's the primary one that we need to fix
<pitti> crashes/
<ogra_> that is fixed
<pitti> ?
<ogra_> i ported xdiagnose the last days
<cjwatson> There're others there though, network-manager, udisks, ...
<cjwatson> ogra_: xdiagnose != xorg
 * cjwatson fixes ogra_'s lexer to go past the first character :-)
<pitti> xdiagnose: /usr/share/apport/package-hooks/source_xorg.py
<pitti> I guess ogra meant that?
<ogra_> right :)
<pitti> python3 /usr/share/apport/package-hooks/source_xorg.py fails, though (print statement)
<ogra_> i fought with that file enough the last days ;)
<ogra_> pitti, because my port isnt merged yet
<pitti> ah
<ogra_> i linked it to the bug
<ogra_> xdialog just needs the merge and an upload and will be fixed, though i think cjwatson is right being worried about other hooks, we should make a lot of noise to get people moving imho
<cjwatson> Huh
<cjwatson> ogra_: Fair enough, sorry, failed to run dpkg -S
<dholbach> cjwatson, if you could publish the fix that might help in a lot of other cases :-P
 * cjwatson fixes his own parser to not suck
<cjwatson> There are also some that won't show up in a current grep but that were fixed after precise
<cjwatson> For example source_grub2.py is only py3-compatible in quantal, not precise
<ogra_> well, but in precise apport doesnt default to py3, does it ?
<pitti> ITHM on upgrades
<ogra_> ah, k
<pitti> i. e. if you upgrade to quantal, and apport gets upgraded before, say, grub2
<pitti> then package install failures of grub2 woudln't have the infos from teh package hook
<seb128> should we SRU python3 compat fixes for hooks for packages we upload to precise for other reasons?
<pitti> fortunately the hook info does not seem all that relevant for package installation failures in most cases
<seb128> i.e I wouldn't do a SRU only to fix a hook to be python3 compatible
<pitti> most of them are for manual bug reports, and some for crashes
<seb128> but we can probably include those in uploads
<pitti> grub2 might be the very exception to this, of course
<pitti> udisks hook fix uploaded, udisks2 hook fix committed to git
<pitti> cjwatson, seb128 ^ FYI
<seb128> pitti, thanks
<pitti> chrisccoulson: can you please fix python3 /usr/share/apport/package-hooks/source_firefox.py ?
<cjwatson> pitti: Maybe apport should just catch SyntaxError in hooks and downgrade that to some kind of warning.
<pitti> cjwatson: apport itself never crashes on bad hooks
<cjwatson> Oh, but this bug is about running py3compile over the source directory, so that's not applicable.
<pitti> it just shows the exception on stderr for debugging and goes on
<cjwatson> OK.
<pitti> it's external code, I assume the worst :)
<xnox> ogra_: thanks for sponsorship! =)
 * ogra_ tips his pilot cap 
<xnox> ogra_: you didn't mark the whole proposal as merged, but I did now =)
<ogra_> oh, sorry
<pitti> chrisccoulson: http://paste.ubuntu.com/1040950/ shoudl be the bulk of the fixes, but I'm not quite sure how your ExtensionINIParserIter parser works (it fails there)
<chrisccoulson> pitti, i'll have a look in a bit. and this has changed quite a lot recently as well (but it's not in the archive yet)
<chrisccoulson> pitti, i also need to maintain compatibility with the current python :)
<pitti> chrisccoulson: yes, my pastebin patch works with both
<chrisccoulson> ah, ok. thanks!
<chrisccoulson> i'll apply it in a bit :)
<pitti> chrisccoulson: thanks; NB that it's not sufficient
<pitti> chrisccoulson: please use http://paste.ubuntu.com/1040952/ rather, debug output looks nicer with that
<chrisccoulson> pitti, sure, thanks
<zul> bdmurray: ping
<bdmurray> zul: hi, done sprinting and looking at the queue now
<zul> bdmurray: thanks
<stokachu> stgraber: hi, could you take a look at http://pad.lv/951343 for possible sponsorship
<ubottu> Launchpad bug 951343 in nss-pam-ldapd (Ubuntu Precise) "authentication fails silently with long pam_authz_search filter" [Medium,In progress]
<hallyn> lool: slangasek: hey, I want to test whether qemu-common from a newly merged (not yet pushed) qemu-kvm-1.1 would break qemu-linaro.  is there a testsuite i can use?
<slangasek> hallyn: not to my knowledge
<xnox> slangasek: I remember you mention that lvm .88  was the 'recommended' version of lvm to use
<xnox> debian is now on .95, and upstream released .96
<slangasek> xnox: at the time, .88 was /a/ version that upstream had blessed for use; but things have moved on since then
<hallyn> slangasek: is there some small .img i can wget and use under qemu-arm as a test?
<xnox> are there stability criteria for lvm.
<xnox> slangasek: hmm. ok
<dobey> stgraber, pitti: want to moderate my reply mail to technical-board through? :)
<slangasek> hallyn: I don't know one offhand, sorry
<hallyn> slangasek: ok, thanks.
<slangasek> hallyn: I mean, between Linaro and Ubuntu there should be several... but if you're meaning to test qemu-system, you need an image for a supported subarch, which is probably only beagle at this point
<hallyn> perhaps the thing to do is drop by #linaro and ask if anyone cares to test with a version in my ppa :)
<hallyn> thanks
<stgraber> dobey: don't have moderation rights, sorry.
<stgraber> cjwatson: ^
<cjwatson> uh, why not
<dobey> oh. thanks
<cjwatson> stgraber: you have /msg
<lool> hallyn: I dont know a testsuite either; you can create QEMU images from Linaro images with linaro-image-tools
<stgraber> dobey: done
<hallyn> stgraber: all of the removal of apparmor policies for lxc was meant to NOT be done in lxc.postrm anymore right?
<hallyn> lool: ok will try, thanks (saw a few urls describing that)
<alexbligh1> What would be the easiest way of automatically building Lucid & Precise installation media with the security updates already applied?
<alexbligh1> (specifically amd64 server)
<hallyn> lool: seemed to boot up fine.  Terminal worked.  Terminal on vnc connection didn't seem to accept input, but mirrored the other output.  (don't know if that's normal)
<ogra_> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<SpamapS> Hrm.. shouldn't we have an 'update-vcs' the same way we have 'update-maintainer' ?
<ScottK> First we should have a policy decision on if we want to replace Debian VCS info or just add Ubuntu info too.
<SpamapS> ScottK: right, like the XFOO-Original-Maintainer
<ScottK> Yes.
<SpamapS> having screwed up the apport upload the other day
<SpamapS> I want to make sure UDD and Vcs-* play nice :-P
<cjwatson> ScottK: I thought we had a policy decision on that years ago.
 * cjwatson hunts.
<ScottK> Dunno?
<cjwatson> Thread starting https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023332.html
<cjwatson> Which agreed on XS-Debian-Vcs-*
<ScottK> OK.
<ScottK> That's about two months after I started doing Ubuntu development, so no wonder I don't remember.
<SpamapS> slangasek: Hey I'm going to fix bug 794082 and do the cron merge (you are TIL) ok?
<ubottu> Launchpad bug 794082 in cron (Ubuntu) "cron ignores /etc/default/cron" [Undecided,Confirmed] https://launchpad.net/bugs/794082
<xnox> cjwatson: does the archive consistently override that? or is it manual job?
<xnox> cjwatson: update-maintainer should probably do that, unless it points to launchpad with *ubuntu* somewhere in the url
<cjwatson> xnox: Binary packages are consistently overridden.  Sources are only overridden if we've changed them.
<cjwatson> (XSBC-Original-Maintainer, that is.
<cjwatson> )
<cjwatson> We don't override Vcs-* at all at the moment.  I'm not clear whether we should or could.
<xnox> hmmm =/
<cjwatson> Not actually massively wild about more hacks to override bits of Sources, TBH
<cjwatson> If we don't have to
<xnox> =)
<xnox> yeah, you'd think that you could do a blancket lp:ubuntu/package..... if all of them were realibly up to date, and used by all teams
 * xnox grumbles something unintelligent
<SpamapS> cjwatson: the only reason I think we might want to is that its now impossible to actually know where the Vcs is in Ubuntu... one must check Vcs-*, and lp:ubuntu/foo
<ScottK> SpamapS: If there's an Ubuntu Vcs-* then you know.
<SpamapS> It is inferrable..
<SpamapS> but its damn unclear
<SpamapS> I'm > 2 years into UDD and I only just now learned that some teams still use distinct Vcs branches. Up until now, I had not encountered that.
<ScottK> I'm > 2 years into ignoring UDD and I can't imagine how you didn't know that.
<SpamapS> Basically I don't think any server packages use it
<SpamapS> and it seems very few foundational packages do either
<SpamapS> meanwhile, I started with Ubuntu dev with UDD
<SpamapS> so, I always start with 'bzr branch ubuntu:..'
<SpamapS> never debcheckout
<SpamapS> never apt-get source
<SpamapS> unless the branch is brorked
<dobey> thanks stan
<dobey> err
<dobey> stgraber: ^^ thanks
<seb128> SpamapS, I would say that most packages which are actively maintained are not using UDD in Ubuntu...
<smoser> seb128, thats an interesting thought. i have had difference experience.
<smoser> the only times i don't use it are when the branches are borked (which, unfortunately, seems too often).
<seb128> smoser, well none of the desktop packages are maintained in UDD
<seb128> smoser, I'm guessing from ScottK's comment that kubuntu is not using UDD either
<ScottK> No.
<ScottK> We have our own /debian only branches.
<xnox> seb128: not UDD but lp:~ubuntu-desktop-team/package/ubuntu ?
<xnox> seb128: not UDD but lp:~ubuntu-desktop-team/package/quantal?
<SpamapS> Right, so the desktop side of the house, which I think has a lot more Ubuntu delta than server side, is rejecting UDD
<seb128> xnox, yes, debian only vcses
<seb128> xnox, lp:~ubuntu-desktop/source/ubuntu
<xnox> yeah, so with bzr and correct Vcs-* headers
<seb128> yes
<xnox> not with apt-get source
<SpamapS> Its something that needs to be really clear in the UDD manuals
<seb128> but with debian only vcs-es
<SpamapS> "This is not a given"
<seb128> yeah, that's creating lot of confusions for contributors :-(
 * xnox somehow has a notion that UDD is bzr regardless of which branch it actually is. As ~ubuntu-desktop predates UDD package importer.
<ScottK> Personally, I think that UDD is great just by virtue of the ubuntu: branch getting created/updated for each upload much of the inherent value is provided without me actually using it.
<seb128> xnox, well, our vcs-es are not full source
<SpamapS> xnox: no, UDD is lp:ubuntu/
<seb128> xnox, so they don't really qualify for an UDD like workflow
<ScottK> That means when I need to go understand when something was done, I've got the history to figure it out.
<xnox> at one point it was ment to point UDD to ~team branches, for packages that do that. Not sure why that didn't happen for long established branches, like on the desktop
<ScottK> UDD branches are full source.
<ScottK> ubuntu-desktop and kubuntu branches are /debian only.
 * xnox would rather have inconsistent checkouts (/debian only and/or full), but always have consistent locations e.g. lp:ubuntu/package
<SpamapS> xnox: +1 from me
<ScottK> Can't.
<xnox> even if lp:ubuntu/package resolves is a symlink to ~ubuntu-desktop
<SpamapS> the full source bit seems to be the part that frustrates most people
<ScottK> The UDD branches have to be able to represent changes anywhere in the package.
<seb128> what drives me crazy with UDD is that every time I try to get a source it's outdated
<xnox> ScottK: I'm sure it was possible to 'bless' and designate branches as "official" at one point.
<Daviey> so i understand that if a team maintains a full source bzr branch, the UDD branch can be re-pointed.
<seb128> the importer keeps failing for desktop packages
<SpamapS> seb128: thats been addressed quite a bit
<Daviey> SpamapS: *every* time?
<Daviey> err seb128
<seb128> SpamapS, we got 3 people asking why lp:ubuntu/source is outdated this month
<ScottK> Also, now that Kubuntu is going to Universe, it would drive me nuts to have some random upload overwrite anything staged in the branch.
<seb128> SpamapS, i.e the gtk import is outdated still
<xnox> seb128: for gnome stuff it is due to .xz tarballs which are failing to import, due to out of date OS of the package-import machine. This is being worked on.
<Daviey> ScottK: well, at least you get a auto generated MP to cover the staged stuff
<xnox> seb128: more info on ubuntu-distributed-devel mailing list
<ScottK> Daviey: That's a regression from not having the changes stepped on at all.
<ScottK> xnox: That'll affect KDE too.
<ScottK> (note that no one noticed)
<SpamapS> seb128: right, caused by pristine-tar issues
 * xnox had no clue that KDE is doing .xz tarballs......
<seb128> xnox, thanks for the info, but well that's the sort of problem which keeps us away from using UDD
<Daviey> ScottK: well it's because we are in the middle ground of not having build-from-bzr and dput.. I can't see how you can keep everyone happy
<seb128> xnox, I'm not interested in trade a well working efficient workflow for a "known broken but being worked" one, we will reconsider the days things are solid
<xnox> seb128: please comment on the udd mailing list. it's being worked on. as it blocks a lot of stuff in e.g. foundations team.
<ScottK> seb128: +1
<SpamapS> seb128: I agree with you actually. I'd like for UDD to adapt to that reality, rather than keep fighting against it
 * xnox runs his own instance of package import to get mdadm branches for example
<ScottK> xnox: I filed bugs on UDD tools two years ago that haven't been addressed.  Why should I invest more time in it now?
<slangasek> SpamapS: no objections to the merge, but why fix bug #794082?
<ubottu> Launchpad bug 794082 in cron (Ubuntu) "cron ignores /etc/default/cron" [Undecided,Confirmed] https://launchpad.net/bugs/794082
<Daviey> seb128: right, by that logic.. you don't want any people testing Quantal pre-release?
<SpamapS> slangasek: because its broken?
<seb128> Daviey, quantal is supposed to be usable every day
<ScottK> Daviey: No, by that logic I don't want me testing quantal now and I'm not.
<SpamapS> slangasek: and, as yet, we have not come up with a decent way to transition from /etc/default/* to env statements in upstar tjobs
<seb128> Daviey, UDD is far from usable every day
<Daviey> seb128: except the days it is not, right?
<slangasek> SpamapS: but /etc/default is lousy and shouldn't be encouraged - given that this hasn't been usable for two LTS cycles now, why re-insert it now?
<seb128> Daviey, well it's not we fix it in the hour or revert
<seb128> Daviey, the day UDD will be issues we report in the hour I might consider using it
<seb128> doh, can't type
<SpamapS> slangasek: because hardy is going away soon? ;)
<seb128> the day UDD will fix*
<Daviey> I actually cannot criticise the response time on issues i have escalated to the people working on it.
<SpamapS> slangasek: we agree, but we don't have a migration path.
<seb128> Daviey, you maybe know who to poke to get your issues sorted ;-)
<xnox> seb128: tranlation fail of "seb128> Daviey, the day UDD will be issues we report in the hour I might consider using it" can you rephrase?
<slangasek> SpamapS: right; but just re-adding /etc/default handling everywhere will regress boot speed
<seb128> xnox, <seb128> the day UDD will fix*
<xnox> seb128: gotcha
<SpamapS> slangasek: I don't worry too much about things that start on runlevel 2 affecting boot speed
<Daviey> seb128: right, and i know who to poke to get desktop issues fixed.. because i interface with them :)
<seb128> xnox, like if had a place to say "can we get gtk import fix" and have it fixed in a timeline which doesn't block me for a week I would sign on maybe
<SpamapS> slangasek: perhaps that is misguided?
<slangasek> SpamapS: well we certainly do
<ScottK> Fundamentally, I don't know what problem I'm having that switching to UDD would solve.
<infinity> ScottK: Honestly, all it seems to do for me is create problems.
<seb128> xnox, but maybe I would not, because once the reliability issues are fixed we still run into the source v3, full source, quilt mess issues
<Daviey> seb128: who did you speak to about the xz issue of imports?
<infinity> (I appreciate the ultimate goal of perhaps building from bzr, it's the interim steps that hurt)
<Daviey> seb128: have you been following the work on v3/quilt issues?
<xnox> Daviey: xz issues are being discussed on the ubuntu-distritubuted-devel mailing list
<seb128> Daviey, nobody and no, I've an efficient, established, working workflow and work to get done which I prefer to spend on the content rather than on the tools
<xnox> Daviey: seb128 *just* found out about the cause.
<MFen> i'm using debhelper (dh) in my local custom package. i want to customize the source package, so i've got debian/source/format 3.0 (custom) and debian/source/options --target-format="3.0 (native)"
<MFen> it errors out, it says..
<MFen> dpkg-source: error: can't build with source format '3.0 (custom)': no files indicated on command line
<cjwatson> MFen: You've misunderstood "3.0 (custom)".  It's not what you want.
<MFen> where does that file list.. go?
<Daviey> seb128: right, my Dapper desktop works great... I'll stick with that.
<seb128> Daviey, I've been going to the UDD sessions at each UDS and explaining there why we don't use UDD though ;-)
<xnox> MFen: use 3.0 (quilt).
<cjwatson> MFen: Just put "3.0 (native)" in debian/source/format and drop that --target-format thing.
<seb128> Daviey, oh, come on, that's nothing to compare
<cjwatson> Or "3.0 (quilt)" if you have a separate upstream tarball.
<ScottK> Daviey: Also, I do a lot of work on Debian and so using a common toolset is a major feature for me.
<MFen> i don't. i *am* upstream, i just want to pass in a list of files from hg manifest
<SpamapS> slangasek: I feel that it is pretty lousy of us to just break peoples systems (even if we have 2 LTS's that are broken, its still lousy) and not give them a way to fix it
<seb128> Daviey, it's like saying I should use dpatch instead of quilt in my packages, why would that be a strategic thing
<cjwatson> MFen: OK, so if you don't have a separate tarball, just use 3.0 (native) in debian/source/format.
<seb128> Daviey, it's just tooling, we use whatever let us do the job best
<Daviey> seb128: I'm simply suggesting that putting yourself in a little bit of pain, helps the process develop.. Otherwise, progression is really slow.  I know mbp was able to solve many issues, based on user feedback.
<MFen> cjwatson: i don't want all the files in this directory though.
<MFen> are you saying i need to manually generate a tarball first, and then there's a source format that just lets me use that tarball?
<cjwatson> MFen: Then build yourself a tarball and use 3.0 (quilt).
<cjwatson> That's what most normal upstreams do.
<seb128> Daviey, the issues we have are known for a long time and don't need use to go through extra pain
<SpamapS> slangasek: and the google guys were pretty mad about us suggesting that we can just have them keep all those settings in /etc/init/*.conf because that is impossible for them to resolve on package upgrade..
<seb128> Daviey, like we have been converting a few packages to UDD for testing and gave the feedback, the situation didn't change in 3 cycles
<ScottK> Daviey: I gave it a good try, gave feedback and filed bugs.  That was two years ago and not much has changed.  Doing the same thing again is not a priority.
<SpamapS> slangasek: either way, I don't have time to implement a /etc/default/* converter ..
 * xnox uses UDD to do debdiffs/NMU's into debian
<cjwatson> SpamapS: /etc/init/*.override exists
<seb128> Daviey, I go at the UDD session at each UDS and they admit UDD is just not having lot of resources allocated
<slangasek> SpamapS: a) they can put it in /etc/init/*.override instead; b) /etc/default/cron is also a conffile so I don't see any reason to believe that's easier to resolve on upgrade than /etc/init/cron.conf, which should change rarely if ever
<seb128> Daviey, they don't lack feedback
<SpamapS> slangasek: /etc/init/cron.conf is code, and so they're not as comfortable using --force-confold
<cjwatson> MFen: the stuff about "arbitrary files" in dpkg-source(1) for 3.0 (custom) is talking about something a bit different; it's basically for people who are doing enormously arcane source package format development.  Basically, nobody who isn't developing dpkg itself needs it.
<slangasek> "code" wut
<SpamapS> cjwatson: aye, but we are not converting things into .override
<slangasek> SpamapS: the only code there is 'exec cron'
<slangasek> indeed, /etc/init/cron.conf is a stellar example of a declarative job
<SpamapS> except it would break if you apt-get remove cron
<MFen> cjwatson: gotcha. ok, so the quilt documentation is far from clear.. where do i put that tarball?
<xnox> MFen: ../myapp_1.3.orig.tar.bz2
<MFen> hmm. maybe it's just the missing version that's the problem
<slangasek> SpamapS: FSVO "break"
<SpamapS> slangasek: emit an error?
<SpamapS> slangasek: Maybe we don't care?
<xnox> MFen: what version control system do you use?
<MFen> xnox: mercurial
<cjwatson> MFen: you must have a version, yes.
<slangasek> SpamapS: I don't care enough about the emitted error to go making /etc/init/cron.conf ugly
<MFen> i'm still having issues with this. now i have the right filename, but it's spewing errors about other files that are in the directory. e.g.
<MFen> dpkg-source: error: cannot represent change to m11/util.pyc: binary file contents changed
<cjwatson> and it must match the bit before "-" in the head version in debian/changelog
<MFen> (this is a file in the source directory but not in the source tarball)
<slangasek> SpamapS: nor do I care enough about upgrade support for /etc/default/cron to make the boot slower for all users
<MFen> how do i make it stfu about that
<cjwatson> you should remove .pyc files on clean; dh will do that for you
<MFen> the whole point is not to do that. there are mountains of files in here that i do not want considered in the source tarball
<MFen> removing pyc files is one thing, removing tons of demo directories and data directories and config files is another
<cjwatson> I think you're missing the point somewhere here ...
<cjwatson> get your source tarball right first, then unpack it somewhere else and do the packaging there
<cjwatson> the packaging must clean up after itself.  that's unrelated to what's in your source directory, because the packaging should never see that
<MFen> that seems like a waste of time. i don't even *want* a source tarball, i will never use it because we don't build our package that way. i'm only doing this so it's not so enormous, because debuild insists on building it anyway
<cjwatson> if dpkg-source is seeing that you're doing something wrong
<cjwatson> you can use -I to exclude things from the source tarball with 3.0 (native)
<cjwatson> if you want to do it that way
<Daviey> native, generally, makes babies cry.
<cjwatson> not always, and let's not be dogmatic about this
<SpamapS> slangasek: ok, so we should mark that bug Won't Fix ;)
<slangasek> SpamapS: that's my preference, yes
<SpamapS> slangasek: but I do feel that this is pretty crappy still. Users with customized /etc/default/* are getting screwed.
<cjwatson> you could even put tar-ignore = <stuff> in debian/source/options (the equivalent of -I)
<cjwatson> however you should still make sure to build the package separately otherwise you might well find that you're accidentally shipping incomplete source
<slangasek> SpamapS: users with customized /etc/default get a one-time upgrade issue to deal with... when upgrading to lucid
<MFen> cjwatson: i've been trying to avoid that because there will be many patterns i have to add to that. i was hoping for a whitelist, not a blacklist
<cjwatson> You can't have one, sorry
<SpamapS> slangasek: *if* its obvious that it is broken
<MFen> although maybe what i really want is to blacklist everything. just give me an empty source package
<cjwatson> Why build a source package at all if you're going to do that?  Just use debuild -b
<SpamapS> slangasek: if they've just raised log priority .. they may not realize for weeks or months that they've lost logs.
<MFen> won't that confuse apt, and reprepro if i don't have one?
<cjwatson> It won't confuse apt.  I can't speak for your archive.
<slangasek> SpamapS: sure, entirely possible - but I don't see why we should be making the boot slower two LTS cycles *later* to try to patch over this when we shipped with that issue for this long
<SpamapS> slangasek: I'm not saying this is super urgent crazy important. But I really don't like that we're sweeping this under the rug. :-/
<cjwatson> Or the policies imposed by your archive administrators, if you don't run it.
<slangasek> SpamapS: maybe a release note is better?
<MFen> well, we don't ship source at all. (properly speaking, we don't ship any of this, it's for internal servers)
<cjwatson> Given that this is the primary Ubuntu development channel, I can't recommend shipping packages without source, but perhaps this is something local.
<SpamapS> slangasek: Or some priority for something to convert them all to env statements in override files.
<cjwatson> Don't see why you need a source package then.  Configure your archive to accept binary-only uploads
<cjwatson> And use debuild -b
<MFen> cjwatson: i like that idea. thanks, i'll work on that
<SpamapS> slangasek: but meh, my time for this issue is officially used up.
<slangasek> SpamapS: right, I wouldn't object to a standard-ish tool to convert /etc/default/foo to foo.override... I think we've discussed this explicitly in the past... but it's not anywhere near the top of the priority list
<SpamapS> slangasek: one thing.. we should remove the file from the package
<SpamapS> slangasek: it would be much more clear that way
<juliank> cjwatson: Your patch looks OK I'd say. I'd like to take a final look at it tomorrow, and then merge it. Currently, I need to do university stuff.
<SpamapS> slangasek: actually even better, I'll install a "# This file is deprecated please edit /etc/init/cron.conf or /etc/init/cron.override directly'"
<cjwatson> juliank: Great, thanks
<juliank> cjwatson: Upload of the new release to unstable is planned for next Thursday.
<juliank> (As we have next Thursday planned due to translation updates)
<SpamapS> slangasek: this might even be a change worth SRU'ing back to lucid, so late hardy upgraders will get the notification that the conffile has changed
<cjwatson> Sounds good, I think.  I just don't want the python3-debian work to get caught up in a freeze.
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> SpamapS: dropping /etc/default/cron> oh indeed, very good point
<SpamapS> slangasek: uploaded a "This is deprecated" version
<slangasek> SpamapS: cheers
<bryceh> ogra_, if you're still around, see the merge proposal; branch is failing to build
<mterry> mpt, the SoftwareUpdates spec defines "uninstallable updates" as updates that would remove ubuntu-desktop.  What about updates that would remove some other package?  There is no UI for presenting such updates (and I think the current U-M handles that by pointing users at a release upgrade dialog)
<BenC> infinity: any way I can get scilab to stop being bumped on the ppc buildd?
<StevenK> BenC: bumped?
<BenC> It keeps getting pushed back while other package builds get higher priority it seems
<StevenK> BenC: Ah, I can rescore it for you, if you wish.
<BenC> Yes, please
<StevenK> BenC: Link me the build?
<BenC> StevenK: https://launchpad.net/ubuntu/+source/scilab/5.3.3-10ubuntu2/+build/3574412
<BenC> Thanks
<BenC> I have a few other FTBFS to kick off once that's done, and it's been in queue since last night :)
<StevenK> BenC: sulfur just picked it up
<RAOF> hyperair: pong.
<infinity> BenC: Queue jumper. :P
<BenC> infinity: queues go in orderâ¦that sucker was on a negative timeline
<infinity> BenC: It's in universe and people kept uploading stuff in main.
<BenC> Damn core-devs and their main packages
<BenC> Dear thunderbirdâ¦welcome back to powerpc
<BenC> And with that, I've gotten rid of all the FTBFS in main/powerpc
<BenC> Damn you firefox
<micahg> BenC: please tell me you didn't upload thunderbird
<BenC> Nope, but I need someone to do it
<BenC> â¦if not me
<micahg> BenC: yeah, ask chrisccoulson how he wants it, it can go in with the next beta
<micahg> unfortunately, it's a monstrosity
<BenC> Firefox will need the same fix
<micahg> yeah
<BenC> Does he handle that too?
<micahg> yep
 * micahg would think merge proposal against lp:firefox/beta
<micahg> really should have one for lp:firefox as well ideally
 * micahg wonders if it was fixed for 15
 * micahg will be happy if we get powerpc back in the stable releases for 14
 * infinity is trying to decide how deeply he cares about mozilla.org stuff compiling for incorrect CPU targets on armel.
<infinity> Well, or failing to.
<infinity> I'm sure I'll care at some point.
<BenC> Give it a beer or two
<infinity> Could take a few litres of gin.
<infinity> GHC seems okay locally, at least.  Just needed a hard rebootstrap, since it sort of explodes upon trying to compile itself.
<infinity> Not the brightest compiler on the tree.
<BenC> GHC on ppc?
<infinity> armel.
<infinity> Not EVERYTHING is about you. :P
<BenC> I was trying earlier (with no success) to re-enable ghci on powerpc
<BenC> hehe
<infinity> GHC on PPC is fine.  Well, except for ghci.
<infinity> No ghci on ARM either.
<infinity> Upstream doesn't much care.
<BenC> It's causing a lot of FTBFS and dep-waits
<micahg> infinity: hrm?  is something else broke?
<infinity> And it's not trivial.
<infinity> BenC: Yeah, ghci just plain isn't support on non-primary arches upstream.
<BenC> It's at least not segfaulting on innovation like it was in Jan
<BenC> *invocation
<infinity> BenC: That may be some failures you'll just have to live with, unless you have a lot of free time.
 * infinity would like to get some people on ghci-on-ARM too, but I'm not made of Engineers.
<BenC> If only I were a haskell type person, but alas, I'm only concerned enough because of the numbers, not because I really like haskell
<infinity> Well, I suppose I *am* made of engineer.  Just one, though.
<micahg> infinity: oh, right, yeah, well, packages build on Debian somehow, so there's got to either be a patch or flag to make it work
<BenC> An Engineer of One (â¢)
<infinity> BenC: I don't care about Haskell, but everyone I know who does use it, uses ghci, so it's effectively useless to them on non-primary arches.
<infinity> micahg: Eh?
<infinity> micahg: A patch or flag for what?
<micahg> infinity: firefox/thunderbird
<infinity> micahg: Oh.  Right.
<micahg> builds on armel in Debian last I checked
 * ajmitch thought that ghci on arm was merged upstream now
<infinity> ajmitch: Is it?
<infinity> ajmitch: If so, yay, but that certainly hasn't filtered down to the masses.
<ajmitch> was reading http://www.haskell.org/pipermail/haskell-cafe/2012-June/101704.html from a few days ago, in 7.4.2
 * RAOF might get mono to actually work on armhf over the weekend.
<ajmitch> RAOF: that'd be nice :)
<infinity> ajmitch: Oh, VERY recently.  Nice.
<infinity> RAOF: Define "work".
<infinity> RAOF: It already works, it's just not hard float...
<RAOF> infinity: Fail to segfault as soon as someone p/invokes.
<infinity> RAOF: Unless you meant s/armhf/armel/
<infinity> RAOF: Or did I miss a recent development with it no loger working?
<RAOF> It's apparently never worked on armhf.
<RAOF> Well, except for purely managed code.
<RAOF> The JIT works, but as soon as you try to call out to a native library it uses the wrong ABI and things go horribly pear-shaped.
<Bluefoxicy> hmm, seems ejecting even the partition does it.
<Bluefoxicy> Is 'eject' just umounting?
<RAOF> You can see this in the build logs; the test-suite works, except for everything that has âpinvokeâ in the name, which segfaults :)
<infinity> RAOF: Oh, lovely.  Well, if you like mono, go to town.
<infinity> RAOF: Bonus points if you make it actually be hard-float while you're at it. :P
<RAOF> It's *got* a hard-float codepath; is that not on?
<infinity> RAOF: (Also, I think this hilights that the testsuite is awful, since it passes on armhf...)
<RAOF> No, I don't think it does. But failing the testsuite doesn't fail the build.
<infinity> RAOF: I could be mistaking it for some other nasty hack, but I was fairly sure that mono on armel and armhf were both more-or-less no-float.
<infinity> Oh, indeed.  "390 test(s) passed. 9 test(s) did not pass."
<RAOF> It's entirely possible; I've recently prodded around a tiny bit in the ARM (and s390, and sparc, and PPC) JITter, and it seemed to have a float codepath.
<infinity> RAOF: Honestly, I only tend to care about mono is as much as it's critical path for building a ton of other crap.
<infinity> RAOF: But if you can make it actually work correctly, go nuts.
<RAOF> I may ask questions about ARM ABIs :)
<infinity> And I may answer them.
<infinity> BenC: So, upstream has a table that *claims* ghci is supported on PPC.  So, it may just be suffering a tiny bit of bitrot, might not be as much effort as I initially claimed.
<infinity> And with ghci supported on ARM in 7.4.2, that tosses out a ton of build failures and brings all our arches to parity.  Ish.
<infinity> Yay for toy languages.
<infinity> (Actually, as much as I don't care about ghc/ghci, I guess having a toy language on toy dev boards is kinda the ideal for poor university students and such)
<BenC> infinity: Are you uploading 7.4.2? If so, I'll try re-enabling ghci on PPC
<infinity> BenC: No.  But I'll probably prod the Debian maintainers about it once I'm done rebootstrapping 7.4.1 on armel. :P
<BenC> infinity: irkâ¦Yeah, there's a patch that disables in on ppcâ¦apparently the 6.8 core (of whatever it is that handles ghci) works on ppc, but the 6.10 in current ghc doesn't work so good
<BenC> infinity: BTW, I only found one more build-arch fixable package, so I have a note to kick it once dpkg is merged
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RAOF
#ubuntu-devel 2012-06-15
<infinity> Riddell / ScottK: calligramobile is no longer, what do you want to do about it being seeded in active?  Switch to calligra, drop it entirely...?
<JontheEchidna> s/calligramobile/calligraactive/
<JontheEchidna> just a rename on upstream's part
<infinity> JontheEchidna: Ahh, I missed the rename.  Thanks.  Will update the seeds and meta.
<JontheEchidna> though one could make the argument that a transitional package would be desirable
<infinity> JontheEchidna: One could, perhaps, though kubuntu-active was barely even a tech preview in precise, so I'm not sure how valuable littering the archive with transitional cruft would be.
<JontheEchidna> true
<infinity> I guess it did have an i386 release.  *shrug*
<infinity> I'll leave that up to other people, I'm just fixing uninstallables. ;)
<RAOF> Ok. I've just totally dropped context. Time for lunch!
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<kira__> hi everybody :)
<kira__> I have stupid question..
<kira__> I have ARM5 based Huawei 8110 ( Qualcomm)
<kira__> so where I can get u-boot for it?
<micahg> kira__: you might want to ask in #ubuntu-arm
<kira__> ok.. thank for advice.
<kira__> thanks
<kira__> bb
<hyperair> RAOF: banshee has a microrelease exception. does it still need to complete the SRU stuff for the bugs?
<RAOF> hyperair: Not by my understanding of the process, which is why I accepted it into precise-proposed.
<hyperair> RAOF: oh, it's accepted?
<hyperair> whoops. =p
<RAOF> hyperair: You shouldn't have switched to dh9, though.
<hyperair> ah
<hyperair> =\
<RAOF> It's fine in quantal, obviously, but that's not useful in an SRU
<pitti> Good morning
<pitti> dobey: it was already, I think
<slangasek> pitti: hi, has anyone brought bug #1013171 to your attention yet this morning?
<ubottu> Launchpad bug 1013171 in xdiagnose (Ubuntu Quantal) "Many package hooks not ported to python3" [Critical,Confirmed] https://launchpad.net/bugs/1013171
<slangasek> pitti: it looks to me like apport should be rolled back to python2 until this is resolved
<pitti> slangasek: not this morning, but we discussed it yesterday
<pitti> it said ogra already fixed the package hook in his branch, so perhaps we can just upload the fixed hook instead, if the full port isn't ready yet?
<slangasek> pitti: there are at least 10 affected packages
<pitti> "many package hooks" is indeed a bit misleading
<pitti> most of them are symlinks to source_xorg.py
<pitti> "critical"? that seems very excessive to me
<slangasek> it breaks upgrades
<pitti> how so?
<slangasek> /usr/share/python3/runtime.d/apport.rtupdate gets called and fails
<pitti> uh, ok
<pitti> slangasek: actually, it's not supposed to pre-compile the hooks in the first place; perhaps I should just (or also) drop that pycompile bit?
<slangasek> how do you mean, not supposed to?
<pitti> the python modules go into /usr/lib/python3.2/
<pitti> the hooks are not python modules
<pitti> they are plugins which get parsed and run dynamically
<pitti> this .rtupdate thingy is bogus
<slangasek> ok
<slangasek> that's a much faster fix then :)
<pitti> so something in our dh_python2/3 stuff overeagerly tries to compile everything that looks like .py in any package directory?
<slangasek> well, it's the sensible default assumption
<pitti> hm, any idea how this bug can be reproduced? I tried sudo apt-get install --reinstall python3.2 apport
<slangasek> though perhaps there's a dh_python3 bug here in creating a .rtupdate for a directory that apport doesn't ship any .py files in
<pitti> oh, it does ship .py files in there (and python scripts which are not named .py)
<slangasek> I think you have to install a new version of python to trigger it... so a precise->quantal upgrade, or remove + reinstall python3.2&apport
<pitti> ah, I see
<slangasek> I think the tools are smart enough to not be fooled by a --reinstall
<pitti> sudo /var/lib/dpkg/info/python3.2.postinst configure -- not that either, hmm
<pitti> I'll keep trying
<pitti> oh, silly me
<pitti> not the python3.2 package, the python3 -meta package
<pitti> sudo apt-get install --reinstall python3
<slangasek> pitti: so I think dh_python3 --skip-private should be sufficient; testing now
<pitti> slangasek: I'm in the middle of fixing the (hopefully) last remaining autopkgtest failure (ETA 20 mins), then I'll do a new upload
<pitti> with either --skip-private, or just rm'ing the file
<slangasek> pitti: alternatively, dump_acpi_tables.py can be renamed to dump_acpi_tables
<slangasek> pitti: either should suffice
<slangasek> anyway, tested the --skip-private solution and pushed
<pitti> slangasek: but apparently it also considers subdirectories? i. e. /usr/share/apport/package-hooks/ is what's causing all the mess?
<pitti> slangasek: nice, thanks!
<slangasek> pitti: I don't know if it looks at the subdirs or not
<slangasek> but if apport doesn't ship any files named .py in that directory in the first place, dh_python3 won't think it needs to provide a rtupdate script for private modules
<pitti> slangasek: thanks for the urlib fix, I'll commit that upstream
<pitti> slangasek: ok; I can see where that script is being used, but I think it's only in source_linux.py hook
<pitti> so we can rename it easily
<pitti> but --skip-private sounds more robust either way
<slangasek> yes, probably
<pitti> slangasek: OOI, how did you notice the urlopen() bug? there is no python3-launchpadlib, or do you have a secret one?
 * pitti gets a dreaded cron mail from ddebs.u.c. running out of space again
<pitti> slangasek: do you happen to have some superpowers to bump RT #52633 ?
<mumbler> pitti: about the title of bug 1013171 -- feel free to change "many package hooks".  :)  That was just my quick-n-dirty attempt to say "not just an xdiagnose bug".
<ubottu> Launchpad bug 1013171 in apport (Ubuntu Quantal) "Many package hooks not ported to python3" [Critical,In progress] https://launchpad.net/bugs/1013171
<pitti> mumbler: seems fine to me
<mumbler> pitti: ok, thanks.  do you have time for a couple apport questions while we are here?  if not, I should go to bed now, anyway...
<pitti> mumbler: just shoot
<pitti> I'm wrapping a new release to fix that bug and the autopkg tests, but I can answer in between
<mumbler> great.  I saw a claim, maybe in someone's blog from UDS-Q, that apport was being phased out in favor of more from whoopsie, and I know not what.  That doesn't seem true now.
<mumbler> So I was going to submit some small doc patches for apport.  Is that still a good idea?
<pitti> it's never been true
<pitti> mumbler: jockey is being phased out
<pitti> mumbler: the thing we introduced was whoopsie, to let apport run in stable releases, too
<pitti> to send crashes to errors.ubuntu.com instead of Launchpad
<pitti> everything else is either a misunderstanding or a secret plot against me :)
<mumbler> pitti: thanks -- I'm not sure what this bad source was, but I will pass that my cell leader^H^H^H correct it if I see it again. :)
<pitti> *chuckle*
<pitti> mumbler: Tertiary Adjunct of Unimatrix Zero-One?
<mumbler> pitti: We have no knowlegdge of such a sector, or a plot, nor would they be relevant if We could acknowledge them.
<mumbler> pitti: so, sometime I will try to make a small patch, to document .apport-ignore.xml a little, in the manpage.
<pitti> mumbler: thanks
<pitti> (or should I say "that is agreeable")
<mumbler> pitti:  :)   I was going to try to speak borg, but I'm sleepy, and it's coming out more like queen victoria, "we are not amused"
<mumbler> hm, I was going to ask about client-side duping a little, but I'm sleepy and you're working, so I'll try to come back another time.  thank you, and good night/morgen.
<jk-> stgraber: ping?
<dholbach> good morning
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<jamespage> morning all
<tsdgeos> when can one start complaining about a MIR being ignored?
<seb128> tsdgeos, complaining is usually not really constructive, just mention what is blocking you and we will find a way to unblock you
<seb128> tsdgeos, can you give the bug number?
<tsdgeos> seb128: https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/1011487
<ubottu> Launchpad bug 1011487 in openjpeg (Ubuntu) "[MIR] openjpeg" [Undecided,New]
<seb128> tsdgeos, oh, that was rejected in the past
<tsdgeos> well
<tsdgeos> it was a bad idea then D:
<tsdgeos> seb128: why was it rejected?
<seb128> tsdgeos, bug #711061
<ubottu> Launchpad bug 711061 in openjpeg (Ubuntu) "[MIR] libopenjpeg2" [Wishlist,Expired] https://launchpad.net/bugs/711061
<seb128> tsdgeos, if you can address the comments from doko please do
<tsdgeos> seb128: read this one, has no reason at all for closing
<seb128> tsdgeos, because doko believes that libjpeg should do everything libopenjpeg does
<tsdgeos> doko has no clue then
<seb128> tsdgeos, see https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/711061/comments/3
<ubottu> Launchpad bug 711061 in openjpeg (Ubuntu) "[MIR] libopenjpeg2" [Wishlist,Expired]
<seb128> tsdgeos, well, that's possible he doesn't know about everything, nobody does know about everything and doing MIR review is an hard job, I don't think saying people "have no clue" is helpful though
<seb128> tsdgeos, he asked question and nobody replied ... maybe you could be productive and share your knowledge on the bug and reply to his questions?
<tsdgeos> seb128: well, he didn't care to search that libjpeg is regular jpeg and openjpeg is jpeg2000 that is a total different format
<tsdgeos> and that's like 5 minutes of searching
<seb128> tsdgeos, did you read the comment I just pasted
<tsdgeos> more like 1
<tsdgeos> seb128: the one about embedded libtiff?
<seb128> tsdgeos, the "FILE FORMAT WARS" comment from libjpeg
<tsdgeos> seb128: sure, so libjpeg developers hate jpeg2000
<didrocks> tsdgeos: want to be part of the MIR team? there are only 3 semi-active persons on the team who have a lot of other hats and other works to do. Help is welcomed
<tsdgeos> what does that mean?
<tsdgeos> seb128: are we letting other people shut down stuff?
<tsdgeos> didrocks: i'm not even an ubuntu developer, don't think i can/should be part of the MIR team
<didrocks> tsdgeos: you can start by that then :)
<seb128> tsdgeos, you are not being constructive there, if you read the bug doko mainly asked for an example of image that is not rendered by our current main stack, can't you just provide one?
<tsdgeos> seb128: sure i can, i already did in my bug
<seb128> tsdgeos, I will mark yours duplicate and reopen the old one, he already has some history and record of review
<tsdgeos> seb128: i am being constructive, i am trying to get our user to get better rendering
<tsdgeos> and people are closing bugs on uninformed decisions
<tsdgeos> and i'm the one not being constrcutive?
<tsdgeos> seb128: good
<seb128> tsdgeos, right, and calling the MIR reviewer clueless is not the way to get things approved, yes they don't know about everything, better helping them to understand the issue than to insult them
<tsdgeos> didrocks: had a look at the process, seemed to cumbersome
<seb128> tsdgeos, I'm sure there are topic you have little clue about as well, MIR reviewer is not an easy job
<tsdgeos> didrocks: besides i know *nothing* about packaging
<seb128> tsdgeos, like try to help them to understand the issue rather than blaming them for not knowing what you know
<tsdgeos> seb128: there's lots of topics i have no clue, but i don't make decisions on them :-)
<didrocks> tsdgeos: well, we are 3 on the team, do you think 3 people can cover the whole stack?
<tsdgeos> didrocks: nope i don't
<didrocks> so, please, bear that in mind
<didrocks> and help rather than critize
<seb128> tsdgeos, well, to be fair details where asked on this bug, and it got closed because nobody provided a good rational in a reasonable timeframe, and they garbage collect the bug to keep a managable queue
<seb128> tsdgeos, bugs closing are not the end of the world, they can be reopened if the requested details are provided
<tsdgeos> seb128: sure, it's fine, that was back then, don't blame me for that, i wasn't using ubuntu so i didn't care you guys closed the bug
<tsdgeos> i'm using ubuntu now, so i do care about my pdf viewer sucking
<seb128> ;-)
<seb128> great
<seb128> so let's move on and get that fixed
<slomo> seb128: you already have a jpeg2000 library in main btw (afaik). libjasper
<seb128> libjasper1: JasPer JPEG-2000 runtime library
<seb128> slomo, hum, indeed!
<seb128> tsdgeos, I guess poppler can't use that one?
<tsdgeos> seb128: unless you write code for it :D
<tsdgeos> seb128: besides jasper is worse
<tsdgeos> have a few images lying around that openjpeg renders and jasper doesn't
<tsdgeos> lying around == sent to a kde mailing list a few years ago
<tsdgeos> besides jasper is unmaintained afair
<tsdgeos> and openjpeg no
<seb128> ok
<slomo> and libjasper doesn't bundle the world (libpng, libtiff, libz, liblcms2) ;)
<RAOF> You wouldn't happen to know if the various rdepneds of libjasper happen to build against openjpeg?
<slomo> RAOF: no, the API is different
<RAOF> :/
<seb128> tsdgeos, it's a bit annoying, gdk and kde seems to use jasper
<tsdgeos> seb128: i know
<tsdgeos> never got myself to rewrite kde's support to use openjpeg
<tsdgeos> blame that on lazzyness
<tsdgeos> we still us ps for pdf preview generation
<tsdgeos> .D
<tsdgeos> err
<tsdgeos> gs i mean
 * RAOF wonders if fixing jasper is quicker and easier than porting to openjpeg
<pitti> seb128: erk, DSL reconnect; got my message?
<pitti> pitti | seb128: looking at the gvfs loop bug ATM; sorry, didn't get to it yesterday
<tsdgeos> RAOF: doubt it
<seb128> pitti, no I didn't, thanks
<tsdgeos> jpeg2000 is kind of non trivial stuff
<tsdgeos> seb128: https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/711061/comments/10
<ubottu> Launchpad bug 711061 in openjpeg (Ubuntu) "[MIR] libopenjpeg2" [Wishlist,Confirmed]
<tsdgeos> seb128: anything i forgot to answer?
<seb128> tsdgeos, not that I know about, I guess the MIR team will be a bit unhappy about having 2 implementation of jpeg2000 in main though, that's the sort of things we don't like to duplicate
<seb128> not sure if that will annoy them enough to force us to converge on one of the two though to accept it
<jamespage> please could someone with the right permissions delete/reject this MP - https://code.launchpad.net/~smoser/ubuntu/precise/tgt/lp977621-start-on-install/+merge/101321
<tsdgeos> sorry my router restarted itself
<tsdgeos> anything i missed?
<slomo> seb128: jasper could be unmaintained upstream, so it might make sense to switch to the other one after checking if that's really the case (there was at least no release since a very long time)
<slomo> seb128: so it might make sense to compare both and then maybe settle on one
<seb128> tsdgeos, <seb128> tsdgeos, not that I know about, I guess the MIR team will be a bit unhappy about having 2 implementation of jpeg2000 in main though, that's the sort of things we don't like to duplicate
<seb128>  not sure if that will annoy them enough to force us to converge on one of the two though to accept it
<tsdgeos> i see
<tsdgeos> tx
<seb128> from the look of things we should converge on openjpeg
<tsdgeos> for one it has an accessible repo, accessible developers, accessible mailing list
<tsdgeos> which jasper has not afaik
<seb128> yeah, jasper didn't get an update in Debian since 2007 as well
<seb128> like it got only one version ever
<seb128> only packaging revision since
<seb128> RAOF, tsdgeos, slomo: the gdk jpeg2000 loader seems small enough, it shouldn't be too much work porting it to openjpeg I guess if somebody wants to do that
<slomo> seb128: i think everybody is only using jasper because it was earlier and everybody important (gdk-pixbuf, kde stuff) is using it. at least that was the main reason why we chose it in gstreamer
<tsdgeos> the thing is that almost noone has any jpeg2000 image around
<tsdgeos> so it doesn't matter much for the desktop itself
<tsdgeos> but somehow it seems more common inside pdf files
<tsdgeos> don't ask me why
<slomo> tsdgeos: well, jpeg2000 is quiete important for video nowadays (digital cinema for example is using jpeg2000). but for plain images i didn't see it used much either, most probably because the advantage over jpeg is minimal compared to switching to a new format
<seb128> tsdgeos, slomo: the gdk bug where jpeg2000 support was added mentions "The one reason for having a jpeg2000 loader at all is that OS X icons apparently store their payload in this format..."
<tsdgeos> he he
<seb128> grrrrr, "Many package hooks not ported to python3" spamming
<seb128> we should forbid people to do those "let's open 1 bug and make it affect a ton of sources"
<seb128> if you are subscribed to any of the sources you get spammed to no end :-(
<pitti> but it's much easier to delete one huge thread than 50 small ones?
<seb128> ScottK, not thanks for that one :-(
<pitti> and you can mute that bug for you if you aren't interested
<Laney> seb128: you can mute individual bugs in LP now
<seb128> pitti, I wouldn't get emails about the 49 sources I'm not subscribed to and would have nothing to delete
<seb128> Laney, I'm interested about the comments related to the source I'm following
<StevenK> 49 tasks on one bug makes Launchpad *VERY* sad.
<pitti> well, I'm actually interested in the progress of that bug, regardless of which packages it affects; it's not a "package" bug, it's a "project-wide task"
<seb128> pitti, it's like "let's open a ftbfs bug and make it affect all the packages in the archive which ftbfs"
<pitti> seb128: not the same root cause usually
<seb128> well, there neither
<pitti> if it's "30 packages FTBFS due to a glib change", then that should/could be one bug, yes
<seb128> ok, let's agree to disagree with that
<seb128> it seems people like the spamming for some reason, I will just mute the bug, but if any of my packages are in there you will need to reach me through another mean then
<pitti> I do like the spamming, yes
<seb128> pitti, the proper way would be to open different bugs, tag them and have you subscribe the to tag
<seb128> pitti, not to impose the spam to any subscribe to any of the sources
<seb128> subscriber
 * pitti sticks with "agree to disagree"
<seb128> ok, fair enough ;-)
<seb128> let's move on
<pitti> I'd consider the alternative way too much overhead
<xnox> pitti: you could have used a tag =) a check the progress of the tag.... just saying =)
 * xnox prefers many sources/tasks in a single bug
<seb128> xnox, I just said that, I think that's what he considers "too much overhead"
<pitti> xnox: I didn't open it in the first place, but I've been guilty in the past of doing the same approach for similar situations
<pitti> xnox: you can't subscribe other people to a tag
<pitti> and even doing it yourself is something that someone needs to ask you to do
<xnox> =(
<pitti> and it would meen tag inflation, too
<seb128> well let's hope it's not a practice that goes increasing
<seb128> but that's the best way to make sure people do stop reading their bug emails
<seb128> just spam them to no end about stuff they are not subscribed to because one thing they care happens to be in the middle of somebody's transition
<xnox> fair enough. pitti, I'm not familiar with apport API, I did 2to3 & compileall is there any way I can test the apport hook with python3?
<pitti> xnox: for the syntax errors you can just run "python3 source_foo.py"
<pitti> xnox: many hooks actually have a __main__ for testing
<pitti> xnox: for the remainder, run apport-bug srcpackage, and watch for tracebackes
<xnox> ok. thanks.
<tsdgeos> do you guys know if .deb packages support filenames with newlines?
<tsdgeos> having a look at the md5sums file inside the control tar inside the deb, it would seem no
<tsdgeos> since the format seems to be
<tsdgeos> md5 filename<newline>
<tsdgeos> md5 filename<newline>
<tsdgeos> etc
<tsdgeos> so if the filename contains a newline it'd probably get confused
<pitti> I've never seen one, and I would not ever accept a deb with a file name containing a line break, and usually not even spaces
<tsdgeos> can i quote you on that?
<cjwatson> .md5sums is ancillary, but the .list format would be broken by a file containing newlines.
<cjwatson> Which is much more important.
<cjwatson> I don't see any code that specifically forbids it, but I haven't spent much time looking for it and I haven't actually tried it.
<cjwatson> I would tend to say that if dpkg doesn't refuse to unpack such a .deb, it would be a bug, since its own file formats would be corrupted by it (unless it has some escaping that I've missed).
<cjwatson> At any rate if you have somebody asking you whether they can put newlines in their filenames in a .deb then the answer is certainly no.
<pitti> tsdgeos: the only place I've ever seen newlines in file names are exploits; I see no legitimate reason for them in packages
<pitti> tsdgeos: and yes, you can quote me on that (but it's my personal opinion, not quoted from a policy document)
<tsdgeos> pitti: sure
<tsdgeos> tx
<pitti> spaces in file names, maybe (e. g. in /usr/share/doc/ for .html files)
<tsdgeos> cjwatson: well, i'm prototyping/defining something that is similar/replacement/complementary to .deb
<tsdgeos> and knowing that .deb is doesn't support (or at least we don't seem to have any deb with) newlines, makes it easier for me to argue not to support that either
<tsdgeos> and use the newline as "separator" in the file format
<cjwatson> Spaces in file names are valid and I've seen them in .debs.
<cjwatson> If you don't mind the file format being binary, though, IMO the correct inter-file-name separator in a non-text file is NUL
<cjwatson> Since that genuinely is invalid in a Unix file name
<tsdgeos> yep
<tsdgeos> problem is it makes it much more difficult to read
<cjwatson> Indeed
<cjwatson> Which is probably why dpkg went for \n
<tsdgeos> and people seem to struggle then why can have char * with a NUL that is not the end of the char *
<tsdgeos> s/why/they
<larsduesing> sorry, again a question: What's about these "Related source package recipes" in launchpad bzr - are they needed?
<larsduesing> example in: https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-1007408
<ScottK> seb128: If you want to do the extra work of filing all the individual bugs and removing all the 'extra' tasks from that one, I'm not stopping you.
<pitti> that alone could be scripted, but it's spreading out information that belongs together
<pitti> particularly for bugs where you need to discuss a solution
<debfx> barry: does apturl-common need to depend on python3-aptdaemon? only the gtk backend seems to use it.
<seb128> pitti, the info doesn't belong together, udisk and xorg (taking random example) probably having different python3 incompatible issues, we don't do one bug "we should port the archive to python3" affecting all the ubuntu python2 sources
<xnox> is there a ppc64 ubuntu port?
<xnox> xnox: confired that there isn't one
<cjwatson> xnox: No
<xnox> ok
<rbasak> Is there a generic way of determining what arches come from which main mirrors (eg. archive.ubuntu.com/ubuntu for amd64 and ports.ubuntu.com/ubuntu-ports for armhf) and if not where would be appropriate to add this? distro-info?
<rbasak> Right now every script seems to have its own lookup table, and the number of these is growing. Eg. debootstrap, lxc, previously cobbler and now MAAS
<bvad> Hey guys, anyone knows where can I find the source for the sound indicator applet in Unity?
<seb128> bvad, lp:indicator-sound
<bvad> seb128: thanks
<seb128> yw
<seb128> bvad, https://code.launchpad.net/indicator-sound
<bvad> Thanks a bunch seb128
<bvad> I'm trying to get the sound indicator applet to start the default gnome sound preferences dialog, instead of the unity one.. How'd I do that?
<seb128> bvad, you log into a non unity session?
<seb128> bvad, we do session detection on the system settings side
<seb128> bvad, why do you want to do that? is there an issue with the unity one?
<bvad> Sort of, when I connect an HDMI cable to my laptop, the HDMI option does not always show up - which means no sound over HDMI. Using the fglrx driver
<bvad> Usually un-plugging and plugging it in again works, but sometimes a reboot is required
<bvad> I'd check out if it was possible to either modify the code for the unity sound settings, or replace it by the stock gnome one. Sorry for the multiple messages
<seb128> bvad, you should report a bug and get that fixed
<seb128> bvad, you can get the GNOME dialog by running "XDG_CURRENT_DESKTOP=GNOME gnome-control-center sound"
<jamespage> cjwatson, would you be happy for me to sponsor a new upstream release of biosdevname into quantal?
 * jamespage notes that cjwatson is the maintainer of the package
<cjwatson> jamespage: Go ahead
<jamespage> cjwatson, OK
<jamespage> thanks
<cjwatson> np, thanks for taking care of that
<bvad> seb128, thank you. I think the bug was already reported
<seb128> bvad, do you have the number? is that bug #986547
<ubottu> Launchpad bug 986547 in gnome-control-center (Ubuntu Precise) "[soundnua] can't change the output to 5.1" [High,Triaged] https://launchpad.net/bugs/986547
<bvad> seb128, let me look into it
<bvad> seb128: It looks more like bug #974963
<ubottu> Launchpad bug 974963 in alsa-driver (Ubuntu) "[soundnua]: hdmi audio missing in sound settings" [Low,Incomplete] https://launchpad.net/bugs/974963
<seb128> bvad, thanks, I will try to see if we can get those issues addressed in a stable update
<bvad> seb128: A solution might be to always show the HDMI audio option, even without a cable plugged in, like the stock gnome settings does. Though this is sort of ignoring the problem at it's core...
<tkamppeter> doko, hi
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<larsduesing> jamespage: kthx :-)
<jamespage> larsduesing, np
<doko> tkamppeter, see my email about pysmbc, pycups is in the works. would be nice if you could do system-config-printer yourself
<larsduesing> oh... Can anybody describe me what: https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/aiccu/quantal-201206042007 means? "Created by Ubuntu Package Importer on 2012-06-04 and last modified on 2012-06-04"
<larsduesing> an unmerge proposal by package importer?
<SpamapS> ugh, collectd is such a bear to get compiled
<SpamapS> its almost as bad as PHP with all the libraries to link
<SpamapS> larsduesing: that means there were pending changes for aiccu in that branch when somebody uploaded something else
<larsduesing> most certainly me... (as I am the only one working on that package...)
<larsduesing> ok, looking after that
<SpamapS> larsduesing: its worth bumping the uploader that they need to check the branch before uploading. :)
<larsduesing> :P
<larsduesing> no, there were some troubles with a bug with bzr-builddeb
<larsduesing> https://bugs.launchpad.net/bzr-builddeb/+bug/1006611
<ubottu> Launchpad bug 1006611 in bzr-builddeb "quilt patches are not reapplied after merge with debian" [Undecided,Confirmed]
<larsduesing> I think it's all about that
<hallyn> slangasek: are there any plans of jumping qemu-linaro to 1.1 during quantal?
<hallyn> if i upload the new qemu-kvm 1.1, the one thing i've foudn will break is qemu-kvm-spice.  i believe bc of a bios mismatch.  if need be i should be able to have qemu-kvm-spice temporarily use a different bios...
<xnox> larsduesing: and even if you apply them yourself... they get different fileids and conflict on merge
<larsduesing> somehow... yes
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<hrw> does someone know when ARM became equal to x86 in Ubuntu?
<stgraber> jk-: pong
<barry> debfx: i think you're right.  should be an easy fix.
<SpamapS> doko: is it possible the recent gcc 4.7 update fixed some problems with hand-optimized assembler that would go all the way back to gcc 4.6?
<SpamapS> hrw: what do you mean "became equal" ?
<vibhav> mdeslaur: ping
<hrw> SpamapS: packages.ubuntu.com listing arm packages atleast
<hrw> SpamapS: I can live with ports.ubuntu.com != archive.ubuntu.com but so far arm is second citizen
<SpamapS> hrw: I'd guess sometime around 10.10 ?
<SpamapS> but I really don't know :p
<hrw> SpamapS: 10.10 is past ;D
<seb128> ev, hey, whoopsie question for you ... the issues are reported only once or does the same issue keeps being reported every time it happens to the user?
<SpamapS> hrw: from my point of view, its definitely *not* a second class citizen
<ev> seb128: the intention is for the report to be sent every time it happens to the user, but I believe apport stops showing after the 2nd or 3rd report at the moment
<ev> I believe mpt has a bug open for this
<seb128> ev, ok, I'm wondering why the numbers of errors.ubuntu.com have dropped so low compared to after release for some issues which didn't get fixed
<ev> seb128: apport's been broken
<seb128> ev, I assume that's because we get reports only from new users
<seb128> ev, in precise?
<ev> quantal
<ev> but yeah, interesting
<ev> I see your point
<ev> well, fixing apport to always send the report will fix this in any case
<vibhav> If a change in an ubuntu delta is transfered to debian, do I need to mention that the change has been tranfered to debian
<ev> I just haven't had the time to do it myself
<seb128> ev, right, thanks for confirming
<xnox> vibhav: reamaining changes; dropped changes; new stuff:
<vibhav> thanks xnox
<seb128> ev, it also mean the current view is not a reflect of what issues are the most frequents atm
<xnox> vibhav: if all changes are dropped and no new onces introduced -> requestsync
<ev> yeah
<seb128> ev, btw is the "if all updates were installed" setting working? it seems to not, like if I unselect "actual" there is no graphs displayed and the report is not changing compared to when "actual" was selected
<ev> seb128: not yet
<seb128> ev, or asked different "can I select the month view and select out fixed issues"?
<ev> can you elaborate? I don't follow
<seb128> ev, if I go on https://errors.ubuntu.com/, change the "Most common problems in the past  " combo to "month" ... does that include fix commited,released bugs?
<seb128> ev, like the ones that collected 5000 tickets during 2 weeks but are fixed for 3 days?
<ev> seb128: yes - I have a branch that fixes this, but haven't landed it on trunk yet due to issues using launchpadlib
<seb128> ev, ok, I guess the simple question was "is the errors.ubuntu.com a view of all errors or of the non fixed errors"
<seb128> I guess it's all errors atm
<ev> it currently greys out those rows
<ev> all at the moment, yes
<ev> currently> in this branch I have
<seb128> ev, ok, excellent, thanks!
<seb128> ev, that's enough questions from me for today, keep up the good work ;-)
<ev> but that's just to see if we get any false positives. We may end up permanently hiding those
<ev> heh, thanks!
<ev> and thanks for the constant input
<ev> it definitely helps direct development
<ev> I just need a small army to do everything we need done
<hrw> SpamapS: arm as architecture when it comes to support is first class. but when it comes to infrastructure support it still 2nd class
<seb128> I know that feeling ;-)
 * ev goes back to teaching errors.u.c to expose "create bug" links where we don't already have a bug number
<tsdgeos> jdstrand: about https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/711061 i wonder if i should mention also that we only ship 1.3 when current version is 1.5 ?
<ubottu> Launchpad bug 711061 in openjpeg (Ubuntu) "[MIR] libopenjpeg2" [Wishlist,Confirmed]
<hrw> SpamapS: for example: try to find out which version of omap4 kernel is recent one...
<seb128> ev, oh, another quick one, is there a way to point an errors.ubuntu.com to a bug number? or to correct a wrong reference?
<ev> seb128: that's what I'm working on right now. It's fairly involved though and requires a new backend to crash-digger (so that the apport duplicate db and errors.ubuntu.com duplicates share bug references)
<jdstrand> tsdgeos: yes please
<seb128> ev, ok, things as on track I see, I will let you work, thanks again for the replies ;-)
<ev> seb128: anytime! cheers
<doko> Spads, I can't see anything obvious ...
<doko> SpamapS, ^^^
<Spads> Â°.Âº
<Spads> âº
<doko> spam ...
<ev> lol
<SpadapS> \ã /
<tsdgeos> jdstrand: done
<vibhav> Spads: Please stop that
<jdstrand> thanks
<jdstrand> SpamapS: I like that last one :)
<jdstrand> I don't know what it is, but I like it
<kelemengabor> pitti: hi, got a few minutes?
<kelemengabor> according to https://wiki.ubuntu.com/Translations/PreciseLanguagePackReleaseSchedule it is time to move some updated langpacks to -proposed for the second language pack update cycle - could you do that?
<kelemengabor> okay, we are a week late, but better late than never :)
<kelemengabor> I'll modify the wiki page and send out the call for testing mail - dpm, are you happy with that?
<dpm> kelemengabor, I definitely am, thanks for staying on top
<larsduesing> hmm, all aiccu bugs but one suggestion are incomplete or invalid. Mission accomplished? :-)
<zul> bdmurray: ping
<mpt> mterry, to try and answer your question: This morning I had Update Manager offering to give me a "partial upgrade", i.e. updates that didn't include glib. It turned out (once I ran Synaptic) that all it needed to do, to install all updates, was remove a -dbgsym package.
<mpt> mterry, I reported bug 955022 about abolishing the "Not all updates can be installed"/"Partial Upgrade" dialog, but it needs technical sanity-checking.
<ubottu> Launchpad bug 955022 in update-manager (Ubuntu) ""Not all updates can be installed" requires a decision most people can't make" [Medium,Confirmed] https://launchpad.net/bugs/955022
<tkamppeter> doko, OK. Is there somewhere documentation about migrating Python 2 -> 3?
<cjwatson> tkamppeter: http://wiki.ubuntu.com/Python/3
<tkamppeter> cjwatson, thanks.
<xnox> mpt: partial upgrade is generally not a good idea. wait for the archive to settle. Generally it means that a library transition is still in progress.
<xnox> mpt: oh just one -dbgsym package
<xnox> mpt: use command line $ apt-get dist-upgrade
<xnox> =)
<mpt> mterry, for updates that would remove some other package, Ubuntu Software Center potentially has that issue as well, with the Conflicts field. So probably it should be part of Aptdaemon. Next week I'll be going through error and edge cases like that one with glatzor.
<mpt> xnox, that is a concise demonstration of why we should get rid of the dialog, yes. ;-)
<mterry> mpt, OK.  Yeah, your proposal in that bug looks reasonable, but would require some thinking of how to present packages that will be removed.  The normal "Updates Available" screen does that now
<mpt> mterry, Synaptic's does, but I don't remember ever seeing update-manager offer to remove stuff.
<mterry> Sorry, does NOT do that now
<mpt> ok :-)
<mterry> mpt, ^
<mterry> I hate that screen.  It's odd too because "Partial Upgrade" is actually a more complete update than a normal update.  Not very partial
<mterry> I'm assuming it's using Upgrade in the distro upgrade sense
<mpt> ev, seb128: The bug where you don't get repeat reports is bug 989800
<ubottu> Launchpad bug 989800 in apport (Ubuntu) "Error alert stops appearing for the same crash after a while" [Undecided,Confirmed] https://launchpad.net/bugs/989800
<ev> mpt: thanks!
<seb128> mpt, thanks
<mterry> mpt, FYI I'm assuming that in the SoftwareUpdates spec where we say something like "Ubuntu 12.04" the updater should say "Xubuntu 12.04" if appropriate.
<mpt> mterry, yep
<mterry> mpt, I'm trying to figure out how to determine which it is...  But lsb_release seems to give the same output for both.  :(
<cjwatson> That's necessary
<mterry> cjwatson, the lsb_release bit?  Do you know of a good way to determine what the system was installed as?
<stgraber> mterry: you don't really have a way of knowing. One way would be to look at the install media in /var/log/installer but it's not necessarily there nor it's reliable. Another is to look for the -desktop packages but there again, you can have more than one installed
<mterry> stgraber, yeah, I would be happy enough to know what it was at first installation
<cjwatson> What he said
<mterry> Seems silly that we can't do that
<mpt> Plymouth thinks I'm running Xubuntu solely because I installed XFCE
<xnox> one way to do this is to check what type of desktop session is running
<Daviey> mpt: can't be worse than when everyones splash screen was switched to a different flavour by accident :)
<xnox> if I have both KDE/Kubuntu and XFCE/Xubuntu - if I'm running update in the XFCE session say 'Xubuntu', if the KDE session say 'Kubuntu'
<cjwatson> That probably isn't awful, yeah
<xnox> as I would expect the frontend to match current desktop sessions, regardless of what packages are installed and which media was used
<mterry> We do have XDG_CURRENT_DESKTOP for that now
<xnox> excellent =)
<stgraber> mterry: /var/log/installer/media-info will contain what was used to install the system, but only for these installed from a media. If you netinstall you won't get it.
<xnox> stgraber: or debootstrap the way some of my friends prefer to install ubuntu.....
<stgraber> mterry: (had to check in a VM as all my systems are netinstalled from PXE and don't have that file)
<Daviey> OEM installs probably don't expose that?
<mterry> stgraber, thanks!
<mterry> Sounds like I can't rely on that stuff and should just use the current desktop environment and map them to derivative names myself
<stgraber> Daviey: I can't remember us explicitly stripping it for OEM installs in Ubiquity, but it's perfectly possible that OEMs wipe /var/log on their installs before imaging
<cjwatson> XDG_CURRENT_DESKTOP> of course provided the updater isn't running inside something that strips the environment, like sudo
<stgraber> mterry: you know I'll open a bug because Edubuntu won't work if you do that, right? :) same thing for ubuntu studio I believe
<cjwatson> I think you need heuristics whatever way you slice it.
<stgraber> mterry: we have multiple flavours running with unity, multiple flavours running with xfce and at the moment, only one flavour running kde. So you'll need some extra logic to figure out exactly what the system is :)
<cjwatson> Two flavours - there's Kubuntu Active.
<stgraber> ah right
<mterry> stgraber, :(
<stgraber> starting to wonder if it'd make sense to have some file storing the name of the flavour installed and use the good old alternatives to have it changed to the right value by the -artwork packages of the various flavours
<stgraber> that'd probably make it consistent with what's done for plymouth, distributor-logo and some other things
<mterry> ahem, got dropped
<mterry> stgraber, an alternatives would be good
<azorin> Hello everyone! I'm having some issues with building a package on Launchpadl.
<mterry> stgraber, maybe I should post to ubuntu-devel and get some feedback.  But seems simple enough to do
<Daviey> Unrelated, but i'd quite like to see something like, if [ "$(pidof X)" ] ; then echo "Desktop Running" ; fi .. added to apport bugs.
<mterry> Daviey, you mean to determine which desktop environment is running?
<Daviey> mterry: no, to determine IF X is running.. Metric that it might be a desktop or server.
<mterry> ah
<mvo> mterry: you can look at the installed metapackages
<stgraber> mvo: no, see above, it's not reliable :) (edubuntu-desktop depends on ubuntu-desktop and some others are co-installable)
<mterry> mvo, and just iterate on all the known ones?
<mvo> yes, that is what the release upgrader is doing
<Daviey> stgraber: Surely some logic can be determined based on installed as a dep or explicitly.. not clean, but there is certainly hints that could be formulated
<stgraber> Daviey: right
<mterry> mvo, OK, so it looks like DistUpgradeCache has code to guess the best meta package.  And then we can just map to names...
<azorin> I'm having some issues with building a package on Launchpad. I would greatly appreciate any suggestions if anyone may have any. Full details of the problem are here: http://goo.gl/mrVdl
<SpamapS> doko: indeed, I was mistaken and I'm still experiencing my problems
<mterry> azorin, #ubuntu-motu might be a better channel?
<azorin> Thanks mterry! I'll check it out right now
<mterry> azorin, but try moving the xwinwrap.o part of the link line before the LDFLAGS
<didrocks> ev: is there any particular order for e.ubuntu.com to show the stacktraces?
<didrocks> ev: like, I want to see the latest one
<ev> didrocks: the instances of a problem?
<ev> off a bucket page
<ev> I should really rename that to problem
<didrocks> ev: right :)
<arges> SpamapS,  hi. Noticed some packages are ftbfs that depend on php5  (>= 5.4.1). Was wondering when that will be bumped? thanks
<didrocks> ev: like, I'm almost sure that I fixed oneconf0.2.6.90.2.8.1
<ev> not at present - there's a bug there in that they're ascii sorted rather than sorted by the time component of the uuid
<didrocks> grrr, space missing from copy and paste
<ev> I noticed that last night
<ev> it's a tricky one to fix, but I will get to it once things calm down
<didrocks> ev: it seems that e.u.c it telling that it's still present on 2.8.1, which isn't really possible from the new code, so I wanted to see that particular stacktrace :)
<infinity> SpamapS: Any plans to merge php5 soon (you, or someone else...)
<ev> (cassandra does not support changing the comparator - you need to migrate the data to a new column family)
<ev> didrocks: if this is precise, someone is likely hitting the bug wherein if you upgrade a package while the binary is running
<ev> and it crahses
<ev> it will use the new package version
<ev> rather than the version the binary was actually from
<didrocks> ev: yeah, same issue that what we have with old good apport?
<ev> pitti fixed this in quantal
<didrocks> oh?
<ev> yes
<didrocks> how so?
<ev> in quantal it doesn't send the report :)
<didrocks> ok, it knows "the upgrade has been done in this session, don't send the crash"
<ev> exactly
<SpamapS> infinity: Suhosin is still not available for 5.4
<didrocks> excellent, that would help :)
<SpamapS> infinity: I had wanted to treat w/ the security team before dropping it
<SpamapS> infinity: though I'm pretty sure we're dropping it.. *everybody* else has.
<infinity> SpamapS: Ahh.  Fair enough.  Seems like a bunch of autosyncs are build-depending on newer php5-dev, so would be nice to sort it.
<didrocks> ev: but I still wanted to double check, so if you can tackle the other issue (or just order if you know the timestamp as a quick workaround), that would be awesome :)
<SpamapS> infinity: but yes, I'd like to get that resolved soon.
<SpamapS> infinity: yeah, soon.
<infinity> SpamapS: I was against adding suhosin in the first place, but I lost that argument.  or gave up caring.
<ev> didrocks: I fully intend to
<ev> I was polishing the bucket/problem page last night
<ev> so it now displays python tracebacks there, as well as the thread stacktrace, IN FULL COLOR ;)
<didrocks> ev: yeah, I noticed that, it's nice! :)
<seb128> ev, didrocks: the apport fix for the "don't send reports for binaries that got upgraded" has been SRUed as well (it's in proposed waiting to be verified)
<ev> and noticed that said giant list of uuids is A) not labelled, and B) not time-sorted
<ev> right now it's just grabbing the first 100 ascii-sorted
<ev> but I'll fix the time sorting and put in pagination
<didrocks> excellent, thanks ev!
<didrocks> seb128: wooow! ;)
<ev> sure thing!
<didrocks> ev: also, I guess you are aware/hear about a lot of sso failure when trying to access a bucket page?
<ev> no? Are you running into this?
<didrocks> yeah, a lot
<didrocks> like, 1/3 of my connexion works
<didrocks> the rest, I get denied access
<SpamapS> infinity: it has mitigated almost every major flaw in PHP..
<didrocks> or "errors"
<didrocks> also, it reasks me for sso each time I'm trying to access a bucket
<SpamapS> infinity: not totally prevented it, but most of the time reduced remote code execution to DoS
<ev> yes, the reasking thing is because we're currently using an IS-provided open id wrapper
<SpamapS> infinity: that said, the maintenance burden is getting higher as Stefan Esser cares less and less ;)
<didrocks> most of the time, as I don't spend a lot of time on the page, it's fine, but still frustrating
<ev> and so there's no caching of credentials
<didrocks> ev: that would be fine if I don't end on this constant errors when logging in
<ev> I'm going to fix that, but doing it with python-openid-auth requires persisting information to the db, via an ORM, which I'm not fond of
<ev> yeah, that one is surprising
<didrocks> yeah, I understand :/
<ev> I'll talk to webops and see if they get logs for these
<didrocks> ev: I'm in London the whole next week, we can have a look together mayve?
<didrocks> maybe*
<ev> didrocks: yes, definitely
<didrocks> ev: excellent, thanks a lot :)
<ev> no problem
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<zul> slangasek: ping
<larsduesing> ahm... who is to be informed on "bugs" in man-pages?
<larsduesing> "sponsor-patch.1"
<larsduesing> "Should any checks (or the build fail), the user has an option  to  edit the patched source and try building it again
<larsduesing> I think the word fail should be outside of the brackets :-)
<infinity> doko: *poke*
<mhall119> ScottK: ping
<infinity> larsduesing: Ideally, you should file the bug with Debian (unless it's an Ubuntu-only package).  Carrying a delta for small manpage fixes isn't generally worth the hassle.
<larsduesing> infinity: sponsor-patch is part of ubuntu-dev-tools
<larsduesing> :)
<infinity> larsduesing: Oh.  Right then.
<infinity> larsduesing: Then file a bug with a patch in launchpad. ;)
<larsduesing> So I will file a bug with bzr branch *G*
<dobey> larsduesing: i suppose you should push a branch and propose it for merging into the upstream tree or whatever :)
<larsduesing> I'll do.
<larsduesing> But should I really do a changelog-entry for an edit of 1 line in the man-page?
<slangasek> pitti: urlopen> hmmm; I got a rather opaque popup about "module something something named urlopen", and grepping the code this looked like the bit that was to blame, but maybe there's another bug lying somewhere still?
<slangasek> zul: pong - but I'm off today, please just ask your question :)
<slangasek> hallyn: qemu-linaro 1.1> well I intend to get us up to date with the releases for quantal, but I know I'm behind, sorry about that
<zul> slangasek: ah it was about an SRU review but I can find someone else
<hallyn> slangasek: would be ok either way, was just wondering which way i'd have to go.  thanks
<slangasek> pitti: RT 52633> it seems unlikely that we'll be able to get a speedy resolution to that, AIUI it's taking a while to get new hardware through the system... I can certainly give it a priority bump but it seems to already /have/ a priority bump from IS
<larsduesing> dobey, infinity: done :)
<larsduesing> https://code.launchpad.net/~lars.duesing/ubuntu/quantal/ubuntu-dev-tools/ubuntu-dev-tools_correct-sponsor-patch-manpage
<larsduesing> (but didn't create a bug for that...)
<bryceh> I've got a package version 2.5 in precise, 2.7 in quantal, that I'm both the author and package maintainer of.  I want to do an SRU to precise; what's the best way to craft the version number?  2.5ubuntu1?  2.5-0ubuntu0.1?  2.5.1?
<infinity> bryceh: It's native?
<infinity> bryceh: And Ubuntu-specific?
<infinity> bryceh: If both of those are true, 2.5.1, or 2.5.0.1, or 2.5.0.12.04, or anything along those lines. :P
<infinity> bryceh: If it's not Ubuntu-specific, and just happens to be in sync with Debian, 2.5ubuntu1 (or ubuntu0.12.04, or whatever)
<bryceh> infinity, yes native and ubuntu-specific
<bryceh> infinity, thanks, 2.5.1 it is :-)
<ScottK> mhall119: pong
<mhall119> ScottK: key, I'm working on a blog post about the new 'Download for Ubunt' buttons in which I'm going to be telling upstreams what to do in order to get newer versions of their apps into precise-backports
<mhall119> and I wanted to check and see if there is anything specific that I should include or warn against
<ScottK> The first thing about backports is we backport from the development release first.
<ScottK> So before you get to precise-backports, you have to get to quantal.
<ScottK> Also we require some basic testing in the target environment (that it builds/installs/runs).
<ScottK> This is not generally for packages with lots of reverse dependencies and the rdepends will have to be tested too.
<ScottK> broder or Laney: Can you think of anything else?
<mhall119> thanks ScottK
<micahg> mhall119: please advise people to use the requestbackport script from ubuntu-dev-tools when requesting a backport, it'll include information on what testing needs to be done as well
<mhall119> micahg: I will
<mhall119> micahg: for upstreams who aren't running Ubuntu, can they just file a bug against the backports project, and then someone else can update the bug description with the requestbackport output?
<micahg> mhall119: I suppose, I think broder was working on something that makes that easier for us
<broder> micahg: for that specifically i thought i talked tumbleweed into doing that
<broder> (requestbackport --rewrite)
<micahg> broder: oh, ok, that works as long as someone is doing it :)
<mhall119> is that a work in progress, or something already available?
 * micahg doesn't see it in trunk yet
<mhall119> ok
<Laney> mhall119: you should link to https://help.ubuntu.com/community/UbuntuBackports and https://wiki.ubuntu.com/UbuntuBackports
<mhall119> thanks Laney
<Laney> np
<mhall119> can someone verify for me that packaging fixes are allowed at any time, they don't need backports or SRUs?
<micahg> mhall119: hrm?
<mhall119> say, if a package was missing a dependency or something
<micahg> where?
<mhall119> hypothetical
<micahg> hypothetically where? :)
<mhall119> if an upstream app developer says "Hey, people can't use the package for my app in Ubuntu because it's missing a dependency on libfoo", we can just add that in a -ubuntu2 version of the package right?
<micahg> mhall119: it depends, it might need an MIR
<mhall119> MIR?
<micahg> !mir | mhall119
<ubottu> mhall119: mir is Main Inclusion Report - see https://wiki.ubuntu.com/MainInclusionProcess for more information.
<mhall119> what if it's in Universe?
<micahg> mhall119: if it's in a stable release, you'll need to do an SRU and give the justification for the addition
<mhall119> ok, so SRU is still required, even if the app itself wasn't changed, just it's packaging
<micahg> mhall119: the package?, then in the dev release you could add it most likely
<mhall119> what if it's correct in the dev release, but wrong in the stable release?
<micahg> mhall119: yeah, the SRU process is meant to avoid regressions and breakage, the bar should be pretty low for a missing dependency though
<micahg> mhall119: you can just propose an SRU assuming it's in the same component
<micahg> err...assumingthe dependency is met in the appropriate components
<mhall119> ok
<mhall119> I'm just trying to let upstream devs know what their options are if our packages aren't giving them the best user experience
<micahg> mhall119: missing dependency can be easy to fix (much easier than a new upstream version :))
<mhall119> right, new upstream should be backported instead, right?
<micahg> usually, yes
<Laney> it doesn't really matter what the fix is
<Laney> the SRU process is the same
<Laney> mhall119: I think you should mention that SRUs can contain bug fixes to the application's code as well as to the packaging
<Laney> and it doesn't really 'lock' versions like you said
<micahg> mhall119: I'm also a little worrisome of "  So if weâve done something wrong on our end that is giving your app a hard time, weâll fix it", in most cases, we get stuff unchanged from Debian, so it would take someone who cares to submit the SRU (not just a bug report as we're drowning in those)
<micahg> mhall119: and in case you're interested, the bottom paragraph appears funny in khtml (akregator rendering engine)
<micahg> hmm, looks fine in konqueror so must be an akregator quirk
<micahg> er..not exactly fine, but not the same weird
#ubuntu-devel 2012-06-16
<mdeslaur> vibhav: yes?
<aviraldg> Hello. Anyone around?
<larsduesing> yes
<aviraldg> According to the channel's topic, "Dev of Ubuntu (not support or app devel)"
<aviraldg> Where would be a good place for Ubuntu-related app-devel help?
<larsduesing> ahm
<larsduesing> what sort of app-devel-help?
<larsduesing> fixing problems?
<larsduesing> or creating new apps?
<aviraldg> (fyi: need some help with figuring out pygtk)
<larsduesing> oh
<larsduesing> aehm
<larsduesing> wait a sec
<aviraldg> (not a newbie, have quite some experience developing stuff, but just not gtk stuff)
<aviraldg> oh lol
 * aviraldg heads over to #ubuntu-app-devel
<larsduesing> good idea
<larsduesing> but there is a specialized channel for pygtk somewher *wait a sec*
<aviraldg> couldn't see the entire topic :P
<aviraldg> #pygtk looks like a ghost-town
<larsduesing> If you can't see the whole topic - type "/topic"
<larsduesing> it shows the topic in the whole beauty
<larsduesing> :)
<larsduesing> #pygtk on irc.gnome.org
<larsduesing> would it be
<larsduesing> another irc server
<aviraldg> thanks :)
<larsduesing> np
<larsduesing> (but saturday morning / friday night is not the best time to get too much people in irc....)
<larsduesing> aviraldg: more information is found on http://www.pygtk.org/feedback.html
<aviraldg> Yeah, I've seen the docs and stuff.
<larsduesing> ok
<vibhav> Good Morning
<vibhav> Daviey: ping
<infinity> jdstrand: If you get bored this weekend, the MIR for libfcgi-perl is the only thing standing between us and a beer on quantal_probs, now that I fixed a few other bits tonight.
 * infinity sleeps.
<infinity> Riddell / ScottK: plasma-mobile {build-,}depends on some NBS stuff.  Is there a new upstream that fixes that?
<infinity> Riddell / ScottK: Seems to be that kde-runtime dropped a -dev and some libraries.
<infinity> Riddell / ScottK: Oh, hrm, perhaps switching the build-dep to nepomuk-core-dev will make it happy.
<Daviey> vibhav: hello?
<infinity> rbelem: Hey, looks like quantal needs a new plasma-mobile git snapshot to deal with the reorg of nepomukdatamanagement stuff (and it will also need a build-dep change from kde-runtime-dev to nepomuk-core-dev while you're in there)
<infinity> Riddell / ScottK: See above, looks like plasma-mobile needs a new git snapshot to be happy.
<infinity> rbelem: Until it's rebuilt with a new snapshot, plasma-mobile is keeping some cruft in the archive, so it would be nice to get it sorted.
<larsduesing> hmm - in #ubuntu-bugs:
<larsduesing> 11:26:38 <econnell> is there any way to escalate a bug?  bug #82853 has existed since 2007 and is still a problem... but it was fixed  in debian in april 2010
<ubottu> Launchpad bug 82853 in openldap (Ubuntu) "Add support for the smbk5pwd overlay" [Wishlist,Triaged] https://launchpad.net/bugs/82853
<Daviey> 	1:3.5.4~rc2-0ubuntu1~ppa1	
<Daviey> /usr/lib/libreoffice/program/soffice.bin:*** glibc detected *** /usr/lib/libreoffice/program/soffice.bin: free(): invalid pointer: ADDR ***
<Daviey> 778072
<Daviey> erk
<vibhav> infinity: ping
<larsduesing> Hmm, How advisable is trying https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally to get to know the things behind the scenes?
<larsduesing> or will it make me going mad? *g*
<jfroebe> anyone know where couchgrid resides now?  I'm going through the quickly tutorials and it seems to have been moved from desktopcouch.records.couchgrid
<JanC> jfroebe: I don't think desktopcouch is still supported?
<jdstrand> infinity: noted
<jfroebe> thanks JanC
<JanC> jfroebe: desktopcouch is being replaced by u1db in UbuntuOne, so even if it's still installable, it's a dead end I suppose
<JanC> unless somebody can correct me on that   ;)
<vibhav> stgraber: ping
<bkerensa> SpamapS: Hey working on a bug here in ceph was wondering if you had any idea what is the issue? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677626
<ubottu> Debian bug 677626 in ceph "ceph - Unwarranted restriction of architectures" [Serious,Open]
<rbelem> infinity, oki i will update it :-)
#ubuntu-devel 2012-06-17
<infinity> rbelem: Cheers.
<lollisoft> Hi, did anyone know if I can avoid using a preprocessor command in a typical make & configure & make install build? I am trying to compile unixODBC, but it may be a general question of posibility.
<sladen> lollisoft: start with  sudo apt-get build-dep unixodbc-bin ; apt-get source unixodbc-bin   if you need to rebuild the package
<sladen> lollisoft: but ideally, work out what you need that is not already in the pre-packaged .deb and try and get it fixed for everyone at the same time
<lollisoft> I think the issue is not known in the Linux world, as I try to build a multi architecture binary on Mac. I thought there is any way to skip intermediate preprocessor steps as these will produce asm code that is not possible when one arch is i386 and the other is ppc. I have got another hint to use two distinct builds and then use lipo. RTFM :-)
<vibhav> !language > lollisoft
<ubottu> lollisoft, please see my private message
<ion> vibhav: â¦seriously?
<micahg> yeah, it was totally abbroviated
<micahg> *abbreviated even
<ion> F!
<ion> F! F! F!
<micahg> and we can pretend it means Fplease just like in JFDI :)
<vibhav> ion: yup
<micahg> we even have a package with that in the archive
<micahg> !info rt3.8rtfm
<ubottu> Package rt3.8rtfm does not exist in precise
<micahg> !info rt3.8-rtfm
<ubottu> rt3.8-rtfm (source: rtfm): FAQ Manager for Request Tracker 3.8. In component universe, is optional. Version 2.4.3-1 (precise), package size 110 kB, installed size 1276 kB
<vibhav> ...
<vibhav> But thats still not family friendly
<micahg> there's nothing explicit in that description
<ion> vibhav: Please donât use the bad letter in â*amily *riendlyâ.
<elky> vibhav, the f in rtfm can mean several things. this isn't a support channel, so the main reason we ask people to refrain from 'rtfm' isn't quite relevant here.
<m4n1sh> Ampelbein: ping
<lollisoft> Yey - by
<vibhav> jamespage: You ther?
<penguin42> what's the 'mdp' block device (254) - not listed in the upstream kernel device list
<shadeslayer> skaet_: do you have a moment?
<ScottK> lifeless: https://help.launchpad.net/Packaging/BuildScores needs updating for the build prioritization changes cjwatson recently landed, but I don't seem to have access to edit it.
<tumbleweed> Laney: are you waiting for broder to review https://code.launchpad.net/~laney/ubuntu-dev-tools/debuild-no-debemail-1007042/+merge/110189 ?
<broder> oh, am i supposed to be reviewing it?
<tumbleweed> he flagged you as a reviewer
<lifeless> ScottK: ~launchpad-doc gates that, care to join ?
<Laney> only because it was backportpackage
<Laney> anyone can review it
<tumbleweed> in that case, landing it
<broder> reviewed
<broder> fwiw
<Laney> ta
<Laney> wait
<Laney> doesn't it need to check that DEBEMAIL is in env?
<tumbleweed> err, yes
 * tumbleweed does that because I just committed it
<Laney> teehee
<ScottK> lifeless: Not really.  This is the first time I've ever felt the need, so it's not a common need.
<lifeless> ok, so, I odn't know the details of the changes, could you at least file a ticket on answers.l.n/launchpad, for the maintenance squad to pickup and apply?
<hyperair> could a unity user run "notify-send --hint=int:transient:1 foo" and tell me if there's anything different from a normal notification "notify-send foo"?
<ion> Doesnât seem to be.
<hyperair> okay, thanks
<hyperair> that means i can safely set the hint for gnome-shell and not worry about it affecting unity.
<SpamapS> bkerensa: re ceph and leveldb.. I wouldn't worry too much about that
<SpamapS> bkerensa: what specifically are you not sure of tho?
#ubuntu-devel 2013-06-10
<shakaran> Is present some member of notify-osd team here? I would some dev comment about this bug https://bugs.launchpad.net/liferea/+bug/1189281
<ubottu> Launchpad bug 1189281 in notify-osd (Ubuntu) "notify-osd crashed with SIGSEGV while checking bubble private mode G_TYPE_INSTANCE_GET_PRIVATE in bubble_get_id()" [Medium,New]
<mwhudson> has anyone nicked the python systemtap support from fedora for debian/ubuntu?
<vipzrx> hello
<vipzrx> does anyone port the ubuntu core 12.04 to the pandaboard es ?
<vipzrx> Guest68: hello
<vipzrx> awz: hello
<vipzrx> anybody here ?
<foka> vipzrx, Hello!
<vipzrx> foka: are you a robot ?
<foka> vipzrx, Are you?  :-p
<sarnold> vipzrx: I installed 12.04 LTS on my Pandaboard ES without trouble
<vipzrx> ok ! I need your help
<sarnold> I can try, but since the whole thing Just Worked, I didn't actually learn much about the pandaboard itself in the process :)
<foka> vipzrx, It seems there are already many success stories of installing Ubuntu 12.04 on PandaBoard ES.  A quick Google search returns various articles, such as this one: http://softswagen.wordpress.com/2013/02/21/how-to-install-ubuntu-12-04-lts-on-pandaboard-es/
<vipzrx> http://omappedia.org/wiki/OMAP_Ubuntu_Core
<vipzrx> I follow this url
<sarnold> (I've also upgraded to 12.10, so I don't have 12.04 LTS answers at the ready...)
<sarnold> vipzrx: if you don't mind getting the full desktop environment instead, you can start here: http://cdimage.ubuntu.com/releases/12.04/release/
<sarnold> vipzrx: Texas Instruments OMAP4 (Hard-Float) preinstalled desktop image -- you can just dd that to a CF card and boot
<vipzrx> sarnold:  thank you for your answer in advance
<vipzrx> the url you sent me is ok
<vipzrx> and I have been successfully make the  ubuntu desktop version running on my panda4460
<vipzrx> now I want to build from the ubuntu core to reduce the size of ubuntu
<sarnold> vipzrx: aha :)
<sarnold> vipzrx: are you doing this just for yourself, on the one machine, or for a product or something that must be easily rebuildable, for lots of people or products?
<sarnold> vipzrx: you could just start with your desktop and apt-get purge packages that you do not want to keep.
<vipzrx> I do it for myself
<sarnold> okay :) and do you want to do it to learn more about the pandaboard, or do you just want the size reduction? :)
<vipzrx> both
<vipzrx> http://paste.ubuntu.com/5750547/  the log from the serial console
<sarnold> aha, then going through the more complicated instructions on the omappedia website make sense..
<vipzrx> when I boot the pandaboard
<vipzrx> he he
<sarnold> hrm, I wonder why you don't have a modules.dep file.
<vipzrx> in the urlï¼å¾åis
<vipzrx> in the url I refered , there is nothing  about it
<vipzrx> $ ls lib/modules/
<vipzrx> $
<sarnold> oh! you don't have -any- modules. that's definitely odd.
<sarnold> the linux-image-3.2.0-1412-omap4 package should have installed the modules..
<vipzrx> how can I do it to install the lost package ?
<sarnold> vipzrx: normally, I'd say to stick the memory card into another computer, mount it, chroot there, and then run dpkg -i to install the package.. but that will be difficult if you do not have a second ARM board around..
<sarnold> vipzrx: how much work would it be to start over? (at least, I assume their rules _can_ get you to a booted system)
<vipzrx> ok
<vipzrx> https://wiki.ubuntu.com/Core/InstallationExample
<sarnold> vipzrx: sorry, it is time for me to go; have a good day, I hope you can solve this quickly :)
<sarnold> vipzrx: oh! nice
<sarnold> vipzrx: step #6 is very much like I suggested .. but I think it would really only work well if you have another ARM computer :)
<vipzrx> ok thank you
<sarnold> vipzrx: good luck :)
<pitti> Good morning
<ricotz> pitti, morning
<ricotz> pitti, did you know about problems with network-manager after updating to systemd 204-0ubuntu3
<pitti> ricotz: no, I don't; it seems to work fine here at least, and I didn't hear complaints yet
<pitti> ricotz: ubuntu3 didn't change anything specific at runtime, that was just a d-i fix
<ricotz> pitti, i see, i reverted to 204-0ubuntu2 at the weekend to make it work again
<pitti> cjwatson: ^ thanks for this!
<ricotz> could be related to using 3.10rc4 though
<pitti> cjwatson: BTW, on Friday you said that pam_getenv was broken; it seems to work quite well here, what did you mean specifically? there's no debian or ubuntu bug about it
<ricotz> pitti, ok, then it might be a glitch caused by something else
<tvoss> cjwatson, ping
<dholbach> good morning
<tvoss> dholbach, guck guck :)
<dholbach> hey tvoss :)
<mlankhorst> morning
<pitti> rbasak, cjwatson: I have http://paste.ubuntu.com/5750880/ now, tested in current sid and saucy; I can't see anything wrong with pam_getenv (but I protected the call against failures anyway)
<mitya57> Mirv: Can we sync the new qtscript from Debian?
<mitya57> (Or do you want to upload 5.1 instead?)
<Mirv> mitya57: sure we could, at least that would get rid of ubuntu version number even though otherwise the -2 should be same as 0ubuntu1 (not sure about the symbols files)
<Mirv> mitya57: current estimate is that we'd stick with 5.0.2 for a while, backporting patches, and maybe around 5.1.1 upgrade to 5.1
<mitya57> Mirv: ok, syncing then
<Mirv> that'd seem a safe route to stay about regression free when Qt5 most of all currently serves Ubuntu Touch efforts
<Mirv> mitya57: thanks a lot!
<mitya57> Error: The checksums of the Debian and Ubuntu packages mismatch â so it will probably be a fakesync
<Mirv> ah, I couldn't get the same orig tarball from NEW :(
<Mirv> is there a place to get the files uploaded to Debian NEW queue?
<mitya57> Mirv: by the way, lisandro has mostly implemented .qch documentation building in submodules â I will try to merge those into Ubuntu when it's ready
<mitya57> fakesync'd
<mitya57> Mirv: I don't know of such place
<Laney> no
<Laney> not in general, but many teams use a VCS which you can use to get such things out of
<mitya57> We know contents of the tarball, we need the tarball itself...
<Mirv> mitya57: yep, I've followed the doc efforts
<Laney> that's what pristine-tar does for you
<mitya57> No, pkg-qt-kde has debian-dir-only git
<Laney> so you see where I said "not in general, but many teams"
<Laney> that means that it doesn't work in all cases.
<cjwatson> <cjwatson@amber ~>$ pam_getenv LANG
<cjwatson> <cjwatson@amber ~>$
<cjwatson> pitti: ^-
<cjwatson> I'd expect en_GB.UTF-8, since that's what /etc/default/locale says for LANG
<cjwatson> Well, even with -l
<cjwatson> Ah, pam_getenv works for /etc/environment but *not* for /etc/default/locale, even with -l
<cjwatson> My memory is that -l was supposed to abstract across that transition, but maybe nobody got round to doing that
<cjwatson> tvoss: hi
<tvoss> cjwatson, hey there :) do you remember our discussion on the symbol versioning topic? You mentioned a magic linker line
<cjwatson> tvoss: What about symbol versioning, exactly?
<tvoss> cjwatson, for the platform api, we wanted to do something similar to glibc, with per-symbol versioning
<cjwatson> I expect you want a version script, then
<cjwatson> http://sourceware.org/binutils/docs-2.23.1/ld/VERSION.html#VERSION
<pitti> cjwatson: right, the manpage says that -l currently doesn't do anything
<pitti> cjwatson: so I use pam_getenv to read /etc/environment, and source /etc/default/locale
<cjwatson> Yeah, your code looks OK for this
<cjwatson> Perhaps I should say that pam_getenv is not living up to its intended purpose, rather than "broken"
<pitti> cjwatson: ok, thanks; I didn't want to commit it before knowing what kind of breakage you meant
<cjwatson> I wasn't very clear, sorry :)
<pitti> cjwatson: ack; the manpage says it's just for parsing /etc/environment
<pitti> cjwatson: no worries; thanks a lot!
<cjwatson> Right, I realise the man page says that, but I remember the discussions when that command was introduced too :-)
<rbasak> pitti: thanks!
<Vdragon> Hi, I would like to ask why Ubuntu don't pre-install all language packs (with/without input methods) on the standard installation media.  Since ISO image can no longer fit into CDs we have nearly 4GBs free space to make Live image more usable to those people not prefer en_US.
<cjwatson> While we don't have the CD constraint any more, there's still a trade-off.  The larger the image is, the more unattractive it is to download.
<cjwatson> So we don't want to instantly grow by a considerable amount.
<cjwatson> We might start gradually trickling in some more common languages, but not all of them.
<cjwatson> There are also performance problems at installation time to consider; language packs preinstalled in the squashfs should generally be removed for installations in other languages, but that takes time (and perhaps a surprising amount of it).
<cousteau> I miss the old days where you could put virtually anything in a single CD image
<Vdragon> cjwatson: Thanks for your answer, however I didn't think the tradeoff is very considerable if we take account average speed of internet(mirror) and disk(USB 3s, SSD) in recent days.
<cjwatson> I'm afraid I respectfully disagree
<Vdragon> @cousteau: I prefer using LiveUSB if available ;)
<udevbot> Error: "cousteau:" is not a valid command.
<Vdragon> cousteau: I prefer using LiveUSB if available ;)
<cousteau> ...@ as a bot trigger?  weird, never seen that
<Vdragon> cjwatson: Me too.  Anyway have a good day :)
<cjwatson> (Speaking as somebody at the wrong end of a pretty slow connection, even in a supposedly developed country)
<Vdragon> cousteau: my fault :P
<cousteau> Back in the day I carried a Knoppix 5.1 CD.  That thing carried EVERY PROGRAM you could think of!  Compilers, manpages...  it was pretty nice.
<cousteau> there was also Musix, with lots of multimedia programs (I think it basically had all Linux multimedia programs I've ever known about)
<cousteau> and, of course, Ubuntu
<cousteau> but times change and software seems to get huger for no apparent reason
<Vdragon> cousteau: cool!
<cousteau> no, not cool.  I miss the old days of Hardy. It looked so nice...
<mok0> Ah, the Hardy Heron. I remember it well
<smb> infinity, I updated bug 1064475 and added several backports of crash to my 4infinity folder on chinstrap (backports are saucy version minus the armhf in the control file). Raring is not necessarily broken but I thought it might be less pain to have them all the same. Up to your decision I guess. And yeah, xen is also there.
<ubottu> bug 1064475 in crash (Ubuntu Quantal) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress] https://launchpad.net/bugs/1064475
<infinity> smb: Any reason to remove armhf from the control file on backport?
<infinity> smb: Do only 3.8+ kernels support crash on ARM?
<smb> infinity, Well I thought we had not built it for arm back then and only start with S
<infinity> smb: Sure, but was that because the package didn't work back then (and does now), because of silly historical cruft, or because it won't work with those kernels?
<infinity> smb: If it's either of the first two reasons, there's no reason to continue to prevent it building.
<smb> infinity, I could not say. It probably builds back then but I had no way of testing. And I thought starting to build a package for an architecture it was not build on release was a reason not to start with it on a backport.
<infinity> smb: Nah, there's no such rule.  If an FTBFS or some other backported upstream code fix/change makes it magically work on a new arch, artificially limiting it to not build on that arch is silly.
<infinity> smb: If anyone has written such a rule, it should be found and purged with fire as a case of "overly strict rules being user-hostile".
<infinity> smb: "You could have this package, but we won't let you, nyah nyah" wouldn't look good in a changelog. ;)
<cjwatson> Also, there's no reason to be strict about that, because a package that simply didn't exist at all before is exceedingly unlikely to constitute a regression by appearing
<smb> infinity, There isn't a written down rule I know of. It was more an assumption not to introduce something new into the archive as a backport would be better. And the changlog just does not say "added armhf". So who would know... :-P
<infinity> cjwatson: Rare corner-cases where this isn't true, like if that package is in a recommends-chain from something people generally have installed, and now it magically gets pulled in.
<infinity> cjwatson: But it would have to be severely broken *and* in a recommends chain for that to be a regression.
<smb> infinity, Maybe you can try to sbuild the saucy package on your arm box on r,q,p and if that works, I recreate the source debs with the armhf back in...?
<cjwatson> infinity: indeed
<tvoss> slangasek, around?
<jibel> pitti, in bug 1189485 apport retracer added a comment but didn't set it as duplicate, is this a known issue ?
<ubottu> bug 1189485 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_type_check_instance()" [Undecided,New] https://launchpad.net/bugs/1189485
<pitti> jibel: hm, did you mark it as dupe yourself?
<jibel> pitti, I did after the retracer said he did but didn't
<pitti>     self.close_duplicate(report, id, master_id)
<pitti> [...]
<pitti> lazr.restfulclient.errors.ServerError: HTTP Error 504: Gateway Time-out
<pitti> jibel: so, LP glitch :/
<pitti> jibel: thanks for cleaning it up
<jibel> pitti, ok, np
 * pitti restarts the amd64 retracer then
<pitti> thomi: would you mind adding me to the ~autopilot team? I'm currently reviewing the -gtk bugs, and would like to do some triaging there, but I can't do that properly without being a team member
<slangasek> tvoss: hi
<Riddell> pitti: any ideas on what's upsetting pkgbinarymangler on this build? https://launchpadlibrarian.net/142096598/buildlog_ubuntu-saucy-amd64.opencolorio_1.0.8%2Brepack1-0ubuntu1_FAILEDTOBUILD.txt.gz
<infinity> Riddell: "Found files in /usr/lib/python2.7/site-packages (must be in dist-packages for python2.7)"?
<cjwatson> Using dh_python2 would probably sort that out.
<cjwatson> You don't seem to be using any Python helper at all there right now, which is very likely a mistake.
<OdyX> tkamppeter: did you see http://bugs.debian.org/711868 ? Apparently we never re-applied colord-support.patch in cups 1.6.2 . Is it still neededor would Alexey's patch be sufficient now.
<ubottu> Debian bug 711868 in cups-daemon "Regression: icc profiles not registered in colord" [Normal,Open]
<OdyX> tkamppeter: also, to you have informations regarding the cups upstream bugtracker ? It's quite cumbersome to get issues reported/fixed without any other tracker than the Apple ID $thing that I refuse to touch with a remote stick,
<Riddell> infinity: mm yes
<infinity> Riddell: See Colin's comments.
<Riddell> yep
<pitti> Riddell: at first sight, sounds like the change of default paths in saucy's automake? (that's a huge pain in the butt indeed)
<pitti> Riddell: (in meeting, haven't looked into details yet)
<cjwatson> pitti: see scrollback, we've dealt with it
<pitti> Riddell: doko added that plausibility check, so it's a deliberate build failure
<pitti> cjwatson: ah, right
<cjwatson> pitti: dh_python2 fixes these things up if it's actually run, regardless of what automake does, and dh_python2 ought to be run here anyway I'd have thought ...
<pitti> yes, absolutely
<Riddell> yep, fix uploaded, thanks pitti,cjwatson
<lool> pitti: hey, stgraber kindly pointed me at https://blueprints.launchpad.net/ubuntu/+spec/community-s-testing-technologies as the closest matching QA effort for the ofono / NM CP testing; would it be ok to list explicit tests for a) SIM card + optional XML db provisioning and b) binary SMS (DM/DS) based provisioning in there?  the latter is meant to allow us to add hooks for opcos that don't support a), but I think it's currently untested code
<pitti> lool: re (meeting)
<pitti> lool: I'm afraid I don't know what either of that means, but sure, please feel free to add some WIs
<pitti> lool: but as a starter we need to figure out how to do the most basic stuff (like detection and making a call/making a connection)
<pitti> good night everyone
<didrocks> have a good night pitti!
<lool> pitti: Yup, this all makes sense
<lool> pitti: I agree that simpler stuff is needed first, just wanted to have a place to list some high-level goals for testing the CP
<lool> pitti: thanks!
<tkamppeter> OdyX, I was assuming that CUPS 1.6.x had adopted colord-support.patch upstream. Is this not the case? Perhaps there are bugs in the adoption. What is Alexey's patch about? Perhaps it can fix these bugs?
<tkamppeter> OdyX, I have contacted Mike, telling him that it is really important to get the STR database back.
<tkamppeter> OdyX, for the time being please report bugs and submit patches by contacting Mike directly.
<bdmurray> stgraber: I think I am experiencing bug 981461
<ubottu> bug 981461 in ifupdown (Ubuntu Precise) "Network interfaces are not correctly brought down on halt, disrupting Wake-on-LAN" [High,Triaged] https://launchpad.net/bugs/981461
<stgraber> bdmurray: do you have ethtool installed?
<stgraber> bdmurray: ethtool eth0 | grep "Wake"
<bdmurray>         Supports Wake-on: pumbg
<bdmurray>         Wake-on: g
<bdmurray> I've tested with tcpdump and the system is receiving the magic packet when powered on
<stgraber> bdmurray: and wake on lan is enabled in the BIOS?
<bdmurray> Additionallly, there is no BIOS setting for it
<bdmurray> And I swear it used to work in 12.10 but I reinstalled recently and put 12.04 on that system
<stgraber> ok, odd. I haven't used wake on lan much since precise, but I have a dozen precise machines that certainly have it working
<stgraber> IIRC the only thing I had to add to some of those was a "ethtool -s eth0 wol g" but what you pasted earlier already looks good and shouldn't need that workaround
<bdmurray> its a mythbuntu system fwiw
<stgraber> bdmurray: just rechecked, the systems that have working wol here only have one extra setting which is "ethtool -s $1 wol g || true" as post-up command in ifupdown but you apparently don't need that in your case
<stgraber> bdmurray: when the machine is off, do you see a link on the network card?
<bdmurray> checking
<bdmurray> hmm, nope
<stgraber> ok, so something is being a bit too efficient at shutting down the machine
<stgraber> bdmurray: so are you actually using ifupdown on that machine? as in, are you network interfaces defined in /etc/network/interfaces instead of NetworkManager?
<bdmurray> stgraber: no, I was not but then I added the interface to /e/n/i and nothing changed
<stgraber> ok, I was just wondering if maybe ifupdown was doing something to bring the link down, but if you get the same under NetworkManager then that's not the case (the machines I use with wol use NetworkManager)
<bdmurray> hmm, okay I can wake it up from suspend
<stgraber> bdmurray: if you use "halt" to shut down the machine (but not cut power), do you see a link?
<bdmurray> stgraber: yes
<stgraber> bdmurray: ok, then it's not Ubuntu shutting down the link as the only difference between halt and poweroff is the final kernel call to cut power
<stgraber> so extremely unlikely to be an issue with ifupdown or our init scripts
<stgraber> bdmurray: what kernel are you using on those 12.04 systems?
<stgraber> *that 12.04 system
<bdmurray> stgraber: I just upgraded to the latest 12.04 one
<stgraber> bdmurray: ok, so the non-backport 3.2 kernel then
<stgraber> bdmurray: might be interesting to retry with the quantal and raring backport, see if that makes any difference
<bdmurray> stgraber: okay, thanks
<OdyX> tkamppeter: for the colord support, cups 1.6 upstream indeed has a bug, which Alexey fixes. I'll drop colord-support.patch from the source package as it's deprecated.
<OdyX> tkamppeter: great for cups' str, thanks. How are you in contact with Michael btw, msweet@ Apple ?
<smoser> slangasek, you have any idea what would 'start networking' on a system that was seemingly failing to bringup networking on boot ?
<smoser> ie, this bug https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1189571
<ubottu> Launchpad bug 1189571 in isc-dhcp (Ubuntu) "isc-dhcp client "Unable to set up timer: out of range" caused by bad 64_bit timer" [Undecided,Confirmed]
<smoser> was stoping networking from coming up on network-device-added
<smoser> but /var/log/upstrat would still have a 'networking' file with data in it.
<slangasek> smoser: not sure I understand the question. /etc/init/networking.conf is the catch-all job for network devices that don't generate network-device-added events.
<slangasek> it runs unconditionally on boot.
<smoser> it does ?
<slangasek> yes
<smoser> bah.
<slangasek> as per the start condition, start on (local-filesystems and (stopped udevtrigger or container)) or [...]
<smoser> well that is it then
<smoser> :)
<smoser> yeah
<smoser> duh
<smoser> i had left over stuff in my head from https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1031065
<ubottu> Launchpad bug 1031065 in cloud-init (Ubuntu Precise) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Fix released]
<smoser> and thought that that was basically not supposed to be run other than manually
<smoser> anyone know what might have changed ...
<smoser> is swear that i used to be able to do:
<smoser> bzr bd -S -- -us -uc
<smoser> then sbuild -d saucy-amd64 --arch-all file.dsc
<smoser> but recently, i've been getting
<smoser> E: E: Failed to copy '../isc-dhcp_4.2.4.orig.tar.gz' to '/Â«CHROOTÂ»/Â«BUILDDIRÂ»': No such file or directory
<infinity> Well, does the file exist?
<smoser> the file *doesn't* exist, because i didnt build with '-sa'
<smoser> but i swear some magic used to make that work
<infinity> Well, how do you expect sbuild to find the source if you don't have source?
<infinity> I'm a bit puzzled. :P
<infinity> -sa has nothing to do with it.
<infinity> -sa defines what's in .changes, not in .dsc
<infinity> So, let's back up, and tell me what bzr bd is producing, and how.
<jbicha> smoser: you don't need to make a .dsc for sbuild to work; sbuild -A -d saucy-amd64 is sufficient
<smoser> jbicha, well, it was just my normal work flow. i didn't know that i didn't eed a .dsc. but its nice.
<smoser> infinity, well, doing -sa would tell (i think) bz rbd to copy its exported .orig.tar.gz to the same place it put the .dsc
<smoser> no?
<jbicha> smoser: one step further, in your ~/.bzr/builddeb.conf
<jbicha> [BUILDDEB]
<jbicha> builder = sbuild -A -d saucy-amd64
<jbicha> then bzr bd without arguments will build with your sbuild
<kees> jcastro: tb meeting happening now, if you have a moment.
<smoser> i didn't know about htat. but i'm not bothered too much by my wrapper 'sbuild-it' that reads .dsc or .changelog and picks the right release based on that.
<kees> jcastro: ah, nm, found RT for brainstorm
<infinity> smoser: Oh, sure, bzr bd copies things around based on the changes, probably.  I dunno.  I don't use it.
<infinity> smoser: My point was more that a source package without all the components isn't actually a source package, so sbuild can't magically find the missing bits.
<smoser> I WANT MAGIC!
<smoser> :)
<jcastro> kees: I can answer questions if you want
<smoser> so i guess it could have bee na change in bzr builddep (version upgraded in saucy)
<kees> jcastro: I was just checking on the status of the request, cjwatson found the RT. we're all good. :) thanks!
<jcastro> ack
<kees> can someone besides me verify this, I'd like to get this closed: https://bugs.launchpad.net/bugs/1177218
<ubottu> Launchpad bug 1177218 in faketime (Ubuntu) "[regression] segfault on raring" [Undecided,Confirmed]
<Sarvatt> kees: done
<kees> Sarvatt: thanks!
<DrFoo> Is there a known issue with mounting cifs share w/ a credentials file?
<DrFoo> 12.04
<smoser> jdstrand, ping
<jdstrand> smoser: hey
<smoser> is there a reason your release at https://lists.ubuntu.com/archives/saucy-changes/2013-May/001104.html is 'saucy-proposed' ?
<smoser> jdstrand.
<infinity> smoser: Cause Jamie's weird and never got the memo about pocket rewriting? :)
<smoser> i'm guessing it was inadvertant, but i'm uploading and wanted to make sure I wasn't wrong.
<smoser> i think it might have caused the bzr importer to fail also
<jdstrand> smoser: istr an email from cjwa tson explaining how the new proposed mechanism worked that -proposed is technically correct, but that there is a redirection from saucy to saucy-proposed for people who don't use -proposed
<jdstrand> if 'saucy' is actually correct, I'll stop
 * smoser doesn' tknow.
<infinity> jdstrand: Both are "correct", but you're one of the few people still using -proposed (and I'm trying to discourage it).
<jdstrand> seems infinity may have some insight
<jdstrand> heh, funny
 * jdstrand shrugs
<jdstrand> I guess I'll stop then, or maybe I'll continue to be an individual :)
<smoser> jdstrand, infinity thanks.
<cjwatson> smoser: I don't really know its inner workings, but I'd be surprised if it made any difference either way to the importer.
<smoser> i wouldnt have thoguht so either.
<smoser> but somethign busted it.
<smoser> :-(
<smoser> i import-dsc and pushed it
<cjwatson> I'm not going to try to guess at the cause :)
<kees> stgraber: do you happen to know how to tell kvm to load an external kernel to a specific location in memory when it acts as the boot loader?
<stgraber> kees: nope, but maybe hallyn does
<stgraber> hallyn: 21:38 < kees> stgraber: do you happen to know how to tell kvm to load an external kernel to a specific location in memory when it acts as the boot loader?
<kees> hallyn: all I see is just "-kernel", but it'd be nice to bump it around in memory when I've built with CONFIG_RELOCATABLE
<DrFoo> Can someone test mounting a cifs share using a credentials file. I've followed all the instructions and syntax I could find on the web and it's telling me I haven't specified a username. There is an old bug for this, but it must have been resolved by now.
<zyga> hey it's after midnight
<zyga> and this is the wrong channel
<hallyn> kees: sorry, i don't
<hallyn> i do, however, need to talk to the cable chaps about why around 4pm (when it gets hot) my internet gets flaky
<kees> hallyn: heh
<hallyn> yeah you'd think that'd be an option.  not finding it
<bkerensa> jbicha: can you pop into #ubuntu-meeting?
#ubuntu-devel 2013-06-11
<log> Can packages in main depend on a virtual package that is provided by one that is also in main?
<log> Or do they have to explicitly depend on the package that's in main?
<log> (This is for Depends for one of the binaries, not the Build-Depends.)
<cjwatson> If there's more than one provider of the virtual package, they need to do REAL | VIRTUAL or behaviour is random.
<slangasek> log: whenever there's a "preferred" real package to satisfy the virtual dependency, it's best to list it first.
<cjwatson> So normally we'd have PROVIDER-IN-MAIN | VIRTUAL
<log> Okay, thanks!
<cjwatson> (This rule is probably not followed everywhere; there are enough constraints on the system that in practice it will *often* choose the "preferred" real package anyway, but now and again this bites somebody.)
<daya_> Anyone have implemented simple-cdd in ubuntu
<pitti_> Good morning
<sarnold> morgen pitti_ :)
<Snow-Man> I don't suppose any of ya'll have run into a kernel panic w/ a 3.2 kernel on a DL585 G1?
<Snow-Man> pitti: hey... :)
<pitti> hello Snow-Man
<Snow-Man> pitti: ever had a kernel panic when trying to run a 3.2 kernel on a DL585 G1?
<pitti> I'm afraid I never did that; that sounds like server-type hw?
<Snow-Man> (I just upgraded the box that hosts the PG gitmaster to wheezy and it turns out to hate the 3.2 kernels)
<Snow-Man> pitti: uhm, well, yes..  It's a 4U, 4-proc HP server box
<sarnold> Snow-Man: there's lots of different reasons for kernels to panic; can you pastebin the problem? that might help someone point out something to try
<Snow-Man> nah, the rackspace guy couldn't get the full panic
<Snow-Man> iirc, when I saw this before, it was something w/ the ASICs
<Snow-Man> or how it handles interrupts or something
<sarnold> hrm. there were a few years there when adding something like acpi=0 ioapic=0 to the linux kernel command line was a very useful debugging step -- but I think the consequence of those would more or less turn your machine into a single-CPU system :)
<Snow-Man> that'd kind of suck..
<pitti> apw: hey Andy! is bug 1068356 something for rtg?
<ubottu> bug 1068356 in linux-firmware-nonfree (Ubuntu) "lots of missing firmware links" [Undecided,Triaged] https://launchpad.net/bugs/1068356
<pitti> apw: seems our l-f-n package is in dire need for some cleanups and updates, and our kernel is missing tons of firmware: links in modules
<mardy> jbicha: hi! I got your comment about eds + uoa, I'll investigate a bit
<mardy> jbicha: it sounds really wrong that a run-time dependency is automatically added because of the build time dependency -- I didn't notice that debhelper was behaving like that, maybe there's something wrong in how eds is built
<jbicha> mardy: I don't think it's behaving wrong :)
<mardy> jbicha: or maybe the UOA dependency is not as cleanly separated as I believed; let me try to split it out and see what happens
<jbicha> I can see why you'd want a library to depend on its associated daemon but signond is no ordinary daemon
<mardy> jbicha: I'm a bit rusty with building... once I checkout lp:ubuntu/evolution-data-server and make my changes to the debian/ directory, how do I build the packages?
<jbicha> mardy: bzr bd (like Unity modules, assuming you have bzr-builddeb set up right)
<OdyX> tkampetter: I just found out why cupsfilters.drv spits some "Bad driver information file", cups 1.6 dropped at least pcl.h and escp.h, we need to include them from cups-filters, I'll prepare a patch on Debian for that.
<pitti> yolanda: good morning, how are you?
<pitti> yofel: FYI, https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-squid3/7/ARCH=amd64,label=adt/ has logs about the two tests that fail now
<pitti> the others work now after your recent fix
<pitti> yofel: so you can't access ftp.ubuntu.com from the jenkins nodes, I'm afraid; http works fine
<dholbach_> good morning
<apw> pitti, ack, will look/discuss with him
<pitti> apw: not sure whether that's really a regression in the kernel itself; could potentially also be in libkmod or so
<pitti> yofel: sorry, that was for yolanda
<yolanda> hi pitti
<yolanda> let me see
<pitti> yolanda: I found out that ftp access works with setting $ftp_proxy on our side, though
<pitti> let me try the full test with that
<yolanda> ok
<pitti> yolanda: I'll discuss with jibel, so no need to do anything on your side yet; just keeping you informed
<yolanda> good, just let me know
<mardy> seb128: https://bugs.launchpad.net/bugs/1189728
<ubottu> Launchpad bug 1189728 in Ubuntu UI Toolkit "[Page] Cannot scroll content if its height is less than page height" [Undecided,New]
<mardy> seb128: that's the problem affecting the About page ^
<seb128> mardy, oh, thanks for figuring that out/filing a bug
<seb128> mardy, ken and I were puzzled at why it worked when tweaking values
<mardy> seb128: me too :-)
<mardy> seb128: there's a lot of magic in the Page component, but not all of it is working properly
<seb128> mardy, yeah, I can see that ;-)
<pitti> xnox: do you know whether there is something like /etc/environment which is being read into upstart jobs? I. e. where would I set $http_proxy so that all daemons pick it uP?
<pitti> /etc/environment itself doesn't seem to get into jobs
<pitti> hm, not that it would help much; even poking it right into the upstart job doesn't fix the squid3 test
<pitti> yolanda: it seems squid3 itself doesn't respect $http_proxy/$ftp_proxy, so you cannot really chain those
<pitti> yolanda: so I don't know how to make this test work :/
<yolanda> so squid3 isn't using the configured proxys?
<pitti> apparenlty not; and it does seem a bit recursive
<pitti> so, that's certainly a limit of our DC machine, not really the test itself; perhaps we should keep this as a manual test only
<pitti> tests which talk to remote servers are notoriously unreliable
<yolanda> i can disable it then
<pitti> yolanda: do you know what test_squidclient does? it still fails here even with proxy set
<pitti> where "here" == DC machine
<pitti> yolanda: oh, of course -- it uses an ftp URL
<pitti> and gopher
 * pitti tries another run with just http and https
<pitti> yolanda: so, tricky; for running the test on a workstation (e. g. by security team), it's definitivley useful to have the full one
<pitti> yolanda: how about this:
<yolanda> tell me
<pitti> yolanda: debian/tests/squid exports an env var $SQUID_TEST_HTTP_ONLY or something
<pitti> yolanda: and debian/tests/test-squid.py tags the ones which use ftp/gopher with @unittest.skipIf('SQUID_TEST_HTTP_ONLY' in os.environ)
<pitti> oh, second argument: "skipping non-http test for autopkgtest run"
<pitti> then the security team can still call debian/tests/test-squid.py for the full thing
<pitti> Test squidclient ... ok
<yolanda> sounds like a good idea
<pitti> yolanda: so, with taking out ftp and gopher, this one works as well
<pitti> yolanda: or maybe calling it with an extra argument or something
<yolanda> so only http is working, or also https?
<pitti> then test_squidclient can add the ftp and gopher one in "full" mode, and only use http[s] for adt mode
<pitti> yolanda: https:// seems fine
<yolanda> ok, problems with gopher and ftp
<yolanda> i'll do some rewrite
<pitti> cheers
<xnox> pitti: i don't think we inherit, nor set proxy settings at the moment. One would need to source them in the job file, or you can simply pass it on a command line. E.g. $ sudo start squid3 http_proxy=$http_proxy
<pitti> xnox: ack, thanks
<Laney> I think jobs intentionally start in a minimal environment
<Laney> http://upstart.ubuntu.com/cookbook/#job-environment
<pitti> indeed, and this makes sense; we don't want the full enironment of the "start" command there for sure; I was just wondering if we source /etc/environment
<xnox> pitti: for session init we inherit a few environment variables (XDG_* and others) and have setenv/unsetenv commands to set "session-wide" environment variables. As well everything on the desktop session wants $HOME and etc.
<pitti> Laney: ah, thanks
<yolanda> pitti, gopher is running locally, is it necessary to skip this test? or maybe only the ftp one?
<pitti> yolanda: they all run locally; the problem is in the DC, where non-http[s] doesn't work
<pitti> yolanda: we need to skip the ftp test, and either the whole squidclient one, or in the DC environment it doesn't add the gopher and ftp list entrie
<pitti> ss
<yolanda> ok, i thought the problem was accessing remote urls
<pitti> yolanda: yes, it is
<yolanda> but gopher is on gopher://127.0.0.1 ?
<pitti> yolanda: ah, ok; so just the ftp one then
<pitti> yolanda: (I didn't notice that, sorry)
<yolanda> np
<pitti> in fact, if it's ok to test against localhost, the test could just set up its own ftp server?
<yolanda> could be, if we setup an ftp server, we are just setting a local gopher service
<pitti> https://git.gnome.org/browse/gvfs/tree/test/gvfs-test#n528
<pitti> I do that in the gvfs test with twistd, that's super-easy; but of course we have root, we could also just install vsftpd or so
<yolanda> i can have root and install packages
<yolanda> there is a needs-root restriction
<pitti> (test dependency)
<yolanda> looks like a good solution, better than skipping the ftp
<pitti> but twistd ftp might still be easier
<yolanda> i'll try to add local ftp then
<mardy> Kaleo_: hi! Do we have any class to read XDG .desktop files?
<yolanda> pitti, is it normal that takes so much time when setting up ftp using twistd ?
<pitti> yolanda: not really, should be sub-seconds
<yolanda> i'll comment the line but suddenly my tests aren't running
<yolanda> there should be some problem with my environment, i try commenting that lines and the problem is the same
<pitti> yolanda: hm, did you follow the approach from the gvfs test?
<pitti> yolanda: NB that this starts twistd on port 2121, as this test doesn't run as root
<yolanda> pitti, yes, but seems that my environment is broken, even commenting that lines it's stuck
<yolanda> i'm recreating it again
<yolanda> no way, i'll try rebooting the machine
<poee> Hi. Where would be the best place to start linux programming ?
<mlankhorst> your own pc :)
<poee> uh I mean which language? etc
<poee> :P
<mlankhorst> that's up o personal preference, just pick something you like
<poee> okay thx.
<tvoss> didrocks, ping
<didrocks> tvoss: pong
<Kaleo_> mardy: a bit
<Kaleo_> mardy: what do you need it for?
<Kaleo_> tvoss: you pinged me yesterday?
<tvoss> Kaleo_, yup, for our catchup :)
<Kaleo_> tvoss: sorry, day off :)
<tvoss> Kaleo_, no worries, was my first day after vacation
<OdyX> tkamppeter: What is the reason to not set "dnssd,cups" as default protocols on cups-browsed?
<mardy> Kaleo_: just to know whether we had some classes for it. I noticed that both razor-qt and KDE have their implementations, so I was wondering if a class reading XDG desktop files could be useful in Qt itself
<mardy> Kaleo_: or maybe as a standalone project
<Kaleo_> mardy: it would be
<Kaleo_> mardy: but we have nothing of quality and separate enough
<mardy> Kaleo_: OK. This look rather clean: http://razor-qt.org/develop/docs/classXdgDesktopFile.html
<Kaleo_> indeed
<yolanda> pitti, i'm unable to run twistd for the tests, as soon as i start it, the tests hangs
<yolanda> i tried with python and even by bash,it's quite strange
<hrw> does someone has etckeeper 1.3 usable under precise?
<tkamppeter> OdyX, in the beginning I thought about simply supporting only the current format, dnssd, by default, but nowadays, listening to CUPS broadcasts I think is a good idea, as servers often use older software versions and so in more use cases we have everything working out-of-the-box. We only leave the CUPS broadcasting of local shared printers off by default. Feel free to change the default to "BrowseRemoteProtocols dnssd cups" in the cu
<tkamppeter> ps-filters package (I think there is a ./configure option for that) and I will let this go into Ubuntu with a sync of your next cups-filters package.
<OdyX> tkamppeter: the only thing I'm afraid of is how we will then phase the "cups" protocol out when we'll want to deprecate it fully.
<OdyX> tkamppeter: ha, by not exposing the new server's printers over "cups", right ?
<tkamppeter> OdyX, yes, as I said, we do not do CUPS BROADCASTING, only BROWSING, BrowseLocalProtocols will stay empty by default.
<OdyX> tkamppeter: great, we have consensus.
<OdyX> tkamppeter: I've begun to get a flow of complicated bugs in Debian as 1.6.2 got uploaded to unstable, and that migration is the one that creates most headaches.
<OdyX> tkamppeter: by the way, did you see my question regarding how to contact msweet ?
<tkamppeter> OdyX, see PM.
<ev> bdmurray: there seem to be some problems with that table sorting code: https://oops.canonical.com/oops/?oopsid=OOPS-bd2bd022aff067ce725ce9f5a425bb7a
<mardy> kenvandine: was it you who merged this just now? https://code.launchpad.net/~mardy/evolution-data-server/split-uoa/+merge/168609
<mardy> jbicha: or you? ^
<Laney> Dang, I would have been picky about the long description :P
<jbicha> mardy: that was me; it seems to work so far
<Laney> but that's a good idea, I'm glad you did it - was going to do it myself probably
<mardy> jbicha: excellent, thanks!
<mardy> jbicha: I'll disapprove the other reviews, then
<jbicha> any ideas about how to do the same for Empathy?
<Laney> can we wait to upload it until we get the desktop file fix?
<mardy> jbicha: yes, it should be quite similar, it's also a module
<jbicha> Laney: sure, empathy & shotwell need to be fixed too for it to matter much
<jbicha> mardy: we already supposedly split the uoa bits out
<jbicha> *our of empathy
<Laney> 'it'?
<jbicha> Laney: this problem: https://code.launchpad.net/~jbicha/libsignon-glib/dont-depend-on-signond/+merge/168496
<Laney> ah, it> the split
<mardy> jbicha: mmm... then I don't understand your question: "any ideas about how to do the same for Empathy?" <- if it's already split it should be alright, isn't it?
<kenvandine> both goa and uoa are split for empathy
<jbicha> except empathy still depends on libsignon-glib1
<mardy> jbicha: ah, weird. Let me check, maybe it's an unnecessary dependency
<mardy> jbicha: lp:ubuntu/empathy, right?
<Laney> because it calls into libsignon-glib from libempathy if you build with UOA
<kenvandine> mardy ~ubuntu-desktop/empathy/ubuntu
<jbicha> Laney: is that fixable or do we need my MP after all?
<mardy> kenvandine: thanks
<Laney> it doesn't look easily fixable, at least
<kenvandine> empathy is split with mcp-account-manager-uoa and mcp-account-manager-goa
<kenvandine> but yes... empathy itself seems to depend on libaccounts-glib
<kenvandine> which is weird
<kenvandine> and libsignon-glib
<Laney> look for HAVE_UOA
<xclaesse> mardy, pong
<mardy> xclaesse: thanks
<mardy> xclaesse: looks like empathy itself is depending on libsignon-glib
<kenvandine> and libaccounts-glib
<xclaesse> it is optional dep, yes
<mardy> xclaesse: is that dependency built into a pluggable module, or is it in a common binary?
<Laney> it's on libempathy-gtk
<xclaesse> it is in internal libempathy
<xclaesse> which is linked on all empathy binaries
<xclaesse> the code separation is not perfect in empathy tree
<mardy> xclaesse: the problem is that Laney and jbicha are trying to make the empathy package not depend on libsignon-glib, so that if one doesn't use UOA one doesn't have to install signond, signon-ui and all (for example, for the GNOME remix)
<kenvandine> which pulls in Qt and more
<Laney> Pretty sure it's not possible as the code stands
<xclaesse> from a packaging POV it is not possible
<xclaesse> mardy, also it would make problems, like accounts menu opens UOA
<mardy> xclaesse: right
<jbicha> xclaesse: oh you mean https://bugzilla.gnome.org/701903 ? ;)
<ubottu> Gnome bug 701903 in UOA "If built with --enable-ubuntu-online-accounts, accounts dialog always opens the UOA one" [Normal,Unconfirmed]
<xclaesse> on gnome remix you would have to change back to empathy-accounts
<xclaesse> jbicha, exactly
<jbicha> that's just a bug though
<xclaesse> I wish GNOME had a gtk implementation of signon-ui
<xclaesse> instead of their useless GOA
<mardy> xclaesse: do you think it would be difficult to modularize empathy-keyring.c?
<mardy> xclaesse: looks like the libsignon-glib dependency comes from there only
<mardy> xclaesse: the libaccounts dependency is not that troublesome
<xclaesse> mardy,  barisione (on #telepathy) started working on that but priority changed and it is not actively worked on atm
<mardy> xclaesse: OK, maybe we'll catch up with him
<xclaesse> mardy, but empathy-auth-client will always need to know about all credentials storages
<mardy> xclaesse: or could the password storage/retrieval methods could be moved to mcp-account-manager-uoa? (am I making some sense at all?)
<xclaesse> we would have to split it into 2 different programs
<xclaesse> one for accounts that store in gnome-keyring, and one for UOA
<mardy> what if we build once with --disable-uoa (or whatever it's called), and then once more with --enable-uoa, and then put the resulting files into different packages?
<mardy> kenvandine: like how you are doing for having dual qt4/qt5 builds
<xclaesse> mardy, if you make those package conflict to not have both installed, then it could work
 * mardy needs to leave soonish
<xclaesse> mardy, note that ubuntu's empathy will migrate accounts to UOA
<xclaesse> then if you switch to GNOME remix your accounts are lost
<xclaesse> (not really lost, but they won't appear if you don't have the uoa plugin)
<xclaesse> so for someone switching between unity and gnome, that won't be pleasant :(
<kenvandine> it's possible
<kenvandine> but not a big fan of doing that
<Laney> seems to me like it would be better to fix the underlying problem rather than hacking around it in packaging
<kenvandine> indeed
<jbicha> mardy: for Saucy maybe we'll have to accept my dont-depend-on-signond MP until someone fixes the empathy issue
<Laney> might be better to seed it rather than having a single random component depend on it
<Laney> if we do do that
<xnox> seeding is more lightweight.
<jbicha> Laney: well it could be multiple components, some people don't have ubuntu-desktop installed for whatever reason
<Laney> yes, you'll have to add it everywhere
<Laney> which is annoying when it's not really a correct dependency
<jbicha> I don't know; I worry about someone having gnome-control-center-signon installed but not working
<bdmurray> slangasek: did you see the last comment in bug 1185300?
<ubottu> bug 1185300 in plymouth (Ubuntu) "package linux-image-3.9.0-2-generic 3.9.0-2.7 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [Medium,Fix released] https://launchpad.net/bugs/1185300
<bdmurray> ev: does that oops page have information about the revision of errors being run?
<jbicha> Shotwell suddenly starting failing to build within the hour http://paste.ubuntu.com/5755143/
<jbicha> doko: any ideas?
<ev> bdmurray: we haven't updated deploymgr (or whatever part would do this) to run `bzr version-info --python > errors/version_info.py` yet, so no
<doko> jbicha, picker binutils ...
<doko> link with -lgomp
<doko> pickier even
<jbicha> doko: stop changing stuff when I'm compiling ;)
<doko> heh
<doko> jbicha, maybe linking with -fopenmp is enough, but I didn't check
<shakaran>  am trying to debug compiz with following this https://wiki.ubuntu.com/DebuggingCompiz but it seems that compiz-*-dbgsym packages are not available? I ask in #compiz but they only suggest compile compiz with gcc -g, but that is complex for desktop users that report bugs with apport. So apport is failing to retrace the compiz bugs
<rbasak> shakaran: thanks for debugging! It looks like debug symbol packages are available for compiz on ddebs.ubuntu.com - have you tried these? See https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages for details.
<ev> bdmurray: https://oops.canonical.com/oops/?oopsid=OOPS-0aa0e4bce06fcf0e9d364461b8889e1f - eep
<bdmurray> ev: whoa, let me finish fixing the previous oops you posted
<ev> :)
<ev> trying to see what's going on here
<ev> fixing this
<shakaran> rbasak, ok, trying that :) Thanks
<bdmurray> ev: thanks
<bdmurray> ev: https://code.launchpad.net/~brian-murray/errors/fix-all-versions-oops/+merge/168713
<ev> bdmurray: thanks; reviewing
<ev> bdmurray: I'm going to simplify this a bit and merge in
<bdmurray> ev: okay, I'll keep an eye out
<shakaran> rbasak, Could you remove the comma in https://wiki.ubuntu.com/DebuggingCompiz after compiz-core-dbgsym? It seems a typo, but the wiki page seems inmutable and I don't have privileges
<shakaran> rbasak, also after compiz-fusion-plugins-main-dbgsym
<rbasak> shakaran: done. Thanks!
<rbasak> BTW, I don't have my privilege either. I think you may just need to log in or something.
<rbasak> s/my/much/
<shakaran> rbasak, right, I think that I was inmutable after login, now I see that I can edit too, but thanks anyway for edit :)
<ev> bdmurray: don't know how I missed this, but the code didn't catch the NFE on bucketsystems_cf.get: http://paste.ubuntu.com/5755358/
<ev> but I think the call is unnecessary
<ev> inserts are fast. get+maybe insert is slow
<bdmurray> would it not insert duplicate systems?
<bdmurray> we want bucketversionssytems to have only unique systems
<slangasek> bdmurray: thanks, I'd missed that last comment in 1185300; reopened/reassigned/commented
<ev> bdmurray: duplicate systems? I'm not sure I follow. It's inserting the system uuid, which is always going to be the same thing.
<ev> bdmurray: I made the change as r78 - if that's in error I'm going to have to hand off to you on this as we're reaching EOD UK time. If you make additional changes to oops-repo, generate a build: https://code.launchpad.net/~daisy-pluckers/+recipe/oops-repository-daily then give webops the .dsc so they can feed it to dak
<bdmurray> ev: right, because its uuid: '' it'll be the same.  I came to that conclusion myself.
<ev> okay, cool
<tkamppeter> OdyX, I have CUPS 1.7b1 in my PPA.
<bdmurray> mpt: could you have a look at bug 1186376 again?
<ubottu> bug 1186376 in software-properties (Ubuntu) "should support setting of whether or not to include phased updates" [Medium,Triaged] https://launchpad.net/bugs/1186376
<lamont> ev bdmurray: does that mean that I do or don't want r78?
<bdmurray> lamont: yes to r78
<lamont> bdmurray: ack - it's working its way through
<slangasek> doko: your latest binutils upload has regressed autopkgtest support.
<arges> ev: is there a way to upload crash data directly to a LP bug. its a kernel bug, and i have .crash .dmesg and all that good stuff. I can manually attach stuff, but wanted to know if there was a whoopsie command to make this easier.
<arges> or is this an ubuntu-bug thing?
<arges> ok so using 'apport-cli *.crash', it asks to send a report (which I do), but then it says 'fill out the form in the automatically opened web browser' which never gets opened
<arges> looks like this is bug 994921
<ubottu> bug 994921 in apport (Ubuntu Quantal) "'ubuntu-bug /var/crash/app.crash' (and even more so, 'apport-cli -c /var/crash/app.crash') should still allow manual bug filing in stable releases" [Medium,Triaged] https://launchpad.net/bugs/994921
<dobey> slangasek: hi. sorry for being a bit slow, but I've just updated bug #1166356 with the requisite test/regression info. thanks.
<ubottu> bug 1166356 in ubiquity-slideshow-ubuntu (Ubuntu Precise) "[UIFe] Old music store interface going away on server" [Medium,Confirmed] https://launchpad.net/bugs/1166356
<arges> ev: I'm wondering if the above bug is blocking any linux kernel crashes from being reported to errors.u.c, have you seen any reports show up recently in saucy?
<slangasek> dobey: great, thanks!
<jbicha> mardy: bug 1190018
<ubottu> bug 1190018 in shotwell (Ubuntu) "Shotwell shouldn't hard-depend on UOA" [Undecided,New] https://launchpad.net/bugs/1190018
<smoser> infinity, adam_g_ saw https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1124384 in saucy
<ubottu> Launchpad bug 1124384 in cloud-init (Ubuntu Saucy) "Configuration reload clears event that others jobs may be waiting on" [High,Confirmed]
<smoser> Preparing to replace upstart 1.8-0ubuntu2 (using .../upstart_1.8-0ubuntu5_amd64.deb)
<smoser> it seems from changelog of 1.8-0ubuntu5 that may be intended to be not possible ?
<adam_g_> smoser, FWIW i have no idea how old of a saucy cloud-image im using
<smoser> i meant xnox
<smoser> well, the goal was that the bug seen there should not occur on upgrade
<smoser> i think
<shakaran_> arges, it is "easy" to fix. You only have to edit a file and allow Crash report. I did that for fill my lastest bug, because if not you cannot fill a crash bug never.
<arges> shakaran_: yes i used the workaround. but i'm wondering why its disabled for apport-cli/apport-bug where it seems like the default behaviour should allow one to upload a crash report to a bug/new bug
<infinity> smoser: I think the implication in the changelog is that the running version (not the new version) needs to support lossless re-exec.
<infinity> smoser: Since the running version is what's responsible for serializing the objects.
<smoser>   * In postinst, check running upstart for the above version number or 1.9
<smoser>     or better and then perform lossless stateful re-execution. Other wise
<smoser>     check for runlevels 2-5 and perform partial stateful re-execution.
<infinity> smoser: Yes, keyword "running".
<smoser> "other wise"...
<infinity> smoser: "Otherwise, work as badly as it did before". :P
<smoser> we should have performed a partial, stateful re-execution
<smoser> hm..
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<infinity> smoser: It did do so.  And hit the same bug because ubuntu2 can't serialize the bits you care about.
<infinity> smoser: On upgrade from ubuntu5 or higher, it should work.
<smoser> i thought the plan was that it would not restart
<smoser> (ie 'partial')
<infinity> smoser: The way I read the postinst, it'll only reexec if (a) it supports full stateful re-exec, or (b) if it's runlevel 2-5.
<infinity> smoser: So, I assume your test was in runlevel 2.
<smoser> no.
<smoser> should not be at runlevel 2
<roadmr> hello folks! I used to be able to rsync rsync://old-releases.ubuntu.com/old-releases/ but as of this morning I can't (@ERROR: Unknown module 'old-releases'). Does anybody know what changed, or who should I ask about this?
<smoser> oh fiddle faddle.
<smoser> its a freaking race.
<smoser> maybe
<smoser> yeah, i think that is what happened. we are at runlevel 2. but that didn't mean that we had reached a safe state to reexec
<infinity> That's... Fun.
<infinity> It sort of goes away when your base version is ubuntu5 or higher.
<infinity> Since re-exec should DTRT.
<infinity> But if you're relying on this to work for, say, raring, then...
<OdyX> tkamppeter: aww, nice, we should get it ready for experimental, are you comfortable with the git packaging to do that ?
<vlad_starkov> Question: I got a problem after apt-get upgrade on Ubuntu 12.04 with raid1+encryption+lvm. After reboot the LVM-passphrase is always wrong! Anyone know this issue?
<doko> slangasek, could you give me a poiinter?
<slangasek> doko: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-binutils/: previous build succeeded (with a fix from pitti), latest upload seems to have lost that change
<vlad_starkov> Emergency question: I got a problem after apt-get upgrade on Ubuntu 12.04 with raid1+encryption+lvm. After reboot the LVM-passphrase is always wrong. After few tries it comes to initramfs# shell. Is it possible to check the passphrase right from initramfs shell?
<vlad_starkov> Any help appreciates!
<slangasek> vlad_starkov: this was an upgrade within 12.04, not an upgrade *to* 12.04 from some previous release?
<vlad_starkov> slangasek: right. That was just a regular software upgrade within 12.04 LTS.
<slangasek> vlad_starkov: since you're in the shell, it should be possible to manually unlock the disk and then resume boot; let me see
<slangasek> vlad_starkov: btw, at the shell, does your keyboard map appear to be correct?  That seems like the most likely culprit for your current problem
<vlad_starkov> slangasek: Probably you are right. I do all the stuff through KVM.
<slangasek> (e.g., if your passphrase is in russian and your keyboard is in english because of a configuration failure, it'll be hard to enter the passphrase from the initramfs shell either :p)
<vlad_starkov> slangasek: English only :-)
<slangasek> ok
<slangasek> vlad_starkov: even so, I would first check that when you type the passphrase at the shell, the right characters are printed
<vlad_starkov> slangasek: how can I make sure I when I enter the passphrase it hides behind the *
<vlad_starkov> slangasek: one momemnt pls
<slangasek> right - once we're sure it's not a keyboard issue, I can help you manually unlock the disk - but I have to look that part up
<vlad_starkov> slangasek: it's not a keyboard.
<vlad_starkov> slangasek: I can type passphrase in the shell
<doko> slangasek, ahh, thanks, forgot that ...
<slangasek> vlad_starkov: /lib/cryptsetup/askpass 'unlocking' | /sbin/cryptsetup -T 1 luksOpen /dev/$source_device $target_device_name  --key-file=-
<slangasek> doko: ok :)
<vlad_starkov> slangasek: so what should I fill in to the variables?
<slangasek> vlad_starkov: whatever it says in /conf/conf.d/cryptroot
<vlad_starkov> slangasek: OK. I see the target and source
<vlad_starkov> slangasek: http://cl.ly/image/1W1D0p2h0w0R
<slangasek> vlad_starkov: ok - so you want /lib/cryptsetup/askpass 'unlocking' | /sbin/cryptsetup -T 1 luksOpen /dev/disk/by-uuid/7d6240ba-2d09-4abc-831f-fba1e35a4f32 md1_crypt --key-file=-
<slangasek> (or you can write "/dev/md1" instead of the long name, if you prefer ;)
<vlad_starkov> slangasek: I think so
<vlad_starkov> slangasek: you type really fast for sure
<slangasek> vlad_starkov: hopefully that command succeeds when you give it the passphrase, and the /dev/md1_crypt file is created
<slangasek> vlad_starkov: yes, I've been told that ;)
<vlad_starkov> slangasek: should I do cryptupsetup luksHeaderBackup /dev/md1 header.img
<slangasek> I'm not familiar with that command
<slangasek> but I guess it wouldn't hurt :)
<vlad_starkov> slangasek: ok just made a backup of header
<vlad_starkov> slangasek: now lounch your command
<vlad_starkov> slangasek: 'unlocking' was a passphrase?
<slangasek> vlad_starkov: no, that's the prompt
<slangasek> it should print 'unlocking' and then let you type the passphrase (without displaying it)
<vlad_starkov> slangasek: so I ran the command and it returned 'unlocking'. What should I do next?
<vlad_starkov> aa ok
<slangasek> type the passphrase, hit enter :)
<vlad_starkov> sure
<vlad_starkov> slangasek: no key available with this passphrase
<slangasek> vlad_starkov: that doesn't sound good.  You should have an older kernel version available; can you try booting an older kernel?
<slangasek> maybe it's a problem in the kernel, or maybe it's a problem with something updated in the initramfs
<slangasek> either way, booting an older kernel should get around it if it's a problem with an update
<vlad_starkov> slangasek: wait a second
<vlad_starkov> slangasek: how to check whether it was decrypted?
<slangasek> vlad_starkov: by checking whether the $target device has been created in /dev (/dev/md1_crypt)
<slangasek> but that error message means it definitely wasn't
<vlad_starkov> slangasek: I tried one more time and changed l (L in down case) to I (i in uppercase) and it returned nothing
<slangasek> oh
<slangasek> "returned nothing" sounds like success :)
<slangasek> is /dev/md1_crypt there now?
<vlad_starkov> slangasek: no
<slangasek> hmm
<slangasek> still, the difference in behavior is promising
<vlad_starkov> slangasek: maybe I reboot the server and try to enter passphrase with uppercase i ?
<slangasek> I would suggest rebooting, and trying again with the "fixed" passphrase - yes
<vlad_starkov> slangasek: ok. 2 minutes..
<vlad_starkov> slangasek: My God!!! It works!
<tkamppeter> OdyX, up to now I have only modified stuff in existing branches and replaced the upstream source in the GITs of Foomatic, I never introduced a new branch (which we probably would need to do here).
<slangasek> vlad_starkov: aha :)
<vlad_starkov> slangasek: I feel myself like an idiot spent 1.5 hours dealing with it
<slangasek> vlad_starkov: I'm glad it was someone writing the passphrase down wrong, and not a critical bug that I have to fix ;)
<vlad_starkov> slangasek: Man thank you so much for you help!
<vlad_starkov> slangasek: I will read about encryption in Ubuntu. This is definitely white space in my knowledge!
<slangasek> LUKS is pretty nice to have... but yes, it's opaque to a lot of people
<vlad_starkov> slangasek: So after that incident I will do backups of LUKS-headers. Nice lesson for me though.
<robert_ancell> jdstrand, Can you set the commit message on https://code.launchpad.net/~jdstrand/lightdm/lightdm-1189948/+merge/168796?
<jdstrand> robert_ancell: I did already
<jdstrand> I tried to request a rebuild, but it didn't seem to work
<robert_ancell> jdstrand, ok, I can do that. Cheers
<jdstrand> thanks
<vlad_starkov> slangasek: After all, I will backup luks headers with "cryptupsetup luksHeaderBackup /dev/md1 --header-backup-file header.img" As someone just recommended me I have to backup LVM headers too. Do you know the correct command for that?
<slangasek> vlad_starkov: I'm afraid I don't, sorry.  If LVM headers were lost, I would expect to be restoring from backups ... probably to a new disk
<vlad_starkov> slangasek: OK. So as I think loosing luks headers is kinda much more painful than LVM
 * vlad_starkov backup backup backup...... and backup!
<xnox> vlad_starkov: one typically should backup the data itself, and not lvm/luks/raid headers. They do help to recover from certain types of corruptions & mistakes, but they are not replacements for full backups.
<slangasek> vlad_starkov: yes, and there's also a higher risk of these being lost to a "normal" operation (if someone incorrectly re-keys the disk).  Whereas an LVM header would typically only be lost because of a disk failure
<slangasek> also what xnox says :)
<hallyn> Daviey: smoser: zul: got a question on path forward for qemu-kvm in precie
<vlad_starkov> xnox: sure.
<arges> hallyn: bug 1189926
<ubottu> bug 1189926 in qemu-kvm (Ubuntu Precise) "data corruption in storage attached to VM using KVM" [High,Triaged] https://launchpad.net/bugs/1189926
<hallyn> there i a data corruption bug in the qcow2 stack in 1.0, which noone seem to be sure how to cleanly bckport
<hallyn> ^ tht one :)  (thanks arges)
<vlad_starkov> slangasek: am I right thinking that luks headers leave the same if I don't change the passphrase?
<hallyn> so I intend to do a merge from 1.2 upstrem, or from 1.2 debian, plus the commit that fixes it - and hope that is accepted for SRU
<slangasek> vlad_starkov: yes
<vlad_starkov> slangasek: so it's good
<infinity> hallyn: Bumping the entire qemu packaging and source to 1.2?  That seems unlikely to be accepted.
<hallyn> my inclination is to merge from debian.   But precise was bsed on upstream qemu-kvm.  Any objections to my switching?
<hallyn> infinity: it's a tough sell, but I'm nto sure there is an alternative otehr than not fixing the bug
<hallyn> infinity: the plus side would be it's in use in wheezy and squeeze-bckports
<hallyn> and it now has an active maintainer (mjt)
<hallyn> we can simply tell people who hit the bug to use a 1.5 backport...
<xnox> vlad_starkov: if you re-initialise the disk again with same settings and passphrase, all your data will not be accessible any more, as a new encryption key will be generated and used for the data.
<hallyn> anyway there's still a very minimal chance that upstream (kwolf) will have a fix, I was just goign to start a merge as a contingency
<xnox> vlad_starkov: to be on a safe side I'd recommend backing up securely the actual encryption key used or complete luks headers using dd or luksHeaderBackup like you used above.
<infinity> hallyn: The commit in question is a 1-liner... I assume it doesn't apply because it modifies code that doesn't exist in 1.0?
<hallyn> infinity: there's that, and the code has changed so much that it's doubthful that the one-liner by itself suffices
<arges> infinity: there have been quite a few changes to the qcow2 code, and this one liner is really just the final patch that fixes it. we could go with a large set of cherry-picks that fix the issue, but I'm unsure that would make a good SRU candidate
<arges> large set == re-write of much of the qcow2 allocation/cluster code
<vlad_starkov> xnox: Currently I have RAID1. So if 1 disk fail, the other one will boot in degraded mode?
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<vlad_starkov> xnox: what is the best practice of backup the entire disk/raid through the network?
<doko> infinity, did we have a bug report for ld.so loading the libraries of a wrong architecture?
<infinity> doko: You mean failing to skip them and erroring out instead?
<infinity>   * debian/patches/any/unsubmitted-ldso-machine-mismatch.diff: Skip past
<infinity>     libraries that are built for other machines, rather than erroring.
<infinity> I didn't close a bug with that changelog entry, so I'm going to assume we didn't have one.
<infinity> Though I need to clean that whole area up a bit and submit some sanity upstream.  It's going to lead to an argument I don't want to get into.
<doko> infinity, in raring?
<infinity> doko: That's in raring, yes.
<doko> hmm, doesn't seem to work
<doko> at least when targeting aarch64
<infinity> doko: Maybe it would help if you told me what you're experiencing instead. :P
<doko> tomorrow, chasing a gcc cross build issue for hours
<infinity> doko: Does aarch64 define __arm__ by any chance?
<doko> no
<infinity> Kay, that's about the only place I see where this could go wonky.
<infinity> But a copy and paste of the errors you're seeing might be more enlightening.
<infinity> Assuming it's not just an opaque "dpkg-shlibdeps hates us" error.
<doko> well, it's the perl issue
<doko> so nothing unknown
<doko> but maybe ld.so could be more intelligent
<infinity> But we already have aarch64 cross packages in the archive, I'm a bit curious why this would suddenly have stopped working.
<hallyn> arges: the more i look at this, the more i'm convinced that the one-line commit actually fixed something that was broken right before it, in commit 250196f19c6e7df12965d74a5073e10aba06c802
<doko> cjwatson did cross-build gcc-4.7
<doko> not sure what he did do
<hallyn> arges: infinity: ^ meaning the 1-liner would be unrelated to the *actual* fix for the bug
<infinity> doko: I was referring to gcc-4.7-aarch64-linux-gnu and gcc-4.8-aarch64-linux-gnu ...
<infinity> doko: Those wouldn't exist if my patch wasn't working, no?  Since the patch was needed for ppc64 and aarch64 both.
<doko> that's build the cross compiler, not cross building the compiler
<infinity> Okay, well, cross-building the compiler might be an entirely different bug we're tripping on, then. ;)
<infinity> Happy to look into it, if someone gives me something slightly more reduced.
<doko> and at some point, I'll get to cross building the cross compiler ...
<arges> hallyn: yea i was trying to backport that patch too... its a doozy though, and needs a lot other changes before hitting v1.0
<infinity> (Or just a tarball of a failed build tree, and a description of what command breaks)
<hallyn> arges: you know in a case like this bisect could in fact be wrong.  heck commit aef4acb6616ab7fb5c105660aa8a2cee4e250e75 may have fixed it too - the more recent commits were unrelated (adding tracing and factoring out functions and such)
<infinity> doko: Cross-building cross-compilers sounds like masochism. ;)
<cjwatson> doko: Like I said to you in /msg, I didn't do anything special, just preinstalled the cross gfortran in the chroot
<cjwatson> doko: Hopefully gcc-4.8 will build natively in stage1 and then we won't need to worry immediately
<doko> infinity, we need a cross compiler for aarch64 targeting armhf, and maybe I do want to do that on a fast platform. so much for the use case
<doko> cjwatson, sorry, didn't see the msg
<infinity> doko: I can't see how this is necessary for out initial bringup.  And once we're building natively on a bunch of parallel buildds, if it takes time, it takes time.  Oh well.
<doko> well, it would be a use case for the canadian cross
<doko> but you know these canadians better than me
<doko> anyway, good night
<infinity> 'Night.
<mwhudson> doko: do you ever see test_io hang building python on armhf?
<xnox> vlad_starkov: just see normal backups, rsnapshot (for small) or bacula (for very large) are good for backups. Also see https://help.ubuntu.com/community/BackupYourSystem for many available options.
<vlad_starkov> xnox: thanks
<smoser> hallyn, i'm afraid i dont have anything to add to the above.
<smoser> only that the cloud archive probably already has a newer version of qemu-kvm for precise ...
<smoser> and that is a supported path.
<hallyn> arges: ^
<hallyn> smoser: ok, I'm looking at what a quantal + wheezy merge would look like, and arges has a working (though not yet qa-tested) patch cherrypick so we may just stick with 1.0 in precise after all
<hallyn> if nothing else, i've got a set of patches which should be added to quantal (low prio as that may be :)
<smoser> that would be nice.
<hallyn> now what is quantal's lifetime again?  /me checks
<hallyn> till april
#ubuntu-devel 2013-06-12
<arges> smoser: I didn't see qemu-kvm in http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/ when I checked
<infinity> doko_: Fixed binutils uploaded (for libiberty, and restoring the lost changes from vorlon and pitti), so you don't have to worry about it.
<OdyX> tkamppeter_: I'll prepare a 1.7 branch for you today and keep you posted.
<dholbach> good morning
<pitti> Good morning
<pitti> infinity: cheers
<Noskcaj> jbicha__, ping
<tkamppeter> OdyX, OK.
<tvoss> didrocks, ping
<didrocks> tvoss: pong
<sil2100> Wellark: ping
<zyga> pitti: ping
<pitti> zyga: pong
<zyga> pitti: my google foo and memory are failing me, could you please point me to some place that explains the changes to dbus session bus, I recall reading that some kind of new bus type is coming (user bus?)
<pitti> zyga: that hasn't landed yet; I'm not sure when that's being planned upstream (or whether it's systemd specific)
<pitti> maybe it also got obsoleted with logind, I'm not sure; in any way it's been a long time since I've heard about it
 * pitti asks desrt
<zyga> pitti: so it's not something super defined yet, ok
<zyga> thank you
<pitti> zyga: I asked Ryan, but probably he's asleep
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
 * dholbach hugs didrocks
 * didrocks hugs dholbach back, couldn't do my shift the other day with unity7/touch apps and so on :)
<dholbach> no worries :)
<infinity> doko: Does the binutils shlibs need to be so painfully restrictive?  We're going to have to reupload every kernel that builds a tools package for every new binutils snapshot...
<doko> infinity, there is no abi
<doko> sometimes even if I keep it, and add a patch, it doesn't build anymore. maybe you do remember ...
<infinity> doko: Yeah, I get that.  I guess this is something we get to suffer with if we use snapshots.  I hope you don't plan to upload a bunch of them before 2.24
<infinity> Not that I mind a bunch of mini-transitions, it's just a bunch of mini-transitions involving rebuilding a bunch of kernels could get annoying. :)
<doko> too late, just uploaded. but yes, trying to keep this soversion as stable as possible
<pitti> infinity, doko: any chance that the "Depends: build-essential" fix can get committed to Debian as well, to avoid losing it again? (also, it's necessary for Debian, too)
<doko> so why did the kernel needs this?
<doko> I thought that was just for libiberty?
<infinity> doko: "too late, just uploaded", as in you uploadd a new snapshot again? :/
<doko> yes
<doko> pitti, debian binutils never had the autopkg tests
<pitti> doko: ah, ok; I thought it was a victim of merging; so, nevermind
<infinity> doko: britney claims that linux and linux-grouper, at least, depend on binutils.  I'd have to look at why.  My assumption would have been libbfd.
<doko> is this gperf?
<infinity> (saucy-amd64)root@cthulhu:~# ldd /usr/bin/perf_3.9.0-5 | grep bfd
<infinity> 	libbfd-2.23.52-system.20130611.so => /usr/lib/libbfd-2.23.52-system.20130611.so (0x00007fbaa6cea000)
<infinity> doko: Oh, bah.  This is a direct result of the libiberty-gone-missing oops.
<infinity> doko: I'll get it fixed up with the kernel team.
<infinity> doko: perf only needs bfd in the alternate linkage case rtg forced because iberty was gone.
<seb128> infinity, just curious, what's the status of the unity SRU for raring?
<doko> infinity, I asked wookey to build a libiberty-dev package from a separate source
<infinity> seb128: I was waiting for someone to figure out how to upload a package with a fixed changelog, but I've given up on that.  I'll re-review today, and reject the one(s) I don't like.
<seb128> infinity, thanks
<doko> infinity, there is still libiberty_pic.a
<didrocks> infinity: AFAIK, Mirv is preparing/have a bamf with a fixed changelog (it's the only one I know about)
<infinity> doko: Well, there's both now.
<Mirv> didrocks: I put it into the google doc, https://launchpad.net/~unity-team/+archive/sru/+files/bamf_0.4.0daily13.05.31%7E13.04-0ubuntu2%7Etest1.dsc
<didrocks> Mirv: ah, good! so infinity: bamf fix on the way :)
<didrocks> (in this patch pilot shift)
<Mirv> so it could be uploaded, although I'm not sure with which version since the ubuntu1 sync request is in the queue
<didrocks> Mirv: reuse the same version, I'm going to reject the one in the queue
 * soren realises that pxe-kexec can be used to trigger d-i in the cloud and falls out of his chair
<Mirv> didrocks: ok, well take that ubuntu2~test1 and upload as ubuntu1 instead.. since it's a dget from a superseded daily-build PPA content, I don't have any bzr or such anyhow
<didrocks> Mirv: ok, will do!
 * infinity gets soren a seatbelt for his extreme computing.
<Mirv> thanks
<didrocks> thanks to you :)
<stokachu> whats the best way to get a BuildID from a kernel image?
<stokachu> for example i can get it from a binary with file
<stokachu> /bin/zsh4: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x336c8162902093067f2186b7e6ac233b74d7ce77, stripped
<stokachu> if i do a eu-readelf there is a section in .notes about a GNU_BUILD_ID though not sure if that is the same thing
<cjwatson> stokachu: use scripts/extract-vmlinux from the kernel source tree to extract the uncompressed vmlinux (scripts/extract-vmlinux /path/to/vmlinuz >vmlinux)
<stokachu> cjwatson: ah nice ill check that out
<cjwatson> It doesn't have a .note.gnu.build-id section though; I wonder where file gets it from
<stokachu> cjwatson: should i use the eu-readelf instead?
<stokachu> there is a build id in the .notes section but nothing about .note.gnu.build-id like the others
<infinity> I'm vaguely confused by file's output there anyway...
<infinity> (base)adconrad@cthulhu:~$ file /bin/mv
<infinity> /bin/mv: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xe438743eb3051f02aff0dd6e051e7ad7d035c286, stripped
<infinity> (base)adconrad@cthulhu:~$ readelf -a /bin/mv | grep Build
<infinity>     Build ID: 3e7438e4021f05b36eddf0afd77a1e0586c235d0
<stokachu> exactly!
<cjwatson> well, just readelf would do
<stokachu> i think ill stick to readelfs build id
<stokachu> eu-readelf -n /boot/vmlinuz-3.2.0-45-generic
<stokachu> that gives me a build id
<cjwatson> like I say, readelf will do and is more widely installed
<stokachu> sounds good to me
<cjwatson> the build IDs printed by readelf and file are the same, just byte-swapped
<stokachu> ok
<cjwatson> (flip four-byte chunks, you'll get the same answer)
<didrocks> pitti: mind marking https://code.launchpad.net/~darkxst/ubuntu/raring/gnome-shell/lp1064584/+merge/165828 as merged?
<OdyX> tkamppeter: pushed the master-experimental branch to cups.git, feel free to push nicely isolated commits on there; no need to include paths for all commits, remember ;) .
<OdyX> tkamppeter: beware, the master-experimental branch is based off master, which has the staged changes for jessie/unstable.
<pitti> didrocks: done
<didrocks> pitti: thanks :)
<pitti> where would I file a bug against the kernel that is running on the phablet image? the chroot doesn't have a kernel package
<pitti> 3.1.10-3-grouper
<ogra_> pitti, linux-grouper for nx7, linux-maguro for galaxy nexus, manta for n4 and mako for n10
<ogra_> they are all in the archive
<pitti> https://launchpad.net/ubuntu/+source/linux-grouper/+bugs
<pitti> "no open bugs"
<pitti> wow :)
 * pitti is going to add the first one then
<ogra_> well, its pretty new
<pitti> I stumbled over a reboot command without any confirmation or security checks :)
<pitti> cat /sys/devices/platform/tegra-i2c.4/i2c-4/4-006a/reg_status
<pitti> (as user)
<ogra_> note that HW bugs you might experience can be android bugs ... :)
<ogra_> ah, well, sysfs cat reboot sounds actually like kernel, yeah
<pitti> filed, thanks
<RoyK> hi all. any clue about bug 1189567?
<ubottu> bug 1189567 in xfsprogs (Ubuntu) "xfs_repair fails to repair filesystem" [Undecided,New] https://launchpad.net/bugs/1189567
<roadmr> hello folks! I used to be able to rsync rsync://old-releases.ubuntu.com/old-releases/ but as of this morning I can't (@ERROR: Unknown module 'old-releases'). Does anybody know what changed, or who should I ask about this?
<Laney> roadmr: IS might be a good first port of call
<roadmr> Laney: thanks, I'll ask over there
<xnox> smoser: did you get a chance to test cloud-init in saucy with updated upstart? are there saucy daily or weekly cloud-init images available somewhere for me to try?
<didrocks>  pitti: and to be marked as merged: https://code.launchpad.net/~timo-jyrinki/ubuntu/precise/compiz-plugins-main/fix_755842/+merge/162934 that will be the last for today, I can handle the other ones :)
<pitti> didrocks: done
<didrocks> thanks :)
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smoser> xnox, still around ?
<xnox> smoser: yeap.
<smoser> we had issues yesterday.. it seems that the upgrade isn't working as i had desired.
<smoser> did you see that info ?
<xnox> smoser: no, i didn't see that. Where, what?
<smoser> http://irclogs.ubuntu.com/2013/06/11/%23ubuntu-devel.html#t19:10
<smoser> it seems to me that the problem is that during the upgrade, upstart thought it *was* at runlevel 2.
<smoser> as i understood it, the idea was to only restart upstart if runlevel 2 had been reached (or suitable older version found)
<xnox> smoser: correct, so it must have been at runlevel 2 already. It performed stateful re-exec, and rightfully did not preserve "pending" / "blocked" events if old upstart was still running as pid 1.
<xnox> smoser: is there a way for me to execute cloud-init image in an lxc container with upgrade to see how it behaves and what's wrong?
<smoser> probably.
<stgraber> xnox: yes, that's how I've been doing testing of those
<xnox> smoser: do cloud-init jobs actually block runlevel 2 event? reaching runlevel 2?
<smoser> you can probably recreate with 'lxc-create -t ubuntu-cloud'
<xnox> right, ack.
<smoser> xnox, they dont' block runlevel 2
<smoser> that is what i noticed.
<xnox> hm. but I need to use some old image.
<xnox> smoser: =(((((( we assumed that cloud-init does all of it's stuff before runlevel 2 is emitted.
<xnox> well reached.
<smoser> $*%#ing parallelism !
<smoser> rc-sysinit.conf is : start on (filesystem and static-network-up) or failsafe-boot
<smoser> and cloud-config.conf is: start on (filesystem and started rsyslog)
<stgraber> xnox: IIRC what I did was create a new cloud container (lxc-create -t ubuntu-cloud -n p1 -- -r raring), then chroot into the container, downgrade some stuff, then make sure /var/lib/cloud is empty except for /var/lib/cloud/seed, then start the container.
<stgraber> xnox: oh, and you need a userdata file (or whatever it's called) to set the update flag, otherwise cloud-utils won't apply updates at boot time
<smoser> right.
<smoser> but basically, nothing is going to stop rc-sysinit from running.
<smoser> i'm not sure if its a bug or not that rc possibly runs parallel to cloud-config.conf. its not ever been a problem itself.
<stgraber> xnox: unfortunately I didn't really take much notes about this, I mostly did that based on directions from jibel and smoser and removed the container from my machine a week ago (otherwise I'd just have given you a compressed version of it)
<xnox> smoser: so which of the jobs runs dist-upgrade, cause that's the one that should be either running after everything else cloud-initish is done? or it should run whilest runlevel 2 has not been reached.
<smoser> xnox, kvm recreate is at https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1103881
<ubottu> Launchpad bug 1124384 in cloud-init (Ubuntu Saucy) "duplicate for #1103881 Configuration reload clears event that others jobs may be waiting on" [High,Confirmed]
<xnox> smoser: k, thanks.
<smoser> you cnan just download a few-day-old saucy
<smoser> xnox, i'm not sure how to do this well.
<smoser> well... one way (possibly hackish)
<smoser> is to say "if cloud-config is running, do not upgrade"
<smoser> er... do not re-exec
<smoser> that'd solve this specific problem
<xnox> smoser: http://cloud-images.ubuntu.com/saucy/ only has back to 20130609.
<smoser> xnox, that has upstart 1.8-0ubuntu4
<smoser> is that not old enough ? otherwise you'll have to downgrade
<smoser> i can show you how i'd do that if you needed.
<xnox> smoser: nah, that has full serialisation already.
<xnox> smoser: must downgrade. or start raring container and dist-upgrade =)))))
<smoser> yeah. so you should be able to reproduce this in lxc or in kvm. but either way will require you to downgrade.
<smoser> i use: http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/revision/15#mount-callback-umount
<smoser> to "mount - run some code - umount" of a qcow image.
<smoser> better link: http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/mount-callback-umount
<xnox> k, thanks. I'll try that and get back with better fix.
<hallyn> infinity: would you mind kicking the libcgroup precise-proposed upload for version 0.37.1-1ubuntu11 ?
 * hallyn lost the version number choosing game again
<infinity> hallyn: "kicking" as in rejecting from the queue?
<hallyn> infinity: yes
<infinity> hallyn: Done.
<hallyn> infinity: thanks
<tvoss> cjwatson, ping
<cjwatson> tvoss: hi
<tvoss> cjwatson, can you join us on https://plus.google.com/hangouts/_/a0a4f88494fc4074198be533bd959ae80e43303a
<cjwatson> tvoss: what's the topic?
<tvoss> cjohnston, an app centric world
<cjwatson> um, ok, that sounds like marketing ... ;-)
<Laney> O_O
<cjwatson> stgraber,xnox: is there anything preventing us cherry-picking the apparmor patches to upstart into saucy?
<xnox> cjwatson: well it was aimed to be part of upstart 1.9 release for saucy once jodh comes back.
<xnox> cjwatson: it could be uploaded to saucy soonish. But I was hoping to fully resolve "full-serialisation & cloud-init bug" in saucy & SRU into raring first.
<cjwatson> hm, ok
<cjwatson> jdstrand: ^-
<cjwatson> the serialisation thing is indeed best to sort out before the next upload
<xnox> (if i will have luck with lxc/cloud-init containers tomorrow, and sru goes through quickly, we can look into getting apparmor into saucy friday going on next week)
<jdstrand> waiting til jodh comes back is ok with me
<jdstrand> we can work with ppas/etc in the meantime
<cjwatson> ok
<slangasek> jdstrand: in that case, you can probably take the upstart upstream daily-build ppa?
<jdstrand> slangasek: does that have armhf enabled?
<slangasek> I believe so
<jdstrand> slangasek: thanks, I'll look into it
<slangasek> https://launchpad.net/~upstart-devel/+archive/upstart-daily-build
<slangasek> hmmm nope, not that one
<slangasek> at least, there's no armhf there
<jdstrand> and no saucy
<jdstrand> np
<slangasek> jdstrand: ah, here we go. https://launchpad.net/~canonical-foundations/+archive/upstart-daily
<jdstrand> slangasek: nice. would you be able to enable saucy build there too?
<slangasek> jdstrand: it seems to be built for raring, but it's still the right code and should be installable on saucy.  Moving it to build for saucy means changing the recipe build, I guess
<slangasek> I'm not sure I know where that lives
<jdstrand> I thought it was just a checkbox
<slangasek> stgraber: ^^ do you know where the upstart daily recipe build is?
<jdstrand> let me see if I can conjure up a url
<stgraber> slangasek: https://code.launchpad.net/~canonical-foundations/+recipe/upstart-daily-nonvirt
 * jdstrand was >< close to giving that :)
<jdstrand> slangasek: under Distribution series, you should have a way to enable saucy and any other releases you want
<slangasek> hmmm, so it's under code.launchpad.net, but is not a branch, ok
<slangasek> changed to saucy going forward
<slangasek> stgraber: does this recipe pull in the Ubuntu packaging delta?
<slangasek> ah, it does
<stgraber> slangasek: right, the recipe is owned by ~canonical-foundations but we're using the ~upstart-dev branch as the source. We had to move the recipe to ~canonical-foundations so it could use the non-virt PPA
<slangasek> but it uses the raring packaging :)
 * slangasek moves this to lp:ubuntu/upstart
<stgraber> slangasek: I'm pretty sure I had that set to lp:ubuntu/upstart back in raring, I suspect LP is very good at changing all references when we create the new series and so we'll have to keep on updating it every time a new series open
<slangasek> ah, fiddlesticks
<slangasek> ok
<geser> does somebody know if/when we get apache 2.4 into saucy? there is a bunch of packages waiting on dh-apache2 from apache2-dev
<mterry> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<cjwatson> It was waiting for the libgd2/net-snmp transition to clear, but that's done now.  However, I'd request that if you're doing this you try to work out *first* whether enough of the transition is done in Debian that we could clear it through -proposed in Ubuntu within a week or so
<cjwatson> Otherwise it gets even harder to land changes
<cjwatson> Some of these transitions are started in Debian and then not pursued as aggressively as would be ideal (I had to fix a fair bit of libgd2 myself)
<RoyK> bug 1189567 seems to be easy to fix - anyone into xfs here?
<ubottu> bug 1189567 in xfsprogs (Ubuntu) "xfs_repair fails to repair filesystem" [Undecided,New] https://launchpad.net/bugs/1189567
<geser> considering that there is RC-bug on apache2 to prevent it from migrating to testing, it seems more modules need to transition first before it gets cleared
<geser> lets hope it gets done soon before we (the ubuntu release team?) decides to stay with 2.2 and we need a solution for those build-depending packages on dh-apache2
<infinity> geser: Feature Freeze is a looong way out, I think we'll be alright holding off a little bit.
<ogra_> heh, feature freeze
<geser> infinity: yeah, just noticed it too, that FF is end of August
<cjwatson> geser: well, *a* solution is to leave them in -proposed
<cjwatson> obviously not necessarily ideal if we need to change them
<geser> would it be possible to SRU a package if a newer version it stuck in -proposed till after release?
<cjwatson> Well, we'd move it to <next>-proposed after release
<infinity> geser: We'd remove it from -proposed if it never migrated (as we did last release)
<infinity> Well, s/remove/move/, as Colin says.
<cjwatson> But I'm not sure whether LP will forbid -proposed from going backwards
<infinity> Hrm.  It probably does.
<infinity> That could be fixed, though.
<cjwatson> Looks like the relevant ancestry check only looks for PUBLISHED and PENDING.
<cjwatson> So it should work.
<cjwatson> You just don't get to *reuse* a version.
<geser> so it's still nice to resolve all those FTBFS and DEPWAIT in -proposed till release but as important as in last releases (before the introduction of -proposed migration) for SRUs and security updates?
<infinity> I feel like that sentence might have been missing some words.
<cjwatson> We have a bit more flexibility, at least.
<cjwatson> Once I get round to fixing a bug in the LP copier, I plan to start demoting stuff from release to -proposed when it's sufficiently broken.
<geser> infinity: ... but not as important ... (I hope I didn't miss any more words)
<infinity> cjwatson: I'm still trying to sort out when that would be a good idea.
<infinity> cjwatson: We can't force users to downgrade afterall, so removing a package from the release pocket doesn't really remove it from the wild in any meaningful way.
<cjwatson> We remove packages in other cases ...
<infinity> We remove because we're removing things completely, sure.
<infinity> But that's a bit different from a "temporary demotion" that should usually just be someone fixing it.
<cjwatson> Also, there's still a handful of sources with no binaries for one reason or another that got into release pre-proposed-migration, but where I'd rather not remove the source entirely because they still ought to get fixed.
<infinity> The exception to that being the group of packages with only source in the release pocket, but that's a one-time fix.
<cjwatson> And of course there's a chunk of uninstallables in the release pocket.
<cjwatson> Each of those has the effect of making proposed-migration a bit less reliable (because it only checks for lower uninstallable count, not a strict subset)
<cjwatson> Anyway, I do expect it to be rare-ish, but I'd like to have the option
<infinity> cjwatson: Do we have britney output for the full archive somewhere readable?
<cjwatson> I don't think so.  It's years since I tried, but I gave up after six hours
<infinity> cjwatson: saucy_probs being main-only is a bit unhelpful for clearing up the remaining uninstallables.
<cjwatson> Maybe it'd be faster now, dunno
<cjwatson> Feel free to have a go and see if it completes in finite time nowadays
<infinity> Heh.
<infinity> I'd probably be happy to manually run it a few times over a few months while we fix and/or demote what's still broken.
<infinity> Cause after that, other than people forcing things in (ugh), we should be able to stay clean.
<geser> ubuntuwire has a debcheck page but it isn't updated anymore since Nov 2012
<smoser> hey..
<smoser> i'm looking at http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/current/images/SHA256SUMS
<smoser> what is "gtk" there?
<smoser> in things like 'cdrom/gtk/initrd.gz'
<smoser> what does that indicate ?
<psusi> hrm... debian seems to have added a new X/gtk frontend to d-i... I wonder if that's it
<jpds> smoser: Well, booting its mini.iso brings up a little GTK installer.
<psusi> I've been wondering why we haven't adopted that in our cds yet
<psusi> last time I set up a debian vm with it, it was quite nice
<jpds> smoser: wget http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/current/images/netboot/gtk/mini.iso
<infinity> arges: \o/
<infinity> arges: Yay for a simple patch for that instead of backporting madness.
<infinity> arges: (re: qemu qcow2 issues)
<qengho> Hi all.  I am trying to use pbuilder-dist to build some package for armhf.  It complains that it can't satisfy "cdbs" build dependency, even though I see it as installable if I "pbuilder-precise login" and "apt-cache policy cdbs".  I can install it manually, too. My debian/control has no version specified for cdbs. I think I need help debugging it.
<arges> infinity: thanks! yea i was happy about it too
<slangasek> psusi: hi, if you're going to do triage work on acpi-support bugs, it would be more useful to assign them somewhere else entirely :)
<slangasek> psusi: because the acpi-support package is legacy and contains only a handful of event handlers in saucy, all of which we want to see moved elsewhere as we find places to land them
<alesage> fginther, ted had a question about where he should assign his new project
<alesage> sorry tedg :) ^^
<alesage> where tedg's new proj probably belongs in a couple of stacks--how should one choose, fginther?
<fginther> alesage, tedg, you mean which stack should it go into?
<alesage> fginther, yes
<tedg> fginther, Yes, it needs to get into the phablet PPAs but I'd rather do the standard distro targets.
<fginther> alesage, it comes down to if it has any dependencies that need to build first and if it needs to be built with anything...
<tedg> fginther, No, none of those.
<tedg> fginther, Eventually Unity 7 and 8 will dep on it, but not yet.
<fginther> tedg, the phablet stack files are really just a crutch until things are in distro. So if we can put it under 'head' all the beter
<tedg> fginther, Sounds fine to me
<tedg> fginther, It's the phablet guys that don't like hearing that their builds are a demoware ;-)
<alesage> tedg stop rattling cages jeez ;)
<alesage> can't we all just get along
<alesage> thx fginther for your advice
<tedg> alesage, That's no fun!
<tedg> :-)
<fginther> tedg, I'm looking at the stack dependencies. Right now unity.cfg might be the best answer.
<tedg> fginther, I put it in misc for now.
<fginther> tedg, the integration team will need to review, they may have a better answer
<tedg> fginther, I figured that was easier to get started.
<anon^_^> is there a preferred method of contact to reach the admin of packages.ubuntu.com
<fginther> tedg, works for me
<tedg> fginther, alesage, thanks guys!
<alesage> tedg np!
<anon^_^> it doesn't appear that the website is reflecting updates/security updates over the past month to multiple Ubuntu releases
<sarnold> anon^_^: indeed, at least libx11 is missing raring's security update
<anon^_^> yeah the entire package db looks like it hasn't been updating since late april
<sarnold> anon^_^: ah, at the bottom there's an "email rhonda@ubuntu.com". can't hurt as a place to start. :)
<anon^_^> i'd prefer irc
<anon^_^> lol
<anon^_^> maybe i'll just wait for cjwatson to appear
<cjwatson> qengho: If you mean building armhf packages on an x86 host, I doubt you'll get far using pbuilder for cross-building - as far as I know it hasn't been taught how to do it.  Use a recent version of sbuild instead, as per https://wiki.ubuntu.com/CrossBuilding
<cjwatson> anon^_^: I have no control over packages.ubuntu.com
<cjwatson> anon^_^: Try #canonical-sysadmin
<anon^_^> rhonda's online just not in chan
<anon^_^> sending her a pm
<sarnold> don't forget that freenode isn't only ubuntu..
<qengho> cjwatson: I figured it out. eatmydata works for native, but for qemu-emulated architectures, it fails, in a weird, weird way:  Can't satisfy cdbs build-dep. Obviously.
<chiluk> smoser mterry can you guys look at https://bugs.launchpad.net/compiz/+bug/1083186  ?
<ubottu> Launchpad bug 1083186 in unity (Ubuntu Quantal) "icaclient windows "dancing" when decorated" [Undecided,New]
 * mterry looks
<chiluk> the sru is seriously stalled.
<chiluk> and I'm not sure how else to push on it .
<slangasek> chiluk: unity and compiz packages were uploaded to precise-proposed just today; you can reasonably expect them to be accepted into precise-proposed sometime this week
<chiluk> thanks slangasek
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2013-06-13
<pianogmx> question for developers, I am going to school for programming but how can i find a project team to mentor me?
<pianogmx> anyone?
<sarnold> pianogmx: best would be to find something that interests you, find a missing feature or a bug that bothers you, and offer a patch to try to fix it..
<pianogmx> sarnold, so if I wanted to do like useful utilities like maybe xchat, how would I go about starting then?
<sarnold> pianogmx: probably in that case you'd want to find the upstream code source, check it out of whatever version control they use, build it locally, test it out, try to figure out how to add whichever features you want, and perhaps ask on irc or mail lists if you need a hint about where to look in the source code for related code...
<pianogmx> okay ima do some research, and idle here for a bit
<sarnold> cool :)
<syntroPi> is there any tablet around which is supported by ubuntu with normal desktop ui like unity and gnome shell?
<pitti> Good morning
<dholbach> good morning
<dylan-m> Good morning, dholbach! :)
<dholbach> hey dylan-m
<vipzrx> morning
<pitti> infinity: btw, has it ever been discussed to run the soyuz builds under eatmydata or setting that dpkg option for unsafe io? considering that installing the build deps takes like half of the build time for small packages, that might considerably lower the PPA build lag?
<xnox> pitti: unsafe io at dependency installation should be ok. running the whole build under eatmydata will make upstart testsuite fail and possibly others as it actually relies on fsync() working.
<xnox> (also upstart testsuite fails if the whole build is done in tmpfs as well....)
<pitti> so, unsafe-io then :)
<pitti> but FTBFS in tmpfs sounds like a bug
<Daviey> xnox: Why does eatmydata fail the testsuite?
<xnox> pitti: upstart tests gazzion ways one can modify a conffile and makes sure it's reloaded when changes via inotify or not. things have improved with 1.9, but I am still building 1.8 for the distro.... Will revisit that pest once 1.9 lands for the distro.
<pitti> xnox: oh, our tmpfs doesn't support inotify?
<xnox> pitti: i believe it does.
<xnox> that's the funny bit.
<xnox> Daviey: eatmydata makes fsync() not actually fsync() and hence data is not written out to disk when one requests for that to happen. Apart from that, I was not spending more time debugging it.
<xnox> I'm glad that running test-suite in parallel works fine with 1.9 and up, and does race itself =)
<jibel> python testsuite failed for the same reason and this is why I disabled eatmydata in package testing.
<pitti> oh, python3.3's autopkgtest succeeds now, great!
<Daviey> xnox, jibel: Ugh, that is rubbish.  I was hoping to use eatmydata more.
<xnox> Daviey: there is no magic in what eatmydata does, it really trades IO speed for reliability. I run all of my sbuilds on tmpfs & eatmydata, but have a modifier schroots that disable that when I notice a weird build failure from time to time.
<Daviey> xnox: I know what it does.. :)
<xnox> "perl: warning: Falling back to the standard locale ("C")." why not fallback to C.UTF-8 ?!
 * xnox hides
<rbasak> I wonder if it's possible to do what eatmydata does but at a different level. Virtualisation perhaps? Or how about a kernel interface to noop syncs?
<rbasak> Would that need disabling O_DIRECT in order to remain transparent to userspace?
<rbasak> AFAICT it should be possible to make eatmydata-like functionality completely transparent to userspace.
<rbasak> (for virtualisation I think libvirt's unsafe caching does something very similar)
<cjwatson> mitya57: None of the outstanding Ubuntu patches to llvm-toolchain-3.2 are needed in llvm-toolchain-3.3?
<mitya57> cjwatson: only the Ubuntu version patch is not applied upstream, I think it's not worth having a delta because of that
<mitya57> (especially while 3.3 is not default)
<mitya57> cjwatson: I'll now forward that upstream
<mitya57> (done)
<cjwatson> mitya57: The Ubuntu version patch is IIRC much more important than it looks, because it causes LLVM to choose a substantially different set of defaults
<cjwatson> If we don't have that patch, I'd say this package should not be in Ubuntu
<mitya57> cjwatson: I'll ask Sylvestre_ to add it in Debian then (and also fix powerpc build)
<xnox> smoser: tested cloud-init with kvm and later with lxc once i figured out how to pass user-data to it. In short, reload-configuration can go back in, but with a version guard checking `initctl version`. In all other cases, instances should always finish initialisation. If one adds upstart jobs via user-data, they might not run, thus a reboot or manually starting them is required.
<xnox> smoser: see email for details. But I will preparing raring SRU with changes as it currently is. I don't see how we can improve the situation any better, retrospectively.
<smoser> xnox, email where?
<xnox> smoser @ u.c
<smoser> replied, xnox
<rbasak> infinity: please see bug 1187722 when you have a chance. I thought you just sponsored SteveMcIntyre's patch but he says you were more involved? I asked him for feedback in #linaro.
<ubottu> bug 1187722 in golang (Ubuntu) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [High,Confirmed] https://launchpad.net/bugs/1187722
 * rbasak finds infinity in #linaro
<smb> infinity, Near daily reminder for crash backports review. You are likely pleased to hear I try to load-balance xen over to apw...
<ev> mpt: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1064395
<ubottu> Launchpad bug 1064395 in apport (Ubuntu) "Apport should still send reports to daisy.ubuntu.com for binaries in the blacklist" [Undecided,New]
<mitya57> cjwatson: http://anonscm.debian.org/viewvc/pkg-llvm?view=revision&revision=690
<cjwatson> mitya57: Great, thanks
<xnox> smoser: reproduced race, added a check in the post-install for [ "$UPSTART_JOB" = "cloud-config" ] which also simply leaves init.upgraded & reboot-required markers.
<xnox> hmm...
<xnox> and it works correct now.
<pitti> tseliot: bug 1185285
<ubottu> bug 1185285 in fglrx-installer (Ubuntu Saucy) "[saucy] fglrx fails to build against linux 3.9.0 (missing version.h)" [High,Triaged] https://launchpad.net/bugs/1185285
<tseliot> pitti: thanks
<zyga> barry: hey, is PEP396 (which I just read) going anywhere? Is it dead or is it just not-in-progress
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
 * dholbach hugs infinity
<bdmurray> doko: could you have a look at bug 1088771?
<ubottu> bug 1088771 in python-defaults (Ubuntu Precise) "dangling symlink /usr/lib/pkgconfig/python2.pc" [Low,Triaged] https://launchpad.net/bugs/1088771
<doko> bdmurray, yeah, I know. most likely not this week
<bdmurray> doko: okay
<jbicha_> ev: did you see bug 1187981?
<ubottu> bug 1187981 in ubiquity (Ubuntu) "symbol conflicts in libtimezonemap1" [Undecided,New] https://launchpad.net/bugs/1187981
<xnox> jbicha_: that might be me.
<jbicha_> GNOME copied our libtimezonemap into their gnome-control-center source and now Ubuntu's datetime panel won't run with g-c-c 3.8
<xnox> jbicha_: that sounds so backwards, given that g-c-c was the one wanting to use libtimezonemap1 in the first place. As libtimezonemap upstream i'm not sure what I can do.
<Laney> wtf
<jbicha_> on the other hand I don't think any other distro packages libtimezonemap and...is it still being maintained?
<jbicha_> https://git.gnome.org/browse/gnome-control-center/tree/panels/datetime/cc-timezone-map.c
<jbicha_> I'm not sure how many changes GNOME has made to the library to know how easily they could switch to a system lib for 3.10
<xnox> jbicha_: yes it's still being maintained. fedora design team approched us, asking to move timezonemap to git.gnome.org and gnome bugzilla and accept their design changes which contradict our previous usability study.
<jbicha_> xnox: can the library support both GNOME's design and Ubuntu's?
<xnox> jbicha_: but none of their proposals seemed to bring any real benefit to libtimezonemap.
<xnox> jbicha_: sure it can, but I only saw mockups from fedora and no code / patches was submitted.
<jbicha_> (by the way there's only 2 rdepends, indicator-datetime & ubiquity)
<jbicha_> xnox: I think I linked to GNOME's code ;)
<xnox> jbicha_: please take it up with g-c-c upstream, that if they decide to fork something maybe it could be submitted as a patch. And also if they do fork a library, they should be renaming the symbols.....
<xnox> jbicha_: sure, it's a link to code =) not patches I can readily apply. I'll diff it to see what has changed.
<jbicha_> https://launchpad.net/libtimezonemap says Obsolete project, where's the current code?
<cjwatson> jibel: Do I understand it correctly that 'adt-britney request' only generates requests for direct reverse-dependencies?
<cjwatson> IOW if you change python2.7 it won't generate requests for things that depend only on python
<jbicha_> xnox: is their current code for libtimezonemap?
<xnox> jbicha_: gtk+3 is here https://launchpad.net/timezonemap
<jbicha_> xnox: ok, you can follow up at https://bugzilla.gnome.org/702194
<ubottu> Gnome bug 702194 in Date and Time "forked libtimezonemap breaks Ubuntu's indicator-datetime" [Major,Unconfirmed]
<seb128> xnox, jbicha_: are we sure they forked the lib?
<jbicha_> yes the copyright header is still there (that's why I pinged ev first)
<seb128> xnox, jbicha_: it seems like they didn't really touch that in years, our lib is based on a copy of their code rather, it just started breaking because they are doing static linking of the panels
<xnox> seb128: now that sounds closer to being true.
<xnox> seb128: i was merely TIL in ubuntu.
<xnox> ev / cjwatson  should know the history
<seb128> xnox, well, looking at the copyright I guess ev started from the Intel code in g-c-c
<seb128> our version evolved
<jbicha_> seb128: it looks like maybe GNOME forked it from Ubiquity back in 2010
<seb128> oh, right
<seb128> the first import has " * Portions from Ubiquity, Copyright (C) 2009 Canonical Ltd."
<jbicha_> and it wasn't really a separate library in Ubuntu until 2011?
<seb128> well anyway it would be better if g-c-c could use the system lib
<Laney> look at README in https://bazaar.launchpad.net/~timezonemap-team/timezonemap/trunk/revision/1 ;-)
<Laney> looks like it has quite a twisty history
<ev> yeah, we were there first
<cjwatson> ubiquity's map originally came from evolution-data-server and I think that was by way of something else, but it wasn't intended as a library when I did that; I think ev was the one to clean it up (by this point it had had very substantial work done on it) and turn it into a library
<cjwatson> it was a descendant of the original EDS/whatever-it-was version but wasn't really the same code at all by that point
<Laney> sounds like they've converged a bit now anyway
<cjwatson> sorry, not EDS, it was from evolution via gnome-system-tools
<cjwatson> It was in a src/cut-and-paste/ directory in at least one of those :-)
<cjwatson> jibel: Hm.  Also, seems to have an idiosyncratic definition of dependencies.  get_package_info for upstart seems to return systemd-services (upstart Conflicts with that) but not libjson0 (which upstart Depends on).
<mwhudson> er
<mwhudson> sanity check
<mwhudson> it's normal for optimized code for armhf in ubuntu to not be compiled with frame pointers, right?
<lifeless> mwhudson: -fomit-frame-pointer; I assume yes.
#ubuntu-devel 2013-06-14
<bdmurray> where can I find somebody to talk to about developing a unity webapp?
<pitti> Good morning
<JackYu> morning:)
<dholbach> good morning
<jibel> cjwatson, correct 'request' generates requests for direct reverse-dependencies. We could generate requests for deeper levels of dependencies, that'd trigger tests more often.
<jibel> cjwatson, I'll check the upstart case
<doko> seb128, Riddell, et al: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130614-saucy.html
<doko> pitti, ^^^postgres ftbfs
<seb128> doko, hey, thanks, is main done or is that build in progress list?
<doko> in progress, now runs alphabetically
<seb128> ok
<seb128> sil2100, ^ compiz seems to be unhappy with boost in saucy
<pitti> doko: ack, will care about this
<seb128> doko, are all those gnome- only ftbfsing on armhf? or is that just that armhf is further down the build list? (if it is why e.g icon is built on i386 if the builders go in order?)
<sil2100> seb128: uuh
<wgrant> icon's urgency=medium
<wgrant> That's probably why
<seb128> oh, ok, so I guess the others one are just not tried on i386/amd64 then
<seb128> wgrant, thanks
<Laney> xnox: ^? emacs is on there ;-)
<seb128> doko, can you retry gnome-contacts?
<doko> seb128, armhf buildds are faster
<seb128> doko, https://launchpadlibrarian.net/142371643/buildlog_ubuntu-saucy-armhf.gnome-contacts_3.8.2-0ubuntu2_FAILEDTOBUILD.txt.gz
<seb128> "Setting up python2.7 (2.7.5-5ubuntu1) ...
<seb128>   File "/usr/lib/python2.7/cookielib.py", line 483
<seb128>     HÂ¨Â°m            if k == "expires":
<seb128>      ^
<seb128> SyntaxError: invalid syntax"
<seb128>  
<seb128> doko, I guess it's a builder issue
<doko> done
<seb128> thanks
<seb128> shrug
<seb128> how come we demoted automake1.11 when it still has stuff in main build-depending on it?
<seb128> don't we have a check or a rules to fix rdepends before demoting?
<pitti> that should be called component-mismatches.txt ?
<seb128> pitti, it's not showing on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt though
<seb128> pitti, but https://launchpadlibrarian.net/142354253/buildlog_ubuntu-saucy-i386.libgadu_1%3A1.11.2-1_MANUALDEPWAIT.txt.gz
<Laney> does c-m know about provides?
<cjwatson> insofar as germinate does
<seb128> Laney, is anything in main that provides automake1.11? or do you ask for a different reason? and if something does shouldn't the build just work rather than depwait?
<cjwatson> automake was a bit of a special case though because Debian took a while to provide the automake1.11 package after uploading 1.13
<cjwatson> And I think the new automake landed *before* that libgadu was changed to depend on 1.11
<cjwatson> So neither c-m nor britney would have been able to know about it
<cjwatson> In fact, even Debian doesn't have an automake1.11 yet
<seb128> is component-mismatch relying on catching changes are a right time? (e.g not looking to the current archive state)?
<cjwatson> None of this is component-mismatches' fault at all
<cjwatson> libgadu has just started build-depending on something that doesn't exist yet
<seb128> http://packages.qa.debian.org/a/automake1.11.html
<seb128> in fact it was recently removed
<cjwatson> That's source.
<seb128> oh
<cjwatson> The automake1.11 source package only built an automake binary, now superseded by automake1.13 source
<cjwatson> Eric said he was going to upload a compat source, but apparently hasn't (yet?)
<seb128> well that version of libgadu is in debian stable and built in ubuntu
<seb128> it's year old
<cjwatson> Ah, that's because the old automake provided automake1.11
<cjwatson> But migration doesn't check build-depends
<seb128> well, in any case I will just change it to use automake non versionned
<seb128> I was more puzzled at why that was happening
<cjwatson> That's probably the right answer; if it fails with 1.13 and is intractable to fix, switch it to automake1.10
<seb128> cjwatson, thanks for the explanations
<StevenK> Version numbers directly in source package names makes me sad. But automaken is all kinds of special.
<cjwatson> Which is probably good enough for most purposes
<pitti> seb128: note that automake 1.13 changes quite some things, so maybe that explicit 1.11 dep was deliberate?
<cjwatson> StevenK: Mostly it isn't any more - it's legacy attitudes
<seb128> pitti, I will try automake1.10
<cjwatson> IME automake1.13 is only really an issue (not counting things that are trivial to fix up) if you're relying on the old serial test harness
<StevenK> cjwatson: If both source and binary change, it can lead to fun migrations. But I said, automake is special, and switching versions may make your package go boom.
<cjwatson> Right, just saying, that's a lot less common than it used to be with old automake
<cjwatson> Even the big changes in 1.13 only managed to cause problems for one of my packages
<pitti> cjwatson: or if your package uses gtk-doc, or VALAFLAGS, or forgot AM_PROG_AR
<pitti> I have some commits in umockdev to make it work with 1.13
<cjwatson> AM_PROG_AR is one of the trivial things
<cjwatson> I wasn't counting that because it's so easy to fix up
<cjwatson> These days I'm fairly strongly of the opinion that the net best answer is to b-d on dh-autoreconf, use that, and fix things up for newest automake where necessary; just because that frees you of having to patch generated files
<cjwatson> But it does rely on the maintainer being awake :)
<xnox> I'd be ok with parallel test harness (it is quicker), if dh_auto_test would somehow sort and echo the tests logs into the buildlog. Often there is useful and/or non-fatal output that can be relevant.
<pitti> yeah, that's my main gripe with it
<pitti> it spits out "3 failures", and nothing else, which is ridiculously unhelpful
<pitti> so in every package you then had to go ahead and find and cat the test logs of failures -- a test runner just ought to do that by default
<xnox> pitti: just check the relevant.log file, oh wait the buildd has deleted that already =)
<pitti> xnox: but even locally, if I do "make check", it's an annoying extra step
<cjwatson> xnox: I think Automake itself should do that on failures, not dh_auto_test.  Could you ask upstream about that?
<cjwatson> (If it's not already a FAQ somewhere ...)
<xnox> cjwatson: I would want that to happen on success as well. But yeah, upstream should provide a facility to do so (display logs) and/or provide relevant targets to achieve that.
<tvoss> cjwatson, ping
<cjwatson> Variable to choose whether you want it on success, perhaps.  I wouldn't normally
<cjwatson> tvoss: No need to ping when I'm already talking
<cjwatson> I'm clearly here :)
<pitti> cjwatson: +1 (on being silent on success)
<tvoss> cjwatson, fair point :) quick one: do we have NITZ support, yet?
<cjwatson> What is NITZ?
<cjwatson> http://en.wikipedia.org/wiki/NITZ ?
<cjwatson> First I've heard of it
<tvoss> cjwatson, let's discuss in #ubuntu-touch, sorry for the noise
<cjwatson> jibel: Sorry, apparently I hadn't had enough coffee when I was looking at adt-britney's behaviour with upstart; I was looking at the dependencies from the previous package in the loop instead ...
<cjwatson> So if you're scratching your head over that, you can stop :-)
 * xnox now knows that NITZ is the thing that gets my time wrong in Latvia
<jibel> cjwatson, thanks, I'm at my 3rd cup of coffee to find where the error was. Enough caffeine for today :)
<jibel> meanwhile, I'm adding support for an arbitrary level of reverse dependencies.
<cjwatson> jibel: Does http://paste.ubuntu.com/5764067/ look right to you?  Without that, is_newer_dependency never finds anything since self.depends hasn't been set
<seb128> hum, some other automake1.11 depwaits: jack-audio-connection-kit jbig2dec ijs
<xnox> ok about optional on success. E.g. procenv package want to display its output even on success, cause it's more or less the sole purpose of the package. I was more thinking along the lines of "how do I check that particular test did run, and which branch if it's conditional" in case of upstart it only has 17 test binaries, but for test_conf the output can be "no inotify available skipping half of test_conf.c"
<cjwatson> xnox: I get the impression that the preferred way to handle the latter in current automake is to use TAP
<jibel> cjwatson, with that change it would compare the version from the request file to the latest version in the archive. What we want is compare the version in the request file to the last version tested (i.e version in the status file)
<jibel> I think is_newer_dependency should return True when self.depends is empty, that'd mean this is a new package.
<jibel> We could even completely skip the version dependency check if the package has never been tested
<jibel> cjwatson, do you agree with this?
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity, seb128
<shadeslayer> ogra_: stgraber android-tools are broken
<shadeslayer> on saucy
<ogra_> ?
<ogra_> whats broken
<shadeslayer> the upstart script to start adbd
<ogra_> works fine here
<shadeslayer> http://paste.kde.org/773486/
<ogra_> oh, thats a packaging error i think
 * ogra_ checks
<ogra_> shadeslayer, you are in a chroot i assume ?
<shadeslayer> ogra_: nope
<shadeslayer> saucy install on my laptop
<xnox> ogra_: i can fix it.
<ogra_> shadeslayer, ugh, you *never ever* want to install that package on a non android device
<shadeslayer> oh?
<ogra_> android-tools-adbd is the daemon
<ogra_> needs kernel support
<shadeslayer> maje it unavailable on x86 then?
<shadeslayer> *make
<ogra_> why ?
<ogra_> if we ever support x86 android devices we want to be able to use it
<xnox> shadeslayer: android is available on x86, despite _us_ not making an x86 android images yet.
<shadeslayer> oh good point
<xnox> ogra_: i guess, it should just not start gracefully.
<ogra_> that apt-get install is pretty blindly just installing everything
<ogra_> xnox, yeah, dh_installinit --no-start is surely needed
<ogra_> and probably a more verbose description ... i dont think it says that  you need android kernel support
<xnox> ogra_: http://paste.ubuntu.com/5764221/ ?
<ogra_> shadeslayer, note that there will soon be more packages prefixed with android- that will ship actual bionic based binaries
<shadeslayer> ogra_: ack, will keep that in mind
<ogra_> xnox, yeah, looks good
<ogra_> we should still have --no-start though ... in case you roll a rootfs on an Ubuntu phone/tablet
<ogra_> (or check if we are running inside a chroot or some such)
<ogra_> xnox, btw, while i look at that job, do you know a way to have the pre-start script run as root but have adbd starting as an unprivileged user ?
<ogra_> using setuid also makes pre-start run as that user
<xnox> ogra_: can I just pretend that people that "roll a rootfs on an Ubuntu phone/tablet" or run "inside a chroot or some such" can figure out what they need to run where & properly use .override and/or not start any daemons =_
<ogra_> well, we could tell them if they complain for sure :)
<ogra_> i agree its a corner case
<xnox> ogra_: often requested feature. atm setuid is for everything. One can use two jobs adbd-setup and adbd. Do you think adbd should be allowed to set those variables unconditionally? in that case next upstart has apparmor support and one could allow non-priviledged process write into those files (unless my apparmor understanding is horribly wrong)
<ogra_> xnox, well, i'm not sure yet how we want adbd to be used at all ...  it would theoretically be good to have it start as nonprivileged user and if you call adb root on the host PC have it switch to root ... but i'm not sure if thats possible at all in our setup
<ogra_> i'm not sure if we will keep adbd in a final image ...
 * jdstrand is lacking context, but apparmor can't be used to elevate privileges beyond what DAC would allow
<ogra_> if we do it would be good to mimic android behavior so exiting documentation works for us as well
<xnox> jdstrand: ack, thanks.
<ogra_> the bit i fear is that this works only  for a certain system user with a certain hardcoded PID (android uses such a scheme all over the place)
<ogra_> (usually the kernel has such stuff hardcoded)
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity, jdstrand, seb128
<xnox> ogra_: http://paste.ubuntu.com/5764247/
<xnox> ogra_: but, if you want "adb root" to work that means adbd will have root/sudo privileges. In that case you can simply do "echo 0 | sudo tee /sys/class/.../enable >/dev/null" and use setuid/setgid =)
<ogra_> xnox, yeah, well, that patch would also need user creation and i fear the kernel has a PID or GID hardcoded for accessing that sysfs node
<ogra_> so the user creation would have to force a UID ...
<seb128> jdstrand, hey, what items of the queue are you looking at? (just to avoid conflicts)
<ogra_> http://android-dls.com/wiki/index.php?title=Android_UIDs_and_GIDs
<seb128> jdstrand, I'm doing the qt4x-11 one atm
<ogra_> seems to actually be 1011
<jdstrand> I am planning on looking at 'security' ones first, then there is an iptables merge that will be added to the list shortly
<seb128> jdstrand, ok, no conflict then, thanks ;-)
<ogra_> hmm, touch there is also 2000 (shell)
<ogra_> *though
<jdstrand> seb128: not atm, no :)
<jdstrand> but if I move on I'll be sure to coordinate
<seb128> jdstrand, thanks
<shadeslayer> ogra_: just to make sure I have the right scripts, this is the live-build script used by the ubuntu-touch images for saucy right? https://bazaar.launchpad.net/~phablet-team/touch-preview-images/ubuntu-build-phablet-saucy/view/head:/configure
<ogra_> this is the jenkins live build script, right
<shadeslayer> awesome
<ogra_> (will be dropped soon)
<shadeslayer> oh
<shadeslayer> newer script?
<ogra_> the ones we use for the official images (not called -preview) are in lvecd-rootfs
<shadeslayer> I see
<ogra_> (note that the hack scripts in the ubuntu-touch subfolder will all go away as well)
<ogra_> xnox, want to upload the first fix ? i thing the user/privilege handling is a thing for later, once we know what we want
<ogra_> s/thing/think/
<xnox> ogra_: ack.
<ogra_> thx
<jdstrand> stgraber: hi! around? if so, can you change the status of https://code.launchpad.net/~sdeziel/ubuntu/raring/openvpn/fix-for-lp1184223/+merge/165760 to 'Rejected'
<jdstrand> stgraber: and https://code.launchpad.net/~sdeziel/ubuntu/raring/mysql-5.5/fix-for-lp1185573/+merge/166379 as Merged?
<pitti> jdstrand: can do
<jdstrand> pitti: ah, thanks! :)
<jdstrand> stgraber: nm
<cjwatson> jibel: Ah, yes, I think that makes more sense - the thing I was observing was that adt-britney was never actually scheduling any requests.  It makes sense that adt-britney should be the thing that keeps track of what's last been tested
<seb128> pitti, can you mark https://code.launchpad.net/~jm-leddy/ubuntu/precise/x11proto-core/micmute/+merge/167620 as merged?
<seb128> pitti, can you mark https://code.launchpad.net/~le-businessman/ubuntu/raring/libcommoncpp2/fix-for-1176058/+merge/166377 work in progress as well?
<pitti> seb128: bien sÃ»r
<pitti> seb128: let me consider it :)
<pitti> seb128: hm, hang on, you can't set to WIP? that sounds wrong
<pitti> (done)
<seb128> pitti, I can't edit MRs targetted to stable series
<seb128> pitti, danke
<pitti> oh, for stables
<seb128> pitti, that one is for raring
<jdstrand> seb128: fyi, I plan to look at https://code.launchpad.net/~le-businessman/ubuntu/raring/libcommoncpp2/fix-for-1176058/+merge/166377 later
<seb128> jdstrand, ok
<jibel> cjwatson, r191 fixes a bug when a request file is provided. It processed all the packages with a testsuite not only those in the request file leading to a very weird list of dependencies in the generated request file.
<cjwatson> jibel: Thanks
<pitti> tseliot: FYI, I'm uploading a new u-d-common; it'll depwait, needs someone to review bug 1190926 first
<ubottu> bug 1190926 in umockdev (Ubuntu) "[MIR] umockdev" [Undecided,New] https://launchpad.net/bugs/1190926
<pitti> tseliot: this fixes the test suite again
<tseliot> pitti: ah, good, I'll have a look at the code, more out of curiosity as I'm not familiar with umockdev
<pitti> tseliot: argh, forgot to port debian/tests/, will do that now
<seb128> pitti, could you put https://code.launchpad.net/~pataquets/ubuntu/precise/avidemux/avidemux-bug-1041144/+merge/121341 as work in progress?
<arges> jdstrand: hi. Just got your email. Thanks for the feedback, revewing the debdiff. Did you want me to run the QA tests on it now?
<pitti> seb128: s4re
<pitti> seb128: d6ne
<seb128> pitti, th1nks
<pitti> argh, that was numlock
<pitti> not a feeble attempt at l33tsp34k :)
<pitti> TGIF
<seb128> lol
<seb128> I was not sure, it's friday after all :p
<seb128> pitti, https://code.launchpad.net/~jm-leddy/ubuntu/precise/x11proto-core/micmute/+merge/167620 as merged as well please? ;-)
<pitti> seb128: done
<seb128> pitti, danke
<jdstrand> arges: feel free to do so for experience sake, but I already did it all and uploaded :)
<jdstrand> arges: and thank *you* for the merge :)
<arges> jdstrand: no problem, thanks for the review! i'll look through the QA info since I do want to learn it.
<jdstrand> arges: I suggest reading scripts/README
<jdstrand> arges: (for the qrt bits)
<arges> jdstrand: will do.
<jdstrand> https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment explains how to setup sbuild (which is useful in and of itself) but also umt, which is the tool the security team (and others) use for building packages
<arges> ok I have a set of schroots for each series/arch on my machine, how does umt compare to just using sbuild?
<jdstrand> https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Using_umt
<jdstrand> https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Typical_package_build_procedure
<jdstrand> it just makes automatable things automated, performs various checks and allows you to do things like compare build logs and binaries easily
<jibel> pitti, WRT umockdev package test, when run from a source tree, adt-run builds the package in $TMPDIR/ubtree0-ubtree/real-tree/ but when run from a dsc it builds the package in $TMPDIR/dsc0-build/umockdev-0.2.6
<pitti> jibel: ooh - that's why it fails in jenkins
<pitti> jibel: thanks for pointing out
<arges> jdstrand: cool thanks
<jibel> pitti, IMO adt-run should cd to real-tree when build-needed is set and package is built from source
<jdstrand> np
<pitti> jibel: I agree
<jibel> pitti, so if you change your hack to [ -d real-tree ] && cd real-tree
<jibel> pitti, it should work in both cases
<kenvandine> mardy, you mentioned you were going to review seb128's translations branch
<kenvandine> mardy, are you working on that or do you want me to do it?
<mardy> kenvandine: oops
<mardy> kenvandine: please do it :-)
<kenvandine> will do
<kenvandine> mardy, i plan to do the same for ubuntu-system-settings-online-accounts too
<seb128> kenvandine, mardy: whoever does win a free beer for next time we see each others, that made me waste quite some time since yesterday, I've 4 stacked branches and I screwed a few times keeping them in sync
<mardy> kenvandine: makes sense
<kenvandine> seb128, yay... i win :)
<seb128> kenvandine, ;-)
<mardy> seb128: I don't drink beer, that's why I let Ken win ;-)
<kenvandine> haha :)
<kenvandine> mardy, such a nice guy!
<seb128> mardy, damn, what drink should I put on the table next time? ;-)
<mardy> seb128: I'm not fond of any drink in particular. My weakness is ice-cream :-)
<seb128> oh, that works too!
<pitti> ooooh, ice cream!
<pitti> c'est toujours l'heure du glace !
<seb128> larsu swapped the beer he owned me for an icecream last time
<seb128> that was nice as well
<seb128> pitti, en effet ;-)
<pitti> seb128: pas de glace Ã  train ici :(
<pitti> "dans le train"
<seb128> pitti, ton train s'arrÃªte Ã  quelle heure ? peut Ãªtre une glace aprÃ¨s le voyage...
<pitti> seb128: je vais arriver Ã  16:30 -- beaucoup de temps pour de glace :)
<seb128> pitti, enjoy ;-)
<pitti> seb128: I will :)
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity, jdstrand
<seb128> jdstrand, sponsoring queue is all yours ;-)
<jdstrand> thanks!
<chiluk>  infinity, jdstrand can I get some love on the precise unity upload?  I'm eagerly awaiting a fix for https://bugs.launchpad.net/compiz/+bug/1083186
<ubottu> Launchpad bug 1083186 in unity (Ubuntu Quantal) "icaclient windows "dancing" when decorated" [Undecided,New]
<chiluk> it looks like compiz changes might also be needed for that unity sru.
 * jdstrand defers to a member of the sru team
<jdstrand> chiluk: I could help get something uploaded, but a member of the sru team needs to approve it
<chiluk> it's already in the upload queue
<Laney> https://launchpadlibrarian.net/142376050/buildlog_ubuntu-saucy-amd64.db5.3_5.3.21-1ubuntu1_FAILEDTOBUILD.txt.gz â what is going on here?
 * jdstrand nods
<chiluk> https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
<chiluk> just unapproved.
<jdstrand> chiluk: yes, you need a member of ubuntu-sru. you happened to ping one a moment ago :)
<Laney> The linker line looks correct... is it to do with the symbols being versioned?
<Laney> I tried with gold and it built.
<chiluk> really?  I thought once it got uploaded it was already approved by the sru team.
<Laney> doko: ^?
<jdstrand> chiluk: no, people can just upload whenever they want, but it goes into the unapproved queue. at that point a member of the sru team can review it and approve it
<chiluk> alright, thanks for the clarification.  I'm still new to this process.
<jdstrand> chiluk: of course, for them to notice it, the bug needs to be in a certain state. this is detailed in https://wiki.ubuntu.com/StableReleaseUpdates
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<GyrosGeier> hi
<jbicha> seb128: simplejson is in depwait, can you upload this instead? http://paste.ubuntu.com/5764930/
<GyrosGeier> I have a Debian package that should have different Build-Depends in Ubuntu
<GyrosGeier> (Ubuntu has Mesa 9, Debian has Mesa 8, so EGL support on Debian does not work, hence a Build-Conflict to avoid the package finding it)
<GyrosGeier> what is the sanest way to handle that?
<bdmurray> Who could I ask about how to test a unity-webapp?
<seb128> jbicha, will do later, I've to run for an hour or so, your diff has a conflict in debian/control and then I can't get debuild -S to work
<seb128> 'build/scripts-3.3' does not exist -- can't clean it
<seb128> /bin/sh: 1: python3.3-dbg: not found
<seb128> E: pybuild:245: clean: plugin distutils failed with: exit code=127: python3.3-dbg setup.py clean
<seb128> if anybody else wants to sponsor the fix feel free
<seb128> otherwise I will have a look when I'm back
<nicolacorti> Hi to everyone
<JackYu> hi
<nicolacorti> Just one question, i'm looking for some information on PyGTK but i think that http://www.pygtk.org/ is down
<jbicha> seb128: yeah I don't know what's up with that, I had to install python2.7-dbg and python3.3-dbg outside mychroot for the clean step to work (and python-distutils-extra & sphinx-common)
<cjwatson> GyrosGeier: Since it's in the .dsc, there's no real way to handle that dynamically if the package is precisely in sync; there'll have to be an Ubuntu-specific patch to the package which gets merged as you upload new versions to Debian
<cjwatson> Assuming there's definitely no way to express the Build-{Depends,Conflicts} in a way that works on both
<doko> Laney, link the library with -ldl
<doko> afk now
<Laney> it is
<doko> no, that's the executable
<Laney> hmm
<GyrosGeier> cjwatson, if mesa 9 is available, use mesa 9 and libgbm 9; otherwise, conflict with libgbm
<GyrosGeier> cjwatson, it could be done with | constructs, but I'm not sure whether buildds will stumble over that
<cjwatson> GyrosGeier: One thing that's useful to know is that Debian's buildds (AFAIK) only ever look at the first entry in an |-list, while Ubuntu's buildds will attempt alternatives
<pitti> cjwatson: btw, haskell-yasod is failing again; does "cabal: At least the following dependencies are missing: clientsession ==0.8.*" sound like a missing dependency or are packages out of sync?
<ScottK> GyrosGeier: You could use a versioned conflicts perhaps.
<cjwatson> It's sometimes possible to construct something that works both ways using that trick
<GyrosGeier> hmm
 * GyrosGeier tries
<tvoss> seb128, ping
<cjwatson> pitti: Looking
<pitti> cjwatson: https://jenkins.qa.ubuntu.com/job/saucy-adt-haskell-yesod/11/ARCH=amd64,label=adt/ FYI
<cjwatson> pitti: I think it's fixed upstream - I'll see if it's possible to upgrade
<cjwatson> pitti: Yep, there was an upstream release that fixes just this and doesn't pull in other major stuff.  I'll package that in Debian
<pitti> nice, thanks
<pitti> I was just wondering because it succeeded a few days ago
<cjwatson> Yeah, we had to upgrade haskell-clientsession in the interim
<cjwatson> And the scaffolding stuff in haskell-yesod is unusual enough that it isn't caught by our scripts that check for coherency
<GyrosGeier> Get: 87 http://ftp.ubuntu.com/ubuntu/ raring/main llvm-3.2-runtime amd64 3.2-2ubuntu5 [30.7 kB]
<GyrosGeier> Get: 88 http://ftp.ubuntu.com/ubuntu/ raring/universe llvm-runtime amd64 1:3.2-16~exp1 [2388 B]
<GyrosGeier> that smells fishy
<infinity> GyrosGeier: What's fishy about it?
<GyrosGeier> infinity, parts of llvm in main, parts in universe, and some with epoch (as in Debian), some without
<infinity> GyrosGeier: Parts in main, parts in universe, is par for the course.
<infinity> GyrosGeier: The epoch-and-not is because those come from two different source packages.
<GyrosGeier> hmm
<infinity> GyrosGeier: The bits that are in main are the bare minimum for the other things in main that require certain llvm bits.  We don't even pretend to support the entire clang/llvm toolchain.
<GyrosGeier> ah okay
 * GyrosGeier is going to have fun watching beignet burn then
<chiluk> infinity what needs to happen in order to get the latest precise unity upload accepted?  I see you are part of the SRU team.  The bug I care about is https://bugs.launchpad.net/compiz/+bug/1083186
<ubottu> Launchpad bug 1083186 in unity (Ubuntu Quantal) "icaclient windows "dancing" when decorated" [Undecided,New]
<chiluk> but the unity team bundles bugs together into sru releases https://launchpad.net/unity/+milestone/5.20.0
<infinity> chiluk: It just needs a queue review.  We'll get there.  I wasted a bunch of time reviewing raring unity SRUs yesterday that LP then rejected, so once I get over that grumpiness, I'll hit up the precise ones, which shouldn't suffer the same problems. :P
<chiluk> awesome.
<chiluk> thanks ...
<chiluk> ah you probably approved the fix to mesa yesterday, that I finally have... thanks for that too.. It was getting annoying not being able to use the dash or alt-tab
<barry> xnox: hi, are you around?  you were the last one to upload emacs24.  wondering if you had any problems building it locally? both the saucy version and my branch with a small fix fail
<GyrosGeier> okay
<GyrosGeier> evil hack, but works
<GyrosGeier> (until doko uploads clang with an epoch)
 * GyrosGeier wonders if there is or should be a package that can be used as a build-dep that takes little space and can never be installed on Ubuntu
<sergiusens> xnox: hey, just learned that you will package android... my question is what should I apt-get to get the x-toolchain?
<xnox> sergiusens: you can use the very dangerous ppa:ubuntu-toolchain-r/test ppa. I would recommend to create a chroot/schroot and enable that ppa inside there. And then you can get the gcc-arm-linux-androideabi from there.
<xnox> sergiusens: be careful with that ppa, as it can have highly experimental / test toolchains which are not supported in any way or shape =)
<xnox> it's doko's playground.
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * infinity coughs.
<sergiusens> xnox: thanks! Well I wanted to start checking it out to build without the packaging in the middle so you had an easier time with whatever errors may show up
<seb128> tvoss, hey, pong (was out for some exercice)
<tvoss> seb128, no worries, all good
<seb128> tvoss, good ;-)
<xnox> sergiusens: well, we don't know for sure if that cross-compiler builds anything sane yet =))))))
<sergiusens> xnox: well, I'll be finding that out ;-)
<hallyn_> psivaa: arges: Bit of a long shot, but I'm wondering whether the recent precise qemu-kvm precise SRU is causing the test failures in ceph and lxc
<hallyn_> psivaa: I don't have admin rights on aldebaran, could we build a qemu-kvm package on it with the lastest change reversed, and see if tests pass?
<hallyn_> arges: maybe i was wrong, and reversing that change *is* urgent...
<arges> hallyn_: yea would be good to see if that's causing those failures
<hallyn_> that's bad bad bad ifso
<hallyn_> oh, no.
<hallyn_> arges: psivaa: never mind, it's on the previous version of qemu
<hallyn_> never mind, ignore me, thanks
<arges> what kind of failure is it? corruption?
<psivaa> hallyn_: ack :)
<hallyn_> arges: seems like an inexplicable hang during testcases
<hallyn_> could be python bug?
<hallyn_>  2476 root      20   0 21232  11m  960 R  99.5  2.3 526:48.59 python
<hallyn_> except when i try what it's doing (subprocess.cmd of debootstrap) it works fine...
<hallyn_> it's just non-stop doing selects
<rsalveti> slangasek: hey, would you mind approving https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-phablet-ubuntufication ?
<rsalveti> don't think we have anyone in our team that's capable of approving blueprints for ubuntu
<slangasek> rsalveti: done
<rsalveti> slangasek: thanks
<manish> ev: ping. please check your mail (@ubuntu.com one)
<GyrosGeier> hi
<mterry> pitti, why does umockdev use dh_auto_test || true?
<mterry> pitti, ah yes, because it uses dep8 for the tests
<slangasek> mterry: how does that explain?  surely it should still be wired up in such a way that dh_auto_test can pass successfully?
<mterry> slangasek, well, it's not an explanation, but I believe I remember talking to him about this before.  There are tests that require installation, which are used in dep8.  During build, he runs tests anyway, but doesn't care about results.  It would be nicer if he just selectively ran some of the tests during build, but...
<slangasek> right, agreed :)
<Laney> I bet it's rather because the tests don't all pass on ppc ;-)
<Laney> where's the script to synthesise the .pc directory?
<GyrosGeier> does the import from Debian to universe work automatically, or does someone have to prod something?
<jtaylor> GyrosGeier: its automatic for apckages without ubuntu diff
<GyrosGeier> it has a diff, which no longer applies because I've tricked the control file to DTRT on Ubuntu
<GyrosGeier> i.e. the diff is unneeded now
<jtaylor> use requestsync
<jtaylor> and describe why the delta can be dropped in the bug report it will create
<jtaylor> its in the ubuntu-dev-tools package
<GyrosGeier> mm
<GyrosGeier> I'm on Debian
<GyrosGeier> the only Ubuntu system I have is my pbuilder
<GyrosGeier> The package in question is beignet, if anyone wants to do me a small favour :)
<jtaylor> it works from debian
<jtaylor> but you do need a lp account
 * GyrosGeier installs
<GyrosGeier> ah excellent
<GyrosGeier> thanks
 * GyrosGeier goes out, after all it is Friday
#ubuntu-devel 2013-06-15
<bkerensa> usb-creator is broken seven ways from sunday
<adam_g_> anyone alive familiar with the dep8 testing suite @ lp:auto-package-testing?
<ScottK> adam_g_: yolanda is.
<mitya57> Who broke the builders? Here is a debdiff between pyside 1.1.2-3ubuntu1 and 1.1.2-4 (http://launchpadlibrarian.net/142485559/pyside_1.1.2-3ubuntu1_1.1.2-4.diff.gz)
<mitya57> ... and the latter ftbfs on both i386 and amd64 while the former built fine...
<jtaylor> am I blind or is there no error message?
<mitya57> there is no error message :)
<mitya57> and the build was done up to 100%
<cjwatson> mitya57: make[4]: *** No rule to make target `/usr/lib/i386-linux-gnu/libQtWebKit.so', needed by `PySide/QtWebKit.so'.  Stop.
<cjwatson> (trick: look at the make level that fails near the end, namely make[2], then search back for successively increasing make levels until you find the one with the actual error message nearly
<cjwatson> *nearby)
<mitya57> cjwatson: oh thanks; but why did the mostly identical version build?
<cjwatson> mitya57: dunno, maybe qtwebkit changed?
<mitya57> oh yes, seb128 sponsored new webkit yesterday
<mitya57> *qtwebkit
<mitya57> libqtwebkit-dev_2.3.1-0ubuntu1_i386.deb does contain /usr/lib/i386-linux-gnu/libQtWebKit.so symlink
 * mitya57 found the issue
<jtaylor> what is it?
<mitya57> hardcoded version in rules
<mitya57> ln -s libQtWebKit.so.4.10.0 debian/libqtwebkit-dev/usr/lib/$(DEB_HOST_MULTIARCH)/libQtWebKit.so
<mitya57> the .so is 4.10.1 in the new version
<infinity> Grr, who retried llvm-toolchain-3.3 on i386? :(
<infinity> Pro tip: if a build is hanging, retrying it over the weekend when no one will be around to kill it is probably silly.
<mitya57> infinity: probably that was a new upload to sid
<mitya57> and it hangs again :(
<infinity> mitya57: It wasn't.  It's already been killed once and someone retried it in the last couple of hours.
<mitya57> infinity: that wasn't me, but kill it anyway if you're able to
<infinity> mitya57: I'm not able, which was the point of my grumpiness.  All the people who have access to log in to buildds tend to take their weekends very seriously.  Oh well. :P
<mitya57> Somebody really needs to fix auto-killing...
<infinity> Yeah, it's on my TODO.
<ricotz> infinity, hi :), jfyi, this linker failure looks like a toolchain problem -- https://launchpadlibrarian.net/142502649/buildlog_ubuntu-saucy-i386.gst-plugins-bad1.0_1.1.1.1%2Bgit20130614.d50625ee-0ubuntu1~13.10~ricotz0_FAILEDTOBUILD.txt.gz
<infinity> ricotz: Why on earth is that using -nostdlib and then trying to guess the right thing to do?
<infinity> ricotz: Anyhow, without looking too closely, I'd give good odds that the -lfoo bits are at the wrong point in the linker command.
<infinity> ricotz: Still, not trusting your compiler or linker, and then manually linking all of crt* -lc, etc, is a bit nuts.
<infinity> ricotz: So, I'd be less inclined to call it a toolchain bug and more inclined to assume it's a misuse of the toolchain.
<ricotz> infinity, thanks for taking a glimpse at it, will point it out to upstream
<infinity> ricotz: If you happen to have a failed local build tree around, try re-running that last link command with "-lstdc++ -lm -lc -lgcc_s" at the end of the command line.
<ricotz> infinity, the amd64 didnt fail which i am have locally too
<ricotz> so a vanilla git build is fine on amd64
<infinity> I'll see if I can reproduce on i386 in a bit.
<ricotz> infinity, thanks!
<infinity> (Probably going to blame crazy toolchain abuse either way, but there's a slim chance it's a gcc/binutils bug)
<infinity> Though, probably not, given that it's whining about stack_chk symbols in libc, and I haven't changed glibc since raring.
#ubuntu-devel 2013-06-16
<Noskcaj> Daviey, ping
<hyperair> hey, in what precedence should libraries be searched in?
<hyperair> https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/1191195 <-- in this bug the reporter has a local /usr/lib/libpng12.so.0 which is getting loaded in place of the legitimate /lib/x86_64-linux-gnu/libpng12.so.0 by mono.
<ubottu> Launchpad bug 1191195 in banshee (Ubuntu) "Cannot launch banshee: Unhandled Exception: System.DllNotFoundException: libgtk-x11-2.0.so.0" [Undecided,Incomplete]
<hyperair> however, ldd seems to resolve to /lib/x86_64-linux-gnu/libpng12.so.0 instead.
<infinity> hyperair: ld.so will resolve in whatever order they landed in the cache, order isn't guaranteed except for hwcap directories.  If someone puts a library on the system path, they should expect it to be used by everything, one can't magically decide to have half their applications use one and the other half another.
<infinity> hyperair: (If the user wants to run some applications with a custom version of a system lib, he should either put it in the directory of the application linking it, use an LD_* fudge, or use an rpath and a non-system lib dir)
<hyperair> infinity: thanks
<hyperair> infinity: i wasn't sure how to explain it to him.
<mardy> any cmake users here?
<hyperair> i used to use cmake, then i saw the light and went back to autotools
<OdyX> wrong light then
<lfaraone> Can somebody sponsor this sync request for hesiod? It contains a minor security fix among other things, lp #1164044
<ubottu> Launchpad bug 1164044 in hesiod (Ubuntu) "Sync hesiod 3.2.1-2 (main) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/1164044
<infinity> lfaraone: Done.
<lfaraone> infinity: awesome, thanks. achernya_^^
<achernya> yay! Thanks!
#ubuntu-devel 2014-06-09
<xnox> usbmuxd packages synced.
<michagogo> Hi, I don't see a link in the topic regarding policy or rules or guidelines for this channel, so I'm sorry if I shouldn't be repeating this again (last time was 14ish hours ago, I think):
<michagogo>  What needs to happen for bug #1314616 to move forward? How does the process work and get advanced from here?
<ubottu> bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,Confirmed] https://launchpad.net/bugs/1314616
<cjwatson> michagogo: It's already listed on http://reqorts.qa.ubuntu.com/reports/sponsoring/, so there's no need to continue asking - it's in the sponsorship queue
<michagogo> cjwatson: ah, okay -- so it's just a matter of someone in the project getting around to looking at it?
<michagogo> That's all I wanted to know. Thank you!
<cjwatson> michagogo: Right
<cjwatson> It's in the right place AFAICS
<michagogo> cjwatson: awesome, thank you! I just wanted to make sure it wasn't stuck on some action or change or correction or something that Scott or I or someone needed to do
<michagogo> (Or something along those lines)
<mpt> Wellark, hi. When your device is set up as a Wi-Fi hotspot, how easy is it to tell how many devices are connected to it?
<xnox> bdmurray: ev_: is there a definitive way to query whoopsie as to which parameters it's using to derive the unique identifier? E.g. is it using IMEI or MAC address or other serial id?
<ev_> xnox: I don't have the command to hand, but if you point gdbus at the service it will tell you
<rbasak> infinity: so juju-core FTBFS on sagari also, so it's still stuck in -proposed. May I have some help with this, please? As I can't reproduce on a porter, I'm pretty stuck.
<mlankhorst> Laney: feel like trying http://paste.debian.net/104091/ ?
<mlankhorst> you had a >= nvc0 right?
<tseliot> bdmurray: hi, I have two packages associated with some SRUs. Can you help please? nvidia-prime (precise-proposed) [LP: #1326257, LP: #1296020], ubuntu-drivers-common (trusty-proposed) [LP: #1306928, LP: #1296020, LP: #1310023]
<ubottu> Launchpad bug 1326257 in ubuntu-drivers-common (Ubuntu Trusty) "[nvidia-prime] Cannot adjust brightness in guest session and results in black screen while changing the resolution" [High,In progress] https://launchpad.net/bugs/1326257
<ubottu> Launchpad bug 1296020 in ubuntu-drivers-common (Ubuntu Trusty) "[Asus U36JC] Non-existent display detected in both intel driver and nvidia driver (Optimus Laptop) (ubuntu trusty 14.04)" [Critical,In progress] https://launchpad.net/bugs/1296020
<ubottu> Launchpad bug 1306928 in ubuntu-drivers-common (Ubuntu Trusty) "Broadcom STA driver gets autoinstalled on BCM4313, where it's no longer needed" [High,In progress] https://launchpad.net/bugs/1306928
<ubottu> Launchpad bug 1310023 in ubuntu-drivers-common (Ubuntu Trusty) "14.04: Nvidia Prime is unable to switch to the Nvidia card" [High,In progress] https://launchpad.net/bugs/1310023
<Laney> mlankhorst: I dunno what that means
<mlankhorst> Laney: what does glxinfo say in OpenGL renderer string ?
<Laney> mlankhorst: Gallium 0.4 on NVE4
<mlankhorst> ok give that patch a try
<Laney> okey pokey
<Laney> mlankhorst: umm I can't actually start the webbrowser app at all now
<Laney> dunno if that's your fault
<mlankhorst> oh funstuff
<mdeslaur> xnox: could you please comment on the apparmor upstart job in bug #1305108...I have added  few questions to it
<ubottu> bug 1305108 in apparmor (Ubuntu Utopic) "please provide upstart job for apparmor" [High,Triaged] https://launchpad.net/bugs/1305108
<mlankhorst> Laney: can you do a backtrace, see where it hangs? :P
<xnox> mdeslaur: you mean systemd job?! =)
<xnox> </troll>
<Laney> mlankhorst: sec
<Laney> getting oxide debug symbols
<Laney> huge dbg package is huge
<mdeslaur> xnox: at some point yes, but we need this for the phone before rtm
<mlankhorst> Laney: don't need that, just the -dbg symbols from the mesa package i think
<Laney> it has oxide in the bt
<mlankhorst> is the bt usable without oxide?
<Laney> dunno, didn't look, just went to install them
<Laney> give me a second, it's installing now
<mlankhorst> ok
<jdstrand> xnox, mdeslaur: fyi, I just added a few comments too
<Laney> mlankhorst: http://paste.ubuntu.com/7618198/ hope that helps
<mlankhorst> stuck on mtx_lock.. hm
<mlankhorst> oops, missed a pipe_mutex_unlock
<mlankhorst> Laney: http://paste.debian.net/104107/ ?
<Laney> sec
<Laney> mlankhorst: I don't see any difference
<psusi> how do you tell bzr not to fscking unapply quilt patches for me?  it always seems to fsck things up and right now it isn't letting me pull/update because it can't unapply a patch
<ScottK> bzr doesn't apply or unapply patches.
<psusi> ScottK: it does it all the time
<psusi>  bzr update
<psusi> Unapplying quilt patches to prevent spurious conflicts
<cjwatson> That's bzr-builddeb
<psusi> ok, well whatever plugin is doing it, it's making bzr unapply patches
<psusi> and it always seems to muck everything up when it does
<cjwatson> There are various properties like quilt-smart-merge to control it
<psusi> in this case, bzr pull --overwrite is leaving my tree out of date still... update fails beacuse unapplying some patch fails... I can't find a way to just make my tree exactly like the current remote
<psusi> is there somewhere I could read up on that?
<cjwatson> bzr revert; rm -rf .pc; and then http://people.canonical.com/~cjwatson/dpkg-quilt-setup usually does it
<cjwatson> as a "no really"
<psusi> tried revert, and deleting .pc
<cjwatson> /usr/share/doc/bzr-builddeb/user_manual/configuration.html
<psusi> ohh, then push -a eh?  didn't try that
<cjwatson> that script unapplies everything manually and then pushes, to synchronise .pc with the tree state
<psusi> for that matter, why is pull --overwrite leaving the tree out of date?
<cjwatson> the bzr-builddeb docs don't mention 'quilt-smart-merge = False' which may also be useful
<cjwatson> don't recall
<mlankhorst> Laney: bleh, I probably missed another mutex_unlock then :/
<mlankhorst> Laney: is there anything in dmesg?
<Laney> mlankhorst: nope
<mlankhorst> found another one I missed, grr
<Laney> I thought you were able to reproduce this
<mlankhorst> Laney: hm what are you trying? because normal case works for me :P
<Laney> $ webbrowser-app
<Laney> â app hangs
<Laney> I never see its interface
<mlankhorst> definitely works for me, weird
<mlankhorst> oh wait you're on utopic right?
<Laney> yep
<infinity> rbasak: I can try to have a poke at it.  Go isn't my forte.
<rbasak> infinity: thanks! I'm not really sure where to go without being able to reproduce
<rbasak> I'd want identical hardware and kernel and rootfs to start I think.
<cjwatson> maybe it's the page size thing?
<cjwatson> oh, powerpc, not ppc64el, hmm
 * cjwatson falls over himself stepping back again
<infinity> rbasak: So, it reproduces on my machine running a trusty kernel.  That would imply it's not a precise kernel issue.
<rbasak> infinity: can you see if it reproduces in a Trusty chroot? I wondered if had anything to do with toolchain changes in Utopic.
<infinity> Though, curiously, reproduces in a different spot.
<infinity> That's not comforting.
<infinity> rbasak: So, ever attempt on utopic seems to crash in a different spot.  Fun.
<infinity> rbasak: And on trusty, it worked, at least on the first try.
<infinity> rbasak: Also, the debian/rules clean target of this package assumes all UNIX machines are single-user. :P
<infinity> rm -rf pkg bin /tmp/go-build* debian/home
<infinity> rm: cannot remove '/tmp/go-build368800735': Operation not permitted
<rbasak> infinity: so we have some kind of gccgo regression here?
<rbasak> I'll take a look at the /tmp/go-build* thing for next upload
<infinity> rbasak: I'll do a few more trusty test builds to confirm it always works there, then I'm a bit stuck at to why it works in the dirty porter chroot and not my clean sbuild chroot.
<infinity> rbasak: First step might be to try to install all the packages in the porter chroot locally, but I can't see why gccgo-go/gccgo would care about random external packages.
<infinity> rbasak: And yeah, building in /tmp is a very silly thing.  Not sure if that's juju's fault or gccgo-go (inherited from golang).
 * popey wonders who could look at bug 1326707 - the 14.10 live CDs have been broken for a while.
<ubottu> bug 1326707 in ubiquity (Ubuntu) "Ubiquity does't start, hangs in "/usr/lib/ubiquity/bin/ubiquity", line 426, in acquire_lock, test_debconf.stdout.readline()" [Critical,Confirmed] https://launchpad.net/bugs/1326707
<trifort> popey: I can look at it, but I will be slow
<trifort> popey: I am new, but I could spend the rest of the day
<popey> I don't know if it's something an expert in the field would need to look at to be honest.
<trifort> popey: if no one else has time, Iâll spend a while to see what I come up with
<popey> thanks.
<trifort> popey: okay, Iâll see what I find
<tedg> bdmurray, It seems that popey's touch images aren't uploading any crash files.
<tedg> bdmurray, Is there something he should be doing? I thought it was on by default?
<popey> is there a switch I can flip, or indeed look at
<tedg> popey, It should be Settings â Security & Privacy â Diagnostics â App crashes and reports
<bdmurray> popey: grep whoopsie /var/log/syslog and I'll bet there is a No StacktraceAddressSignature message in there
<bdmurray> tedg: the issue is that most of the stacktraces on armhf are corrupt
<tedg> bdmurray, Oh, that's a bit scary, is there a fix?
<bdmurray> tedg: doko is looking into it some and so am I
<popey> tedg: bdmurray i have 4 devices, and on the one I have used most, it has "Diagnostics : Sent" in settings
<bdmurray> tedg: I'm trying to get it sorted it out
<popey> http://paste.ubuntu.com/7620032/ what I see from grepping whoopsie
<bdmurray> Network connection found that may be a paid data plan.
<bdmurray> it only uploads on wifi
<popey> tedg: ^
<tedg> bdmurray, Ah, cool. It'll be interesting to hear what that issue is :-)
<tedg> bdmurray, Is there a way to check what it thinks about the network?
<bdmurray> tedg: more than what I just said?
<tedg> bdmurray, Sorry, didn't realize that was in reference to the log :-)
<bdmurray> tedg: it uses network-manager via dbus see https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/connectivity.c#L91
<bdmurray> ah, okay
<tedg> bdmurray, Oh, wow, you should totally use libnm-glib, it'll make your life easier :-)
<bdmurray> tedg: sure, I'll add that to the list ;-)
<slangasek> wait what
<bdmurray> slangasek: ?
<slangasek> wasn't libnm-glib what we /were/ using?
<slangasek> I thought that was part of the original implementation, and that this was what was causing whoopsie to wake up 20 times a second ;p
<ev> Gnetworkmonitor causes the endless wakeups (on a chatty network)
<ev> tedg: libnm-glib put me in gvariant hell, if memory serves. bzr log should be somewhat informative, but I'm on a phone.
<tedg> Hmm, I'd guess that libnm-glib would take you out of gvariant hell, the code there looks very GVariant-y.
<popey> bdmurray: so do you want me to file a bug or something?
<bdmurray> popey: no, your crash reports aren't being uploaded because you are not on a wifi connection.
<popey> i am â»
<popey> it's incorrectly identified my connection
<tedg> British WiFi, not real WiFi :-)
<popey> Metric Bits.
<popey> wlan0     Link encap:Ethernet  HWaddr 98:d6:f7:62:80:e2   inet addr:192.168.1.110  Bcast:192.168.1.255  Mask:255.255.255.0
<bdmurray> popey: try restarting whoopsie then 'sudo service whoopsie restart'
<popey> Jun  9 22:03:00 ubuntu-phablet whoopsie[31548]: Could not connect to the system bus: Timeout was reached
<popey> (after some restart messages)
<npr> how can i contibute to ubuntu ???
<ev> tedg: hm, not sure why then :)
<popey> npr: http://community.ubuntu.com/contribute/ â»
<tedg> popey, Do you have a 3g data connection as well?
<popey> tedg: i do
<tedg> Perhaps whoopsie is detecting the first, instead of enumerating them.
<npr> how do i finf bugs .....correct them or submit them for evaluation ...
<npr> tried once before but couldnt get started
<bdmurray> I've also run into bug 1320988
<ubottu> bug 1320988 in whoopsie (Ubuntu) "whoopsie did not become on-line after connecting to wifi" [High,New] https://launchpad.net/bugs/1320988
<bdmurray> which is why I suggested restaring whoopsie
<npr> can anyone suugest how to get inolved ....
<trifort> npr: be patient
<trifort> npr: go here http://qa.ubuntuwire.com/ftbfs/
<trifort> mpr: see if you can make a red package not red
<trifort> npr: http://cdimage.ubuntu.com/ is where you get the daily image
<Noskcaj> npr, Or if there is any package you want to work on specifically, find it and fix bugs
<npr> trifort : whats difference betweend usual iso and daily image
<popey> npr: also, look for bitesize tagged bugs and see if you can reproduce and/or fix https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
<npr> Noskcaj  : used linux for some time ...but no particular choice ..
<trifort> npr: daily image has the next ubuntu release that isnât ready for everyone
<npr> popey  how to get  sutaible bug to solve form me ???
<npr> popey : what are programming skill i need .... i can code in python and c++ ....
<npr> popey : done simple web development with php and backend ....
<npr> popey : so how to find out a suitable bug ?
<popey> npr: take your time and browse those bugs to find one you can fix
<trifort> npr: https://bugs.launchpad.net/drizzle/+bugs?field.tag=low-hanging-fruit
<tedg> ev, bdmurray, it looks to me like this loop will exit if it finds any paid interface. Thus ignoring non-paid ones. https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/connectivity.c#L133
<tedg> tedg, I think you need to check what the default interface is, and use that to determine how traffic is being routed.
<trifort> npr: but I find it is best to find a bug that you care about
 * tedg is talking to himself
<npr> trifort : bug to care about ??
<trifort> npr: a bug that affects you
<npr> trifort : ok
<npr> trifort : i  find a bug ... whats the next step ??
<trifort> npr: see if you can reproduce it on your machine
<tedg> popey, An interesting test might be to remove your SIM and see if all your crash files upload.
<tedg> popey, I'm guessing the answer is yes :-)
 * popey looks for one of those things for popping out SD cards
<tedg> The ironic part about this being the case is that we'd be specifically not getting crashes from people using the phones daily, but instead from those using casually.
<popey> http://paste.ubuntu.com/7620234/
<popey> online
<popey> still doesn't look like it's uploading
<popey> i have a weeks worth of crashes in there, 15 of them
<tedg> popey, does it say "online" in syslog ?
<popey> yup
<popey> this worries me, that we haven't been capturing these crash reports â¹
<tedg> bdmurray, Any thing else that could be blocking them? ^
<bdmurray> popey: ls /var/crash/ ?
<bdmurray> tedg: oh, I haven't seen this before - "Unable to find a hardware address"
<tedg> bdmurray, I bet popey is hiding it.
<tedg> ;-)
<tedg> popey, perhaps restart to see if it's a race with oFono ?
<tedg> (restart whoopsie)
<tedg> Not the whole phone
<popey> http://paste.ubuntu.com/7620314/ is my var/crash
<popey> tedg: i rebooted the whole phone after yanking the sim
<bdmurray> well I get this error 'unable to find hardware address' message too
<tedg> popey, Yeah, curious if it can't get your address because whoopsie started before oFono.
<popey> ok, restarted whoopsie
 * tedg doesn't want to know what "dirty trojita" is in that directory listing.
<popey> hJun  9 22:47:20 ubuntu-phablet whoopsie[4282]: whoopsie 0.2.30 starting up.
<popey> Jun  9 22:47:20 ubuntu-phablet whoopsie[4282]: Using lock path: /var/lock/whoopsie/lock
<popey> Jun  9 22:47:45 ubuntu-phablet whoopsie[4287]: Could not connect to the system bus: Timeout was reached
<popey> haha
<popey> (email client)
<bdmurray> tedg: restarting whoopsie got me past the hardware address message
<bdmurray> popey: try '/usr/share/apport/whoopsie-upload-all'
<popey> i have done that before..
<popey> but thats manual, right?
<tedg> bdmurray, I imagine that is because it can't find oFono. Perhaps the upstart jobs need to be adjusted so it doesn't start until after oFono is up.
<popey> yeah, its uploading when i run that
<tedg> bdmurray, will upload-all block when on a paid connection? Or does it override that as well?
<bdmurray> popey: yeah, its manual but there is an upstart job to start it on a .crash file
<bdmurray> so if there were to be a new crash and a new .crash all existing crashes should be uploaded
<bdmurray> tedg: yes, whoopsie-upload-all is sort of a misnomer it gathers data for all .crash files and touches .upload so that whoopsie will upload them.
<bdmurray> tedg: but doesn't actually upload them
<popey> in the same way that I can find all of my uploads from the desktop, is there a way to find all my uploads from my device?
<tedg> But if popey had run that before it means there should be .upload files, right?
<popey> i have run it in the past, weeks ago
<tedg> popey, It's in the settings pane
<popey> so it is!
<bdmurray> tedg: not if it was weeks ago as some of those crashes are newer than that
<tedg> Yeah, okay. And they get cleaned up at some point.
<popey> no good for me wanting to look at these on my desktop though
<popey> cant copy/paste URLs â¹
<bdmurray> stand by
<tedg> popey, Type it *very slowly* :-)
<bdmurray> gdbus call -y -d com.ubuntu.WhoopsiePreferences -o /com/ubuntu/WhoopsiePreferences -m com.ubuntu.WhoopsiePreferences.GetIdentifier
<tedg> popey, As a hack the first url sent to the browser is on the command line, so you could probably get it via ps.
<tedg> Assuming the browser wasn't running when you clicked on it.
<popey> so it is!
<trifort> is there a way to visualize circular locks?
<popey> whee!
<popey> so should I crontab /usr/share/apport/whoopsie-upload-all ?
<popey> â»
<tedg> popey, As long as it takes out your SIM at the same time :-)
<popey> hah
<trifort> given two manifest files, is there a way to print the changelog differences for the whole manifest difference
<bdmurray> whoopsie-upload-all should have created .upload files unless whoopsie wasn't running
<tedg> trifort, You can diff two directories: diff foo/ bar/
<trifort> tedg: yes, did that
<trifort> tedg: sorry
<trifort> tedg: knowing that about 20 packages have changed, I want to print the changelogs for the 20 changed packages
<popey> All reports uploaded successfully
<trifort> tedg: I am wondering if a tool exists before making my own
<bdmurray> apt-listchanges
<tedg> popey, So we had to remove your SIM and restart whoopsie to get a HW address, then run upload-all ?
<trifort> bdmurray: okay, thanks for the help
<bdmurray> I reported the restart issue as bug 1328285
<ubottu> bug 1328285 in whoopsie (Ubuntu) "can not find hardware address" [Undecided,New] https://launchpad.net/bugs/1328285
<popey> thanks bdmurray tedg
<slangasek> stgraber: do you know a proper way to programmatically get a list of all network interfaces on a system, including those that are currently down?  http://linux.die.net/man/7/netdevice documents that SIOCGIFCONF doesn't include down interfaces, and recommends /proc/net/dev instead
<stgraber> slangasek: I usually iterate through /sys/class/net which works fine if you just want a list or want physical interface related kind of information. If you need to query the interface configuration, then you need getifaddrs and it's a whole other kind of worm (also, some most IPv6 info is also in /proc, but ipv4 isn't... yay for consistency)
<slangasek> stgraber: context is whoopsie trying to get a mac address to use as a system identifier; this shouldn't be dependent on network interfaces being up
#ubuntu-devel 2014-06-10
<stgraber> slangasek: /sys/class/net/*/address will get you that
<stgraber> slangasek: if you want to make sure you've got an ethernet device (and therefore a MAC), check that /type == 1 too
<slangasek> bdmurray: ^^ does that give you enough info to execute on this for whoopsie?
<slangasek> (of course, traversing directories in C is only the most tedious thing ever, but well.)
<stgraber> slangasek: well, compared to the networking syscalls, traversing directories is piece of cake :)
<bdmurray> slangasek: I think so
<sarnold> popen("ls -1"); /* run away */
 * infinity throws tomatoes at sarnold.
<xnox> slangasek: bdmurray: ha, chipaca and I were finding bugs in whoopsie system identifier today at code&coffee. So as I side note, ubuntu push notifications use whoopsie system identifier to send notications.
<Chipaca> xnox: to receive them, rather
<slangasek> oh, then all the more reason we should fix it so that the system identifier is persistent once chosen ;)
<Chipaca> stgraber: wlan devices also have MACs, tho
 * xnox still thinks it should do uuidgen instead.
<slangasek> Chipaca: yes, and wlan is a subset of ethernet for these purposes
<Chipaca> slangasek: wfm :)
<Chipaca> xnox: could you send me the code that segfaulted in the bum test, btw? wasn't able to reproduce your issue on the train home
<xnox> Chipaca: so for my ubuntu account, how do i get the same push notification both of my unity8 desktop & my phone? Do both desktop & phone must have different IDs? or on the contrary the same one?
<Chipaca> xnox: push messages are sent to tokens that are associated with (device, user, application) triads
<xnox> Chipaca: it's on my laptop, let me fetch it out and push. I got my select/channel strategy right. I think I will have just one channel, and "for range" across it. And close it when needed.
<xnox> Chipaca: that would be sequential processing and "go-like" i believe.
<Chipaca> xnox: and what about the process that died etc etc?
<xnox> go func(cmd) {message_queue <- cmd.Run(); message_queue.close()}
<Chipaca> slangasek: stgraber: so you're going to change whoopsie to read /sys instead of siocgifblessyouconf?
<Chipaca> a'ight
<xnox> the other one (the webserver) is really just go server(conn) {message_queue <- "restart or pass"} more-or-less.
<slangasek> Chipaca: I think bdmurray is taking this (bug #1328285)
<ubottu> bug 1328285 in whoopsie (Ubuntu) "can not find hardware address" [High,Triaged] https://launchpad.net/bugs/1328285
<Chipaca> excellent. that'll trickle down and avoid us some workarounds in push
<xnox> Chipaca: such that if process dies, and there was no api call to restart, I exit and die, otherwise restart the worker.
<xnox> Chipaca: but my scheme is on paper only at the moment (back of the envelope on the train), I'll write it up properly and will push for you to review.
<infinity> xnox: The point of not using uuidgen was to at least have a fighting chance for a reinstall to end up with the same ID, I thought.
<infinity> xnox: Which sounds even more interesting for the push notification thing than for the errors thing.
<infinity> (Though, I'd expect notifications to be tied to an account, not a machine...)
<Chipaca> for most services, yes, and applications need to support transparently re-requesting a token
<xnox> infinity: however for the push thing at the moment, multiple fresh machine installs end up with the same ID at the moment when they shouldn't.
<Chipaca> so uuidgen would work for us :)
<slangasek> entertainingly, uuidgen contains the same bug
<xnox> *fun*
<slangasek> ioctl(3, SIOCGIFCONF, [...])
 * xnox goes to fixing IMEI in ubuntu-emulator then
<slangasek> of course, 'uuidgen -t' generates a different one each time it's called, so that's not suitable for values you want to persist across reinstalls, regardless
<slangasek> which therefore makes it reasonable for it to only look at up interfaces :)
<slangasek> xnox: why IMEI?  whoopsie prefers mac address over imei
<slangasek> so if we fix this bug that causes whoopsie to not actually find not-yet-configured network devices, that would seem to be the most straightforward
<xnox> slangasek: IMEI has bigger range I can use vs QEMU registered MACs (or maybe those are just reserved)
<slangasek> xnox: ok; but we're not finding imei reliably on boot due to race conditions, and I was proposing we sidestep that
<xnox> right, but making emulator's SIM be realistic is also worthwhile.
<xnox> not finding imei reliably on boot -> how come?
<slangasek> xnox: if we think we *should* prefer IMEI, then that's a whole other set of code changes
<slangasek> xnox: because you can't query the imei until ofono starts, and you can't make whoopsie start on started ofono because it's not phone-specific
<xnox> it's a properly of the SIM modem
<xnox> oh, it's using ofono to query that, hm, not nice.
<slangasek> (you can shove a .override into the lxc-android-config package, but those overrides should eventually go away :P)
<slangasek> xnox: if by "property" you mean an android property, we should not be koolaid-man'ing the abstraction layers to query it directly from either whoopsie or the push notification service
<slangasek> (indeed, I think ev initially proposed having whoopsie query it via android libs and I argued him down :)
<xnox> haha, no not android properties. I would have thought one can query modems direct from like /sys/ but i guess we have ofono precisely because phone modems are anything but standard.
<slangasek> right
<slangasek> the middleware should be the interface
<slangasek> now, the other thing I don't understand here is how the push notification service is getting /whoopsie's/ system identifier... is it linking to libwhoopsie?
<xnox> and it looks like in the emulator at the moment i have to do $ adb shell start ofono, cause otherwise it's not getting started. Haven't checked yet, what's going wrong.
<xnox> slangasek: yeap, ubuntu-push notification imports a go package called "C" which allows to link & call C functions.
<xnox> slangasek: and it links in libwhoopsie (probably static, together with glib i guess)
<slangasek> xnox: right, I wasn't questioning the mechanics of linkage :), just wondering if libwhoopsie is what it's using for this - and wondering to myself if it's right that libwhoopsie own this
<xnox> slangasek: imho whoopsie should provide a dbus api socket to query system id (possibly dbus activatable)
<slangasek> blarg
<xnox> zorg?
<slangasek> why in the world should this go over dbus?
<xnox> not dbus as in dbusd system/session bus, but as in "any IPC call"
<slangasek> if the system ID should be persistent once determined, it should be written to the filesystem and everything else should just read it from there (with a suitable wrapper)
<slangasek> yes, why involve two processes in what should be a simple file read
<xnox> make kernel export one in /proc ?!
<xnox> well, /sys
<slangasek> am I being trolled
<xnox> I may have a sun-stroke =)
<xnox> i see your point, it should be a task to write out system-id somewhere well-known early in the boot when it is deterministingly known.
<xnox> i think ev was against that though, cause e.g. errors uses that id per-machine, not per-user. And knowing system-id one can check crashes from the other user.
<slangasek> er, but isn't that security through obscurity?
<slangasek> because the system ID is still generated deterministically based on publically-visible host info
<slangasek> anyone can compute the system ID by hand if they have access to the machine
<slangasek> we just don't do a good job of making the computation deterministically ourselves ;)
<psusi> xnox, hi there.. I realized recently that there are some changes that we have to dmraid and mdadm that need merged into debian ( since the corresponding changes to libparted already have been and cause some breakage ).. I noticed you filed an ITA on dmraid a while back and was wondering if you are still planning on doing that?
<xnox> psusi: i've replied to your private message, yes I need to upload dmraid into debian with all the changes i have staged. It's not ready for sid, but i can upload it into experimental.
<xnox> psusi: what specifically are you after to get added to dmraid?
<psusi> xnox, the 'p' partition separator changes for one, and the whole dmraid vs. mdadm for isw second
<psusi> Curtis Gedak has been testing a new gparted livecd release based on sid and found that both mdadm and dmraid are trying to activate isw arrays
<psusi> and that libparted thinks there should be a 'p' before the partition number but dmraid does not
<psusi> it's also still not using kpartx to activate the partitions so won't work with gpt
<psusi> I submitted the patches to kpartx to debian today that our dmraid changes depend on
<psusi> also I realized that I made kpartx-boot a hard depends of dmraid... but it should probably just be a recommends since if you just want to access a dmraid array but not boot from it, you don't need kpartx-boot
<tedg> slangasek, If someone has access to the machine they can just ask whoopsie for the ID, we don't lock it down. No reason for them to compute it.
<slangasek> tedg: right; thus there's no reason for us to compute it each time on boot (and sometimes get a different answer!) rather than recording it on disk.
<tedg> slangasek, yeah, I'd agree.
<tedg> But I do think computing it from well known addresses is better than a uuid.
<pitti> Good morning
<pitti> tkamppeter: FYI, latest cups regresses its tests: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-cups/lastBuild/ARCH=amd64,label=adt/console
<pitti> tkamppeter: "Error - unable to access "/usr/share/cups/data/testprint" - No such file or directory"
<Unit193> pitti: Howdy.
<tkamppeter> pitti, /usr/share/cups/data/testprint is part of cups-filters. Is it possible to introduce a dependency only for these tests?
<RAOF> tkamppeter: Sure, add it to the debian/tests/control file.
<tkamppeter> RAOF, thanks.
<dholbach> good morning
<pitti> tkamppeter: right, what RAOF said
<pitti> hey dholbach, wie gehts?
<Unit193> pitti: Decided to have fun, I'm on systemd 213.
<pitti> Unit193: oh, wow :) I have 208 locally, with the necessary merges with Debian
<Unit193> I have a minimal set of merges needed.
<dholbach> pitti, sehr gut - und Dir? auch am Schwitzen?
<pitti> dholbach: re from meeting
<pitti> dholbach: oh ja, Sommer :) it's going to be fun this afternoon, avoiding brain melt
<dholbach> haha, yes - it's supposed to be 36Â°C in Berlin today
 * pitti rolls down the shades everywhere
<dpm> morning cjwatson, I'm trying to create an i386 click chroot, but the following does not work: 'click chroot create -a i386 -f ubuntu-sdk-14.10' - it complains about architecture not being specified. Any ideas?
<dpm> cjwatson, nm, wrong command order
<ypwong> xnox, hey, wonder if you have some time to look at the seed branch of ubuntu kylin?
<xnox> ypwong: i have. They look ok. I don't know what the next steps are, e.g. upload meta src-package which uses germinate to generate meta-package and subsequently switch image building to use that.
<ypwong> xnox, who knows the next step?
<xnox> most recently Laney did it for desktop-next, and a few other people know about introducing need seeds into the image building infrastructure (e.g. cjwatson, infinity, etc) but I should learn / find out what's needed as well.
<ypwong> ypwong, should I wait for you for the instructions of what to do next? :) or i ask laney?
<xnox> well a new meta package will need to be uploaded, and clear NEW queue, before we can proceed switching the build to the new metapackage. So sponsoring to utopic is the next step, that I can do.
<xnox> Once that is done, further changes can be implemented.
<xnox> I'll try to get that sponsored today.
<ypwong> that's cool
<ypwong> thanks for that
<Laney> xnox: did you try a local build?
<xnox> Laney: good point, nope. How would I do that? I've never did livefs+cdimage build.
<xnox> (only d-i which is as easy as debuild)
<Laney> I didn't test the cdimage part, just with live-build
<Laney> to make sure the seeds are ~right
<Laney> when doing desktop-next, that is
<xnox> using lp:livecd-rootfs   ?
<Laney> you need to add a project there, or modify the existing kylin one I guess
<Laney> then I used http://people.canonical.com/~laney/random-scripts/build-ubuntu-iso
<Laney> upload your stuff (seed package + livecd-rootfs) to a PPA and change the PROJECT and PPA in there, then run that from a scratch directory
<Laney> mostly stolen from ubuntu-defaults-builder, thanks pitti ;-)
<pitti> Laney: note that this is probably outdated, e. g. I never tried it with UEFI
<Laney> right, just for testing in a VM that the stuff is good enough to try inside cdimage
<seb128> yeah, that script isn't UEFI friendly, it didn't boot on the inspiron 11
 * Laney nod
<xnox> Laney: can you re-kick off ubuntu-desktop live i386 & amd64 builds? I believe the webbrowser-app uninstallability has been resolved.
<Laney> okay
<shadeslayer> mhall119: hey, who's Svetlana
<doko> bdmurray, cjwatson: please could you subscribe foundations to cm-super bug reports (for a MIR)?
<xnox> jibel: hm, smoke-iso-validation do not pull iso images from cdimage.ubuntu.com, but instead  pull them from some other mirror?
<jibel> xnox, I don't know this job. let me check
<xnox> jibel: http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/Smoke%20Testing/job/utopic-desktop-amd64-smoke-iso-validation/ it should be pulling 10.1 image, but instead pulls 9
<xnox> http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/Smoke%20Testing/job/utopic-desktop-amd64-smoke-iso-validation/37/console
<xnox> what's tachash.ubuntu-ci?
<jibel> xnox, apparently it pulls ISOs from a machine somewhere in the lab. There must be a cron that updates them from cdimage.u.c
<jibel> psivaa, ^ do you know?
<jibel> xnox, but this is green now with your fix https://jenkins.qa.ubuntu.com/view/Ubiquity/view/Ubuntu/
<xnox> jibel: ah, good. So those pull the latest images!
<jibel> xnox, yes, they pull directly from pending/
<pkern> Who could I assign a kernel bug to for triage? (Patch landed upstream, workaround known.)
<xnox> jibel: so should the other iso-validation and preseed jobs, cause those block pending -> current migration.
<xnox> jibel: i guess i'll have to wait.
<psivaa> xnox: yea, the tests run on aldeberan which takes the image from jatayu
<xnox> psivaa: why not take images from cdimage?
<xnox> psivaa: and/or what's the propagation delay?
<xnox> psivaa: e.g. static-validation did see 20140610.1 image and does asserts for the image to be that, yet it pulled 20140609 under test
<psivaa> xnox: no idea, may be retoaded knows why not taken from cd image
<psivaa> xnox: static validation gets triggered once the checksum in the local cache is updated and at that point cdimage and the local cache will be in sync
<xnox> hm, ok.
<psivaa> if you trigger it manually before the full sync then you'd see issues :)
<xnox> psivaa: =))))) damn
<psivaa> xnox: speaking of static validation, i *think bsdtar in trusty is causing the failure, test_vmlinuz
<psivaa> http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/Smoke%20Testing/job/utopic-desktop-amd64-smoke-iso-validation/36/console
<jibel> xnox, the sync script runs every 2 hours, so you'll have to wait.
<pitti> dpm, jamespage, xnox: tomorrow's sessions about "langpacks for touch devices" and "systemd plans for server" are in the same time slot, any chance to move either of them? otherwise I'll attend the langpack one; xnox and slangasek know enough about systemd anyway
<dpm> cjwatson, when you've got a minute, do you think you could help us with bug 1328486 ? We're trying to recommend the emulator for core app developers, and this one is blocking us on compiled apps. Thanks!
<ubottu> bug 1328486 in click (Ubuntu) "Click x86 chroot fails to build cmake projects" [Undecided,Confirmed] https://launchpad.net/bugs/1328486
<xnox> pitti: i was hoping to have you as an expert panellist on systemd one.
<dpm> pitti, ok, thanks for the heads up. I've got no permissions on the devel track, but I think slangasek can reschedule meetings there
<pitti> xnox: heh; I'm not actually that much of an expert in systemd (the boot part), I'm pretty much learning as I go :)
<shadeslayer> slangasek: ping
<xnox> dpm: i thought that failure serguisens and I fixed when we were in malta.....
<dpm> xnox, I don't know, both zbenjamin and I could reproduce it. I'm using trusty, if that makes a difference.
<dpm> or is the fix pending upload?
<xnox> dpm: how is that a bug with click, instead of the bug in cmake of that app?
<dpm> xnox, it's not just that app, (which builds fine on non-click x386 and click armhf), it can also be reproduced in the other example attached to the bug
<mhall119> shadeslayer: she's belkinsa on irc, very active community person
<shadeslayer> cheers
<pitti> dpm: I implemented the percentage treshold now: http://paste.ubuntu.com/7623368/
<pitti> dpm: I used 50% as Chinese has 59% coverage (as the number of packages in the image is quite a bit higher than the apps+unity8 in your web app, 70% is too high)
<cjwatson> doko,bdmurray: done
<cjwatson> dpm: what version of click are you using?
<CodePulsar> What is the password for joining the IRC channels? I've registered at LaunchPad. How can I join the sessions?
<cjwatson> no password
<pitti> ogra, dpm: so http://people.canonical.com/~pitti/tmp/langpack-touch/ have 65 MB Installed-Size in total
<pitti> those are the languages with at least 50% coverage
<CodePulsar> I always get redirected to #ubuntu-uds-platform-1 instead of the actual channel
<cjwatson> I don't know what actual channel you're talking about
<pitti> ogra_, dpm: whereas on today's phone build we have a total Installed-Size: 139736
<pitti> for just 5 languages
<CodePulsar> cjwatson: nevermind, fixed the problem
<ogra_> pitti, wow !
<pitti> dpm, ogra_: spec updated
<pitti> mvo: did you see the aptdaemon test regression? that looks real
<mvo> pitti: uh, I have seen it but failed to investigate in detail :/
<pitti> mvo: nevermind, thanks; mostly want to check whether email notifications are working
<mvo> pitti: I wanted to get a new upstream release out of the door but it seems we are not there yet
<mvo> pitti: aha, now I do remember, it wasn't failing on my normal box :/ need to test with a schroot
<dpm> cjwatson, sorry, I was on the phone. I'm using click 0.4.25-ubuntu1~0trusty1
<dpm> awesome, thanks pitti!
<dpm> pitti, one thing I'd like to discuss in the session is how to make the stats and cut-off more meaningful and filter out the packages that are not visible in the UI
<dpm> so that there's not a disconnect between what we're asking the translators to focus on the web stats and the l-p-o-matic stats
<cjwatson> dpm: ok, will take a while to build the chroot
<rbasak> infinity: what's the next stop for the juju-core powerpc ftbfs please? Currently it's impacting landing some bugfixes in Trusty and unblocking juju-quickstart from being broken in Trusty.
<rbasak> I'm wondering whether to ask for an exception to get an SRU landed to Trusty ahead of this to unblock that.
<dpm> thanks cjwatson
<dholbach> xnox, is http://summit.ubuntu.com/uos-1406/meeting/22303/how-to-get-your-path-into-debian-ubuntu/ your session?
<cjwatson> if so it's misspelled ...
<xnox> dholbach:  yes.
<xnox> cjwatson: i've corrected the spelling in the title, but url persisted?!
<mapreri> xnox: the origianl url stays there to avoid breaking existing link. http://summit.ubuntu.com/uos-1406/meeting/22303/how-to-get-your-patch-into-debian-ubuntu/ works fine too.
<xnox> mapreri: ok, cool.
<dholbach> xnox, ok... I just asked because there's "How code contributions make it into Ubuntu" later on that day as well (run by sil2100 and myself)
<dholbach> xnox, is it going to be a demo/presentation?
<mapreri> xnox: too be honest, you can put everything after the numbers let the links works. e.g http://summit.ubuntu.com/uos-1406/meeting/22303/wrghoet/ works fine too :)
<xnox> dholbach: can be merged if you wish, and I'll join you.
<xnox> dholbach: it was a request to steve to host a session, let me find an email about it.
<xnox> dholbach: hm, mhall119 requested to lead a development getting things into ubuntu session. I was planning to run through bug -> patch -> (ubuntu sponsorship queue) / (debian BTS patch submission) -> done
<xnox> dholbach: and then take questions.
<xnox> dholbach: not quite a demo.
<dholbach> xnox, ah ok... looks like I tried to do the same thing - first show/explain how patches get into Ubuntu and then let somebody (in this case sil2100) talk about how changes get into all our upstream projects, which then go through CI, and at some stage land on touch images
<dholbach> xnox, I'm not sure if all in all it wouldn't be too much to cover in an hour :)
<sil2100> xnox, dholbach: I wanted to only mention the path of CI Train to get packages into the archive
<dholbach> xnox, sil2100: if you think all the content fits into one session just fine, I'd let you two do the talking and I pass on the questions and/or ask some stupid questions myself :)
<cjwatson> dpm: OK, I see the problem, thanks.  It won't involve rebuilding chroots, fortunately
<dpm> cjwatson, ah, excellent. Will it require new package uploads, or is there a workaround I can use? I'm asking as I'm running a UOS session tomorrow about using the emulator for app development
<cjwatson> dpm: see bug comment
<dpm> ok, reading
<michagogo> cjwatson: btw, why is it reqorts? Shouldn't it be reports?
<michagogo> (also, reports does work, but it redirects...)
<vmlintu> Hi, I'm trying to understand the 3.13 kernel maintenance process. How the patches end up there? The tree here has seen no activity for some time: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.13.y;a=shortlog  Am I looking at the right place?
<cjwatson> michagogo: some infrastructure problem at some point I believe, but I don't operate it and know nothing
<michagogo> Heh
<slangasek> shadeslayer: pong?
<cjwatson> vmlintu: #ubuntu-kernel is probably a better place to ask
<shadeslayer> slangasek: how do you want to do session notes on the platform track
<vmlintu> cjwatson: thanks, I'll ask there
<michagogo> Also: is there a log of completed SRUs somewhere?
<michagogo> (I'd like to take a look and see if there's an average time for them to be done)
<slangasek> shadeslayer: hmm.  An etherpad?
<shadeslayer> slangasek: well, do we have a schedule on who's covering what?
<slangasek> shadeslayer: I assumed that the track leads who approved the talks would be responsible for covering them (or soliciting notes from the session leads)
<shadeslayer> ah ok
<bulletxt> hi, Ubuntu 14.04 is shipping gutenprint 5.10 PRE2   but the final release came out some time ago. Do you think you can update it to latest release? Thanks a lot
<pitti> dpm: yep, sounds good
<dpm> cjwatson, thanks for investigating bug 1328486 - I understand this will need a fix in click and a subsequent upload. For my demo tomorrow, shall I go for the hack you're mentioning (despite the warning), though? Or do you think you might be able to come up with a branch I could use directly for the demo?
<ubottu> bug 1328486 in click (Ubuntu) "Click x86 chroot fails to build cmake projects" [Undecided,Confirmed] https://launchpad.net/bugs/1328486
<cjwatson> dpm: I have a mostly fairly quiet day, so I'll see what I can do between sessions
<dpm> ok, thanks!
<cjwatson> dpm: not sure I can get a landing through in time, so it might be "use this branch for now"
<dpm> cjwatson, I think that'd be perfect
<TuxRescue> friendly greetings. nobody on #ubuntu could answer the qestion why "apt-cache show" will not display tag information (debtags) and my google efforts leave me without usable results
<TuxRescue> are tags not used at all in ubuntu?
<CodePulsar> Ubuntu Login and Launchpad can have the same password?
<CodePulsar> I've changed the password on my Ubuntu Login account and now I cannot login to LaunchPad
<TuxRescue> CodePulsar: easy: try your old new and your old password?
<TuxRescue> nvm
<CodePulsar> The password is the same
<CodePulsar> There is some mismatch somewhere
<CodePulsar> ah found the culprit
<CodePulsar> the password manager didn't change the password
<CodePulsar> Also, Why I cannot login with Ubuntu Login to Launchpad, i.e. authorize Launchpad in Ubuntu Login, why do I have to provide the password in LaunchPad which is the same as Ubuntu One, or is this process doing exactly what I say?
<CodePulsar> Ubuntu Login user/pass is the same as LaunchPad user/pass ?
<rbasak> CodePulsar: try asking in #launchpad.
<rbasak> TuxRescue: I have no idea, but askubuntu.com is a good place for that kind of question.
<TuxRescue> okay, sorry
<mterry> Is anyone familiar with starting hangouts for Ubuntu Online Week?  I get the error "Sorry, Hangouts On Air has been disabled by your domain administrator"
<mterry> mhall119, ^
<mhall119> mterry: several people are having that with their canonical account, please ask IS for help, there's nothing I can do there
<CodePulsar> mhall119: do you have the browser plugin installed?
<CodePulsar> mterry: ^
<mterry> CodePulsar, I think so?  I've participated in hangouts before
<CodePulsar> about:plugins
<CodePulsar> mterry: are you logged in with the "right" Google account?
<mterry> CodePulsar, yeah
<dholbach> xnox, sil2100: so do we feel we can merge all this content into one hour or what should we do?
<sil2100> dholbach: both sessions are tomorrow?
<dholbach> as both sessions are tomorrow, it might be good to make any necessary change now, so folks have time to adapt to a changed schedule
<Laney> I think you need more than an hour to cover both CI train and packaging and forwarding to Debian
 * Laney both <three things>
<dholbach> Laney, I guess you're right... we'll just leave everything as it is for now
<dholbach> sil2100, xnox: ^
<Laney> dholbach: Maybe make them concurrent?
<Laney> not that I'm involved so feel free to ignore :)
<Laney> I meant sequential not concurrent, sorry was reading something about threading at the same time...
 * Laney goes away now
 * dholbach hugs Laney
<pitti> stgraber, infinity: reminder: TB meeting in #u-m-2 in 2 mins
<mterry> bregma, are you able to start a canonical on air session?
<mterry> bregma, neither seb128 nor I can start one due to technical problems with IS
<bregma> doesn't look like it
<mterry> :(
<mterry> stgraber, can you by any chance?   ^
<seb128> dholbach, mhall119: did other people had issues with their account being restricted?
<stgraber> mterry: nope, I'm leading another session at the moment
<dholbach> seb128, mhall119 said earlier to talk to IS about it - they should know more about what's wrong
<mhall119> seb128: yes
<mterry> stgraber, ah, OK.  well at least it works for someone  :)
<mterry> dholbach, yeah I talked to IS.  They escalated the issue but weren't sure of ETA
<dholbach> mterry, seb128: so nobody can run the desktop session now?
<mterry> dholbach, looks like it
<dholbach> let me see if I can
<seb128> dholbach, I can't
<seb128> google tels me that live hangouts are desactivated and I need to talk to my admin about it
<mterry> bregma, can you join?
<xnox> dholbach: well my session was going to be <<1h, and the ci-train/packaging has potential to overrun.
<xnox> dholbach: can we have a 2h slot between all of us back-to-back
<dholbach> sure... I don't know when exactly sil2100 has time
<sil2100> dholbach, xnox: theoretically I have time all UOS, since I have to be around anyway :)
<sil2100> So I'm fine with anything tomorrow I guess
<dholbach> sil2100, would 15 UTC tomorrow work as well? that'd be right after xnox' session
<dholbach> xnox, sil2100: do you feel we need to rename the sessions somewhat to make the difference clearer?
<xnox> dholbach: sure call them "Kill Bill vol1" & "Kill Bill vol2"
<sil2100> dholbach: that time is fine for me I guess
<xnox> dholbach: or some more appropriate titles.
<sil2100> dholbach: and don't listen to xnox !
<dholbach> xnox, sounds great!
<dholbach> I never saw the movies :)
<xnox> dholbach: danke schon, meine freund!
<xnox> sil2100: alles klar?! =)
<sil2100> xnox: ja ;)
<xnox> sil2100: fantastisch!
<dholbach> xnox, sil2100: already - I moved the session
<dholbach> sil2100, maybe we could call the session "from fix to phone: getting your fix on the Ubuntu phone" or some such? just to make it clearer and distinguish from the other session?
<sil2100> dholbach: hm, since CI Train can be also used for desktop, I'm not sure if this completely fits my part of the session :)
<dholbach> hum, ok
<dholbach> I was just trying to come up with a catchy title ;-)
<sil2100> Maybe 'from fix to image' instead? Then it could mean both phone and desktop ;)
<dholbach> sil2100, works for me!
<Laney> from my keyboard to your screen
 * Laney is a marketing genius
<dholbach> Laney, maybe you want to move to the comms team!
<dholbach> xnox, sil2100: we're all set then :)
<sil2100> dholbach: thanks for taking care of this :)
<sil2100> Laney: hah! ;)
<dholbach> no worries
<Laney> A first in class patch distribution process bringing enterprise grade deployment strategies to the Ubuntu ecosystem
<xnox> Laney: as seen on TV!
<Laney> I'll take ten!
<shadeslayer> jsalisbury: ping, got a moment to discuss https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1310402
<ubottu> Ubuntu bug 1310402 in linux (Ubuntu) "Userland depends on ionice idle but default scheduler is "deadline". " [Wishlist,Triaged]
<shadeslayer> jsalisbury: I have baloo upstream here too, so would be nice if you had a moment to sort it out
<shadeslayer> s/it/this/
<dholbach> Laney, I'd say our holistic strategy utilises user-centric processes to empower our users users to bring powerful synergy effects to Ubuntu. What do you think?
<sarnold> I'm not sure you've really captured the idea that ubuntu is by and for the users though. could you mention them a bit more?
<jsalisbury> shadeslayer, sure.  It might be better to discuss on #ubuntu-kernel
<dholbach> sarnold, ok, you'll have the post of propaganda minister in our team - we'll have our first meeting on Monday
<shadeslayer> vHanda: ^^ ok
<sarnold> sweet. I'll polish up my medals.
<xnox> rbasak, jamespage - i wonder if maybe you could help me. cgo is passing "-marm -march=armv7-a -mfloat-abi=hard" when compiling, which my compiler doesn't like, saying "gcc: error: unrecognized command line option '-marm'"
<xnox> rbasak: jamespage: any idea, what's wrong? I do have GOARM=7 set in the environment.
<rbasak> xnox: not really my department, sorry. I don't have any specific experience with cgo.
<rbasak> xnox: but my immediate question is: you're calling gcc - native on amd64? Do you need it to be calling a cross compiler, or are you native on armhf already?
<xnox> rbasak: hm, ok. I do wonder if installing gcc-multilib would resolve it.
<xnox> rbasak: it's calling ["arm-linux-gnueabihf-gcc", "-E", "-dM", "-xc", "-marm", "-I", "/tmp/go-build772552266/runtime/cgo/_obj/", "-Wall", "-Werror", "-"]
<xnox> from strace.
<rbasak> Ah, OK. It's not that then.
<xnox> it just shouldn't pass -marm, as the cross-compiler is not a multilib one and doesn't need "-marm" flag
<rbasak> Yeah I did wonder that.
 * xnox writes a shell wrapper that drops -marm flag....
<rbasak> It's a little bit of an unusual situation though - with cross compiling. It wouldn't surprise me if you've hit an edge case not previously considered.
<xnox> or should i recompile cgo
<rbasak> Yeah I was going to suggest a wrapper :)
<rbasak> Though I don't see why gcc shouldn't accept that flag anyway
<xnox> rbasak: i'm guessing, doko would say it's a lie.
<xnox> who is not online, hm.
<cjwatson> dpm: There's a branch linked from the bug now.
<cjwatson> https://code.launchpad.net/~cjwatson/click/native-dpkg-architecture/+merge/222690
<cjwatson> mvo: ^- could you review that when you get a chance?
<mvo> cjwatson: sure, let me have a look
<cjwatson> oh damn wrong target
<cjwatson> old habits die hard.  fixing
<cjwatson> mvo: https://code.launchpad.net/~cjwatson/click/native-dpkg-architecture/+merge/222691
<dpm> oh awesome, thanks cjwatson!
<cjwatson> mvo: huh, mvo_ isn't you?  I was talking to that user in /msg and hadn't had a reply ...
<mvo> cjwatson: it may just be a leftover connection
<cjwatson> Not your usual /whois output
<mvo> cjwatson: *ick*
<brotoes> Hello all. I am creating an internal APT repository using reprepro and apache2. The distributions config file seems to want a paragraph for every release of ubuntu. is it necessary to add every distribution of ubuntu you want the repo to work with to the file?
<cjwatson> mvo: thanks, fixed the mocking now
<mvo> thanks cjwatson, its really a detail all the tests will be exercised on the buildds
<cjwatson> ... and remembered to push
<mvo> s/a/as/
<cjwatson> yeah, it does make it easier locally though of course
 * mvo nods
<cjwatson> Crudest mock ever but hey
<cjwatson> stgraber: Could you stick https://code.launchpad.net/~click-hackers/click/devel/+merge/222702 into the CI Train, please?
<stgraber> robru: hey, I'm getting "stgraber is missing the Job/Build permission" again... is that related to the Jenkins problems?
<mvo> cjwatson: heh, mock is fine, we have a fake-dpkg in the apt testsuite that is simlar
<robru> stgraber, hm, i'll check
<robru> stgraber, which job are you trying to run?
<stgraber> robru: trying to assign a silo for cjwatson
<robru> stgraber, ah indeed, the permissions I added got reverted
<cjwatson> dpm: does bug 1328486 still need its non-click tasks?
<ubottu> bug 1328486 in Ubuntu Reminders app "Click x86 chroot fails to build cmake projects" [Undecided,New] https://launchpad.net/bugs/1328486
<robru> stgraber, ok try now
<stgraber> robru: worked, thanks!
<stgraber> cjwatson: you've got silo 14
<robru> stgraber, now I'll try to make it really permanent ;-0
<cjwatson> stgraber: thanks
<cjwatson> stgraber: did you already hit build or shall I?
<stgraber> cjwatson: I didn't hit build for you
<cjwatson> ok, will do that
<psusi> cjwatson: I'm trying out git-dpm to update the parted git repo and naturally there are conflics trying to rebase the patches... what I can't figure out is how to tell what patch is now half applied ( conflicted )?  all I can see is that these files have been changed and have conflicts, but I have no idea why.. any tips?
<cjwatson> psusi: well it's just the usual things for git rebase, IIRC you normally get <<< >>> markers
<psusi> yes, the conflicts are marked in the code, but what I'm looking for is the log describing what change I'm in trying to resolve
<cjwatson> oh I remember that being awkward
<cjwatson> there's a file somewhere under .git, I forget the name, you can pass it to "git show"
<psusi> I thought it was supposed to be in .git/COMMIT_EDITMSG, but it seems to hold the previous correctly applied patch isntead
<cjwatson> .git/rebase-apply/patch or something
<cjwatson> https://stackoverflow.com/questions/2118364/how-to-identify-conflicting-commits-by-hash-during-git-rebase
<psusi> dpm seems to be using rebase-merge rather than rebase-apply
<cjwatson> some trivial variant of the above procedure worked the last time I needed this anyway
<psusi> hrm... boy, what a pain
<cjwatson> yeah, this could be easily improved in git rebase I suspect
<psusi> you'd think that git status would tell you the name of the commit you are in the middle of trying to resolve
<cjwatson> all it'd need to do is tell you the commit hash and first line of ... yeah
<psusi> aha... git log --color -p -n 1 `cat .git/rebase-merge/current` does the trick
<cjwatson> that sounds about right; I think you can even just pass the file name rather than `cat ...`
<psusi> seems it wants the `cat ...`
<cjwatson> ok
<xnox> rbasak: tracked it down between the talks -> right compiler, wrong linker = caboom!
<rbasak> xnox: nice :)
<psusi> cjwatson: I think I found a bug in git-dpm.. been git rebase --skip'ing a lot of the patches since they are merged in the new upstream... but I got to one it won't let me get past... git rebase --skip just tries to apply the same patch over again
<cjwatson> psusi: I had that once but could never reproduce it accurately.  But what makes you think it's a bug in git-dpm rather than in git rebase?
<psusi> could be.. I'm not sure how git-dpm is actually interacting here
<cjwatson> I think I ended up restarting the rebase from scratch and it went away
<cjwatson>         gitcmd rebase -m --onto "$UPSTREAMREV" "$oldupstream" || ret=$?
<cjwatson> really nothing especially special
<cjwatson> if you can figure out an accurate reproducer then I'm sure git upstream would appreciate the report
<cjwatson> maybe one that's a bit smaller than "rebase parted" :)
<cjwatson> I think I hit it with password-store a while back
<psusi> so there isn't any sort of hook that gets run in dpm until after you are completely finished with the rebase?
<cjwatson> not afaik
<cjwatson> it's all just plain git at this level
<dpm> cjwatson, the fix for click works wonderfully, thanks :)
<cjwatson> dpm: great - should be publishing at the moment so with any luck you'll have it in utopic in time for your session tomorrow
<dpm> excellent
<cjwatson> dpm: I don't maintain the trusty backport so you'll need to ask whoever does to update that
<dpm> cjwatson, that's fine, I can take care of that
<cjwatson> cool
<psusi> well, other than this apparent git bug getting stuck and the lack of a simple/automatic description of what patch you are trying to resolve, which is just another git shortcoming, so far git-dpm seems pretty sweet
<xnox> Chipaca: totally cross-compiled ubuntu-push-client.go. piece of cake 4 line invocation of "go build"
<xnox> http://blog.surgut.co.uk/2014/06/cross-compile-go-code-including-cgo.html
<cjwatson> mvo: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-click/lastBuild/?
<mvo> thanks cjwatson
<bharper> Does Ubuntu have any documentation for building packages for a third party repo?  Any special consideration like package naming converstions?
<seb128> is there known multiarch issues on utopic?
<seb128> http://pastebin.ubuntu.com/7625153/ is what seems to happen when trying to crossbuild ubuntu-system-settings
<seb128> "                    Depends: libc6-dev:armhf but it is not going to be installed or" is in the log
<cjwatson> apt's output tends to be misleading once things go wrong enough
<cjwatson> has this package ever cross-built before?
<seb128> pmcgowan, what happens if you try to apt-get install libc6-dev:armhf ?
<cjwatson> if not, it probably needs additional things converted to multiarch in various ways
<seb128> cjwatson, yes, it was working fine in trusty, Laney fixed issues with rdepends a few times
<seb128> I guess something in utopic regressed there
<cjwatson> I'm confident libc6-dev:armhf is a red herring
<pmcgowan> seb128, Recommends: gcc:armhf but it is not going to be installed
<seb128> do you have any tip debugging such issues?
<cjwatson> you typically have to iterate on adding every mentioned package to a single large apt-get install call until you get more useful errors
<cjwatson> and keep an eye out for anything that's nonsensical
<seb128> pmcgowan, what about apt-get install gcc:armhf ?
<cjwatson> quite often failures are because you end up trying to install host-arch versions of things that really should be tools (i.e. build arch)
<cjwatson> gcc:armhf is one such nonsensical thing; you don't want that
<seb128> cjwatson, is that normal that apt stops on recommends?
<pmcgowan> seb128, just keeps chaining
<cjwatson> seb128: --no-install-recommends
<seb128> pmcgowan, does it work if you "apt-get build-dep --host-architecture=armhf --no-install-recommends  ubuntu-system-settings"
<pmcgowan> seb128, no same thing
<cjwatson> will need work, doubt I can debug this with twenty-questions on IRC
<seb128> pmcgowan, ok, anyway it's not likely a local error but a bug, I'm going to try to have a look tomorrow
<pmcgowan> seb128, thanks a lot
<seb128> cjwatson, yeah, I was thinking the same, thanks for helping ;-)
<cjwatson> oh I don't have a useful chroot for this right now
<cjwatson> will build one after this session
<seb128> cjwatson, don't worry, I can try debugging it tomorrow (might ping Laney for help if needed, he did some of that before ;-)
<seb128> you already have enough to do
<xnox> seb128: it could be transient, and
<xnox> typing in the wrong window
<xnox> seb128: pull-lp-source ubuntu-system-settings; sbuild --host armhf *.dsc cross-compiles fine. So (a) disable proposed, (b) it might not be a clean chroot.
<seb128> pmcgowan, ^
<xnox> pmcgowan: do you have a complete log of what's failing?
<seb128> xnox, http://pastebin.ubuntu.com/7625153/
<xnox> seb128: that's not a full sbuild run, e.g. with apt-get update and sources used etc.
<pmcgowan> xnox, I did that earlier and had the same issue
<pmcgowan> well
<pmcgowan> I did an sbuild on a chroot I made, and it failed to get the deps
<xnox> pmcgowan: it could have been transient, since there is new gcc in proposed.
<pmcgowan> maybe my chroot is bad then
<xnox> it does eventually FTBFS
<cjwatson> certainly disabling -proposed is a good idea whenever you're expecting multiarch to work in any way whatsoever
<xnox> /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'
<seb128> bah, what is "dpkg --add architecture armhf" doing? I did that and now my apt-get complains about invalid sources
<cjwatson> since the arch skew in -proposed frequently causes failures and that's specifically something that proposed-migration guards us against
<xnox> but that's 91% into compiling.
<xnox> seb128: oh, you need to arch qualify all your sources.
<cjwatson> seb128: just use mk-sbuild --target=armhf utopic
<xnox> seb128: i hate that.
<seb128> cjwatson, thanks
<cjwatson> you don't want to add an architecture to your regular system for this kind of thing
<cjwatson> it will just be a pain
<pmcgowan> cjwatson, how do I disable proposed for the chroot?
<seb128> well, that "regular system" is my test laptop
<xnox> seb128: well, $ mk-sbuild --target=armhf --skip-proposed utopic
<cjwatson> pmcgowan: edit /etc/apt/sources.list
<cjwatson> seb128: even so
<cjwatson> oh yeah --skip-proposed
<pmcgowan> ah
<cjwatson> pmcgowan: it's possible you already have stuff installed from there though; if you can easily recreate it from scratch with the mk-sbuild command above, then do
<xnox> pmcgowan: seb128: https://wiki.ubuntu.com/Touch/CrossCompile
<pmcgowan> cjwatson, yeah I will start over (again)
<pmcgowan> yeah thats what I used
<xnox> that has the 2-step guide, plus extra info
<pmcgowan> simply didnt work for me
<seb128> xnox, thanks, googling I found https://wiki.ubuntu.com/CrossBuilding which was not that useful
<seb128> or maybe it was
<cjwatson> feel free to add --skip-proposed to that :)
<seb128> I just tried to add it to my normal system :p
<seb128> e.g avoiding sbuild
<xnox> seb128: well it has the same two steps down in the middle of the page.
<seb128> right, just noticed
<cjwatson> and maybe add sterner comments to it about how taking shortcuts probably won't help :)
<seb128> but I didn't want to sbuild (maybe I was wrong)
<xnox> seb128: your normal system will break, when you try to e.g. cross-compile something that pulls in armhf GLES and knocks out your GL (compiz/unity7....)
<pmcgowan> cjwatson, so to be sure, how do I clear out my existing bad schroots
<seb128> xnox, well, I don't care, that's my "test unity8 desktop session" test box
<cjwatson> pmcgowan: make sure they're not in use (schroot -l --all-sessions), then you can just remove the relevant things from /var/lib/schroot/chroots/ and /etc/schroot/chroot.d/
<cjwatson> seb128: more importantly it's just much more of a pain to debug anything not in a clean chroot
<cjwatson> and there are some conflicts you hit when trying to do things in a full system + extra architecture that won't happen in a clean chroot
<cjwatson> so I actively recommend against that approach
<seb128> cjwatson, that's true, though often a real system is enough to hit installability issues and debug
<seb128> noted
<cjwatson> yeah, but seriously you get *loads* more
<seb128> thanks ;-)
<cjwatson> it will waste ridiculous amounts of time :)
<cjwatson> at least used to
<seb128> I somewhat got twisted habits because my laptop has a 80G disk and I'm avoiding extra chroots or vms there
<cjwatson> you end up trying to make the whole desktop multiarch-compatible in ways that aren't otherwise necessary
<cjwatson> pmcgowan: you might want to use the rm --one-file-system option for safety
<pmcgowan> too late, all gone
<cjwatson> ok, if your home dir is still there then I guess it's fine :)
<pmcgowan> ;)
<cjwatson> *cough*
<pmcgowan> hmm good point
<pmcgowan> but it is
<cjwatson> checking for no active sessions first is usually enough
<pmcgowan> I quit the session and nuked them first
<cjwatson> dpm: click 0.4.26.1, will be in utopic after this publisher run
<dpm> cjwatson, excellent. And perfect timing, I just got my first compiled app to build and run on an x86 emulator from Qt Creator :)
<cjwatson> (informal version number format: backward-incompat.backward-compat for version of packaging format spec, then landing count, then optional brown-paper-bag count for landing failures)
<cjwatson> dpm: great
<mvo> cjwatson: sorry for the jenkins breakage, I'm fixing it now
<cjwatson> np, thanks
<pmcgowan> dpm, awesome, glad it worked
<dpm> pmcgowan, yep, all ready for the demo session tomorrow
<cjwatson> dpm: please can you delete the non-click tasks on that bug then, since it sounds like it was never a problem there?
<dpm> cjwatson, sure, done
<cjwatson> ta
<hallyn> infinity: hey, you had said earlier that qemu upstream had aarch64 full emulation patches you wanted.  Could you check ppa:ubuntu-virt/virt-daily-upstream and see if that trusty package has what you need?  (i need to merge at least 2.0.0+dfsg-6, maybe git head into utopic soon)
<hallyn> patches in https://github.com/susematz/qemu/commits/aarch64-1.6 are still noticably absent from upstream though
<infinity> rbasak: How is an FTBFS in utopic blocking anything in trusty?  That sounds like a process failure I can't help with. :P
<Chipaca> xnox: code or gtfo :)
<Noskcaj> pitti, I think you can sync psqlodbc, the ubuntu delta is no longer needed (i think)
<xnox> Chipaca: it's not that bad =) i'm sure you can wrap it in your makefile easily ;-)
<Chipaca> xnox: why would i?
<Chipaca> (serious question; is there a benefit?)
<Chipaca> xnox: i guess building on my computer and testing the resulting binary on the phone?
<xnox> Chipaca: yes, and a table of 15 people bugging me that "they can't build on the phone any more, cause dependencies don't fit to install" and they are using go with cgo and have no way to compile code locally anymore for testing
<Chipaca> xnox: :) ok
<xnox> Chipaca: and thus relying on e.g. 40minute feedback loops to get binaries from e.g. merge proposal.
<Chipaca> hey, if dependencies for push fit on the phone, ... what dependencies are they trying to get that don't fit?
<xnox> Chipaca: dunno, scopes go something
<Chipaca> xnox: while you're in this neck of the woods, and seeing as how you have me thinking about this already, ...
<Chipaca> xnox: how do i cross-compile the signing helper?
<xnox> Chipaca: what is signing helper?
<Chipaca> xnox: in ubuntu-push, under signing-helper
<Chipaca> xnox: usually built with e.g. cmake && make
<xnox> Chipaca: do that, but in a click chroot, or prefix cmake with $ dpkg-architecutre -aarmhf -c cmake && make
<xnox> Chipaca: but since it uses Qt5, i'd do it in a click chroot.
<Chipaca> xnox: pointers to read up on click chroots?
<Chipaca> xnox: is that just a regular arm schroot? qt5 builds ok in there?
<xnox> Chipaca: http://paste.ubuntu.com/7625572/
<xnox> Chipaca: yeah, it's a regular amd64 chroot, with crossbuild-essential-armhf + installing most of ubuntu-sdk-libs-dev packages that are multiarch installable
<Chipaca> neat
<Chipaca> anyway, i came online to find an audiobook to listen to while ironing school uniforms
<xnox> Chipaca: i don't know where are our click chroot docs, cause create needs funky args which I got wrong way around lately (as in it only installed stuff for like html5 apps, instead of cross-compiler to compile native binaries)
<Chipaca> xnox: I'll look it up in a bit
<Chipaca> xnox: thanks :)
<xnox> Chipaca: I think $ click chroot -aarmhf -fubuntu-sdk-14.10-papi-dev1 create
<xnox> should do the right thing, and then
<xnox> $ click chroot -aarmhf -fubuntu-sdk-14.10-papi-dev1 run cmake .
<xnox> $ click chroot -aarmhf -fubuntu-sdk-14.10-papi-dev1 run make
<xnox> in the signing-tool folder should cross-compile everything the right way
 * Chipaca obeys
<Chipaca> hmm, create needs sudo
<xnox> yeap.
<xnox> damn fails
<xnox> then i'd try
<xnox> $ sudo click chroot -aarmhf -fubuntu-sdk-14.04-papi-dev -sutopic create
 * Chipaca continues setting up his ironing space
<xnox> which is do what 14.04 would do, but force use utopic
<xnox> or maybe my click package is simply out of date
<Chipaca> create still progressing, here
<xnox> right good.
<xnox> than it's just me.
<xnox> blimey 1k of packages to update, didn't touch desktop in a while.
<Chipaca> xnox: what did you need to do to make cgo cross-compile? anything?
<xnox> Chipaca: install all the build-dependencies by hand & specifying an arch for native things (e.g. libglib2.0-dev:armhf but just golang-go-linux-arm)
<xnox> Chipaca: and yes, pass environment for CC, GOPATH, PKG_CONFIG_LIBDIR, and linker
<Chipaca> xnox: so, that's the code i meant. I'll add it to the makefile (including fetching the deps and all).
<Chipaca> xnox: just probably not tomorrow :)
<Chipaca> unless it's in patch form, that is
<xnox> Chipaca: well i have patches against upstream go submitted to make that invocation more simple.
<Chipaca> ooohh
#ubuntu-devel 2014-06-11
<Fudge> any truth to roumers about a Ubuntu mate remix?
<Fudge> roumors
<cjwatson> Fudge: I've heard some noises about it, but it hasn't reached the point of people coming to the release team asking for official builds yet.
<cjwatson> I think there is some work happening on it though.
<Fudge> thanks very much cjwatson
<Fudge> we were thinking of a meta package for Vinux users who love the old Gnome2 feel but personally I like Unity
<pitti> Good morning
<pitti> Noskcaj: are iodbc and unixodbc now installable in parallel, or did Debian's psqlodbc now drop support for iodbc?
<pitti> doko_: I forwarded the unity-scope-click autopkgtest failure to dobey; seems the new gcc now emits a new warning which makes it FTBFS
<pitti> doko_: that's the one that holds back the gcc-4.0 upload, FYI
<cristian_c> Hi
<cristian_c> I was testing a wifi guide to enable the EOL repositories
<cristian_c> apt-get update is working, but apt-get install no
<Laney> doko: are you aware of gcc-doc bustage?
<cristian_c> I get many 404 not found
<cristian_c> *s
<cristian_c> Investigating, I discovered that EOL repositories are not updated
<cristian_c> I was suggested to open a bug report for these problems
<cristian_c> Can you confirm this problem and explain how to open the report in my case?
<pcarrier> hi! I've been frustrating by the gdb/ddeb experience on precise. coming from the el world, after a debuginfo-install I get source listings out of the box when inspecting core dumps
<pcarrier> am I missing something to make it work?
<pcarrier> for example, here I'm pretty sure I installed the correct version of rsyslogd-dbgsym, yet gdb doesn't find the source:
<pcarrier> #3  0x00000000004319a6 in qqueueEnqObj (pThis=0x23d6d80, flowCtlType=eFLOWCTL_NO_DELAY, pUsr=<optimized out>) at queue.c:2400
<pcarrier> 2400 queue.c: No such file or directory.
<seb128> do we have a script that does "fetch all the debs from a ppa build"?
<darkxst> seb128, as in all debs for a single package? no idea if there is a script I just do it with apt pinning
<seb128> darkxst, I don't want to use apt, typically I just want to wget/download the debs from a build page, like https://launchpad.net/~ci-train-ppa-service/+archive/landing-019/+build/6072535
<seb128> that's for local reviewing, not for installing
<darkxst> seb128, source or binary?
<shadeslayer> bdmurray: none of the issues listed on http://people.canonical.com/~ubuntu-archive/phased-updates.html against kde-workspace can be found
<seb128> hey SRU team, could anyone review unity-settings-daemon in the trusty SRU queue? it fixes an important issue with touch screen configs that the oem team would be happy to see resolved
<shadeslayer> oh
<seb128> darkxst, binaries, I get dget the .dsc for source, but e.g the url I just copied a > 10 debs
<seb128> darkxst, it's a bit annoying to click on them all and click download for each
<darkxst> seb128, pretty sure you could the urls in less than 10 lines of python, but I dont have a script
<seb128> darkxst, right, I was just asking in case we had a standard script is some devtools collection
<seb128> I'm going to write one myself otheriwse
<seb128> just trying to avoid reinventing things
<seb128> thanks for replying though ;-)
<mlankhorst> Laney: I've reviewed my code and found some more missing unlock paths, can you try  mesa - 10.1.3-0ubuntu1+ppa1 from the canonical-x/x-staging ppa?
<Laney> mlankhorst: okay, in a short while
<Laney> is this going upstream?
<seb128> bdmurray, infinity, stgraber, arges, slangasek, ..., ^ see the unity-settings-daemon ping some lines earlier, if one of you could have a look this week that would be nice ;-)
<mlankhorst> eventually
<mlankhorst> need to review it some more first
<zbenjamin> can anyone tell me what getprop "ro.product.cpu.abi" would return on a amd64 machine?
<zbenjamin> would it be also x86
<ogra_> zbenjamin, only if you have an android running on your amd64 :)
<ogra_> (i doubt there are amd64 android builds)
<zbenjamin> ogra_: i see, it will still be a 32bit build hmmm
<ogra_> what are you trying to do ?
<zbenjamin> ogra_: i need to map the devices abi to the abi inside QtCreator and right now i look for a way to find out whats the correct way
<ogra_> for the using the emulator ?
<ogra_> (i mean, do you look for the arch of the host or of the target system ? getprop will not be available on desktops, only indsie ubuntu touch VMs or real HW)
<ogra_> *inside
<zbenjamin> ogra_: for the target system
<ogra_> for that using getprop should be okayish
<zbenjamin> i could use uname i guess
<ogra_> yeah, that works for sure
<zbenjamin> ogra_: thx
<ogra_> and will even work once we have actual x86 tablets etc
 * zbenjamin --> lunch
<ogra_> (that dont use an android container)
<zbenjamin> ogra_: yeah thats what i had in mind
<zbenjamin> bbl
<ogra_> note that it wont return debian arches that way though
<ogra_> phablet@ubuntu-phablet:~$ uname -m
<ogra_> armv7l
<xnox> zbenjamin: uname returns the kernel, not the userspace abi. Uname can be amd64, yet userspace i386.
<xnox> zbenjamin: i think you want $ dpkg --print-architecture
<xnox> zbenjamin: but thanks to qemu-user-static for example I can execute armhf, i386 and amd64 binaries on my amd64 machine.
<xnox> ev: errors.ubuntu.com is not showing a graph =(
<ev> xnox: we just cut over to a new database. That will return ~tomorrow.
<xnox> ev: =( ok.
<zbenjamin> xnox: what i need is the architecture/abi i have to use to compile apps for the device
<xnox> zbenjamin: at the moment we have two: armhf (all devices + emulator) and i386 (emulator)
<xnox> zbenjamin: adb shell dpkg --architecture, will tell you the architecture device is running.
<xnox> --print-architecture that is
<cjwatson> seb128: script> citrain in phablet-tools-citrain is sort of close
<ogra_> did that land already ?
<cjwatson> Well, I have it from ppa:phablet-team/tools
<ogra_> oh, it is a separate package
<ogra_> yeah, i thought it was supposed to be merged into phablet-tools
<cjwatson> it's in utopic though
<ogra_> (it did ... but only on source level ... produces its own binary)
<ev> make experts: is there any way of having a match-anything rule that doesn't try to evaluate files? I'm trying to have a fallback rule that effectively passes an argument to another rule, so that I can do `make name.of.test.to.run`
<ev> and then a rule (with dependencies) gets executed, passing name.of.test.to.run as a command line argument
<cjwatson> does declaring the non-file-based-target in .PHONY help?
<ev> cjwatson: nope - so perhaps I'm doing something entirely wrong here: http://paste.ubuntu.com/7628766/
<ev> $@ ends up being the first file in the directory, Makefile
<jtaylor> ev: have a variable with ?=
<jtaylor> e.g. TESTS ?= $(wildcard *runfiles)
<jtaylor> make TESTS=on-ythis-file-please
<jtaylor> like regular make check
<jtaylor> automake check
<ev> yeah, I guess I could fall back to that. It just looks ugly and creates inconsistency between running ./run-tests with arguments and feeding something an env var.
<ev> but I'm already abusing make for this
<jtaylor> its not an env variable its a make variable
<ev> indeed
<mlankhorst> Laney: ping? :P
<Laney> not yet sorry
<pitti> cjwatson: is there something like "click uninstall", or is that simply "sudo rm -r /opt/click.ubuntu.com/com.ubuntu.calculator/" ?
<pitti> I found "unregister --all-users", but that's not the same
<ogra_> pitti, adb shell click unregister --user=phablet $PACKAGE
<cjwatson> pitti: unregister
<doko> dobey, could you have a look at https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/lastBuild/?  not sure if pitti already told you
<cjwatson> Don't just do rm -r, you'll leave bits behind
<seb128> cjwatson, thanks
<pitti> cjwatson: I tried that (with and without --all-users), it still leaves /opt/click.ubuntu.com/com.ubuntu.calculator/* behind
<pitti> that just hides it
<cjwatson> pitti: in general that depends whether the app is running
<cjwatson> it should get GCed eventually; normally, don't worry about it
<pitti> cjwatson: ah, ok; thanks!
<cjwatson> --all-users likely isn't what you want unless it was registered with --all-users to start with
<pitti> cjwatson: I don't know how it was registered; it's installed by default
<pitti> cjwatson: use case: for testing a local .click I wanted to ensure that no other version is installed, and then click install that one; but perhaps I don't need to do that cleanup
<cjwatson> you don't
<cjwatson> any user-installed version will override things installed by default
<cjwatson> the installed-by-default stuff will be in /usr/share/click/preinstalled/, not /opt/click.ubuntu.com/, and it is generally not possible to remove those (unless the image is writable)
<cjwatson> so we don't try, we just hide it
<cjwatson> but anyway the structure of the database makes that sort of care unnecessary
<cjwatson> https://click.readthedocs.org/en/latest/databases.html FWIW
<pitti> hmm; apparently I managed to actually remove /opt/click.ubuntu.com/com.ubuntu.calculator/1.3.279/ (as on current image), but still have 1.3.277/ (my local install), and now can't unregister/remove the latter
<pitti> cjwatson: thanks
<cjwatson> look through /opt/click.ubuntu.com/.click/, there might be a @gcinuse thing somewhere
<pitti> ah, 276 was in the image, 279 came as an app update
<cjwatson> in any case, it isn't supposed to matter - the version that's actually used is looked up dynamically in the .click directories
<cjwatson> stray versions are allowed to hang around a bit
<dobey> doko: yes. will have a fix in a few minutes
<zbenjamin> xnox: thx
<rbasak> infinity: ping, re: juju-core powerpc ftbfs
<infinity> rbasak: Yo.  I'm still trying to get to the bottom of it.  But, as I said yesterday, why should a utopic FTBFS be holding up trusty in any way?  We already know it builds on trusty.
<rbasak> Sorry, I must have missed your reply.
<rbasak> I wanted Fix Released status in Utopic for an SRU to Trusty. But I guess having it in utopic-proposed is enough?
<infinity> rbasak: Having it in proposed is enough.
<infinity> rbasak: The point of that rule isn't that development users are more important and must get the fix first, the point is for the fix to not get lost/forgotten in the devel release.  Uploaded, or even commited to a branch that you guarantee will get uploaded, is good enough.
<rbasak> OK, thanks. I'll work on the SRU.
<ogra_> did we switch the compiler default to 4.9 already ?
<hallyn> xnox: hey, you're DD right?  Would you mind taking a look at http://people.canonical.com/~serge/netcf-src-0.2.4/netcf_0.2.4-1.dsc and potentially sponsoring it?
<hallyn> xnox: normally ahs3 uploads for me but he's swamped with real life
<xnox> hallyn: sure.
<hallyn> xnox: thanks!
<ricmm> ogra_: lemme know if I missed the reply
<xnox> hallyn: i need to sprint somewhere with you, to get keys cross-signed.
<ogra_> doko, did we swithc the compiler default to 4.9 already ?
 * xnox hasn't seen verification failed in a long time.
<ricmm> xnox: hey, are we using 4.9 by default in u now?
<ricmm> or doko
<xnox> ogra_: ricmm: i believe we use 4.9 by default from now on. Let me find out when that happened.
<ogra_> must have been very recent
<xnox> ogra_: it's about a month late.
<xnox> ricmm: older compilers are still available and you can choose to use an older one.
<hallyn> xnox: are you going to be at linuxcon chicago or plumbers dusseldorf?
<xnox> ogra_: as off 2 hours ago.
<ogra_> hah !
<hallyn> anyway come up with a pretext i love to sprint :)
<ogra_> ricmm, so that might be your prob :)
<ricmm> it is indeed
<ricmm> I just checked, the first failing build is using 4.9
<ricmm> instead of 4.8
<ricmm> boom headshot
<ricmm> I'm never landing my stuff
<ogra_> oh my
<xnox> slangasek: ^ can i go to linuxcon chicago or plubmers dusseldorf? Or have a cloud vs core stand-off sprint =)
<cjwatson> as he said you can Build-Depends: gcc-4.8 and set CC=gcc-4.8, or similar
<ogra_> right
<xnox> ricmm: build-depend on gcc-4.8 set 4.8 compiler. Or give me the build failure and maybe i can fix it for you?
<cjwatson> though clearly this is technical debt
<slangasek> xnox: ... to get keys cross-signed with hallyn?
<xnox> ricmm: what's the build log?
<ogra_> cjwatson, just that this needs a change of the MP and means re-testing everything again
<xnox> slangasek: yes.
<cjwatson> ogra_: sure
<ricmm> xnox: this is a tough header-based thing with dbus-cpp
<ricmm> its not a build failure, its a runtime hashtable explosion
<xnox> ricmm: that's fine, what's the build failure? =)
<ricmm> so maybe an ABI break somewhere
<ogra_> cjwatson, ricmm is only trying to land that since 4 weeks :P
<slangasek> xnox: try to be more circumspect about your motives
<ogra_> it was done today :)
<cjwatson> ogra_: this isn't really a helpful line of argument ...
<ricmm> there is no argument, forget about it all
<ogra_> not a line of argument at all ...
<xnox> ricmm: i believe dbus-cpp is compiled with 4.7, maybe we need to recompile dbus-cpp with 4.9
<ogra_> just a comment
<ricmm> I'll have this thing work 4.8 and bye bye
<ricmm> dbus-cpp is 4.8
<ricmm> probably will need a recompile yea
<ricmm> I'll figure it out dont worry
<ricmm> just wanted to know when the change had happened
<ricmm> to confirm
<ricmm> thanks
<hallyn> lol.  xnox: slangasek ain't gonna go for that one :)
<hallyn> xnox: i bet we can come up with very good reasons.  systemd.vs.cgmanager.vs.lxc comes to mind
<hallyn> which is very much inplay at both linuxcon and plumbers, in fact
<cjwatson> ricmm: perhaps this is simply that dbus-cpp is hardcoding 4.8 and something built on it is failing to hardcode 4.8 and was assuming that default gcc == 4.8
<cjwatson> or something like that
<hallyn> mdeslaur: stgraber: (zul:)  if no objections i'll push http://paste.ubuntu.com/7629496/
<mdeslaur> hallyn: fine with me
<hallyn> mdeslaur: on the topic, are you actively working on the $)(*&)%(* required for virt-manager merge, or are we all just hoping someone else does it?  :)
<hallyn> i'll try to look into it assuming you do not have time.
<hallyn> or, that's right, you were mentioning something new that may be easier to have ppl switch to?
<stgraber> hallyn: LGTM
<hallyn> thx, pushing
<mdeslaur> hallyn: I've done it, it's just that there are a zillion MIR bugs to file
<hallyn> mdeslaur: right, that's waht i meant
<mdeslaur> hallyn: give me a couple of days, and I'll take a look
<hallyn> although,
<hallyn> virt-manager isn't in main is it?
<mdeslaur> yeah, it is
<hallyn> egads
<mdeslaur> right
<mdeslaur> might be easier to demote it :P
<hallyn> ok - thanks, happy to wait :)
<hallyn> yes,
<mdeslaur> is it part of anything strategic that we ship?
<hallyn> i'm not sure anyone uses it on server anyway...
<hallyn> not that i know of
<mdeslaur> ok, I'll look into that possibility too
<hallyn> jamespage: smoser: ^ do you know if virt-manager needs to be in main for any particular reason?
<hallyn> the only thing rdepending on it is ubuntu-virt-mgmt :)  which sounds like a bogus metapackage
<hallyn> oh and is in universe anyway
 * sarnold weighs how many MIRs might be needed vs having a simple bloody tool that can show which VMs are actually running...
<smoser> hallyn, i dont have a good reason off the top of my head
<hallyn> sarnold: simple tool like xterm -e "while :; do virsh list; sleep 5m; done"
<hallyn> :)
 * sarnold hugs hallyn 
<hallyn> lol
<rbasak> hallyn: you know about watch, right? "watch -n300 virsh list"
<hallyn> i do
<hallyn> but what can i say i like manually looping
<rbasak> You like doing what? :)
<sarnold> the man likes to control his own loops
<sarnold> he'd have used goto except shell makes that hard :)
<doko> ricmm, what exactly is the issue? didn't see a reply when xnox or ogra_ were asking
<ogra_> doko, dbus-cpp is compiled against 4.7 or 4.8
<ogra_> that caused a bunch of build issues now
<doko> ogra_, and why is this an issue?
<ogra_> dunno ... they are working on porting it now ...
<xnox> doko: no reply either.
<ogra_> (no worries, it was just the info that the default switched that was important )
<xnox> ricmm: can you please give us projects which need fixing?
<xnox> ricmm: doko and I, are both from foundations team and we are ultimately responsible to get all packages fixed for 4.9.
<ogra_> xnox, silo 007
<ogra_> rebuilding the location-service FTBFS due to dbus-test-runner timing out
<ogra_> xnox, doko, seems a simple rebuild of dbus-cpp fixes everything ... it was just that nobody was aware the default had changed
<doko> ogra_, xnox: it's suspicious that a simple rebuild fixes things ...
<ogra_> well, dbus-cpp is special :)
<doko> dobey, thanks for the fix
<dobey> no problem :)
<pitti> jcastro: hey! so I'm trying "juju quickstart" as in your tutorial, as that looked really nice; I get http://paste.ubuntu.com/7630057/ and now it's just hanging
<pitti> jcastro: and no running wget; any idea how I can check what's going on?
<jcastro> pitti, can you ping frankban on #juju-gui? Marco and I are in the middle of another session
<pitti> jcastro: strace is just in an endless futex wait
<pitti> jcastro: sure, thanks
<xnox> tedg: !!!!
<tedg> ?
<xnox> tedg: oh, surprisingly it wasn't you this time =)
<xnox> tedg: indicator-datetime adding a semi-bogus recommends =)
<tedg> ?
<xnox> bug 1309063
<ubottu> bug 1309063 in Indicator Date and Time "It's confusing to use the Incoming Call sound for Alarms" [Medium,In progress] https://launchpad.net/bugs/1309063
<xnox> pulls in ubuntu-touch-sounds
<xnox> into all instalations of indicator-datetime => everywhere
<tedg> xnox, not sure that's a bad thing? how else would we ensure we had an alarm sound?
<xnox> tedg: indicator-datetime does alarms on xubuntu & unity7 ?!
<xnox> tedg: and it should fallback to the desktop sound theme -> thus get alarm sound from the theme
<xnox> not a file on disk
<tedg> xnox, I believe the issue there is that the mechanisms on the phone aren't theme aware.
<tedg> xnox, And we will do alarms if someone uses that Ubuntu SDK to set them.
<xnox> k, cool.
<xnox> weird, i thought sounds came from the same themeing capability as icons.
<xnox> and i thought we do have that in the sdk -> well, pure qt
<tedg> xnox, It's similar, but just a matter of programming :-)
<slangasek> ricmm, doko: bug #1329089 filed
<ubottu> bug 1329089 in gcc-4.9 (Ubuntu) "g++-4.9 binary incompatibilties with libraries built with g++-4.8" [Critical,New] https://launchpad.net/bugs/1329089
<slangasek> ricmm, doko: I think I'm going to revert the gcc-defaults change, until we have a handle on the cause of this incompatibility
<infinity> slangasek: You'd think that if this was a fundamental ABI breakage issue, we'd have seen it in a lot of testsuite during the 4.9 rebuild tests, since most of them would have been running against 4.8-built libraries.
<infinity> slangasek: Is it possibly that dbus-cpp itself is just doing something Very Bad?
<slangasek> infinity: interestingly we've turned up that at the time of the archive rebuild, several of these components were hard-coded to use a different compiler /earlier/ than 4.8
<slangasek> so it's possible that this was a 4.8-specific ABI breakage
<infinity> slangasek: Or possible that these components are somehow crazy. :P
<slangasek> you don't blame the python script when the interpreter segfaults, and you don't blame the library when the ABI output by the compiler changes
<infinity> slangasek: You do when the library does things against spec that intentionally break its ABI, but yes, point taken.
<doko> slangasek, so is there anybody available from the phone team who can tell what the failing test is supposed to test?
<slangasek> doko: ricmm might be able to; but I know this was holding up a stalled landing, so he's been busy working around it on his side and may not be in a position to discuss it right now
<infinity> slangasek: dbus-cpp is tvoss's baby, isn't it?  Maybe he could shed some light on if it's doing something naughty with C++ that it shouldn't.
<slangasek> infinity: in an appropriate timezone, probably
<slangasek> in the meantime, I've reverted the default compiler to 4.8, so we're not under time pressure
<infinity> You bumped the epoch instead of just mangling versions?  Fun.
<infinity> I guess that's easier than making gcc_4.8 depend on gcc-4.9
<infinity> Err, other way around.
<doko> well, bumping the epoch should be a no-go
<infinity> doko: It's already been done.
<slangasek> doko: how does that follow?
<slangasek> or rather: what would you expect to do in a revert if not an epoch?
<doko> because any synced versioned deps will be meaningless in ubuntu from now on
<cjwatson> the +really convention is less intrusive
<cjwatson> less permanently intrusive I mean
<doko> slangasek, just change the dependencies
<cjwatson> do we have time to undo the epoch with archive hackery?  that's kind of scary
<slangasek> cjwatson: sure, but much more error-prone for a metapackage that munges the binary version numbers of each individual binary at build time
<infinity> It's still in proposed, we could thwack it.
<slangasek> doko: as the Debian maintainer, why would you not just bump the epoch in Debian too?
<slangasek> it already has an epoch there
<slangasek> it's not like revving the epoch would cost you anything
<cjwatson> I've stopped p-m so that we have time to finish this discussion
<slangasek> cjwatson: thanks
<cjwatson> will block gcc-defaults now, this was just quicker
<slangasek> fwiw I don't like the idea of either +really, or having a mismatch between the binary package version and the compiler version it depends on; I think the epoch is least-bad here
<cjwatson> I don't object to the epoch if doko accepts it in Debian but I think that Ubuntu-specific epoch changes should be avoided at nearly all costs
<infinity> slangasek: The epoch is least bad, long-term, but I assume this is only a day-or-two-long solution while we hunt the issue.
<infinity> And for a couple of days, ugly version tricks seem to make more sense.  But meh.
<cjwatson> ok, gcc-defaults blocked, p-m unstopped
<slangasek> infinity: again, error-prone
<doko> I'll look at fixing the dependencies now
<cjwatson> surely only "error-prone" in gcc-defaults' own build process, and that doesn't take long to check
<slangasek> doko: ok, if you want to own this, I defer to you
<slangasek> doko: though if you wanted to just agree to revving the epoch in Debian, you could go to sleep instead ;)
<doko> I do not want to ... but it looks I'll have to if I do not want to bump the epoch
<slangasek> why do you object to bumping the epoch?
#ubuntu-devel 2014-06-12
<cjwatson> feel free to remove my block if you folks reach consensus, or update it as necessary ... I'm off to bed shortly
<cjwatson> oh, hell, blocks is unversioned
<infinity> cjwatson: Luckily, a versioned block doesn't fail to block, but completely crashed britney!
 * cjwatson updates
<infinity> ("luckily")
<slangasek> hah
<cjwatson> infinity: feature
<infinity> s/crashed/crashes/
<slangasek> /failsafe/, n.:
<doko> slangasek, infinity, cjwatson: please lets go with this: http://paste.ubuntu.com/7631134/
<slangasek> ok
<infinity> doko: WFM.
<infinity> We'll need to delete the old one before you upload.
<infinity> Doing that now.
<doko> ok
<infinity> doko: I assume you test-built locally and checked gcc/g++/cpp binaries for sanity?
<doko> yes, installed these using a dist-upgrade
<infinity> doko: Alright.  Should be safe to upload now, I think.  If I'm wrong, the binaries will reject, and I can retry later when it's definitely safe. :P
<infinity> doko: When the fresh builds are done, I'll give them a once-over here too, and then undo Colin's block.
<doko> infinity, i386 upload was rejected
<doko> old packages still in the archive
<cjwatson> It's possible you'll have to build them in a PPA and copy back
<infinity> doko: I'll sort it out.
<cjwatson> But we'll see once the publisher processes the deletions
<infinity> cjwatson: Nah, the publisher just raced.
<doko> ok, I'm afk now
<infinity> cjwatson: It published the binaries after I deleted, and had a sad, I imagine.
<infinity> cjwatson: Happened for armhf too, and those were the two arches that published this cycle.
<infinity> So, next cycle should clear it up.
<infinity> I think.
<cjwatson> OK, so a retry later will clear it?  OK.
<infinity> Should do.
<infinity> If not, there's a pretty icky soyuz bug here.
<cjwatson> Too late, I'm at my quota of soyuz bugs fixed today
<infinity> Heh.
 * wgrant reads scrollback
<infinity> wgrant: Highlighting on "soyuz bug"?
<wgrant> soyuz in general, IIRC
<infinity> wgrant: Anyhow, probably just a misfeature not a bug.  We'll see after another publisher run.
<infinity> wgrant: 4/6 arches were published, 2 were accepted, I deleted the source, publisher ran, published the 2 outstanding, and those 2 caused reject clashes for the new upload.
<infinity> wgrant: My assumption is that the next publisher run will clean them up.  Or maybe I'll have to delete harder. :P
<wgrant> infinity: It won't require a publisher. You probably need to re-delete.
<wgrant> You probably deleted it before process-accepted ran
<wgrant> So the binaries didn't exist to be deleted yet.
<infinity> wgrant: Kay, so those binaries live on forever now without a second deletion?  That does seem like a bit of a bug.
<infinity> (ie: the pending pubs should have been deleted too...)
<infinity> But I'll re-delete.
<wgrant> infinity: There are no pubs until process-accepted runs; that's the problem.
<wgrant> mumble soyuz redesign mumble
<infinity> Deleted harder.
<wgrant> infinity: I'd check the DASBP pages to be sure.
<infinity> That means remembering how to navigate to the page I can never find.
<wgrant> I think cjwatson knows
<wgrant> But it has the best URL in Launchpad
<infinity> https://launchpad.net/ubuntu/utopic/i386/cpp
<infinity> That'll do.
<wgrant> Yep
<wgrant> I think I managed to click through to it once.
<wgrant> Only once.
<infinity> I just did.
<infinity> Well, sort of.
<wgrant> On-screen keyboards don't count.
<infinity> I got to https://launchpad.net/ubuntu/utopic/i386/cpp/5:4.8.2-5ubuntu4 from the build record, and then stripped the version by hand.
<infinity> I'm not convinced you can get there completely with clicks.
<wgrant> infinity: See the "Package relationships" section
<wgrant> And the breadcrumbs.
<infinity> wgrant: Okay, so if I found something else that depended on cpp, I could navigate to it.  That doesn't count. :P
<wgrant> infinity: Breadcrumbs on that page get you straight there!
<wgrant> DistroArchSeriesBinaryPackageRelease is finally useful for something :)
<infinity> wgrant: The breadcrumb, indeed.
<infinity> wgrant: SUPER INTUITIVE.
<wgrant> I'm disappointed that it wasn't DistributionArchitectureSeriesBinaryPackageRelease
<infinity> Alright, deleting with extra violence cleared up the binary rejects.  We're good to go.
<infinity> And a quick once-over of the resulting binaries appears sane.  As sane as 4.9 depending on 4.8 can be.
<infinity> So, I shall unblock.
<infinity> (base)adconrad@cthulhu:~/build/britney/hints-ubuntu$ bzr u
<infinity> bzr: ERROR: unknown command "u"
<infinity> Martin missed a golden opportunity there to respond with 'No, U!"
<RAOF> infinity: So, what would bzr U do? :)
<infinity> RAOF: Something to "your mom", I imagine.
<pitti> Good morning
<Unit193> Howdy.
<seb128> bdmurray, I don't understand that email telling that the evince SRU to trusting has an increase in bug reports, the url in the email gives a "no data to display" page on e.u.c
<seb128> shrug
<seb128> e.u.c seems to not be working properly
<seb128> ev, bdmurray: hey, ^ ... e.g https://errors.ubuntu.com/?release=Ubuntu%2014.04&package=nautilus&period=year ... it tops to 500 then 80 reports, on the year view, we have bugs with > 80 reports a day on the daily view since release, those numbers are wrong
<seb128> same on other sources
<seb128> e.g I tried evince or unity-control-center
<seb128> like picking the week view gives the same numbers
<ev> seb128: we cut over to a new database. All the reports you are seeing are new as of yesterday
<tvoss> infinity, ping
<tvoss> doko, ping
<seb128> ev: did we loose history? :-(
<ev> seb128: this is part of a plan to reunify the previous databases and upgrade us to cassandra 2.0
<ev> nope, we still have everything
<ev> it's just warehoused
<doko> tvoss, evil dbus-cpp pong
<seb128> ev, k, is it going back to the e.u.c frontend?
<seb128> ev, also, is that what creates the issue I was mentioning to bdmurray a bit before that ping? I got an email since that the evince SRU is blocked because there has been an increase in reports with that version
<seb128> ev, is that because the system has no old record, consider there was no bug, and see new ones for the SRU that got copied yesterday, and assume the trend shows a regression?
<infinity> tvoss: What doko said.
<tvoss> infinity, happy to learn what my mistake is :) the offending class is http://bazaar.launchpad.net/~phablet-team/dbus-cpp/trunk/view/head:/include/core/dbus/message_router.h
<tvoss> infinity, the mutex member causes the issues, both for 4.7 -> 4.8, and for 4.8 -> 4.9
<tvoss> not sure why, though
<infinity> tvoss: My C++ is weak, but doko might have some ideas?
<tvoss> infinity, doko is looking into it, sent him a pm in German :)
<Laney> es ist kaputt
<infinity> tvoss: I'd love to come to an agreement that this is a dbus-cpp bug, and fix it there, but there's always the possiblity that you've found a compiler bug with your clever abuse of the language.
<tvoss> infinity, I'm abusing the language at itmes, yes. Not in this particular case, though
<tvoss> if the std::mutex and std::lock_guard abi is stable, this should cause issues
<tvoss> shouldn't, obviously
<ev> seb128: just trying to dig you up some background material
<infinity> tvoss: mutexex might invoke static inlining that isn't guaranteed stable.  Though that would seem unfortunate.
<infinity> tvoss: Anyhow, wild speculation from me at 3am isn't worth anyone's time.  I'll let you and doko argue with it.
<seb128> ev, no hurry, I'm afaik for a bit, I'm mostly interested in knowing how I get my SRU unflagged as increases errors when it doesn't (the url in the email gives a "no data to display" e.u.c)
<tvoss> infinity, well, sure, at which point I'm happy to hide it in the impl. But: I would like to understand why the abi obviously isn't stable
<ev> seb128: *nods* I'm afraid I don't know the answer to that. bdmurray and I believe slangasek were looking into how we handle phased updates with this temporary change
<seb128> ev, ok, thanks, I'm waiting for them to be online then
<ev> seb128: so right now we have the data living in three separate clusters. Over the next few months we'll be pulling these together in the background, doing a bit of repair to tidy up counters and other things that don't merge so easily, and then cutting over to this Cassandra 2.0 version of the database.
<ev> Nothing will be lost, but this was needed as webops got painted into a corner by running out of disk space as part of an attempt to purge unneeded data.
<ev> It also brings a lot of improvements around storage size (compression by default, which makes it faster as well), ability to run big queries over the entire db more efficiently (the new client apis have knowledge of what nodes own which token ranges and split that across threads), and our ability to grow and manage the database nodes
<ev> sorry I couldn't be of more help on the phased updates stuff
<Laney> doko: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1328838
<ubottu> Ubuntu bug 1328838 in apt (Ubuntu) "Can't x-build ubuntu-system-settings with 1.0.4ubuntu1: /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'" [Undecided,New]
<Laney> please look at that and see if you think it could be the same thing
<mvo> doko: thats probably a dupe of #1329089
<Laney> I mention it partially because of the attempts to lay the blame on dbus-cpp. :)
<mvo> Laney: oh, sorry I missed that bit
<doko> mvo, do you know why this is the same issue?
<doko> or is this guessing?
<mvo> doko: just guessing
<doko> mvo, the please undo the duplicate
<mvo> doko: done
<tvoss> doko, what is our rebuild policy if the toolchain changes? Do we rebuild the world?
<doko> tvoss, no, only for ABI changes. and until now I can't find any intentional ones ...
<doko> Laney, what does ldd say about /usr/lib/arm-linux-gnueabihf/libapt-pkg.so ?
<Laney> which version?
<doko> e.g. libstdc++
<doko> the one you mentioned in the bug report
<tvoss> doko, reading https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html right now
<tvoss> doko, outstanding issues explicitly says: "Because of this, mixing C++ ABIs is not recommended at this time."
<tvoss> doko, and I think that is the case we are hitting right now
<doko> Laney, which cross compiler did you use?
<Laney> doko: whatever I get when I do sbuild --host=armhf foo.dsc
<doko> so 4.8
<Laney> oh you mean which version, yes
<doko> tvoss, that's why I'm fighting versioned build dependencies on g++ like in dbus-cpp ...
<tvoss> doko, the versioned build-dependency has gone
<tvoss> doko, we upgraded everything to latest
<tvoss> doko, including the platform api
<Laney> 	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6d53000)
<doko> does it have a dep on libstdc++ (>= 4.9)? I assume not ...
<Laney> but I guess it could be this problem tvoss mentions if the cross toolchain is behind the native one
<Laney>  Depends: libbz2-1.0, libc6 (>= 2.15), libgcc1 (>= 1:4.4.0), liblzma5 (>= 5.1.1alpha+20120614), libstdc++6 (>= 4.9), zlib1g (>= 1:1.2.3.4)
<doko> hmm
<xnox> hm.
<doko> well, wanted to wait with the cross toolchain updates ... but looks I should start with this ...
<ricmm> there is no versioned build dep accross our components, as tvoss said
<ricmm> we removed all of that a bit over a month ago
<ricmm> do you think the archive needs a run of stdc++s reverse build deps to rebuild? that sounds painful
<cjwatson> last resort
<doko> well, I think for most cases it is not needed. I'd like to find out what exactly did cause the issue for dbus-cpp
<tvoss> cjwatson, admittedly, but: even the gcc guys themselves advice against mixing ABIs
<cjwatson> mixing ABIs isn't strictly the same as mixing compiler versions
<tvoss> cjwatson, sure, but I think it strikes in this case
<infinity> tvoss: That same page you pointed at also notes the painstaking effort made to make sure libstdc++ is backward-compatible, mind you (unless configured for an ABI break).
<cjwatson> and my point is investigate first, don't sweep it under the carpet with a rebuild.
<tvoss> cjwatson, I'm all in for that
<cjwatson> we can talk about what rebuilds are needed (and how to make sure that partial upgrades work, etc.) AFTER investigating the root cause.
<tvoss> infinity, sure, but: the warning is put there for a reason. I'm not saying it always breaks, just that we should be mindful
<cjwatson> we aren't going to rebuild everything C++ on every toolchain change
<cjwatson> just not happening :)
<tvoss> cjwatson, sure, I just would like to understand what prevents us from doing so in theory
<doko> $ apt-cache rdepends libstdc++6|wc -l
<doko> 5695
<cjwatson> and hasn't been necessary in the past as a general rule; there have been some events where it has been necessary to rebuild some things
<cjwatson> rebuilding frivolously is expensive
<cjwatson> both for us and our mirrors
<tvoss> cjwatson, tracking down build issues and weird behavior is expensive, too. Just saying that it is a balance
<cjwatson> and if there really is an ABI event then we have to do more than rebuild; we'd probably have to change package names and so on
<cjwatson> this is peanuts compared to the cost of rebuilding 5000 packages
<cjwatson> I don't think you appreciate the scale there
<ricmm> lukasz is saying in another channel that they saw issues with the OSK
<ricmm> between 4.8 -> 4.9
<ricmm> so, there are stones unturned that might only show up as bugs
<ricmm> that people wont be able to diagnose
<ricmm> sil2100: ^
<doko> OSK?
<cjwatson> on-screen keyboard
<sil2100> In case of ubuntu-keyboard these were FTBFS issues, so nothing serious
<tvoss> cjohnston, I surely appreciate the scale
<tvoss> cjwatson, even :) I surely appreciate the scale
<cjwatson> we have done C++ ABI changes in the past, but only after we understood exactly what was causing them
<cjwatson> package name changes and rebuilds in response to ABI changes I mean
<cjwatson> and such things need to be synced with Debian
<tvoss> cjwatson, doko a question though: under the assumption that the c++ abi for 4.8 -> 4.9 did not change, and the ABI of dbus-cpp didn't change (as there was no upload to it), why would anything break at all?
<cjwatson> obviously it needs to be investigated
<cjwatson> my point is precisely the opposite of let's ignore ABI breaks
<infinity> tvoss: If, as you note, you saw this from 4.7 to 4.8 as well, I feel this is something more subtle than your run of the mill ABI break.
<cjwatson> but rebuilding everything C++ is a lot of expense that could maybe be avoided by root-causing the ABI change
<infinity> (And we clearly didn't have to rebuild half the archive for that switch)
<doko> tvoss, I don't know yet. so starting with obvious things, mayb start testing for class sizes, offsets, etc ...
<cjwatson> infinity: IIRC that was a C++11 specific thing
<cjwatson> and hardly anything uses that yet
<cjwatson> reading https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html in more detail - I think it's fairly clear from that page that the C++ ABI it's talking about is that controlled by -fabi-version, other ABI-affecting compiler options, and configure options used when building libstdc++; not simply changing version, because it has clear tables of versions, interfaces they provide, and compatibility between them.  There's certainly scope ...
<cjwatson> ... for problems there, but it is obviously intended to be backward-compatible except where explicitly indicated otherwise, and where backward-incompatibility isn't indicated we should dig into it and raise with upstream as necessary rather than assuming that it's a lost cause and rebuilding the world.
<tvoss> cjwatson, sure, I'm not arguing that gcc version change results in abi changes (not necessarily breaks)
<tvoss> instead I'm saying that it should raise awareness, and that we might want to thing about tooling to catch issues with the ABI in version change cases
<tvoss> s/thing/think/g
<xnox> dbus-cpp comes with an std c++11, yet libstdc++ is probably (didn't check)  built with c++98, and there is a mention that complex::{imag,real} would be affected (cause abi incompatibility) unless it gets inlined.
<doko> xnox, libstdc++ is build for both
<cjwatson> libstdc++ has to be built for both otherwise c++11 wouldn't work at all, I expect
<xnox> ok.
<xnox> meh, checked mutex classes/headers and it well, obviously, doesn't use complex numbers to do mutexes. so yeah futile.
<seb128> cjwatson, I guess that restricting the architectures set for ubuntu-system-settings to "amd64 armhf i386" would make the world unhappy through the u-s-s-online-accounts/online accounts stack, right?
<cjwatson> seb128: Yup
<seb128> :-/
<Laney> I suppose it can be made conditional in one way or another
<seb128> k, need to way for mterry then
<Laney> the build-dep
<seb128> yeah, we could disable the wizard build on the other archs
<Laney> Either avoid whatever functionality or make the wizard a compile-time option
<seb128> cjwatson, just for context, we are discussing https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675 which added a build-depends on libunity-mir-dev, which is only available on a limited archs set
<cjwatson> making that part of it conditional seems reasonable
<cjwatson> until we get unity-mir ported
<seb128> right
 * seb128 commented on the bug, waiting for mterry to get online to discuss it more
<seb128> cjwatson, Laney: thanks
<seb128> bug->mr
<xnox> pitti: apw has tried running with systemd yesterday and his lightdm doesn't come up and he gets dropped to tty1
<apw> pitti, yeah it is reliable i've rebooted 3-4 times and it occurs each time
<pitti> xnox, apw: anything in sudo systemctl status lightdm ?
<xnox> bug 1329056
<ubottu> bug 1329056 in lightdm (Ubuntu) "lightdm does not start under systemd" [Undecided,New] https://launchpad.net/bugs/1329056
<apw> it was saying something (dead)
<xnox> pitti: that was inactive (dead) or somesuch
<pitti> no log?
<apw> i am about to reboot
<apw> pitti, where would i find the said log
<xnox> pitti: there is a tarball of hist jobs, but i was not entirely sure how to debug what he is experiencing.
<pitti> apw: if it attempted to start, but failed with an error, it would be in systemctl status
<pitti> the attached logs on that bug look like being from older/manual runs
<xnox> pitti: how would one check if e.g. multi-user target was reached? and/or list everything that failed?
<apw> pitti, http://paste.ubuntu.com/7633248/
<xnox> maybe apw has more things failing that are needed to run lightdm....
<pitti> xnox: systemctl status shows all successes and failures (at the bottom)
<apw> pitti, http://paste.ubuntu.com/7633249/
<pitti> oh, no plymouht at all?
<apw> i believe i saw plymouth
<apw> though i'd have to reboot to be 100% sure
<pitti> no trace of it in that log
<pitti> anyway, it's only an After=, not a Requires=
<apw> pitti, ok, i defniatly see plymouth, i have purple, black, purple with ubuntu logo and dots, black VT1
<xnox> apw: is your plymouth started from initramfs, and not from rootfs? as in do you use encrypted root?
<pitti> apw: i. e. "systemctl start lightdm" works? or how did you start it manually?
<apw> xnox, i don't use encrypted root, but i do use encrypted disks do i have the tools installed, but i thought you fixed that not to install them in the initramfs
<xnox> you should have some plymouth units
<apw> pitti, yes systemctl start lightdm works just fine
<apw> xnox, and if they have plymouth in their name, i do not
<apw> xnox, ok there is a heap of plymouth in my initramfs, i thought you had fixed that
<apw> to not be in there if i didn't use root encrypted
<pitti> multi-user.target - Multi-User System
<pitti>    Loaded: loaded (/lib/systemd/system/multi-user.target; disabled)
<pitti> "disabled" - interesting
<apw> can i poke that one more?
<xnox> apw: other hooks may pull in plymouth into the initramfs, crypto is just one of them.
<apw> xnox, ok perhaps we can investigate that later :)
<xnox> apw: if uninstalling cryptsetup and regenerating initramfs removes plymouth, there is a bug in my logic.
<apw> pitti, is it me or is that both disabled and active ?
<xnox> apw: or quicker to check if you have "overlayroot" package installed.
<pitti> ah, looks the same here, so nevermind
<apw> dpkg-query: no packages found matching overlayroot
<apw> (is there a more specific cannel for ubuntu systemd we should be using?)
<xnox> apw: this is as best as it gets
<xnox> apw: we can use #ubuntu-kernel if you preffer that =)
<xnox> but pitti doesn't idle there
<pitti> graphical.target is also active
<xnox> apw: i hear that kernel & systemd are about the same thing, and may only ever be upgraded in lock-step.
<pitti> apw: ls -l /etc/systemd/system/graphical.target.wants/lightdm.service ?
<xnox> pitti: i don't have that.
<apw> pitti, i dont have that either
<pitti> hm, that must be a leftover from some intermediate experimentation then
<apw> i presume systemd is meant to run in initramfs as well, from its command set
<xnox> apw: yes.
<xnox> apw: well run in "dracut", not just any initramfs.
<pitti> we don't want that for now
<pitti> phone, brb
<mardy> seb128: do you think you could spend some minutes to test the silo 017?
<mardy> seb128: me and dbarth are testing it, but we are not sure whether it's behaving correctly (it about signon-ui-x11 and u-s-s-o-a coinstallation)
<rsalveti> pitti: do you know how I can test incoming calls with phonesim? want to reproduce a ringtone issue that happens when getting an income voice call, but want to see if I'm able to reproduce using a tablet
<mardy> seb128: the obsolete package "signon-ui" is not getting removed when we apt-get the new packages, so the installation of the new packages fails
<pitti> rsalveti: yes, phonesim has some magic numbers which cause a callback: http://bazaar.launchpad.net/~phablet-team/dialer-app/trunk/view/head:/tests/autopilot/dialer_app/tests/test_calls.py#L120
<rsalveti> pitti: cool, will try that, thanks
<pitti> rsalveti: in particular, 199 (http://bazaar.launchpad.net/~phablet-team/dialer-app/trunk/view/head:/tests/autopilot/dialer_app/helpers.py#L48)
<seb128> mardy, hey, sure I can have a look ... do you have a pastebin of the command/log/error?
<mardy> seb128: http://pastebin.ubuntu.com/7633228/
<mardy> seb128: no, sorry, that was wrong
<seb128> mardy, why do you try to install signon-ui if it should be removed?
<mardy> seb128: actually, what I get is:
<mardy> The following packages have unmet dependencies: signon-ui-x11 : Conflicts: signon-ui
<mardy> E: Unable to correct problems, you have held broken packages.
<mardy> seb128: ^
<mardy> seb128: I'm just using citrain-slurp
<seb128> mardy, what command give you that?
<mardy> seb128: but maybe that command does not behave well and I should just dist-upgrade instead?
<seb128> mardy, what about "sudo apt-get install signon-ui-x11 ubuntu-system-settings-online-accounts signon-ui-service"
<mardy> seb128: same error
<dbarth> i can try dist-upgrade
<dbarth> but that doesn't tell me that ussoa is involved
<xnox> mardy: how is the package rename done? can i check if the packaging was done correctly?
<mardy> xnox: sure, let me dig up the MPs
<seb128> mardy, the provides might be an issue
<seb128> since you B on signon-ui (<< ) and provides are not versionned
<seb128> xnox, https://launchpadlibrarian.net/176993740/signon-ui_0.16%2B14.10.20140530-0ubuntu1_0.17%2B14.10.20140605-0ubuntu1.diff.gz
<seb128> mardy, ^
<mardy> xnox: https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/signon-ui-service/+merge/222016 and https://code.launchpad.net/~mardy/signon-ui/signon-ui-service/+merge/222017
<seb128> mardy, the issue, I think is that  signon-ui-x11 provides signon-ui, or you make -service conflicts with that one
<seb128> well with << 0.17, but since provides don't have versions
<seb128> you probably need to drop the -x11 P or the -service B
<xnox> mardy: that package rename is done incorrectly, which will fail dist-upgrades as well.
<seb128> xnox, it's not a rename, it's a split
<seb128> xnox, what is incorrect?
<xnox> seb128: i don't see a split, well, i guess it's a split & rename.
<seb128> xnox, it had one binary, now it has a -x11 and a -service, it's a split & rename yes
<xnox> seb128: signon-ui should be provided as a dummy upgrade package
<xnox> which depends on the correct thing.
<xnox> conflicts & provides dropped
<Bluefoxicy> https://www.youtube.com/watch?v=5Qj8p-PEwbI  I hate the news :|
<xnox> mardy: i'd deffer to the person who approved your merge-proposals =)))))
<xnox> seb128: *wink* *wink* =)
<seb128> xnox, it seems we have disagreements on the topic though ;-)
<seb128> xnox, dummy transitional are not strictly needed, they help when you have rdepends and apt is having issues resolving upgrades
<xnox> seb128: well, signon-ui dummy upgrade package must be provided
<mardy> xnox: so, it seems that you are right at least on your guess that dist-upgrade won't work: in fact, it does nothing
<seb128> xnox, no it doesn't
<Bluefoxicy> the summary here is what?  MIT student can't figure out how to connect to wifi?
<xnox> seb128: there is no other way to trigger pkgA to upgrade to pkgB(provides pkgA)
<seb128> xnox, we could update rdepends and use a provides, though dummy might make apt's job easier
<seb128> xnox, but it's not a "must"
<seb128> xnox, there is, C,R,P use
<mardy> xnox: I wouldn't like to drop the Provides, otherwise we have to hunt and change the reverse deps
<seb128> with updated rdepends
<xnox> mardy: dummy package wouldn't require to change depends.
<xnox> mardy: and it's only two reverse-depends in the whole archive
<seb128> mardy, having a dummy transitional might be the easiest solution
<xnox> $ reverse-depends signon-ui --list
<xnox> signon-plugin-oauth2
<xnox> signond
<mardy> xnox: and the dummy package would depend on the two possible implementations (signon-ui-x11 and u-s-s-o-a)?
<seb128> but for 2 rdepends it seems like it's not strictly needed
<mardy> xnox: with an ||, of course
<xnox> mardy: not sure....
<seb128> mardy, you could just drop the breaks from -services
<seb128> those 2 rdepends are not versionned
 * mardy brb
<seb128> so the provides ought to be enough
<xnox> mardy: it looks like it would have been easier to (a) not rename signon-ui (b) make new signon-ui have whatever signon-ui-service currently has (c) create new signon-ui-x11 which has whatever is not in singon-ui
<xnox> and signon-ui-x11 would just have Replaces: signon-ui (<< old)
<xnox> that's how package splits done normally, without renaming everything.
<xnox> and one wouldn't need to change any dependencies
<xnox> cause i presume reverse dependencies only need what signon-ui-service currently has.
<seb128> xnox, things depending on signon-ui expect an UI and they would stop getting one with your suggestion
<seb128> the current approach is fine, the provides does the job
<seb128> it's just the -services breaks which creates the issue
<xnox> right, as one can't do versioned breaks on a provides. provides are versionless.
 * xnox goes back to rebuilding android
<seb128> mardy, sorry it turned out in so much discussions, your call on what you want to do
<seb128> either you can add a dummy, or try what I just suggested
<dbarth> mardy: can you update the merge proposal ^^ ?
<dbarth> mardy: i'd like to free the silo eventually
<cjwatson> wgrant,infinity: There's one other theoretical way I know of to get to the DASBP pages: https://launchpad.net/ubuntu/utopic/i386 and search from there.  The reason it's theoretical is that the search nearly always times out
<mardy> dbarth: I'll first try seb128's suggestion first, since that's less changes
<mardy> dbarth: I updated the signon-ui branch
<dbarth> mardy: thank you
<seb128> ev, bdmurray: the e.u.c database changes create some confusion, maybe that would be a good think to email ubuntu-devel about, just a "fyi, work is ongoing which might creates some issues with the db"
<pitti> apw: what is ls -l /etc/systemd/system/display-manager.service for you?
<pitti> it should be a symlink to /lib/systemd/system/lightdm.service, unles you have more DMs installed
<pitti> that's the multiplexer for making the whole thing compatible to debconf, /etc/X11/default-display-manager, etc.
<pitti> xnox: ^ FYI; that's how it's selected/started
<apw> lrwxrwxrwx 1 root root 35 Jun 11 19:48 /etc/systemd/system/display-manager.service -> /lib/systemd/system/lightdm.service
<pitti> apw: ok, that's right, thanks
<xnox> apw: and $ cat /etc/X11/default-display-manager 2>/dev/null
<xnox> apw: is also /usr/sbin/lightdm ...
<xnox> pitti: cause there is ^ ExecStartPre check
<pitti> right
<pitti> fun to support all the gazillion different ways to configure it :)
<apw> /usr/sbin/lightdm
<pitti> xnox: the one bit which I'm missing in the puzzle is how default-display-manager.service is started; it's not linked to any *.wants/
<xnox> ./system/graphical.target:Wants=display-manager.service
<xnox> ?
<xnox> /etc/systemd/system/display-manager.service -> /lib/systemd/system/lightdm.service
<pitti> ah, right
<kdeuser56> it seems late command and ubiquity success command are broken for 14.04
<kdeuser56> has anybody a working preseed file with these two commands for ubuntu desktop?
<xnox> kdeuser56: all the desktop jobs here are using late commands & fails/success commands https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/
<xnox> kdeuser56: so the released isos have those working
<slangasek> seb128: unflagging the stopped SRU => talk to bdmurray and he'll fix it up
<kdeuser56> xnox: I have the following:d-i preseed/late_command string sudo poweroff;
<xnox> kdeuser56: preseeds can be found in https://code.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/desktop
<xnox> kdeuser56: that's not the right way to shutdown ubiquity installs.
<xnox> kdeuser56: ubiquity != d-i
<bdmurray> seb128, slangasek: I'm looking into it
<kdeuser56> xnox: I know ... but ubiquity ubiquity/poweroff boolean true
<kdeuser56>  is really broken
<seb128> slangasek, thanks (pinged him, waiting for a reply)
<seb128> bdmurray, hey
<xnox> kdeuser56: ubiquity/reboot: automatically reboot when the installer completes. Be sure to add 'noprompt' to the kernel command line to also skip the "please remove the disc, close the tray (if any) and press ENTER to continue" usplash prompt.
<xnox> kdeuser56: https://wiki.ubuntu.com/UbiquityAutomation
<kdeuser56> xnox: I know all of that, but believe me, it does not work here
<xnox> kdeuser56: d-i preseed/late_command is not excecuted by ubiquity.
<kdeuser56> xnox: I can give you all my scripts
<xnox> kdeuser56: you want ubiquity/success_command & / or ubiquity/failure_command:
<kdeuser56> xnox: neither is ubiquity ubiquity/success_command shutdown -h now
<kdeuser56> xnox: the ubiquity reboot command works, but ubiquity poweroff command gets ignored ... if the install finishes, it boots to desktop
<bdmurray> seb128: one issue was that the url in the email and the package version two times. this is sorted now.
<bdmurray> s/and/had/
<kdeuser56> xnox: my kernel commandline when booting the desktop is: "file=/cdrom/preseed/install.seed noninteractive noprompt initrd=/casper/initrd.lz quiet splash --"
<kdeuser56> xnox: I mean when booting my remastered live cd
<bdmurray> slangasek: how do you feel about disabling the rate increase check for ~24 hours
<kdeuser56> xnox: the preseed works fine, but the success commands do not work, no matter how simple they are.
<slangasek> bdmurray: probably a good idea
<slangasek> bdmurray: otherwise you're just going to have to play whack-a-mole with them all
<kdeuser56> xnox: ubiquity/reboot works, poweroff is broken ... the live cd boots desktop after a successful install, even if I have set the poweroff value
<kdeuser56> xnox: A messy version of what I tried to do: http://paste.ubuntu.com/
<kdeuser56> xnox: damn ... http://paste.ubuntu.com/7634008/
<kdeuser56> xnox: anything else you can advise me?
<seb128> bdmurray, slangasek: could somebody send an email to the devel list to have a public status update/fyi on what is happening? e.u.c appears to miss datas and SRU trigger weird emails, that probably deserve some communication
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/no-rate-increase-check/+merge/222957
<kdeuser56> xnox: no respone anymore? :-(
<slangasek> bdmurray: wasn't it decided that IS was going to handle communicating to the list about this?  I guess that hasn't happened
<bdmurray> slangasek: that was my understanding too, I'll send something I guess
<slangasek> bdmurray: ok
<slangasek> bdmurray: merged
<xnox> kdeuser56: you should not presseed both reboot and poweroff
<Laney> bdmurray: just fixed that whoopsie/ubuntu-system-settings bug you told me about in malta btw
<kdeuser56> xnox: I tried all combinations ...
<bdmurray> Laney: oh, cool thanks!
<xnox> kdeuser56: and ubiquity/poweroff should work.
<kdeuser56> xnox: I am already pretty frustrated because I kinda bruteforced to find out what works ... and that command clearly does not work
<xnox> kdeuser56: please file a bug with complete installer syslog in debug mode.
<xnox> kdeuser56: but do it against stock/released isos, not a customized one.
<kdeuser56> xnox: my remaster iso is the original iso, I simply modified the boot options
<xnox> kdeuser56: you seem to mix d-i & ubiquity presseed values....
<xnox> kdeuser56: ubiquity doesn't run tasksel for example, and etc.
<kdeuser56> xnox: since there is really really bad documentation, how would I do it right?
<xnox> kdeuser56: which documentation did you use?
<kdeuser56> xnox: lol, the tasksel tasksel commands are from the official kubuntu iso
<kdeuser56> xnox: in kubuntu.seed
<kdeuser56> xnox: regarding the doc: really bad situation imho
<kdeuser56> xnox: one example: https://help.ubuntu.com/14.04/installation-guide/example-preseed.txt
<xnox> and embedding btrfs filesystems on lvm2 volumes -> i'm not sure that would do what you believe it.
<xnox> kdeuser56: that's not docs for ubiquity preseeding.
<xnox> kdeuser56: but for d-i, server and netboot.
<kdeuser56> xnox: that is not noted anywhere
<kdeuser56> xnox: I searched various examples on the net for the desktop
<kdeuser56> xnox: everywhere its nearly identical
<xnox> https://wiki.ubuntu.com/DesktopCDOptions
<xnox> https://wiki.ubuntu.com/UbiquityAutomation
<xnox> kdeuser56: above two links really list the limited subset of individual keys one can pressed for ubiquity & the custom keys ubiquity accepts for preseeding.
<kdeuser56> xnox: http://www.filewatcher.com/p/dell-recovery_0.98.2.tar.gz.1421121/dell-recovery.natty/casper/seeds/ubuntu.seed.html
<xnox> kdeuser56: dell-recovery is not ubiquity, nor d-i. it has it's own presseeding mechanism.
<xnox> kdeuser56: dell-recovery is a derivative projects from ubiquity.
<kdeuser56> xnox: where can I get a list of all working keys?
<kdeuser56> xnox: and how is succes command supposed to work?
<xnox> kdeuser56: i gave you two urls for ubiquity.
<xnox> <xnox> https://wiki.ubuntu.com/DesktopCDOptions
<xnox> <xnox> https://wiki.ubuntu.com/UbiquityAutomation
<kdeuser56> xnox: yeah, but there are like 5 keys listed ...
<kdeuser56> xnox: nobody can work stuff with that
<kdeuser56> *get to work
<xnox> kdeuser56: if you want to use full d-i preseeding, then use a mini.iso and then you can preseed everything that d-i supports.
<kdeuser56> xnox: okay, if I understand right now, ubuntu desktop offers nearly no option to automate installs ...
<xnox> kdeuser56: it offers bare minimal of things that one would want to preseed. and we automate with that: OEM installs, LVM, multiple language installs.
<kdeuser56> xnox: almost everything works in the preseed stuff that I linked you, apart from: success_command and ubiquity poweroff ...
<kdeuser56> xnox: I already tested that
<kdeuser56> xnox: so I find all of that really strange now ... it works although you tell it is not supposed to work?
<xnox> kdeuser56: please file a bug about poweroff and/or success command not working.
<mdeslaur> kdeuser56: they work for me
<xnox> kdeuser56: did you try booting stock cd, and presseeding just those two values on kernel cmd line (not full preseed)
<mdeslaur> kdeuser56: hold on a sec, I know what you're doing wrong
<mdeslaur> kdeuser56: try this: ubiquity	ubiquity/reboot	string	true
<mdeslaur> kdeuser56: it's a string, not a bool
<mdeslaur> kdeuser56: ubiquity	ubiquity/success_command	string	blahblah.sh
<mdeslaur> kdeuser56: that's a string too, you forgot the type keyword in your example
<kdeuser56> mdeslaur: okay my bad, I screwed up the paste ...
<kdeuser56> mdeslaur: the reboot works with boolean too ...
<kdeuser56> mdeslaur: only poweroff does not work with boolean
<kdeuser56> mdeslaur: I'll try now, with the string, thx for the suggestion
<mdeslaur> kdeuser56: FYI, this is what I use in one of my scripts: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt#L1971
<kdeuser56> mdeslaur: okay now it gets really messy: when to use uiquity, when d-i, and what about console setup?
<kdeuser56> mdeslaur: where do you get the info from?
<kdeuser56> mdeslaur: and why does my script work with d-i too apart from the things I mentioned?
<mdeslaur> kdeuser56: you basically have to look into those packages and see what debconf command they honour
<mdeslaur> kdeuser56: there's no good list, AFAIK
<kdeuser56> mdeslaur: any simple/automated way to that stuff with debconf?
<kdeuser56> maybe canonical should have invested in creating a sane new installer than mixing up debian stuff with some in house stuff
<kdeuser56> mdeslaur, xnox: but thanks very much anyway for your support
<mdeslaur> well, debconf is pretty cool as you can preseed everything
<kdeuser56> mdeslaur, xnox: sorry for my frustration
<mdeslaur> it would be nice to get a master list, and I certainly understand your frustration
<kdeuser56> mdeslaur: link to some debconf tutorial?
<mdeslaur> this perhaps? http://www.fifi.org/doc/debconf-doc/tutorial.html
<kdeuser56> mdeslaur: so would debconf instead of pressed look like?
<kdeuser56> mdeslaur: *how
<kdeuser56> mdeslaur: okay, poweroff works as string ... thanks
<mdeslaur> kdeuser56: that's what preseeding does, it pre-populates debconf
<mdeslaur> so you can preseed all packages that use debconf
<mdeslaur> the trick is figuring out how each package uses debconf
<kdeuser56> mdeslaur: oh no wrong alert ... I only got a stuck reboot using a prior version of the script
<kdeuser56> mdeslaur: okay, red hats/fedoras kickstart is way superior for sure
<kdeuser56> mdeslaur: thats really messy to find that out package wise and a pain to automate
<mdeslaur> kdeuser56: i disagree...preseeding work with any package, kickstart is only for install
<kdeuser56> mdeslaur: might be true, but kickstart does one thing and does it pretty good in a clearly documented way
<kdeuser56> mdeslaur: preseed is a real pain already ... maybe I am just too stupid
<mdeslaur> kdeuser56: breathe in, breathe out :)
<kdeuser56> mdeslaur: yeah, thanks very much for now ... I will go out for a while
<kdeuser56> mdeslaur: ciao and thanks so much!
<mdeslaur> np!
<barry> mvo: can you point me to the branch/code that solves the coverage problem for you in click w/dbus?  i have code that *should* be working according to the coverage.py docs, but it still seems not to collect subproc coverage.  i'd love to compare my approach to yours
<mvo> barry: sure! please check https://code.launchpad.net/~mvo/click/coverage/+merge/221871
<mvo> barry: oh, but not w/dbus, we "just" use subprocess calls
<mvo> barry: if you can point me to your branch I'm happy to check it out
<barry> mvo: cool, thanks.  let me spend a little time reviewing and hacking.  i'll send you a branch url when i have something
<mvo> barry: sure :)
<slangasek> bdmurray: so should I just ignore the spate of new regressions reported for the unity SRU yesterday?  I guess they're all either duplicates or false-positives
<bdmurray> slangasek: I wouldn't ignore the new regressions rather check on them and see if the previous package version appears on the problem page today or tomorrow
<slangasek> bdmurray: ok
<slangasek> bdmurray: would it be possible to reset the state for these packages, so that the uploaders don't have to re-poll?
<slangasek> i.e., clear the list of newly-associated crashes
<bdmurray> slangasek: I'm not following
<doko> barry, libreoffice isn't blocking python3.4 migration. tests which did always fail don't block
<slangasek> bdmurray: the mails I got are because the phased-updater sees these crashes as regressions, and has recorded this somewhere - could we clear all such data that was added in the last day, and let the phased updater check again in 24h?
<doko> but now openssl triggered a python3.4 autopkg test failure ...
<barry> doko: oh, now i see that on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<barry> i was only looking at the python3.4 package
<mvo> doko: could this be https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1329297 ?
<ubottu> Ubuntu bug 1329297 in openssl (Ubuntu Utopic) "openssl CVE-2014-0224 fix broke tls_session_secret_cb and EAP-FAST" [Undecided,Confirmed]
<barry> mvo, doko https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-python3.4/lastBuild/ARCH=i386,label=adt/console
<mdeslaur> grr...what'd I break?
<barry> looks like a borken test run more than anything else
<doko> looks like it needs a give back
<mvo> yeah, something else I think
<mvo> sorry for the noise
<mdeslaur> I hate Mr. Hash Sum
<barry> no worries.  i restarted the build - let's see if that helps
<doko> but everything is now blocked on libffi and some haskell packages using it
<bdmurray> slangasek: we could override the specific problem by adding it to the phased update overrides branch temporarily and then remove it again
 * mvo needs to land this by-hash branch to make the update more robust
<mvo> *sigh*
<slangasek> bdmurray: well, I'm not aiming to override it for the specific case of unity, since I'm the uploader there and have a rough idea of what's going on - more interested in the general problem, and any SRUs other people have uploaded that might be affected by this
<slangasek> bdmurray: but if this is too much work, then nevermind
<bdmurray> slangasek: I mean add that problem https://errors.ubuntu.com/problem/4858f7a856a0ceb65b4dfb0ffc48015fc52848a4 to https://bazaar.launchpad.net/~ubuntu-sru/+junk/phased-update-overrides/view/head:/phased-updates-overrides.txt for ~24 hours to allow more crashes to come in (and maybe one about the previous version) and then remove it.
<slangasek> bdmurray: right, but how would we do that comprehensively, for any other SRUs that have already had their phasing stopped?
<bdmurray> slangasek: it'd have to be done for each individual problem identified as a regression yesterday. I get cc'ed on all the emails so have a list of those problems.
<cjwatson> doko: somewhat tempted to override that, as that's waiting for builds that need haskell-http-conduit to be fixed which is blocked on stuff currently in Debian NEW ...
<cjwatson> yeah, let's do that
<cjwatson> doko: should migrate next run
<slangasek> mterry, stgraber, xnox, cjwatson, dbarth, dpm_, mvo: developer track session summaries to http://pad.ubuntu.com/uos-1406-development-summary, please :)
<stgraber> slangasek: out for lunch (on my phone). I'll write something about system-image for servers when I get back (I think that's the only session I led which was in the dev track, the rest were in devops)
<dpm> slangasek, cool, thanks. Are you going to present the summary?
<slangasek> dpm: yes
<slangasek> stgraber: ok
<dpm> great, thanks
<dbarth> slangasek: done
<xnox> slangasek: added a few bits from things i've been in.
<kdeuser56> mdeslaur: I can confirm for sure now, that ubiquity ubiquity/poweroff boolean true is broken ... it does neither work with string instead of boolean
<mdeslaur> kdeuser56: ok, please file a bug
<kdeuser56> but I can't provide debug stuff ... no experience with that
<kdeuser56> mdeslaur: I can only write 14.04, poweroff does not work ...
<kdeuser56> mdeslaur: I think nobody will care as long as I do not provide the information needed for someone to debug without trying it
<mdeslaur> write the bug # here, and I'll take a look when I get a minute
<kdeuser56> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1329417
<ubottu> Ubuntu bug 1329417 in ubiquity (Ubuntu) "Ubiquity not powering off with "ubiquity ubiquity/poweroff boolean true" in preseed file " [Undecided,New]
<doko> xnox, libboost-python1.55-dev recommends again libgccxml-dev
<doko> pitti, jibel: give back https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-lintian/lastBuild/? ?
<cristian_c> Hi
<cristian_c> I was testing a wiki guide to enable the EOL repositories
<cristian_c> apt-get update is working, but apt-get install no
<cristian_c> I get many 404s not found
<cristian_c> Investigating, I discovered that EOL repositories are not updated
<cristian_c> I was suggested to open a bug report for these problems
<cristian_c> Can you confirm this problem and explain how to open the report in my case?
<slangasek> Trevinho, bregma: mterry seems to have fallen off IRC, and I don't have a summary of the "Unity8 Desktop Preview" session for the wrap-up; any chnace one of you might be able to add something to the etherpad? http://pad.ubuntu.com/uos-1406-development-summary
<slangasek> (your names are on the list as attendees, so I'm assuming you know - if not, please redirect me)
<slangasek> seb128: ^^ or maybe you would be able to say
<seb128> slangasek, not much decisions, we did a summary of the goals for the cycle
<seb128> "having an iso with unity8 on mir, no xorg, being able to run gtk & qt apps fullscreen, work on session management for unity8"
<bregma> sounds about right
<seb128> "being able to install & run clicks"
<slangasek> seb128: ok, thanks
<seb128> we are going to have an installer, it might not be in the live session
<seb128> we are looking at using system-images as well
<seb128> </summary>
<seb128> slangasek, yw
<jdstrand> slangasek: well, not that it matters, but in section 4.5.1 of the upstart cookbook, step 16 of job lifecycle says "The started(7) event is emitted. For services, when this event completes the main process will now be fully running. If the job refers to a task, it will now have completed (successfully or otherâwise)."
<jdstrand> istr reading somewhere else that stopped should be used with a task too
<jdstrand> slangasek: I think we need some expert advice in that bug. what would you (or xnox, or really anyone) suggest for when to start the job, if it should be a task or not (it seems it should be-- it is a discete set of operations) and what lightdm should have (don't have to comment here-- in the bug would be fine)
<slangasek> jdstrand: isn't that just what I've done? :)  You may be right that you'll get a 'started' event when the task finishes, but I prefer to see this done the way /etc/init/network-interface-security.conf is - tasks are more suitable when you want the job to be run multiple times across a system's lifecycle
<jdstrand> slangasek: hmm, this task could be run at other times-- eg an apparmor upgrade
<slangasek> oh?
<jdstrand> slangasek: ok, well, I see mdeslaur is also commenting in the bug, perhaps it should be taken there?
<slangasek> ok
<mdeslaur> slangasek, jdstrand: disregard my last comment in that bug, not sure what I was thinking of
<Chipaca> slangasek: bdmurray: ping about #1328285
<Chipaca> that is bug #1328285
<ubottu> bug 1328285 in whoopsie (Ubuntu) "can not find hardware address" [High,Triaged] https://launchpad.net/bugs/1328285
<Chipaca> thanks ubottu
<bdmurray> Chipaca: yes?
<Chipaca> bdmurray: currently whoopsie uses the "first" network interface
<Chipaca> bdmurray: do you know how that order is determined?
<Chipaca> to preserve it when looking at /sys/class/net
<Chipaca> ooooh, ifindex
 * Chipaca pokes
<bdmurray> Chipaca: no, I don't. slangasek or stgraber might
<Chipaca> there's an ifindex
<Chipaca> that'll work
<Chipaca> bdmurray: are you working on that, or would you mind if I picked it up?
<Chipaca> __lucio__ is going to start shouting at me if the whoopsie id is broken fur much longer
<Chipaca> for, too
<Chipaca> maybe that's a slangasek question too ^
<michagogo> !info whoopsie
<ubottu> whoopsie (source: whoopsie): Ubuntu error tracker submission. In component main, is optional. Version 0.2.24.5 (trusty), package size 20 kB, installed size 110 kB
<slangasek> Chipaca: I hadn't been working on it, it's fine for you to pick it up if bdmurray says so :)
<slangasek> Chipaca: however, ifindex is fairly useless here too, interface ordering is not stable
<Chipaca> slangasek: ok, but I want to be just as broken as the current code in that sense
<Chipaca> not differently broken
<Chipaca> ev: unless you have different ideas?
<ev> hi
<Chipaca> hi.
<slangasek> Chipaca: but it's not a stable ordering, so it doesn't /matter/ if it's differently broken ;)
<ev> hm, could we lexicographical sort the non-loopback interfaces?
<slangasek> Chipaca: I was going to suggest sorting lexically
<ev> boom
<bdmurray> Chipaca: I'm not working on it
<Chipaca> ev: non-loopback, or ethernetty (type 1)?
<slangasek> Chipaca: the latter
<Chipaca> ev: sorting lexically will mean you'll get a different whoopsie id if the user brings up an rfcomm0 interface on a wifi-only device
<slangasek> Chipaca: and you should be able to grab /sys/class/net/$foo/address directly from the fs
<Chipaca> slangasek: yes; need some fiddlery to filter by type, but yes
<slangasek> (since you're already rooting around with files, no sense in using completely separate interfaces for querying the ethernet address...)
<Chipaca> heh, yeah, all that code is going out :)
<Chipaca> ev: are you bashing you head on the desk still?
<slangasek> Chipaca: rfcomm0 shouldn't have an ethernet iftype, should it?  But regardless, this comes back to the fact that once the system ID is generated it should be stored on the fs
<Chipaca> it is looking a lot like that, yes
<ev> I worry about us storing it on the filesystem
<ev> then we wont get the same identifier from the same system across installs
<ev> given the amount of unique data in the hardware, there must be a way of calculating a stable signature
<infinity> ev: How are the two concepts orthogonal?  You can calculate it with a deterministic algorithm but still store it on the filesystem so it's not recalculated at every boot.
<infinity> ev: This also has the advantage that, say, me replacing a piece of hardware in a whitebox system doesn't change my system ID (at least, not until I reinstall).
<infinity> Ahh, memories of Microsoft Product Activation.
<sarnold> but didn't you feel better knowing you had a genuine product? wasn't that an advantage?
<slangasek> ev: you currently don't get the same identifier from the same system across /boots/, let alone across installs.  At least storing it to the fs, if it's done at a point that should give reproducible results, gives us a chance at having the same id across installs while also ensuring that it's the same across reboots
<infinity> sarnold: Yes, I felt very priviledged to have to call a hotline every time I installed Windows.
<sarnold> infinity: a valued customer!
<Chipaca> xnox: ping
<infinity> sarnold: I'm not sure I would have minded if the online activation actually worked, but while retail keys usually work fine, MAPS, MSDN, and volume licensing keys are all notorious for not working automatically.
<infinity> sarnold: Seems like a system designed to annoy the very customers you should be treating as well as possible might be a bit flawed. :P
<sarnold> infinity: yeah, the music industry didn't really make headway against piracy until getting music legally was easier than getting it illegally; microsoft could have learned from that experience..
<infinity> sarnold: Honestly, as much as I'd love to think all our customers share my hippie ideals, I suspect that "It's not a royal pain to obtain and install across thousands of machines" may well be what got us in the position we are today.
<infinity> sarnold: Not that I mind at all winning on technical merits, but it's painful to then have to turn around and explain what "Free Software" is, and why we care. :P
<sarnold> infinity: heh, having been held hostage to a closed-source database once at one job was enough for me to care about free software from then on...
<xnox> Chipaca: hey
<Chipaca> xnox: so... did you get anywhere thinking about blacklisting macs and/or imeis?
<xnox> Chipaca: not yet.
<Chipaca> ev: slangasek: bdmurray: xnox: https://code.launchpad.net/~chipaca/whoopsie/no-moar-siocyadda/+merge/223007
<Chipaca> ooh, i should point at the bug
 * Chipaca fixes
<xnox> Chipaca: need to fix duplicates first before blacklisting them.
<Chipaca> xnox: I'm not entirely sure I understood what you meant
<Chipaca> but my brain just did the nokia "low battery" sound at me
<xnox> sarnold: which one was it.
<Chipaca> so this is where I go to bed
<xnox> Chipaca: what do you expect?! in a similar state  here as well. only had one coffee today as well.
<xnox> =))))
<Chipaca> xnox: I dunno, I thought latvians ran on potato
<xnox> Chipaca: don't make me go all putin on you, to explain that i'm russian =)
<xnox> and well british.
<Chipaca> xnox: :)
<xnox> I shall post you a letter with my thoughts =)
<Chipaca> xnox: fwiw i knew that was going to offend you for entirely different reasons than the apparent :)
<Chipaca> anyway. bed. yes. good.
<sarnold> xnox: it was a front-end by one vendor on top of informix that ran on an sco unix system without compiler or headers available at a price we could afford...
<slangasek> Chipaca: you should have called him a Lithuanian for maximum points
<xnox> sarnold: i think i'm glad that to me SCO stands for Shanghai Cooperation Organisation
<Chipaca> slangasek: i only wanted to rib him, not start a war
<xnox> slangasek: that causes one to smile and start explaining geography, very politely, whilst exploding with rage inside.
<doko> is this the land of draculas?
<xnox> no we are not talking about east germany =)
<sarnold> xnox: hah, you're lucky. :)
<xnox> anyway all of us should be asleep anyway
 * Chipaca puts down the emacs and steps away
<sarnold> too true. it'd be a good afternoon for a nap :)
<doko> don't know about east germany, Ich bin ein Berliner
<sarnold> mmm lekker
<xnox> doko: wunderbar =)
<infinity> doko: Mmm, doughnuts.
<doko> no, these are Berliners
<doko> "Pfannkuchen"
<doko> xnox, gcc-4.7 4.7.4 uploaded, time to update the android cross toolchains
<xnox> sarnold: SCO is a funny coupe - represent ~42% of world population, yet their meetings are never reported by G7 members
<xnox> doko: yeap, will do. and the toolchain-base packages as well, i guess.
<Unit193> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1321869/comments/10
<ubottu> Ubuntu bug 1321869 in libxml2 "xmllint 2.9.1+dfsg1-3ubuntu4.1 does not load entities any more" [High,Fix released]
<doko> xnox, I was waiting for infinity to integrate the cross build changes ...
<infinity> Surely, if they built a few months ago, they should still build today.
<xnox> doko: guten nacht, Matthias =)
<doko> yep, nothing did change within the past two years :-/
#ubuntu-devel 2014-06-13
<mdeslaur> Unit193: crud. Thanks, I'll prepare a regression fix for the regressions fix :)
<Unit193> mdeslaur: Thank you very much.  Patch only needs changed offset.
<chiluk> my squid-deb-proxy and squid3 seem to be in a fight to the death... and neither seems to function.
<mdeslaur> Unit193: security update regressions suck. If someone pings me about them, they can be sure I'll prioritize fixing them quickly. Thanks!
<Unit193> 'Welcome, and thanks again.
<pitti> Good morning
<pitti> doko_: lintian> whoops, fallout from python 3 porting; added test, fixed, pushed out, restarted test
<dholbach> good morning
<Noskcaj> could someone please merge libvirt?
<Noskcaj> hallyn, ^
<michagogo> infinity: KMS FTW?
<michagogo> (re: VL activation)
<dpm> morning pitti - I was going to approve the webbrowser-app template for utopic, but I've noticed that rather than uploading a single po/webbrowser-app.pot template, there seems to be one for each architecture -> https://translations.launchpad.net/ubuntu/utopic/+source/webbrowser-app/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot - would you have any idea why? It's the first time I've seen this in a template
<pitti> hey dpm
<dpm> hey :)
<pitti> dpm: I don't have a definitive answer, did LP changed recently in that regard?
<pitti> dpm: we indeed do build translation tarballs on every arch, but we've done so forever
<dpm> I can't be 100% certain, but I wouldn't think LP has changed anything in translations recently
<dpm> pitti, I don't seem to see it with other packages in the imports queue, seems to be something in that package only
<pitti> dpm: another hypothesis is that it might differ between architectures?
<pitti> most templates and po files should be identical on all arches
<pitti> but maybe this does some magic and encodes the architecture in a translatable string or so
<dpm> it shouldn't have any differences, afaik
<dpm> but I guess I'll have to ask Olivier when he comes online
<pitti> dpm: they are indential except for the POT-Creation-Date:
<mardy> xnox: hi! About yesterday's signon-ui stuff: what is a dummy package? Is it just an entry in debian/control (with no files shipped) that just depends on the newer stuff?
<xnox> mardy: yes.
<xnox> mardy: apt-cache search dummy -> that should bring up plenty of examples.
<mardy> xnox: oh right, good idea. Thanks!
<Chipaca> ev: good morning to you sah
<ev> morning!
<Chipaca> ev: so. Should we store the whoopsie id on the filesystem after calculating it the first time?
 * ev tries to find where we had that conversation last night, for review :)
<Chipaca> ev: here :)
<Chipaca> ev: but also, slangasek commented in the bug
<Chipaca> bug 1328285 that is
<ubottu> bug 1328285 in whoopsie (Ubuntu) "can not find hardware address" [High,In progress] https://launchpad.net/bugs/1328285
<ev> hm
<ev> Chipaca: where are we even seeing this, now that we have IMEI support? Emulator?
<Chipaca> ev: which of the "this"es?
<ev> Chipaca: it looking at the MAC addresses
<Chipaca> hmmmm
<Chipaca> ev: the imei is appended to the mac, because it isn't big enough
<Chipaca> ev: no mac, no whoopsie id
<ev> ah right
<Chipaca> ev: that's what my branch solves
<Chipaca> ev: my quesiton was about the next step: currently the whoopsie id depends on interface ordering, which is not stable (and can change not only between boots but also during a single boot by e.g. loading stuff)
<Chipaca> ev: so we should probably store the whoopsie id once we've gotten a 'known good' one
<ev> well that's where I'm worried. A big point of this was to allow for an identifier that would span reflashes of the device or reinstalls of the OS
<ev> but I'm struggling to think of an alternative off the top of my head
<Chipaca> ev: so: you currently don't have that
<Chipaca> ev: or rather, you have that more by accident than by design :)
<ev> okay, so how about this. We stop using MAC addresses, which are hard to get consistent results from, and instead grab some other static information from the device in the case of phones (manufacturer, serial, etc).
<mardy> jpds: hi! Do you have a minute to talk about bug 1329629
<ubottu> bug 1329629 in account-plugins (Ubuntu) "can't add linked in account because of failure" [Undecided,New] https://launchpad.net/bugs/1329629
<Chipaca> ev: and on non-phones?
<ev> In the case where we don't have a phone and still don't have a dmi table to work with, we write "unidentified-system" or something like that
<ev> and then we can at least see how big the problem is
<ev> because big data
<Chipaca> :)
<ev> well maybe something a bit more granular than that
<ev> unidentified-system-no-dmi-not-phone
<ev> unidentified-system-bogus-dmi
<ev> and so on
<ev> (the latter case being xnox's crazy back of a van laptop)
<ev> mpt: I don't suppose you have any thoughts on this? (What we do when we don't have enough stable unique information in the hardware to generate a system identifier)
<mpt> ev, I do not :-)
<ev> :)
<ev> Chipaca, bdmurray, slangasek, tedg: are you happy with this plan? ^
<Chipaca> ev: once concern: sounds like a lot of work
<ev> probably less work than carefully managing a file on disk
<ev> much less work if slangasek wouldn't mind us using libandroid-properties ;)
<ev> I should help with this, but lately volunteering my time for hacking is a good way to have things take ages.
<ev> I'll still try if no one else can pick it up
<ev> (and if we're all in agreement that it's the right course)
<Chipaca> I don't see libandroid-properties as being any worse than the current dmi thing
<ev> yeah, I'm struggling to remember what Steve's concern was with it. I think he wanted that whole library dead.
<darkxst> r0ckhoff9i5
<diwic> darkxst, oops
<diwic> darkxst, if that was a password you probably want to replace it now
<infinity> ev: Why are you so against a file on disk?
<infinity> ev: Getting enough sources to generate a unique ID implies it might not be perfectly stable.  Doing it once and storing it solves that for, at least, that install.
<infinity> ev: And never having to do the work again until the next fresh install is also just saner at runtime.
<ev> infinity: because files on disk do not persist across installs
<infinity> ev: Sure, but how does that relate?
<ev> because the identifier is there to identify machines, not installations
<infinity> ev: If you come up with an algorithm that you think has a high probability of giving you the same result across two installs, having a file on disk is STILL BETTER than calculating at every boot, or every init of a library or whatever.
<ev> ah, I just got angry and didn't read what you actually wrote. Oops?
<shadeslayer> bdmurray: btw how big was the old tracker db ? :P
<infinity> ev: Unless you're really concerned that someone's going to move a hard drive between machines and you think it should suddenly be a "new machine" because of that.
<infinity> ev: But I'd argue that's the same machine, just with a bunch of new parts. :P
<ev> infinity: I'm not against having a file there as a cache
<shadeslayer> bdmurray: for errors.ubuntu.com
<ev> shadeslayer: several terabytes
<shadeslayer> whoa
<ev> yeah, cassandra is pretty damn good for really big data
<infinity> ev: Right, the file as cache thing was what both Steve and I were arguing for.  By all means, if you can make the algorithm (mostly) stable, go for it, but you're probably never going to get that perfect, so the file saves you there, plus it's just more efficient to have the cached ID.
<ev> infinity: yeah, I was reading most of that inbetween walking home and making dinner, so apologies for missing the finer points
<ev> for what it's worth, I'd rather us be as close to perfect as we can, discarding what we cannot be perfect about
<ev> well not discarding, but lumping that together so we can know how much of an impact it would have
<infinity> ev: Well, you'll always have the whitebox problem where many motherboard don't have model numbers or serial numbers.
<infinity> ev: RAM often has serial numbers, but that's replaced probably as frequently as NICs.
<ev> yeah, but that's what unidentified-system-bogus-dmi is for
<infinity> ev: Right, I'm saying that I suspect that bucket will be larger than you think, but an interesting experiment.
<ev> systems like xnox's, which as far as I can tell was bought by some shady character from the back of a van
<ev> yes, so we make it big, then find ways to whittle it down
<ev> bought off*
<infinity> How badly this all falls over on !x86 is another interesting connundrum.
<ev> ugh, I really need to ditch this mac keyboard for something decent. If only to prevent my hands from sweating to nothingness. Any recommendations?
<infinity> Not talking phones, where you can be saved by an IMEI, but ARM servers, POWER servers, etc.
<infinity> ev: Ducky keyboards are love.
<ev> POWER? Pshh, who cares about /that/
<pitti> I still swear on the Kinesis keyboards :)
<xnox> ev Sculpt is the best http://www.microsoft.com/hardware/en-gb/p/sculpt-ergonomic-desktop/L5V-00006
<infinity> Anything with cherry mechanical switches, really.
<pitti> well, that might be ambiguous in English -- I mean I just love them
<darkxst> diwic, only half, wonder what happened to the first half!
<xnox> infinity: ev would be eaten alive if he brings mechanical keyboard into the office =)
<ev> this yeah? http://www.amazon.co.uk/Ducky-DK9087-Shine3-Keyboard-DK9087S3-BUKPTYY1/dp/B00I47XNNM/ref=sr_1_6?s=computers&ie=UTF8&qid=1402653827&sr=1-6
<infinity> xnox: There are cherry switches that don't make clicky noises.  I use brown, personally, quiet.
<ev> xnox: I sit with IS now. I'm surrounded by James' laugh and the sound of the foosball table
<ev> I bet you do.
<infinity> ev: They make dozens.  This is the one I'm using right now: http://www.amazon.co.uk/Keyboard-Zero-Mech-Brown-Switch/dp/B00GJVA9XW/ref=sr_1_1?s=computers&ie=UTF8&qid=1402653916&sr=1-1&keywords=ducky+zero+brown
<xnox> ev: any space for one more body near IS? =)
<ev> yeah, come on down
<ev> infinity: ooh, that's nice!
<ev> thanks
<ev> xnox: London is always happy to have you
<infinity> ev: If you're considering a mechanical keyboard, researching the different switch "colours" is helpful, but brown is pretty office friendly, and a really nice feel.
<ev> (if we were just on the other side of that bridge this joke would work on multiple levels)
<infinity> ev: Reminds me of the old skool (PowerMac G3 and earlier) Mac keyboards, but a bit more travel, and much less prone to early demise.
<davmor2> xnox: you'll note he didn't say he is always happy to have you ;)
<ev> davmor2: shh you. He didn't pick up on that. :)
<davmor2> ev: oh sorry I didn't realise it was a secret ;)
<xnox> davmor2: i thought it was more of a stab that snob ev, doesn't consider SE3 to be in London =)
<ev> I should bring in a PowerMac, if only to complain about how well Ubuntu works on it to IS
<ev> and to look so awesomely retro
<xnox> ev: can PowerMac do juju?
<ev> It's not London!
<xnox> ev: what's your post-code?
<ev> Greenwich is at best "Greater London"
<ev> NW5
<ev> but just barely
<ev> right on the NW3/5 edge
<xnox> yeah but NW3 is much closer than SE3 though.
<xnox> http://www.doogal.co.uk/images/london_postcode_map.gif
<pitti> wow, I never realized these postcodes encode compass directions
<xnox> pitti: for london they do.
<xnox> pitti: elsewhere they don't.
<ev> pitti: it's also how the gangs organise themselves
 * Laney wonders what NG7 counts as
<Laney> the badlands
<ev> if Britain is anything, it's order.
<xnox> pitti: otherwise it would have been impossible to navigate around london. Cause there are same street names in every postcode more or less.
<ev> NG7?! Is that even a thing?
<xnox> pitti: typically though the post-codes spiral out
<xnox> ev: don't worry, it's outside of M25 =)
<ev> There's land beyond the green belt?!
<ev> No, I refuse to believe this.
<xnox> pitti: with XX1 being the city-center.
<pitti> clever
<xnox> pitti: e.g. more traditional http://en.wikipedia.org/wiki/File:HU_postcode_area_map.svg
<xnox> pitti: i used to live in HU16 which was considered "posh" as you are far away from the center, yet the post-code is small hence has expensive houses / subburbs.
<xnox> well, expensive..... expensive for Hull, in northern england.
<Laney> hahaha
<Laney> you need to get further out into the villages to be actually posh
<xnox> Laney: who shall I blame for packaging dbus headers really wrong?! =)
<Laney> use the changelog?
<xnox> Laney: doko: utter maddness - /usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/dbus-arch-deps.h
<jpds> mardy: I wasn't the last one that touched the LinkedIn plugin.
<xnox> Laney: doko: utter maddness - /usr/include/x86_64-linux-gnu/dbus-1.0/dbus/dbus-arch-deps.h would be better.
<Laney> the pcfile gets the right directory
<davmor2> ev, xnox: within the sound of Bowe Bells is technically London if you ask a Cockney :)
<xnox> Laney: yeah, but still ugly =)
<Laney> go send a patch upstream :P
<mardy> jpds: but you made the first merge proposal; what I wanted to ask you, is whether you registered the app key on your account, or if it was registered by IS
<jpds> mardy: I remember that I asked people to register one.
<jpds> mardy: Not sure how the code's progressed since then.
<mardy> jpds: no, the code is still the same, and it's working OK, but we need some changes on the key. I'll ask IS to look into it, then
<mdeslaur> Unit193: how are you getting xubuntu-docs to fail to build with the current libxml2 packages? It seems to build fine for me
<mdeslaur> I'd like to figure out why it's failing so I can make sure I fix it properly
<Unit193> How it's doing translations, so `make translate` should do it.
<Unit193> It's also validate, which is what will be the clear indicator.
<mdeslaur> Unit193: oh! ok, I see the errors now, thanks. I wasn't failing the build, but I should have looked at the log.
<Unit193> Sure thing, whatever helps.
<mvo> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mvo
 * dholbach hugs mvo
<Sm21> ubuntu sux
<mdeslaur> dad?
<Sm21> i have the balls to say it
<Sm21> ubuntu has lost touch
<Sm21> unity sux
<infinity> Sm21: Is any of this on topic for a development channel?
<Sm21> yes
<infinity> Sm21: Hint, this IRC channel isn't your personal soapbox.
<Sm21> infinity, the truth hurts, hint.
<ikonia> Sm21: I've just removed you from #ubuntu channels - do you want to leave here too ?
<ikonia> if not - please stop with the random rants, and ask your development questions/input
<Sm21> ok mark shuttleworth is all about making money and you are all his fanboys
<infinity> Sm21: Ubuntu is a lot more than just Unity.  If you prefer other desktop environments, there are plenty of other flavours and, this being a development channel rather than a personal ranting channel, you could help work on one of them.
<ikonia> Sm21: final warning
<IdleOne> Enough is enough. Start a blog if you want to rant
<pitti> thanks ikonia
<ikonia> well that worked out well for him
<michagogo> "Patch Pilots: mvo" <-- what does that mean?
<mvo> michagogo: see https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews?action=show&redirect=PatchPilot
<mvo> michagogo: it basicly means that I will sponsor to upload fixes into the distro and/or land branches
<infinity> mvo: And the equally important review and reject. :P
<mvo> infinity: heh, true!
<xnox> barry: hey! I'm trying to work through all the bugs you filed a while ago against system-image vs emulator
<xnox> barry: so i have a couple of scripts that will let you boot emulator in both normal & recovery modes
<xnox> but at the moment it fails downloading things.
<xnox> aka bug #1261552
<ubottu> bug 1261552 in android (Ubuntu) "system-image fails due to missing directory" [Medium,Confirmed] https://launchpad.net/bugs/1261552
<xnox> not sure who is suppose to normally create /android/cache/recovery
<ogra_> xnox, android ... when you initially install the device with it
<ogra_> xnox, all we do is to mount the cache partition under /android/cache
<infinity> ogra_: My Android device doesn't have a recovery directory under /cache...
<ogra_> infinity, then your android device doesnt need it ... and thats fine ... your nexus device would have it though
<infinity> ogra_: This is a Nexus.
<ogra_> oh ?
<ogra_> id /cache actually mounted ?
<ogra_> *is
<barry> xnox: i saw the activity on those bugs - do you have something i can test?
<infinity> ogra_: I would assume so...
<ogra_> well, i have often seen it being only mounted on demand ...
<infinity> Oh, maybe I can't read it as !root, and my file manager is being unclever and telling me it's empty.
<pitti> seb128, dpm: do you happen to know any universe package which uses X-Ubuntu-Use-Langpack?
<dpm> pitti, I think we tested it with synaptic at some point but we disabled it
<pitti> seb128, dpm: On http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs I created a list of sources which are in universe, have translations, and are on the touch image
<seb128> pitti, gnome-panel used to, let me check if it still does (I think it was reverted because it was buggy)
<pitti> none f them use that
<seb128> https://launchpad.net/ubuntu/+source/gnome-panel/1:3.6.0-0ubuntu2
<xnox> barry: yeah, so if you have latest & greatest ubuntu-emulator it should have --recovery option.
<seb128> hum, got reverted indeed
<seb128> pitti, no, I don't
<xnox> barry: ubuntu-emulator run --help to check
<xnox> barry: with that you can create e.g. i386 emulator like so http://paste.ubuntu.com/7638850/
<pitti> seb128: I was mostly wondering whether my grepping was wrong, but seems we indeed don't use it much
<xnox> barry: with extra commands to get the recovery initrd "in the right way"
<xnox> barry: i've picked revision 70 as arbitrary recent one, yet behind current. With a hope to "system-image upgrade it"
<pitti> dpm: in case you are "unnamed", I already have a section for "skip these" :)
<xnox> barry: use-raw-disk -> such that state is preserved across reboots.
<dpm> pitti, damn you caught me! :)
<xnox> barry: how i did start the emulator (with --memory 2048 to get it spin faster)
<dpm> not sure why my name is not in there
<seb128> pitti, http://ubuntu-codesearch.surgut.co.uk/search?q=X-Ubuntu-Use-Langpack
<xnox> barry: and i get to the same as in the above bug -> /android/cache/recovery is missing and downloads file
<xnox> barry: http://paste.ubuntu.com/7638863/
<pitti> seb128: thanks; so my grepping was correct
<xnox> barry: i'm running this as root and e.g. cd /android/cache/recovery; wget https://system-image.ubuntu.com/gpg/image-master.tar.xz does work
<barry> xnox: is that utopic's ubuntu-emulator, or from a ppa?
<xnox> barry: it's utopic's ubuntu-emulator. It should be safe to install on any releases. We compile it such that one can do binary copy and install it on e.g. precise
<pitti> sil2100, dpm, seb128: so we should mark these 14 universe sources for langpack-ification; it's not a 5 minute script job due to citrain, or does that now automagically merge back from teh archive?
<xnox> barry: i can compile it for your choice of distro =) what are you running?
<pitti> i. e. what is less intrusive, mass-upload them with a script and sync back the bzrs, or propose 14 MPs?
<barry> xnox: utopic of course! :)
<xnox> barry: you are such a unicorn =)
<dpm> pitti, I've added a note for the indicators - do you think it might be worth promoting those 2 packages to main instead? I don't have a preference, just mentioning it for the sake of consistency with the rest of indicators
<seb128> pitti, I would go with "email the list and let the respective upstreams get that landed with their next changes"
 * barry imagines a double-entendre off-color retort
<xnox> barry: so i have no clue what system-image-cli is not liking about the emulator, but it should be all good to go
<pitti> dpm: maybe; in fact I think *all* of those should be in main, and touch should only be built from main :)
<sil2100> pitti: hard to say, I would use CITrain for that if those are bzr-enabled in overall, as in this case the landing should be quick
<xnox> barry: and i believe everything is fixed now (channels are right, we have ability to boot into recovery with crutches, etc.)
<barry> xnox: what we need is an interface to boot into recovery from inside the emulator, e.g. `reboot -f recovery` is what the phones do.  will that work?
<pitti> sil2100: yeah, it's a purely mechanical change; so 14 MPs, leave them in approved, and fold them into the next uploads?
<seb128> pitti, you can do mps and let respective lander handle the landings as well, if you feel like doing the mps
<pitti> it's not like we need to immediately upload them
<seb128> but I would just send the email
<xnox> barry: that's in progress. I have a hacky way to get that working. Essentially i replace "reboot" binary with a script that does: nc 10.0.0.1 <<EOF
<seb128> let teams include those
<xnox> reboot recovery
<xnox> EOF
<pitti> seb128: can do as well
<seb128> then do mps for the remaining ones in few weeks, if there are some that got ignored
<xnox> barry: and that connects to the host, and reboots the emulator into recovery.
<dpm> hi oSoMoN, I was asking pitti this morning, but you might know more as it's your app -> I was going to approve the webbrowser-app template for utopic, but I've noticed that rather than uploading a single po/webbrowser-app.pot template, there seems to be one for each architecture -> https://translations.launchpad.net/ubuntu/utopic/+source/webbrowser-app/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot - would you have any idea why? It
<dpm> 's the first time I've seen this in a template
<xnox> barry:  i can give you those scripts as well, we haven't integrated it yet into ubuntu-emulator proper.
<dpm> or ogra_, as you were the last uploader ^
<ogra_> huh ?
<pitti> sil2100: a third option would be to just bzr commit the changes directly to trunk, but I guess we don't do that any more, as trunk == archive, not staged changes, right?
<pitti> I mean s/trunk/the upstream branch/
<ogra_> dpm, i never uploaded webbrowser-app in my life
<xnox> barry: driving "ubuntu-emulator run" & "ubuntu-emulator run --recovery" externally should be enough to see what else we are missing. E.g. can we run system-image in download only mode? and externally validate download, & trigger reboot into recovery?
<sil2100> pitti: yeah, I wouldn't propose that as it might confuse landers and upstreams
<barry> xnox: yeah, that would be great.  i can write a reboot hook that does the low-level bits in the mean time.
<sil2100> pitti: I would stick to MPs :)
<pitti> sil2100: ok; so I guess I'll mail the list first
<seb128> pitti, just do an email to phone with "upstream from those projects, can you include those small changes"
<seb128> and wait
<dpm> ogra_, ah, it seems to have your name and sil2100's in https://translations.launchpad.net/ubuntu/utopic/+source/webbrowser-app/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot
<ogra_> dpm, i think CI train is cheating you ...
<seb128> then we can see what's remaining to do
<xnox> barry: my crutches are in http://bazaar.launchpad.net/~xnox/+junk/killerd/files
<dpm> ogra_, might well be :)
<oSoMoN> dpm, no idea why, but I guess the files themselves are identical, maybe except for the generation timestamp
<xnox> barry: i make emulator.conf upstart user session job (as one would naturally do)
<xnox> barry: start killerd.go service on the host
<dpm> oSoMoN, yes, they are identical except for the timestamp
<ogra_> dpm, if i took a look at debian/control and changelog and ACKed that it might put my name into the upload field even though i dont know anything about the upstream code
<xnox> barry: which does start/stop emulator and passes --recovery as needed.
<xnox> barry: that's good for shutdown/reboot/reboot-recovery from the host
<xnox> barry: but not good for shutdown/reboot/reboot-recovery from whilst booted into recovery as we have no "nc" there yet =)
<xnox> whoops =) which i'm fixing
<xnox> barry: the idea is to get "reboot -f recovery" work with dirty tricks behind the back.
<mpt> ev, bdmurray: What happened to the graph?
<barry> xnox: sounds good.  i'll play with this today if i get a chance
<xnox> barry: kk
<xnox> barry: if anything do shout and i'll try to respond asap =)
<xnox> mpt: new cassandra database, starting from day 0.
<xnox> mpt: it will be eventually "stitched" together
<xnox> mpt: see email on ubuntu-devel about it
<barry> xnox: awesome, thanks
<kdeuser56> would you consider the following issue as a bug: when creating a /boot partition in ubiquity, the partition does not seems to have a UUID and is not mounted using UUID in fstad
<kdeuser56> (using btrfs filesystem)
<xnox> kdeuser56: why would it be?
<kdeuser56> for ext2,3,4 it works
<xnox> kdeuser56: ext doesn't use pools and subvolumes =)
<kdeuser56> xnox: yeah but mounting using /dev/sdXY is not really good
<kdeuser56> xnox: imagine I install in a virtual machine ... then /boot would be sda1, but when booting on the real setup it is /dev/sdb1
<kdeuser56> xnox: thats what made me curious about that issue
<xnox> kdeuser56: is it actually causing a problem for you, or you just dislike the generated /etc/fstab ?
<xnox> e.g. did the install fail to boot?
<kdeuser56> xnox: it causes problems and manual intervention
<kdeuser56> xnox: no boot did not fail, just /boot was not mounted on the booted target system
<kdeuser56> xnox: and it indicated that on the first boot (Failed to mount /dev/sda1 on /boot)
<xnox> kdeuser56: please open a bug about that. with $ ubuntu-bug ubiquity
<xnox> kdeuser56: which will attach all the right logs, and it doesn't attach, do attach the resultant /etc/fstab
<kdeuser56> xnox: It is for sure a bug, because blkid does not find a btrfs boot partition generated by ubiquity
<kdeuser56> xnox: btrfs root partitons are fine though ...
<kdeuser56> xnox: what could result in a uuid not being there?
<xnox> kdeuser56: sorry, i'm busy now. Did you open a bug report? what's the bug #?
<hallyn> Noskcaj: zul is working on it.  zul, how's 1.2.5 coming?
<hallyn> (libvirt, obv)
<zul> hallyn:  its coming..will look at it today
<mpt> xnox, so now we have three?
 * mpt reads the mail
<xnox> mpt: correct. this is the third incarnation
<mpt> holy schmoly
<doko> chrisccoulson, tvoss, Mirv: I see that qt5 is built in c++11 mode, and oxide-qt not. is this intended?
<tvoss> doko, no idea
<kdeuser56> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1329794
<ubottu> Ubuntu bug 1329794 in ubiquity (Ubuntu) "Btrfs boot partition does not have an UUID" [Undecided,New]
<kdeuser56> xnox: I mean though it has not been recommended to have btrfs for /boot, it should at least behave like any other filesystem in that function, right?
<seb128> bregma, Saviq, tedg: logout on unity8 still doesn't work for me, using https://launchpad.net/~ci-train-ppa-service/+archive/landing-008
<Saviq> seb128, heh
<Saviq> seb128, can you try calling the interface directly?
<seb128> Saviq, do you have a dbus command handy?
<tedg> charles, ^
<charles> +1 to Saviq's suggestion
<Saviq> seb128, fraid not
<seb128> charles, see my question to Saviq?
<Saviq> 62	+ connection.registerService("com.canonical.Unity");
<Saviq> 63	+ connection.registerObject("/com/canonical/Unity/Session", this,
<charles> similar suggestion, can you monitor the dbus to see what i-session sends when you hit Logout
<Saviq> and it's Logout and/or RequestLogout methods
<seb128> shrug
<charles> Saviq, there's no Logout
<seb128> it's not easy to do "things" inunity8
<seb128> unity8
<charles> it should be RequestLogout in com.canonical.Unity.Session
<seb128> like no d-feet
<seb128> no alt-tab
 * bregma misses alt-tab big time, it's on the list for 14.10
<charles> dbus-monitor?
<bregma> dbus-send?
<seb128> charles, when doing what? picking logout in the indicator?
<charles> seb128, right you could dbus-monitor to see what i-session calls
<charles> it should be calling RequestLogout when in unity8
<kdeuser56> xnox: what specific info should provide to help debug this problem?
<xnox> kdeuser56: file a bug using $ ubuntu-bug ubiquity.
<kdeuser56> xnox: I have linked you the bug already
<xnox> kdeuser56: sorry, i have missed it.
<kdeuser56> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1329794
<ubottu> Ubuntu bug 1329794 in ubiquity (Ubuntu) "Btrfs boot partition does not have an UUID" [Undecided,New]
<xnox> kdeuser56: tah.
<xnox> kdeuser56: what do you mean suppose?! was the /boot mounted after rebooting the installed system or not?
<kdeuser56> xnox: it was not mounted, but the system was bootable
<xnox> kdeuser56: why are you conducting installation in qemu and transfering to hard ware later?
<xnox> kdeuser56: that's not the only thing that will be borked.
<kdeuser56> xnox: I installed in qemu using real storage
<kdeuser56> xnox: there is nothing borked, it is just like I installed it on real hardware
<kdeuser56> xnox: with the difference that it saves me time (reboot + time of install), as I can work besides the installation
<xnox> kdeuser56: please open the bug with $ ubuntu-bug ubiquity -> that collects a whole bunch of debug logs and information from the system.
<kdeuser56> xnox: how do I assign to an already existing report with that command?
<kdeuser56> xnox: besides that, please do not forget that this has nothing todo with qemu, as I reproduced on real hardware with a manual install
<kdeuser56> xnox: I will remove that qemu bit, because people always search for something that sounds unfamiliar with them and give that as a reason for it not working despite I already tested it out properly
<xnox> kdeuser56 I'm sorry, without installer logs there is nothing i can debug
<kdeuser56> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1329810
<ubottu> Ubuntu bug 1329810 in ubiquity (Ubuntu) "Btrfs /boot partition has no UUID" [Undecided,New]
<kdeuser56> xnox: but I guess nobody will need the debug information as I am sure everyone can reproduce the issue anyway
<rbasak> mvo: around? Is it too late to ask for a change to hwe-support-status?
<rbasak> mvo: sorry I'm late with this. I'd like to point the user to a URL, but I don't have much space to do it.
<rbasak> mvo: so I'm wondering about a --print-url option or something like that which prints a URL to send the user to, as I've only released that it's release-specific.
<kdeuser56> xnox: please ping me for further information. thanks very much for your cooperation and help
<rbasak> If not, I can hardcode the URL for now, and fix it next LTS cycle.
<michagogo> Hey ubottu, could you link me to bug 1314616?
<ubottu> bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,Confirmed] https://launchpad.net/bugs/1314616
<michagogo> (How come that doesn't work in PM?)
<rbasak> mvo: unping. I thought of a better way.
<rbasak> (no changes at your end needed)
<mdeslaur> mvo: thanks for the apt debdiffs!
<mdeslaur> mvo: mind if I make the changelog a bit more verbose?
<slangasek> ev: so, to circle around to the whoopsie id thing... I'm perfectly fine to have us prefer IMEI over MAC for system identifiers, according to xnox that's better for uniqueness anyway
<slangasek> ev: however, that exacerbates the problem of finding the ID on boot, because of ofono becoming a startup dependency (and only on the phone)
<ev> slangasek: what about padding that out with more persistent data from the system, like the serial
<mvo> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> how do you mean, "more persistent"? the IMEI is fixed
<ev> is this not readable outside of ofono?
<mvo> mdeslaur: not at all, ajust in any way needed
<ev> as in IMEI + serial + manufacturer + whatever else
<mdeslaur> mvo: thanks!
<ev> sha512'ed
<slangasek> we don't have any other sane interface for getting the IMEI
<mvo> mdeslaur: thank you and sorry for the trouble :/
<slangasek> ev: serial+manufacturer> redundant, the IMEI should already be unique
<ev> but is it wide enough to create a decent hash?
<ev> that was the concern before, I thought
<slangasek> oh, was it?
<ev> I thought? I remember someone kicking off about it. infinity and apw are the usual culprits for telling me I'm doing it wrong.
<slangasek> infinity, apw: what is ev doing wrong
<slangasek> ;)
<slangasek> ev: so maybe they know something that I don't, but I can't see any way that serial+manufacturer gets you a better hash than just imei
<ev> yeah, let's just call it a bogus claim
<slangasek> unless the concern is that someone is going to create a rainbow table of all IMEIs...
<ev> heh
<ev> so I'm happy for caching to a file, so long as the aim is still to have something that's stable across reinstalls. I think we deal with the problem of not having enough persistent data to work with by marking those as obvious fails
<ev> and then tracking the size of that bucket of IDs
<ev> if it's small, we waste no time on it
<ev> if it's big, we see what we can do
<slangasek> (IMEI = 15 digits, 3.2bits/digit, so 48 bits of space - not impossible to rainbow table that)
<slangasek> (though not for the casual attacker)
<slangasek> yeah, that all sounds sane to me
<slangasek> if we do want to prefer IMEI over MAC, which in principle is better because it more directly identifies a system rather than an interface, we still need to sort out the ofono stuff
<arges> stgraber: hi. the open-vm-tools-lts-trusty upload. that was diffed against precise1. I'm not sure what you mean by missing changelog entry?
<stgraber> arges: right, since precise1 never hit updates, you need to also include the precise1 entry in .changes
<stgraber> arges: anyway, lamont also sponsored it to the queue and his upload was correct, so I just accepted that one instead
<arges> stgraber: ok thanks
<vicTROLLA> Does anyone know where I can find an reasonably up to date package for systemtap?
<apw> ev, slangasek, i don't think in this case it was me complaining, though it does sound like me
<slangasek> :-)
<infinity> slangasek: "if we do want to prefer IMEI over MAC, which in principle is better"... See, the case where you *have* an IMEI (phones, tablets, and a select few laptops with GSM cards) is also the case where replacing your NIC is almost never (except for the laptop) an option.
<infinity> slangasek: So, I'm not sure it's really any better than the MAC. :P
<infinity> slangasek: Trying to use things other than MACs for the PC/server case might make sense, depending on what evan wants to consider "a system", but for the "I can't take it apart anyway, so meh" phone case, any unique ID is a unique ID.
<infinity> slangasek: And bringing ofono into it certainly does seem to complicate things.
<slangasek> infinity: except for the case where you plug a USB ethernet adapter in, or enable networking over bluetooth, or have a virtual bridge on your superphone for VMs, or
<infinity> slangasek: And I can't really envision Ubuntu Phone being installed on anything that has a GSM radio but not WiFi.
<infinity> slangasek: You can ask an interface what sort of interface it is.
<slangasek> infinity: and all of the above are "ethernet"
<infinity> (YOu can get more specific than ethernet)
<slangasek> $ cat /sys/class/net/virbr0/type
<slangasek> 1
<vicTROLLA> out of curiosity, why do you need the identifier?
<slangasek> vicTROLLA: devices need to be uniquely identified when they submit crash reports, so that a user can find their crash reports in the database
<infinity> slangasek: Anyhow, I tend to agree that uniqueness is far more important in the phone case, especially if people are trying to piggyback push notifications on this (which seems like a mistake to me, but whatever), so IMEI is about the only thing we're sure will be stable and unique.
<slangasek> (given that we explicitly don't associate crash reports with any sort of identifiable account information, for privacy reasons)
<vicTROLLA> referencing IMEI will lead to problems. I'm not fully up to date on the how/why but I do know it makes cell carriers angry
<vicTROLLA> this is why android/ios provide a device token
<slangasek> we're not using this as part of a security interface
<infinity> slangasek: If you ignore the part where people have talked about using this for push...
<slangasek> infinity: that's still just an identifier
<infinity> slangasek: Unless these are broadcast/anonymous/insecure push (like telling people about system updates), but I'd expect most/all of those usecases to be pull.
<slangasek> I'm sure system updates won't be pull
<infinity> Why?  They are for nearly everyone else.
<slangasek> no, carriers do push notifications of OS updates
<infinity> Waking a phone up to tell someone something that the phone could have found out itself ten minutes later is poor form when that something isn't time-sensitive.
<infinity> Do they?  Maybe I've been using Nexus devices too long, but they poll.
<slangasek> the nexus devices don't get their update info from the carrier
<infinity> I assumed carriers just override the poll location.
<infinity> For non-Nexus builds.
<slangasek> given the frequency of OS updates, it's a much better use of the network resources overall to push ;)
<infinity> slangasek: Yeah, that's true.
<bdmurray> pitti: I've add some more information to bug 1328180
<ubottu> bug 1328180 in Errors "retraces of unity missing information" [High,New] https://launchpad.net/bugs/1328180
<ScottK> infinity:  Also, since once you start the carrier update process, the phone is useless for 10 minutes anyway, so it's actually better to find out about it at a time you didn't want to use the phone.
<infinity> bdmurray: Have you tested the utopic gdb against any of your bad backtrace reproducers?
#ubuntu-devel 2014-06-14
<bdmurray> infinity: no, not yet
<bdmurray> infinity: would that be a good idea?
<infinity> bdmurray: Might be nice to see if 7.7.1 magically fixes the issue.
<bdmurray> infinity: I'll have a look
<saikat> Hi, i am new in Ubuntu development. Can any body help me to get started please... i have already followed all the steps of the following link http://packaging.ubuntu.com/html/getting-set-up.html
<sarnold> welcome aboard saikat :)
<saikat> thanks
<saikat> samold : can you please help me ?
<sarnold> saikat: maybe; what would like you know?
<saikat> Hi, i am new in Ubuntu development. Can any body help me to get started please... i have already followed all the steps of the following link http://packaging.ubuntu.com/html/getting-set-up.html
<saikat> what's next ?
<sarnold> saikat: first, I guess you'd like to learn that you can type a few characters of an irc nickname and hit 'tab' for your irc client to complete the rest of the nickname -- at least most clients do that :)
<sarnold> that'll save all kinds of time :)
<sarnold> saikat: what's next probably depends upon what you want to do -- what are you looking to contribute to ubuntu?
<sarnold> saikat: is there a specific package you want to work on? or a tool you want to write? or a bug you want to fix?
<saikat> samold : yes
<saikat> samold : i want to start with bug fixing
<saikat> sarnold: are you there ?
<sarnold> saikat: yeah, sorry, I got distracted looking at the bug list :) I found one I thought I had lcosed ages ago... but it's open, confirmed, and critical, it surprised me :) hehe
<sarnold> saikat: here's a huge list of bugs, if you're looking for one at random :) https://bugs.launchpad.net/ubuntu
<saikat> sarnold: okay.... now, how i will get the existing code ?
<sarnold> saikat: you could use apt-get source <packagename> or pull-lp-source <packagename>
<saikat> sarnold : i selected an bug https://bugs.launchpad.net/ubuntu/+source/gallery2/+bug/620087
<ubottu> Ubuntu bug 620087 in gallery2 (Ubuntu) "gallery2 update deleted config" [Critical,Triaged]
<saikat> sarnold: i have selected one bug.... now what will be the package for this ?
<saikat> https://bugs.launchpad.net/ubuntu/+source/gallery2/+bug/620087
<sarnold> saikat: first, it would be a good idea to reproduce the problem, so that you can recognize when you fix it
<saikat> sarnold: yes yes.. that will be good..
<saikat> sarnold : but, how can i find the package for a bug ?
<sarnold> saikat: in this case, the package name is gallery2 -- so you would need to install a version of gallery2 older than 2.3-1ubuntu3.3 (you can find 2.3-1ubuntu3 in the 10.04 LTS release)
<sarnold> saikat: then you would need to configure it, then upgrade to a newer version, and see if the configuration is destroyed
<saikat> sarnold: when i am trying download the package of gallery2.... i am getting an error "Unable to find a source package for gallery2"
<sarnold> saikat: dinner time :) have fun
<saikat> sarnold: any idea ?
<sarnold> saikat: gallery2 was removed in trusty and newer
<sarnold> saikat: you can find the packages here: https://launchpad.net/ubuntu/+source/gallery2
<__llort__> how long does it take to get my app on the ubuntu store
<__llort__> been waiting at least 2-3 weeks still pending review
<Chipzz> __llort__: definitely not the right channel here
<__llort__> prolly going to take 3 weeks to get an answer here too :D
<__llort__> ah well
<Noskcaj> __llort__, you got a reply
<__llort__> oh i was disconnected
<__llort__> can you copy paste it please
<__llort__> Noskcaj, ^_^
<Noskcaj> from <Chipzz> __llort__: definitely not the right channel here<Chipzz> __llort__: definitely not the right channel here
<__llort__> i was told it was by people in #ubuntu
<Noskcaj> i think #ubuntu-app-devel is the place to ask
<__llort__> OH
<Noskcaj> This is for making ubuntu itself
<__llort__> i see, thanks very much
<psusi> g_udev_device_get_sysfs_attr() seems to cache the results rather than re-read it from sysfs each time it is called... does anyone know a way to avoid the caching and force it to re-read?
#ubuntu-devel 2014-06-15
<Logan_> is it a known issue that MoM is down?
<stgraber> yes
<ScottK> Logan_: It's all in the same data center with LP and tons of other stuff.
<Logan_> ah, got it
<kdeuser56> xnox: did you have a look at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1329810 ?
<ubottu> Ubuntu bug 1329810 in ubiquity (Ubuntu) "Btrfs /boot partition has no UUID" [Undecided,New]
<vicTROLLA> thats unsurprising. libuuid is crazy unstable
<Noskcaj> why did libquvi get published in universe instead of main?
<infinity> Noskcaj: It was demoted in trusty.
 * infinity re-promotes.
<Noskcaj> totem-pl-parser will need a rebuild to catch it
<Noskcaj> thanks
<Noskcaj> *retry
<infinity> Noskcaj: Should sort itself in half an hour or so.
<Noskcaj> cool
 * psusi pokes infinity 
<infinity> psusi: Yes, I'm sorting it out this week, honest.  With cherries on top.
<Logan_> darkxst: just a quick note - you don't have to ask people for whom you sponsored syncs, etc. to unsubscribe ~ubuntu-sponsors after you have sponsored the fix
<psusi> <G>
<Logan_> darkxst: they leave the queue if they're fixed, so no further action is required
<Logan_> hey infinity :)
<Logan_> brb, being taught how to cook by a friend (let's see how this goes)
<infinity> Noskcaj: Whoops, missed libthingee-scripts.  Promoted that and trying again after the next publisher.
<infinity> Logan_: Try not to set fire to anything.
<Logan_> no utopic unicorns were harmed in the making of this food
<darkxst> Logan_, ok
<infinity> Noskcaj: You can retry those totem-pl-parser builds (again) in about 20 minutes.  I have to take off and not be around a computer for a few hours.
<infinity> Noskcaj: Or, if you can't do that, I'll do it when I get back. :P
#ubuntu-devel 2015-06-08
<Logan> does anyone know enough about GTK+ (especially the templating system) to figure out why gnome-weather won't launch with the new upstream release? please see Bug 1462834
<ubottu> bug 1462834 in gnome-weather (Ubuntu) "fails to start due to TypeError" [Undecided,New] https://launchpad.net/bugs/1462834
<Logan> actually, it looks like we might need a new version of gjs
<pitti> Good morning
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<dholbach> good morning pitti, I'm just looking at https://code.launchpad.net/~noskcaj/gnome-session/3.16/+merge/261279
<dholbach> and it says:
<dholbach> * Upstream has disabled support for consolekit even on non-systemd
<dholbach>   systems with this release. We follow upstream and do not enable it
<dholbach>   forcefully. Please file a bug if you think this change is wrong.
<dholbach>   - Drop libdbus-glib-1-dev build-dependency, it is now only used by
<dholbach>     consolekit support code.
<dholbach>   - Drop consolekit recommends from gnome-session-bin.
<pitti> \o/
<pitti> at last
<dholbach> I'm not quite sure which implications this would have for wily
<dholbach> so that's something we want? :)
<pitti> dholbach: we haven't supported consolekit since saucy
<dholbach> ok
<pitti> well, upstream really means "logind", saucy and up use logind on top of systemd-shim (with upstart)
<pitti> so 's all well
<dholbach> I'll play around with it some more - thanks
<pitti> dholbach: thanks for double-checking!
<dholbach> yeah... better ask before people can't log in to their sessions ;-)
<dholbach> we've been there before :)
<zyga> good morning
<zyga> is anyone experiencing corrupted fonts on wily today?
<seb128> what sort of corruption?
<seb128> what video card/driver?
<zyga> seb128: fonts randomly don'tr render
<zyga> seb128: nvidia 650ti
<zyga> seb128: or blink
<zyga> seb128: terminal seems to be affetecd the least
<zyga> seb128: unity menu is nearly useless
<zyga> seb128: and firefox is randomly very bad or quite okay (in chunks)
<seb128> zyga, no idea then
<zyga> seb128: maybe my gpu got damaged by the heat lately?
<seb128> does it work if you restart your session?
<zyga> seb128: nope, I rebooted just in case
<seb128> that looks similar to https://bugs.freedesktop.org/show_bug.cgi?id=88584
<ubottu> Freedesktop bug 88584 in Driver/intel "[ilk] Font and screen corruption in GTK+ applications" [Major,New]
<seb128> k, so not that, which makes sense because afaik that ^ is an intel issue
<zyga> I'm seeing https://www.dropbox.com/s/lzmbn8l6it77oc8/corrputed-screen.png?dl=0
<mitya57> dholbach: That gnome-session change is relevant only for kfreebsd and hurd, so it doesn't affect Ubuntu at all
<dholbach> cool, thanks mit
<dholbach> cool, thanks mitya57
<dholbach> I just wanted to be sure :)
<dholbach> mitya57, we might have to do a new ubuntu-packaging-guide upload at some stage - it looks like the Ukrainian translations team is working their way through everything at a furious pace :)
<mitya57> Nice!
<mitya57> Ping me when it's ready for upload :)
<dholbach> will do! :)
<dholbach> pitti, do you think you could take a quick look at https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1459685 again? locutusofborg responded
<ubottu> Ubuntu bug 1459685 in curl (Ubuntu) "please merge curl from debian" [Undecided,Confirmed]
<pitti> dholbach: replied
<zyga> seb128: we didn't land something like xmir over weekend, did we?
<dholbach_> thanks pitti
<seb128> zyga, xmir is to be used under unity8
<seb128> not something that is started on your normal session
<LocutusOfBorg1> hi pitti , I updated bug 1459685
<ubottu> bug 1459685 in curl (Ubuntu) "please merge curl from debian" [Undecided,Confirmed] https://launchpad.net/bugs/1459685
<zyga> seb128: ah, thanks
<LocutusOfBorg1> with the new Debian upload (the nettle transition)
<LocutusOfBorg1> I don't want a broken curl in wily too ;)
<pitti> LocutusOfBorg1: cheers! LGTM
<pitti> Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck failed with error code
<pitti> 8.Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck failed with error code
<pitti> sorry, ECHAN
<LocutusOfBorg1> oops gnutls28 needs to be updated prior to curl, working on a debdiff
<pitti> wgrant: do you know whether today's vivid langpack export has already been started?
<pitti> sil2100: ^
<pitti> wgrant: I did some German translations about an hour ago which the touch guys are waiting for
<wgrant> pitti: Not for another 90 minutes.
<pitti> wgrant: ah cool, thanks
<sil2100> wgrant, pitti: thanks! :)
<dholbach> cyphermox, maybe you can take a look at https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1459685 as well?
<ubottu> Ubuntu bug 1459685 in curl (Ubuntu) "please merge curl from debian" [Undecided,Confirmed]
<LocutusOfBorg1> is anybody looking at the cmake build failure?
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1459685/+attachment/4411458/+files/debdiff-new
<ubottu> Ubuntu bug 1459685 in curl (Ubuntu) "please merge curl from debian" [Undecided,Confirmed]
<LocutusOfBorg1> oops
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/cmake/3.2.2-2ubuntu1/+build/7482691
<LocutusOfBorg1> ^^^
<LocutusOfBorg1> (a.k.a. libjsoncpp MIR or whatever)
<pitti> it's not a build failure, it needs a MIR
<LocutusOfBorg1> of course, I'm asking if I can help with the MIR :)
<LocutusOfBorg1> I tried to use the embedded jsoncpp but seems a PITA to patch
<pitti> nah, we shouldn't use embedded code copies, but the packaged ones
<LocutusOfBorg1> +1 this is why I'm asking for a MIR too, instead of trying to patch it ;)
<LocutusOfBorg1> https://github.com/open-source-parsers/jsoncpp/issues/147
<LocutusOfBorg1> upstream seems working on that too
 * pitti stares at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg in awe
<pitti> I suppose we don't want to maven-ize junit4?
<pitti> (the new version in -proposed seems to do that)
<pitti> doko: do you know who to bother about java bits?
<dholbach> cyphermox, nevermind
<dholbach> Laney, seb128: do you have an opinion on https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1456597?
<ubottu> Ubuntu bug 1456597 in ubuntu-mate-settings (Ubuntu) " ubuntu-mate-settings 0.4.5 release [debdiff attached]" [Wishlist,New]
<Laney> dholbach: Not further, you can upload it if you want
<dholbach> thanks Laney
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ricotz> dpm, hi, please accept pending emails for ubuntu-translators list
<cjwatson> zyga: You should be able to use Git{Repository,Ref}.landing_{candidates,targets} on production now.  (May require 'rm -f ~/.launchpadlib/api.launchpad.net/cache/*wadl*' first to force launchpadlib to refresh its API details.)
<zyga> cjwatson: thanks!
<zyga> cjwatson: I'll give that a try as soon as I can, my pc just melted though
<cjwatson> Mine is permanently melting, I'm refreshing the UPS delivery page for the new laptop about four times a day ...
<seb128> cjwatson, which one did you get?
<cjwatson> seb128: T450s
<seb128> thinkpad, ok ;-)
<dpm> ricotz, I can't see any pending e-mails on the queue that are not spam. What's the subject of your e-mail?
<dpm> ricotz, ah, I think I see it now
<ricotz> dpm, ok, I just resent it
<smoser> Laney, you merged gnome-terminal, do you know anything about
<smoser> Tell me a bug youâve debugged wrt cloud / server
<smoser> bah
<smoser> paste fail
<smoser> https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1463072
<ubottu> Ubuntu bug 1463072 in gnome-terminal (Ubuntu) "highlighting on left mouse double click ends at :" [Undecided,New]
<Laney> smoser: No sorry - can you file it upstream please?
<Laney> will look if you get no joy
<smoser> Laney, that is bugzilla.gnome.org  ?
<smoser> can you at least verify that you see this behavior also ?
<Laney> smoser: yup, and yup
<smoser> Laney, done, bug linked. thanks.
<Laney> smoser: thank you!
<Laney> caribou: yo - you assigned yourself to https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1415880 some time ago - are you working on getting the fix in?
<ubottu> Ubuntu bug 1415880 in bcmwl (Ubuntu) "14e4:4365 bcmwl-kernel source: fix for null pointer crash" [High,In progress]
<shaderslayer> doko: ping
<shaderslayer> doko: can we discuss https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787689 somewhere
<ubottu> Debian bug 787689 in g++-4.9 "[armhf] Internal compiler error while building qtbase (qt5)" [Serious,Open]
<gQuigs> anyone know if removing the rc06 rc[06].d links still needed with systemd?  (https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2015-June/015560.html)
<gQuigs> I haven't been able to find the original issue that has these being removed from packages
<yecril71pl> Hello, which package provides libbz2.pc?
<micahg> apt-file search libbz2.pc? (might need to install apt-file and run apt-file update)
<micahg> or use packages.ubuntu.com
<yecril71pl> It seems there is no such package.
<yecril71pl> So how am I supposed to pass PKG_CHECK_MODULES(libbz2, bzip2 >= 1.0)?
<micahg> well, the dependency is libbz2-dev, but I don't see a pkg-config file in there
<yecril71pl> libbz2-dev is obsolete
#ubuntu-devel 2015-06-09
<shaderslayer> rbasak: any news on that docker backport
<psusi> sigh.. why is the libvirt bzr branch out of date/abandoned, and the source package doesn't point to any other vcs?
<psusi> for that matter, why the hell was the bzr branch like a 1 gb download? that's nearly as big as the entire linux git repo which goes back how many hundreds of thousands of commits over the last 13 years?  whew...
<pitti> Good morning
<Unit193> pitti: Heya.  Oh, any news on switching from upstart user sessions to systemd user sessions?
<pitti> Unit193: no, it's not on the agenda; I'm afraid I have my hands uber-full with system-side stuff already, and it's still mostly just me
<pitti> Unit193: but it's much less of a switch rather than a gradual migration
<pitti> Unit193: both upstart and systemd are running for the user session, so both can be used
<Unit193> pitti: Ah, bummer then.  And yeah, though saw didirocks helped a bit.  Oh?  I was thinking the session management, thought that'd be more of a flip.  And yeah, noticed, I'm already using a systemd user unit. :)
<pitti> Unit193: ah, you do? "systemctl --user -t service" is still empty here :)
<Unit193> (I'm using one because I created one...)
<pitti> arges: do you have time to accept the utopic/vivid postgresql SRUs? thanks in advance!
<dholbach> good morning
<FourDollars> dholbach: Good morning. Are you the patch pilot today?
<dholbach> FourDollars, I was, yesterday
<dholbach> but maybe you just mention what needs uploading?
<FourDollars> dholbach: Could you help https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1460521?
<ubottu> Ubuntu bug 1460521 in efibootmgr (Ubuntu) "UEFI BootOrder is not empty after I removed the last boot entry." [Undecided,New]
<dholbach> slangasek, stgraber: ^ do you know who could take a look at this one?
<FourDollars> dholbach: I have prepared https://code.launchpad.net/~fourdollars/ubuntu/trusty/efibootmgr/1460521/+merge/261464.
<dholbach> yes, I saw it, but I don't know anything about efibootmgr - that's why I pinged Steve and StÃ©phane
<FourDollars> I see.
<FourDollars> slangasek: stgraber: Thx in advance.
<caribou> Laney: I assigned myself to the bug a while ago because someone I was in touch with told me he was able to reproduce the bug
<caribou> Laney: haven't heard from him since
<zyga> good morning
<rbasak> shaderslayer: still working on it. The dependencies keep changing :-/
<dholbach> mitya57, I commited the Ukrainian translations to trunk and made them available on packaging.u.c
<dholbach> mitya57, they're now up to 70%, but maybe we still wait a few days and then make a release?
<brainwash> are there any news on running X as non-root (for drivers which support KMS)? the idea is old and plans did exist like 5 years ago. according to bug 1292324 , lightdm is not ready yet and there seems to be no progress
<ubottu> bug 1292324 in Light Display Manager "Support non-root X" [Wishlist,Triaged] https://launchpad.net/bugs/1292324
<stgraber> dholbach: maybe cyphermox
<jamespage> barry, morning - do you know if the DPMT has considered a lintian check to compare upstream version requirements in python projects against actual versions in Debian/Ubuntu?
<mejo> hi
<mejo> I accidently uploaded a package to upload.ubuntu.com via ftp. The packages are not meant for ubuntu, I intended to upload them to a private repository. The packages in question are 'monitoring-plugins-inet-*'. What is the best contact to ask for removal of them?
<mejo> I guess that they're removed anyway, just want to be sure ;)
<cjwatson> mejo: They'll have been automatically rejected if you don't have upload permissions to Ubuntu.
<cjwatson> mejo: Indeed, I see the rejection in the logs.
<mejo> great, thanks for checking
<zyga> re
<zyga> cjwatson: I was off yesterday, I'm working on tarmac full time today
<cjwatson> zyga: OK, I'm preparing for stakeholder meeting so unlikely to have much attention for it
<zyga> cjwatson: thanks, I only have one request, could you help me see the roadmap you see in asana later today when you have a moment, or direct me to someone who can help me with that
<cjwatson> zyga: that probably needs help from ev
<cjwatson> (since he owns the containing team)
<zyga> cjwatson: ok, I'll talk to ev then, thank you
<doko> pitti, in the past jamespage cared about these mismatches
<dholbach> stgraber, cyphermox is on holidays I think
<jamespage> doko, pitti: unfortunately my time is not scaling to cover java stuff any longer
<jamespage> I did take a peek at junit4 - looks like upstream dropped the ant based build process
<jamespage> rbasak, do you or anyone in the server team have capacity to look at options around the mismatches explosion in wily?
<rbasak> jamespage: I don't think we have the capacity right now. Will have to bounce to gaughen.
<arges> pitti: tomorrow is traditionally my SRU day, but what do you need looked at the utopic queue?
<pitti> arges: postgresql-9.4 in utopic and vivid, for bug 1461425
<ubottu> bug 1461425 in postgresql-9.4 (Ubuntu Vivid) "New upstream microreleases 9.1.17, 9.3.8, 9.4.3 - fixes regression in previous update" [Undecided,In progress] https://launchpad.net/bugs/1461425
<pitti> arges: sorry for hassling; it's quite a serious regression, and somehow utopic and vivid slipped through last week's SRU rounds
<arges> pitti: ok. i'll review. Yea that was my fault since I was waiting on it going into wily
<pitti> arges: I'd like to verify it today, and get them into -updates this week still if at all possible
<pitti> arges: much appreciated, thank you!
<arges> pitti: ok done.
<pitti> arges: cheers
<pitti> arges: would you mind if we released at least the precise one now already (5 days/verified), as that's most affected by the regressino?
<arges> pitti: just 9.1/precise?
<pitti> arges: I wouldn't mind 9.1+9.3/trusty either, but it's much less affected (i. e. not affected in a default configuration)
<pitti> arges: actually, yes: 9.1/trusty needs to go along with 9.1/precise to avoid breaking p->t upgrades
<arges> pitti: seems reasonable for just 9.1, and its only 1 day earlier.
<mitya57> dholbach: Sounds like a plan, will upload on the weekend then
<smoser> is gsettings an interface to dconf ?
<larsu> smoser: yes
<smoser> so why, then
<smoser> $ dconf list /org/gnome/terminal/legacy/profiles:/
<smoser> :63575bfd-baa0-4acd-86fc-6726b91ff51e/
<smoser> list
<smoser> :bdddb09c-01fe-4230-90b0-331af6389b5f/
<smoser> default
<smoser> $ gsettings list-recursively | grep gnome.germinal
<smoser> ^ nothing output there.
<smoser> well, spelling error there.
<smoser> but:
<smoser> $ gsettings list-recursively | grep gnome.terminal
<smoser> doesn't hae the same content.
<smoser> why not ?
<smoser> larsu, ? i'm clearly missing something.
<barry> jamespage: i'm not aware of it, but it's an interesting idea
<cjwatson> smoser: grep -i
<larsu> smoser: these settings are relocatable, which list-recursively doesn't list
<larsu> you need to pass the path at which they're stored
<cjwatson> ah right, that too :)
<larsu> which doesn't work for me right now for some reason... and desrt is not in here :/
<dholbach> thanks mitya57
<smoser> larsu, well, thanks for the input. what a pain.
<smoser> for anyone else bothered by gnome-terminal double-click highlight, there is a config-change fix at
<smoser>  org.gnome.Terminal.Legacy.Keybindings
<smoser> err.. https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1463072
<ubottu> Ubuntu bug 1463072 in GNOME Terminal "highlighting on left mouse double click ends at :" [Medium,Confirmed]
<larsu> smoser: the syntax is schema:path, but list-recursively seems to have a bug where it always returns default values
<larsu> smoser: hm, I was happy about this change because I can now copy/paste filenames from grep output without the :
<smoser> larsu, yeah. both ways have annoyances. its good that it is configurable at least. thanks again for your help.
<slangasek> dholbach, FourDollars: efibootmgr would be in cyphermox's basket, but he's out for the next two weeks
<dholbach> can anyone else take a look at it?
<slangasek> dholbach: if it's urgent
<dholbach> I don't know
<dholbach> FourDollars asked me if I could sponsor it, but it's well out my area of expertise
<seb128> bdmurray, hey, did you see my previous pings about the trusty gtk sru?
<seb128> wondering why it's blocked/not copied to updates despite being fixed-verified for weeks
<xnox> seb128: bunch of regressions
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html
<seb128> xnox, those never worked on trusty
<seb128> so not regression
<seb128> they also are mostly not gtk issues
<xnox> seb128: little does britney know, hence "Not considered"
<xnox> seb128: you need release people to do hints / skips for you. e.g. ping infinity about it.
<seb128> xnox, right, I pinged bdmurray several times asking how we can get those false positive overwriten or if the SRU team could override it
<seb128> xnox, k, I tried that but with the SRU team
<seb128> I figured out they would know how to deal with those issues for SRUs
<cjwatson> The SRU team can override such things, yes
<seb128> some of those autopkg are just buggy on trusty
<seb128> e.g https://jenkins.qa.ubuntu.com/job/trusty-adt-deja-dup/lastBuild/ARCH=amd64,label=adt/console
<seb128> "env: dbus-launch: No such file or directory"
<seb128> it's not a regression from the gtk update
<cjwatson> It's possible they don't know how, but it's in lp:~ubuntu-sru/britney/hints-ubuntu-trusty etc.
<seb128> cjwatson, thanks :-)
<xnox> ah, tah.
<Laney> Oh, is p-m actually used for migration for SRUs?
<Laney> I thought that it was simply that the tests were being run
<cjwatson> No(t yet), but it's informational
<cjwatson> seb128: So yeah, that's the other reason the SRU team probably doesn't care
<cjwatson> It's not necessary at this point to get proposed-migration to pass in order to promote a package
<cjwatson> The sort of rough roadmap I had was that we'd migrate over to using p-m for SRUs with hints set by the SRU team when things were ready to go
<cjwatson> But that's incomplete and we never finished discussions of what tooling we'd need etc.
<slangasek> but it does show up on the report (http://people.canonical.com/~ubuntu-archive/pending-sru.html), and things that are red there require further investigation
<cjwatson> If somebody who's still a functional member of the SRU team wants to pick that up and run with it, it's probably not too hard at this point, and would be a nice defence against accidentally releasing uninstallable updates and such
<cjwatson> Right, that's true, though I imagine it still at least sometimes happens that people choose to disregard those without actually making it green
<cjwatson> Given that the trusty hints branch has had zero commits
<cjwatson> Or else you're all heroes and are making everything pass first without ever having to hint
<slangasek> heh
<cjwatson> I know which I think is more likely :)
<Laney> At what level are uploaders supposed to care about this? Proactively checking the report? Waiting for an SRU team member to ask if they need extra eyes?
<Laney> All I knew is that the tests were being run but I thought they were considered basically noise at this point due to the level of false failures
<Laney> Until i had a couple of pings on bugs. :)
<arges> So it would be good to fix the false positives, I try to review all regression reports to see if they are failures not related to packages, but it takes me about 10 times a long to review a package. If it something complex like gtk+3.0 I ask for the uploader for some help reviewing those false positives
<arges> which is what Laney did looks like
<EvilRoey> hello all!  Question... now that rebootless kernel swapping is mainlined in the kernel, how long until we can upgrade Kubuntu releases without having to reboot?
<rbasak> EvilRoey: maybe try the kernel team in #ubuntu-kernel?
<EvilRoey> ah, thanks!
<slangasek> the high rate of test regressions in trusty between the release and the time we turned adt on for SRUs has certainly been problematic
<bdmurray> cjwatson: what information should go in hints-ubuntu-trusty?
 * zyga sent out the first merge proposal for tarmac
<zyga> https://code.launchpad.net/~zyga/tarmac/git-support/+merge/261528
<cjwatson> EvilRoey: http://jwboyer.livejournal.com/50232.html may be worth reading
<zyga> it's mostly a no-op (nothing new0
<zyga> but I want to see who's responding
<EvilRoey> aye
<zyga> if you are here, please ping me, I'd like to talk about tarmac git support
<cjwatson> bdmurray: compare lp:~ubuntu-release/britney/hints-ubuntu and see http://ftp-master.debian.org/testing/hints/README
<bochecha_> bdmurray: hi, you've sent the ibus-cangjie update to vivid-proposed last week (thank you for that!), can I ask you to send it to utopic-proposed and trusty-proposed as well? :)
<EvilRoey> by the way, I just wanted to express my gratitude for all of your hard work.  I've been using Kubuntu since before Warty Warthog, and I am consistently impressed by how much less administration I have to do on my own system because the system takes care of it for me.  Thanks so much ^_^
<cjwatson> Kubuntu as such didn't exist until Hoary, but we're glad you're enjoying it :)
<cjwatson> (The warty repositories had KDE, though, so it was probably possible to use it there)
<EvilRoey> aye :)
<EvilRoey> I mean.  Shit.  I remember hand-rolling my own kernel in order to support 64-bit and XFS (this was back in 2005? 2004?)
<EvilRoey> in the days before Ubuntu.
<EvilRoey> and all of the little modifications that I put here and there
<EvilRoey> and all of that blisfully went away
<EvilRoey> (still though, fuck nvidia)
<smoser> pitti, around ?
<smoser> systemd experts, i'm seeing https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1463461 on wily, but vivid worked/works fine
<ubottu> Ubuntu bug 1463461 in open-iscsi (Ubuntu) "resolvconf not updated by open-iscsi systemd job" [Undecided,New]
<smoser> it appears to me that /lib/systemd/system/ifup@.service.d/open-iscsi.conf is not getting run
<jamespage> barry, its something that would be useful for the openstack packages, and I thought it might be generally useful as well
<barry> jamespage: maybe open a bug against lintian in debian?
<jamespage> br
<jamespage> barry, that was my plan - I'm not sure my perl is up to actually writing an implementation
<barry> jamespage: mine is so rusty you'd get tetanus
<pitti> hey smoser
<pitti> kees, stgraber, slangasek, mdeslaur: reminder: TB meeting in 6 mins
<smoser> pitti, hey. see above... figured you might know something about that.
<jamespage> barry, bug raised
<pitti> smoser: not off the top of my head; I opened the bug, will look into it ASAP
<barry> jamespage: thanks!
<xnox> pitti: does ubuntu does the cgroup killing spree on logout with loginctl by default?
<pitti> xnox: no, we don't
<xnox> pitti: if not, how that default behaviour was changed?
<xnox> pitti: i want that too, but can't find it.
<pitti> xnox: it has never changed, it has always been off
<xnox> pitti: changed from upstream that is, cause upstream is to kill by default.
<xnox> unless "enable-linger" is done on the user account wiht logind apis.
<pitti> xnox: #KillUserProcesses=no â ./src/login/logind.conf in trunk
<xnox> horum, ok.
<slangasek> bdmurray: fwiw I've seeded hints-ubuntu-trusty now with a force-badtest on gvfs - though I wonder if gvfs shouldn't be made to get a fix test, considering it itself is being SRUed
<slangasek> bdmurray: will these hints have any effect on http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html ? i presume not
<slangasek> bdmurray: deja-dup fails with an error about not finding 'dbus-launch', which is an environment regression; I don't remember, did we draw a line on which packages should be added back to the trusty testbed?
<infinity> slangasek: If the hints have no effect, that would seem to defeat the purpose...
<bdmurray> slangasek: of the top of my head I don't know what effect the hints will have on update_excuses.html
<slangasek> infinity: the purpose of the hints is to have them actually tie into proposed-migration when we do package publications; we're not using p-m currently, we're doing manual copies
<slangasek> infinity: so the question is, does the report consider hints
<infinity> slangasek: Hints are being taken into account, but it might not be the right branch...
<infinity> slangasek: Looks like it's using the main hints-ubuntu branch for everything.
<slangasek> ok, so the report needs a slight tweak?
<infinity> If we're meant to be using branches for hints, then britney probably needs to learn how that works, yeah.
<slangasek> oh, sorry - that's not even what I meant
<slangasek> what I meant to ask was, will the hints have any effect on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<slangasek> which is the report we actually use
<infinity> slangasek: If you meant sru_report rather than update_excuses, yeah.  That could use a tweak to show ignored tests.
<slangasek> bdmurray: ^^ ?
<infinity> slangasek: But ignored tests won't be ignored until your hints are actually taken into account by britney. :P
<slangasek> though maybe instead of changing the report we should just start using p-m for the publication
<slangasek> hmm. or at least, scrape the p-m output for inclusion in the report instead of querying adt directly, if that's what we currently do?
<infinity> slangasek: We're certainly getting closer to being able to do that, but I'm not sure we've specced out the final step yet.  As in, how do we actually let something through.
<cjwatson> infinity: You sure?  See lp:britney/britney1 britney line 318
<cjwatson> slangasek: the report already consumes the yaml output from p-m
<infinity> cjwatson: I dunno.  The logs for trusty imply it's pulling the main hints.
<cjwatson> infinity: it will pull an existing branch if there is one
<cjwatson> so it's possible that it just needs an rm -rf in the right place
<cjwatson> lemme look
<infinity> cjwatson: Ahh, if it needs manual intervention to wipe out data/$dist/Hints, that's probably the missing bit.
<cjwatson> ah, yeah, so that's a fun landmine across releases
<infinity> cjwatson: Does britney already know if dist == devel?  If so, we can check the current branch name and wipe it if it's not a dist branch.  Or we could stop using the unversioned trunk entirely and fork a new hints-dist on each opening.
<bdmurray> slangasek: sru-report uses the update_excuses.yaml file if that answers your question
<cjwatson> infinity: Or we could bzr pull --remember --overwrite
<slangasek> bdmurray: it does, thanks
<infinity> cjwatson: I don't speak bzr well enough to know what that combination does, but sure?
<cjwatson> it saves rebranching from scratch every time but makes sure it ends up in the right place
<infinity> To be fair, we need to branch on each release anyway.
<cjwatson> I mean at runtime
<cjwatson> One moment, this would be clearer with code
<infinity> Either we branch trunk to wily on wily release, or we branch wily to x-series.
<infinity> The latter is less error-prone.
<infinity> cjwatson: But yes, I get what you mean.
<cjwatson> gah one of these days I'll use the right merge target, please ignore the garbage merge
<cjwatson> infinity: https://code.launchpad.net/~cjwatson/britney/fix-sru-branching/+merge/261538 is what I mean
<cjwatson> (untested)
<cjwatson> I don't mind what you want to do with trunk or whatever, but I think this is correct anyway; makes it more certain that reality will be in sync with code
<infinity> cjwatson: Yeah, that looks sane in the current context.
<cjwatson> infinity: cool, can you merge and make sure it doesn't make it all explode? :)
<infinity> cjwatson: Yeahp, will do in a bit.
<cjwatson> ta
 * cjwatson goes back to wrapping head around graph algorithms
<rcj> Question for whomever about LP git support.   Trying to push to a personal repo for a distribution source package like lp:~rcj/trusty/+source/open-vm-tools but push fails with 'Project 'trusty' does not exist.'
<rcj> And that is following the spec for urls @ https://help.launchpad.net/Code/Git
<rcj> nm, should have been lp:~rcj/ubuntu/+source/open-vm-tools/+git/trusty
<cjwatson> rcj: As you say, but "trusty" probably isn't a sensible repository name.
<cjwatson> rcj: You could just have one branch for each series in a single repository, and simply push your repository for all your open-vm-tools packaging to lp:~rcj/ubuntu/+source/open-vm-tools
<rcj> cjwatson, I'm looking to map branches to releases so that they would show up @ https://code.launchpad.net/ubuntu/+source/open-vm-tools
<rcj> cjwatson, I would prefer that
<cjwatson> rcj: We ask that you don't
<cjwatson> rcj: We haven't put the UI for packaging together yet, but we expect to be putting all series into a single repository as a general practice; it's much better for easy data sharing and more convenient for people checking it out
<rcj> cjwatson, that particular package is broken for bzr because a package was uploaded with an illegal character ('\') in a filename and now we can't use the bzr branches
<rcj> cjwatson, one repo is great
<cjwatson> rcj: Right, I'm just saying that the +git/trusty means a completely separate repository, which we do not advise for series branches
<cjwatson> rcj: Nothing's going to show up on /ubuntu/+source/open-vm-tools yet, but hopefully soon
<cjwatson> rcj: But if you just push to ~rcj/ubuntu/+source/open-vm-tools then that should do for now and we'll hopefully be able to make useful views for it soon; it could eventually be turned into a default repository for the package once we get permissions worked out there
<rcj> cjwatson, excellent. I was hoping that would be the direction.
<zyga> cjwatson: quick question, is there a way to rewrite the default branch for a series from bzr to git somehow?
<cjwatson> zyga: No.
<zyga> cjwatson: either in the gui or programmatically
<zyga> cjwatson: so how can a bzr-based project migrate over to git?
<cjwatson> zyga: It's almost certain to involve a manual migration; doing this right typically involves per-project care
<cjwatson> zyga: Or, maybe I've misunderstood what you're asking exactly
<zyga> cjwatson: yeah, sorry, I mean that if I go to code.launchpad.net/project, it shows the bzr branches and git branches are offered under a separate link (thanks for the link btw!), now for new some other project I managed to somehow make git the default
<zyga> cjwatson: I'm curious to understand how does that work
<cjwatson> zyga: There's going to be a switch for the project's default VCS.  It's not entirely in place yet.
<zyga> cjwatson: checkbox (bzr main) and hwcert-tools (git main) for example
<zyga> cjwatson: ah, perfect, thanks!
<rcj> cjwatson, after pushing to that URL I don't see anything @ https://code.launchpad.net/~rcj/ubuntu/+source/open-vm-tools which is unexpected.  (git+ssh://rcj@git.launchpad.net/~rcj/ubuntu/+source/open-vm-tools) Is that known or a bug?
<cjwatson> zyga: There are no projects where git can possibly be the default yet, but you may be looking at a different view.
<cjwatson> rcj: It's known, we haven't put this together for packages yet because we're focusing on projects.
<rcj> cjwatson, ah, okay and I found it at https://code.launchpad.net/~rcj/ubuntu/+source/open-vm-tools/+git/open-vm-tools, is that right?
<cjwatson> Correct.
<cjwatson> Or https://git.launchpad.net/~rcj/ubuntu/+source/open-vm-tools
<cjwatson> Eventually they'll match, the latter path being preferred.
<zyga> cjwatson: hmm, weird, the page https://code.launchpad.net/hwcert-tools did look different last week
<zyga> cjwatson: anyway, thanks, I'll just wait
<cjwatson> zyga: Yes, we temporarily had a mixed view which was a hack.
<rcj> cjwatson, thanks for taking the time.  I've been really happy with all the git support.  Looks like I'm just getting a head of things.
<cjwatson> zyga: What you see now is about two steps towards making it not a hack.
<zyga> :)
<cjwatson> rcj: A little bit, yeah.  Hopefully we'll catch up soon :)
<zyga> little by little, I'm super happy to see everything iterate so quickly
<zyga> cjwatson: is there a reason why git->bzr imports cannot be made from git repos hosted on launchpad
<zyga> cjwatson: I need it to keep recipes running
<nedbat> I've been reading about the process for becoming an Ubuntu committer (not because I will, but to design a similar process for Open edX), and have a question: this page (https://wiki.ubuntu.com/DeveloperMembershipBoard) doesn't explain how people become members of the Developer Membership Board.  Are they appointed?
<micahg>  nedbat they're elected by Ubuntu developers
<micahg> I think you're looking for this page: https://wiki.ubuntu.com/UbuntuDevelopers
<infinity> nedbat: If you're bootstrapping a new community, you do have a bit of a chicken and egg problem if you want an elected board to oversee membership. :)
<nedbat> infinity: yes
<infinity> nedbat: But one would generally grandfather in a few of the project founders as the initial board to then approve new developers, and when the developer base reaches critical mass (whatever you define that to be), you'd kick yourselves out of the board and have an election to elect a new one.
<nedbat> micahg: thanks
<nedbat> micahg: just for completeness, I'm not sure the UbuntuDevelopers page explains that the board is elected by the developers.
<micahg> nedbat: no, that's about how to become a developer
<nedbat> micahg: ok.  the Board page doesn't mention it either.
<infinity> slangasek: What's with the uncommitted change in snakefruit:~ubuntu-archive/proposed-migration/code/b1/update_output
<infinity> slangasek: Looks like it was probably you.
<micahg> nedbat: then, I'm not sure if it's in the wiki, but that's how we've run the elections in the past, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-February/001125.html, we use CIVS (http://civs.cs.cornell.edu/)for the ballots
<nedbat> micahg: thanks. any idea what percentage participation you get for those elections?
<slangasek> infinity: it certainly was not
<infinity> slangasek: I was just assuming based on the line changed having your name in it. :P
<micahg> nedbat: I think between 40 and 60%
<nedbat> micahg: wow, that's good.
<slangasek> infinity: I suspect it was cjwatson; and I suspect it was fixing a problem because of my imported Debian release team status
<slangasek> infinity: the change dates to 2013, I didn't even know how to get to snakefruit then
<infinity> slangasek: Indeed.  Just unlike Colin to cowboy in prod.
<infinity> slangasek: I'll poke him instead, though.
<infinity> cjwatson: ^
<infinity> slangasek: Honestly, I'd assume it was me, but I definitely don't remember doing it. :)
<infinity> (yeehaw)
<slangasek> infinity: actually I checked IRC logs, I may have made this change, was britney being run from lillypilly at the time? :)
<slangasek> infinity: feel free to revert the chunk around my name and we'll see what happens.  The rest of those changes, no idea
<infinity> slangasek: Probably, yeah.  I think we got snakefruit somewhere around the same time we did the ppc64el bootstrap, so late 2013 or something.
<infinity> slangasek: The changes to britney itself are a revert by me just now, but that's how I noticed your bit.
<slangasek> ok
<infinity> slangasek: Anyhow, if your bit is necessary, I'd rather you commit it than playing the "revert and see what blows up" game. :P
<micahg> would we accept an SRU for desktop packages for precise anymore?  trying to figure out what to do with a backport request
<infinity> micahg: Yes.
<micahg> ok, I'll go ahead and process the backport then, thanks
<slangasek> infinity: I don't *know* that it's necessary. It didn't fix the problem at the time
<infinity> micahg: >= precise are 5y LTS for all Ubuntu products, not just server.
<infinity> micahg: And many flavours too, for that matter.
<micahg> oh, haha, forgot :)
<slangasek> infinity: so it was not sufficient, and may also not be necessary.  just revert it, and if my hints fall out of circulation, I'll remember this conversation.
<infinity> slangasek: Oh.  Hah.  Okay.
<infinity> slangasek: Reverted, and the hack lives on in .~1~
<infinity> micahg: To be fair, though, even for products without a 5y support commitment, there's no reason we wouldn't accept an SRU from the community, people are just less likely to generate them in the first place.
<infinity> micahg: Lack of commitment doesn't imply active impedence.
<micahg> infinity: I thought I remembered you saying that in the past, just thought I'd verify :)
<zyga> cjwatson: hey, do you have any plans on adding getByUrl on git_repo/git_ref
<zyga> cjwatson: tarmac needs it, I can work around by parsing the URL and converting that to an api.launchpad.net URL to load directly
<asterai> Hi some one of developpers here?
<sarnold> 360, give or take..
<asterai> I want to contribute the Ubuntu, where i can get the task?
<asterai> )))
<asterai> I want to be one of ubuntu developpers )))
<zyga> asterai: https://wiki.ubuntu.com/ContributeToUbuntu
<zyga> asterai: please read that and see what you'd like to do
<asterai> Ok, tnx. )))
<asterai> Ok, i read all of text. And subscribed to Ubuntu kernel.
<asterai> Where i can get the tasks?
<asterai> Here have some one who can mentor me. How to start? And get my first task.:)
<asterai> Here have some one who can mentor me - How to start? And get my first task.:)
<taggart> what ubuntu releases would it be reasonable to expect users to be installing currently (including sites that might need to reinstall a host with an older but still supported release)?
<taggart> the di-netboot-assistant config file currently looks like this:
<taggart> https://anonscm.debian.org/cgit/d-i/netboot-assistant.git/tree/config/di-sources.list
<taggart> so it has: hardy lucid precise saucy raring quantal oneiric
<taggart> can any of those be dropped? what needs to be added?
<taggart> I think last time I submitted a patch for this cjwatson or slangasek probably gave me the answer...
<taggart> I am guessing:
<taggart> LTS: Drop hardy. Add trusty
<taggart> normal: Drop oneiric, quantal, raring. Add utopic, vivid
<doko> taggart, lucid could be dropped as well
<taggart> doko: Hi! lucid is still listed at http://releases.ubuntu.com/ but is it supported?
<taggart> or i guess more importantly, is any of the installed base still on it? (reasonably)
<doko> enoclue. but it's EOL
<slangasek> it hasn't been dropped from the servers yet but it is EOL, yes
<slangasek> taggart: there is an externalized package now in Ubuntu that provides this information: distro-info
<taggart> ok, I think I will drop it from the config since there will be some delay before the package ships in a release
<taggart> slangasek: ah sweet!
<taggart> slangasek, doko: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788292 patch 6. once that gets uploaded it would be good to pull that into ubuntu to fix there too
<ubottu> Debian bug 788292 in di-netboot-assistant "di-netboot-assistant: update di-sources.list" [Normal,Open]
 * taggart bails, see ya!
<cjwatson> zyga: not something we've thought of, it seemed a bit unnecessary since we have getByPath, but I guess we could if it makes life significantly easier.  Feel free to file a bug about it
#ubuntu-devel 2015-06-10
<infinity> slangasek: Your trusty hints now work.
<infinity> bdmurray: Your yaml scraper might need love to ignore test regressions with a "should wait, but forced" note on them.
<RAOF> infinity: Oh, are we both complaining about sru autopkgtest failures at the same time? :)
<infinity> RAOF: Well, you're complaining, we're trying to fix, but yes. ;)
<RAOF> Ah, good, good.
<pitti> Good morning
<pitti> jdstrand: why don't we have libseccomp on arm64? Debian builds it there
<sarnold> probably poor guy's been stuck in meetings since then :)
<zyga> cjwatson: oh, I'll check out getByPath, thanks
<zyga> cjwatson: hmm, I cannot find that method, I'm looking at https://api.launchpad.net/1.0.html
<zyga> ah, devel/
<lifeless> zyga: yea, ignore 1.0.
<zyga> lifeless: thanks, I was actually about to ask cjwatson if thre will be a new API version (since he recommended to rm stale wadl files)
<lifeless> zyga: magic 8 ball says no
<zyga> :)
<lifeless> zyga: so, the original idea was that each API version would be guaranteed for a period
<lifeless> zyga: but the reality is nearly everyone is using devel now
<lifeless> zyga: and its being evolved pretty gracefully
<lifeless> zyga: so, if there was some radical stuff; deprecations for instance to remove - that weren't reflecting LP stopping doing something, just the API not showing it or something crazy
<lifeless> then cutting a 1.1/2.0 and removing the stuff in devel would be sensible
<zyga> lifeless: yeah, makes sense
<lifeless> but, since there's effectively no reason to remove stuff from the API and not LP itself, I don't think there's cause to do that
<lifeless> a major overhaul of pagination maybe
<lifeless> but - there are comaptible graceful ways to roll that out incrementally
<lifeless> which are ultimately better IMO
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
<zyga> barry: hey, I have a question about debian packages and PEP440
<zyga> barry: some things, on import of pkg resources, produce noisy warnings because pkg-resources seems to parse the full ubuntu version
<zyga> barry: e.g. /usr/lib/python3/dist-packages/pkg_resources/__init__.py:2512: PEP440Warning: 'apturl (0.5.2ubuntu6)' is being parsed as a legacy, non PEP 440, version. You may find odd behavior and sort order. In particular it will be sorted as less than 0.0. It is recommend to migrate to PEP 440 compatible versions.
<lifeless> zyga: thats the version thats in the distutils metadata for apturl I would say
<lifeless> zyga: and its right, that version isn't, and needs fixing
<zyga> lifeless: so what is the recommended approach, it seems that pkg-resource somehow sees debian/ubuntu version
<zyga> lifeless: patch the world?
<zyga> lifeless: (or just pkg-resources)
<lifeless> I've seen no evidence that that is the case
<zyga> lifeless: that what is the case?
<lifeless> cat /usr/lib/python3/dist-packages/apturl-0.5.2ubuntu4.egg-info
<lifeless> Version: 0.5.2ubuntu4
<lifeless> that one package
<lifeless> has a non-PEP-440 version in its Python metadata.
<lifeless> so that one package needs to be fixed
<zyga> lifeless: I suspect many more packages are affected
 * zyga does a quick grep
<zyga> hmm, perhaps it's more isolated, it's just python-apt/apturl and ufw
<cjwatson> Most Python packages aren't native, so they likely just have the upstream version there
<cjwatson> I expect it's only native packages
<lifeless> yup
<lifeless> I was assuming things maintained in the Debian universe would be much more likely to use Debian versions :)
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<FourDollars> No! No patch pilot now! XD
<sil2100> FourDollars: you need any package sponsored? ;)
<FourDollars> sil2100: Yes.
<FourDollars> sil2100: https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1455533
<ubottu> Ubuntu bug 1455533 in udisks2 (Ubuntu Trusty) "Dell systems showing "DIAGS" in Nautilus bar" [Undecided,In progress]
<FourDollars> sil2100: Thx a lot. :D
<sil2100> FourDollars: hmmm, ok, it's a main package so my MOTU-powers are not enough to sponsor it for you sadly
<sil2100> But I can at least review it and try finding someone else
<FourDollars> sil2100: No problem. Thx for your help anyway.
<FourDollars> sil2100: That's good. Thx a lot. :D
<doko> Riddell, cantor ftbfs everywhere
<Laney> Riddell / shaderslayer: Do you use pkg-kde git now? How do you want commits for that?
<barry> zyga, lifeless: i dreamed about pep 440 version numbers last night
<smoser> pitti, responded in bug 1463461. i can give you access to this environment if you want, but other than the 300M download it is easy enough to recreate.
<ubottu> bug 1463461 in open-iscsi (Ubuntu) "resolvconf not updated by /lib/systemd/system/ifup@.service.d/open-iscsi.conf" [High,Incomplete] https://launchpad.net/bugs/1463461
<pitti> smoser: ok, I'll try to recreate; but I would still have been interested in the ifup@*.service output
<smoser> its there now
<pitti> smoser: coldplugging udev during boot ought to trigger those
<pitti> and I wonder why that didn't happen
<smoser> coldplugging ?
<pitti> smoser: right, you gave the vivid ones, which look fine; I meant the failing wily status output
<smoser> i gave wily too
<pitti> smoser: during boot, we udevadm trigger all devices, to run udev rules for devices which are already "there" (from the kernel and initramfs)
<smoser> its just so non-interesting that you missed it :)
<smoser> (comment 4)
<smoser> what udevrule does run ifup ?
<pitti> oh :)
<pitti> /lib/udev/rules.d/80-networking.rules
<pitti> smoser: ah, I have an idea
<pitti> smoser: in vivid that started ifup@.service directly, in wily we use Debian's net.agent
<pitti> I suppose that somehow filters it out
<smoser> bah. '!= remove'
<smoser> i just read 'remove' and thought remove
<pitti> smoser: I suppose you run http://bazaar.launchpad.net/~smoser/maas/maas-ephemeral-sniff/view/head:/README.txt with s/trusty/wily/ ?
<smoser> right.
<smoser> pitti, xkvm is http://smoser.brickies.net/git/?p=tildabin.git;f=xkvm;hb=HEAD
<smoser> i just use it as a wrapper around kvm to more easily put NICs onto a bridge.
<pitti> ah, nice -- I suppose everyone has such scripts (mine is http://people.canonical.com/~pitti/scripts/vmbr)
<pitti> nicely points out how qemu should be easier to use :)
<pitti> smoser: "eth0" in tgt-boot-test should be my primary wlan interface? or something that's hanging off the bridge (using lxcbr0)?
<smoser> pitti, by default its going to put a NIC on virbr0 (libvirt bridge)
<pitti> the sed doesn't work either, I'll just hardcode an IP
<smoser> you can change that string to whatever you want
<smoser> it will dhcp on it.
<smoser> and 'eth0' there is the guest's eth0
<pitti> smoser: no, I mean tgt-boot-test tries to call ifconfig (and sed) on my *host* eth0
<smoser> ah. i see, yeah.
<pitti> # this is the IP address of the tgtd
<smoser> just set it.
<pitti> ipaddr=$(ifconfig wlp3s0 | sed -n '/inet addr/s/\([^:]*:\)\([^ ]*\)\( .*\)/\2/p')
<pitti> I don't know what a tgtd is, so not sure what to put in here
<smoser> it has to be the ip that tgt is listening on. i think it listens on all)
<smoser> tgtd is the iscsi daemon
<pitti> ah, I now get some VM booting
<pitti> smoser: hm, it seems on reboot my changes to files aren't persistant
<pitti> smoser: e. g. I added some debugging to /lib/udev/net.agent, but on reboot they are gone
<pitti> some kind of overlayfs?
<pitti> overlayroot on / type overlayfs
<pitti> aah
<smoser> pitti, they're not persistent.
<smoser> yeah. overlayroot.
<smoser> if you want you can probalby remove thoes kernel params, and moutn read-write.
<smoser> but you can also mount the image RW and make changes inside
<pitti> manual eth0
<pitti> aah!
<pitti> so ifup@ isn't triggered because this is a manual interface
<pitti> smoser: I'm testing with udevadm trigger now, easier/fastet
<pitti> faster
<smoser> well, its manual for good reason.
<smoser> well, i dont know. maybe. its manual though, and that has worked before.
<pitti> I see how it worked in vivid, I'm not sure how it worked in utopic and before
<smoser> i have known in the past
<smoser> but dont remember without lookoing.
<smoser> pitti, network/interfaces is written in initramfs by http://bazaar.launchpad.net/~cloud-initramfs-tools/cloud-initramfs-tools/trunk/files/head:/dyn-netconf/
<smoser> just fyi
<pitti> ok, so we have an eth0 which is set up by the initramfs, and not wanted to set up by ifupdown
<smoser> right
<pitti> ah, /etc/init/iscsi-network-interface.conf
<ogra_> just dump a "manual" config into /etc/network/interfaces.d
<pitti> mount: cannot remount /dev/sda read-write, is write-protected
<smoser> pitti, yeah, tgt is exported ro
<pitti> hm -- how do I make this r/w to get this actually persistant
<smoser> s/readonly/
<smoser> in the tgt-boot-test
<smoser> you'll see.
<pitti> cheers
<smoser> ogra_, well, the dyn-netconf converts ipconfig/klibc to network/interfaces and puts it in /run. that could subsequently or optionally be linked into /etc/network/interfaces.d, but that still requires that there is nothing in /etc/network/interfaces for those
<smoser> and in this case, /etc/network/interfaces.d is RO
<pitti> smoser: ok, I understand how it worked pre-vivid, I followed up to the bug
<jdstrand> pitti: re libseccomp-- it looks like because they pulled in 2.2 which wasn't available until a few weeks ago
<jdstrand> 'add newly supported arm64, mips, and mipsel'
<pitti> jdstrand: ah; I just wondered why we have a delta for the Architectures: line in the first place, as opposed to just using Debian's
<jdstrand> pitti: that's why
<jdstrand> 2.1 didn't have those
<pitti> jdstrand: ooh! 2.2.1 vs. 2.1.1, I mis-looked
 * jdstrand nods
<pitti> jdstrand: ack, thanks; so that'll just come with the next merge
<jdstrand> yes
<pitti> jdstrand: these numbers were just too similar :)
<jdstrand> indeed :)
 * jdstrand updates the backlog to mention this is a merge now
<pitti> nameserver 10.0.3.1
<pitti> smoser: ^ got that in my /etc/resolv.conf now, as opposed to "empty"; looks good?
<pitti> smoser: I can ping out and have network and DNS and stuff
<pitti> smoser: followed up to the bug again, I'd like to hear your opinion
<smoser> k
<hallyn> infinity: qemu in wily isn't promoting from -proposed - presumably because of new binary pkgs?
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu says "missing builds"
<pitti> ah yes, binNEW
<hallyn> oh sorry, i'll go ask in -release :)
<smoser> pitti, i like the arp search that yours does.
<smoser> (vmbr). i was just wanting that recently.
<dobey> mdeslaur: hi. the new nettle in wily seems to be breaking on arm/ppc: https://bugs.launchpad.net/ubuntu/+source/nettle/+bug/1463875 any chance you could look at this? it's causing build failures in silos
<ubottu> Ubuntu bug 1463875 in nettle (Ubuntu) "Crash in libnettle6 on armhf and powerpc archs" [Critical,New]
<mdeslaur> dobey: looks like there's a nettle transition in progress
<mdeslaur> dobey: I guess someone in foundations needs to rebuild stuff
<dobey> mdeslaur: oh, these builds are using -proposed already, so i guess it's what is causing the crash perhaps, and not the version in wily release?
<mdeslaur> dobey: yeah, that's probably it
<mdeslaur> infinity: can you sort that out? ^
<dobey> mdeslaur: updated the description with the package version/pocket info.
<caribou> a while ago I asked why there was such a gap in rsyslog versions (7.4.4 .vs 8.9.0)
<caribou> and was told that most probably it was because nobody cared to merge it
<caribou> is that true ?
<mdeslaur> caribou: that's plausible. it's marked as "please take" on merges.u.c
<caribou> mdeslaur: I feel like this could be a good candidate for me to increase my merge knowledge, but I will need help
<caribou> mdeslaur: would people around be ready to help a young merging padawan ?
<caribou> I've done a few small ones
<mdeslaur> caribou: that one seems to be big :)
<mdeslaur> caribou: best thing is to try it, then file a bug with your debdiff
<mdeslaur> and get whoever's on patch piloting duty to take a look
<caribou> mdeslaur: ok, I'll see if I can spare some time to give it a try
<infinity> mdeslaur: What am I sorting?
<mdeslaur> infinity: stuff is segfaulting in wily-proposed because I think nettle needs a transition
<mdeslaur> infinity: see dobey's bug above
<infinity> mdeslaur: So, it's clearly needing a transition, but what makes you think that's causing the segfaults?  Assuming both versions are being loaded and curbstomping each others' symbols?
<infinity> (Can't really see that happening in the sparse bug report...)
<mdeslaur> infinity: it's just a probably cause, I have no idea if that's the reason or not
<mdeslaur> probable
<infinity> mdeslaur: Oh, see, I thought you might have evidence, rather than superstition.  You're no better than my parents. :P
<mdeslaur> infinity: heh, no evidence at all, which is why I'm bugging you :)
<infinity> mdeslaur: Right-o.  I can have a look at completing that transition, but would be nice to verify the segfaults will clear up when I do.
<infinity> mdeslaur: Thankfully(?) it won't all migrate when it's done, cause I think nettle's also stuck in the current haskell transition, so that should buy a bit of time to test and fix the actual bug. :P
<mdeslaur> I'm sure dobey can help test it...I'm not even sure why I am part of this discussion at all :P
<cjwatson> infinity: It is, though we might find it easier to demote stuff temporarily to forcibly decouple that ...
<infinity> mdeslaur: Cause you inserted yourself? :)
<cjwatson> Haskell still has some weird busted doctest stuff that I'm clueless about, and misc broken packages
<infinity> cjwatson: Whee.  Well, I'll cross that bridge when it collapses in my path and I need to untangle my metaphors with a flamethrower.
<mdeslaur> infinity: I wish
<dobey> infinity: i don't think finishing the transition will fix the issue. it seems the cause is the new version of nettle that is currently in transition
<dobey> oh, so the binary is apparently linked to both libnettle.so.6 and libnettle.so.4
<cjwatson> Right, classic mid-transition segfault city stuff with indirect linking
<dobey> ah, libcurl3-gnutls is linked to both
<dobey> cjwatson: so i guess just finishing the transition will end up fixing it, assuming everything gets rebuilt properly to only link to the one version?
<xnox> stgraber: can one define lxcbr0 purely with systemd-networkd configuration files?
<cjwatson> dobey: Sounds like it from what you said
<dobey> ok
<dobey> hopefully happens quickly then :)
<infinity> dobey: Can you include a link to the failing build in your bug report?
<dobey> infinity: sure.
<infinity> dobey: Ta.
<dobey> done
<smoser> pitti, you're probably afk now aren't 'you
<shaderslayer> Laney: yes, we already have commits for t
<shaderslayer> unless the question is, how do you get commit rights for that, in which case it's basically, talk to the pkg-kde maintainers, and ask nicely
<infinity> dobey: Why is it that whenever I ask someone to link a build, the link a log instead? :)
<Laney> shaderslayer: no, it's what do I do when I upload one of those packages?
<Laney> shaderslayer: before I could just push to bzr
<dobey> infinity: oh, right.
<dobey> infinity: there :)
<infinity> dobey: Yeah, I'd already tracked it back and linked it in a comment. :P
<infinity> dobey: But thanks. :)
<shaderslayer> Laney: uh, good question ... maybe send a patch to pkg-kde on alioth
<shaderslayer> Laney: FWIW we have an entire worfklow, for landing changes via a CI
<Laney> CI... ktrain?
<shaderslayer> something along those lines
<shaderslayer> Laney: https://community.kde.org/Kubuntu/CI
<cjwatson> What would it take to move the Kubuntu branches to git on Launchpad so that we can use normal Ubuntu ACLs for them?
<cjwatson> s/branches/repositories/
<cjwatson> (LP probably needs some bits and pieces of work before that's smooth, but it wouldn't take much at this point)
<Laney> shaderslayer: ^
<shaderslayer> cjwatson: would require a 2 way mirror between launchpad and pkg-kde
<shaderslayer> the idea was to be very close to debian folks by working in the same repos so that they could more easily reuse our work
<GunnarHj> arges: Hi Chris, see that you are working with the vivid queue. Can you please accept ubuntu-docs also, since it needs to be build during this week.
<arges> GunnarHj: sure i'll take a look
<GunnarHj> arges: Thanks!
<shaderslayer> ScottK: do you know if python2.7 armhf installs on a amd64 system
<shaderslayer> or well, is it supposed to
<shaderslayer> because I seem to be running into http://paste.ubuntu.com/11691499/
<sarnold> what are you trying to accomplish?
<shaderslayer> sarnold: trying to install the python2.7 armhf packages in a chroot?
<shaderslayer> sarnold: basically, we're trying to install some armhf packages that depend on python2.7:armhf
<shaderslayer> ( inside a x86 chroot (
<sarnold> shaderslayer: do you need to be able to execute those programs?
<shaderslayer> sarnold: well, that's the thing, I don't have to execute anything, it seems to be a dep of some other armhf packages, I'm trying to figure which one
<sarnold> shaderslayer: maybe use dpkg --unpack on the deb files in question?
<shaderslayer> sarnold: http://paste.ubuntu.com/11691583/
<shaderslayer> which actually doesn't tell me why it doesn't want to install python
<shaderslayer> sarnold: heh
<shaderslayer> sarnold: we need some way of reproducing this, since it's not a one off thing :P
<shaderslayer> or atleast afaik
<infinity> shaderslayer: python's postinst executes python, there's no way around that really.
<infinity> shaderslayer: So, if you have a dep chain that pulls in python, there are two options:
<infinity> 1) Look into what's pulling it in and if it's actually necessary, and if we can fix the world to not do that, thus making cross-building more pleasant.
<sarnold> shaderslayer: .. but you're trying to execute armhf instructions on amd64. you could break out qemu if you don't mind it being glacial..
<infinity> 2) install qemu-user-static and copy /usr/bin/qemu-whatever-arm into the chroot.
<infinity> shaderslayer: The super unhelpful "file not found" from python is actually it saying that it has no PE for python2.7, thus can't run it.  qemu-user-static would fix that.
<shaderslayer> infinity: yeah now I understand it a bit better :)
<infinity> But if this is a chain we expect people to install for crossing, breaking the dep is probably better, if we can.
<shaderslayer> so it unpacks it just fine
<shaderslayer> infinity: yeah, except I can't understand http://paste.ubuntu.com/11691583/
<shaderslayer> or well, I can't understand why python2.7 is pulled
<shaderslayer> I don't see anything in there which would explain it
<infinity> pkgProblemResolver doesn't show you all the dependency resolution, just the bits it needs to work hard to try to fix.
<shaderslayer> I see
<infinity> shaderslayer: "apt-get install foo bar python2.7-minimal:armhf-" might be enlightening.
<infinity> shaderslayer: As you might get a "foo depends on python2.7, but it's not going to be installed" message.
<shaderslayer> I see
<shaderslayer> I'll try it out
<infinity> Repeat for python:armhf- and python2.7:armhf-
<lifeless> barry: poor thing :)
<barry> lifeless: it's okay.  i woke up laughing
<doko> Mirv, I think for ciborium you have to find somebody to port it to the next qml go version
<sarnold> is there a "best bug" for the "package ... is already installed and configured" that we should be duping all these to?
<infinity> sarnold: It's a dpkg bug, we think, but no one's ever been able to reproduce it reliably enough (or at all) to debug it.
<infinity> sarnold: Not sure if there's a master bug for it.
<infinity> sarnold: But if you feel like cleaning up my dpkg bug list, you're welcome to dupe a few dozen. :P
<infinity> sarnold: I'd be much more interested in a reproducer, though.
<sarnold> infinity: interesting. up til now i've assumed it was something like the updater pops up, gets ignored, then the user runs apt-get dist-upgrade manually, and then eventually clicks "go ahead" in the dialog a day or two later
<infinity> sarnold: It happens so infrequently that it could be FS corruption, or cosmic rays, or kittens lobbing string cheese at computers, but at scale, with the number of users we have, it looks pretty common. :/
<sarnold> infinity: for a while I was checking dmesgs on those to try to see if there were sata errors or other segfaults or something but .. figured there's so many of them and never any indication of other errors that there had to be a bug elsewhere in th eupdate stack
<infinity> sarnold: Your assumption would be a pretty magnificent locking failure, which I'm about 99% sure can't happen.
<sarnold> infinity: man I ignore those dialog boxes for days
<sarnold> hehe
<infinity> sarnold: As a useless data point, I've never seen the bug on any of my machines, ever.  Which is super unhelpful.
<sarnold> infinity: me neither! our two useless datapoints now draw a useless data curve :)
<infinity> sarnold: Actually, you know, it might be an apt batching bug.
<infinity> sarnold: You get that error message if you try to configure something that's already configured.  eg: "dpkg --configure libc6"
<infinity> sarnold: Do the logs on the most recent one seem to show the package in question being configured successfully, then a second attempt happening later?
<infinity> sarnold: It's possible I've been blaming this on dpkg all along and it's really just apt being stupid and trying to do a configure pass on the same package twice.
<luc4> Hello! Iâm trying to use the arm-linux-gnueabihf-g++ crosscompiler to cross-build a lib on ubuntu for a ubuntu arm device. When I try I notice this happens: http://pastebin.com/HDkLxEQ9. STL is not found. The iterator header is in /usr/arm-linux-gnueabihf/include/c++/4.9.2 in the host system. But why isnât the compiler looking up into that dir when building? Am I doing something wrong or should the compiler look in th
<luc4> as well?
<dobey> luc4: in your paste, it appears that directory is not included in the search path
<luc4> dobey: are you saying I should add that manually?
<luc4> dobey: but shouldnât that be a system search path?
<dobey> i'm not entirely sure. i don't know what you installed. all i can say is that i've not ever had that issue when cross-compiling packages that use STL
<dobey> plenty of other problems, but not finding the stl headers wasn't one of them :)
<luc4> dobey: is âiteratorâ supposed to be in /usr/arm-linux-gnueabihf/include/c++/4.9.2?
<luc4> dobey: ah, waitâ¦
<luc4> dobey: cross-compiling works
<dobey> i don't know
<luc4> dobey: it does not when I set âsysroot.
<dobey> well, there you go
<luc4> dobey: question now is: is the compiler supposed to look for âiteratorâ in the sysroot or in the host?
<dobey> luc4: i'd guess the g++/gcc documentation explains what happens when -sysroot option is used
<luc4> dobey: yes, I read that but it does not clear this out
<dobey> you are changing the root from / to something else; the default include paths added by gcc follow the root specified.
<luc4> dobey: if you look at the output I reported above, it seems it looks into some host paths first, and then some paths in the sysroot.
<luc4> dobey: in either cases, iterator is in a different dir.
<luc4> dobey: in the target filesystem it is in /usr/include/c++/4.9.
<dobey> yes, the /usr/lib include paths are special
<dobey> i'm guessing you probably need to install the stl headers and libstdc++ you want to use, in the sysroot
<luc4> dobey: yes, I installed that.
<luc4> dobey: in the sysroot I have âiteratorâ.
<dobey> i mean, the error message is pretty clear about where it's looking
<luc4> dobey: but still not in one of the dirs the compiler is looking.
<luc4> dobey: yes, iterator is not there.
<luc4> dobey: it is like the expected layout was different.
<dobey> no, but probbably the raspbpi has a different gcc version or at least, the headers are installed in a different path, than the compiler in ubuntu uses. so you will have to add the path, or not build with -sysroot, or something similar
<luc4> dobey: version is 4.9.2 for both. And on pi Iâm using ubuntu mate.
<luc4> dobey: I suppose it should be identical...
<dobey> yeah, i wouldn't expect ubuntu mate to change the gcc build
<dobey> i don't know how you installed the headers there though. i can only tell you that the error message in your pastebin is quite clear :)
<luc4> dobey: clear? :-) in the sense that it is not looking where it should?
<dobey> luc4: well your definition of "should" may not match the compiler's definition
<dobey> luc4: it is clear in the sense that it reports all the locations where it looked for the header. it's up to you to find out why it isn't there :)
<luc4> dobey: thatâs the reason why I came here in the first place :-)
<luc4> dobey: when I was cross-building the same way with other distros like raspbian it was working...
<dobey> were you using -sysroot then?
<luc4> dobey: the crosscompiler used its own version of system libs + headers
<luc4> yes
<luc4> I was using the linaro toolchain and raspbian
<luc4> also the toolchain was different from the system, but providing the proper libs, everything was working
<luc4> here for some reason it seems that when setting sysroot, the compiler does not look for system headers were they are on the host
<dobey> well, there's nothing more i can tell you.
<luc4> do you know if there is someone maintaining those packages?
<dobey> gcc? yes, the foundations team maintains the toolchain
<luc4> dobey: in the output of the link there is âignoring nonexistent directory "/opt/rpi/sysroot_mate/usr/arm-linux-gnueabihf/include/c++/4.9.2ââ. That dir â/usr/arm-linux-gnueabihf/include/c++/4.9.2â exists in the host but not in the targetâ¦ maybe just some missing packageâ¦?
<dobey> you mean /usr/lib/arm-... there right?
<luc4> yes
<luc4> ah, now I got this! http://pastebin.com/20JCVkyv
<dobey> anyway, i'm not sure. and i don't have root on your machine. i'm sure you can look and figure it out :)
<luc4> not sure if it makes sense to install a cross compiler for arm on a arm system...
<dobey> probably doesn't
<luc4> unfortunately I spent a day on thisâ¦ not sure I can find the issue
<dobey> you're doing the build on the arm device?
<luc4> dobey: no, I need to cross compile.
<dobey> oh ok
<dobey> anyway, i don't really have any other suggestions for you myself. and i have to go now. good luck
<dobey> later
<luc4> dobey: no problem, thanks for your time
<luc4> dobey: my suspect is that those three dirs should not be prepended by the sysroot path.
<cjwatson> shaderslayer: I suppose that could be done, but surely the main obstacle previously was revision control, and it's really not hard to add another remote to a git clone ...
<shaderslayer> requires pushing twice then :(
<shaderslayer> and I'm sure people will screw up pushing twice
<cjwatson> Only if you're committing to two different branches ...
<shaderslayer> IIRC branches track only one remote don't they?
<cjwatson> I was suggesting that the Kubuntu branches could actually move back to Launchpad so that they could make use of Ubuntu project ACLs
<shaderslayer> ah
<cjwatson> Now that it doesn't have to involve using a different VCS
<cjwatson> (Or at least that we could explore that and figure out what else we need to fix in LP to make it workable)
<shaderslayer> dunno, maybe we could write our own mirroring tech
<shaderslayer> cjwatson: oh oh
<cjwatson> Two-way mirrors are inherently problematic
<cjwatson> A one-way mirror is obviously fairly easy
<shaderslayer> cjwatson: does Launchpad provide hook delivery
<cjwatson> shaderslayer: YM webhooks?
<shaderslayer> since we use that on our jenkins
<shaderslayer> cjwatson: yep
<cjwatson> shaderslayer: It's our top development project
<shaderslayer> so git.debian allows us to delivery commit hits to Jenkins to allow us to do per commit builds
<cjwatson> We hope to have that in a month or so
<shaderslayer> cjwatson: I think the consensus at the moment is that anyone who wants to contribute to Kubuntu can ask for debian-qt-kde commit rights
<cjwatson> Yeah, in practice when that's been tried elsewhere in the past the result is that uploaders who are doing things across the distro rather than just in Kubuntu simply don't commit
<cjwatson> It's always been tried with good intentions, but ...
<cjwatson> Maybe when we have dgit of everything or something
<infinity> luc4: The whole point of -sysroot is to look in your sysroot for everything.  If it allowed you to pollute your environment with your real root, that would defeat the entire puropse.
<infinity> luc4: In other words, you got what you asked for, you just weren't sure why you were asking for it. ;)
<luc4> infinity: not exactly, my sysroot has the header âiteratorâ, but still, the compiler wonât find it.
<luc4> infinity: also, if you look here: http://pastebin.com/HDkLxEQ9 youâll see the crosscompiler also looks into the host system for some headers
<luc4> infinity: which, according to your sentence, should be wrong, shouldnât it?
<infinity> luc4: The gcc-cross stuff is either "special" or a bug, I'm not sure.  But what you're doing when you set sysroot is explicitly saying "instead of /usr/include and /usr/arm-linux-gnueabihf/include, I want you to prepend /opt/rpi/sysroot_mate to that".
<luc4> infinity: Iâm not entirely sure about that, however, letâs suppose it is: my question is âwhy isnât it finding the headers in the sysrootâ?
<infinity> luc4: So, you'd need to install libstdc++-dev and g++ in your sysroot to find the headers there.  Or not compile with sysroot.
<luc4> infinity: precisely, done already
<infinity> luc4: Oh, that may still not work, mind you, because our cross-compilers are set up to look in the cross locations, but not the native ones.  That might be a bug.
<infinity> luc4: Clearly, this is not how any of us call our compilers. :P
<luc4> infinity: the header âiteratorâ is in the sysroot, it is just in a system directory that the compiler is not searching.
<luc4> infinity: I could add it manually, and that way it works, but it doesnât seem right.
<luc4> infinity: Iâm not sure Iâm following. You say you donât set the sysroot?
<infinity> luc4: No, it may well be broken.  I would expect to see $sysroot/usr/include/c++/4.9.2 on the search path, I think, when calling it that way.  But it's a bit messy, since that absolutely *can't* be on the search path when not sysrooting.
<infinity> luc4: No, I don't use sysroots for crossing.
<luc4>  infinity: and how can you ensure that the build finds all the proper libs and headers?
<infinity> luc4: I use an amd64 chroot with armhf as a foreign arch, and install the armhf build-deps in said chroot.
<infinity> luc4: Whereas, I assume your sysroot is pure armhf, which isn't quite the scenario we packaged our cross-compilers for (but that doesn't mean it shouldn't work... Like I said, this is probably a bug you should file)
<luc4> infinity: at the moment Iâm adding three paths manuallyâ¦ not sure it will work but Iâll try...
<luc4> infinity: I can file the issue but Iâm not a compiler expert. Soâ¦ what do you think?
<infinity> luc4: One doesn't need to be an expert to file bugs. :)
<luc4> infinity: no, but as you seem to be a little more used, you probably can tell me if I should or not.
<infinity> luc4: Can't hurt to file it.  Like I said, we don't really use the sysroot feature much (or at all), so I'm entirely willing to believe it's broken and needs looking into.
<misspapaya> I un-tar'd ubuntu-core onto an SD card for a system without a display and I don't get a login prompt
<misspapaya> via serial
<misspapaya> how do I set that up?
<misspapaya> (armhf)
<infinity> misspapaya: Which version?
<misspapaya> infinity: trusty
<infinity> misspapaya: You want something like this: http://paste.ubuntu.com/11692880/
<infinity> misspapaya: Alter the filename and tty* in the file to match your actual serial port.
<misspapaya> kk thanks :(
<infinity> misspapaya: Whatever you're passing on the cmdline as console=
<misspapaya> s/(/)/
<misspapaya> can't ubuntu just magically know the hardware it's running on? :P
<infinity> misspapaya: The core tarball is just a rootfs, there's no installer, and precisely zero magic.
<misspapaya> infinity: that worked. Thanks :)
<misspapaya> I just forgot to add a user
<infinity> Users are overrated.
<misspapaya> init=/bin/sh
<misspapaya> now to get back to seeing if GPS works in orbit :P
<sarnold> misspapaya: check the datasheet or manual; some of the gpses I've looked at recently include e.g. ""altitude < 18000 meters or velocity < 515m/s COCOM limit, either my be exceeded by not both" -- which probably rules out orbit
<jrwren> anyone familiar with dh_python? I'm trying to extract some functionality for some other purpose, but i cannot follow how the shebang option is used. I see parser.add_option shebang, and then its never used.
<misspapaya> sarnold: haha thanks for the input but I'm not the head of this project so it's not a major concern of mine
#ubuntu-devel 2015-06-11
<Mirv> doko: ack, I asked mandel to look at the bug, he probably knows what it's about then
<linuxuz3r> just wanna say hi
<linuxuz3r> im a noob
<pitti> Good morning
<Unit193> Howdy, pitti.
<doko> infinity, subscribed glibc to https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1248642
<ubottu> Ubuntu bug 1248642 in nvidia-graphics-drivers-331 (Ubuntu Trusty) "dynamic library inconsistencies with OpenGL/C++" [Undecided,Confirmed]
<caribou> merge question : rsyslog installs an "upstart only" job (saving dmesg on boot) in the vivid version
<caribou> should I migrate it to systemd ?
<caribou> on the same topic, should I also migrate the upstart job to systemd ? upstream debian  hasn't done the systemd bits yet
<rbasak> caribou: does that mean that Vivid with systemd regresses the saving dmesg on boot functionality?
<rbasak> caribou: AIUI, yes we should fix that in systemd.
<rbasak> pitti: ^^
<caribou> rbasak: I would think so
<rbasak> I wonder if we should SRU a fix for that to VIvid.
<caribou> rbasak: FYI I went ahead & created an rsyslog-dmesg.service
<rbasak> Saving dmesg on boot is useful.
<caribou> rbasak: I can create the bug & SRU once the merge is done
<rbasak> Users will only discover it not there when they debug and can't find it.
<rbasak> caribou: thanks!
<caribou> rbasak: how about migrating the upstart script to systemd ?
<rbasak> caribou: the regular rsyslog job?
<caribou> well, upstream only has an init job but we do provide an upstart job merged in
<rbasak> Then the init.d job is fine unless losing the upstart job regresses some functionality
<caribou> rbasak: the upstart job is now obsolete so it means relying on upstream init script
<caribou> rbasak: I'll check it out
<rbasak> Obsolete for Ubuntu, yes. Debian could use it for Debian users using upstart though
<caribou> rbasak: ok got bug #1464227
<ubottu> bug 1464227 in rsyslog (Ubuntu) "kernel messages are not saved when rsyslog is started" [High,In progress] https://launchpad.net/bugs/1464227
<caribou> rbasak: don't think it is in the debian package
<pitti> caribou: it's all in the journal, isn't it?
<rbasak> Hmm. I suppose if systemd provides equivalent functionality then we don't need it? (Does it?)
<mdeslaur> pitti: the journal isn't enabled by default though, no?
 * mdeslaur doesn't have a /var/log/journal directory
<pitti> mdeslaur: journal is (in /run), just not persistant journal in /var
<pitti> but rsyslog also captures kernel messages
<mdeslaur> hrm, I don't have anything in /run/systemd/journal either
<mdeslaur> I guess it's in ram
<pitti> mdeslaur: it is in /run/systemd/journal
<pitti> mdeslaur: "sudo journalctl -b" -> does that work?
<mdeslaur> yeah, that works
<rbasak> wfm
<mdeslaur> it's cached in ram
<rbasak> Will that retain "dmesg on boot" indefinitely or will it roll over eventually?
<rbasak> "systemd-journal[318]: Runtime journal is using 8.0M (max allowed 77.8M..."
<rbasak> The usefulness of /var/log/dmesg is that once dmesg wraps it's still available.
<pitti> rbasak: nothing is kept indefinitely :) (logrotate etc.)
<rbasak> If systemd can still wrap, I think it'd still be useful to have /var/log/dmesg.
<mdeslaur> I do seem to have my dmesg stuff in /var/log/kern.log
<pitti> yes, journal will wrap eventually, depending on the amount of RAM (or disk, if you use persistancy)
<pitti> mdeslaur: yes, that too
<pitti> we cleaned up some of rsyslog's duplication a while ago, but there's still plenty
<pitti> and as long as we install rsyslog I don't want to enable persistant journal by default
<pitti> we already hit/wake up the disk enough as it is
<mdeslaur> nah, no sense logging twice
<mdeslaur> and dmesg is in kern.log
<mdeslaur> so I don't see why a separate /var/log/dmesg is required
<pitti> yes, me neither; that's why I never bothered to port it, it's just the fourth duplicate
<rbasak> pitti: /var/log/dmesg was previously kept at least until next boot
<rbasak> mdeslaur, pitti: kern.log eventually rotates round within the same long-lived boot
<rbasak> Nevertheless it's useful to see what the kernel said on boot without having to reboot
<rbasak> That's where /var/log/dmesg comes in.
<ogra_> there was an upstart job that just echoed dmesg into that file right after boot ... /var/log/dmesg is really really helpful
<mdeslaur> rbasak: oh, I see, hrm
<pitti> well, lots of things are "really really helpful"
 * ogra_ is fully with rbasak here and would like to have it back
<pitti> but writing everything four times isn't
<rbasak> It's only small and is only written once on boot
<ogra_> well, dmesg eventually scrolls away
<rbasak> /var/log/dmesg doesn't get written or grow at any other time.
<ogra_> and there is no other log that has this info
<pitti> syslog is kept for a fair while
<pitti> ogra_: sure, /var/log/syslog, /var/log/kern.log, and the journal
<ogra_> syslo doesnt have these messages
<ogra_> and kern.log starts later as well
 * ogra_ buys a new g key
<rbasak> /var/log/dmesg is useful after a server has been running a really long time. After all logs have rotated away.
<ogra_> not only a server :)
<rbasak> :)
<pitti> rbasak: how is it more useful than, e. g. knowing what postfix did 233 days ago?
<rbasak> pitti: it's the kernel messages on boot that are useful.
<ogra_> right
<pitti> I mean, I do appreaciate log files, but it's always a trade-off between wakeups, disk space, and retaining information
<rbasak> pitti: since they are still relevant to the running system and aren't necessarily historical.
<pitti> and right now we rather have too much duplication still
<rbasak> No wakeups for /var/log/dmesg
<rbasak> Mine is 89K.
<ogra_> it is the one place where you have proper boot messages and its tiny
<rbasak> pitti: you realise /var/log/dmesg is only written on boot and never touched again, right?
<pitti> yes
<rbasak> pitti: get systemd upstream to not rotate the first dmesg output out, and then we won't need to keep a file with it any more. If you really want :)
<pitti> rbasak: systemd? linux you mean?
<rbasak> No I think linux would insist it's a userspace concern.
<pitti> but the entire dmesg is in the journal
<rbasak> It will rotate out, no?
<pitti> rbasak: dmesg is the kernel's ringbuffer
<rbasak> Yes, which rotates.
<pitti> rbasak: yes, depending on your disk space
<rbasak> OK. I'm saying that what was in the kernel's ringbuffer straight after boot is important, should be kept and should not rotate out ever.
<rbasak> It's ~100K so that shouldn't really be a problem at all.
<pitti> well, *shrug*, if you really care about yet another copy, I don't veto if someone adds that job to rsyslog; I just always foud it rather pointless
<rbasak> We already did it in /var/log/dmesg, so let's keep doing that unless there's a replacement.
<rbasak> OK, thanks :)
<pitti> if you find it useful, I mean
<rbasak> I have used it in the past a number of times.
<rbasak> Saves having to reboot to get that information.
<ogra_> yeah
<pitti> TBH, I didn't even know that it existed until now :)
<rbasak> "should not rotate out ever" -- well, rotating once-per-boot (like it did < Vivid) is fine.
 * pitti checks, journal logging on my desktop goes back to April 22
<rbasak> Sometimes things spam to dmesg
<rbasak> Logging with rotation is never expected to always go all the way back to boot.
<rbasak> (and that wouldn't be reasonable because of the space it might take)
<mdeslaur> caribou: see the can of worms you've opened? :)
<pitti> yeah, classical bikeshed territory :)
<ogra_> mdeslaur, well, we heard about a "new fledgling in the Foundations team nest" .... worms are the food of the day ;)
<pitti> you could have waited until Friday
<pitti> ogra_: *tweet* *tweet*
<ogra_> :D
<mdeslaur> heh
<caribou> mdeslaur: ouch, I stepped out a while & missed on all the fun :)
<mdeslaur> caribou: nice try :)
<caribou> mdeslaur: well, looks like the rsyslog merge (aside from bikesheding) in not as hard as it looked
<mdeslaur> caribou: cool
<caribou> mdeslaur: most of the diff was in the CVE that you uploaded a while ago & that was a backport from newer versions
<caribou> rbasak: back at the upstart migration to systemd topic, the main difference in the upstart job it that it takes care of the apparmor profile
<caribou> rbasak: so I do think that it is sufficient to justify migrating the job
<rbasak> caribou: I think systemd has syntax for AppArmor
<mdeslaur> caribou: you can drop the apparmor stuff if you convert it to a systemd unit
<mdeslaur> err, systemd service
<caribou> mdeslaur: why ? seems rather trivial to keep it
<mdeslaur> caribou: the apparmor stuff in upstart scripts was to prevent race conditions
<mdeslaur> caribou: the systemd unit file for apparmor should be started early enough for that to not be a problem
<caribou> rbasak: yeah, I found AppArmorProfile=, but according to the doc it still needs the profile to be loaded first
<mdeslaur> caribou: yeah, don't use apparmorprofile=
<caribou> mdeslaur: ah, ok
<gogis_> I know C/++, Python, Pascal, quite Java... I also understand Assembly and I can learn other languages quickly... can I somehow help with the development of ubuntu?
<gogis_> hmm, it's quiet here :D
<dobey> gogis_: do you have any particular things you are interested in helping with? there are plenty of bugs filed on launchpad (or in upstream bug trackers), which you could submit patches for
<gogis_> dobey: Well, firstly, I should probably learn something more about how these works :)
<gogis_> but where can I find the sources and how do I submit patches?
<dobey> gogis_: generally, the best place to submit patches is to upstreams.
<gogis_> dobey: okay, thanks :)
<chiluk> hallyn, re: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1451598   ... I talked to arges a few days back about pushing the SRU, and he told me that you were bundling up a few fixes for precise ... is that still true or was it an error in communication?
<ubottu> Ubuntu bug 1451598 in libvirt (Ubuntu Precise) "Libvirt spams libvirt.log with virNetSocketReadWire and similar errors" [Medium,New]
<arges> there are also some libvirt bugs needing verification before we can accept the current libvirt in the queue
<arges> #1425619 #1447030
<chiluk> arges 1425619 is a trusty only fix.
<chiluk> I'm concerned with precise only.
<arges> chiluk: its in the pending queue. i missed it yesterday
<arges> unapproved queue that is
<chiluk> arges 1379585 is the one we need verified
<chiluk> arges it looks like hallyn already verified 1379585
<chiluk> so I'm not sure what's holding up the promotion to updates..
<infinity> Huh.  I wonder why '-vga qxl' isn't the qemu default.  It actually functions sanely, unlike pretty much all the others.
<juliank> Any idea how I can trigger bug 1445949 ?
<ubottu> bug 1445949 in python-apt (Ubuntu) "Version does not conform to PEP440" [Undecided,New] https://launchpad.net/bugs/1445949
<juliank> I have a workaround that normalizes the part of the Debian versioning scheme we use to PEP440 (ubuntu => +ubuntu, ~alpha => .a, ~beta=>.b, ~rc => .rc, ~exp => .dev, build is stripped)
<juliank> This should make it happy, so I'd like to test it
<hallyn> chiluk: i have a sru list but none for precise, so feel free to push that one
<chiluk> arges ^^ do you mind?
<chiluk> thanks hallyn ... I'm not a core dev yet.
<arges> chiluk: sure
<hallyn> oh
<arges> chiluk: hallyn done
<chiluk> I guess that's an indication that I probably should be ..
<hallyn> what'd done exactly?  you pushed the fix for 1451598 ?
<arges> hallyn: i've accepted libvirt into precise-proposed
<arges> it was already sponsored
<hallyn> oooh.
<hallyn> i confused myself
<arges> i have the same problems too
<hallyn> well glad it's all settled :)  \0
<hallyn> thx arges
<dobey> infinity: hi! just curious on what else is holding up the nettle transition still. i see curl is a valid candidate now on the excuses page
<infinity> dobey: A little too much multitasking is preventing me from unwinding it all right this instant.
<dobey> infinity: ok
<infinity> dobey: We probably need to decouple it from the Haskell transition, but I haven't had time to see if anything else is also holding it up.
<dobey> ok.
<juliank> Can/Should somebody mark bug 1464305 as only affecting vivid, utopic, and trusty? Wily's ndiswrapper supports kernel 4.0. The other(s) need a tiny fix, if someone wants to SRU them (https://anonscm.debian.org/cgit/collab-maint/ndiswrapper.git/commit/?id=fe307aab912c55fb357670e5e838c353712a689b)
<ubottu> bug 1464305 in ndiswrapper (Ubuntu) "ndiswrapper-dkms 1.59-2: does not support kernel 4.0" [Undecided,New] https://launchpad.net/bugs/1464305
<juliank> Because the only thing to care about is the strncasecmp strnicmp rename in the kernel, so it's not like this could break anything in an SRU
#ubuntu-devel 2015-06-12
<pitti> Good morning
<Unit193> Heya.
<pitti> tyhicks, kirkland: *sigh*, more trouble with ecryptfs swap: bug 1453738
<ubottu> bug 1453738 in ecryptfs-utils (Ubuntu) "installer in LVM mode sets up broken encrypted swap, using duplicate unencrypted swap" [High,Triaged] https://launchpad.net/bugs/1453738
<pitti> it seems for the past several years we have set up unencrypted or broken swap and nobody noticed :/
<pitti> except that this bug is worse, as we unintentionally use unencrypted swap
<Mirv> something has just killed i386 building? https://launchpadlibrarian.net/208901928/buildlog_ubuntu-wily-i386.webbrowser-app_0.23%2B15.10.20150610-0ubuntu2_BUILDING.txt.gz happens on multiple sources
<Mirv> "dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None died with signal 11"
<Mirv> and i386 only
<Mirv> all cmake though
<Mirv> all I know is that they built on Wednesday at least
<Mirv> it seems cmake specific, but I don't see anything recent related to that uploaded
<Frantique> hello all
<Frantique> guys, why it is so slow to give a review to the updated packages on developer.ubuntu.com?
<zzzdeb> hello, is there any way i can create a deb package that makes a delay at install?
<Frantique> zzzdeb: perhaps a sleep in preinstall script?
<Frantique> or in postinstall, depending on the needs, ofcourse
<Mirv> actually, I had a successful build 13h ago, and now those cmake i386 failures
<caribou> I need some help with a merge :
<caribou> I have fixed all conflicts from grab-merge and trying to build the source pkg
<caribou> turns out that apparently one of the source in the tarball has been modified by grab-merge
<caribou> is it to be expected ?
<caribou> i.e. one patch from the previous version is applied in the merged output
<Mirv> caribou: I'm not sure if I understand the context, but you might want to change the source version number (if the source is not actually same anymore), or unapply the patch if it has been accidentally applied and should actually be in debian/patches and only applied at build time
<Mirv> Frantique: you could try asking on #ubuntu-app-devel regarding the review
<caribou> Mirv: that's what I'm doing atm. I got the pristine source from the tarball & crafting a quilt patch to keep the modification applied
<caribou> Mirv: I am just surprized that MoM didn't flag that as a conflict
<Frantique> Mirv: thanks
<zyga> cjwatson: hey, do you know who I can ping to get tarmac reviews?
<zyga> cjwatson: I sent out an introductionary merge request a few days ago but without any response
<zyga> cjwatson: I'm working on more changes locally to actually do stuff but I'm worried with the lack of response so far
<LocutusOfBorg1> Hi ubuntu sponsors, your opinion on bug 1297849 ?
<ubottu> bug 1297849 in network-manager-vpnc (Ubuntu) "[SRU] Virtual private network connection fails after distribution upgrade due to outdated Network Manager configuration files" [High,Triaged] https://launchpad.net/bugs/1297849
<LocutusOfBorg1> seems that syncing network-manager* stuff from debian might be the easiest solution, at least for wily
<Mirv> infinity: we believe the gnutls broke all i386 cmake builds https://launchpadlibrarian.net/208901967/buildlog_ubuntu-wily-i386.unity8_8.02%2B15.10.20150603.1-0ubuntu2_BUILDING.txt.gz
<Mirv> sil2100: ^
<Mirv> that's the only thing that matches the timing, and it seems gnutls is somehow used by cmake at least
<Mirv> sil2100: infinity1: confirming i386 building without an issue without -proposed, so I filed bug #1464569
<ubottu> bug 1464569 in gnutls28 (Ubuntu) "3.3.15-5ubuntu1 breaks CMake on i386" [Undecided,New] https://launchpad.net/bugs/1464569
<cjwatson> zyga: if it were me I would try the last three or four people from the intersection of (has committed to trunk, is in the team that can do so)
<zyga> cjwatson: thanks
<sil2100> Mirv: thanks!
<sil2100> infinity1: we'll have to do something with the new gnutls28 as it's really breaking stuff
<cjwatson> Does a straight cmake rebuild fix things?  (Would be quick to try locally, I expect)
<cjwatson> Or possibly a curl rebuild
<LocutusOfBorg1> cjwatson, sil2100 Mirv
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1462934
<ubottu> Ubuntu bug 1462934 in gnutls28 (Ubuntu) "please merge gnutls28 from Debian" [Undecided,Fix released]
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1459685/comments/9
<ubottu> Ubuntu bug 1459685 in curl (Ubuntu) "please merge curl from debian" [Undecided,Confirmed]
<LocutusOfBorg1> ^^^^
<LocutusOfBorg1> unfortunately it has been uploaded before gnutls, not after :)
<LocutusOfBorg1> You might look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784009 too
<ubottu> Debian bug 784009 in libgnutls-deb0-28 "Lack of versioned symbols in nettle causes segfault" [Serious,Fixed]
<sil2100> Oh :)
<sil2100> LocutusOfBorg1: thanks!
<LocutusOfBorg1> I mentioned in the merge request, but not enough loudly ;)
<LocutusOfBorg1> sorry for the confusion
<LocutusOfBorg1> thanks to you!
<zyga> cjwatson: hey, did you see my question about ppa and code exporter earlier
<zyga> cjwatson: I'm curious if the restriction not to export bzr branches from launchpad-based git branches
<cjwatson> zyga: I think you were offline when I tried to reply
<cjwatson> zyga: Where do PPAs come into it?
<zyga> cjwatson: is intentional or a tech limitation
<zyga> cjwatson: and what is the recommended way to get ppa packages built from git repos
<zyga> cjwatson: perhaps, I had some issues with my machines latelty
<zyga> cjwatson: they are built from recipes
<zyga> cjwatson: from bzr branches
<cjwatson> zyga: And indeed, there is such a restriction on code imports at the moment (historically, it was to prevent circular imports from other bzr branches on LP), which we'll lift soon
<cjwatson> zyga: Recipes are on the to-do list, which I'm pretty sure I've told you before, we don't have a "recommended way" yet
<zyga> cjwatson: that makes sense, so the recommended way will be to use bzr exportrs for recipes?
<cjwatson> There will probably be a transitional period when LP-git-to-LP-bzr imports work but recipes don't yet
<cjwatson> But we do intend to make recipes work for git too
<zyga> cjwatson: oh, I must have missed that, thank you
<cjwatson> The import limitation dates from bug 820069
<ubottu> bug 820069 in Launchpad itself "BadUrlLaunchpad raised mirroring a branch" [Critical,Fix released] https://launchpad.net/bugs/820069
<cjwatson> Well, and a similar thing in the codeimport worker
<cjwatson> Which is rather older, 2007-era
<rbasak> shaderslayer: test docker.io backport packages at https://launchpad.net/~docker-maint/+archive/ubuntu/staging. I will review and upload for SRUs soon.
<shaderslayer> rbasak: thanks!
<rbasak> shaderslayer: please let us know how you get on
<shaderslayer> will do :)
<shaderslayer> rbasak: oh, would have been nice to have armhf packages too
<rbasak> shaderslayer: can you rebuild locally OK? The PPA just isn't enabled for armhf that's all.
<rbasak> shaderslayer: when we upload to Ubuntu you'll get armhf
<shaderslayer> rbasak: yeah, I reckon we'll do that
<infinity> sil2100: Ugh.  Who turned off proposed in that silo to make the package build?  That's not helpful.
<arges> hallyn: does lxc by default set any cgroup.cpu.* settings?
<arges> hallyn: n/m i can just lxc-info it
<hallyn> arges: nope
<arges> hallyn: thanks, yea see it now
<barry> pitti: are you still around?  q re: adt-run
<sil2100> infinity: we did that, the unity8 was required for a landing
<infinity> sil2100: ...
<sil2100> infinity: it's eaisly reproducible in anything ;p!
<sil2100> Mirv reproduced it with some strange package in his PPA
<infinity> sil2100: That's not the point.  Those PPAs have proposed enabled for a reason.
<infinity> sil2100: Skipping past transitions in proposed means the transitions never finish (and can even regress).
<infinity> sil2100: Was unity8 in *wily* that important that it couldn't wait for a proper fix?
<sil2100> infinity: ok, sorry about that then, we didn't know it depended actually on anything that was in transition, it was a dual landing so it required landing to both places, wily first even
<sil2100> Since we thought that the problem was in a dependency of a dependency
<infinity> sil2100: Might be a process failure if "dual landing" implies "hack around breakage in the devel series".
<infinity> sil2100: It may well have not caused an issue, I haven't checked, but generally, turning off proposed is a Bad Thing.
<infinity> sil2100: And I keep running into silo PPAs where it's been turned off and never back on, which is also irksome.
<sil2100> infinity: noted, well, having proposed enabled also includes additional risks, especially when you land to the overlay without proposed-migration, since you could basically build against a broken library that would be dropped
<sil2100> So it's a double-edged sword anyway
<sil2100> infinity: I have re-enabling the PPA to use -proposed in my daily-doings, so this one wouldn't be forgotten
<infinity> sil2100: Anyhow, I'd argue the process needs revision to match the SRU process.  SRUs require "fix in devel", but that really just means "uploaded, so we don't lose the code change", not "uploaded, built, and migrated" or anything.
<infinity> sil2100: dual landing should likely be similar.  The goal is to not lose the change, not to force people to hack around temporary problems just to get B landed before A.
<sil2100> infinity: right... sadly right now the dual landing required landing both at once
<sil2100> We *could* release just one, but only after removing binaries of the other from the PPA
<sil2100> Which sucks a bit
<sil2100> But yeah, dual-landings is a quick helper thing
<smoser> infinity, i suspect you know if anyone... is there a way that i can disable initramfs update that would happen as a result of 'apt-get install' operation ?
<smoser> strikov and i are wanting to avoid that as we know we're going to haev to update ourselves. and just want to save some time.
<cjwatson> The standard way we use in various places is to divert it aside temporarily and replace with a trivial wrapper.  See livecd-rootfs for example.
<ogra_> mv  /usr/sbin/update-initramfs /usr/sbin/update-initramfs.real && ln -s /bin/true /usr/sbin/update-initramfs
<ogra_> (and revers it after update)
<cjwatson> Please use dpkg-divert instead.
<cjwatson> I gave a pointer already which is better.
<ogra_> yeah, sorry, i was typing :)
<cjwatson> You don't want your work to be undone if an initramfs-tools upgrade happens to arrive.
<ogra_> indeed, thats just a quick hack ... diverting is the proper way
<DreadPirateBob> Getting a failure on launchpad in my PPA. bzr bd -- -k <parentkeyid> is signing with <subkeyid>. dput succeeds, but the build fails because it doesn't recognize the key.
<DreadPirateBob> Anyone know how to get this working?
<DreadPirateBob> barry maybe? (Hi Barry)
<DreadPirateBob> Nevermind. Confusing output, but not an error.
<barry> DreadPirateBob: ok... and hi!
<DreadPirateBob> backportpackage showed the right thing, so I was confused
<cjwatson> DreadPirateBob: You mean the complaint about being unable to check the signature on the .dsc?
<cjwatson> Or possibly the one about the public key for the archive on ppa.launchpad.net being unavailable.  Either way, we should suppress both of those when we get round to it, but at least it's only cosmetic.
<DreadPirateBob> This was two fold: when I ran bzr bd -S -- -k<myparentkey>, when it got to the signing part, it prompted me for the subkey. Then dput verified using the subkey, and then showed a warning in the build log that the key could not be verified.
<DreadPirateBob> but the subkey is not shown in the launchpad ui
<DreadPirateBob> probably just a display setting.
<meles> I'm havin a problem when trying to get my ambient light sensor working. I would need the value of /sys/class/backlight/acpi_video0/max_brightness which is not found. Instead I have /sys/class/backlight/intel_backlight/max_brightness. Is there any way to link it?
<shadeslayer> does anyone know how to switch to the gold linker for a package?
<shadeslayer> -fuse-ld=gold for now I guess :3
<cjwatson> DreadPirateBob: Right, anything you see in the build log about key verification is cosmetic and should be silenced; Launchpad does all the verification well before it gets to the point of building the source package, and doesn't need to do it again there, but we haven't made all the warnings shut up :-)
#ubuntu-devel 2015-06-13
<shadeslayer> xnox: ping
<shadeslayer> xnox: I've just been passed this patch for multiarch http://paste.ubuntu.com/11705191/
<shadeslayer> in cmake
<shadeslayer> xnox: apparently multiple cmake runs are screwed without this
<shadeslayer> xnox: ( Only the first few lines matter I think )
<cedian_linux> is there also a ubuntu-touch dev support?
<Blastyr> Hey guys. I have a specific question about the installer that I hope someone can answer. Can I (and if yes, how do I) invoke the expert installer when booting the install media in UEFI mode?
<happyaron> wonders how to add a private PPA...
<happyaron> oh got it
<procyonidae> jjohansen I got true problems with my compiling for touch
#ubuntu-devel 2015-06-14
<Logan> anyone know the deal with cmake builds failing on certain arches by being killed with signal 11?
<Logan> er, builds of packages that use cmake as their buildsystem, not builds of cmake itself
<infinity> Logan: That should have been resolved, I thought, unless I missed something.  Do you have an example?
<Logan> just happened
<infinity> Logan: There was a poorly (read: not at all) planned nettle transition that kinda blew up the world.
<Logan> https://launchpad.net/ubuntu/+source/choqok/1.5-2ubuntu1/+build/7539310
<Logan> https://launchpad.net/ubuntu/+source/openturns/1.5-7/+build/7539095
<infinity> Logan: Fun.  Okay.  Still more transition to fix, then.  I didn't look very closely before the weekend, cause I had more pressing things to deal with.
<Logan> looks to just be i386, actually
<Logan> what's the technical explanation behind this?
<infinity> Logan: The technical explanation is that nettle doesn't do symbol versioning, so if we're half transitioned and both libnettle4 and libnettle6 end up loaded in the same process space, they stomp all over each other.
<infinity> Logan: I think I just uploaded the last library (libarchive) that affect cmake in such a way, so we can do some build retries in a bit.
<infinity> Logan: Not sure I feel like hunting down the rest of the transition at 1:30am.
<Logan> ah, gotcha
<infinity> Logan: cmake seems happy again.
<wgrant> cjwatson: Could you please commit https://launchpad.net/ubuntu/+source/grub2/2.02~beta2-25ubuntu1 to Debian git?
<cjwatson> wgrant: Already did and uploaded
<cjwatson> Though I only just pushed it - git.d.o was down earlier
<wgrant> Oh
<wgrant> I checked git.d.o like 5 minutes ago :)
<cjwatson> Thanks for the fix
<wgrant> Thanks.
<ogra_> :D
<ogra_> oops
<ogra_> that was totally not intended ... silly focus
<wgrant> Broken bootloaders make me happy too :)
<micahg> could I please get someone to retry https://jenkins.qa.ubuntu.com/job/wily-adt-libconfig-model-dpkg-perl/lastBuild/
<micahg> the amd64 test seems to be a bit flaky, I was only able to get it to fail once and cannot reproduce anymore
<Laney> micahg: doin'
<micahg> thanks
<Unit193> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788580 would be important.
<ubottu> Debian bug 788580 in pbuilder "pbuilder: No more mounts /dev/pts inside the chroot if host is running systemd 220, causing packages to FTBFS" [Important,Open]
#ubuntu-devel 2016-06-13
<jbicha> mwhudson: could you nominate bug 1432271 bug 1484785 and bug 1586708 for wily and xenial please?
<ubottu> bug 1432271 in One Hundred Papercuts "[SRU] Abiword always starts after logging in" [High,Triaged] https://launchpad.net/bugs/1432271
<ubottu> bug 1484785 in abiword (Ubuntu) "language selector text cut off in abiword" [High,Fix released] https://launchpad.net/bugs/1484785
<ubottu> bug 1586708 in abiword (Ubuntu) "Abiword icon has extra smaller icons included" [Undecided,Fix released] https://launchpad.net/bugs/1586708
<slangasek> LocutusOfBorg: yes, it's possible to demote botch or ignore its testsuite; please tell us which is the more correct here and why :)
<slangasek> LocutusOfBorg: fwiw the disabling of botch autopkgtest was already done as of 0.16-2ubuntu2 in xenial, this was not a behavior change introduced in the new merge.
<pitti> slangasek: can you please approve to yakkety and set an adequate priority, ÏÎ±ÏÎ±ÎºÎ±Î»Ï? https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-network-yaml
<seb128> cyphermox, hey, could you look at bug #1591622? it might be a regression from your console-setup xenial SRU which is in proposed currently
<ubottu> bug 1591622 in console-setup (Ubuntu) "Can't login to system, system is booting up error" [High,Confirmed] https://launchpad.net/bugs/1591622
<flexiondotorg> I'm working on getting the Ubuntu MATE seeds to follow recommends.
<flexiondotorg> I have indicator-session in the Ubuntu MATE live seed. When recommends are followed this pulls in gnome-control-center or unity-control-center.
<flexiondotorg> However, because MATE uses (proxies) the same namespaces for session management, no code changes are required in indicator-session.
<ogra_> yeah, recommends are fun :)
<flexiondotorg> Only a debian/control change is required.
<flexiondotorg> So, which would be best debdiff or merge proposal?
<slangasek> pitti: you mean 'ÏÎ±ÏÎ±ÎºÎ±Î»Ï;' ;)
<pitti> slangasek: you mean the semicolon is mandatory?
<slangasek> pitti: (done)
<slangasek> pitti: ?-(Greek)->;
<seb128> flexiondotorg, you want a merge request for indicator-session changes
<seb128> it's maintained in a bzr vcs and landing through ci
<infinity> flexiondotorg: What are you trying to fix?
<flexiondotorg> infinity, That unity or gnome control-center or pulled in which also pulls in their session manager.
<infinity> flexiondotorg: What's the proposed fix?
<flexiondotorg> So in Ubiquity DM, the GNOME or Unity session manager is used in preference to MATEs.
<flexiondotorg> Meaning none of the MATE settings are used.
<flexiondotorg> infinity, unity-control-center | gnome-control-center | mate-control-center in debian/control for Recommends.
<flexiondotorg> I'm just testing locally to be sure this fix is correct.
<infinity> Ahh, yeah.  That'd probably do.  Don't forget the unity-control-center-signon bit too.
<flexiondotorg> infinity, Yes, I was going to pull in gnome-control-center-signon, but I'm not sure that will help.
<flexiondotorg> There is no MATE alternative for to signon however.
<infinity> flexiondotorg: Well, if you don't need that bit, just make the signon stuff also depend "| mate-control-center"
<flexiondotorg> And it is not required, so I am considering making that unity-control-center-signon | gnome-control-center-signon | mate-settings-daemon
<flexiondotorg> infinity, Yeah, or your idea seems more sensible :-)
<infinity> libaccount-plugin-1.0-0 will also cause you some issues there.
<infinity> Maybe.
<infinity> Or maybe that's just a loop.
<infinity> Yeah, that might just be a loop.
<cyphermox> seb128: looking
<flexiondotorg> seb128, yelp recommends gnome-user-guide. mate-user-guide also uses yelp.
<flexiondotorg> So I want to change that Recommends to gnome-user-guide | mate-user-guide
<Unit193> Drop to suggests. >_>
<flexiondotorg> Unit193, Or that.
<flexiondotorg> I'd prefer that.
<Unit193> Xubuntu wants neither, honestly.
<flexiondotorg> Indeed.
<flexiondotorg> seb128, Laney Looks like I can't upload or make a merge proposal for https://code.launchpad.net/~ubuntu-desktop/yelp/ubuntu
<flexiondotorg> Will a debdiff do?
<Laney> Do a branch and ask someone to merge it manually if you can't do a merge proposal
<flexiondotorg> Laney, OK, merge proposal is possible :-)
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/yelp/mate-compatibility/+merge/297171
<flexiondotorg> Unit193, ^^^
<cpaelzer> rbasak: do you have a minute for a few best practise hints on package upgrade testing?
<cpaelzer> I'm not getting lucky with piuparts and I start to think my case is too special
<rbasak> cpaelzer: sure.
<cpaelzer> rbasak: thanks - anybody else feel free to jump in if you want to share a better approach :-)
<cpaelzer> rbasak: I wanted to test the clamav fix we were discussing next week before going SRU with it
<cpaelzer> TL;DR case:
<cpaelzer> A-old in Trusty, A-new-broken in W&X, A-new-fixed local (sbuild)
<cpaelzer> I'd like to test a Trusty -> Xenial Upgrade (with A-new-fixed)
<cpaelzer> would need something like a do-release-upgrade + ppa
<cpaelzer> probably not the most important case here, but I can discuss and learn in this case as much as in any critical one later on
<cpaelzer> rbasak: ^^
<rbasak> cpaelzer: piuparts is a tool that may be able to help. I'm not sure if it's an exact fit to your problem though.
<cpaelzer> as I wrote, so far it didn't make me happy :-)
<rbasak> cpaelzer: to do it manually, then a PPA with dist-upgrade (not sure how to use a PPA with do-release-upgrade but dist-upgrade is close enough for most purposes).
<cpaelzer> if anything I think I spottet only unrelated issues in piuparts
<rbasak> Oh, sorry, I missed that.
<rbasak> Instead of a PPA you can use a local repository.
<rbasak> apt-ftparchive can create the packages and releases files.
<cpaelzer> hmm, the problem will be that due to dependencies I'd need to build almost the full distro
<cpaelzer> since the newer packages depend on Xenial things
<cpaelzer> do you suggest building the new package, but for Trusty?
<cpaelzer> let me read apt-ftparchive ...
<rbasak> http://paste.ubuntu.com/17288886/ is what I use
<rbasak> gpg is optional - you can use [trusted=yes] in sources.list instead.
<cpaelzer> ok, with that I could go to a trusty container and build my local archive for the packages - thanks
<cpaelzer> that is similar to what we used for the nis test back in manchester
<rbasak> cpaelzer: build the proposed fixed package in Xenial using a Xenial chroot, and then put it in its own repository. Start a Trusty machine (container should do), dist-upgrade to latest Trusty, then s/trusty/xenial/ in sources.list, add your local archive to override the new A, and then dist-upgrade.
<rbasak> cpaelzer: you can verify what apt sees with "apt-cache policy"
<cpaelzer> ok, now I see how you avoided do-release update
<cpaelzer> thanks
<cpaelzer> nice plan
<cpaelzer> will give that a try
<rbasak> It would be nice if do-release-upgrade grew a feature for a third party apt source for testing purposes.
<rbasak> cpaelzer: if using lxd you may hit bug 1580984.
<ubottu> bug 1580984 in systemd (Ubuntu) "procps postinst fails when inside lxd" [Medium,Confirmed] https://launchpad.net/bugs/1580984
<cpaelzer> thanks for making me aware before I ran too deep into it rbasak
<jbicha> dholbach: could you target bug 1484785 and bug 1586708 for wily and xenial too? thanks
<ubottu> bug 1484785 in abiword (Ubuntu) "language selector text cut off in abiword" [High,Fix released] https://launchpad.net/bugs/1484785
<ubottu> bug 1586708 in abiword (Ubuntu) "Abiword icon has extra smaller icons included" [Undecided,Fix released] https://launchpad.net/bugs/1586708
<dholbach> sure
<flexiondotorg> cjwatson, I am right in thinking that adding a Recommended package to blacklist in the seeds should prevent that package ever being listed in the germinate output?
<cjwatson> flexiondotorg: blacklist entries should almost never be used
<flexiondotorg> cjwatson, Yes. I read that too.
<cjwatson> flexiondotorg: the problem with them is that it is extremely difficult to cause them to be in sync with the output of apt
<cjwatson> flexiondotorg: so no, I don't think you're right
<flexiondotorg> I'm trying to understand if they actually work at all.
<cjwatson> flexiondotorg: their only useful purpose is to cause a hard error if something sneaks in that definitely shouldn't
<flexiondotorg> I've seen Xubuntu and Ubuntu MATE are trying to use blacklist to prevent unnecessary Recommends: gettings seeded.
<cjwatson> flexiondotorg: please don't waste much time investigating them, 99% of attempts to use them are wrong
<flexiondotorg> gnome-user-guide for example.
<flexiondotorg> I've been filing merge proposals to fix some of the at source.
<cjwatson> yeah that's really what you have to do
<flexiondotorg> But still puzzled what blasklist does, versus what it is intended to do.
<flexiondotorg> What do you mean by "hard error"? Where would that be visible?
<flexiondotorg> cjwatson, I'm trying to make Ubuntu MATE seeds follow recommends, mostly to ensure the live seed never breaks. Which is has in the past.
<cjwatson> Sorry, I can't really remember the details right now
<cjwatson> The blacklisting support was added in order to be able to ensure that libavcodec never got onto Ubuntu images
<flexiondotorg> But I would actually like the desktop seed to no-follow-recommends.
<flexiondotorg> Can I just add  * Feature: no-follow-recommends to the desktop seed?
<cjwatson> I suspect it's not actually a germinate-level error, but it results in incomplete images that are uninstallable (because it just ignores that bit of the dependency tree)
<cjwatson> I never bothered to gold-plate it very much
<flexiondotorg> Or does it also require "feature no-follow-recommends" in STRUCTURE?
<cjwatson> flexiondotorg: You *must* keep that in sync with how livecd-rootfs builds your image
<cjwatson> You will get very very very confused if it's not in sync
<cjwatson> flexiondotorg: "feature no-follow-recommends" in STRUCTURE doesn't do anything
<flexiondotorg> cjwatson, Good to know.
<flexiondotorg> So if I want one seed to not follow recommends is that possible?
<cjwatson> At the germinate level, yes; but as I say, you must keep that in sync with what apt is going to do.
<cjwatson> Think of germinate sort of like a cheap apt simulator.
<cjwatson> So you should first look at whether you can implement what you're asking for in livecd-rootfs when it builds the image, and then look at keeping the seeds in sync with that.
<flexiondotorg> cjwatson, livecd-rootfs for Ubuntu MATE does currently instruct apt to not follow recommends.
<flexiondotorg> Not sure if that is for all seeds?
<cjwatson> I don't know, you'll have to work that out.
<flexiondotorg> cjwatson, OK, thanks for the time.
<flexiondotorg> I think I've learned the Blacklists won't do what I require.
<cjwatson> It can be difficult to make that per-seed.
<cjwatson> Because apt doesn't really know about seeds, so things may get confusing on upgrade.
<flexiondotorg> I'll test desktop seed not following recommends.
<flexiondotorg> OK. I'll give it a good test.
<flexiondotorg> See what works.
<cjwatson> Remember that when you upgrade a system it's going to upgrade (say) ubuntu-standard and ubuntu-mate-desktop at the same time, and follow recommends for either both or neither.
<flexiondotorg> Right.
<flexiondotorg> Understood.
<cjwatson> This is why I think that attempts to tweak Recommends following on a per-flavour basis are mostly doomed to eventual failure.
<cjwatson> Even if it doesn't seem so at first.
<cjwatson> So you *can* do it, but you have been warned :-)
<flexiondotorg> Warning heeded.
<flexiondotorg> The objective is to get everything in Ubuntu MATE following recommends.
 * cjwatson nods
<cjwatson> Good good
<kgunn> stgraber: hey there, i know you solved the xenial boot on phone lxc issue...just wanted to check, where we need to track the change?
<kgunn> assuming it was prollly specific to android lxc
<happyaron> infinity: mind to accept the network-manager-applet SRU to -proposed? version 1.2.0-0ubuntu0.16.04.3
<cpaelzer> rbasak: fortunately the tests worked in containers (my uvt-kvm has issues recently)
<cpaelzer> rbasak: the good thing, it unveiled the debdiff was incomplete - there were even more file moves than reported in the bug :-)
<cpaelzer> rbasak: integrated in the next debdiff and a reproducible testcase available now
<cpaelzer> rbasak: thanks for your help with the local repo and normal upgrade instead of do-release-upgrade path
<smoser> doko, thank you for fix to bug 1584147. it seems fixed on my end.
<ubottu> bug 1584147 in python3.5 (Ubuntu) "cloud-init hangs on boot as Python waits for sufficient randomness to start" [High,Confirmed] https://launchpad.net/bugs/1584147
<smoser> pitti, ^ fyi
<infinity> tdaitx: FWIW, the bug you want to file is actually https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811181 (ie: it's already filed)
<ubottu> Debian bug 811181 in apt "apt: Please document auth.conf" [Wishlist,Open]
<infinity> tdaitx: You want /etc/apt/auth.conf with a format like "machine ppa.lp.net/foo/bar/ubuntu\nlogin username\npassword 12345"
<infinity> tdaitx: Then your sources.list can drop the creds and be 644.
<pitti> smoser: yes, I noticed; I also stopped getting "instance timed out waiting for ssh" worker death mails \o/
<stgraber> kgunn: it's just one file that needs to be updated in the lxc-android-config package and uploaded to the archive, looked like someone was tracking this in the bug report
<kgunn> excellent and thanks for the help stgraber
<stgraber> np, glad that we finally got to the bottom of this one
<nacc> rbasak: just an fyi, the upload of phpunit-mock-object is a 'known-to-fail' build due to needing to bootstrap. So the merge is still good, in case you were wondering.
<rbasak> nacc: I thought it might be something like that. Thank you for confirming.
<nacc> rbasak: np, sorry for not warning you ahead of time
<nacc> infinity: --^ so the version of phpunit-mock-object has been uploaded to proposed. Not sure if you got a chance to look at the bootstrap yet.
<nacc> infinity: slangasek: let me know if either of you are able to look at that bootstrap request for phpunit. I assume it requires an AA to do it.
<nacc> Logan: in case you missed it, I figured out last week what's needed to get phpunit (php-codecoverage/phpunit-mock-object) working. It requires a bootstrap build in the archive of those three packages.
<nacc> infinity: slangasek: fwiw, I filed LP: #1592139 to keep track of it (for myself)
<ubottu> Launchpad bug 1592139 in phpunit-mock-object (Ubuntu) "Please bootstrap build phpunit, phpunit-mock-object and php-codecoverage" [Undecided,New] https://launchpad.net/bugs/1592139
<nacc> cjwatson: --^ i did subscribe ~ubuntu-archive to that bug, because I believe I need an AA to help out. Not sure if that's appropriate or not, please CMIIW
<nacc> cjwatson: only directing at you, as you're listed as the owner of said group :)
<cjwatson> Yeah, it's appropriate
<cjwatson> If nobody else gets round to it first then I'll do the bootstrap tomorrow
<nacc> cjwatson: ok, thanks -- didn't find much documentationa about this specific case
<cjwatson> I suspect it is entirely in a few people's heads
<nacc> cjwatson: thanks! i know folks are sprinting and such, but this will hopefully clear up a bunch of php* stuff in -proposed
<cjwatson> I'm not sprinting, so :)
<nacc> :)
<cjwatson> (But I am on vacation today, so on principle I should leave it till tomorrow ...)
<nacc> cjwatson: totally fine by me
<tsimonq2> I have a question relating to the chromium-browser package, it is currently FTBFS, but there has been an upstream release. Would it be appropriate to update to the upstream release, then see if there is still an FTBFS, if not, then ask for that to be sponsored? Or should the FTBFS be fixed, then the upstream release?
<tsimonq2> but in Debian, the chromium package is updated to where it needs to be
<tsimonq2> I don't know if it comes from Debian, if so, I'll update the Ubuntu package with Debian revisions
<tsimonq2> thoughts?
<dobey> tsimonq2: i think you need to talk to qengho on #ubuntu-desktop
<tsimonq2> dobey: okay, thank you
<dobey> i think he's still the one doing chromium related stuff
<nacc> tsimonq2: reading the launchpad page(s) and rmadison output, it seems like yakkety needs either a merge or sync by someone
<nacc> tsimonq2: as debian is currently at 51.0.2704.79-1 and yakkety-proposed is at 50.0.2661.102-0ubuntu1.1242
<tsimonq2> yeah
<nacc> tsimonq2: but yeah, it seems like qengho was TIL, so that's probably the right place to start, might just need a re-merge if that FTBFS has already been fixed.
<tsimonq2> nacc: well it builds fine in Debian, so maybe :)
<jbicha> tsimonq2: chromium in Debian and chromium in Ubuntu are managed rather differently; they aren't kept in sync at all
<tsimonq2> oh really jbicha? how so?
<nacc> that's what i was going to ask next
<nacc> tsimonq2: all the ubuntu versions have -0ubuntu suffixes
<jbicha> you should probably talk in #ubuntu-desktop about that...
<elbrus> nacc: autopkgtest for cacti on armhf improved a tiny bit. At least you can now see in the artifacts that apache crashes.
<elbrus> *** Error in `/usr/sbin/apache2': double free or corruption (fasttop): 0xb7359660 ***
<elbrus> [Mon Jun 13 02:22:16.497596 2016] [core:notice] [pid 13694] AH00052: child pid 13699 exit signal Aborted (6)
<nacc> elbrus: heh, cool -- any ideas why? (haven't looked yet myself)
<elbrus> nacc: lots of php timeouts before that.
<nacc> elbrus: looking
<elbrus> so I suspect the server is overloaded
<nacc> elbrus: yeah, and the armhf machine maybe slower anyways, so i wonder if that 30s timeout is appropriate
<nacc> might just need to be a known-bad test on armhf, as it is marked now (for php7.0)
<elbrus> well, that is the default I guess
<elbrus> should I try to increase the timeout then (on armhf?)
<elbrus> going to be ugly...
<nacc> i'm honestly not sure; it seems like that might fix things, but it feels super-hacky
<elbrus> indeed
<nacc> and might end up masking a real error eventually
<elbrus> but it succeeded in the past
<nacc> yeah, i wonder what changed, if anything, with the machine
<elbrus> maybe just more used
<elbrus> any idea who to ask to have a look? pitti?
<dosaboy> bdmurray: is there anything i need to do to get this moving - https://bugs.launchpad.net/ubuntu/+source/python-os-brick/+bug/1521396
<ubottu> Launchpad bug 1521396 in python-os-brick (Ubuntu Wily) "[SRU] Fix iopsLimit parameter in ScaleIO connector" [Medium,New]
<nacc> elbrus: i was just thinking about that ... not sure
<bdmurray> dosaboy: looking
<bdmurray> dosaboy: accepted it
<dosaboy> bdmurray: \o/
<dosaboy> thanks
<Logan> nacc: figured as much - best of luck!
<tsimonq2> !info snapd yakkety
<ubottu> snapd (source: snapd): Tool to interact with Ubuntu Core Snappy.. In component main, is optional. Version 2.0.2 (yakkety), package size 2745 kB, installed size 14700 kB
<tsimonq2> !info snapd xenial-updates
<ubottu> 'xenial-updates' is not a valid distribution: kubuntu-backports, kubuntu-experimental, kubuntu-updates, partner, precise, precise-backports, precise-proposed, stable, testing, trusty, trusty-backports, trusty-proposed, unstable, utopic, utopic-backports, utopic-proposed, vivid, vivid-backports, vivid-proposed, wily, wily-backports, wily-proposed, xenial, xenial-backports, xenial-proposed, yakkety, yakkety-backports, yakkety-proposed
<tsimonq2> !info snapd xenial
<ubottu> snapd (source: snapd): Tool to interact with Ubuntu Core Snappy.. In component main, is optional. Version 2.0.8 (xenial), package size 3581 kB, installed size 17156 kB
<nacc> Logan: thanks :)
<juliank> infinity: Around? I'm preparing for the apt 1.2.13 xenial SRU. I unfortunately forgot to open a SRU placeholder bug and reference it in the changelog, so we cannot sync this way, but there's #1573547 that we could reuse as the SRU tracking bug (it's the only bug in launchpad closed by the upload anyway). Opinion?
<juliank> Probably should sync 1.3~exp2 to yakkety first, though :/
 * juliank wishes apt would autosync from experimental if available
<juliank> I now updated bug 1573547 to include the SRU part, makes more sense than to create another bug and makes the uploading easier :)
<ubottu> bug 1573547 in apt (Ubuntu) "Apt's bash completion is incomplete" [Low,Fix committed] https://launchpad.net/bugs/1573547
<juliank> APT yakkety sync: bug 1592171
<ubottu> bug 1592171 in apt (Ubuntu) "Sync apt 1.3~exp2 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/1592171
<juliank> I feel like requestsync does not work well for syncing as an SRU
<juliank> It would just create a "Sync apt 1.2.13 (main) from Debian unstable (main)" subject, and the only place it mentions xenial is in "Changelog entries since current xenial version 1.2.12~ubuntu16.04.1"
<juliank> I feel like that would just confuse people and end up with them trying to sync 1.2.13 to yakkety
#ubuntu-devel 2016-06-14
<jbicha> I use requestsync for merges too, I just change the subject and the description fields to match what I'm trying to do
<jbicha> you can do that before you submit or after
<jbicha> I'm really happy you're fixing that for xenial :)
<cpaelzer> good morning
<cking> pitti, can you help me out on bug 1579036, i've verified the SRU for xenial and it's been stuck in -proposed for a while
<ubottu> bug 1579036 in spl-linux (Ubuntu Xenial) "add dep8 tests for the scripts/check.sh SPL/SPLAT tests" [Medium,Fix committed] https://launchpad.net/bugs/1579036
<chiluk> hey debfx, do you know what's going on with the ubuntu quassel package?  I was looking at doing the merge for it, and the debian/control file points at Vcs-Bzr: lp:~ubuntu-dev/quassel/ubuntu and Vcs-Browser: http://bazaar.launchpad.net/~ubuntu-dev/quassel/ubuntu which both seem out of date.  Should I just ignore those referenced projects and update the control file to point elsewhere?
<ginggs> chiluk: from what i can tell, quassel is maintained independently in ubuntu
<ginggs> in https://launchpad.net/ubuntu/+source/quassel/+publishinghistory all the versions are -0ubuntu
<chiluk> ginggs: they all seem to be merges with debian sources, but the above mentioned project seems to be out of date, but it still is being mentioned in the most recent control file.
<debfx> chiluk: yep you can ignore that. ScottK and I are maintaining quassel in Debian now.
<ginggs> chiluk: i don't think pointinf the Vcs-* fields at the Debian Vcs would be correct.  It is also strange to me that the Debian version got an epoch bump, but the Ubuntu version never did.
<chiluk> ok.. debfx.. would you like me to attempt a merge from debian back into ubuntu?
<ginggs> chiluk, debfx: it would be great if we could sync up with Debian at come point
<debfx> I think you can mostly the sync the package. there might be some transitioning stuff needed.
<doko> mdeslaur, http://bugs.python.org/issue26867 is there a way to query the enabled protocols?
<mdeslaur> doko: not that I know of, unfortunately
<mdeslaur> doko: let me think if there's a better patch for that, and I'll get back to you
<pitti> cking: sure, looks nice and green; released
<cking> pitti, many thanks!
<pitti> infinity: if you want to fix reportbug locally for you, just apply this inline: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=fd907eea
<infinity> pitti: Ta.
<slangasek> nacc: bootstrap done
<pitti> cking: argh -- one of the two instances now failed with http://paste.ubuntu.com/17319931/
<pitti> cking: at least that now seems to be something entirely different
<cking> pitti, aren't those alignment faults caused by a bad userspace program that the kernel is handling?
<pitti> cking: yeah, that's what it looks like; but ssh stopped responding, so I guess some test did something bad to the host
<pitti> cking: anyway, no stuck processes so far
<cking> pitti, so the aarch32 BKPT error occurs during ptracing of a 32 bit executable, so it maybe that the child died, perhaps the parent tracer gets hung by that
<pitti> tdaitx: https://bugs.launchpad.net/auto-package-testing/+bug/1550280
<ubottu> Launchpad bug 1550280 in Launchpad itself "autopkgtest: allow testing against private PPAs with private results" [High,Triaged]
<pitti> infinity: bug 1510344
<ubottu> bug 1510344 in unity-settings-daemon (Ubuntu) "Keyboard Backlight Turns on at boot" [High,In progress] https://launchpad.net/bugs/1510344
<chiluk> debfx, quassel can not be directly synced because of name changes in the  d/control file.
<_morphis> stgraber: ping
<barry> nacc: ping
<mwhudson> pitti: for some reason i just had the idea of writing a charm for britney
<mwhudson> pitti: must be time for bed
<pitti> mwhudson: much appreciated :)
<pitti> mwhudson: this is actually on the sprint agenda for discussion :)
<mwhudson> pitti: haha
<mwhudson> i am there in spirit if not in body
<juliank> infinity: mvo: Time to do "syncpackage -d experimental -V 1.3~exp2 -b 1592171  -s juliank apt" for bug 1592171, and "syncpackage -r xenial -V 1.2.13 -s juliank apt" for SRU bug 1573547 ? (Not sure if the commands are entirely sane; -V ... is probably not needed, but probably does not hurt) - More APT for everyone!
<ubottu> bug 1592171 in apt (Ubuntu) "Sync apt 1.3~exp2 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/1592171
<ubottu> bug 1573547 in apt (Ubuntu) "Apt's bash completion is incomplete" [Low,Fix committed] https://launchpad.net/bugs/1573547
 * juliank is learning syncpackage commands
<Unit193> juliank: FWIW, ~ubuntu16.04.1 would be appended.
<juliank> Unit193: No need to, 1.2 is the xenial line
<juliank> Unit193: (that's what infinity basically wrote)
<Unit193> !info apt xenial
<ubottu> apt (source: apt): commandline package manager. In component main, is important. Version 1.2.12~ubuntu16.04.1 (xenial), package size 1029 kB, installed size 3271 kB
<juliank> Unit193: Yeah, 1.2.12 was a different case. It autosynced to yakkety by accident...
<juliank> yakkety now has 1.3
<Unit193> Aha, niiice.  And yeah, noticed that bit.
<rbasak> juliank: there won't be a bug reference to follow in the changelog to get to the SRU bug though.
<juliank> rbasak: There is a (LP: #1573547) in the changelog
<ubottu> Launchpad bug 1573547 in apt (Ubuntu) "Apt's bash completion is incomplete" [Low,Fix committed] https://launchpad.net/bugs/1573547
<rbasak> juliank: oh, great :)
<Unit193> Indeed, pretty fancy.
<juliank> I'm considering going with the same APT release series for (maybe) 16.10, 17.04, (maybe) 17.10 as I do for the Debian stable release (Deb freeze is in Jan, probably lasts long enough for 17.10) Then all could be pseudo-synced to the same version.
<juliank> On the other hand, it might make sense to let experimental APT versions flow into 17.10 in preparation for 18.04.
<Unit193> Oh, I meant to ask last time, do you have a vcs for command-n-f?  (Timed out on OFTC for now or I'd ask there.)
<juliank> Unit193: Not really anymore :/
<juliank> the newer ubuntu one has one somewhere though, I hope
<juliank> Long term, I'd like to merge
<seb128> Trevinho, bah, infinity copied the u-s-d SRU over to yakkety, unsure if that means you need to rebase your silo or if we just land that anything like the copy hadn't be done
<Trevinho> seb128: ah...
<Trevinho> seb128: in general in these cases I'd just pull that revision into trunk
<Trevinho> seb128: since it's already in distro
<Trevinho> seb128: I can do that and redo a rebuild
<seb128> your call
<seb128> I would just discard it if it was me
<Trevinho> seb128: have you approved all the branches involved? Since one wasn't
<seb128> Trevinho, which one?
<Trevinho> seb128: is that just a changelog?
<Trevinho> entry I mean
<seb128> no, it's the xenial SRU
<seb128> so the keyboard backlog fix for boot
<Trevinho> seb128: https://code.launchpad.net/~3v1n0/unity-settings-daemon/keep-cached-kbd-backlight-updated/+merge/294662
<seb128> the > changed to >=
<seb128> ah
<seb128> I was hoping somebody else would test that one since I don't have the hardware
<seb128> I guess I can do a code review at least
<pitti> cyphermox: https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-network-yaml
<Trevinho> seb128: however, in a second though, well I'd just overwrite the landing in yakkety... Since the change is already in the silo anyway
<seb128> Trevinho, wfm!
<Trevinho> seb128: so once that review is done I think you can just hit the publish with the IGNORE_VERSIONDESTINATION flag
<seb128> right
<seb128> thanks for confirming
<coreycb> arges, hi, we have some openstack SRU's in the review queue if you have some time to review.  I'm particularly looking to get the xenial ones moving along.
<funman> hello
<funman> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc3-yakkety/BUILD.LOG (warning: 13MB) shows package is built with do_tools=0, thus no linux-tools deb being built. Why not?
<funman> ah moving to #ubuntu-kernel
<rbasak> cyphermox: are you making any progress on bug 1585771?
<ubottu> bug 1585771 in debian-installer (Ubuntu) "Automatic security upgrades are always enabled" [High,New] https://launchpad.net/bugs/1585771
<cyphermox> rbasak: I had not; looking at it now
<cyphermox> (if teh source ever downloads)
<arges> coreycb: ok looking
<arges> coreycb: i'll look at xenial today, and others tomorrow since it is my sru day
<arges> sprinting atm
<coreycb> arges, no problem, thanks
<rbasak> cyphermox: thanks! I was going to assign it to someone on the server team but you grabbed the assignment first.
<cyphermox> rbasak: well, if you want to take care of it, by all means
<arges> coreycb: did you upload horizon?
<arges> or keystone
<coreycb> arges, hmm to xenial?
<arges> coreycb: yes
<arges> bug 1591248
<ubottu> bug 1591248 in neutron-vpnaas (Ubuntu Xenial) "[SRU] mitaka point releases" [Undecided,New] https://launchpad.net/bugs/1591248
<coreycb> arges, looking
<arges> coreycb: ok i'm leaving soon so i'll get ot the rest tomorrow
<coreycb> arges, ok.  horizon is uploaded and I dropped keystone  from that bug since it's not finished.  thanks!
<cyphermox> rbasak: I'm looking at it (for realz now), this is more complicated than expected
<barry> nacc: ping
<sarnold> It's 7:37 back in portland, it might still be a while :)
<pfsmorigo> Is debian-install that creates /etc/default/grub file?
<doko> tumbleweed, my test rebuilds for the pypy SRU were successful: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<tumbleweed> doko: \o/
<barry> sarnold: yeah.  i was hoping he might be an early riser ;)
<sarnold> .. or perhaps late sleeper? :) heh
<barry> or maybe his alarm would start screaming when i pinged his nick
<tumbleweed> doko: want to copy it into -proposed then? (can you from that PPA?)
<tumbleweed> doko: also, are the rebuilds required? I assume not
<doko> tumbleweed, well, build-deps for some main packages, so I thought I would better check
<tumbleweed> oh, absolutely
<tumbleweed> I just meant, we don't have to do in-archive builds
<doko> now in the queue
<infinity> pfsmorigo: It's copied into place by the grub2 postinst, and potentially altered by grub-installer during install.
<nacc> slangasek: thank you!
<nacc> slangasek: how does this work with excuses? phpunit is still stuck because phpunit-mock-object and php-codecoverage are both regressing phpunit's older version (which is expected); and they do pass with the new version. Basically, they all need to be considered together, I think?
<barry> nacc: https://github.com/gitpython-developers/GitPython/issues/470 - i am working on a fix.  we can probably talk about it in a few hours
<barry> nacc: i will probably also have a few changes for usd-import
<nacc> barry: ah nice!
<nacc> barry: sure, thanks, much appreciated :)
<barry> nacc: since you're here and i have a few minutes...
<nacc> barry: yep, i'm around now :)
<barry> nacc: so i was looking for some packages to test this on, and saw a merge request for sbuild on the patch pilot page.  i started to import it and hit a crash.  after *much* debugging, turns out that some sbuild changelog entry has non-utf8 characters in it, and python3-git tries to decode the bytes with utf-8 in strict mode, and that crashes.  they have a safe_decode() method which does an `errors='replace'` so that seems appropriate to
<barry> wrap around the stdout/stderr bytes it gets back from the `git show-file` subproc call.  if our network wasn't so horrible i would have tested this hours ago, but now i'm running another import to see if that works.  doesn't help that the dpmt git-dpm branch for python-git is hosed.  i may just upload a fix to ubuntu until that gets unwedged
<nacc> barry: make sense ... yeah, it seems ... odd that there is a stray character there. I guess the committer didn't use the right UTF character and it got mis-translated by some tooling to <F6> ?
<barry> nacc: yep
<barry> nacc: so yeah, a bug in the changelog, but a pretty much permanent one :)
<nacc> yeah, we probably need better error-handling there too, then
<barry> nacc: so one of the changes i will propose is to log the exception in usd-import instead of swallowing it ;)
<nacc> barry: yep, perfectly fine by me :)
<barry> nacc: coolio
<nacc> barry: i will admit to not being the most experienced python developer -- patches are definitely welcome!
<barry> nacc: +1
<cjwatson> barry: Hm, really?  The current changelog in sbuild.git debian/unstable is entirely UTF-8.
<cjwatson> barry: As is the current one in the Ubuntu archive.
<barry> cjwatson: it was in an older published ubuntu changelog, but i don't remember the version number right now
<barry> cjwatson: maybe nacc can see it as he correctly identified the <F6>
<nacc> per the gh bug report, seems to be 0.24
<cjwatson> Oh, so full-history importing
<nacc> cjwatson: yep
<nacc> find all sorts of corner cases that way :)
<cjwatson> Yeah, fixed in 6756b2a6 but you gotta cope with this.
<barry> nacc, cjwatson anyway, ttyl
<nacc> barry: np, thanks for the info!
<rbasak> May I have a review of https://github.com/ltangvald/mysql-5.7/commit/fa6ea034692 from an experienced dev please? The mechanics are simple but I want to make sure the approach is correct (seddery of conffile)
<stgraber> _morphis: hey
<nacc> cjwatson: before i file an unnecessary update to LP: #1592139; can you help me understand how the bootstrapped packages "should" interact with excuses? these three binary packages can only proceed together, and they all work in -proposed. But necessarily, the phpunit-mock-object and php-codecoverage packages break the version of phpunit in release.
<ubottu> Launchpad bug 1592139 in phpunit-mock-object (Ubuntu) "Please bootstrap build phpunit, phpunit-mock-object and php-codecoverage" [Undecided,Fix released] https://launchpad.net/bugs/1592139
<cjwatson> nacc: Break in what sense?
<nacc> cjwatson: the unit tests fail, but I believe it's variously because the formatting of the output has changed with the newer dependency packages from -proposed, or there are functional changes. Those same unit tests in the newer version of phpunit pass.
<nacc> cjwatson: actually, the excuses output is a bit confusing
<cjwatson> nacc: Probably just wants the autopkgtests rerun with the newer phpunit in this case, I think, but get pitti to have a look.
<nacc> for non-amd64/armhf, it's passing with teh newer version of phpunit, but for those two, it's failing for the older version
<nacc> ack, that does seem to be all, thanks!
<nacc> pitti: :) if you could help out, i'd appreciate it. Trying to get the set of phpunit, phpunit-mock-object and php-codecoverage through. I think phpunit-mock-object and php-codecoverage's autopkgtests need to get rerun with the newer phpunit wehre it's failing for the older phpunit
<nacc> Logan: fyi, phpunit/phpunit-mock-object/php-codecoverage should get into release shortly, which should unblock some stuff :)
<popey> bdrung: hello! I've just been bitten by bug 1581807 (which you have a fix for). Do you need help with it? I'd love to see that land so I can build Audacity.
<ubottu> bug 1581807 in wxwidgets3.0 (Ubuntu Xenial) "Define wxIsNaN() as std::isnan() in C++11 mode" [Undecided,Incomplete] https://launchpad.net/bugs/1581807
<nacc> Logan: (or anyone else), now that phpunit is installable in yakkety and is up-to-date, do the various tests/builds that failed due to deps need to be manually restarted? they aren't in dep-wait, they simply failed to build (because phpunit wasn't installable)
<nacc> e.g., https://launchpad.net/ubuntu/+source/php-react-promise/2.4.1-1 but there are many others
<cjwatson> nacc: If LP doesn't say "Dependency wait" for them on the +build page, they will have to be manually retried.
<cjwatson> nacc: I've retried.  If you can get a list of package names then I can do them in bulk.
<cjwatson> nacc: *retried php-react-promise
<nacc> cjwatson: ack, i'll start collating that list now
<nacc> rbasak: sorry to pester, did you get a chance to review the php-imagick merge?
<nacc> cjwatson: http://paste.ubuntu.com/17334290/
<nacc> cjwatson: those are all the ones i found that failed to build due to phpunit alone; i'm looking through the rest of the php packages in excuses as well
<cjwatson> nacc: php-constant-time was already built, just in NEW; I've retried the rest
<nacc> cjwatson: ah sorry, thanks!
<cjwatson> (an older version of php-constant-time did fail and may still have been in excuses)
<nacc> cjwatson: yeah, i think that must have been what i saw
<rbasak> nacc: sorry, not yet. I was trying to make progress on MySQL today. I'll take a look at outstanding sponsoring tomorrow.
<nacc> rbasak: thanks!
<Logan> nacc: you're awesome!
<nacc> Logan: thanks for the pokes on it, sorry it took so long to get resolved
<nacc> cjwatson: did php-sabre-vobject get retried? lp says the failed build is still from 5/23?
<nacc> oh! my fault  -- php-sabre-vobject-3
<nacc> sorry!
<nacc> hrm, attempting `requestsync -n php-symfony-security-core`, but it reports that it doesn't exist in the primary archive of sid; however rmadison says it is in unstable?
<jbicha> nacc: try requestsync symfony
<jbicha> it uses the source package name, and I don't think you want -n
<nacc> jbicha: ah sorry
<nacc> jbicha: you're right!
<nacc> i just glossed the source package name
<nacc> ok, will go look at the merge :)
<nacc> jbicha: thanks for the hint!
<slangasek> nacc: phpunit, yes, I saw the autopkgtest results earlier and reschedulded tests with all three packages
<slangasek> nacc: so I believe those have all migrated now
<nacc> slangasek: yep, thanks!
<nacc> slangasek: if you have a moment, could you manually retrigger the build of php-sabre-vobject-3? i typo'd my request to cjwatson earlier
<slangasek> nacc: done
<nacc> slangasek: thanks!
<nacc> slangasek: down from ~430 mentions of php on excuses to ~300 :)
 * mwhudson DOSes the launchpad builders with go 1.6.2 rebuilds
<cjwatson> mwhudson: that's ok, they aren't going to notice in the middle of the test rebuilds
<mwhudson> cjwatson: heh
<mwhudson> cjwatson: i was wondering, do you have any handwavy idea of how many builds are done a day?
<cjwatson> mwhudson: total across all arches?
<mwhudson> yeah
<mwhudson> a few thousand?
<cjwatson> /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-20160610.gz:8186
<cjwatson> /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-20160611.gz:6754
<cjwatson> /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-20160612.gz:6617
<cjwatson> /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-20160613.gz:4439
<cjwatson> cjwatson@carob:~$ zgrep --count 'Dispatching job' /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-201606{10,11,12,13}.gz
<cjwatson> sorry for order
<mwhudson> heh
<mwhudson> so my extra 900 is an extra ~10%
<cjwatson> the numbers above are without a test rebuild running though, and those started today
<mwhudson> heh i see build ten million must have been pretty recently
<cjwatson> oh yeah, I totally didn't notice that
<cjwatson> not actually run yet, so probably part of the test rebuilds
<cjwatson> https://launchpad.net/ubuntu/+archive/test-rebuild-20160614/+build/10000000 has the honour
<mwhudson> earth shattering
<nacc> so i think i fixed one of the puppet autopkgtest issues (LP: #1570472)
<ubottu> Launchpad bug 1570472 in puppet (Ubuntu) "Set systemd as default service provider" [Undecided,In progress] https://launchpad.net/bugs/1570472
<nacc> but the other one (puppet-module-puppetlabs-ntp)
<nacc> if i have adt-run drop to a shell on failure, the script in question (run-tests) runs both tests succesfully
<nacc> it's also failing in debian, fwiw, at the same point (introducing puppet 4.5.0)
#ubuntu-devel 2016-06-15
<doko> tedg, bdmurray: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1592649 please backport
<ubottu> Launchpad bug 1592649 in whoopsie (Ubuntu) "whoopsie fails to build from source in xenial" [High,Confirmed]
<pitti> Good morning
<doko> rbasak, I see some build regressions with mysql-5.7 in xenial
<pitti> nacc: this group already landed apparantly
<pitti> nacc: I retried all the other php regressions now, maybe some of it will stick now
<doko> pitti, https://launchpadlibrarian.net/265375370/buildlog_ubuntu-xenial-amd64.ubuntu-defaults-builder_0.54_BUILDING.txt.gz
<doko> sil2100, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160614-xenial.html could you address the dbus-cpp ftbfs with the touch guys?
<doko> barry, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160614-xenial.html could you look at the bzr ftbfs?
<sil2100> doko: hey! Ok, will poke them, uh, dbus-cpp again...
<pitti> doko: fix uploaded
<doko> apw, could you have a look at https://launchpadlibrarian.net/265374798/buildlog_ubuntu-xenial-amd64.kmod_22-1ubuntu4_BUILDING.txt.gz ?  using ppa:ubuntu-toolchain-r/ppa
<infinity> apw: ^-- That's fixed in Debian, just needs a merge.
<doko> jamespage, https://bugs.launchpad.net/ubuntu/+source/migrate/+bug/1592663
<ubottu> Launchpad bug 1592663 in migrate (Ubuntu) "migrate fails to build in xenial" [High,Confirmed]
<doko> rbasak, https://bugs.launchpad.net/ubuntu/+source/python-pymysql/+bug/1592664
<ubottu> Launchpad bug 1592664 in python-pymysql (Ubuntu) "python-pymysql fails to build on xenial and yakkety" [High,Confirmed]
<slangasek> nacc: fyi I'm going to drop the delta to php-codesniffer to add nocheck/stage1 profiles; it's not worth carrying a delta to the package for, though it probably is worth someone taking the time to submit that patch upstream to Debian
<jamespage> hmm fallout of the late-ish switch to mysql-5.7
<apw> infinity, doko, erp ok
<doko> sil2100, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1592691
<ubottu> Launchpad bug 1592691 in mir (Ubuntu) "mir fails to build in xenial" [High,Confirmed]
<doko> sil2100, //bugs.launchpad.net/ubuntu/+source/unity/+bug/1592676
<sil2100> doko: thanks, let me forward those further
<cyphermox> xnox: am I still supposed to have to restart gpg-agent all the time
<xnox> cyphermox, =((((((
<doko> xnox, https://launchpad.net/ubuntu/+archive/test-rebuild-20160614/+build/9977711
<doko> xnox, https://launchpad.net/ubuntu/+archive/test-rebuild-20160614/+build/9977711
<doko> apw, https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1592722  please merge and backport
<ubottu> Launchpad bug 1592722 in kmod (Ubuntu) "kmod fails to build in xenial (and yakkety)" [High,Confirmed]
<Unit193> Looks like libtorrent somehow wasn't properly rebuilt against boost, no-change rebuild fixes the problem with it.
<apw> doko, on it
<rbasak> doko: will look - thanks.
<doko> jamespage, could you have a look at https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1592793 ?
<ubottu> Launchpad bug 1592793 in openvswitch (Ubuntu) "openvswitch fails to build in xenial on armhf" [High,Confirmed]
<jamespage> doko, I should think so
<LocutusOfBorg> abeato, hi, ping about ofono if you are interested :) (new version in Debian)
<abeato> LocutusOfBorg, hey, thanks for the info, I saw a new upstream version too (we actually go there directly these days)
<LocutusOfBorg> thanks for caring :)
<rbasak> cpaelzer: I really appreciate your commentary in bug 1581839 (comment 3). Makes it much easier to review. Thank you.
<ubottu> bug 1581839 in clamav (Ubuntu Xenial) "package clamdscan 0.98.7+dfsg-0ubuntu4 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/clamdscan.1.gz', which is also in package clamav-daemon 0.98.7+dfsg-0ubuntu0.14.04.1" [High,Triaged] https://launchpad.net/bugs/1581839
<Son_Goku> so who's the guy making all these random snapd packages for the distros
<rbasak> Son_Goku: I'm not sure, but there's a separate #snappy channel.
<Son_Goku> he's zyga on github, but who is he on IRC?
<Son_Goku> ah
<Son_Goku> thanks
<cpaelzer> I'm sure - there is a #snappy channel
<rbasak> cpaelzer: snap :-P
<dobey> zyga is zyga
<cpaelzer> I asked around there yesterday :-)
<rbasak> cpaelzer: bug 1581839 looks good, just one question. I'm not sure what the right answer is.
<ubottu> bug 1581839 in clamav (Ubuntu Xenial) "package clamdscan 0.98.7+dfsg-0ubuntu4 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/clamdscan.1.gz', which is also in package clamav-daemon 0.98.7+dfsg-0ubuntu0.14.04.1" [High,Triaged] https://launchpad.net/bugs/1581839
<rbasak> cpaelzer: it's fairly comment when marking a Breaks/Replaces to suffix a ~, so that it catches backports as well. Eg. version X backported becomes X~something, so X~ is lower than them both, but X is not.
<rbasak> common
<cpaelzer> rbasak: yeah we talked about it, but since we are not targetting a specific "old" version we should be fine
<rbasak> So, in this case, do we want 0.99+dfsg-1ubuntu1~ in case 0.99 is backported to Trusty, or would that be completely the wrong thing to do?
<cpaelzer> rbasak: we are tarketting anything prior to the first version in the release
<cpaelzer> rbasak: ah - I think I finally got you ...
<cpaelzer> rbasak: you mean if a backport add 0.99 back ... hmm
<cpaelzer> yeah I tihnk I neglected that case too early
<rbasak> I guess one question is: if 0.99 does get backported to Trusty, then which way round will the manpages be in it?
<rbasak> Though, Breaks/Replaces catching some extra stuff will do no real harm here.
<cpaelzer> rbasak: we don't know for sure how the backport would be done, I'd expect to be the "new" way
<cpaelzer> rbasak: and then it would already have made that transition
<cpaelzer> rbasak: the "extra" breaks/replaces that will occur then shouldn't hurt us right?
<rbasak> shouldn't hurt us right?> right
<rbasak> would already have made that transition> assumes that the user has dist-upgraded Trusty before dist-upgrading to Xenial.
<rbasak> Which may be a fair assumption to make, but if we can make it safer than we might as well I think.
<rbasak> So, if my logic is right (and I'm really not sure, would appreciate you confirming), we should suffix ~.
<cpaelzer> rbasak: I'm currently in a test fight with dpkg --compare-versions about this
<rbasak> Actually my logic is a little flawed. It won't matter if the user upgrades from release pocket Trusty straight to Xenial, because then the B/R in Xenial will catch it anyway.
<cpaelzer> rbasak: I'd recommend you http://www.justgohome.co.uk/blog/2015/01/ubuntu-package-versions.html but well, you should know :-)
<rbasak> :-)
<rbasak> I think a suffix ~ is only required if 0.99 is later backported to Trusty with Trusty (not Xenial) packaging.
<rbasak> (so old manpage locations)
<cpaelzer> rbasak: I also think ~ isn't required for the following reason
<cpaelzer> rbasak: so 0.99~ is -lt than 0.99 as I thought - which also is reasonable as it "has to"  upgrade for e.g. changes .so linkage
<cpaelzer> rbasak: that means no one will ever be able (without wreaking havoc) to insert anything not falling into <0.99 (without ~)
<cpaelzer> rbasak: and that way the <0.99 will catch all cases we want
<cpaelzer> my - probably even more flawed - thinking
<cpaelzer> but that is 2/2 votes to go without ~ in this case
<cpaelzer> And a backporter would have to explcitly make changes to "reapply" the old Trusty packaging
<cpaelzer> if we have to choose that is not the one I'd consider likely
<rbasak> I think it depends on how the Trusty updates are done. Whether they typically bump new upstream version without pulling in debian/ from newer releases, or whether they are full backports from the development release.
<cpaelzer> rbasak: lets play this out if 0.99 gets backported it will become 0.99~ to ensure the upgrade path is working
<doko> sil2100, for completeness: https://bugs.launchpad.net/ubuntu/+source/dbus-cpp/+bug/1592814
<ubottu> Launchpad bug 1592814 in dbus-cpp (Ubuntu) "dbus-cpp fails to build on xenial" [High,Confirmed]
<cpaelzer> rbasak: if the backport does the move then the backport has to do the same breaks/replaces to work
<infinity> Trevinho: Congrats, your new unity-settings-daemon crashed for me after I upgraded. :P
<cpaelzer> rbasak: if we come again with 0.99 in Xenial we will break/replace again - but that is not "wrong", just too much
<cpaelzer> rbasak: but
<cpaelzer> rbasak: if the backport doesn't move the files, our match with <0.99 (without ~) will be required
<cpaelzer> rbasak: wo without ~ works in both cases, while with ~ will only work in one of two ways a potential backport could be done
<cpaelzer> rbasak: right?
<rbasak> cpaelzer: when you say <0.99 (without ~), do you mean (<< 0.99+dfsg-1ubuntu1)?
<sil2100> doko: thanks, will forward it, but tvoss is on it already
<cpaelzer> rbasak: yes
<cpaelzer> rbasak: where in that version string would the ~ be insertded on a backport?
<rbasak> 0.99+dfsg-1ubuntu1~ would be the alternative usually.
<rbasak> But in this case, it looks like debian/ is never updated (except as necessary) when a new upstream is pulled in.
<rbasak> (I did "git clone -b ubuntu/trusty-updates git://git.launchpad.net/~usd-import-team/ubuntu/+source/clamav
<rbasak> " to look at the history - thanks nacc!)
 * rbasak ponders
<rbasak> This is a little mindbending :-/
<cpaelzer> rbasak: trying to simplify that - I think we should "catch" as much as possible to be on the safe side. Appending a ~ makes a version "smaller". That means not adding it at the breaks/replaces catches more
<rbasak> cpaelzer: thanks. You've just convinced me.
<cpaelzer> I'll mark that day in my calendar :-)
<rbasak> :-)
<cpaelzer> dkms question - in a dkms package sources are placed in /usr/src/<packagename> which is good as I can rely upon that. Is there any sort of Variable I could use in the associated dkms conf file to refer to that path?
<cpaelzer> or at least the package name (in case it ever changes)
<cpaelzer> I have code that works fine for me writing the full path, but I'd like to be as adaptive as possible to have less chance to break in the future
<infinity> Trevinho: Completely reproducible.  Lock->Fade->BacklightOff->USDCrashes->Fonts, etc go wonky.
<cpaelzer> fyi -  found it in man dkms after reading a while - cancelling my former question
<seb128> infinity, distro serie, unity-settings-daemon version, backtrace?
<infinity> seb128: yakkety, filed a bug, network here sucks, looking for the bug #. :P
<seb128> infinity, with the version that landed a few hours ago?
<infinity> seb128: Aye.
<seb128> https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1592816
<ubottu> Error: launchpad bug 1592816 not found
<seb128> k
<seb128> Trevinho, ^
<infinity> seb128: The xenial SRU version is lovely.  The yakkety version, less so.
<seb128> yeah, we have a good stack of changes in that update
<seb128> we were discussing SRUing some
<seb128> but looks like we have some work to do first
<infinity> *nod*
 * infinity downgrades for now, before this drives him nuts.
<seb128> though it's in the screensaver proxy which was not on the list of things we are looking at SRUing for this round
<LocutusOfBorg> hi does anybody know what is missing liquidsoap for migration?
<LocutusOfBorg> is biniou testsuite, right?
<nacc> pitti: thanks, i'll keep you posted
<nacc> slangasek: agreed, i'm working on sending those up to debian in parallel
<Trevinho> infinity: it's a pure upstream change, so not all my fault... And I didn't notice that before
<Trevinho> infinity: however, easy to fix I guess
<Trevinho> actually....
<seb128> Trevinho, lying :p
<Trevinho> seb128: check https://github.com/GNOME/gnome-settings-daemon/blob/master/plugins/power/gsd-power-manager.c no signal disconnection at all :)
<Trevinho> which... I believe doesn't happen there because of some reason
<Trevinho> At least there's not something different in there
<Trevinho> in the idle management
<seb128> Trevinho, https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=5614e2c7a275a092e1fcf43450d7f0c5730c14bd
<seb128> Trevinho,
<seb128> -                        ret = upower_kbd_toggle (manager, &error);
<seb128> -                        if (!ret) {
<seb128> +                        if (upower_kbd_toggle (manager, &error) < 0) {
<seb128> Trevinho, you changed the return type so I guess we need those ret check changes as well?
<Trevinho> seb128: oh, it seems os
<Trevinho> so*
<Trevinho> seb128: also noticed that ci-train has  a big  issue in generating bzr changelogs... No multilnes anymore in commits
<Trevinho> I added on these the git commits I backported
<seb128> oh?
<Trevinho> robru: ^
<seb128> example?
<Trevinho> seb128: see https://code.launchpad.net/~3v1n0/unity-settings-daemon/kbd-brightness-update/+merge/295000 and compare with what we have in bzr log for trunk
<Trevinho> just first line is taken
 * Trevinho now wants to redo that :-@
<rbasak> teward: I just commented on bug 918896. Here's a wider question for the channel. If we want to apply an Ubuntu delta to a version 1.0 source package, then is it OK to just throw quilt at it and bundle up the source package so that the applied quilt patch is effectively in the diff.gz? I've not seen it done this way before.
<ubottu> bug 918896 in pymssql (Ubuntu Yakkety) "No data returned from MSSQL server" [High,Confirmed] https://launchpad.net/bugs/918896
<seb128> Trevinho, oh, right :-/
<rbasak> Usually I'd expect to use the packaging's patch system if there is one, or to not use a patching system at all when applying an Ubuntu delta (and just applying the patch wholesale)
<teward> rbasak: the other option other than "not fixing it" is "replace it completely", or "remove it"
<teward> because I already poked the Debian python modules team
<teward> they aren't motivated to fix it
<teward> and say "how about you prepare a team upload and we sponsor it"
<teward> which doesn't help solve the problem
<teward> the other is "do nothing" and NACK the suggested debdiff
<Trevinho> seb128: you want me to backport the whole commit?
<Trevinho> (plus a couple more linked in the same bug)?
<teward> rbasak: if you have an alternative suggestion for fixing it let me know
<teward> but that package?  Unmaintained since 2009 I think it was *checks logs*
<seb128> Trevinho, your call, unsure if we need the property
<seb128> Trevinho, the ret check might be enough
<rbasak> teward: apply the patch without quilt. So "quilt -a", move fix-get-result.patch to /tmp or something, remove debian/patches and .pc, "patch -p1 < /tmp/...", and build the source package like that.
<teward> rbasak: E:FTBFS: Changes in source package not reflected
<teward> tried that
<rbasak> teward: I'm not sure I'm correct in declining to sponsor what you provided though. I'd appreciate some feedback on that from someone else.
<Trevinho> seb128: ok
<teward> i'll rebuild/test again in sbuild shortly
<teward> but failing that
<rbasak> teward: that's odd. I'd expect it to not do that since it's source format 1.0.
<teward> rbasak: first instinct was to say "Lets remove it"
<teward> but the rdeps list becomes massive
<teward> rbasak: i'm just as happy running `sudo pip install pymssql` everywhere instead - would rather have 2.1.2 from upstream than obsolete/broken 1.0.x from the repos)
<Trevinho> infinity: in few seconds you should get fixed packages at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014/+packages
<teward> rbasak: following your advice now, to see if it all works as it should
<teward> debuild -S didn't complain, but sbuild might, so we'll see
<nacc> so ... is there a bug in `pull-debian-source`? specifically that it calls rmadison('debian', package, suite, 'source'), but the 4thparameter to rmadison() is the architecture?
<nacc> this is in 16.04
<nacc> oh nm, apparently, 'source' is a valid arch specificier :/
<teward> rbasak: you can unsubscribe sponsors for now from that bug
<teward> i'll readd when i get a chance to respin/test debdiffs
<teward> in the manner you just stated
<nacc> can someone rerun the php-horde-core -> php-horde-imp armhf test failure? it seems to be a testbed issue (timeout)
<nacc> same with php-horde-mime -> php-horde-compress
<ctpd> Can someone point me to the latest Xenial relase glibc sources.
<nacc> ctpd: http://packages.ubuntu.com/xenial/glibc-source ?
<rbasak> nacc: done
<ctpd> nacc: thanks
<nacc> rbasak: thanks!
<nacc> also, i think the php-fxsl -> phpdox i386 failure needs to be rerun against the newer version of phpdox (where it passes everywhere else)
<ctpd> Is the git branch (of Xenial release glibc) somewhere available (online)? Need the change history...
<nacc> ctpd: i don't believe it's maintained in git; do you need more than the changelog provides?
<ctpd> nacc: yes, the actual changes
<nacc> ctpd: i can import the whole history of publishing (cf. ubuntu-server e-mails on the subject), but it won't be a normal git history, but a publishing history (you can use `git diff` etc, though)
<ctpd> nacc: sounds like an overkill...
<ctpd> in particular i have some doupts about some changes in bits/pthreadtypes.h. Would like to know more about the history before diving into discussions.
<nacc> ctpd: http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.23-0ubuntu3/changelog doesn't mention any changes to that file in ubuntu
<ctpd> nacc: ahh. ok... should get in contact with the debian guys then:
<ctpd> * debian/patches/hurd-i386/local-pthread_types.diff: make it create a new     sysdep/mach/hurd/bits/pthreadtypes.h instead of modifying     bits/pthreadtypes.h.  Move from series.hurd-i386 to series.
<nacc> ctpd: yep
<morphis> stgraber: sorry, didn't saw your pong yesterday
<ctpd> nacc: thx
<morphis> stgraber: just wanted to check if you can tell me how far uid_map/gid_map support on 3.10 based kernel should be; should I be able to map uid/gid range I've added in /etc/subuid / /etc/subguid?
<morphis> stgraber: (for user namespaces)
<rbasak> nacc: I suggest you configure quilt as documented in https://wiki.debian.org/UsingQuilt. Eg. "-p ab" for quilt refresh. This reduces diff noise.
<rbasak> (IMHO, this should be part of dep3 to save diff noise by standardising for everyone)
<nacc> rbasak: fixing locally
<rbasak> nacc: don't worry about fixing up this merge or anything. Not worth it. Looks like this package will have to have noisy quilt changes all the time anyway since the version number is embedded in path names :-/
<rbasak> nacc: to confirm, you're happy for me to upload php-imagick from your tree now, right?
<nacc> rbasak: yes please
<rbasak> OK
<nacc> rbasak: thanks! yeah there's a few packages that are like that in php (and the debian vcs also shows commits that are just rewriting the diffs)
<nacc> i've also sent almost all of it to debian and once the newer imagemagick gets in debian, we can merge/sync that and drop our remaining delta
<nacc> rbasak: not sure if you saw it earlier, but if you could also retrigger the php-fxsl -> phpdox build (it ran on i386 with an older phpdox)
<rbasak> nacc: done. Sorry I missed it before.
<nacc> rbasak: np!
<rbasak> nacc: got time for a sync on the importer later? No urgent. Perhaps on the hour (37 minutes)?
<rbasak> nacc: php-imagick uploaded BTW.
<nacc> rbasak: i'm free now, i might have a contractor coming by during that sync up, but should only need to let them in to measure
<teward> rbasak: wrt 918896, it works without the quilt patch, albeit Lintian is throwing some complaints
<teward> i'll go test that built binary on Yakkety, and if all else works, replicate for other releases
<teward> sponsors unsub'd until I can get to it
<stgraber> morphis: non-existent basically
<nacc> did something just happen to debian's package information? https://packages.debian.org/search?keywords=php-defaults
<nacc> rmadison says it's there
<rbasak> nacc: sorry, I was getting dinner. I'll fire up a Hangout now.
<rbasak> teward: great, thanks!
<nacc> rbasak: sounds good
<rbasak> nacc: http://stackoverflow.com/a/4971817/478206
<morphis> stgraber: ok, so I basically have just a single user I can map
<morphis> stgraber: just https://paste.ubuntu.com/17376163/ wonders me then
<robru> Trevinho: please file a bug against lp: bileto with what you expect the generated changelog to be
<robru> Trevinho: don't forget you can supply your own changelog if you're unhappy with the one generated for you
<morphis> stgraber: but I see what the trick is now with new[u,g]idmap
<nacc> pitti: can you kick the php-defaults -> php-imagick tests now that the new php-imagick has landed in -proposed? (should be migrating to -release shortly)
<nacc> or anyone else, really :)
<juliank> Word is in: Google repos produce no warnings anymore!
<juliank> (except Earth)
<Unit193> \o/  Now if videolan will fix 'em.
<nacc> heh, google-talkplugin now gets a hash sum mismatch :)
<juliank> Yay!
<nacc> exchange one warning for an error :)
<tumbleweed> doesn't google earth require LSB stuff anyway?
<Unit193> Noticed that, nacc.  Great stuff. :P
<juliank> nacc: Tell mmoss@chromium.org, maybe in https://bugs.chromium.org/p/chromium/issues/detail?id=596074
<nacc> juliank: thanks for the pointer
<nacc> slangasek: i think we can delete php-zend-search from yakkety (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816684), that's what is holding up the php-zend* in proposed, afaict
<ubottu> Debian bug 816684 in php-zend-search "Useless in Debian" [Serious,Open]
<mwhudson> is there some way i can use copy-package to copy the newest version of a package in a distroseries? i.e. from -proposed if it's there, -updates if there, -release if not?
<cjwatson> mwhudson: not that I'm aware; would require a wrapper to go hunting
<mwhudson> cjwatson: ack
<mwhudson> cjwatson: next question i guess, how would that wrapper work? launchpadlib i guess
<mwhudson> or grepping ~/.chdist/trusty/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_${suite}_*_binary-amd64_Packages
<cjwatson> something with getPublishedSources I guess
<mwhudson> unless i can get apt-cache to tell me the suite somehow
<cjwatson> you can give it a series but not a pocket
<cjwatson> I mean, you can give it a pocket as well but you don't have to
#ubuntu-devel 2016-06-16
<nacc> slangasek: pitti: i think i've gotten most everyting resolved in excuses except for symfony & doctrine. I will spend some time tomorrow looking at those, as i think we'll need some more bootstrapping possibly
<Trevinho> robru: the problem is not the debian changelog. That is fine. Ad I wrote in the email, the bugged one is the bzr commit message. Which should be multi-line
<Trevinho> Ad = as
<robru> Trevinho: if you write your own changelog, it uses that also for the bzr commit
<robru> Trevinho: anyway I can review this tomorrow
<Trevinho> robru: Mh ok, but that is not fine. The commit message should be used for bzr commit. Whole the debian changelog should only apply to distro changes
<Trevinho> While*
<Trevinho> Robru: Ok thanks. Please have a look to this. Since we're loosing useful informations when it's up to blame or review changes
<robru> Trevinho: ok, will do
<Trevinho> Thanks
<Logan> nacc: regarding bug 1592972, shouldn't that substitution variable add php-pear? that's kinda weird
<ubottu> bug 1592972 in php-text-captcha (Ubuntu) "php-text-captcha depends on php-pear" [Low,New] https://launchpad.net/bugs/1592972
<slangasek> nacc: php-zend-search removed
<pitti> Good morning
<sil2100> Morning
<pitti> nacc: php-imagick kickified
<didrocks> good morning pitti, sil2100
<pitti> bonjour didrocks !
<sil2100> Morning didrocks! :)
<infinity> Trevinho: That fixed it, thanks.
<xnox> infinity, sorry that i forgot to push xenial-proposed bzr branch of d-i for last sru =(
<xnox> infinity, thanks for committing all that.
<xnox> no i did, derp, got my :parent and :push mixed up
<xnox> $ bzr pull --overwrite --remember :push
<pitti> cking: trusty kernel on xenial gives me http://paste.ubuntu.com/17392362/, and lxd hangs; does that smell like some incompatibility with the trusty kernel, possibly seccomp related?
<cking> pitti, syscall 384 on aarch64 is getrandom() and that does not exist on trusty :-(
<pitti> cking: ah, meh
<pitti> cking: so I guess that won't get me very far; I guess vivid next?
<cking> pitti, I believe 3.19 is the first ubuntu kernel that supported that syscall
<pitti> cking: cool, that shold be vivid then; I'm currently installing that
<mwhudson> slangasek, pitti, etc: call now?
<pitti> mwhudson: one minute
<slangasek> mwhudson: working on it, yes :)
<mwhudson> :)
<slangasek> mwhudson: live!
<pitti> mwhudson: we are talking
<pitti> cking: hm, still happening with 3.19; OTOH, I don't think the fallout is actually too bad, perhaps userspace has an appropriate fallback
<pitti> cking: anyway, I'll keep vivid running and see whether it happens there; that limits the bisect space
<cking> pitti, yep, thanks, let's see what falls out
<mwhudson> pitti: hey i'm going to upload a new docker.io soon with actual sane autopkgtests
<mwhudson> pitti: can you remove the blocks that are stopping them running?
<pitti> mwhudson: oh, sure
<pitti> mwhudson: committed and rolled out
<pitti> mwhudson: thanks for that!
<mwhudson> pitti: thanks, uploading (turns out i had it all prepared already)
<pitti> mwhudson: (and the next worker mass-killing will be on you :-P)
<pitti> more seriously, I'll let you know if it still wreaks havoc
<mwhudson> heh
<mwhudson> this one really shouldn't
<mwhudson> next fun task: get this junk in the xenial sru queue
<pitti> you apparently have high opinions about your work :)
<mwhudson> heh
<mwhudson> now i want the publisher and britney and so on to get 100 times quicker magically
<FourDollars> Is there any problem that http://ddebs.ubuntu.com is not synced to the latest version? http://paste.ubuntu.com/17393232/
<sarnold> pitti: ^^^ are you still the go-to contact for ddebs?
<pitti> sarnold: I'm afraid so; I did get a couple of cron mails from it recently, I just didn't have time to investigate yet
<sarnold> pitti: hehe
<sarnold> pitti: thanks
<cyphermox> caribou: maybe http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commitdiff;h=1ba2e171eb75f1abc72e939d9cbd9681c56954d0;hp=e9ad6f77a9036e60acc047cc2150a4dce1545578 ?
<cyphermox> infinity: http://paste.ubuntu.com/17393792/
<mwhudson> pitti: argl, some of the docker.io autopkgtests have been triggered by the runc/containerd uploads and are running the old, bad, tests
<mwhudson> pitti: if they die and start again, will they pick up the new version of docker.io?
<Laney> juliank: I just got "W: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/_srv_mirrors_ubuntu_dists_yakkety_InRelease" - and the release file wasn't used - for the Ubuntu archive which has "Date: Thu, 16 Jun 2016  9:35:47 UTC
<Laney> "
<Laney> do you know who has the bug here?
<Laney> looks like it's https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=9febc2b so maybe I should ask DonKult
<juliank> Laney: Looks fancy, I saw something similar yesterday on travis
<cjwatson> Not something to do with space-padding of the hour field?
<cjwatson> That would maybe account for it not being all the time
<cjwatson> Do ask DonKult though ...
<juliank> Oh yeah, it expects 09
<juliank> not <space>9
<juliank> AFAICT
<Laney> Could be the same with the day of month then
<cjwatson> No, we use %d for that
<Laney> The repository affected is non-LP
<cjwatson> Ah
<cjwatson> Not too sure why LP uses %k for the hour, which we could change, but we have quite a few Release files in the wild using %k for the hour so apt needs to handle that IMO
<juliank> Let me check
<juliank> On travis it even rejects Sun Nov  6 08:49:37 1994
<juliank> no idea why though
<juliank> (it works here, maybe trusty parsed differently)
<juliank> Hmm, not sure how to parse that
<Laney> https://github.com/smira/aptly/blob/master/deb/publish.go#L670
<juliank> I tried "%a, %d %b %Y %k:%M:%S"
<juliank> std::get_time() seems to be weird
<juliank> I now tried %H with two spaces in front as the doc says "leading zeros not required", but that does not seem to work
<juliank> Well, I guess I'll figure that out in the next hour
<juliank> gtg now, back in ~ 20-30 min
<Laney> I hope it's just a matter of permitting some more patterns
<Laney> thanks for looking
<juliank> cjwatson: Laney: It looks like a libstdc++6 bug, I cannot get it to parse an hour with space instead of 0 padding
<juliank> According torkel http://en.cppreference.com/w/cpp/io/manip/get_time, %H does not require leading zeroes, so " %H" should parse " 9". But it doesnt
<juliank> "torkel" should have been "to", sorry
<jaksi07c8> hi
<jaksi07c8> I'm looking for a way to create a customized Ubuntu ISO
<jaksi07c8> there is a help page, but it doesn't mention USB bootable ISOs or UEFI
<jaksi07c8> is the way official ubuntu ISOs are generated public?
<juliank> cjwatson: Laney: Yep, confirmed: Reproducer: https://paste.debian.net/739661/
<juliank> doko: ^ perhaps something for you to look at? - summary: std::get_time() in libstdc++6 requires leading 0s for %H and friends, but must also accept ones without leading 0s; causing APT to fail for some repos that use " 9" (%k) instead of "09" (%H) for hour formatting
<juliank> this whole C++ thing is so buggy :/
<juliank> We previously used strptime() which worked fine, but requires calling setlocale() around it
<juliank> which is ugly and not thread safe
<pitti> mwhudson: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#docker.io \o/
<juliank> cjwatson, Laney, doko - Reported the libstdc++6 date parsing bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556
<ubottu> gcc.gnu.org bug 71556 in libstdc++ "set::get_time() requires leading 0s for %H and friends" [Normal,Unconfirmed]
<cjwatson> juliank: I think you should probably report this as a Launchpad bug as well.  We can't do much about old Release files, but if %H will work everywhere (which seems likely) then there's really no reason for us not to use that instead of %k and make life a little easier.
<cjwatson> juliank: (obviously that doesn't help other archives)
<juliank> cjwatson: I hope we get this fixed soon-ish, and it only affects 1.3*
<cjwatson> All right, well, whatever you think best
<juliank> But yes, you could just change %k to %H
<juliank> :D
<cjwatson> We should probably prefer what apt-ftparchive uses, which is %H
<pitti> xnox: bug 1422249
<ubottu> bug 1422249 in python-launchpadlib (Ubuntu) "TypeError crash if credentials are expired and needs to re-login [py3]" [Undecided,New] https://launchpad.net/bugs/1422249
<pitti> xnox: bug 1425575
<ubottu> bug 1425575 in python-launchpadlib (Ubuntu) "[py3] corrupts binary bug attachments" [Undecided,New] https://launchpad.net/bugs/1425575
<pitti> xnox: bug 1425627
<ubottu> bug 1425627 in lazr.restfulclient (Ubuntu) "[py3] bug.subscribe() crashes with simplejson.scanner.JSONDecodeError" [Undecided,New] https://launchpad.net/bugs/1425627
<xnox> and bug 1471927
<ubottu> bug 1471927 in launchpadlib "AccessToken.from_string() crashes on python3" [Undecided,New] https://launchpad.net/bugs/1471927
<xnox> barry, ^
<xnox> shall we? =)
<xnox> there is double decode bug.....
<tkamppeter> slangasek, hi
<tkamppeter> slangasek, thanks for fixing bug 1592841.
<ubottu> bug 1592841 in krb5 (Ubuntu) "FTBFS on ppc64el, blocks updates of all packages depending on krb5, for example CUPS" [Critical,Confirmed] https://launchpad.net/bugs/1592841
<tkamppeter> slangasek, but now krb5 does not seem to make it from -proposed into release again, without reason visible on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#krb5
<tkamppeter> slangasek, perhaps it needs some manual kick?
<sarnold> doesn't it take seven days to migrate?
<tkamppeter> sarnold, no, if I upload something into the development branch (no yakkety) it goes into -proposed first and after around an hour it advances to release.
<sarnold> tkamppeter: ah :)
<tkamppeter> sarnold, the seven days are for SRUs. They go into -proposed and the original poster of the bug is called for testing and if there is positive confirmation but no regression report in the seven days, the SRU is advanced to -updates.
<ginggs> tkamppeter: does krb5-sync perhaps need to be rebuilt?
<Laney> transition
<Laney> libkadm5srv-mit10
<slangasek> tkamppeter: it hasn't migrated because what Laney and ginggs say. I'm triggering a rebuild now of the revdeps
<Laney> slangasek: I've got a couple of them already
<nacc> Logan: there are other php-* packages that also add the explicit depends (I based my patch off the same) -- also debian just took the same patch, so we can sync now :)
<nacc> slangasek: thanks!
<nacc> pitti: great, thanks!
<nacc> rbasak: if you wouldn't mind taking a look at and sponsoring bug 1592890
<ubottu> bug 1592890 in php-pimple (Ubuntu) "Fix autopkgtest failure for php-pimple" [Undecided,New] https://launchpad.net/bugs/1592890
<nacc> rbasak: that will clear out two more php excuses (i've already sent the same patch to debian as well)
<nacc> pitti: i believe both armhf failures from the update php-defaults run are testbed issues
<nacc> pitti: php-defaults -> php-horde-imp; php-defaults -> php-horde-ldap
<nacc> pitti: the cacti one may also fail again (it was failing before), but slangasek determined (and I agreed) it's not due to the deps, but something with cacti + armhf itself
<dosaboy> bdmurray: hi, sru 1521396 is *-done so ready when you are :)
<bdmurray> dosaboy: it helps more knowing the package and release rather than a bug number.
<dosaboy> bdmurray: 10-4 lemme get that for you
<dosaboy> bdmurray: python-os-brick and Ubuntu Wily
<dosaboy> bdmurray: hopefully this is the last os-brick sru for a bit ;)
<bdmurray> dosaboy: it's been in -proposed for < 7 days.  Is there a rush to get it in -updates?
<dosaboy> bdmurray: how long would you typically let it bake?
<dosaboy> typically/ideally
<bdmurray> dosaboy: "The SRU team will evaluate the testing feedback and they will move the package into -updates after it has passed a minimum aging period of 7 days."
<dosaboy> bdmurray: ok no problem that makes sense
<bdmurray> dosaboy: looking at the patch again it's basically just one line right?
<dosaboy> bdmurray: yep
<bdmurray> dosaboy: okay, then if its important I'm fine with releasing it early
<dosaboy> bdmurray: sounds good, fwiw this change is in all subsequent versions of Openstack already and was essentiually a type in that release so should be pretty safe
<dosaboy> s/type/typo
<nacc> slangasek: phpseclib -> php-horde-mapi test failure. I am having a heck of a time figuring out what's going on. If I have my adt-run drop to a shell and run the same command as the d/t/control file, it passes. The reason it's failing (I think) is the deprecation warning (maybe the test runner assumes any stderr output is a failure?). phpunit does raise all warnings to exceptions, but even manually
<bdmurray> dosaboy: right, then I'll release it now.
<nacc> hacking it to not do that for deprecations doesn't seem to help. Note that this is also an issue in Debian.
<dosaboy> bdmurray: thanks
<nacc> rbasak: also, if you could add sponsoring from bug 1570472 to your list, that'd be great
<ubottu> bug 1570472 in puppet (Ubuntu) "Set systemd as default service provider" [Undecided,In progress] https://launchpad.net/bugs/1570472
<nacc> rbasak: have a q for you after the meeting, if you have about 5 minutes
<rbasak> Sure
<nacc> rbasak: re: cobbler; it's not a merge as the Ubuntu version is out-of-band with Debian (packaged in Ubuntu before Debian afaict). Is it appropriate to requestsync with a simple -- 'want to get to the Debian version'? What is the best strategy for explaining years of Ubuntu delta accumulation? Do I need to go through each released version and ensure it does/doesn't apply to the Debian version?
<rbasak> nacc: good question. I think it's fine to summarise. There's no hope of maintaining backwards compatibility, this branch is EOL, so we're deliberately breaking to the Debian branch.
<nacc> rbasak: ack, just wanted to confirm, as `requestsync` gave me a whole bunch of delta to explain :)
<rbasak> And that we don't really expect people to upgrade cobbler from release to release anyway without taking a great deal of care and reading the release notes.
<rbasak> It might be worth release noting this.
<nacc> rbasak: yep
<nacc> rbasak: thanks!
<bdmurray> LocutusOfBorg: there are no Launchpad-Bugs-Fixed in the .changes file for your upload of biber to xenial-proposed.
<LocutusOfBorg> sorry bdmurray
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/biber/+bug/1589644
<ubottu> Launchpad bug 1589644 in biber (Ubuntu Xenial) "[SRU] biber 2.4 to xenial" [Low,Fix committed]
<bdmurray> LocutusOfBorg: I saw the bug in the changelog, but its not in the .changes file possibly because you built it on a debian system?
<LocutusOfBorg> no, I didn't
<LocutusOfBorg> dpkg-buildpackage -S -sa -d on ubuntu 16.04lts
<bdmurray> well without a Launchpad-Bugs-Fixed line, the SRU tools won't know about the bug which will slow down the process.
<LocutusOfBorg> but why it didn't add it?
<cjwatson> bdmurray: hm, really?  http://launchpadlibrarian.net/265003294/biber_2.4-1ubuntu1.16.04.1_source.changes shows a Launchpad-Bugs-Fixed line
<cjwatson> bdmurray: linked from https://launchpad.net/ubuntu/xenial/+queue?queue_state=1
<bdmurray> cjwatson: hmm, thanks I didn't realize the package name linked to the .changes file.  I'll try sru-review again
<bdmurray> LocutusOfBorg: okay, that was my mistake
<LocutusOfBorg> wonderful to hear :) thanks for reviewing it
 * LocutusOfBorg leaves to home
<nacc> cyphermox: around? have some quick questions on the current ubuntu delta for sg3-utils
<bdmurray> mwhudson: Is comment #10 a good test case for bug 1574904?
<ubottu> bug 1574904 in docker.io (Ubuntu Xenial) "Docker compiled with wrong version of Go" [High,New] https://launchpad.net/bugs/1574904
<slangasek> nacc: yes, by default anything on stderr is a failure; there's a Restriction that you need to explicitly set if you want stderr to /not/ be treated as a failure
<nacc> slangasek: ah interesting, i think that's what we want for this case -- i'll look for documentation
<nacc> Restriction: allow-stderr
<dobey> i still think that is an insane default
<nacc> slangasek: i think the php-defaults -> php-horde-{imp,ldap} failures in excuses are testbed issues, can you mark them as ignored? (or retry?)
<nacc> slangasek: fyi, i think all php related packages in excuses now have fixes filed for them that are just awaiting sponsorship
#ubuntu-devel 2016-06-17
<nacc> slangasek: and i just worked through all of the TIL from yakkety, i think i hit them all; will check again after that pile of syncs and merges gets sponsored
<cyphermox> nacc: what's up?
<pitti> nacc: I retried the armhf regressions
<xnox> infinity, https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1593592
<ubottu> Launchpad bug 1593592 in command-not-found (Ubuntu Xenial) "many commands not found by command not found" [Undecided,New]
<seb128> could somebody from the SRU team review the network-manager items in the xenial queue? they are waiting for a while and currently the LTS versions of those plugins don't work at all because we didn't update them to match the nm version
<pitti> I'll have a look
<seb128> pitti, hey, thanks!
<seb128> pitti, how are you? still having a productive week?
<seb128> pitti, did you watch the game yesterday evening?
<pitti> seb128: hm, is that the correct bug actually? bug 1297849
<ubottu> bug 1297849 in network-manager-vpnc (Ubuntu) "[SRU] Virtual private network connection fails after distribution upgrade due to outdated Network Manager configuration files" [High,Triaged] https://launchpad.net/bugs/1297849
<pitti> I thought there was another one, with xenial tasks
<pitti> seb128: yeah, we did watch it, but was rather boring..
<pitti> ah, it should have referred to bug 1576726 as well
<ubottu> bug 1576726 in network-manager-openconnect (Ubuntu Xenial) "[SRU] network-manager 1.2.0" [High,Confirmed] https://launchpad.net/bugs/1576726
<seb128> pitti, I don't know why Aron picked that one but it has SRU info&co
<seb128> happyaron, ^
<pitti> meh, I was missing that; this is awfully bad
 * pitti goes ahead and updates the bugs
<seb128> sorry, do you want me to reupload with another bug reference?
<happyaron> yes..?
<seb128> happyaron, see what pitti said
<pitti> bugs updated
<seb128> pitti, thanks
<happyaron> k
<xnox> cjwatson, infinity - W: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/us.ports.ubuntu.com_ubuntu-ports_dists_yakkety_InRelease
<xnox> i think it's broken for the first 9h59m of the day
<happyaron> was trying to use one report for all the 1.2.0 SRUs
<xnox> Date: Fri, 17 Jun 2016  8:06:11 UTC
<xnox> vs
<xnox> Date: Fri, 17 Jun 2016 03:15:36 UTC
<seb128> happyaron, right, but you used 1297849 for the openconnect one which is an older bug?
<xnox> wgrant, ^^^^
<seb128> pitti, thanks for the review
<seb128> pitti, is there anything you want us to change/fix on the bugs/uploads?
<pitti> seb128: nah, it's fine
 * pitti reviews a couple of other things in the queue
<seb128> k, sorry if there was an issue with the bugs
 * seb128 hugs pitti
 * pitti hugs seb128 back :)
<sarnold> tvoss: looks like internal irc is dying..
<sarnold> tvoss: does ps auxwZ show any security contexts for the processes involved?
<tvoss> sarnold, checking
<tvoss> sarnold, yup, most of them show 'unconfined'
<Odd_Bloke> I see that a test rebuild of xenial is currently under way.  Can someone educate me (or point me to somewhere I can educate myself): why do we do test rebuilds, and why are we doing one now?
<wgrant> xnox: LP has always done that. Has apt changed recently?
<Laney> xnox: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556
<ubottu> gcc.gnu.org bug 71556 in libstdc++ "set::get_time() requires leading 0s for %H and friends" [Normal,New]
<wgrant> Odd_Bloke: Test rebuilds are done periodically to ensure that packages are still buildable. In this case it's probably to test a gcc SRU.
<Laney> perhaps this apt should be removed in the meantime
<Laney> or uploaded with that change reverted
<Laney> juliank: ^- thoughts?
<wgrant> Odd_Bloke: There are usually a few done during a series' development to check that we don't release binaries that we can't fix later.
<xnox> Odd_Bloke, because if the mega toolchain updates in xenial-proposed/updates? =) e.g. there is gcc point release, python point release, ruby point release, binutils updated....
<xnox> and we are redoing a test rebuild with that new toolchain, which is aimed for xenial SRU
<xnox> Odd_Bloke, there was a session about this, here at the Athens Core sprint =)
<slangasek> nacc: php-defaults -> php-horde-{imp,ldap} looks to have passed; did you get someone to retry those, then?
<GunnarHj> pitti: Hi Martin, wonder if you can take a look at bug #1592162 and the ubuntu-docs item in the xenial queue. There are several other bugs mentioned in the changelog, but I'd prefer not to create xenial tasks for those if possible, so the verification can be done at one place.
<ubottu> bug 1592162 in ubuntu-docs (Ubuntu Xenial) "Translation update + extras" [Medium,In progress] https://launchpad.net/bugs/1592162
<juliank> Laney: That only affects 1.3~exp2 in proposed AFAICT, so we can drop that from proposed for now
<juliank> But does that really use proposed packages?
<Laney> juliank: Right - I didn't know if you wanted the other fixes to go into yakkety, or not
<Laney> buildds
<Laney> sorry, got a call now, brb
<juliank> I'm not sure how long it takes to fix this in libstdc++6, maybe we should revert it in the mean time for 1.3~exp3
<xnox> wgrant, whilst it's valid to have " ", "0", "1", "2". however currently in yakkety i cannot upgrade for 9h59m of UTC time.
<xnox> wgrant, could you hack launchpad to start using leading "0" instead of leading " " despite, " " being valid?
<xnox> juliank, 1.3~exp2 is on devac02 for me
<xnox> juliank, it's in yakkety-proposed.
<xnox> ... so affect all yakkety builds
<wgrant> xnox: I'd really prefer that the apt regression be fixed rather than hacking around the regression in permanent LP code.
<wgrant> (it's also faster to fix apt)
<Laney> juliank: If it's okay with you I'll upload an apt with that commit reverted, and we can sync exp3 over that once it's available
<cjwatson> wgrant: I think we probably should change LP, but not because of the apt regression (and I think we should get apt sorted out first), but rather because using %H rather than %k would match apt-ftparchive
<rbasak> Do you have a pointer to the apt regression please? The new apt in proposed is causing the pdns mysql dep8 test to fail, but I haven't figured out if it's just due to non-determinism changing configure ordering or a bug in apt yet.
<Laney> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1593583
<ubottu> Launchpad bug 1593583 in apt (Ubuntu) "Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_yakkety-proposed_InRelease" [Undecided,Confirmed]
<rbasak> Thanks
<rbasak> I guess that sounds unrelated.
<Laney> Unless you're seeing messages about date parsing, I'd say so
<wgrant> cjwatson: But being gratuitously different finds bugs in standard libraries!
<cjwatson> wgrant: True, I guess.  I also happen to think the "maybe one space, maybe two" form is ugly though :)
<wgrant> cjwatson: I can't disagree.
<slangasek> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mwhudson, slangasek
 * dholbach hugs mwhudson and slangasek 
<GunnarHj> slangasek: Hi Steve, saw that you are piloting, and wonder if you can take a look at bug #1592162 and the related ubuntu-docs item in the xenial queue (already uploaded). The changelog includes several other bugs, but my wish is to concentrate the verification to the one I just mentioned, where it all is explained. Is that ok?
<ubottu> bug 1592162 in ubuntu-docs (Ubuntu Xenial) "Translation update + extras" [Medium,In progress] https://launchpad.net/bugs/1592162
<juliank> Laney: Fine with me, I ask DonKult if there's any gotcha, let's see what he says
<Laney> juliank: It's uploaded - we can sync the next fix
<Laney> (I presume this bug affects experimental too)
<slangasek> GunnarHj: please remove the other bug references from the changelog in that case, because otherwise it becomes difficult to track / determine the verification status of the bugs
<slangasek> GunnarHj: (so, this should be an upload without the bug references, and a reject of the one currently in queue)
<GunnarHj> slangasek: Ok. Can you reject the current upload?
<slangasek> GunnarHj: done
<GunnarHj> slangasek: Thanks!
<rbasak> nacc_: around? When you get a reconstruct now that we have the importer, do you just end up tagging a commit that the importer imported?
<rbasak> nacc: also https://git.launchpad.net/~nacc/ubuntu/+source/sg3-utils/log/?h=merge&id=reconstruct/1.40-0ubuntu1 is interesting. It looks odd, but is correct.
<rbasak> when you *tag* a reconstruct I mean.
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mwhudson, slangasek, seb128
<slangasek> tkamppeter: hi, so I'm hitting EOD here at sprint, but I wanted to at least briefly update you regarding the lsb printing stuff
<slangasek> tkamppeter: I'm having a hard time deciding on a path forward here, because I notice all of the openprinting.org LSB packages declare a dependency on the full LSB, not just on the printing module
<slangasek> tkamppeter: and we *know* that we don't implement the full LSB, due to Qt, which is precisely why the LSB packages were being dropped from Debian
<slangasek> tkamppeter: so, how much of the LSB do the openprinting packages actually need?  Could they be changed to declare that they only need core+printing?  Do they need more, and if so which pieces?
<nacc_> rbasak: hey
<nacc_> slangasek: yep, pitti hit them, thanks!
<nacc_> cyphermox: i found some stray changes to debian/ that don't seem like delta we want to carry -- but wanted to double-check with you
<nacc_> cyphermox: https://git.launchpad.net/~nacc/ubuntu/+source/sg3-utils/commit/?h=merge&id=a3e87b386e479e8160b71dc37909e011717e3226
<nacc_> rbasak: that would only be the case if the original commit wasn't a merge
<rbasak> nacc: I don't follow. What do you mean by original commit?
<nacc> rbasak: `usd-merge reconstruct <commitish> <commitish>` takes each commit between the two cherry-picks them so they are linear
<nacc> rbasak: so reconstruct is tree-identical to some tagged commit
<rbasak> Oh, yes of course, sorry.
<nacc> rbasak: (presuming our process and an imported version is the tip of the ubuntu/yakkety)
<rbasak> So if there are merge commits, then the reconstruct will end up being not one of the imported ones.
<rbasak> Got you, thanks.
<nacc> rbasak: but it's not commit-identical, since we altered the parenting
<nacc> rbasak: yeah
<rbasak> I've got the beginnings of a cloner/linter BTW. It flags sg3-utils because "usd-merge tag ubuntu/(devel)" doesn't do what you did, because we're intentionally throwing away the latest sync :)
<nacc> rbasak: and reconstruct does that check to ensure it's tree-identical to the original commit, as well
<nacc> rbasak: yeah, i wondered about that :)
<nacc> rbasak: and awesome to hear!
<nacc> pitti: apologies, just filed LP: #1593768 so php-defaults won't break php-radius anymore
<ubottu> Launchpad bug 1593768 in php-radius (Ubuntu) "Sync php-radius 1.4.0~b1-6 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1593768
<nacc> rbasak: also, sorry for bombarding you with MRs
<nacc> rbasak: most are pretty trivial, i hope
<rbasak> nacc: it's fine. That's prompted me to write the tool. Might as well write the script then run it six times or whatever :)
<nacc> rbasak: :) i almost wrote it myself when i was submitting it `usd-merge review` or whatever, that just did the sanity checks
<nacc> rbasak: i mean it couldn't necessarily verify the only change to control is metadata or changelog is ubuntu versions, but it can verify the only changes are to both, for instance
<rbasak> nacc: I might commit my script to wip/review or something in git master or something, so everyone can make use of it early. It's hacky and has copy and pasting involved etc but it seems better to me to do it this way than have it in a separate branch. Sound oK?
<nacc> rbasak: totally fine with me!
<rbasak> nacc: https://git.launchpad.net/~nacc/ubuntu/+source/sg3-utils/commit/?h=merge&id=0785667f26f3901c65e62f378adba0d89ecb2dff has only upstream changes. I didn't think that would be in logical at all?
<nacc> rbasak: a good point -- it was part of the old delta (in that it was part of the tree in that version) because upstream was cherry-picked down ahead of Debian (from Debian git)
<nacc> rbasak: i guess i could have dropped it from reconstruct in logical, is that what you mean?
<rbasak> nacc: right
<nacc> rbasak: i did end up dropping it in the rebase, since Debian moved past the same upstream
<nacc> rbasak: you're right; i tend to keep logical/ complete for some reason, but i should have trimmed it down to ... logical ... changes
<rbasak> nacc: I think it is semantically part of reconstruct and deconstruct, but not logical.
<rbasak> :-)
<nacc> rbasak: yep, I just always worry about losing track of bits of delta in the rebase to new/debian; so i find it easier to drop there (not trusting myself to have decided what was or wasn't logically part of the delta)
<nacc> rbasak: i guess i know better now, but i didn't before :)
<rbasak> When we can lint logical that should be easier. Then you'll be able to trust that logical is correct more easily.
<nacc> rbasak: yep, agreed
<nacc> rbasak: want me to fix-up and send a new MR? or since you're mid-review, i guess you've got a handle on it?
<nacc> rbasak: ah i remember why
<nacc> rbasak: acc'g to our workflow, logical/ is supposed to match old/ubuntu exactly except for changelog and metadata
<rbasak> No need to fix this up. It doesn't impede my review at all, just a little surprising from the process perspective.
<nacc> rbasak: we might have changed that, but i thik that was my sanity check
<rbasak> Sorry, I've probably forgotten about my addendum because a new upstream is an edge case. Changes not to debian/ for 3.0 (quilt) packages are fine to ignore too.
<nacc> rbasak: yep, that makes sense -- we have a better definition of the 'logical' now, i think
<nacc> rbasak: i'll work today on fleshing out the public wiki page, and maybe we can clarify that there
<nacc> dholbach: jgrimm mentioned to me that you might be antoher good person to pull into our git-based workflow
<dholbach> nacc, I'm not sure - how can I help?
<nacc> dholbach: oh no help needed, more of an fyi: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
<dholbach> ah yes, I saw the edits of the page
<nacc> dholbach: might be a nice piece to have for new community members
<dholbach> yes it is
<nacc> dholbach: who do know git, but don't know packaging as well
<dholbach> maybe we could have a discussion about it on ubuntu-devel@ about it?
<dholbach> if we want to make it the default
<dholbach> and update our docs accordingly
<dholbach> I know packaging.u.c is still referring to bzr-lp
<rbasak> I don't think we're quite ready for that yet - the importer is only run by nacc (or theoretically by me though I haven't done it yet) on demand.
<nacc> dholbach: yeah it's probably not ready for prime-time yet :)
<nacc> dholbach: but eventually :)
<dholbach> it might be good to discuss it already
<nacc> dholbach: my plan was to keep fleshing out that wiki page and then send it ubuntu-devel
<rbasak> We should probably get to the stage before we are running it automatically before we recommend it for general use.
<dholbach> to see what kind of feedback people have
<dholbach> nacc, nice!
<dholbach> good work!
<rbasak> dholbach: discuss it already> certainly
<dholbach> <3
<nacc> dholbach: we also want to work on the side rbasak has been working on, which is more of the review of merges/development all in git
<dholbach> ok
<dholbach> I haven't used git-lp yet O:-)
<nacc> dholbach: just wanted to get it on your radar, thanks!
<dholbach> thank YOU :)
<cjwatson> nacc: I don't suppose I can persuade any of you folks to work on bits of the LP side of this?
<rbasak> cjwatson: what's the roadmap for the LP side of this, OOI?
<cjwatson> rbasak: enotime
<cjwatson> rbasak: or do you mean what are the items on it?
<rbasak> cjwatson: no, I mean if you did have time, what work needs doing?
<rbasak> Right :)
<cjwatson> rbasak: can you see https://trello.com/c/KPGdVNXf/275-add-dgit-support-to-launchpad ?
<cjwatson> oh wait, that doesn't have the checklist
<nacc> cjwatson: i'd be happy to at least try and help!
<rbasak> FWIW, I don't think I have a suitable Trello account
<cjwatson> rbasak,nacc: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html is still basically right
<cjwatson> modulo dgit-specific stuff, although I do think that if you could make your stuff dgit-compatible or even using dgit then that would be great
<rbasak> I still need to study dgit again. In fact, as it's a Friday afternoon, I might do that now.
<nacc> cjwatson: yeah, i jokingly suggested renaming to ugit as a move towards combining them :)
<rbasak> Certainly the last four items of that list coincide with our goals I think.
<nacc> rbasak: agreed
<cjwatson> rbasak,nacc: http://paste.ubuntu.com/17435877/ is my work-in-progress patch to dgit to use the LP API
<cjwatson> I think your importer would plug in well provided that it constructs compatible trees
<cjwatson> might well be worth talking with Ian about it
<rbasak> Is there a public dgit tree somewhere I can poke at?
<rbasak> Or do I need to use dgit to clone one?
<cjwatson> git://anonscm.debian.org/dgit-repos/repos/dgit.git
<rbasak> http://anonscm.debian.org/cgit/dgit-repos/dgit.git - No repositories found
<cjwatson> is that right?  I think so
<rbasak> But I don't mean a tree for dgit itself
<cjwatson> oh I see
<rbasak> I mean a tree that is what a package looks like when fetched with dgit
<rbasak> Aha
<rbasak> https://browse.dgit.debian.org/
<cjwatson> ah well done, I was just looking for that
<cjwatson> also dgit(1) and dgit(7) describe some of it
<cjwatson> anyway, the next big thing on the LP list is to hook archive upload permissions up to permission to push to lp:ubuntu/+source/thing
<rbasak> That's "* Archive-permission-based ACLs for target-default package repositories" I think?
<cjwatson> that's a very well-bounded task that somebody could take on and would learn a bit about how the LP git code works while they're there
<cjwatson> yep
<cjwatson> it's probably about two weeks for a complete LP newbie provided they have prior Python experience
<cjwatson> maybe a week
<cjwatson> and I can mentor
<rbasak> I'd enjoy that I think. So would nacc probably.
<rbasak> We need to discuss our priorities I think though.
<cjwatson> Yep.
<rbasak> And who'd want to turn down the opportunity of being mentored by cjwatson :-)
<cjwatson> Heh ;-)
<seb128> shrug at the sponsoring queue
<seb128> Laney, there is a stack of "appstream icon for ..." bugs with only images attached and no details, no diff, nothing
<seb128> is that a result of one of our call for appstream improvements?
<Laney> yes
<seb128> should we just unsubscribe sponsors since those are not really in sponsoring state
<seb128> like no explanation nor diff
<seb128> they sit there since march
<Laney> they take a bit of work to sponsor
<nacc> rbasak: cjwatson: sorry got distracted by something else; agreed, this sounds like a good intersection point!
<Laney> since the problem often is not that the icon is missing
<Laney> it's sometimes random other issues
<seb128> it feels like those bugs don't have enough data that anyone feels like sponsoring
<seb128> also I don't think many of us feel qualified at deciding if a random icon should represent a program
<seb128> should be an upstream decision
<rbasak> """If  you  are  a  quilt  user you need to know that dgit's git trees are
<rbasak>        `patches applied  packaging  branches'  and  do  not  contain  the  .pc
<rbasak>        directory (which is used by quilt to record which patches are applied)."""
<slangasek> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mwhudson, seb128
<rbasak> I'm not very keen on that.
<rbasak> Who made the call for contributions? That person presumably has some expectation over how to handle sponsorship?
<cjwatson> rbasak: Ah, now, that's one of the reasons I specifically like dgit :-)  For maintenance purposes I think it has to be paired with something like git-dpm.
<Laney> seb128: The icons being "random" wasn't really the problem that I encountered
<cjwatson> I don't think I would be interested in using something that wasn't compatible with git-dpm.
<Laney> If you don't think they are useful then by all means get rid of them
<Laney> The alternative is to actually figure it out on a case by case basis
<seb128> Laney, well, I picked https://bugs.launchpad.net/ubuntu/+source/jedit/+bug/1558671 and I don't understand what the request is about
<ubottu> Launchpad bug 1558671 in jedit (Ubuntu) "AppStream icon for jedit.desktop" [Undecided,New]
<rbasak> I considered handling quilt out-of-scope for my initial merge workflow. Using commits with quilt fully popped doesn't seem to have impeded this at all.
<seb128> Laney, there is just a .svg attached to the bug and no debdiff nor package changes
<rbasak> I understand how git-dpm is a big improvement for someone using git to actually maintain a quilt patchset.
<Laney> seb128: Ship it in the hicolor scalable directory
<Laney> There were mails about this to devel-announce and devel
<rbasak> It might be tricky to find a clean way to integrate this all though.
<seb128> Laney, right, but I don't even know the icon license nor if upstream would be happy to have that icon representing their program
<Laney> Fine
<seb128> Laney, thanks
<Laney> You don't have to look at it
<Laney> just get rid of them
<seb128> no, it's fine
<seb128> it's just that sit in the queue since march
<seb128> but I'm going to do like the others and let them here
<seb128> somebody eventual can pick them
<seb128> eventually
<Laney> I doubt that anybody except me ever will
<Laney> This stuff needs to get less bus factory
<Laney> but I'll try to deal with some of them next shift
<seb128> thanks
<seb128> the issue there is also that most people don't know about appstream
<seb128> I know email were sent, I read them but the details didn't stick
<seb128> and those bugs are not actable without investment to figure out how things work, what should be done exactly etc
<seb128> they are a bit poor form for sponsoring requests
<seb128> like the contributors let us the work to figure out the details and do the packaging and testing
<Laney> http://article.gmane.org/gmane.linux.ubuntu.devel/39405
<seb128> I guess it would help to put that url in the bugs description ;-)
<seb128> but yeah I remember
<seb128> well, for some reason they are not being picked up -:/
<seb128> but sponsoring activity seems a bit low recently as well
<seb128> oh well
 * seb128 sponsors a few more items to help getting the queue lower than 110
<rbasak> slangasek: re bug 1593768, sorry, I was "syncpackage: Please wait for the sync to be successful before closing bugs."
<ubottu> bug 1593768 in php-radius (Ubuntu) "Sync php-radius 1.4.0~b1-6 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/1593768
<rbasak> I'm never sure what to wait for exactly, BTW. Proposed accept email? Release pocket accept email?
<rbasak> It'd be nice if syncpackage could tell LP the -b argument and have LP handle it like a changelog mention.
<nacc> slangasek: thanks as always for the sponsorships!
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mwhudson
<cjwatson> rbasak: Yeah, that's bothered me for a while, since technically it should be Release accept but who wants to wait for that
<cjwatson> Needs a bugs= parameter to Archive.copyPackage, I guess, and then propagate that all the way down the stack to close_bugs_for_sourcepackagerelease
<tkamppeter> slangasek, the LSB printing packages from Epson are simply print filters in reality, no GUI no network backends, ... they should simply work with lsb-printing.
<rbasak> cjwatson: glad you agree. Add it that enotime backlog :-P
<nacc> can someone retrigger the tests for phpseclib -> php-horde-mapi (new version landed in yakkety)
<nacc> also, php-random-compat -> php-symfony-polyfill (s390x) seems stuck. It says in progress, but I don't see it in the queue?
<nacc> finally, the php-horde-support -> php-horde-group (ppc64el) failure seems to be a testbed failure, can it also be retried
<nacc> woo, php-defaults finally transitioned out of excuses :)
<nacc> hrm, same issue with php-horde-stream -> php-horde-mime (ppc6el) (test says in progress, but it's not in the queue?)
<nacc> down to 73 mentions of php in excuses :)
<rharper> shagu
<nacc> rbasak: do we want to send the icinga2 delta to debian (mysql 5.7 related)
<nacc> rbasak: i think if we did and they took it, we can sync icinga2 in yakkety
#ubuntu-devel 2016-06-18
<Saviq> if anyone's around, would you please â» the two regressions visible here for qtmir and unity-api http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#qtmir thanks!
<Saviq> actually might throw in the unity-scopes-api one as well
<Saviq> although those ones I'm afraid are not flakies but something gone wrong with BT on the armhf side "Job for bluetooth.service failed because the control process exited with error code."
#ubuntu-devel 2016-06-19
<dminca> Hello everyone
<dminca> has anyone manage to make a PPA out of personal ?dotfiles
<dminca> I would like to see some sample projects on personal dotfiles, just so I would get the gist of packaging them
<melodie> hello
<melodie> I meet with an issue with geany in Xenial. Since a few days when I launch it it does not show, and it starts a process that eats almost all the RAM. I'd like to do a strace before reporting it : how do I end the command line to make it write the output to a file?
<dminca> melodie: command > output_file_name
<melodie> hi dminca : no need of something looking like "2 >&" or "2& >" or the kind?
<melodie> strace can be tricky
<dminca> nah
<jtaylor> just use the -o file option of strace
<dminca> > is to overwrite
<dminca> >> is to append
<dminca> ...yeah, or that.
<melodie> ok, I reported a bug against Geany
<dminca> what's the difference between httpd and apache ?
<maswan> apache is a free software project/foundation. apache httpd is their most famous software. also, httpd can be a non-apache http daemon too.
<dminca> httpd can also be a proxy ?
<infinity> dminca: Some httpd servers can only proxy, some httpd servers can only server local content, and some (like apache httpd) can do both.
<infinity> s/only server/only serve/
<infinity> dminca: These aren't really appropriate questions for a development channel, FWIW.
<dminca> ok, thanks infinity
<JanC> there are even httpd servers who can do neither
<mwhudson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mwhudson> (only about a week late)
#ubuntu-devel 2017-06-12
<LocutusOfBorg> mdeslaur, hello, I *think* pcsc-lite can be sync'd now, because the dlopen stuff in wpa supplicant is now useless https://packages.debian.org/unstable/wpasupplicant
<LocutusOfBorg> it is now linked that library, so moving it seems to be useless
<bdrung> bdmurray, hey, do you have time to review my patches for apport?
<bdmurray> bdrung: I'm catching up from a sprint last week but will add it to my todo list.
<bdrung> bdmurray, thanks. ping me in case you have questions.
<seb128> slangasek, hey, can we get $team-reports to use ~desktop-bugs instead of ~desktop-packages? we have been using -bugs for MIRs&co for a while and the other team was an old QA created one by pedro which is unmaintained and subscribed to random components pedro wanted to include in qa reports back then
<cyphermox> bdmurray: ^ this is about the master package team mapping list
<bdmurray> seb128: what about the packages to which desktop-packages is subscribed to and desktop-bugs is not?
<seb128> bdmurray, not sure what you mean, those are a random collection ~desktop-packages is a list pedro made back then to build qa reports of things "desktopish", why would we have those on our list?
<seb128> bdmurray, like "amarok" is there which we never users/maintained
<bdmurray> seb128: The goal with the subscriptions was to have a team who'd look after a bug if an important one came up about a package e.g. https://bugs.launchpad.net/~foundations-bugs/+packagebugs is stuff we are subscribed to.
<seb128> bdmurray, yes, I know, and we have been using ~desktop-bugs as our team for MIRs for years so that's the correct one
<seb128> bdmurray, ~desktop-packages is a team owned by pedro who left the project years ago
<seb128> it's just an outdated leftover
<bdmurray> seb128: Okay, but we I think its still worth reviewing packages subscribed to by that team and not by desktop-bugs to make sure we don't lose anything legitimate.
<bdmurray> seb128: I'm happy to make such a list.
<seb128> bdmurray, I can do the list, it's basically copying +packagebugs from both teams and diffing
<seb128> but thanks
<elopio> bdmurray: any chance of getting click and snapcraft in proposed today? Or maybe I should ping the person in SRU vanguard today.
<gsilvapt> Hello all. I'm trying to arrange a debian/control file with wrap-and-sort but the command does nothing and there is stuff to sort within the control file. Any suggestion?
<gsilvapt> The -v options returns nothing too
<Skuggen> gsilvapt: The control file is inside a debian/ directory and isn't "different" in any way like a changed filename?
<rbasak> gsilvapt: are you running wrap-and-sort from the top level of your source tree?
<gsilvapt> No, Skuggen and yes, rbasak
<elopio> infinity: hello. We need help to get click and snapcraft into -proposed.
<infinity> elopio: Of which release?
<elopio> we need click 0.4.46+17.10.20170607.3-0ubuntu1 and snapcraft 2.31. In xenial, yakkety and zesty -proposed.
<elopio> last I heard on friday we were waiting for the dput of click in artful.
<slangasek> elopio: when I spoke with bdmurray on Friday, he was reviewing it and found that the SRU bug for click did not have the necessary information
<infinity> elopio: I see no click in the xenial queue.
<elopio> slangasek: yes, I added it on friday.
<slangasek> ok
<slangasek> infinity: I see it for yakkety+zesty; perhaps bdmurray didn't make it as far back as xenial for the sponsorship
<infinity> https://bugs.launchpad.net/ubuntu/+source/click/+bug/1693226/comments/4
<ubottu> Launchpad bug 1693226 in click (Ubuntu Zesty) "Break the conflicts with click the optparser" [Undecided,New]
<infinity> Rather than just fix the bug, looks like someone decided to backport it?
<bdmurray> https://bugs.launchpad.net/ubuntu/+source/click/+bug/1693226/comments/4
<bdmurray> Right and I didn't feel comfortable sponsoring that.
<slangasek> right
<elopio> oh.
<elopio> What can we do to make sure it's safe?
<slangasek> we can not do a wholesale backport
<infinity> ^
<slangasek> instead of including unrelated changes and then having to figure out how to prove they're safe
<infinity> SRUs should be about fixing targetted bugs, not upgrading everything to the latest and shiniest.
<infinity> (I realise snapcraft and snapd may have set unrealistic expectations here. :P)
<elopio> not at all, I understand the goal of SRUs. I just thought Sergio had it all covered.
<elopio> but I'm just not sure I understand what's needed. Should I hand-pick the module rename on top of the version that's on xenial?
<kyrofa> And the test fixes, probably
<infinity> Yes.
<elopio> the other change was to get the tests passing in artful, so that won't be necessary.
<kyrofa> Oh that was artful-specific? Handy
<elopio> infinity: what should I give you? a diff, a branch, a deb? And do I need to make a separate bug for xenial?
<infinity> Same bug(s).
<infinity> Odds are that http://launchpadlibrarian.net/323335627/click_0.4.45.1+16.10.20160916-0ubuntu1_0.4.46+16.10.20170607.3-0ubuntu1.diff.gz will sort of just work for the older version, unless the code moved around a bit between xenial and yakkety.
<kyrofa> I doubt the code has changed much
<elopio> I think it should conflict at least a little. But doesn't sound hard.
<infinity> elopio: A debdiff between current xenial and the proposed fixed package should do.
<elopio> infinity: awesome, thanks.
<infinity> I imagine applying the patch wholesale will conflict a tad just because OMG WHOLE FILE RENAMES really don't agree with diff/patch.
<infinity> But should be trivial to reconstruct it conceptually by hand.
<infinity> Trivial, but time consuming, so I'd rather it was your time. ;)
<elopio> infinity: oh, of course, it's not something we should outsource :)
<elopio> unless we could get our Naming Chief Officer to do it...
<infinity> PS: Can someone hop in a time machine to when unified diff was specced and add mv, link, and mode?  Thanks.
<infinity> And rm.
<infinity> "This whole file became /dev/null" is such a helpful way to represent a deletion.
<jbicha> infinity: if you're doing SRU candidates, could you look at libgweather 3.24.1/zesty (you can reject 3.24.0)
<juliank> I wonder if we could have an e2fsprogs backport for xenial that supports metadata_csum, as the HWE kernel supports that. Does that make sense to anyone other than me?
<kyrofa> infinity, re the xenial click patch, what do I do with the changelog version in such a case?
<xnox> juliank, yes.
<juliank> xnox: But how? Just updating e2fsprogs to 1.43.something seems dangerous, should we have an e2fsprogs-hwe package?
<juliank> Or just in -backports?
<juliank> (both would work, obviously)
<nacc> mdeslaur: are you working LP: #1574670 ?
<ubottu> Launchpad bug 1574670 in update-manager (Ubuntu Xenial) "ubuntu-support-status returns inaccurate information" [Undecided,Confirmed] https://launchpad.net/bugs/1574670
#ubuntu-devel 2017-06-13
<mdeslaur> nacc: I haven't had time to look at it yet
<mdeslaur> nacc: I have to basically modify the tool to use the main/universe split instead of looking at the support period listed in the Packages files
<mwhudson> oh heh i made some uploads just after a kde update
<mwhudson> so i'll get my autopkgtest results next week then
<lathiat> e
<jamespage> any arm* linker guru's able to help my understand why I see this linker failure on armhf only - https://launchpadlibrarian.net/323794587/buildlog_ubuntu-artful-armhf.ceph_12.0.3-0ubuntu1~ubuntu17.10.1+ppa11_BUILDING.txt.gz
<jamespage> ?
<seb128> hum
<ginggs> jamespage: i recognize the compiler warning, but can't see what the actual linker error is.  where can i find the source package?
<jamespage> ginggs: you can pull it from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2779/+packages
<ginggs> jamespage: ta
<seb128> the urls to download the debs from https://launchpad.net/ubuntu/artful/+queue?queue_state=0&queue_text= don't work
<seb128> they lead to "Lost something?" launchpad pages
<seb128> e.g  libebook-1.2-19_3.24.2-0ubuntu2_amd64.deb (69.7 KiB) NEW
<seb128> -> https://launchpad.net/ubuntu/artful/+upload/15539512/+files/libebook-1.2-19_3.24.2-0ubuntu2_amd64.deb
<seb128> cjwatson, wgrant, hey, do you know if that's a launchpad bug/known issue?
<cjwatson> seb128: https://bugs.launchpad.net/launchpad/+bug/1697680 - reported by Didier earlier today and I pushed an MP to fix it
<ubottu> Launchpad bug 1697680 in Launchpad itself "Can't access binaries in NEW queue (source packages assets are fine though)" [Critical,In progress]
<seb128> thanks
<seb128> sorry for not checking launchpad reported bugs first, I should know better
<cjwatson> seb128: interesting that we rolled out the change that caused that regression on 2017-05-11 and you both noticed it within hours of each other :)
<seb128> (I had IRC closed during lunch so didn't notice that didrocks hit that earlier)
<seb128> hehe, yeah
<cjwatson> (it was a consequence of the fix for bug 1663334)
<ubottu> bug 1663334 in Launchpad itself "make queue files dget'able" [Low,Fix released] https://launchpad.net/bugs/1663334
<seb128> archive admin reviews are not going strongly nowadays :-/
<cjwatson> seb128: (you can use queue fetch as a workaround)
<seb128> ah, nice to see those becoming dget compatible!
<seb128> I did get the binaries from the build page
<cjwatson> or that, yes
<seb128> they are just not marked as New so a bit of forth and back but it was ok :-)
<seb128> thanks!
<cjwatson> np
<ginggs> jamespage: i'm gonna try building with --no-parallel in case that makes the build log easier to follow
<jamespage> ginggs: ok it will take some time...
<jamespage> ginggs: thanks for the help
<ginggs> doko and infinity know of that warning.  I started a wiki page to keep track of affected packages https://wiki.ubuntu.com/GCC7#arm_gcc_7_abi_transition . ceph is the first build failure I've seen, the others fail autopkgtests because of the warning
<ginggs> jamespage: ^
<rbasak> cyphermox: please see bug 1624519 - I pinned it down. I think it's related to your merge of tasksel 3.34ubuntu1.
<ubottu> bug 1624519 in tasksel (Ubuntu) "Debian-defined tasks override Ubuntu-defined ones" [Undecided,Triaged] https://launchpad.net/bugs/1624519
<nacc> mdeslaur: yep, just checking, we had one user respond in a different bug (php7.0-fpm MIR) and referred to that bug as to why the status is what it is. Presumably it's a cherry-pick(s) back from the yakkety version?
<mdeslaur> nacc: no, yakkety doesn't contain a fix....the tools needs to work around the fact that the Support tag wasn't updated correctly in previous releases
<mdeslaur> right now yakkety is ok, just because it's not an LTS release
<mdeslaur> actually, I'm not even sure if yakkety is ok
<nacc> mdeslaur: oh! :) it's marked fix released by bdmurray
<mdeslaur> yeah, it's complicated...some of the yakkety universe packages have "Supported: 9m"
<mdeslaur> when in fact...they probably shouldn't
<nacc> mdeslaur: ok, it seems like you have a solid handle on it :)
<mdeslaur> kind of :P
<kyrofa> Hey infinity, I've got a click patch for xenial that works, and I figured I should just bump the ubuntu2 to ubuntu3. However, there is no debian/patches currently, and I'm not sure how to build a source deb using the 0.4.43 orig tarball without debian/patches
<kyrofa> (my debian packaging chops need some work, so I'm pleased I'm getting exposed to this, but I could use some guidance)
<nacc> kyrofa: d/p only exists if there are patches to apply?
<nacc> kyrofa: that is, if it's an upstream source change
<nacc> kyrofa: is it? (or what is the patch specifically)
<cjwatson> kyrofa: click is a native package.  don't use debian/patches/
<cjwatson> kyrofa: just apply the thing directly
<cjwatson> well, its versioning isn't technically native, but still
<nacc> cjwatson: ah, makes sense
<kyrofa> cjwatson, yeah the versioning was throwing me off. I tried applying directly, but of course when I use the 0.4.43 orig tarball I get complaints of local changes. Should I not be using that orig?
<cjwatson> kyrofa: I would be inclined to construct a version along the lines of 0.4.43+16.04.20170613-0ubuntu1.  bileto should be able to do that for you if you give it the right input
<cjwatson> kyrofa: e.g. an MP that's based on the correct starting point
<cjwatson> kyrofa: "Revert to r606" in your MP - why?  Why not just branch from r606 in the first place?
<kyrofa> cjwatson, ah, which would be a new tarball, that does make things easier. infinity just asked for a debdiff, I shouldn't need to make a new MP unless you want me to?
<cjwatson> well, your branch, not your MP
<kyrofa> cjwatson, because I don't know bzr :P . If I was to make a MP it would of course be cleaned up
<cjwatson> kyrofa: It would be preferable to figure out how to land this using bileto if possible
<kyrofa> cjwatson, okay
<cjwatson> kyrofa: I've pushed lp:~click-hackers/click/xenial, which should help you; it should be possible to branch that and use it as the target for an MP
<kyrofa> cjwatson, excellent, I'll do that, thank you
<rbasak> xnox, slangasek, rharper: do we have a bug tag for the netplan server iso related work? Bug 1697730 is a candidate I think.
<ubottu> bug 1697730 in systemd (Ubuntu) "Long boot time due to systemd-networkd-wait-online.service failure" [Undecided,New] https://launchpad.net/bugs/1697730
<slangasek> rbasak: bugs are being linked from the blueprint https://blueprints.launchpad.net/ubuntu/+spec/foundations-aa-migrating-to-netplan
<slangasek> rbasak: also, cyphermox
<rbasak> Linked, thanks.
<ogra> wow, you re-vived blueprints ?
<slangasek> they've never been dead
<ogra> well, others said differently :)
<ogra> good to see someone still uses them
<tdaitx> bdmurray, to enable staging it's enough to just add a 'staging' in the crashdb-conf's ubuntu entry, right? after that, how do I access the staging error tracker?
<bdmurray> tdaitx: No - that's for apport. To switch whoopsie you'd do stop the whoopsie service and manually start it via 'sudo CRASH_DB_URL=https://daisy.staging.ubuntu.com'. Then go to errors.staging.ubntu.com/OOPS/$OOPS_ID.
<kyrofa> cjwatson, so do I target xenial in bileto, then?
<bdmurray> sudo CRASH_DB_URL=https://daisy.staging.ubuntu.com whoopsie -f'
<bdmurray> tdaitx: ^^ that's what I really meant
<tdaitx> bdmurray, right, thanks, I will check why it is duplicating the tag, it shouldn't... I used the same logic from other places and there was no duplication check, I might have missed something
<cjwatson> kyrofa: I believe
<cjwatson> so
<kyrofa> cjwatson, alright, build is running. That MP is very nearly a clean backport of the MP you already reviewed if you have time to take a look
<cjwatson> kyrofa: which MP?  I thought I just approved one
<bdmurray> tdaitx: well if 'tag' not in report['Tags'] would avoid it
<tdaitx> bdmurray, sure, I know, but does that mean that the other reports also duplicate the tag?
<bdmurray> tdaitx: I don't know. Maybe apport should review the tags for duplicates or something. Its really not a big deal though.
<tdaitx> bdmurray, if the tag is being added twice then all that hs_err logic is also being run twice, I would like to understand why - and yeah, I can cut it at the very first if (no need to run all that again)
<kyrofa> cjwatson, oh you were fast, thank you!
<tdaitx> bdmurray, alright, no duplication on staging, I believe it was the way I ended up running stuff... for some reason the update-notifier-crash service is not detecting my X session, so the service wont activate (not even manually)
<tdaitx> I ended up running apport-cli and then also installed apport-noui
<tdaitx> as I was doing stuff in parallel apport might have run through the report twice or something
<tdaitx> starting update-notifier-crash manually send the report to staging and there was no tag duplication, as expected
<tdaitx> now I need to check why that service believes there is no X session =/
<bdmurray> tdaitx: That seems like a special corner case.
<fossfreedom> Hi all - our package budgie-desktop was sync from debian/experimental today - but it failed to build.  It builds successfully in pbuilder and also in our PPA. Any guidance that you can give me why buildd would produce a different build result?
<nacc> fossfreedom: in https://launchpadlibrarian.net/323780787/buildlog_ubuntu-artful-amd64.budgie-desktop_10.3.1-2_BUILDING.txt.gz search for FAILED
<nacc> Unknown option -lm
<nacc> Run 'valac --help' to see a full list of available command line options.
<nacc> fossfreedom: is that why?
<fossfreedom> yup - but I'm struggling why buildd is failing but the same source builds in an artful PPA and also artful pbuilder
<nacc> fossfreedom: does your PPA have proposed enabled? or your pbuilder?
<jbicha> when did you build it in your artful ppa?
<fossfreedom> no
<nacc> fossfreedom: the builder does
<nacc> fossfreedom: and there is a new valac in artful-proposed :)
<fossfreedom> about 10 minutes ago jbicha
<nacc> fossfreedom: 0.34.7-1 (a) and 0.36.3-1~gi1 (a-p)
<fossfreedom> ahhh
<nacc> fossfreedom: so presumably the new valac has changed flags somehow?
<nacc> fossfreedom: but enablign proposed should make it reproducible
<jbicha> valac is stricter so I expect several packages to FTBFS :(
<fossfreedom> okey dokey - will try that.
<nacc> jbicha: ah, interesting
<jbicha> valac 0.36 is the same vala released with GNOME 3.24 a few months ago
<jbicha> there was also a glib2.0 update this morning
<jbicha> the glib update is still in -proposed
<fossfreedom> ok - thanks.  Yeah - enabling proposed killed the build.
<nacc> fossfreedom: gl! :)
<infinity> fossfreedom: Looks like a meson/ninja (well, somewhere in the build system) bug to me.
<infinity> fossfreedom: That -lm should be passed to the cc call, but not the valac call.
<infinity> fossfreedom: Or maybe it's self-inflicted.  src/lib/meson.build has "meson.get_compiler('c').find_library('m', required: false)," which seems to be to be forcing it to add C-style linking to a vala project.
<fossfreedom> infinity, agreed.  very odd.  Upstream confirms that they are using the same valac compiler version as in proposed.
<jbicha> fossfreedom: you could try disabling -proposed in your PPA and selectively copying packages into the PPA to see which ones fails the build
<jbicha> for instance, upstream is likely not using the latest glib development release
<infinity> Based on the error, it can really only be meson or valac.
<infinity> Either valac stopped ignoring the incorrect option or meson started injecting it into the valac call.
<infinity> Both are new in -proposed.
<jbicha> oh I forgot that meson was stuck in -proposed too
<kyrofa> infinity, that xenial click SRU MP has been approved and bileto is all green. I'm nervous to hit "publish" though given that I'm targeting xenial. Is that the next step?
<kyrofa> (cc cjwatson, although I expect you're asleep)
<slangasek> that is the next step. hopefully the ticket was set up correctly to target xenial, and not xenial overlay?
<kyrofa> slangasek, indeed, xenial: https://bileto.ubuntu.com/#/ticket/2812
<infinity> Oh joy, a bileto SRU.  My favourite.
<kyrofa> infinity, join the club man :P
<kyrofa> Alright I hit publish
<kyrofa> slangasek, I'm getting a "packaging diff requires ACK" even though I checked the ACK box... does someone else need to do that?
<slangasek> kyrofa: you must have upload rights on the package to ack the packaging changes
<kyrofa> Yep, not me then
<kyrofa> Is that not redundant given an approved MP?
<slangasek> no, it is not
<kyrofa> I guess given the fact that multiple MPs could be included makes it possible to get weird results
<slangasek> there is no guarantee that the people approving the MPs on the upstream project have upload rights to Ubuntu either
<kyrofa> Ah of course
<slangasek> in this case if it was approved by cjwatson, then yes - but bileto doesn't try to discover that
<slangasek> publish clicked to publish click
<kyrofa> Haha, thanks slangasek
<kyrofa> What's next regarding the actual SRU process? I've never SRUd with bileto before
<slangasek> next it goes into the unapproved queue for the release, and one of the SRU team members grumbles at having to review a package copy in the queue as it forces them to do a full download
<kyrofa> Okay good deal
<nacc> anyone have a suggestion on a python packaging question? dep8 tests are failing with the new celery, but I think the underlying issue is actually that the tests are no longer packaged in python{,3}-celery, because they moved from (in the upstream src) celery/tests to t/. So the python debhelper doesn't see them as being part of the celery/ directory and doesn't include them. Is it appropriate for me to
<nacc> override the build step for this? Or is it ok to skip installing the tests (they are run at build time and pass)
<slangasek> nacc: we do not normally expect tests to be packaged in order to be used for autopkgtest; they're usually run from the source tree of the package in question
<nacc> slangasek: right, i think the old dep8 test used the as-installed version. So it'd be ok to, in theory, run them from the src tree using the as-installed package
<slangasek> nacc: yes, that would be preferred
<nacc> slangasek: ok, i'll work on tweaking those around, thanks!
<nacc> slangasek: hrm, i think i'm seeing a broken pattern in dep8 python tests using pytest. A lot of packages do (roughly): for p in python-versions; do $p -m pytest tests/; done
<nacc> slangasek: but that (per the upstream and manpage) adds '.' to the PYTHONPATH
<nacc> slangasek: so it ends up, depending on the package layout, testing the source contents, not hte as-installed python lib
<slangasek> score
<nacc> slangasek: if instead, one does pytest or (pytest-3) tests/, the tests use the system python as-installed libs
<nacc> slangasek: but then you can't make it a pretty loop (since the invocation name is different)
<nacc> slangasek: i'm not sure if i'm right, but i definitely see different behavior with celery based upon how in invoke pytest
<kyrofa> bdmurray, the newly patched click is now in the unapproved queue for xenial
<nacc> mdeslaur: rbasak: fyi, upstream apache has unmarked http/2 as experimental in 2.4.26
<nacc> https://httpd.apache.org/docs/2.4/howto/http2.html#comments_section and https://httpd.apache.org/docs/2.4/mod/mod_http2.html
<sarnold> sweet
<nacc> and that version *should* be coming out soon, and i'm happy to update us to it this cycle for security team's comfort
<nacc> sarnold: --^ just fyi
<Unit193> That's also the first version with openssl 1.1 support.
<nacc> Unit193: good to know
<nacc> slangasek: --^ i guess you'd also be interested then :)
<Unit193> (Though of course I'd prefer it not, because that'd hold Ubuntu back from switching this cycle.)
<sarnold> hasn't debian done the work to transition all but three or four packages to openssl 1.1?
<gsilvapt> Has anyone ever experienced issues with descripts' wrap-and-sort? When I run the command it does nothing and there are stuff to be organized
<gsilvapt> And I'm running in the right directory
<Unit193> sarnold: They have libssl1.0-dev.
<nacc> gsilvapt: it's python :) should be easy to debug?
<gsilvapt> nacc, the problem is that I get literally nothing
<gsilvapt> I run wrap-and-sort and nothing. even using the verbose option
<Unit193> nacc: If that's the case, I have another python breakage that I'd love to know what'sgoing on. :>
<nacc> Unit193: :)
<nacc> gsilvapt: which srcpkg (is it in the archive)?
<gsilvapt> what do you mean? What package I'm trying to sort debian/control?
<nacc> gsilvapt: yeah
<Unit193> sarnold: For kicks, http://paste.openstack.org/show/612474
<gsilvapt> I've tried in several but the one I'm currently trying to work on is lskat
<nacc> gsilvapt: well, the b-d in that srcpkg are allready sorted and wrapped
<gsilvapt> I'm locally testing the package
<gsilvapt> I'm taking one line out of order
<sarnold> Unit193: that looks like a depressing story
<nacc> gsilvapt: works fine here (17.04)
<sarnold> Unit193: this looked like a story with a happy ending https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061
<ubottu> Debian bug 827061 in release.debian.org "transition: openssl" [Normal,Open]
<nacc> gsilvapt: i edited one line out of order, ran the script and it put it back
<gsilvapt> It's super odd. I have no clue what could be causing this
<gsilvapt> and I definitely don't want to re-format this machine again
<nacc> gsilvapt: are you on 17.04?
<gsilvapt> 16.04
<nacc> gsilvapt: like i said, it's a pretty straightforward script, add some debugging and see?
<nacc> gsilvapt: ok, let me spin up a container
<Unit193> sarnold: Depends really, curl was built against 1.0 due to its library, but does support 1.1.  Some things do have support, if not just a simple rebuild then new upstream.  Ruby 2.4.0
<Unit193> Erm...Ruby is one of them, but Debian is skipping 2.4.
<gsilvapt> how do I do that, nacc ?
<nacc> gsilvapt: well i was assuming you knew python :) you can add print()s throughout, though
<gsilvapt> I assume you're suggesting adding that to the script's source?
<nacc> gsilvapt: yes
<gsilvapt> I can give that a try . I need to find where it is located though
<Unit193> (And like alpine, just have to wait for my sponsor to come back, and I can push the new version that supports 1.0 and 1.1.  Sadly, gvpe isn't there yet, so I'm really hoping Ubuntu stick with 1.0)
<nacc> gsilvapt: `which wrap-and-sort`
<sarnold> anonymous cvs, oy :)
<Unit193> I did https://bitbucket.org/unit193/gvpe, but I haven't kept up with it.  You might remember it from me asking you about openssl incompatibilities a few releases back.  There was a protocol issue that wouldn't allow it to communicate, never found out why.
<slangasek> sarnold: don't worry, it's anonymous cvs with pgp-signed commits
<mdeslaur> nacc: awesome! (re: apache2)
<nacc> mdeslaur: i updated the bug as well
<gsilvapt> nacc, the script stops at the get_files function. It's not working but it gives no error
<sarnold> is this the kind of error were watching what it does via strace is useful?
<nacc> gsilvapt: ok, still setting up a repro env
<gsilvapt> ok, I can wait. Thank you and sorry for the trouble
<nacc> gsilvapt: nothing to apologize for :)
<nacc> gsilvapt: works fine in a 16.04 lxd
<Unit193> nacc: Ask him for the source package?
<nacc> gsilvapt: http://paste.ubuntu.com/24852460/
<nacc> Unit193: i was testing the srcpkg gsilvapt mentioned (lskat)
<Unit193> Oooh,dang.  Missed that part.
<nacc> Unit193: np
<nacc> gsilvapt: when you say it 'stops' at the get_files function ... what did you mean?
<gsilvapt> nacc, I basically add print() in all variables and it stops running after the get_files function because it is not searching for files properly
<gsilvapt> It sets an empty list as files
<gsilvapt> If files are empty, then there's nothing else to run...
<nacc> gsilvapt: yes, files is empty to start, the function attempts to find entries from SUPPORTED_FILES that match in the shell
<nacc> gsilvapt: where are you running the command?
<gsilvapt> source package parent directory
<nacc> gsilvapt: oh
<Unit193> sarnold: Inconsequential PM?
<nacc> gsilvapt: you need to run it from the srcpkg directory itself
<gsilvapt> I'm running inside lskat/
<sarnold> Unit193: any time :)
<gsilvapt> inside lskat, there's the debian/ folder
<nacc> gsilvapt: oh ok, i misunderstood what you meant by 'parent directory' then
<gsilvapt> It returns errors when running inside debian/ or outside lskat
<nacc> gsilvapt: can you run the command (or alterations) as i showed in my paste? or use a paste and show me your alterations and the failure?
<gsilvapt> Sure, I can copy/paste the script in a bin and show you the output. Potentially I'm doing the print() thing wrong but it seems unlikely
<gsilvapt> nacc, do you prefer just a diff between my changes and the original file or do you wanna see the full script?
<nacc> gsilvapt: well in theory we have the same script (wrap-and-sort) -- i meant can you do exactly the alteration i did in my paste (just moves one line) and then show wrap-and-sort failing to fix it?
<gsilvapt> I didn't add many prints
<nacc> gsilvapt: a diff is fine too -- my point is, i'm not seeing hte problem (in 16.04 or 17.04)
<gsilvapt> I have a different debian/control file here but sure. Fixes were proposed but not yet merge. It doesn't matter because it doesn't work anyway.
<gsilvapt> 1 second then.
<gsilvapt> nacc, this is the debian/control file: https://paste.ubuntu.com/24852525/ Notice line 17 and 18 should swap. when I run wrap-and-sort -v, this is what I get (using the prints inside the script, otherwise it would return literally nothing): https://paste.ubuntu.com/24852530/
<nacc> gsilvapt: http://paste.ubuntu.com/24852550/
<nacc> gsilvapt: works fine in my 16.04 lxd
<gsilvapt> Well, I can't figure out what is causing the issue
<nacc> gsilvapt: try spinning up a lxd and reproducing it in a clean env
<gsilvapt> According to the print thing, it can't find any files but they exist
<nacc> gsilvapt: can you paste your change to the scrpit?
<nacc> *script
<gsilvapt> sure
<gsilvapt> I don't think a diff is very understandable here. Can I just send a paste of the source?
<nacc> gsilvapt: that's fine too
<gsilvapt> diff or source?
<gsilvapt> lol :)(
<nacc> gsilvapt: a diff is always understandable :)
<sarnold> diff -u is usually more understandible
<sarnold> understandable too
<gsilvapt> Sorry if I always get confused with regular diffs :P
<gsilvapt> https://paste.ubuntu.com/24852571/
<nacc> sarnold: true :) -- i mentally assume everyone is doing -urpN due to kernel work
<nacc> gsilvapt: yeah, do `diff -urpN old new | pastebinit` instead
<nacc> *please
<gsilvapt> Ahhh, this now looks cute
<gsilvapt> lol
<gsilvapt> I'm so noob, oh god...
<gsilvapt> https://paste.ubuntu.com/24852585/
<nacc> gsilvapt: it's reversed, but that's ok
<gsilvapt> I noticed, I should've switched the order but I guessed you'd understand
<nacc> gsilvapt: http://paste.ubuntu.com/24852599/ can you apply this and re-run the command?
<gsilvapt> nacc, https://paste.ubuntu.com/24852616/
<nacc> gsilvapt: hrm, are your files for some reason executable?
<gsilvapt> The option is ticked, yes
<nacc> gsilvapt: hrm? i mean the files in your scrpkg
<nacc> gsilvapt: e.g., d/control itself
<gsilvapt> The option to run d/control as executable is ticked, yes
<gsilvapt> Allow executing file as program
<infinity> nacc: Hint, "pastebinit -f diff" even gives it pretty colours.
<nacc> infinity: oh nice!
<nacc> infinity: thanks :)
<nacc> gsilvapt: um, it shouldn't be
<nacc> gsilvapt: you made that change?
<nacc> gsilvapt: in the current ubuntu source package, the only executable in debian/ is 'rules'
<gsilvapt> Not really
<nacc> gsilvapt: `wrap-and-sort` will not wrap or sort any executable file
<nacc> gsilvapt: i'm still not sure what you mean by ticked? cna you pastebin `ls -ahl debian/` ?
<gsilvapt> Okay, makes sense. What did I do to have this setting all files as executables?
<nacc> gsilvapt: i have no idea :)
<gsilvapt> https://paste.ubuntu.com/24852653/
<nacc> gsilvapt: yeah that's ... wrong :)
<gsilvapt> This has to be a configuration issue then because I experienced the same issue in all srcpckgs
<gsilvapt> Did I mess up permissions and such?
<nacc> gsilvapt: run `pull-lp-source lskat` in /tmp, say
<nacc> gsilvapt: does it have the same permissions?
<nacc> gsilvapt: do you have an odd umask set?
<gsilvapt> AFAIK, no
<nacc> gsilvapt: you can check with `umask`
<gsilvapt> What value should I get?
<nacc> default is 0022
<gsilvapt> I have 0002
<nacc> gsilvapt: did `pull-lp-source` produce hte same permissions?
<gsilvapt> I don't have the same permissions when using pull-lp-source
<gsilvapt> The other source was pulled from git
<nacc> gsilvapt: for comparison: http://paste.ubuntu.com/24852666/
<nacc> gsilvapt: hrm, maybe a git config ? pulled from where?
<gsilvapt> Yep, that's what I have
<gsilvapt> Here: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/lskat/
<nacc> gsilvapt: and more directly to your paste earlier: http://paste.ubuntu.com/24852672/
<nacc> gsilvapt: with just a git clone?
<infinity> Permissions look fine in git.
<gsilvapt> yes
<gsilvapt> I have nothing overriding permissions in my gitconfig
<nacc> gsilvapt: a fresh git-clone also shows them executable?
<gsilvapt> https://paste.ubuntu.com/24852686/
<gsilvapt> Oh, wait. I sent the wrong url
<gsilvapt> Barr, too many tabs. Nevermind. Testing a new clone in a new folder. Potentially the issue is in the target directory I have been using
<gsilvapt> Yeap, that has to be it
<nacc> gsilvapt: ok :)
<gsilvapt> So I tried cloning in my home directory, permissions worked fine. I have a folder in an external drive in which I have everything related to projects. It's the only way I can have multiple packages and not run out of space (small 128 gbs SSD + 1 TB HDD)
<gsilvapt> How can I set up this folder in my HDD so that it doesn't mess up permissions?
<infinity> gsilvapt: Is said external drive formatted with a sketchy filesystem, like vfat?
<nacc> gsilvapt: what infinity said would be my next suspicion.
<infinity> I suspect either it's a filesystem that doesn't support permissions at all (like fat/exfat/vfat), or a "foreign" filesystem that supports POSIX permissions via a bit of translation trickery but mount often decides the "defaults" should be something weird (NTFS and HFS+).
<infinity> In the latter case, you can mount it differently and fix some of your woes, but honestly, you shouldn't do package build type work on a non-UNIX-friendly filesystem.  Too many build systems make too many assumptions.
<infinity> gsilvapt: If 'stat -c%T -f /path/to/build/area' is anything other than 'ext2/ext3', 'xfs', or 'btrfs', your success rate is likely to vary.
<infinity> (Yes, there are a ton more fully POSIX-compliant filesystems the kernel supports, but those are the only three that get enough use that I'm comfortable recommending them)
<infinity> Oh, and I guess zfs now.
 * sarnold puts down the zfs-advocacy megaphone
<infinity> sarnold: I refuse to believe anything good has come from SunOS/Solaris since sendfile()
<slangasek> haha
<sarnold> infinity: but you should see all the blinking lights during a scrub!
#ubuntu-devel 2017-06-14
<cjwatson> infinity: acceptx() was pretty cute
<cjwatson> infinity: Oh, and sendfilev() was awesome for benchmarks.
<cjwatson> (or, charitably, for static file serving)
<mwhudson> oh hooray python3-defaults-3.5.3 source has a .bzr directory in it
<mwhudson> wait i uploaded that
<Unit193> mwhudson: G'luck on DM!
<mwhudson> ah the newest version i didn't upload also has it
<mwhudson> (i was sure i didn't do anything bzr related in my uploads...)
<mwhudson> slangasek: quick review on http://paste.ubuntu.com/24852968/ ?
<slangasek> mwhudson: if it builds, then sure? :)
<mwhudson> hah
<slangasek> mwhudson: the reference to python3.6-minimal makes me sad
<mwhudson> i should do some testing before i rebuild 3000 packages against it i guess
<mwhudson> slangasek: yeah i don't understand what that's doing there
<slangasek> mwhudson: the -minimal split as a whole never achieved its intended purpose and is now just an inconvenience in the archive... references to it from other packages are particularly heinous
<mwhudson> slangasek: i see
<cjwatson> references to it from python3-defaults seem a bit less heinous than from elsewhere, seeing as it has a python3-minimal itself
<cjwatson> though I don't know what it's doing in Build-Depends
<cjwatson> some kind of bootstrapping hack given the :any ?
<mwhudson> slangasek: have lunch appt in 8 minutes going to see how much pycxx i can understand in that time :)
<slangasek> yeah, possibly
<cjwatson> that would be a "don't remove -minimal without doing careful cross-build tests" flag for me
<slangasek> right, if anything I would promote it to python3.6:any instead
<cjwatson> yeah but I wonder if that complicates bootstrapping due to non-cross-installable dependencies or something
<slangasek> could be
<slangasek> anyway, I'm certainly not advocating that it must be changed as part of the transition
<slangasek> mwhudson: pycxx, this autopkgtest is hateful and clearly could never have worked anywhere; shameful
<slangasek> s/shameful/SAD/
<slangasek> mwhudson: one-line change to add cxx_exceptions.cxx to setup_makefile.py, alongside cxx_extensions.py; must rebuild and install since the autopkgtest (properly) tests the installed package; and now I'm afk, feel free to turn this comment into a patch or something
<sarnold> diff --hand-waving-on-irc  :)
<mwhudson> slangasek: ok
<mwhudson> good thing i had lunch instead of coming to the same conclusions
<sarnold> you really can't go wrong with lunch
<mwhudson> tis true
<gsilvapt> Apologies for the long delay, nacc and infinity. I'll be testing this soon (need some more reboots)
<gsilvapt> infinity and nacc: Regarding the command you suggested, it says fuseblk.
<gsilvapt> Meaning I'm toasted for this...
<sarnold> gsilvapt: what the heck kind of filesystem -is- that?
<Unit193> fuse?
<sarnold> yeah not many fuse backends seem like they'd be up to package builds
<tarpman> sarnold: guessing it's ntfs via ntfs-3g
<sarnold> *shudder*
<Unit193> fat32 better?
<sarnold> *shudder*
<blahdeblah> Is this sarnold trigger word bingo?  Let me try.
<blahdeblah> NFS
<sarnold> number field sieve? sounds like fun!
<blahdeblah> drat - foiled again!
<blahdeblah> Some launchpad server upgrades under way; expect some minor delays on builds and diffs
<ginggs> jamespage: ceph build failure with --no-parallel https://launchpadlibrarian.net/323860925/buildlog_ubuntu-artful-armhf.ceph_12.0.3-0ubuntu1~ubuntu17.10.1+ppa12_BUILDING.txt.gz
<jamespage> ginggs: yep that's the one
<jamespage> any ideas on cause?
<ginggs> jamespage: no, sorry
<cpaelzer> doko: Hi,does python3-ldb-dev ring a bell on bug 1614936 ?
<ubottu> bug 1614936 in ldb (Ubuntu) "package python3-ldb-dev (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/x86_64-linux-gnu/pkgconfig/pyldb-util.pc', which is also in package python-ldb-dev 2:1.1.24-1ubuntu3" [Low,Confirmed] https://launchpad.net/bugs/1614936
<cpaelzer> doko: I hoped you might be able to help clarifying the right approach, so I subscribed
<cpaelzer> you
<jamespage> ginggs: figured out the other i386 issue (ish)
<jamespage> https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1697908
<ubottu> Launchpad bug 1697908 in gcc-6 (Ubuntu) "i386 compilation hang with rocksdb (via ceph)" [Undecided,New]
<jamespage> have a patch series to try with
<rbasak> nacc: \o/
<jamespage> how do I persuade proposed migration to look at autopkgtest results for reverse-depend packages in proposed as well?
<jamespage> I have a stack of autopkgtest fixes in proposed, but py modules are testing against the release pocket
<rbalint> jamespage: i have a script for generating links for autopkgtests with additional dependencies
<rbalint> jamespage: let me push it somewhere
<jamespage> rbalint: great - thanks!
<Laney> umm
<Laney> If a package breaks another one, that sounds like Breaks to me
<rbalint> jamespage: https://git.launchpad.net/~rbalint/+git/autopkgtest-retry
<rbalint> jamespage: it needs editing and parsing the yaml in python is slow
<rbalint> Laney: in theory, yes, but in practice adding Breaks for every other package which happens to be broken is unmanagable
<Laney> If you add extra triggers into autopkgtest runs, you risk causing a package to migrate without the thing you added a trigger on, which would end up breaking real users.
<rbalint> Laney: what is then the proposed way of getting two (n) packages migrated which pass autopkgtest together only?
<Laney> rbalint: As you would with a normal package upgrade - you add the right relationships to ensure that users can only have working combinations of packages installed
<Laney> If you're seeing failures that are fixed by adding extra triggers then autopkgtest is pointing you to a bug
<rbalint> Laney: will the Breaks trigger autopkgtest with the right version from proposed?
<Laney> The triggers translate into pins
<Laney> So yes
<Laney> It's an option to use the workaround that you're suggesting if you decide that it's not a realistic bug, but I think it should be considered after thinking about fixing the packages.
<rbalint> Laney: i assumed that if i add an extra trigger the original package will migrate only together with the triggering version
<rbalint> Laney: at least this would make more sense to me than asking for temporary deltas with Breaks
<Laney> why is it temporary?
<Laney> And no, because you're filing those requests outside of britney.
<rbalint> Laney: not all Breaks are recorded between packages and keeping the ones which surfaced only for the short period of -proposed migration may not be really useful
<Laney> rbalint: The fact that a combination of packages doesn't work together doesn't change just because the situation is in release instead of proposed.
<rbalint> Laney: i agree
<rbalint> rbalint: if you pick all versions of all packages ever been in zesty (release) during the development for zesty and test every combination of them with autopkgtest which are co-installable considering Breaks Conflicts etc rules would those tests pass?
<rbalint> Laney: ^
<Laney> I'm not getting into a discussion about an absurd situation
<Laney> You understand what I'm saying, and I have to go work on codec installation now, so see you later
<jamespage> rbalint: ta
<psusi> so what the heck does dpkg mean when it says a package is in a very bad inconsistent state?  been seeing a lot of bug reports lately about upgrades throwing this error on grub.
<bdmurray> xnox: I added some info to that systemd bug 1621396
<ubottu> bug 1621396 in systemd (Ubuntu Yakkety) "systemd-resolved crashed with SIGSEGV in dns_packet_is_reply_for()" [Low,Confirmed] https://launchpad.net/bugs/1621396
<xnox> bdmurray, and the russian text says that systemd-resolved was modified since the error occured.
<xnox> thus crash; upgrade; then report.
<xnox> bdmurray, thanks a lot. because i raised an eyebrow at that crash report
<bdmurray> xnox: No problem.
<bdmurray> xnox: Its possible apport should do something better / different here.
<bdmurray> xnox: I reported bug 1697959 about the report containing "fake" information.
<ubottu> bug 1697959 in apport (Ubuntu) "late package version collection can cause confusion" [Undecided,New] https://launchpad.net/bugs/1697959
<pitti> bdmurray: back then, ev was pretty adamant about "I want all sorts of broken bug reports on errors.u.c.", apport has specific code to ingore UnreportableReason: for errors.u.c.
<pitti> perhaps it's time to reconsider :)
<bdmurray> pitti: I recall those discussions from when we were in London.
<kyrofa> Hey rbasak, can we get snapcraft into proposed for x y and z?
<kyrofa> bdmurray, click is now in proposed. Can you help me get snapcraft there as well?
<bdmurray> kyrofa: Could you check with arges or rbasak first since its their SRU day?
<kyrofa> arges isn't here, I pinged rbasak over 30 minutes ago
<bdmurray> kyrofa: okay, I'll have a look in about an hour
<kyrofa> bdmurray, I appreciate it, thank you
<slangasek> smb: why is your network device so broken? :)
<smb> slangasek, It would be both for me KVM and Xen. But I am just updating to the latest ISO. Maybe it is just that which was broken. :)
<slangasek> ok
<slangasek> though, you were already on the latest version of systemd
<smb> Yeah, just want to be sure it really still happens. If not, then meh
<slangasek> smb: do you have radvd running somewhere such that you *should* be getting public IPv6?
<smb> slangasek, no radvd (no ipv6 for my home network). One thing I want to change at some point but never get to
<rbasak> kyrofa: sorry, I'm nominally EOD at 1800 UTC+1, and it would have been too big a chunk of review to do last thing for me anyway. I've been deep inside the certbot SRU today.
<rbasak> bdmurray: thank you for looking
 * rbasak wonders why snapcraft isn't a classic snap
<kyrofa> rbasak, it is
<kyrofa> But it's not stable yet, still in beta
<rbasak> So why the need for SRUs?
<rbasak> I see.
<kyrofa> And there's no real established pattern for transitioning deb users to snaps
<kyrofa> Don't want to leave them in a lurch
<rbasak> I did wonder about that. snapcraft sounds like the perfect candidate to lead the way on that :)
<nacc> heh
<nacc> show us the way, kyrofa! :)
<kyrofa> Ha! Well, once it's actually stable and well-tested, I'm sure we'll chat about it
<cjwatson> And LP builders don't yet support installing snaps, so would have problems installing snapcraft
<smb> slangasek, Bah, so fwiw I am still broken ... or rather my installation(s)
<cjwatson> It'd also make our development setups depend on snapd in lxd, which would perhaps be excessively exciting
<slangasek> smb: right, so maybe this needs some poking around in the kernel state of the device to understand why networkd isn't considering it 'configured'
<smb> slangasek, possibly. would be nice if it was not just me though. even more so as I am not around the rest of the week
<slangasek> smb: what does 'ip link' look like on this box?
<smb> slangasek, http://paste.ubuntu.com/24857940/ (after timing out and then working normally except for the failed service)
<kyrofa> cjwatson, excellent points indeed
<slangasek> smb: ok, nothing looks abnormal there to me
<kyrofa> And the simple fact that snaps don't run everywhere that debs do. You wouldn't be able to use snapcraft on travis anymore either
<tsimonq2> Hmmmm... can I use syncpackage with PPAs?
<slangasek> yes
<slangasek> if you're syncing /from/ a ppa /to/ the main archive, you must not do a binary sync
<tsimonq2> I'm looking to sync from Debian to a PPA
<slangasek> (I don't recall of LP itself has a way of enforcing this as a security policy)
<slangasek> yeah, that's doable
 * tsimonq2 isn't seeing it in the manpage...
<slangasek> oh. you probably can't use the syncpackage command, sorry - you can do it with copy-package from ubuntu-archive-tools
<tsimonq2> Ah ok
<tsimonq2> slangasek: I can't figure out how to use this with Debian... hint?
<infinity> tsimonq2: copy-package --from=debian --from-suite=sid --to=ppa:adconrad/ubuntu/ppa --to-suite=artful hello
<infinity> tsimonq2: Adjust to taste.
<tsimonq2> infinity: gracias.
* ChanServ changed the topic of #ubuntu-devel to: Canonical datacentre firewall maintenance 23:59 - 00:00 UTC | Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
* ChanServ changed the topic of #ubuntu-devel to: Canonical datacentre firewall maintenance 23:00 - 23:59 UTC | Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
#ubuntu-devel 2017-06-15
* ChanServ changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<blahdeblah> launchpad codebrowse server is going down for an upgrade shortly
<blahdeblah> launchpad codebrowse server upgrade is complete
<gema> can someone point me to the scripts that build the netboot image for ubuntu?
<jamespage> rbalint: I made a few tweaks to make things a bit for flexible and automatically detect new proposed versions to check things against
<jamespage> https://git.launchpad.net/~james-page/+git/autokgtest-retry/commit/?id=15ffcee37b8039eef377e3488c57d348035f0efb
<jbicha> pitti: could you look into python-dbusmock's autopkgtest failures with NM 1.8 in artful?
<popey> Apologies for the nonsense on devel-discuss. I've set the person to moderation, and not let any more nonsense through.
<popey> feel free to ping me if I miss anything
<tsimonq2> Does anyone know if copy-package can be used on a package in incoming.debian.org?
<stgraber> I don't believe it can. copy-package only talks to the LP API and the built-in LP Debian mirror doesn't include incoming as that's not an actual Debian archive
<tsimonq2> Ah, ok. So I guess I'll have to wait. :/
<tsimonq2> Thanks stgraber
<cjwatson> stgraber: Well, it actually is nowadays, and we'd like to mirror it, we just need to work out what the importer would do in the event that something was unaccepted and maybe republished
<tsimonq2> Harumph, why would this command ask for syslinux-themes-ubuntu-artful? :/
<tsimonq2> $ sudo -E ubuntu-defaults-image --package lubuntu-desktop --arch amd64 --release artful --flavor lubuntu --components main,restricted,universe
#ubuntu-devel 2017-06-16
<blahdeblah> lists.launchpad.net going down shortly for an upgrade
<Unit193> blahdeblah: So should we ask if the updates are anything interesting.
<blahdeblah> Unit193: I'm afraid it's rather dull; just getting the host infrastructure up to xenial
<Unit193> That's interesting enough, nice to get to the current LTS. :)
<Unit193> platform.artful/standard: foundations-aa-migrating-to-neplan â foundations-aa-migrating-to-netplan
<dupondje> https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1692870 => any chance this can get accepted once? Cause I think it breaks more things than listed even
<ubottu> Launchpad bug 1692870 in zlib (Ubuntu) "gzip compression broken in UniFi (built-in tomcat)" [Undecided,Confirmed]
<infinity> dupondje: Could use a slightly more pleasant test case. :/
<infinity> dupondje: But if UniFi is the only way you know to reproduce it, better reproduction steps would be lovely.
<infinity> (install this thing from that place, go to local URL X, check logfile Y)
<infinity> dupondje: You also don't explain why, in your debdiff, you dropped a seemingly unrelated patch.
<fossfreedom> hi all.  Is there anyway to rollback/remove the broken meson package in artful proposed to allow budgie-desktop to build please?
<jbicha> fossfreedom: has that issue been reported to meson yet?
<dupondje> infinity: i'll check to adapt the reproduction steps. Its installing the unifi package, and then go to the guest portal page. But could be a bit more descriptive indeed.
<dupondje> the patch is just an upstream patch: https://github.com/madler/zlib/commit/f9694097dd69354b03cb8af959094c7f260db0a1
<fossfreedom> yep - its a known issue - https://github.com/mesonbuild/meson/issues/1939 - I reported upstream to budgie-desktop and its their recommendation to rollback.  Other distro's similarly are having difficulty building vala based meson stuff as well.
<dupondje> i'll test tomorrow if I can reproduce it with plain tomcat. Would be easier to test :)
<jbicha> fossfreedom: honestly, we're not likely to just rollback, but I see the issue you linked has a proposed commit attached
<jbicha> fossfreedom: could you try rebuilding budgie with a meson built with that commit?
<fossfreedom> sure
<jbicha> roll forward instead of roll back :)
<nacc> jbicha: fyi, your fix for deja-dup also fixes a bug (LP: #1668915)
<ubottu> Launchpad bug 1668915 in deja-dup (openSUSE) "Deja-dup 34.3 fails to build with vala 0.35.6" [Medium,Confirmed] https://launchpad.net/bugs/1668915
<infinity> dupondje: You also dropped a patch from series.
<fossfreedom> jbicha: tried to with those patches.  Got further but failed.  There are a series of regressions marked on that version upstream - not all have fixes - certainly not merged.  That version of meson is well and truly broken
<jbicha> fossfreedom: please open an Ubuntu bug against meson and add the tag "block-proposed"
<jbicha> I apologize for the inconvenience but I don't think we're likely to just remove the package from proposed at this point in Ubuntu's dev cycle
<jbicha> by the way, Debian unstable has the same version of meson (the Debian maintainer is the upstream maintainer)
<fossfreedom> aye. no worries. raised the bug report anyway - https://github.com/mesonbuild/meson/issues/1939
<fossfreedom> wrong copy paste
<fossfreedom> https://bugs.launchpad.net/ubuntu/+source/meson/+bug/1698463
<ubottu> Launchpad bug 1698463 in meson (Ubuntu) "v0.41.0 meson has numerous regressions that stop vala based apps compiling" [Undecided,New]
<jbicha> thanks
#ubuntu-devel 2017-06-17
<dupondje> https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1692870 => updated testcase (its really easy). And tried to simulate with Tomcat, but not seems to happen there
<ubottu> Launchpad bug 1692870 in zlib (Ubuntu) "gzip compression broken in UniFi (built-in tomcat)" [Undecided,Confirmed]
#ubuntu-devel 2017-06-18
<gsilvapt> Is anyone around who could help me solving an issue in sbuild? I'm getting this error in all builds: https://paste.ubuntu.com/24885745/
<gsilvapt> I'm almost 100% sure this is related to sbuild's setup & configuration but can't figure out what
<cjwatson> gsilvapt: building for series where gpg2 is the default inside the chroot requires bug-fixes that postdate sbuild 0.67.0 - I think you need 0.71.0
<gsilvapt> cjwatson, thank you for replying. I found the answer here: https://groups.google.com/forum/#!msg/linux.debian.bugs.rc/3LHnM78aLZQ/5EkBoexwBQAJ
<cjwatson> hopefully it's not too painful to backport but I haven't tried
<gsilvapt> May have messed up something while setting up the gpg keys
<cjwatson> ah possibly that too
<cjwatson> but err I think that message only applies to newer sbuild versions
<gsilvapt> No clue. I deleted those and the builds started worked normally. At least they wouldn't stop there
<cjwatson> maybe not, that was against 0.65.2
<cjwatson> OK, sounds like you're fine then
<jbicha> doko: why do artful builders have both gcc-6 and gcc-7 installed?
#ubuntu-devel 2018-06-11
<sunweaver> Hi all!
<sunweaver> I wonder how the Ubuntu build daemons handle alternative build dependencies.
<cjwatson> sunweaver: Equivalent to sbuild --resolve-alternatives
<sunweaver> cjwatson: thanks
<caribou> Hello, any member of the SRU team around today ?
<caribou> There is a dependency issue b/w  kdump-tools (in -updates) and kexec-tools (-proposed) which makes the installation of the linux-crashdump meta-package to fail
<caribou> (xenial)
<rbasak> caribou: does the kexec-tools in proposed need updating with a Breaks?
<rbasak> Oh, I see more discussion in #ubuntu-release
<caribou> rbasak: no, it's been handled by sil2100 in #ubuntu-release
<sil2100> The binary-dependencies seem to be in place since otherwise the package would install correctly, it's just that the new dependency is not intentional and has been missed
<sil2100> We need to get the kexec-tools package tested and released I guess
<sil2100> But maybe there's some better way?
<coreycb> hello sru team, please could we get a review of the uploads for heat bug 1761629?
<ubottu> bug 1761629 in OpenStack Heat "[SRU] unicode error when using old unicode non uuid style user id" [Medium,In progress] https://launchpad.net/bugs/1761629
<rbasak> coreycb: looks like that's still blocked by the previous heat SRU.
<awe_> AlexKaluzhny, I'll be joining the call a few minutes late today
<ddstreet> sil2100 rbalint lp #1774120 is your preference to remove the changes to the ebtables.init script, and restrict the fix/workaround to only the ebtables.prerm script, and in that to 1) ignore the invoke-rc.d for ebtables.init, and also 2) ignore 'upgrade-failed' for ebtables versions less than the current version for each release (i.e. hardcode version check in prerm)?
<ubottu> Launchpad bug 1774120 in ebtables (Ubuntu Bionic) "ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to 2.0.10.4-3.5ubuntu2.18.04.1 on WSL" [Low,In progress] https://launchpad.net/bugs/1774120
<ddstreet> if so, do you know if there is a way to override the #ERROR_HANDLER# that debhelper injects, or should i just remove the #DEBHELPER# and insert the equivalent check (but ignoring errors)
#ubuntu-devel 2018-06-12
<kees> systemd-shim really need to be purged before xenial -> bionic upgrades ....
<sil2100> Hey, does anyone else see "/sys/firmware/dmi/tables/smbios_entry_point: Permission denied" errors in their autopkgtest logs for cosmic?
<sforshee> LocutusOfBorg: I assume you're aware that there's a vboxguest driver in the upstream kernel now. We've still been shipping that and the vboxsf modules from the virtualbox-guest-dkms package in ubuntu kernels, and I wanted to get your opinion on whether we should continue doing so
<sforshee> one hiccup, if we use the kernel's vboxguest driver we cannot ship vboxsf as it has dependencies on the vboxguest dkms module
<ddstreet> sil2100 re: lp #1774120, if the last cosmic debdiff i attached looks like what you're asking for, can you upload that to cosmic and reject the previous SRU uploads?  I'll re-upload fixed SRUs.  Or, let me know if the cosmic debdiff isn't what you were looking for
<ubottu> Launchpad bug 1774120 in ebtables (Ubuntu Bionic) "ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to 2.0.10.4-3.5ubuntu2.18.04.1 on WSL" [Low,In progress] https://launchpad.net/bugs/1774120
<LocutusOfBorg> sforshee, I know... not sure if we should continue or not too :)
<LocutusOfBorg> my version should be "better" because I can tweak stuff and permissions
<LocutusOfBorg> the basic kernel one works BTW
<sforshee> LocutusOfBorg: if the in-kernel driver is currently more limited we can disable it and continue using the one from your package for now
<sforshee> I assume we'd at least be missing the shared folders functionality
<LocutusOfBorg> sforshee, better ship it because of vboxvideo
<LocutusOfBorg> so we don't have to use seeds of vbox-guest in iso
<sforshee> LocutusOfBorg: I don't follow, we've been using the in-kernel vboxvideo module already and afaict it has no dependencies on the vboxguest module
<LocutusOfBorg> vboxvideo is provided by "kernel" and "vbox-guest"
<LocutusOfBorg> the kernel version is useful in daily-live images, avoiding to install vbox-guest package
<LocutusOfBorg> vbox-guest provides more tools and an updated (usually) kernel module
<LocutusOfBorg> so the latter "enhances" the kernel one
<sforshee> LocutusOfBorg: ok, but I don't see how that impacts which version of vboxguest.ko we choose to ship in the ubuntu kernel packages
<sforshee> but it sounds like we're better off using the vboxguest.ko from your package for now, so I'll go that direction
<sforshee> we can always reevaluate later
<Nafallo> hi! who handles http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html ? it seem a bit stalled.
<LocutusOfBorg> sforshee, do you want to stop providing it completely?
<sil2100> Does anyone know if there's some way of marking an autopkgtest as 'skipped' from inside the test? Let's say, I have an ADT test that in some certain special condition I want to mark itself as skipped?
<sforshee> LocutusOfBorg: my preference would be to use the in-kernel drivers as long as they are providing the equivalent features
<ginggs> sil2100: if blah blah exit 0 in debian/tests/name-of-script ?
<jpleau> Trevinho: (I hope you're the right person :P) About the bug you filed for the GDM login/logout issue, do I have to do anything ? You mentionned I had to file a bug but it appears you did so already!
<Trevinho> jpleau: Hey! yeah, exactly :)
<jpleau> Okay, just wanted to be sure. I'm aware of the flow for Debian stable updates but less so for Ubuntu. Thanks
<phibs> Is this a place to ask a generic package building question?
<sarnold> hey phibs :)
<phibs> uyo
<phibs> yo&*
<phibs> ok I give up haha
<teward> #ubuntu-packaging might be a better place to ask generic package building things, no idea if it's still a 'living' channel though
<phibs> yeah
<phibs> Basically https://packages.ubuntu.com/cosmic/lshw has patches that reference one dir too specific, instead of a/src/blah its a/lshw-B.02.18/src/blah and does not build :(
<teward> um
<teward> phibs: that's by design with the way the package is laid out
<teward> patches are relative to the root of the source package tree
<phibs> the patch diff doesn't even create the debian dir in the same package dir....
<phibs> it's AFU, try it :)
<teward> well
<teward> i just dget'd the package
<teward> and all the patches just applied
<phibs> hmm
<teward> with quilt push -a
<teward> https://paste.ubuntu.com/p/mVWymNkQZ2/ is the 'root' of the source pkg
<teward> so the first 'folder' within the source package dir is lshw-B.02.18/
<phibs> oh I see
<phibs> thanks!
<phibs> stupid me haha
<teward> it's just this package and the way it's laid out
<phibs> nod
<phibs> yeah hadn't run into a package laid out like that before
<teward> (disregard the /tmp/lshwstuff/... parts
<phibs> any way to have it fetch/unpack things from say: https://packages.ubuntu.com/cosmic/lshw ?
<phibs> or is there a tool that does that
<sarnold> apt-get source if you have deb-src lines set up
<sarnold> pull-lp-source may do the job too
<teward> dget -u on the .dsc file linked on that page works as well, but that preassumes you have dget as well
<phibs> my host is xenial, i'm backporting the cosmic one
<phibs> dget -u is perfect, thanks
<sarnold> there's some kind of automated backporting command ..
<sarnold> it can also feed right into a ppa so you don't even need tobuild locally
<teward> part of the dev tools, yeah i'm familar with it
<sarnold> but lunchtime :)
<sarnold> see ya phibs, teward :)
<phibs> thanks to you both
<teward> backportpackage is what sarnold's thinking of
<teward> i forget the package that installs it though, maybe `ubuntu-dev-tools`
<teward> (I'm on a Xenial system too heh)
<phibs> yeo
<phibs>  ubuntu-dev-tools has it
<phibs> teward: thank you for your help sir, solved my issue!
<teward> glad to have helped :)
<phibs> so yeah the problem was I was unpacking/diffing myself, which worked fine with normal layouts but this one was a tad abnormal so dget -u from now on it is.
#ubuntu-devel 2018-06-13
<rbalint> vmbuilder did not see an update for some time, is there a successor or it just needs some love to support bionic + cosmic?
<tsimonq2> (multipass?)
<tsimonq2> In this case I'll assume that this is OK, but for the future, a native package with e.g. 1.4.4 when SRUed becomes 1.4.4.1 right?
<cpaelzer> xnox: hi is the systemd autopkgtest still retry-to-win?
<cpaelzer> recent logs look that way, but to be sure I wanted to ask in case there are special bells and whistles to that atm
<cjwatson> tsimonq2: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging has some recommendations for native packages.  1.4.4.1 would only be OK if it's an Ubuntu native package that's not in Debian.
<tsimonq2> cjwatson: Thanks.
<xnox> cpaelzer, i think it got worse recently, did not yet debug on how to make it better =/
<cpaelzer> ok
<cpaelzer> I have seen the fsck hit in the past
<cpaelzer> there seem to be a new one around "unhappy-2.input"
<cpaelzer> good name btw
<cpaelzer> breaks on "Failed to parse UID: '9999999999': Numerical result out of range"
<cpaelzer> maybe now both issues are flaky and together cause a higher fail rate
<cpaelzer> I could get it working with "just" one retry this time
<cpaelzer> I haven't seen the UID thing before, so I thought I mention if that is known to you already xnox
<cpaelzer> xnox: I read through the last 8 fails and found like 6 different issues
<cpaelzer> so it is (as it was in the past) not just a single issue to fix :-/
<rbasak> RAOF: please could you take a look to see if you're happy releasing budgie-desktop-environment? I'm not sure how to verify the things mentioned in the changleog without bugs, or if you're expecting those to be released without explicit veriication?
<rbasak> bug 1755831 and bug 1772238
<ubottu> bug 1755831 in budgie-desktop-environment (Ubuntu Bionic) "ibus not working properly" [Wishlist,Fix committed] https://launchpad.net/bugs/1755831
<ubottu> bug 1772238 in budgie-desktop-environment (Ubuntu Bionic) "[SRU] .desktop file strings shown untranslated in Budgie" [High,Fix committed] https://launchpad.net/bugs/1772238
<RAOF> rbasak: I was going to release without explicit verification of the things not bugged in the changelog.
<RAOF> Oh, yeah! It's Wednesday! Oops.
<rbasak> RAOF: OK. Do you want to take care of that then?
<rbasak> I'm just about done with the pending-sru queue for today. I didn't get o some. debootstrap should be releasable soon - I've kicked some dep8 tests and force-badtested one.
<rbasak> I'm looking at qemu and libvirt from the Bionic unapproved queue next.
<cpaelzer> RAOF: he is looking at the mentioned because he is kind and I'm sort of RAOF for those two updates :-)
<RAOF> I can take care of that, but it'll be tomorrow, because I'm on my phone now ð
<cpaelzer> RAOF: then let rbasak continue and take what you can tomorrow
<cpaelzer> IMHO the queue is full enough to get both of you busy
<cpaelzer> if rbasak tries to get the full queue done today his head might explode
<LocutusOfBorg> nacc, pacemaker merge?
<rbasak> didrocks: fancy re-sponsoring lastpass-cli in bionic unapproved but using Ubuntu or adjusting vendor so that Launchpad-Bugs-Fixed appears? :)
 * rbasak will be back after lunch
<xnox> Laney, mailings lists are dead; long live mailing venues =)
<Laney> :>
<Laney> we could use the Ubuntu amphitheatre
<didrocks> rbasak: sorry, wdym by "using Ubuntu"? Indeed, the changelog has a Closes: instead of LP:. I didn't notice it, Nafallo FYI ^
<didrocks> if that's the only thing needing changes, I'll handle it, just want to clarify the "but using Ubuntu" :)
<rbasak> didrocks: "Closes LP:
<rbasak>      #1766186"
<rbasak> should be parsed correctly I believe.
<ahasenack> "Closes" is fine, dep3changelog uses that syntax
<ahasenack> but LP: # is mantadory
<rbasak> I think it's odd, but some old timers use it.
<didrocks> I'll replace by a traditional LP: ;)
<didrocks> rbasak: let me reject the current one
<ahasenack> rbasak: dep3changelog adds "Closes"
<rbasak> didrocks: usually when the header is missing it's because the signer used dpkg-buildpackage on Debian without overriding the vendor.
<didrocks> rbasak: it's a new setup machine, maybe I'm missing a config I didn't restore? but I'm on bionic
<rbasak> The only other thing I can think of is that the line wrap confused the parser. But I was under the impression that didn't affect anything.
<didrocks> could be
<rbasak> AFAIK, it should work by default on any Ubuntu
<rbasak> (well maybe not Warty, I don't know)
<Laney> https://launchpadlibrarian.net/374036485/lastpass-cli_1.0.0-1.2ubuntu2_source.changes <- no LP there?
<rbasak> That's weird
<rbasak> https://launchpadlibrarian.net/374053940/apache2_2.4.29-1ubuntu4.2_source.changes is what I was looking at
<rbasak> Which would explain it
<rbasak> I'm looking at the wrong package :)
<Laney> :D
<didrocks> :)
<didrocks> yeah, it was wrong anyway, Closes: instead of LP: as said
<didrocks> argh, I purged LaTeX after sponsoring this! Have to reinstall it because debian/rules clean needs it :p
<rbasak> I use -nc -d usually
<Laney> didrocks: debuild -S -d -nc?
<Laney> high five
<didrocks> yeah, let's try with -nc to see if the diff is ok
<didrocks> Launchpad-Bugs-Fixed: 1555562
<didrocks> ok, looking better
<didrocks> and diff is ok
<rbasak> \o/
<didrocks> rbasak: thanks for noticing! Pushed
 * rbasak pends on the Launchpad diff generator
<Laney> ahasenack: never heard of dep3changelog, thanks for the hint BTW
 * Laney notices who wrote it too
<ahasenack> who?
<rbasak> The one person that I know of who considers "Closes: LP: #XXX" OK :)
<rbasak> Oh no sorry. That's "Closes LP: #XXX" :)
<nacc> LocutusOfBorg: i'll take a look
<LocutusOfBorg> nacc, <3
<smoser> slangasek: you did a review of bionic pollinate SRU at https://bugs.launchpad.net/ubuntu/+source/pollinate/+bug/1761240 . the code for the trusty, xenial, artful are all the same as the bionic... i wonder if you could easily review those also ?
<ubottu> Launchpad bug 1761240 in pollinate (Ubuntu Artful) "SRU pollinate 4.33" [Medium,Confirmed]
<smoser> https://bugs.launchpad.net/ubuntu/+source/pollinate/+bug/1761240
<slangasek> smoser: it's not true that they're all the same as for bionic, today; bionic is at 4.31, artful is at 4.27, etc.  so the diffs will need separate review (but I'm planning to do that)
<smoser> slangasek: yes, understood that you review the changes, but in this particular package, probably reviewing the code is just as easy.
<smoser> $ wc -l `which pollinate`
<smoser> 350 /usr/bin/pollinate
<xevious> python3-configshell-fb (which is in universe) has a bug that's breaking my scripts on Ubuntu. It was resolved in 1.1.fb23 (1.1.23 in Debian-speak). What's the process for getting a universe package updated to its latest version?
<xevious> https://github.com/open-iscsi/configshell-fb/commit/82f79eb2f967ecd820d531488d0b64d6015b1aaf
<nacc> xevious: file a bug
<xevious> Would it be better to file it with Debian or on Launchpad?
<tsimonq2> xevious: Launchpad.
<nacc> xevious: ubuntu bugs go in launchpad
<nacc> xevious: but it's not fixed in debian either? then you'd also file one there as a good person (tm)
<roaksoax> win 3
<tsimonq2> win 4
<Unit193> /win 73
<xevious> nacc: No, sid and bionic have the same version in universe.
<xevious> nacc: I'll file the bugs once I finish some tests.
<winksaville> I'm using bionic and I ran across a problem using llvm-3.9 that I build from source using gcc, but if I use llvm-3.9 package it works. Further, if I use clang to compile llvm-3.9 from source it works.
<winksaville> So my question is when the llvm-3.9 package is built for distribution what compiler is used?
<sarnold> winksaville: take a look at the build logs on https://launchpad.net/ubuntu/+source/llvm-toolchain-3.9
<sarnold> here's the difference that ubuntu carries compared again sthe debian package https://patches.ubuntu.com/l/llvm-toolchain-3.9/
<sarnold> hope this helps, lunchtime :)
<winksaville> Txs, I'll take a look
<xevious> nacc: I got around to making the Ubuntu ticket: https://bugs.launchpad.net/ubuntu/+source/python-configshell-fb/+bug/1776761
<ubottu> Launchpad bug 1776761 in targetcli-fb (Ubuntu) "targetcli aborts with the error message "NameError: name 'readline' is not defined" when running in interactive shell mode" [Undecided,New]
<winksaville> sarnold: I found the build logs on https://launchpad.net/ubuntu/+source/llvm-toolchain-3.9/1:3.9.1-19ubuntu1/+build/14185079 and downloaded https://launchpad.net/ubuntu/+source/llvm-toolchain-3.9/1:3.9.1-19ubuntu1/+build/14185079/+files/buildlog_ubuntu-bionic-amd64.llvm-toolchain-3.9_1%3A3.9.1-19ubuntu1_BUILDING.txt.gz
<winksaville> But when I try to gunzip it says its "not in gzip format", what have I done wrong?
<xevious> nacc: I just emailed it to Debian.
<xevious> nacc: ...and here it is on their bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901484
<ubottu> Debian bug 901484 in python3-configshell-fb "targetcli aborts with the error message "NameError: name 'readline' is not defined" when running in interactive shell mode" [Normal,Open]
<winksaville> sarnold: never mind, it appears it gets decompressed in transit or some such and if I save it as a .txt file I can see it just fine.
<doko> coreycb, jamespage: for LP: #1482765 please can you follow-up with the security team?
<ubottu> Launchpad bug 1482765 in neutron-vpnaas (Ubuntu) "[MIR] neutron-vpnaas" [Undecided,Fix committed] https://launchpad.net/bugs/1482765
<sarnold> winksaville: all good?
<coreycb> doko: it looks like the security team's been subscribed. should i check with them on status?
<doko> coreycb: please do. just promited it for cosmic
<coreycb> doko: will do, thanks
<coreycb> doko: is there any way to get that into main for bionic at this point or is it too late?
<doko> coreycb: I was told that you need approval/awareness of the security team for this extended security support
<doko> but we had prmotions in the update pocket before
<coreycb> doko: got it
<coreycb> doko: thanks agian
#ubuntu-devel 2018-06-14
<Laney> xnox: did we ever figure out that serial-getty thing?
<xnox> Laney, nope, don't think so
<Laney> hmm
<Laney> stgraber: if you've got some time later, could you help us figure out where /etc/systemd/system/getty.target.wants/serial-getty@.service is coming from in ubuntu images: containers please?
<Laney> stgraber: it blocks the system from being considered 'running' until it times out
<xnox> and it appears to be generated on first boot only; not subsequent ones; as if some side-channel is used to configure the container on first boot, which systemd serial generator manages to spot but then that goes away
<LocutusOfBorg> sbeattie, intel-microcode sync now? :)
<menace> why does ubuntu not fix gnupg for 16.04, though it is in main and should therefore get security upgrades? there's a security update
<rbasak> menace: are you sure it's not fixed? What's the CVE?
<rbasak> menace: use https://people.canonical.com/~ubuntu-security/cve/ to look it up please.
<mdeslaur> this? https://usn.ubuntu.com/3675-1/
<mdeslaur> menace, rbasak ^
<menace> yep, why is gnupg2 not fixed in 16.04?
<jdstrand> mdeslaur: ^
<menace> sorry for the long reaction
<mdeslaur> hrm, that's a good question
<mdeslaur> sbeattie: ^
<r4co0n> Hi, I come over from #ubuntu, where I just asked if a backport of a recent version of source package nghttp2 would be accepted for xenial? We have this as a build dependency here and would like to avoid building it too.
<r4co0n> upstream has 1.32.0, as does buster - xenial, which we are targetting, only has 1.7.1 available, cosmic is at 1.30.1.
<rbasak> r4co0n: see https://wiki.ubuntu.com/StableReleaseUpdates and/or https://wiki.ubuntu.com/UbuntuBackports
<r4co0n> rbasak, I think "Continued Functionality of Reverse-Dependencies" is what will rule out backporting this.
<r4co0n> thanks for your help
<winksaville> sarnold: All is good, it looks to me that gcc-7 was used to compile the toolchain, clang was used in tests.
<winksaville> Not what I was hoping to see, as I've found compiling llvm with clang but the app (ponyc) with gcc works, where as if both are compiled with gcc it fails. So I'm going to try to figure out why, we'll see if I'm successful :)
<mdeslaur> r4co0n, rbasak: nothing appears to use nghttp2 in xenial though, so it may still be a possibility: $ reverse-depends -r xenial src:nghttp2
<mdeslaur> No reverse dependencies found
<mdeslaur> we pretty much disabled everything from using nghttp2 in xenial with the intent on possibly re-enabling at a later date. Updating it to a more recent version would possibly make sense
<r4co0n> mdeslaur, that sounds promising. I will look into backporting this, if I get it to work as expected locally, I will get back here.
<nacc> r4co0n: if you haven't seen it, `backportpackage` may be helpful (you can test in  PPA)
<slangasek> cjwatson: hi, so LP: #1451194 has been a nuisance for a while but has bubbled up the priority list a bit.  I would like us to fix this by having openssh itself (as profile code shipped in the package, not directly in the daemon...) detect when an invalid locale has been passed, and squash it to C.UTF-8.  Do you have opinions?
<ubottu> Launchpad bug 1451194 in openssh (Ubuntu) "OpenSSH always passes LANG and LC* environment variables, even when it doesn't make sense" [Undecided,New] https://launchpad.net/bugs/1451194
<cjwatson> slangasek: I'd rather see somebody help to push forward something like Damien's suggestion towards the end of https://bugzilla.mindrot.org/show_bug.cgi?id=1346, personally
<ubottu> bugzilla.mindrot.org bug 1346 in sshd "PAM environment takes precedence over SendEnv" [Normal,New]
<cjwatson> I don't think any of this is particularly straightforward
<cjwatson> slangasek: but I'll review a patch to profile code if somebody wants to come up with one, I suppose
<slangasek> cjwatson: "could somehow search the local locale database for a good fit" that one?
<slangasek> I'd fear that would get bogged down in upstream design discussions for rather a long time
<slangasek> am I wrong?
<slangasek> and doing it in profile of course has the limitation that it's ineffective when you're not running a shell
<cjwatson> slangasek: it might take a while to sort out, but I'm concerned about yet another profile-level hack that will have corner cases, be Debian-specific, etc. etc.
<slangasek> ok
<cjwatson> I acknowledge it may be better than nothing at all, but still, it's not my preferred optiomn
<cjwatson> *option
<cjwatson> something that's been suggested by upstream to begin with seems like a good candidate for not getting too hopelessly bogged down
<slangasek> so we currently have /etc/profile.d/Z99-cloud-locale-test.sh which looks at the locale settings, detects invalid ones, but only screams about it rather than fixing up
<slangasek> maybe we should improve that in cloud-init, and then also work on the upstream openssh solution
<rbasak> I suggested doing it in PAM rather than in profile. I think that'd work for non-shell cases too.
<slangasek> right, otoh if there's appetite for doing it in openssh directly, that's even more comprehensive
<slangasek> smoser: ^^ do you have concerns about making /etc/profile.d/Z99-cloud-locale-test.sh do a locale fix-up instead of screaming?  (to eventually become a no-op if we change the openssh upstream behavior)
<smoser> slangasek: what is "fixup" ?
<slangasek> smoser: replace invalid locales in the environment with C.UTF-8
<slangasek> smoser: (instead of a loud banner)
<smoser> the fallout of doing so is 2 things
<slangasek> smoser: at minimum for en_* locales that we haven't generated; but I think we should give the same experience to users of all locales, English or not
<smoser> a.) the user doesn't get told how to fix this situation on their new instance
<smoser> b.) if they already knew hwo to fix it, theyd' have to exit and come back in to get it applied. versus just having it fixed by 'apt install'
<smoser> its not "english or not"
<smoser> its instance has a locale present or not.
<smoser> quite possibly an image built other than by canonical official images has multiple locales.
<slangasek> the user gets told how to fix it; in English.  if they needed a non-English locale, this is not the most helpful.
<smoser> slangasek: we're not going to fix all the places that a non-english speaking person who ssh's to a system has to read english.
<smoser> at least not in cloud-init
<smoser> it may not be perfect, but I suspect that the majority of users are able to figure it out.
<slangasek> a well-localized system should not require a user to read any English at all
<slangasek> if the user wanted non-English, they can pick their locale in cloud metadata
<smoser> so was the message actually causing problems ?
<smoser> ie.... could we
<slangasek> if I don't speak English and I log into the system and get English, I'm going to google for help in my own language
<cjwatson> The message doesn't cause a major problem IMO; not having a working locale can, though
<smoser> slangasek: well, honestly likely if you see:
<slangasek> the banner is not necessarily useful, because I don't necessarily understand any of the words printed
<smoser>  apt-get install locale-cc
<smoser> you might guess that copy and paste is going to fix your problem
<cjwatson> (IMO in all cases where it does cause a problem it's a bug at that point, but tackling it that way hasn't always been super-effective)
<smoser> but anyway...
<smoser> so... what about
<smoser> a.) give a message stating how to fix
<smoser> b.) set C.utf-8
<slangasek> smoser: the message is intrusive, particularly for users who *don't* care about translations because their local locale is en_US.UTF-8 and their remote locale should be C.UTF-8
<smoser> or was the message itself problematic to something.
<slangasek> smoser: we have had a complaint about the message per se
<slangasek> and per above, I don't think it's actually the right place to tell the user how to fix it
<slangasek> was this initially added based on user requests?
<smoser> this was originally added under request of a partner who was heavily non-english
<slangasek> ok
<smoser> (from my memory)
<slangasek> so that's a useful datapoint
<slangasek> smoser: I certainly think that "print message, then map to C.UTF-8" is better than status quo
<slangasek> I would still prefer the mapping, with no message
<smoser> slangasek: i dont understnad why youd' prefer that though.
<smoser> other than filling up stderr with non-useful information on the first time connection to a new instance for the user.
<slangasek> smoser: because I think it's correct for every US user to have en_US.UTF-8 as their local locale, and I think it's correct to have C.UTF-8 as the default remote locale on all cloud instances, and I think it's annoying to print a large banner message in this case
<smoser> i can see myself complaining about cloud-init writing nonsense to my stderr that was breaking some scripts i have.
<slangasek> which is why I mentioned that we might special-case English here
<smoser> but then i can see the other side of myself saying ... "well set your locale to C.UTF-8 and that wont happen... you should do that anyway if you're looking at output."
<slangasek> which also leads to my observations about the irony of presenting a message in English only to those users who request non-English
<slangasek> "set your locale to C.UTF-8" - nack that is not the correct locale for the client, and having to configure your ssh client to DTRT is noisome
<smoser> meh. i get bug reports in non-english. i can usually make out what they mean. and i'm about as non-french (or dutch or spanish or chinese) speaking as a person can be.
<smoser> i'd only ever complain about automation
<smoser> that is the only time when it can be considered annoying.
<smoser> if you're parsing machine output, C.UTF-8 is the right thing.... or, if you wanted to parse xx_XX, then well, you should be setting up the locale so the message was useful.
 * cjwatson takes that as a challenge to start filing bug reports in smoser's direction in Irish
<smoser> as long as they have stack traces
<cjwatson> heh
<smoser> then i'm good.
<Nafallo> reminds me about when I had a Welch manager that changed language when he was in the mode. he stopped when I talked Swedish at him ;-)
<slangasek> smoser: so there's the other subcase that we would care about, which is that I think this message should be suppressed on minimal images
<smoser> slangasek: i'm not completely bent on keeping exactly what is there. as you might suspect, it doesn't affect me
<Nafallo> s/mode/mood/
<smoser> but i dont know where else you might enlighten the user on how to fix this.
<slangasek> smoser: minimal images have all locales stripped etc and are not meant for human use and the user gets a separate message in motd telling them how to unminimize
<smoser> the human user gets a message
<smoser> the one that the image was not designed for
<smoser> :)
<slangasek> yes
<smoser> is that message translated ?
<slangasek> but as they already get a message about it being minimal and how to make it human-friendly, we should fold any locale information into that message
<slangasek> not have cloud-init present one separately
<smoser> i'm also perfectly fine to look one other place before doing nothing in Z99-cloud-locale-test.sh
<smoser> such that minimal images could just contain configuration that tells cloud-init you're not interested in that.
<smoser> or, i guess if you  put something that changed the lcoale as you're suggesting in the minimal image, as long as it ran before Z99, then cloud-init would see the changed values and would not print anything.
<smoser> right?
<smoser> echo 'LC_ALL=C.utf-8' > /etc/profile.d/Z98-minimal-cloudimage.sh
<slangasek> smoser: that makes it even more difficult for a user to set a different locale if that's what they want.  If cloud-init is going to print anything at all in any cases, I'd rather we have it a) not print when the invalid locale is en_*, and b) not print when we're running on an image which is discernably Ubuntu minimal
<slangasek> smoser: but, if the end state is that openssh is going to avoid ever passing an invalid locale to the target environment, this script in cloud-init will no longer print anything, ever
<slangasek> so if that's the direction we're going, I don't see a reason not to change cloud-init now to match that
<smoser> $ cat /etc/profile.d/Z98-minimal-cloudimage.sh
<smoser> LC_ALL=C.UTF-8
<smoser> that does seem to work.
<slangasek> yes, but it's wrong to have to add this as additional config on the image
<smoser> i dont know that that is true.
<smoser> you're suggesting its wrong to change the thing that wants behavior changed. its better to change everything.
<smoser> but again, i'm not really oppposed to your suggested change if its thought through. i am opposed to change on a whim.
<slangasek> I'm saying it's wrong to solve this by scattering more unmanaged config files on the image
<smoser> it doesnt have to be unmanaged.
<slangasek> that increase what the user has to contend with if they do know what they're doing and do want to enable a locale on a minimal image
<slangasek> we don't install any additional packages in the minimal image
<ErichEickmeyer> Okay, I've gone through the wiki and I give up. We (the Ubuntu Studio team) have a number of ubuntustudio-* package updates that we need to get into Cosmic. How do we go about doing that?
<tsimonq2> ErichEickmeyer: Meaning, new packages or existing package updates?
<ErichEickmeyer> existing package updates.
<tsimonq2> What kind of updates? Do you have a debdiff?
<ErichEickmeyer> Basically, the first four in https://code.launchpad.net/~ubuntustudio-dev
<slangasek> ErichEickmeyer: does the Ubuntu Studio team not have any uploaders for your packages?
<ErichEickmeyer> slangasek: We do not currently, the ones we had are AWOL or burnt-out during the last two years.
<tsimonq2> ErichEickmeyer: I can help y'all out this time, but ditto slangasek. :)
<ErichEickmeyer> There were a lot of issues leading to it, but we're picking-up the pieces.
<slangasek> ErichEickmeyer: from a flavor governance POV, it should be a very high priority for you to get uploaders on your team, either by convincing existing Ubuntu developers to become part of the team or by having team members apply for uploader rights
<tsimonq2> ErichEickmeyer: It would be great if these could be git instead of bzr. ;P
<ErichEickmeyer> tsimonq2: We have one in git, and we're slowly migrating. I might take-up that on the ones I've touched.
<ErichEickmeyer> slangasek: Agreed. Studio was on the verge of dying before a few of us got busy, but those of us that "rescued" it don't have uploader rights.
<tsimonq2> ErichEickmeyer: I have a script that converts them super easily. If you add me to a team I can JFDI.
<ErichEickmeyer> slangasek: We used to have Ross Gammon, but we rarely if ever see him, and sakrecoer is, for lack of a better term, out.
<ErichEickmeyer> tsimonq2: Done.
<tsimonq2> ErichEickmeyer: I might also invest some time in cleaning up these packages, so that when someone else jumps in, they aren't coming into a labyrinth of outdated packaging (been there done that). ;)
<ErichEickmeyer> tsimonq2: Sadly, that's going to be the case. We have a ton of packages that are leftover from Trusty. :P
 * tsimonq2 shudders
<tsimonq2> Challenge accepted.
<ErichEickmeyer> LOL
<slangasek> ErichEickmeyer: I know Ross applied for uploader rights last November but I don't know if that was granted... and I hadn't heard that he'd idled out
<ErichEickmeyer> slangasek: That's correct, pretty much idled out.
<ErichEickmeyer> He simply has no time.
<ErichEickmeyer> same with sakrecoer.
<ErichEickmeyer> This is what happens when a flavor is on the verge of dying and somebody gives it CPR.
<ErichEickmeyer> I've been lucky to be able to keep OvenWerks and eylul, but everyone else is new (including me).
<ErichEickmeyer> Though eylul is pretty burnt-out from the last two years as well.
<tsimonq2> ErichEickmeyer: Seems I need to be a member of Ubuntu Studio Core to have permissions to push to lp:ubuntustudio-icon-theme.
<ErichEickmeyer> tsimonq2: Oh man, sakrecoer is still the owner, and he was going to hand ownership to me 2-3 weeks ago but never did. :/
<tsimonq2> ErichEickmeyer: Oh well. We can make it work for now.
<tsimonq2> I'll just push to a different-yet-sane location.
<ErichEickmeyer> tsimonq2: I just changed the maintainer. Should be good now.
<tsimonq2> ErichEickmeyer: Thanks.
<ErichEickmeyer> Np
<tsimonq2> ErichEickmeyer: "ubuntu-studio-devel@lists.ubuntu.com" is still your mailing list?
<ErichEickmeyer> tsimonq2: Yes.
<tsimonq2> Cool.
<tsimonq2> Actually, let's continue this in #us-dev :)
<Deknos> ahoi, is there a information, why ubuntu did not patch gnupg2 for ubuntu 16.04?
<sbeattie> Deknos: sorry, oversight, working on it.
<Deknos> ah, okay, that's okay, no problem, thank you!
<slangasek> smoser: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1134036/comments/20
<ubottu> Launchpad bug 1134036 in maas (Ubuntu) "Failure when using ssh with a locale that is not configured on the server" [Medium,Confirmed]
<slangasek> smoser: and I've polled some non-native English speakers, so far nobody has told me I'm insane for wanting to remove the message
<slangasek> smoser: but I give you options on what type of patch you'd prefer for cloud-init
<tych0> smoser: hi, i have a question. i'm using uvtool to try and test some new kernels
<tych0> when i install my new kernel and reboot, it renames my vm's NIC
<tych0> so i followed the instructions in /etc/netplan/*cloud-init.yaml
<tych0> about putting network: {config: disabled} in /etc/cloud/cloud.cfg.d somewhere
<tych0> but it still configures my interface :(
<tych0> is there some way i can get it to not configure? or otherwise get it to b esmart enough to rename the interface?
<rbasak> tych0: for testing, if you have only one NIC, I believe you can set net.ifnames=0 on the kernel commandline and it should always be called eth0. Does that help?
<tych0> oh
<tych0> that does help :)
<tych0> let me try.
#ubuntu-devel 2018-06-15
<tych0> oh, but i wonder how i pass that initially before the image spawns, so cloud init sees eth0 the first time it runs
<tych0> hrm. my ifname is still called ens3?
<tych0> i guess it's systemd renaming things?
<rbasak> Did net.ifnames=0 get through? Check /proc/cmdline
<slangasek> no, it's systemd /not/ renaming things
<slangasek> ens3 is the new-style kernel naming
<rbasak> https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html is my usual reference for all of this
<rbasak> My understanding is that ens3 happens as a result of a udev rule
<tych0> rbasak: yes, it did
<tych0> BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=91bfde43-9e70-45e9-b215-ab15bfdf4c92 ro net.ifnames=0 console=tty1 console=ttyS0
<rbasak> "...you disable it by booting with
<tych0> so i wonder if i can install a new kernel now and it won't screw thing sup
<rbasak> net.ifnames=0 or disabling 80-net-setup-link.rules"
<rbasak> [upstream]
<slangasek> ah
<slangasek> sorry, I was under the impression this was the in-kernel name nowadays
<tych0> well, it seems hung with my new kernel and net.ifnames=0 :(
<rbasak> Hung on boot? Give it 60 seconds.
<rbasak> (if you have console)
<Unit193> (Isn't ln -s /dev/null /etc/systemd/network/99-default.link  the more recommended method anyway?)
<tych0> yeah, i have console
<tych0> you can reproduce this by just uvt-kvm create a vm, and then install a stock 4.17 kernel build from upstream with bindeb-pkg
<tych0> it just hangs forever
<tych0> anyway, based on irc timestamps 60 ceonds have passed and no luck :(
<tych0> oh, there we go
<tych0> huh, weird
<tych0> it's still named ens3
<slangasek> Unit193: well, I don't know what people who don't want ifnames recommend; I recommend not trying to outsmart ifnames
<tych0> but it took like 3 minutes to get past something. what's the systemd command for showing what took what time in th eboot chain?
<rbasak> What are you trying to achieve?
<slangasek> tych0: systemd-analyze
<tych0> rbasak: i want to run a mainline kernel on a uvt-kvm created vm
<slangasek> and systemd-analyze critical-chain
<rbasak> If you use a non-Ubuntu kernel with perhaps a different config, then things may not necessarily work.
<tych0> slangasek: right, thanks
<rbasak> You might have better luck with https://wiki.ubuntu.com/Kernel/MainlineBuilds
<tych0> rbasak: naturally. but i've been using this setup for several years, 18.04 images brok eit :(
<Unit193> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ near the bottom.
<tych0> rbasak: i don't really want a mainline kernel, i want a kernel with patches that i have applied. but my patches are unrelated to ifnames and such
<rbasak> Unit193: I don't think those instructions take into account backwards compatibility with older Ubuntu that pitti took care of so carefully - see my link above.
<smoser> tych0: well, cloud-init should be configuring your networking once per instance.
<smoser> on subsequent boots, cloud-init should not do anything in uvtool. pretty sure it should recognize its not a new instance and do nothing.
<smoser> so... cloud-init *should* set the system up to always rename the nic that is there with the same name.  ie, it "pins" it to whatever it saw the first time for this instance.
<tych0> smoser: but the contents of /etc/netplan/*cloud* mention that it will reconfigure it once per boot
<smoser> easiest thing for you to do if you want to just get rid of cloud-init interaction with networking in boot is just: sudo touch /etc/cloud/cloud-init.disabled
<smoser> then it wont even run on subsequent boots.
<smoser> to be clear... http://paste.ubuntu.com/p/p3m9SPpCHB/
<smoser> the behavior you're describing is definitely not intended. so feel free to file a bug.
<smoser> but i suspect your test kernel doesn't have some drivers or can't see the uvt-provided filesystem or somthing
<smoser> so cloud-init tries to re-configure
<smoser> or possibly its something else.
<smoser> anyway, feel free to file a bug.
<smoser> if you just want cloud-init out of the way, touch that file and be done.
 * smoser has to go afk
<tych0> smoser: cool, thanks
<tych0> i like it on first boot, but you're right that i'm probably missing some drivers that uvt kvm wants. the kernel is very small
<razwelles> Hey, I'm trying to understand the underpinnings of how linux puts a system on sleep. I've followed up to s2ram, and /sys/power/state, but I'm trying to find source code and I don't know where to go from there.
<cpaelzer> Laney: hi, I have checked bug 1708008 - if I read that correctly you know the code that runs there
<ubottu> bug 1708008 in rabbitmq-server (Ubuntu) "rabbitmq-server 3.5.7-1ubuntu0.16.04.2 security update dumped durable queues for autopkgtest.ubuntu.com" [Undecided,Triaged] https://launchpad.net/bugs/1708008
<Laney> hey cpaelzer
<Laney> did you see my reply?
<cpaelzer> Laney: do you know if we publish in persitent mode
<Laney> ah yes, you replied again
<cpaelzer> I only wrote mine and didn't refresh :-)
<Laney> maybe you didn't see comment #6
<Laney> :-)
<cpaelzer> hehe
<cpaelzer> the good things is we came to the same conclusion and the bug is no bug
<cpaelzer> thanks Laney
<Laney> cpaelzer: this is a more emegent issue for us https://bugs.launchpad.net/auto-package-testing/+bug/1772236 if you're interested in more rabbity things
<ubottu> Launchpad bug 1772236 in rabbitmq-server (Ubuntu) "rabbit died and everything else died" [Undecided,New]
<cpaelzer> I'm not particularly interested, was just going along bug queues and found this one could need some love
<Laney> ok then
<Laney> is there a procedure to get this on your team's queue somehow?
<cpaelzer> rabbitmq is in for OpenStack which is why the team is also subscribed
<cpaelzer> on the server team we mostly try to run away if we see it
<cpaelzer> It would usually be picke dup on bug triage which is a daily round robin task
<cpaelzer> don't ask me what happened to this one :-)
<cpaelzer> the procedure if the former doesn't work is in ping in #server about it
<cpaelzer> but you did now
<Laney> I guess really I should test that security regression theory by reverting erlang eh
<Laney> the update doesn't look that suspicious :/
<cpaelzer> no it really doesn't
<cpaelzer> so you want to downgrade/upgrade erlang to see if that was the trigger?
<cpaelzer> or does it then also need time to reach the OOM that one can see in the bug
<cpaelzer> I don't know what to do on rabbitmq on this bug for now, if anything consider making Restart=on-failure the default
<Laney> they've been about a week apart
<cpaelzer> what is your experience with that setting so far?
<Laney> hasn't happened since then
<cpaelzer> I'm subscribing the Team, but for now there is no clear action to take IMHO
<cpaelzer> if you found something that should be changed let us know
<cpaelzer> the subscription ensures it isn't totally lost
<Laney> it's just suspicious to me that it started memleaking after all these years
<cpaelzer> but also has no guarantees on 24/7 attention
<Laney> so "feels" like something changed
<Laney> but yeah, no real evidence
<cpaelzer> yeah one would have expected that since the system was deployed
<cpaelzer> Laney: rabbitmqctl has some logs about memory consumption per queue
<cpaelzer> maybe you could set up a cron job to log hourly to a file or so
<cpaelzer> to have some idea which queue might be the leaker
<Laney> good idea, can you post a tip to the bug and I'll try to get to that later on
<Laney> please?
<cpaelzer> sure
<willdeberry> hello all. i am running some own deb repos for work and wanted to get your inputs on best practice on moving packages between levels of repos (eg: proposed and stable). currently using reprepro and have all the different levels segmented via different URLs and we sync between them using rsync. Is relying on rsync and different URLs against the grain? Is it better to manage packages at the
<willdeberry> individual package level and use something like reprepro to move between levels?
<willdeberry> not sure why that split between lines :-/
<cjwatson> It's usually much better to have a single pool and have something like reprepro add extra references to the relevant packages to different suites under dists/
<cjwatson> rsyncing things around is certainly possible but really painfully clunky
<cjwatson> You can just use "reprepro copy" and friends
<willdeberry> copy will overwrite all contents if you move from proposed to stable for instance?
<cjwatson> willdeberry: What do you mean?  Presumably you don't have the same version of the same package in both proposed and stable with different contents in each; that would be weird and confusing and probably something you'd want to avoid.  So I'm not sure what would be overwritten.
<psusi> am I crazy or is grub-efi-amd64-signed supposed to be included in the pool on the install image, otherwise you can't install on a secure boot system without a network?
<psusi> and it doesn't seem to be listed in any of the cd manifests
<cjwatson> $ curl -s http://releases.ubuntu.com/bionic/ubuntu-18.04-desktop-amd64.list | grep grub-efi-amd64-signed
<cjwatson> /pool/main/g/grub2-signed/grub-efi-amd64-signed_1.93+2.02-2ubuntu8_amd64.deb
<psusi> ahh... right... the .manifest is what is in the squashfs
<cjwatson> Indeed
<psusi> ahh, ubuntustudio is missing /pool
<psusi> at least in 16.04.4
<willdeberry> cjwatson: gotcha, by overwrite i should have said version bump. thanks or the direction and info
<cjwatson> willdeberry: Oh, right.  I don't use reprepro very much but I think so.
<powersj> anyone know if this page ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi was migrated anywhere before alioth was retired
<tsimonq2> powersj: I don't think so.
<tsimonq2> sil2100 (who needs to get a bouncer!) brought it up on some mailing list a week or two ago
<tsimonq2> bdmurray: Forgive my bikeshedding :)
<bdmurray> tsimonq2: It'd be more helpful if you'd add what you'd like.
<tsimonq2> bdmurray: Perhaps s/can take/takes/ but I was uncertain on it.
#ubuntu-devel 2018-06-16
<tsimonq2> rbasak: In light of bug 1777205, it would be good if some progress could be made on the python-acme SRU, unless removal is a better option.
<ubottu> bug 1777205 in python-acme (Ubuntu) "python-acme to start crashing on June 19th" [Undecided,New] https://launchpad.net/bugs/1777205
<Unit193> https://github.com/certbot/certbot/commit/5940ee92ab5c9a9f05f7067974f6e15c9fa3205a is a really easy fix.
<tsimonq2> Right, and I'd JFDI, except there's already a package in xenial-proposed.
<Unit193> Bug says it only applies to Bionic.
<tsimonq2> ...
<tsimonq2> oh
<tsimonq2> Unit193: When was it that you were going to apply for MOTU already? :P
<Unit193> At least 4 weeks, though I think this is a core-dev thing. :)
<sarnold> when are you applying for that then? :)
 * sarnold runs
<Unit193> Much longer?  Likely care more about universe though.  Hopefully DD isn't too far.
<sarnold> heh, funny, I thought you already had that one..
<Unit193> I have DM.
<sarnold> ah so i'm at least not way wrong :)
<Unit193> (I need another sig to actually get DD, so that'll be hard to come by.)
<tsimonq2> I'm in the same boar.
<tsimonq2> *boat
<tsimonq2> I have two borderline three advocates for DD. I just need the sigs.
<tsimonq2> (Although I am headed towards core-dev myself...)
#ubuntu-devel 2019-06-10
<whereistimbo> Hi guys. I'm having trouble building pulseaudio deb from git branch remotes/pkg/applied/ubuntu/bionic, I'm using clean install of xubuntu 18.04.2 with virtualbox, any help with recommended setup?
<raviola> 	Hi guys. I'm having trouble building pulseaudio deb from git branch remotes/pkg/applied/ubuntu/bionic, I'm using clean install of xubuntu 18.04.2 with virtualbox, any help with recommended setup?
<raviola> I need build pulseaudio deb package from source so I can debug it. But I have trouble to build it even in clean install
<cjwatson> this is not me offering to help, but you probably stand a better chance of finding somebody to help you if you put a transcript of exactly what you've done and the resulting error messages on a pastebin (e.g. paste.ubuntu.com)
<cjwatson> (please don't highlight me in responses)
<raviola> Thanks cjwatson, however I think the fault is my part so I'd like to just redo the clean install in virtualbox
<cjwatson> 14:08 <cjwatson> (please don't highlight me in responses)
<cjwatson> anyway, if you don't show what the errors are then probably nobody will be able to help
<cjwatson> so that would be your best way forward
<sil2100> Laney: hey! A quick question - do you know if the latest version of britney2-ubuntu is used in production right now? Since I was thinking of maybe switching off dry-run mode from the SRU ADT thingy this week, it looks like it works as expected but still doesn't save the state apparently
<sil2100> Laney: I think I fixed that though
<sil2100> Laney: is the latest master in production now? Or is it simply the broken version still?
<Laney> sil2100: what broken version?
<Laney> every run does a 'git pull' from the branch
<Laney> I didn't merge anything further from you yet if that's what you mean
<sil2100> Ah, hmmm, so it's basically using the latest master
<sil2100> Since I pushed 2 fix commits there, but maybe there's something broken somewhere else
<sil2100> Laney: thanks, will look into what's up then o/
<Laney> you can go onto the machine and look at 'git log' in there
<sil2100> Laney: but isn't that on snakefruit?
<Laney> yeah
<Laney> can confirm the head is 1cbc21d25851bf5652663a434d20a2c671c59e54
<sil2100> Laney: thanks!
 * sil2100 looks into that
<sil2100> Laney: aaaah, ok, forgot that when it's run in dry-run mode, the state file is simply not saved
<sil2100> Laney: duuuh
<sil2100> Laney: so ok, it will most probably work once we switch to normal mode of operations
<sil2100> Laney: do you think we could switch dry-run off tomorrow?
<Laney> sil2100: yeah, I think that should just happen if you commit the appropriate change to b1
<ahasenack> is there a specific log file ownership/permissions policy for when we want the logs to be restricted?
<ahasenack> I've seen some 0640 root:adm
<ahasenack> or root:root 0600
<ahasenack> also syslog:adm 0640
<ahasenack> apport.log: 0640 root:adm
<ahasenack> auth.log: 0640 syslog:adm
<ahasenack> boot.log: 0600 root:root
<ahasenack> syslog: 0640 syslog:adm
<sarnold> ahasenack: hmm, I thought the policy manual dictated adm group for most logs, but don't see it on https://www.debian.org/doc/debian-policy/ch-files#log-files
<ahasenack> yeah, it talks about purging, but not ownership or permissions
<ahasenack> even 10.9 just below
#ubuntu-devel 2019-06-11
<cpaelzer> is there a runtime component that resolves some of the usrmerge
<cpaelzer> I'm trying to find why in a container/vm of eoan I have /usr/sbin/iptables while on an sbuild env it is missing
<cpaelzer> the package itself carries only /sbin/iptables, so something else must add that symlink with /usr prefix
<cpaelzer> and since that is ok on container/vm but missing in sbuild I wondere if there is something active that doesn't run in the schroot that adds this
<cpaelzer> if anyone has a pointer about that please let me know :-)
<cpaelzer> oh and s390x seems stuck at https://launchpad.net/builders
<cpaelzer> if anyone could bump them that would be great
<acheronuk> ^ cjwatson ?
<cjwatson> poking
<cpaelzer> thanks cjwatson
<cyphermox> doko: didrocks: jdstrand: cpaelzer: MIR team meeting?
<doko> cyphermox: wrong channel? ;)
<cyphermox> no
<cyphermox> it's meant to be a ping ;)
<ahasenack> hi, diaspora-installer actually downloads the diaspora tarball from github in its postinst, using wget. That fails on the armhf autopkgtest lxd (https://pastebin.ubuntu.com/p/N9MqVKvN4Q/), but works in the other arches (https://pastebin.ubuntu.com/p/RVQFSwXS8F/)
<ahasenack> both go through squid.internal, but on the armhf lxd that's unresolveable (dns)
<ahasenack> hm, n/m, that was just bad luck, but there is still a real error later on. I created an MP to hint it
<coreycb> hello, can an archive admin please remove python-oslo.log 3.44.0-0ubuntu2 from eoan-proposed? we have some recursive dependency issues and this is the easiest resolution.
<coreycb> s/recursive/circular
<ddstreet> xnox you figured out the systemd storage failures yet?  i won't bother looking if you already fixed it
<xnox> ddstreet:  figured out => no; there is related discussion on the upstream mailing list to the similar effect; i do wonder if we somehow activate swap without noticing, to be debugged. As currently the "swap" test is the one that now consistently fails over.
<xnox> i should upload my experiment to see if things get better.
<ddstreet> xnox i'm pretty sure the problem is the swap (and tmp) tests have ExecStartPost jobs (mkswap and mke2fs) but the test cases don't wait for those post-start jobs to complete, so it's a race between the stop call and the post-start job
<ddstreet> not sure if that's how you fixed it or not
<ddstreet> maybe i'm wrong
<ddstreet> you would know best :)
<ddstreet> it's possible just adding --job-mode=fail would fix the race
<xnox> hm
<xnox> post-start are racy.
<xnox> i wonder why that is used, instead of starting a new unit.
<ddstreet> or, actually waiting for mkswap or mke2fs to complete; the fstab test does by apply(local-fs.target)
<ddstreet> seems the generator stuffs it in there, i assume
<ddstreet> didn't actually look at where it's getting added
<xnox> ddstreet:  experimenting here locally i replaced mkswap -> with 'sleep 30; mkswap.real /dev/....' shell script.
<xnox> ddstreet:  and both 'systemctl start ...' and 'systemctl restart cryptsetup.target' (or like 'local-fs.targer' do seem to block and wait for ExecPostStart to complete.
<xnox> ddstreet:  what my patches locally do, is do not do "double start" anymore, as that is strictly redudand and racy. sprinkle udevadm settle, and force remove dm device.
<xnox> ddstreet:  https://paste.ubuntu.com/p/PFvkGTT3y3/
<xnox> but that's kind of like imperical guessing rather than understanding what is going south here.
<Unit193> Well that was concerning, after yesterday's big OpenSSL update, I had a ruby script fail with encoding issues in openssl/buffering.rb.  Either it was a fluke, or re-running the script gave different output such that the issue didn't happen again. :3
<sarnold> Unit193: does it do dynamic loading?
<Unit193> sarnold: For most elements it's the same if run later in the day as it changes based on the date, for 2 elements though it changes every run.
#ubuntu-devel 2019-06-12
<rbasak> xnox: please could you look at bug 1798786? Claimed to be a regression caused by libssl bump.
<ubottu> bug 1798786 in fetchmail (Ubuntu Bionic) "can't retrieve gmail emails. fetchmail: OU=No SNI provided; please fix your client./CN=invalid2.invalid" [High,In progress] https://launchpad.net/bugs/1798786
 * rbasak doesn't see how that's "In progress"
<rbasak> ahasenack: ^ ah, just noticed the timing of your comment
<rbasak> I added the regression-update tag.
<ahasenack> yep, uploading to the sru queue as we speak
<ahasenack> meant to ping xnox just to let him know
<rbasak> Because I feel this should feed back to the SRU team on regression considerations for the SSL work.
<rbasak> Ah. Thanks!
<xnox> rbasak:  SNI is real, one must send SNI. SO that sru should ship, if it hasn't yet - https://code.launchpad.net/~ahasenack/ubuntu/+source/fetchmail/+git/fetchmail/+merge/368713
<ahasenack> doing it right now
<ahasenack> just checking the version number, I might have made a mistake there
<ahasenack> ah, yeah
<ahasenack> 6.3.26-3build1    | bionic
<ahasenack> 6.3.26-3ubuntu0.1 | cosmic-updates
<rbasak> xnox: sure. No objection to the SRU. I just mean that for the libssl work, it's "Regression Potential" that might have been missed.
<rbasak> (this could be a class of bugs and not just one)
<ahasenack> what version can I use for bionic in this case? Cosmic has the fix already
<rbasak> xnox: do we need to actively look for others, for example, to make sure that we haven't created other regressions?
<ahasenack> I need something between 3build1 and 3ubuntu0.1
<ahasenack> 3ubuntu0.1~18.04.1?
<rbasak> ahasenack: +1
<rbasak> Interesting odd case :)
<xnox> rbasak:  we have fixed half-a-dozen of these SNI things in all the things already. all of those SRUs landed in bionic, prior to landing 1.1.1 sru.
<xnox> but obviously missed fetchmail
<rbasak> xnox: ack. I was just asking if it needs to be thought about, not knowing what had already been considered.
<xnox> rbasak:  all good. SNI was called out as Regression Potential in the openssl 1.1.1 sru.... =)
<xnox> we did anticipate, plan, fix things for it.
<rbasak> Ah, OK :)
<rbasak> ahasenack: when you upload, do you want a fast review for that? Seems appropriate.
<ahasenack> sure
<ahasenack> rbasak: mp is/was https://code.launchpad.net/~ahasenack/ubuntu/+source/fetchmail/+git/fetchmail/+merge/368713
<ahasenack> I'll just have to update the version number, then maybe you can take a quick look, since cpaelzer's +1 was for the former?
<rbasak> Possibly warrants an aging period ignore too, given that it's a regression and the fix is well tested in other series.
<rbasak> Sure
<cpaelzer> yep
<cpaelzer> ahasenack: did you push a new version number to not collide?
<ahasenack> cpaelzer: rbasak: just now
<rbasak> ahasenack: +1. Sorry I think I stole the wrong review slot.
<rbasak> (there are no longer any team ones)
<rbasak> ahasenack: (please upload)
<ahasenack> rbasak: done
<rbasak> Does anyone think that a quick verification and release into -updates immediately is a bad idea for this one?
<rbasak> The source is identical to what is in Cosmic now anyway, sans changelog
<ahasenack> it's even the same version from cosmic
<ahasenack> yeah
<ahasenack> the test is super easy, I can do it as soon as it's available
<rbasak> So only risk is of the rebuild environment being different (which, to be fair, we know it is, because of so much work in Bionic)
<ahasenack> rbasak: well there is a new ssl being picked up this time :)
<rbasak> :)
<ahasenack> rbasak: fetchmail verification done
<rbasak> ahasenack: thanks!
<rbasak> vorlon: your comment introduces some doubt. Do you think I should wait before releasing?
<rbasak> xnox: do you think you could help with vorlon's question in bug 1798786 please? I don't see you subscribed.
<ubottu> bug 1798786 in fetchmail (Ubuntu Bionic) "can't retrieve gmail emails. fetchmail: OU=No SNI provided; please fix your client./CN=invalid2.invalid" [High,Fix committed] https://launchpad.net/bugs/1798786
<xnox> rbasak:  vorlon: https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786/comments/27
<ubottu> Launchpad bug 1798786 in fetchmail (Ubuntu Bionic) "can't retrieve gmail emails. fetchmail: OU=No SNI provided; please fix your client./CN=invalid2.invalid" [High,Fix committed]
<rbasak> xnox: sounds like you're confident - are you happy for me to release?
<vorlon> rbasak, xnox: thanks
<xnox> rbasak:  yes.
<rbasak> Done. Thanks!
<rbasak> (and to Andreas)
<rbasak> (and Christian, and Steve!)
<TJ-> is there a way to auto-generate an initial man-page for a built binary from its --help prior to custom editing it?
<ahasenack> TJ-: I used txt2man in the past to bootstrap a new manpage
<bryce> +1 to txt2man
<bryce> (if the tool's --help is sensibly formatted)
<TJ-> ahasenack: thanks! I ended up doing it manually. I'm packaging dmzadm (for dm-zoned) SMR drive management etc
<ahasenack> good luck, and thanks for thinking about the manpages :)
<TJ-> ahasenack: I live in man-pages; couldn't be without :)
<ahasenack> :)
<TJ-> am I correct in thinking, for the version, if I publish initially in a PPA that -0ubuntu1-xxxx (so that there's no Debian version number) is the way to go?
<TJ-> hmmm that should be -0ubuntu1~xxxx "~" of course
<ahasenack> ~, yes
<ahasenack> I use ~ppaN
<TJ-> I'm doing (test) builds for 18.04>19.10 so I add ~YYMM[.minor]
<TJ-> In case anyone wants to test dmzadm with the dm_zoned device-mapper module, for SMR ZAC/ZBC (host managed) shingled drives, https://launchpad.net/~tj/+archive/ubuntu/ppa/
<Unit193> txt2man?  Seems like you mean help2man.
#ubuntu-devel 2019-06-13
<cjwatson> No, txt2man is a different thing
<cjwatson> apt show txt2man
<cjwatson> (not an endorsement particularly - I've never used it)
<Unit193> Indeed, though given the question asked about the output from --help, I wondered if the wrong one was mentioned.  It's moot now I guess anyway.
<cjwatson> Yeah, perhaps
<cpaelzer> about half of the ppc64 builders seem to be stuck in "cleaning" for quite a while - anyone around to bump them?
<cjwatson> cpaelzer: I might have absent-mindedly done so earlier this morning, but they mostly seem to be building now.  (If you ask in a Launchpad channel then we're more likely to see)
<Unit193> G'morning.
<cpaelzer> thanks cjwatson
<cpaelzer> yeah they seem mostly ok now
<cjwatson> vorlon: Hey, you're TIL for vim - could you please merge it from unstable (or I will if you want)?  There's a CVE
<LocutusOfBorg> cjwatson, https://twitter.com/hashtag/vodafonedown?lang=en looks like is more half of italy having issues, not really launchpad/ubuntu/canonical domains :)
<vorlon> cjwatson: uploaded, ta
<cjwatson> Great
<tkamppeter> cyphermox, hi
<sil2100> Laney: eh, trying to approve the gst packages now
<sil2100> Most of them have both the 1.14.1 and 1.14.4 bugs in the .changes file
<sil2100> I'll be approving them anyway, will have to insta-verification-done those bugs
<sil2100> And now LP is really really slow
<hallyn> huh, expect package broken in disco?
<hallyn>  unknown system group 'messagebus' in statoverride file; the system group got removed
<hallyn> lol now i can't install dbus either.
<hallyn> oh, nm, i know what happened
<sarnold> systemd-expectd?
<Unit193> sarnold: Hrm, saw that "incompatible character encodings: ASCII-8BIT and UTF-8" again.  I wouldn't think it's because of the update, but it only started happening the day after. :3
<sarnold> Unit193: sorry, I can't recall context on that one :/
<Unit193> openssl 1.1 messing with my ruby script, not much context.
<sarnold> Unit193: hmm, can you reduce the problem to something smallish?
<Unit193> Nope.
<sarnold> dang :(
<Unit193> Hopefully I'll be able to catch it..
<wxl> for a given packageset (or if it's easier, a given package), is there a way to get notified on new uploads in either the proposed or release silos?
<Unit193> https://lists.ubuntu.com/mailman/listinfo/Eoan-changes with a good filter. :>
#ubuntu-devel 2019-06-14
<cpaelzer> xnox: should http://autopkgtest.ubuntu.com/packages/s/systemd/bionic/ppc64el be a force-badtest?
<LocutusOfBorg> hello vorlon, do you feel ola syncing today? there is a versioned dep on python-protobuf left, but meh, since all the other delta is gone... maybe we can consider sync?
<ginggs> tseliot: hi, do you have plans to backport the 430 driver to disco?
<tseliot> ginggs: yes, to both disco, and to bionic
<ginggs> tseliot: excellent!  i've been experiencing lockups on a machine with 2 x TITAN X, upgrading to 430 seems to have solved it
<tseliot> ginggs: I have it in a PPA here https://launchpad.net/~canonical-hwe-team/+archive/ubuntu/intermediate-kernel
<ginggs> tseliot: thanks, i just backported the eoan version to disco in my PPA
<tseliot> ok, well, it's the same
<juliank> jelmer: Is it expected that brz is about 2-3 times slower than bzr?
<juliank> bzr info is 0.07s user, brz info is 0.25s user
<juliank> um
<jelmer> juliank: no, that's not expected
<juliank> jelmer: Hmm, I should cProfile it
<jelmer> juliank: if you can consistently reproduce it, we'd be very interested in a bug report (with profiling details would be awesome)
<juliank> jelmer: https://bugs.launchpad.net/brz/+bug/1832868
<ubottu> Launchpad bug 1832868 in Breezy "2-3 times slower than bzr for simple things" [Undecided,New]
<juliank> oh the filename does not end in callgrind, I'm bad at reading docs
<vorlon> LocutusOfBorg: yep, sync of ola looks fine, done - thanks
<juliank> callgrind stuff does not seem helpful anyway, it shows bzr using more ticks than breezy
<juliank> despite being more than twice as fast in user time
 * juliank is confused
<xnox> juliank:  maybe try $ time bzr rocks
<xnox> juliank:  ditto brz ?
<xnox> juliank:  that should be "just startup time profiling of bzr"
<juliank> xnox: 0.093 vs 0.303
<juliank> (real)
<juliank> 0.072 vs 0.270 user time
<xnox> horum
<xnox> no idea if that is because brz has more plugins (shouldn't matter) or because it's just python3
<juliank> breezy seems to open a ton of .egg-info files
<juliank> well read the PKG-INFO of each .egg-info
<juliank> and the entry_points.txt
<cjwatson> This sounds like the sort of thing that turns out to be due to importing pkg_resources somewhere
<cjwatson> A while back I had a similar problem in LP and going around some lazr.* modules to avoid them importing pkg_resources unnecessarily was a big win, but it did involve some spelunking
<cjwatson> Ah, so breezy.plugin imports pkg_resources and bzrlib.plugin doesn't
<cjwatson> There's a faster version somewhere, let me see where I ran across it
<cjwatson> importlib_resources
<cjwatson> https://pypi.org/project/importlib_resources/
<cjwatson> Hm, but it doesn't have iter_entry_points
<cjwatson> Anyway, it's definitely almost entirely due to that - "BRZ_PLUGIN_PATH=-entrypoints brz rocks" is close to the bzr time
<vorlon> juliank: it doesn't look like you upstreamed your changes from gnutls28 3.6.7-2ubuntu3 to Debian, am I missing it somewhere?
 * juliank looks
<juliank> vorlon: Ah right, I upstreamed that to upstream git and did not follow up on it
<vorlon> ah ok
<juliank> https://gitlab.com/gnutls/gnutls/merge_requests/986
<juliank> But yes, I moved it to the test runner script, so it's probably good to upstream that part to Debian
<juliank> Not sure if this needs to be upstream upstream
<juliank> vorlon: Sent to Debian, no bug number yet
<juliank> https://bugs.debian.org/930541
<ubottu> Error: debian bug 930541 not found
<xnox> juliank:  how can i make $ apt install openssl
<xnox> juliank:  upgrade everything that came from openssl source package, rather than just the /usr/bin/* binaries.
<juliank> xnox: make openssl break the old versions?
<xnox> juliank:  sure, but like a generic apt syntax? $ apt install src:openssl => i.e. upgrade all binary packages that came from that source package? including like dbgsyms -doc -dev etc.
<xnox> for any package =)
<juliank> xnox: don't have syntax for that yet
<xnox> juliank:  it would be nice to do a wider match, when interactive, and have more exact syntax non-interactive, or something like that.
<juliank> I think it will be something like ?upgradable(?source-name-exact(openssl))
<xnox> that would work too
<juliank> xnox: I think apt should generally only upgrade entire source packages
<xnox> i do wish for $ apt install src:openssl => like install source package unpacked into like /usr/src => to be used for Built-Using stuff
<xnox> juliank:  ooooh ! yeah, especially if it can without things getting broken, otherwise hold-back and upgrade only things it can.
<juliank> Source package objects (to get all binaries of a source package) will be in apt 1.9.1 if all goes well
<juliank> and patterns hopefully too
<juliank> but I gotta write a parser and a lot of classes for them which will be annoying
<juliank> apt install source packages I do recognize makes sense
<juliank> Syntax-wise, I'd treat src as an arch and end up with openssl:src, though, I guess
<juliank> but not 100% sure
<juliank> maybe src:openssl is a name, and it's architecture is amd64 or something to have working cross-build dependency resolution
<juliank> so that apt install src:openssl:amd64 installs openssl build dependencies for building amd64 packages
<juliank> and src:openssl:ppc64el installs build dependencies for cross-compiling
<juliank> xnox: So, I'm discussing this in #debian-apt, again
<juliank> xnox: because I really want to have Build-Depends: src:pkg and apt install src:pkg
<juliank> I think the latter is easy to do compared to the former
<juliank> although, maybe not
<juliank> xnox: Also, apt install src:openssl:src to recursively install source packages for all openssl build dependencies
<juliank> :D
<xnox> heh
#ubuntu-devel 2019-06-16
<nuche> i've been really impressed with the ubuntu fork elementary os over the last several years. has there been any consideration of bringing it under the actual ubuntu umbrella?
<nuche> i've been thinking that perhaps - if not - it would be well worth looking closely at the effort and integrating a more macos centric development design effort into the ubuntu methodology.
<nuche> arguably the #1 problem of linux has been not only the severe fractionalization over the last couple decades, but also the fact that no real standardization has taken hold comprehensively and apple truly has that market cornered right now (i'm not going to debate the different ui implementations, but i've been in this industry for 40 years and i ca
<nuche> n say that bar none next/nextstep -> macos have ruled the roost as far as ui dev and well focussed innovation go)
<nuche> we truly need a serious initiative to harness this kind of focus and to spearhead it for linux that surpasses the current leadership that's pushing gnome (and even kde, although it's arguably a bit better than the gnome guys)
<alkisg> I had this idea a few years back, and I'm still wondering who would oppose to it:
<alkisg> Why can't we convince Debian to feature-freeze at the same time as Ubuntu LTS releases, and then "release when it's ready"?
<alkisg> Wouldn't this make packaging and testing and bug fixing easier, and even make more upstream developers align their release schedules to that same feature freeze date?
<tenplus1> hi folks, is anyone else having weird issues with the snap version of chromium browser after update ?
#ubuntu-devel 2020-06-08
<AlecTaylor> hi
<AlecTaylor> https://changelogs.ubuntu.com/meta-release-lts is down in my MOTD
<mwhudson> err
<mwhudson> https://launchpad.net/ubuntu/+source/sigviewer -> click latest release -> retry amd64 build in focal -> Build for superseded Source
<mwhudson> what?
<mwhudson> i retried the build in groovy i mean
<mwhudson> wgrant: can you explain this one? ^
<wgrant> mwhudson: Looks like you retried the focal builds, where it doesn't exist any more?
<wgrant> The groovys are all failed
<mwhudson> wgrant: oh right
<mwhudson> maybe i should give up on trying to be useful today
<wgrant> Aren't you off today?
<mwhudson> no
<wgrant> Or does NZ have a different fake queen's birthday from us
<wgrant> Huh
<mwhudson> the queen is a week older in nz
<wgrant> Relativity.
<xnox> because timezones
<Unit193> I thought everyone finally switched to EST.
<eoli3n_> Hi
<eoli3n_> i want to remove DM entry for gnome-wayland but its not in /usr/share/xsessions
<eoli3n_> any idea where it gets that file ?
<eoli3n_> forget it, its obvious
<eoli3n_> wayland-session
<xnox> rbasak:  was reimport of udd repositories completed? or like can it be scheduled that some of them become stable before others?
<rbasak> xnox: no, still in progress, sorry. And it's bottlenecking inefficiently so I'm working on improving parallelism to speed it up. In the meantime, yes, if you have a particular package you want reimported earlier, I can schedule that.
<xnox> rbasak:  if you could, it would be nice if these would be imported sooner:
<xnox> console-setup
<xnox> hw-detect
<xnox> localechooser
<xnox> shim-signed
<xnox> user-setup
<xnox> rbasak:  then i can refer to stable repos from ubiquity subtrees. But, no big deal if they change abis in the future again.
<rbasak> xnox: I've submitted reimport requests for those. It'll take a while due to the current performance issue.
<coreycb> seb128: can your update to software-properties 0.98.10 be uploaded? I have some cloud archive updates to make and can include it. also I think we may need to cut a stable branch.
<seb128> coreycb, yes, it's fine to upload, I just staged in the Vcs because it was not important enough to justify an upload by itself at the time, and ack for a stable serie
<coreycb> seb128: thanks, I'll take care of those bits
<seb128> coreycb, thanks!
#ubuntu-devel 2020-06-09
<mwhudson> gtest-nux-windowcompositor.cpp:143:40: error: field âwnd_threadâ has incomplete type âboost::shared_ptr<nux::WindowThread>â
<mwhudson> i don't wanna now
<mwhudson> oh just a missing #include probably
<ogra> juliank, tickle ... i'm trying something hackish over here to inject a packageproxy into an lxd container before the first "apt update" runs ... this seems to work fine for the "apt update" but the next apt comand doesnt find any packages then and i can see that sources.list was reverted when i enter the container  ... is there some special apt feature that re-sets it or am i hitting some lxd issue ?
<ogra> here is a log https://paste.ubuntu.com/p/6tVQNvMpnv/ of the container output
<juliank> ogra: you have to wait until cloud-init is done, basically
<juliank> ogra: or well, set the proxy via cloud-init
<ogra> well, i'm not aware that i'm running cloud-init at all in that container
<ogra> is that a new default ?
<juliank> ogra: I only know that the lxd images run cloud-init
<ogra> bah
<ogra> not at all what i want (and nothing in the output indicates cloud-init running)
<juliank> ogra: so you can configure your lxd profile in https://paste.ubuntu.com/p/x8Sgd7z7fv/
<juliank> s/in/like this/
<juliank> That's what I have in my default profile to configure all (Ubuntu) lxd containers to use my squid-deb-proxy
<ogra> yeah, i know how to mangle cloud-init ... i neither want it installed nor do i want it to run though ... thanks for the pointer ... i'll talk to stephane
<juliank> I understand, it causes some annoyances like these
<ogra> (i was assuming somehow that the minimal images are actually minimal ð )
<juliank> It's quite useful though, I have a dev lxd profile that automatically adds a user with my name that way (and has $HOME mounted into the container, and UID/GID mapped accordingly)
<juliank> So, yeah not sure I like or not like
<ogra> right, but i'm building an lxd based ubuntu core appliance image which means my lxd config is hardcoded in the gadget snap ... and i want to be able to define the proxy dynamically when starting a build ...
<juliank> ack
<ogra> well, changing both files fixes it ... ugly but works for my little hack for the moment
<rbasak> xnox: your requested reimiports are complete. Please keep an eye out for any apparent errors and let me know. It'd be good to spot any problem now before we declare the repos stable.
<xnox> rbasak:  thanks! on it.
<rbasak> xnox: for bug triage/cleanup purposes, are you tracking https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177?
<ubottu> Launchpad bug 1861177 in libseccomp (Ubuntu) "seccomp_rule_add is very slow" [High,Triaged]
<rbasak> Is it OK to remove any action for the server team there?
<xnox> rbasak:  no, foundations is not aware of that bug report at all.
<xnox> rbasak:  and we are not tracking it at all.
<xnox> rbasak:  security team maintains libseccomp.
<xnox> rbasak: and normal process is to use rls-gg-incoming or some such.
<xnox> rbasak:  but i advise to ping security team about it
 * xnox tags it "Public Security" they seem to react to such changes ;-)
<rbasak> OK, thanks
<xnox> (or rather change the "type" of the bug)
<rbasak> Right now the implication in the bug is that you will work on it, so you might want to deny that to make it clear ;)
<rbasak> Oh
<rbasak> Unless they mean a different Dimitri?
<xnox> rbasak:  how? why?
<rbasak> Nope I think they mean you
<rbasak> xnox: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177/comments/7
<ubottu> Launchpad bug 1861177 in libseccomp (Ubuntu) "seccomp_rule_add is very slow" [High,Triaged]
<xnox> rbasak:  there are multiple libseccomp issues inflight
<xnox> rbasak:  there is inflight backport of new seccomp
<xnox> rbasak:  it was reverted / patched / reintroduced / etc
<rbasak> Anyway, I'm just triaging here :)
<xnox> rbasak:  amurray or somesuch are dealing with it
<xnox> rbasak:  i think you should remove server-next and move on =)
<rbasak> Yep :)
<xnox> it is being worked on by the security team, and it's not "high" any more
<xnox> (there were things done to ensure it is not "high")
<xnox> rbasak:  updated status closer to reality "medium" and "inprogress"
<rbasak> Thanks!
<jdstrand> rbasak (cc amurray, xnox): a 2.4.3 SRU is in flight (by amurray), but looking at https://github.com/seccomp/libseccomp/pull/180 (the fix for the bug), https://github.com/seccomp/libseccomp/issues/187 (2.4.3 backports), and code inspection, the fix for the bug is not in 2.4.3 and will come in 2.5
<xnox> hm, right
<xnox> jdstrand:  unless we cherrypick it into groovy, and when we do the next libseccomp backport we do it then?
<jdstrand> xnox: we are not currently working on it. That could be changed via the stakeholder process
<jdstrand> it will come at some point
<jdstrand> 2.5 will have riscv64 support and we are looking to update libseccomp more refularly
<jdstrand> (we aren't doing the riscv64 stuff, but that would be nice for focal)
<jdstrand> rbasak: once 2.4.3 lands everywhere, bryce's patch should be easy enough to apply, but would need extensive testing. I suggest reaching out to joeubuntu, CC'ing amurray and myself if you want us to prioritize that
<jdstrand> rbasak: or if your team wanted to do it, we could perhaps help with testing. ie, there are options to discuss :)
<rbasak> jdstrand: I think the only reason Bryce flagged it is because it's a contributed patch and we try to prioritise those. I don't know that there's any other need to prioritise from the server team end.
<rbasak> (and I removed the flag as it doesn't look like it'd be the server team sponsoring anyway)
<jdstrand> rbasak: ack, thanks (amurray, perhaps we discuss that ^ with joeubuntu?)
<rbasak> FWIW, I don't think we'd prioritise it any more anyway even if we were sponsoring - unless the contributor was willing to take on the effort of the extensive testing,e tc.
<jdstrand> I don't think the contributor would be up for doing the testing as it relates to snap
<jdstrand> but that is good info
<kyrofa> I'm trying to understand why libceres1 isn't available on arm64. Is it because of this test failure? https://launchpad.net/ubuntu/+source/ceres-solver/1.14.0-4ubuntu1/+build/19091179
<kyrofa> Err, for focal, sorry
<kyrofa> Specifically: if I SRU a fix for that test failure, will that be enough to get libceres1 and libceres-dev on arm64 in focal?
<tumbleweed> kyrofa: yes
<kyrofa> Thanks for the confirmation tumbleweed
<ahasenack> https://code.launchpad.net/update-notifier/+git is out of sync with what's in groovy, does someone check that periodically and updates the master branch?
<ahasenack> bdmurray: specifically your groovy 3.192.31 upload isn't in https://code.launchpad.net/update-notifier/+git
<bdmurray> ahasenack: that's because somebody converted update-notifier to git without notifying the foundations team and didn't update the update-notifier project in Launchpad
<bdmurray> notifying or consulting
<ahasenack> bdmurray: I followed the Vcs-Git header, it's currently pointing at git, let me check when that was changed
<bdmurray> ahasenack: I know who the somebody was and haven't gotten around to talking to them about it
<ahasenack> bdmurray: but going forward, it's git?
<ahasenack> or tbd
<bdmurray> ahasenack: tbd as its in focal but I think the change was premature
<ahasenack> bdmurray: foundations has a meeting on thursday? This could be brought up there
<bdmurray> ahasenack: sure
<vorlon> sbeattie: hey, would it be possible for the security team to help us out with an archive search to find out if anything is still using the GetConnectionAppArmorSecurityContext bus method in dbus as of focal, to determine whether we can drop the Ubuntu delta in groovy?  (That the Security Team introduced ;-)
<tyhicks> vorlon, sbeattie: I'm pretty sure that it was only Ubuntu phone stuff that used the old method but an archive search would be a good idea
<vorlon> yeah that was also my expectation, but some of the phone stuff did get dual-purposed onto the unity desktop, so
<sbeattie> sarnold: can you take the above ^^^
<sarnold> sbeattie: yeah
<sbeattie> thanks!
<tyhicks> sarnold: to give a little background, GetConnectionAppArmorSecurityContext() was the initial attempt at allowing a dbus client to get another peer's AppArmor label
<jdstrand> sbeattie: I think we need to do more than focal when considering snapd since snaps can stage things from xenial
<jdstrand> sarnold: ^
<jdstrand> hey tyhicks :)
<tyhicks> sarnold: upstream dbus opted to go with a more generic mechanism: GetConnectionCredentials() which is documented at https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-credentials
<jdstrand> sarnold: since a snap staging something from xenial might be running on focal and expect the api
<tyhicks> hey jdstrand :)
<jdstrand> xenial dropped a lot of the unity8 stuff iirc correctly, so hopefully we are ok
<tyhicks> I'd be very surprised if xenial or newer has anything using that old method
<jdstrand> hopefully that's the case
<jdstrand> we'll know soon enought though! :)
<jdstrand> enough*
<sarnold> luckily/unluckliy, actually restricting a search to a subset of the archive is pretty difficult for me; "search everything" is my usual approach (unless we can get lucky and search only eg .c or .py or similar..)
<jdstrand> sarnold: are you using forarchive?
<sarnold> jdstrand: no.. I've never quite gotten the hang of the N layers of indirection.. (and that machine doesn't have any credentials or git trees on it at all..)
<jdstrand> sarnold: ok, cause I have some recipes for it I would've shared :) fyi, I just extracted the single tool from git and plopped it on there-- mine also doesn't have git trees, etc, etc
<sarnold> jdstrand: ooohhhh, well please do share, I'll see if I can get them to work out here :)
<jdstrand> sarnold: I'll share that with you in a bit
<sarnold> yay thanks
#ubuntu-devel 2020-06-10
<sarnold> vorlon: looks like dbus snapd deepin-notifications rust-dbus http://paste.ubuntu.com/p/9MGPZ7FXWw/
<sarnold> jdstrand: thanks for the help getting for-archive going -- it's really *crazy* faster to search just a portion of the archive, and to start from the tarballs rather than unpacked sources
<LocutusOfBorg> hello xnox, mongodb is sad due to python-yaml removed, do you still want it?
<ricotz> hello, could someone take a look at the pending "ldc" transition in resolve issues with uninstallable packages
<LocutusOfBorg> ricotz, I can do it
<ricotz> LocutusOfBorg, ty!
<rbasak> jamespage: o/ reviewing bug 1881077. Where did you get the orig tarball from?
<ubottu> bug 1881077 in openvswitch (Ubuntu Bionic) "[SRU] openvswitch 2.9.6" [Medium,Triaged] https://launchpad.net/bugs/1881077
<rbasak> There's a bunch of noise in the diff - looks like a switch to a git snapshot so missing autoconf
<rbasak> I noticed you changed the watch file
<rbasak> But that's still a .gz, and the orig tarball you uploaded is an .xz and I can't find that anywhere
<rbasak> tjaalton: are we colliding on SRU processing?
<rbasak> I just commented on bug 1871214 but only just noticed that you accepted the Focal SRU only two hours ago (but you missed Bionic and Eoan).
<ubottu> bug 1871214 in nfs-utils (Ubuntu Eoan) "[SRU] nfsd doesn't start if exports depend on mount" [Medium,In progress] https://launchpad.net/bugs/1871214
<jamespage> rbasak: hmm odd - let me check
<jamespage> I'm pretty sure I uscan'ed but can't remember specifically
<rbasak> Thanks. I don't see any specific problem but it did seem odd so I thought I'd ask in case it was unintentional.
<tjaalton> rbasak: yeah sorry, was looking at the focal queue and missed that this one was for x/b too..
<tjaalton> and e
<tjaalton> not x
<vorlon> sarnold: thanks for the analysis!
<vorlon> seb128, Laney: see sarnold's list of packages referencing the old dbus apparmor api http://paste.ubuntu.com/p/9MGPZ7FXWw/
<Laney> vorlon: nice and small
<jdstrand> that paste doesn't seem to include all releases
<jdstrand> please note my comment from yesterday that if dbus-daemon drops the api, snaps that stage-package from < groovy could break
<jdstrand> that doesn't mean to not do it, just that it is something to consider
<ackk> Hi, filed a RM request which should be quite trivial here: https://bugs.launchpad.net/ubuntu/+source/django-piston3/+bug/1882949
<ubottu> Launchpad bug 1882949 in django-piston3 (Ubuntu) "RM: remove django-piston3 / python3-django-piston3 from archive" [Undecided,New]
<LocutusOfBorg> xnox, openms sync?
<sergiodj> doko: hey, I'm updating mako and I saw you reenabled python-mako back in february in focal.  I can't find any rdepends on python-mako on groovy, so I'm considering removing the binary again.  when you can, please let me know what you think.  TIA!
<xnox> LocutusOfBorg:  mongodb should be removed from the archive
<LocutusOfBorg> xnox, care to ask for it? you seem to be the one maintaining it...
<LocutusOfBorg> btw there is a new mongodb python3 readt
#ubuntu-devel 2020-06-11
<doko> sergiodj: yes, please drop the Python2 stuff again
<santa_> rbalint: hi, I got a crash in unattended-upgrades and I think I have a patch, if you have some time I would like to discuss how to get it fixed in ubuntu
<rbalint> santa_, hi, sure, how is it crashing?
<santa_> rbalint: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1883082
<ubottu> Launchpad bug 1883082 in unattended-upgrades (Ubuntu) "Crash when using Package-Whitelist-Strict" [Undecided,New]
<santa_> just reported a min ago
<rbalint> santa_, that's fresh  :-)
<santa_> it always crashes with strict whitelist
<santa_> I think I know the cause and I have a possible patch for this
<rbalint> santa_, ok, please attach it to the bug
<santa_> sure
<rbalint> santa_, thanks, the fix seems simple and if you attach it i'm including it in the next upload + sru and give the credit since you found the fix first :-)
<santa_> rbalint: ok, that was what I was going to ask - SRU for focal; what would be the version you are going to use?
<santa_> because I'm going to build a custom package in a PPA ;)
<santa_> would be 2.3-0ubuntu0.1 ?
<santa_> 2.3-0ubuntu0.1 for focal SRU I mean
<rbalint> 2.3.0ubuntu0.1 i think, since it is a native package
<rbalint> santa_, out of curiosity why do you use strict whitelist?
<santa_> rbalint: I'm working for a company which requested this
<santa_> we used to have a home-made script to do this, but I'm rewrking the thing, if possible, with u-a
<santa_> * reworking
<santa_> rbalint: the thing needed is having just a small set of packages being upgraded automatically (firefox, openssh server, ...) and the rest manually if I'm not mistaken
<rbalint> santa_, thanks, make sense, i'd just would like to understand how u-u is being used in the wild
<santa_> sure np
<Laney> juliank: on a different note ;-)
<Laney> can you help me quickly to make https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/policy.py#L1032 work with xenial's python3-apt?
<Laney> looks like that has changed signature since
<juliank> Laney: you're backporting?
<Laney> juliank: nope, trying to run britney on snakefruit which is xenial
<juliank> Laney: The architecture option does not exist on xenial
<juliank> Laney: So I'm not sure this can be run on xenial, because that does the [...] architecture filtering
<Laney> hmm
<juliank> you might have to implement architecture wildcards yourself and pre-mangle input
<Laney> was hoping for a way to do it anyway :P
<juliank> Laney: Ah
<juliank> Laney: You can set APT::Architecture before calling it on xenail
<juliank> Laney: But like restore it afterwards
<juliank> native_arch = apt_pkg.config["APT::Architecture"]
<juliank> apt_pkg.config["APT::Architecture"] = arch
<juliank> parse_src_depends(block, False)
<juliank> apt_pkg.config["APT::Architecture"] = native_arch
<Laney> ah, that's nice if it works, let me try it
<Laney> in an except:, maybe upstream will take it
<Laney> silly ancient machines
<Laney> neat, seems to be working
<Laney> merci juliank
<paride> Hi! Groovy live-server ISO images are successfully being built for all the 4 archs: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/groovy/ubuntu-server-live
<paride> but the ppc64 image is not published here: http://cdimage.ubuntu.com/ubuntu-server/daily-live/pending/
<paride> It use to be up to May 28.
<paride> any idea of what could be wrong?
<cjwatson> https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/groovy/daily-live-20200611.log
<cjwatson> absurdly hard to read but I think the relevant error is:
<cjwatson> xorriso : FAILURE : -as mkisofs: Unsupported option '--netatalk'
<cjwatson> I think xnox was working on a xorriso upgrade at some point?
<paride> yeah I saw his branch
<paride> https://code.launchpad.net/~xnox/debian-cd/use-xorriso/+merge/384480
<paride> the date of the latest comments matches the last day ppc64 images were produced
<paride> cjwatson, thanks for pointing me to the right point in the build log. fiy this is the problem: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1883103
<ubottu> Launchpad bug 1883103 in Ubuntu CD Images "Switch to xorriso causes failure in ppc64 image generation" [Undecided,New]
<paride> xnox, vorlon, ^^
 * cjwatson nods
<xnox> tah
<xnox> cjwatson:  paride: i am in progress redoing ppc64el using cd-boot-images. I'll try to push a branch for that asap then.
<paride> xnox, which does not use --netatalk
<paride> so maybe it's not needed after all
<paride> could it be a legacy thing needed to support Apple PPC hardware?
<xnox> it is
<xnox> the new cd-boot-images for ppc64el just has a couple of files and that's it, without any magic options
<xnox> and i did test it locally and it does boot
<santa_> rbalint: I've just attached a patch for a u-a SRU, the first one was cheesy so please ignore it ;)
<santa_> I plan to use it in the next few days, let's hope it works as expected
<Laney> xnox: oh yay for submodules
 * Laney grinds teeth
<Laney> :)
<xnox> Laney:  ooooooh is that good or bad?
<Laney> xnox: hahah well I've not enjoyed using them up to now
<Laney> but still, thanks for the work
<cjwatson> Better than what was there before, probably worse than subtrees :)
 * xnox played a lot for with --prefix subtree & submodules
<Laney> did you fork all of the repos into Launchpad or something
<cjwatson> The main problem with submodules is that the UI is awful even for git
<Laney> sorry for asking instead of checking
<xnox> cjwatson:  so subtree wouldn't allow to rebase things nicely. Unless something like git-dpm to do the "rebase, but actually git merge"
<xnox> with subtree integration.
<cjwatson> And likes to sometimes leave submodules mysteriously out of date
<xnox> Laney:  cjwatson: yes, i did setup git->git for all of the d-i projects, and then added ~ubuntu-installer team repos based off that, with ubuntu delta, on top of the right debian tag.
<xnox> Laney:  cjwatson: so i can setup a "subtree" based git repo with all of those things too, I guess for evaluation.
<cjwatson> It can absolutely be handled, it's just one of those things where you need to pay closer attention than average at the client end
<cjwatson> (Also doesn't work with recipes and it's not clear how to make it work, though you may or may not care about that - see https://code.launchpad.net/~tintou/git-build-recipe/+git/git-build-recipe-1/+merge/351699)
<xnox> right, in the worst case scenario of subtree "rebase" one just removes a subtree and merges in a new one.
<bdmurray> vorlon: looking at https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status and "Things to pick from" nautilus-python has migrated right? I'm wondering how up to date this is
<vorlon> bdmurray: only as up-to-date as the last +1 maint person who updated it :)
<arnatious> I'm trying to figure out how to make this SRU: flake8 released an update supporting python3.8 only after we released focal. Should I just make the issue "This valid python code is failing <insert 3.8 language feature>, flake8 3.8 addresses this?"
<Odd_Bloke> arnatious: I'm not 100% sure I understand the question; could you explain the issue in a little more detail?
<arnatious> Yeah - the python3-flake8 package doesn't support all of python 3.8 as-is
<arnatious> Odd_Bloke flake8 released the update adding 3.8 support in early May, after we released focal.
<arnatious> We're on python3-flake8 3.7.9, PyPi has 3.8.x now. flake8 is supposed to keep minor version in sync with python
<Odd_Bloke> Aha, right, I hadn't understood you were talking about SRUing flake8 itself, thanks for the clarification!  Do you have a bug for this?
<arnatious> I'm filing one, I was wondering if saying ^ that would be enough for a bug report
<Odd_Bloke> I'm not a member of the SRU team, so I'm not the best person to be answering that specifically I'm afraid.
<RAOF> arnatious: I *am* a member of the SRU team, and https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template is a good start.
#ubuntu-devel 2020-06-12
<eoli3n_> Hi
<eoli3n_> what replace icedtea-plugin which is deprecated ?
<mason> eoli3n: Looks like there was a stable release two months ago: https://en.wikipedia.org/wiki/Icedtea
<Odd_Bloke> vorlon: We've discovered that cloud-init opens its log on xenial with the encoding set to ANSI_X3.4-1968 (presumably because we're opening it quite early in boot; it is opened as UTF-8 later in boot); this means that we will silently discard log lines that have characters that couldn't be encoded in *checks notes* 1968.  Can you think of any reason for us not to just open the log file in UTF-8 (i.e.
<Odd_Bloke> https://github.com/canonical/cloud-init/pull/427)?
<Odd_Bloke> I can't think of any reason, but locales/encoding in the first stages of boot always make me nervous. :p
<mdeslaur> I'm pretty sure I've been maintaining xenial since at least 1968
<mdeslaur> maybe it just feels like it
<ahasenack> juliank: around? (probably not, but here it goes anyway). I'm debugging a update-notifier message on trusty: https://pastebin.ubuntu.com/p/xKstpcx9WT/
<ahasenack>           # now check for security updates that are masked by a
<ahasenack>             # canidate version from another repo (-proposed or -updates)
<ahasenack> ^that is probably doing something incorrectly wrt esm security updates when esm is disabled
<ahasenack> juliank: I filed https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1883315
<ubottu> Launchpad bug 1883315 in update-notifier (Ubuntu) "Showing esm update as installable when esm is disabled" [Undecided,New]
<vorlon> Odd_Bloke: I see no reason not to open it in utf8, no
<Odd_Bloke> vorlon: Thanks!
#ubuntu-devel 2020-06-14
<rbasak> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.bionic/rdepends/command-not-found/command-not-found lists command-not-found coming as a recommends from the standard seed.
<rbasak> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/rdepends/command-not-found/command-not-found seems to have an empty entry. But the seed doesn't seem to have changed.
<rbasak> Why are these different?
<rbasak> I just upgraded a system to focal and autoremove wants to remove command-not-found-data, which seems odd. I'm trying to understand why.
<rbasak> Here's the seed entry for Focal (same as Bionic): https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/tree/standard?h=focal#n70
<rbasak> Oh. command-not-found-data is deprecated now?
<rbasak> That's fine, but I'm still puzzled by the difference in germinate output
<mwhudson> hm what actually failed here? https://launchpadlibrarian.net/484050479/buildlog_ubuntu-focal-riscv64.golang-1.14_1.14.3-2ubuntu2~20.04.1_BUILDING.txt.gz
<mwhudson> oh well i'll try again
