#ubuntu-devel 2004-11-15
<elmo> err, warty has SW RAID support in the installer, right ?
<lamont> mjg59: any thoughts on #3213?
<mjg59> With ACPI, there's no way to call DPMS code
<mjg59> Why there's a garbled screen, I'm not sure
<mjg59> Do we know if this is using the framebuffer?
<jdub> elmo: yes
<elmo> not RAID 1 root, apparently
<elmo> oh well
<amu> n8 
<thom> mdz: yeah, i'm gonna land one avec patches tomorrow morning
<carlos> jdub: is there any reason because the ubuntu-calendar-november package does not exists in hoary?
<mjg59> Hoary is a pr0n-free zone in order to prevent the developers from becoming distracted
<mjg59> They only get their pr0n fix when it's ready for release
<bob2> all they have for distractions now is frozen-bubble and mao
<mjg59> NO MAO
<carlos> :-P
* pasc still hasn't played mao
<pasc> I've managed to escape so far
<thom> pasc: heh, you shall soon learn the full power of the dark side
<pasc> heh
<pasc> I had bob2 and lifeless at my place yesterday, and _still_ managed to avoid it ;-)
<jdub> carlos: hrm, thought elmo was going to push it there too
* jdub will fix/
<carlos> jdub: thanks
<lamont> mjg59: the bug is the sum total of what I know about it.  (Actually, I fear it's the superset... :-)
<mdz> mako: ping?
<jdub> oh poo
<jdub> hrm
<jdub> how can we get u-c and u-c-monthly packages into hoary, given that they already exist in the archive?
<jdub> mjg59: http://bugme.osdl.org/show_bug.cgi?id=3670
<jdub> thom: http://primates.ximian.com/~glesage/stuff/firefox/ -> 1.02 update
<mjg59> jdub: Yeah, I've been playing with that
<mjg59> The video_post stuff seems to work pretty well
<mjg59> At the weekend, I'll build up test kernels
<jdub> garrett's theme works in 0.9.3, too
<jdub> handy
<mjg59> As is, I'm doing suspend and resume on the X40 with no kernel arguments now
<bob2> wow
<mjg59> We just reinit the video from userspace after resume
<mjg59> I'm feeling pretty good about S3 support, once we manage to figure out what the complete failure on some hardware is
* mjg59 wonders if he can convince Mark that a Sony X505VP would make a good test machine
<bob2> how's suspend looking on the craptop?
<jdub> mjg59: "yeah, this one is reaaaallly buggy"
<mjg59> bob2: Suspend is just peachy
<mjg59> Resume, now that's a different matter
<bob2> hah, right
<mjg59> I've no fucking clue. The thing just never executes any of the wakeup code.
<mjg59> Which makes debugging a complete arse
* mjg59 is at the point of wondering about printing out the ACPI spec
<mjg59> It's only 500 pages or so...
<bob2> can windows wake it up?
<mjg59> Yeah
<mjg59> Works fine with XP
<mjg59> I'm wondering about trying to write my own trivial ACPI implementation and then comparing that
<mjg59> Hmm. We ought to be able to bodge screen blanking for the console together with x86 emulation.
<mjg59> There's a routine at a known location in VBE compliant VGA Bioses
<mjg59> More fun for me at the weekend
<mojo_> morning
<mojo_> morning
<mojo_> hey
<mojo_> has AsliSolaritaire game in GNOME supported SVG yet?
<mojo_> I decide to work on a SVG version
<mako> mdz: hey there
<mako> mdz: i'm still working on the summary of the kickoff meeting.. i'm almost done.. it's SO LONG
<mdz> mako: you're telling me
<mako> mdz: i've been working on it for 2.5 hours :)
<mdz> mako: I sent you my notes, right?
<mako> mdz: yeah
<mdz> mako: I polished those notes into the HoaryGoals page
<mako> oh, ok
<mako> i will link to those
<mako> the summary will have a paragraph for most these
<mako> a lot of it can be integrated straight into the goals page
<mdz> mako: hmm, I was working on a hoary status update, sounds like we have some overlap
<mdz> mako: you can stick to the events of the meeting, and I'll flesh things out in the status update\
<mdz> if it's easier
<mako> what do you mean by events of the meeting?
<mako> as in, don
<mako> do you mean, "dont' flesh out out the feature goals so much"?
<mako> because that's what i'm doing onw
<mdz> more or less, yeah
<mdz> but if you've already done it, great
<mako> mdz: well.. i've done probably half
<mako> i've done more than half the log
<mako> mdz: i'll just continue. should be less than an hour
<mdz> I haven't written that bit of the status update yet
<mdz> so, more power to you
<mako> mdz: yeah, it will be useful to you and i was doing it anyway :)
<mako> i can throw what i have somewhere if you want
<mdz> how I'm hoping it will work is that I've created subpages for the feature goals which need more fleshing out, and the people responsible will create them
<mdz> nah, I'm on my way out
<mako> ok, sounds good
<jdub> mdz: don't want to do bug tree?
<mojo_> where is mplayer in upstream??? has lamont uploaded it yet?
<lamont> mojo_: ??
<lamont> "in upstream"??
<mako> mdz: heh.. at about 3.5 hours into the meeting, thing really start to degenerate :)
<mako> mdz: as in, your list is about as useful as the log itself :)
<mojo_> lamont: I can;t find any mplayer package!
<lamont> mojo_: it's in multiverse as of hoary
<mojo_> thx
<lamont> although it appears to be ftbfs on amd64.
<mojo_> lamont: synaptic crash immediately while loading data from multiverse
<lamont> interesting
<mojo_> lamont: bug sumitted
<mojo_> lamont: apt-get works well with multiverse but...y xmms is dep for mplayer????
<chrisa> mojo: yes, --with-xmms iirc
* lamont just builds things. :-)
<mako> does anyone want to read the hoary kickoff meeting summary and do me a huge favor in the process?
<lamont> mako: where?
<mako> lamont: i need someone to fix obvious grammar errors in the second half
<mako> i've been looking at it for almost 4 hours and my eyes are just too crossed to catch anything :)
<lamont> ok
<mako> lamont: http://people.ubuntulinux.org/~mako/
<mako> lamont: just edit the file when you find errors and send me the changed version
<mako> and thanks :)
<lamont> .rst?
<mako> lamont: it's a text file
<mako> lamont: restructured text you don't need to know RST it edit it
<mako> rst is the source
<lamont> so I should make edits in .rst. ok
<mako> yeah
<mako> lamont: i'm stepping out to buy a book
<mako> lamont: just email me
<mako> lamont: and thank you so much
<lamont> mako: OK.
<lamont> mako: sent
* lamont sleeps
<fabbione> morning guys
<fabbione> night lamont
<bob2> didn't daniels just go to bed?
<fabbione> bob2: well it's 5am here
<fabbione> it's not like i am babysitting him
<fabbione> he can go to bed when he wants :-)
<bob2> heh, I just assumed he'd been hackign with you :)
<fabbione> no
<lifeless> last message from daniels is 07:20
<lifeless> which is some time ago
<fabbione> during the night i have this insane habit to try to sleep
<lifeless> really ?
<fabbione> and i don't even succeed
<dasenjo> Hi .. how are you ?
<dasenjo> Im almost a newbie .. but I want to contribute with ubuntu .. 
<bob2> dasenjo: do you know how to maintain debian packages?
<dasenjo> bob2, a little .. 
<dasenjo> bob2, really I dont feel I can mantain XFree or the kernel ... but a web aplicattion or a perl scipt collection .. 
<dasenjo> bye.
<mojo_> I've just made the Xig DexTop CDE 3.0 work with Ubuntu, sweet!
<bob2> hehehe cde.
<mojo_> bob2: I still use CDE, Maya6 and Ubuntu for 3D works, GNOME still leak lots of my resources
<chrisa> CDE still makes my eyes bleed
<mojo_> bob2: can u pls check for me wethere there is any msg 'FATAL: udev' in your demsg??
<mojo_> chrisa: can u pls check for me wethere there is any msg 'FATAL: udev' in your demsg??
<chrisa> I don't run ubuntu
<bob2> hah
<bob2> mojo_: none
<mojo_> bob2: try 'FATAL'
<bob2> nada
<mojo_> bob2: thx, so this is not initscript bug
<mojo_> bob2: I got a msg after init process bootup, FATAL: udev is alreay mounted in /dev/
<bob2> odd
<mojo_> bob2: and FATAL: can't find bla blah kernel/hw_char thing
<bob2> nothing matching FATAL in my dmesg
<mojo_> bob2: some msg can't be caught by dmesg, I try to find someway to catch it
<bob2> there used to be /var/log/bootlog
<bob2> but I can't actually find it in ubuntu
<mojo_> same here
<mako> lamont: thank you so much for your help
<pitti> Morning!
<fabbione> mdz: ping
<fabbione> hey pitti
<pitti> Hi fabbione!
* pitti greets the X-Men
<fabbione> hehe
* sid77 'morning (it :)
<daniels> pitti: morning
<pitti> Hi daniels
<sivang> morning all
<Mithrandir> 'morning
* ChrisH yawns
<pitti> Hi mvo_ !
<mvo_> hi pitti 
<mvo_> good morning :)
<fabbione> hey Miss Vogt :P
* fabbione hides
* mvo_ slaps fabbione 
<mvo_> good morning fabbione :)
<sivang> morninig pitti !
<pitti> Hi sivang 
<seb128> hello guys
<jamesh> mvo_: were you trying to find me yesterday?
<mvo_> jamesh: yes, I wanted to ask stuff about libglade and toolbars
<jamesh> mvo_: bug 157215?
<sivang> bonjour seb128 
<mvo_> jamesh: did I reported it? then yes :)
<seb128> 'jour sivang :)
<seb128> jamesh: hey. So transparent applets will work now ! What was missing exactly before ?
<jamesh> seb128: I just changed libpanel-applet to handle background changes in an idle handler (instead of in the PropertyBag set_prop handler), and a valid background pixmap was being passed to the applet every time
<seb128> jamesh: ok, cool. You rock :)
<jamesh> whereas before it would sometimes say "I don't like this pixmap ID, so will use the default background"
<seb128> ok
<seb128> this will be nice for the GNOME 2.10 screenshots :)
<jamesh> seb128: it seems that my libpanel-applet change doesn't fix the problem, but does significantly reduce how often it occurs
<seb128> that mean that sometimes you get a transparent background and sometimes not ?
<seb128> with the same code ?
<jamesh> occasionally the background pixmap ID the panel passes to the applets seems to be invalid
<jamesh> (most likely because the panel has already deleted it and changed to something else)
<daniels> seb128: btw, the metacity-weird-spinning-cursor-with-xterm thing is reproducible here
<jamesh> in those cases, you end up with the applet will go back to the default background
<daniels> seb128: and metacity doesn't start at all per default, i need to start it from a terminal
<daniels> seb128: does the version of metacity we ship have a built-in compositing manager?
<seb128> jamesh: hum ok
<seb128> daniels: yes, metacity has a composite manager
<daniels> seb128: phat
<seb128> daniels: but the package is built without it
<seb128> Not building compositing manager by default now, must enable explicitly to get it. And it doesn't work, so don't bother unless you want to hack on it...
<seb128> Building without compositing manager
<daniels> ah, ok
<daniels> well, when it becomes useful, you'll probably want to start building it
<daniels> for the meantime, I'll just make up an xcompmgr package
<seb128> ok
<daniels> i'm interested in getting seriously wide testing on composite and seeing whether or not it's worth enabling per default (i.e. slow/buggy?)
<seb128> BTW you're the first to report a problem about metacity not starting with the session
<seb128> that's weird
<daniels> yeah, you're telling me ;)
<thom> seb128: he probably just doesn't know how to run X properly
<seb128> thom: I think so yeah
<daniels> thom: maybe it died in the arse under the load of ten thousand NetworkManager dialogs
<seb128> thom: what about the firefox-dev package ? Lot of work ?
<daniels> thom: (btw, the firefox back/forward button hackery involved hacking gdk)
<jamesh> what sort of hackey?
<daniels> jamesh: just getting it to understand back and forward key sequences and dealing with history thusly (i.e. same way as horizontal scrolling)
<daniels> (on that note, if vertical scrolling is the z-axis, what's horizontal scrolling? the  axis? the  axis?)
<thom> seb128: shouldn't be too bad
<jamesh> thom: has anyone considered asking for permission to use the official firefox branding?
<thom> jamesh: not that i'm aware of
<trukulo> fabbione, i've got here uniform of rogue, if you want it...
<fabbione> ahhaa
<daniels> i don't think anyone wants to see fabbione in that ...
<fabbione> trukulo: daniels will run away screaming
<fabbione> that's not good ;)
<azeem> LWN claims Ubuntu 4.10 supports the Pegasos-II, did somebody verify that in the meantime?
<trukulo> fabbione, daniels : are you going to Mataro ?
<trukulo> because i will go
<daniels> trukulo: both of us will be there, yah
<trukulo> i will be very pleased to see both of you dressed as rogue and jean grey
<trukulo> lol
* lilo looks in
<azeem> mako: Ubuntu traffic #9 has http://people.ubuntulinux.org/~mako/ubuntu-traffic/u20041022_09.html as URL, but it says 'Ubuntu Traffic #9 For 2004/10/2' in the title (10/2 vs. 10/22)
<trukulo> i'm not *@canonical , but i've talked with javier linares and i will go one day to talk with you
<ChrisH> Is it okay if I just edit the Wiki page HardwareSupportMachinesLaptops? I have a Toshiba Tecra 8100 and could provide some updates.
<fabbione> trukulo: you will recongnize us...
<trukulo> fabbione, if i don't, i'll ask for you
<fabbione> we will be the ones with black eyes and most injuries
<trukulo> and kamion and jdub, i think i've found jdub's pants
<trukulo> lol
<fabbione> after users will try to hunt us down
<trukulo> don't worry, at least it's better than a cake in the face
<trukulo> so seriously, i wanna go to met you, if you have time perhaps you can explain me what are you going to do in mataro
<seb128> ChrisH: yes, feel free to make changes on the wiki
<ChrisH> seb128: ok
<fabbione> trukulo: we will be probably fixing bugs on X.org & Co.
<trukulo> fabbione, will you have time for a coffe?
<Mithrandir> trukulo: nope, just beer.
<trukulo> Mithrandir, umm, i think i can sacrifice and have a beer too
<Mithrandir> :)
<daniels> iced tea is good also
<daniels> trukulo: bugsquashing, handwaving about future plans
<daniels> hacking like crazy :)
<trukulo> well, i'm not a programmer, but perhaps you need a bad BOFH there
<lilo> hmmmm....I mostly stopped by because I noticed you folks were having a conference on in the beginning of December....I wanted to make sure you let us know if you needed anything
* lilo is not sure who to talk to
<Mithrandir> lilo: jdub or mdz, I'd guess.
<lilo> kay
<lilo> also, as behind as we are on processing them, you may want to file a group contact form if you haven't already....would they be the people to talk to about that as well?
<lilo> (it'd be whoever would be considered "official contacts")
<fabbione> trukulo: we will find the time for everybody hopefully
<fabbione> trukulo: i don't make any kind of promises but i will be there for sure
<fabbione> and yes..
<fabbione> BEEEEEEEEEEEEEEEEEEEEEEER!
<fabbione> a lot :-)
<lilo> hehe
<trukulo> fabbione, lol, yes, i know that it's very difficult to talk with everybody
<trukulo> i'll kidnape you, don't worry
<Mithrandir> lilo: I guess so, yes.
<lilo> kay...thanks!
<daniels> lilo: jdub is the best point man in terms of setting up a group contact for ubuntu
<lilo> daniels: kay, sounds good
<daniels> lilo: as for the conference, we should be fine in terms of infrastructure, but thanks
<lilo> daniels: mostly I just want to make sure that if you need anything on the fly, you know to check with us
<lilo> daniels: higher user limits on some NAT IP, etc.
<daniels> yeah
<daniels> yeah, if we need higher per-IP limits, I'll ask again
<daniels> (ran into that problem in August)
<lilo> yeah, we do need to keep those pretty limited normally due to kiddie problems, the limits in turn can create issues
<lilo> I'll try to get hold of jdub about the group contact thing
<lilo> I've been noticing you guys a lot lately, you've been very busy, I wanted to touch base :)
<fabbione> lilo: don't worry too much... we might as well keep the conference on oftc
* fabbione hides
<lilo> fabbione: eek 8)
<fabbione> lilo: wouldn't be easier for you guys if we setup a local server and link from that one?
<fabbione> atleast all the conference people will not die on netsplits
<lilo> fabbione: well, we can do that if you guys want to
<lilo> fabbione: happy to set something up
<fabbione> lilo: we can take a look to it after we will know the available infrastructure setup down there
<daniels> lilo: last time we had an internal IRC server because we had a staggeringly reliable connection, but if you're happy to have us set up a leaf, we might do that
<lilo> sounds good
<fabbione> lilo: perhaps you can prepare a server config "freenode" approved for such task
<fabbione> so that we need to minimize intrusion in the netwoek
<daniels> just as long as it's not going to be taken down by someone doing OPERWALL, umode -o, or whatever
<fabbione> s/need/can
<lilo> well, usually we just request an account and set the thing up as a normal server
<lilo> then it gets routing configuration updates along with everybody else
<fabbione> lilo: well.. isn't better than someone really experienced provides us a tested configuration?
<daniels> unfortunately on an internal LAN, we'd be uncomfortable about the security issues of providing accounts
* lilo nods
<lilo> well, maybe we can work something out that will do the job
<Mithrandir> daniels: we could put it on a separate host which is only allowed to speak irc through the net.
<Mithrandir> what would the system requirements for such a system be?
<daniels> Mithrandir: p100
<fabbione> lilo: the problem is if we are behind NAT
<fabbione> lilo: we might not have control over the firewall 
<daniels> lilo: if you guys are comfortable with it, I'm quite comfortable administering dancer
<daniels> lilo: but this is all hypothetical, so we'll cross that bridge if/when we come to it
<lilo> daniels: should be doable
<Mithrandir> I can bring spare HW, and I can set up a VPN of some sort home to.
<daniels> lilo: phat
<Mithrandir> s/to//
<fabbione> seb128: if i was starting from 1 Jan 2004.. there is lifeless that prefers to jump back to year 1004 ;)
<daniels> heh, someone just pointed out http://www.google.com/search?q=ubuntu+debian to me
<seb128> fabbione: ah ah :)
<daniels> mdz: please import #251386
<seb128> pitti: here ?
<pitti> seb128: yes
<seb128> you've seen the changes in the groupes/privileges stuff in gst ?
<seb128> I don't really like the new system, you can't make manual tweaking for stuff not listed ... and you don't have the details on the list items neither
<pitti> seb128: hmm, actually I think the new design is slightly better
<seb128> pitti: BTW I don't have  #3230 here, the "gksudo users-admin" menu entry still works fine ... you sure you didn't make typo error in your password or something ?
<pitti> seb128: at least it was easy to add our plugdev/scanner groups
<pitti> yes, I tried it maybe ten times :-)
<pitti> BTW, it still worked yesterday
<pitti> but now, after a reboot, it doesn't any more
<seb128> weird weird weird
<pitti> did you reboot?
<seb128> yes
<pitti> odd
<seb128> my computer is down when I sleep
<pitti> mine too
<seb128> and I've slept this night :)
<pitti> the authentication system got even more complicated
<pitti> and I currently don't know how to set default privileges for newly created users only in the users-conf script
<seb128> gksudo works with other stuff on your box ?
<pitti> but I can't test this as long as I'm bothered with this su stuff
<pitti> btw, I also tried at the console with "sudo users-admin"
<pitti> preauthenticated, i. e. without password
<pitti> same problem
<seb128> no problem with sudo here
<seb128> I've just tried
* pitti scratches his head
* seb128 too
<pitti> The odd thing is that it worked yesterday
<pitti> but not after today's dist-upgrade...
* seb128 dist-upgrade
<seb128>   dictionaries-common libexif-dev libexif10 libraptor1 libruby1.8 lvm2
<seb128>   mysql-common ruby1.8 synaptic
<seb128> nothing that could be problematic in this imho
<seb128> still ok after the dist-upgrade ...
<seb128> you have changed your PATH or something ?
<pitti> seb128: I have 1.1.0-0ubuntu1
<pitti> not really
<seb128> ii  gnome-system-t 1.1.0-0ubuntu1 Cross-platform configuration utilities for G
<pitti> seb128: whereis users-admin is correct
<pitti> seb128: I also tried in the built source
<pitti> seb128: I try to log out and back in
<|trey|> Permission to put the Java source I use in Wiki commented out? (plus explaination)
<trukulo> |trey|, denied (lol)
<|trey|> trukulo, what? why  :(
<trukulo> it's a joke
<|trey|> 8)
<pitti> seb128: still same problem...
<trukulo> it's a wiki, do it, that's what a wiki is for
<seb128> pitti: dunno what could be wrong ....
<pitti> seb128: I dig into this.
<|trey|> (deb http://jrfonseca.dyndns.org/debian/ ./ - the source...)
<seb128> pitti: ok, let me know if you find something
<seb128> pitti: does "sudo su -c /usr/bin/time-admin" works ?
<daniels> lamont: fwiw, coreutils is ftbfs on my buildd here
<pitti> seb128: I think I know what's wrong
<seb128> oh ?
<pitti> seb128: I modified users-conf and this thing somehow does not like my debugging statements
<pitti> seb128: so, my fault :-)
<seb128> ok
* Mitario wakes up
<Mitario> hi all
<seb128> morning Mitario 
<|trey|> https://www.ubuntulinux.org/wiki/GuideToHoary Changes to Hoary sources.list ok?
<ChrisH> mjg59: I have two Toshiba notebooks. Do you need help in testing/debugging? The Tecra seems to have some trouble still (sound, power management etc.).
<mjg59> ChrisH: That would be good
<mjg59> ChrisH: I'll be building test packages at the weekend, if you're interested?
<ChrisH> mjg59: Sure.
<|trey|> Note entirely sure if I should be telling them HOW to do it?  :o
<|trey|> not*
<mjg59> ChrisH: I'll be looking at power management first, since that's the biggest issue
* |trey| is just making sure he doesn't get in trouble he thinks  :)
<ChrisH> mjg59: Right. Not being able to suspend/hiberate is a problem. :) That used to work when I had Debian on it.
<ChrisH> mjg59: I don't know if that's related. But during boot I get messages like "modprobe: FATAL: Error inserting pciehp" and "...shpchp"... :Operation not permitted
<mjg59> ChrisH: Yeah, that's unrelated
<fabbione> Mithrandir: any eta for 3032?
<fabbione> Mithrandir: if so.. would you mind to take care of 2872 too?
<mjg59> ChrisH: It's likely that under Debian you were using APM rather than acpi - if you add apm to the end of /etc/modules and boot with acpi=off things might work better
<ChrisH> mjg59: Ah. I'll try.
<ChrisH> mjg59: btw, the boot phase is delayed during ntp sync when there is no network connection. perhaps this could be improved.
<mjg59> ChrisH: Yeah, that ought to be better in Hoary
<Mithrandir> fabbione: yes, I'll take 2872 as well.
<fabbione> Mithrandir: thanks
<fabbione> Mithrandir: btw... just finished to build x.org debs for amd64 :-)
<Mithrandir> fabbione: woo :)
<fabbione> next one is ppc
<sid77> yeah
<sid77> waiting that :)
<mjg59> fabbione: When do we get the sweet, sweet crack?
<fabbione> mjg59: pretty soon
<daniels> soon enough, young jedi
<daniels> you must be patient to fully appreciate the way of the x
<daniels> padawan
<Kamion> ObiWan
<daniels> Kamion: in use, apparently
<Kamion> ah
<ObiOne> or ObiLan
<ObiOne> ;)
<mjg59> Craaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaack............
<fabbione> hey elmo
<fabbione> elmo: can i get access to a i386 hoary chroot at the dc?
<elmo> hey fabbione
<daniels> mjg59: you love the pipe
<elmo> fabbione: haven't you got i386/hoary locally?
<daniels> elmo: yes, and also DSL
<fabbione> elmo: yes i do, but i will be more happy to spare 150MB of uploads for X.org during the next days
<fabbione> elmo: since we might have to release one behind another for testing
<fabbione> like on roockery or so
<fabbione> before hitting the archive
<fabbione> one upload from here would take me ages
<fabbione> more than a remote build
<Kamion> elmo: did you see my question yesterday about "Task: ubuntu-desktop" fields for hoary?
<elmo> fabbione: meh, ok, building
<elmo> kamion: yes, but as I was leaving, one sec
<fabbione> elmo: after the first build i will need your help on ppc and amd64 to build xorg-synaptic-drivers, because it requires xorg installed in the chroot
<mjg59> ZORG
<elmo> kamion: fixed
<daniels> mjg59: BORG
<elmo> fabbione: meh, k
<daniels> (to which the logical next step is, of course ...)
<fabbione> elmo: no rush.. it's going to be either later today
<mjg59> Joerg?
<fabbione> or tomorrow
<daniels> mjg59: no, BONG
<Kamion> elmo: ta
<Kamion> should be able to build Hoary CDs now
<Kamion> actually I'm installing with one now to see how the installer works, but it doesn't have any of Desktop on it
<daniels> mjg59: JRG is two steps
<mvo_> elmo: is it possible to get changelog like http://packages.debian.org/changelogs/pool/ for ubuntu? that would be uebercool
<elmo> Kamion: is RAID1 root on the d-i TODO list?
<Kamion> elmo: should just work with the d-i sync?
<elmo> Kamion: oh, well, that means installing hoary :)
<elmo> but if it's going to be in hoary, excellent
<Kamion>     - raid1 works for root (or /boot) with raid1, of course does not with
<Kamion>       raid0. Remove the big scarey warning, though we really need a new one
<Kamion>       about raid0 and some other raid levels.
<Kamion> might force lilo rather than grub
<elmo> kamion: is it worth test installing hoary while I'm here?  I have an amd64 I'm installing anyway
<Kamion> well, I'll do a daily build once auckland picks up your Packages changes
<elmo> mvo_: that's the one with full changelog, right?
<Mithrandir> elmo: it would be nice to have the new syslinux tested.
<mvo_> elmo: yes. so that aptitude and synaptic can get them
<Kamion> elmo: don't spend too much effort on it, though, it's exceedingly rough and I'm betting myself large sums of money that base-config will be broken
<mvo_> elmo: it's not urgent of course (not at all)
<elmo> mvo_: well, reasonably happy to do - but you could set it up yourself too, if you wanted - there's a full mirror on rookery, tho it's not auto-syncing yet
<Kamion> Keybuk: would it be possible to make your merge tool handle permissions?
<elmo> Kamion: mirror's are  syncing now, fwiw
<Keybuk> Kamion: not easily
<Keybuk> they're pretty hard to spot too
<Kamion> even for new files?
<Kamion> it broke grub-installer :)
<Kamion> elmo: ok, turns out I have to wait for grub-installer to autobuild anyway
<elmo> fabbione: macaroni
<fabbione> elmo: thanks!
<fabbione> elmo: can I get ccache in the chroot please?
<fabbione> and rman
<fabbione> that should make it
<sivang> any doc people around?
<thom> dpkg-deb: building package `mozilla-firefox-dev' in `../mozilla-firefox-dev_0.99+1.0RC1-3_amd64.deb'.
<seb128> cool :)
<Mithrandir> thom: does it still crash if you type more than two characters into the search field?
<daniels> Mithrandir: wfm on i386
<Mithrandir> daniels: crashes for me on amd64 :)
<elmo> fabbione: done
<Mithrandir> daniels: but works most of the time on amd64
<daniels> hm
<Mithrandir> uhm
<Mithrandir> i386
<fabbione> elmo: thanks
<thom> Mithrandir: no, i've still never seen that crash on i386 or amd64
<daniels> ah, bong.  gcc-3.3 completes a full (slow) spin around the buildd, only to be followed immediately by gcc-3.4.
<Mithrandir> nothing like remote-healing system just by logging into them.
* |trey| asks that people that see Synaptic not being used for 'http://blah/foo ./' be changed... you just leave the last line empty, worked since early warty...
<|trey|> I changed what I could find... but don't see any more  :(
<mvo_> |trey|: apparently the synaptic repository is difficult to use for a lot of people
<|trey|> mvo_, Not enough people read the Synaptic howto I guess... but it works...
<mvo_> |trey|: I know that it works :)
<thom> um, rock.
<thom> usr/bin/ldd: line 1:   915 Segmentation fault      LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= ${RTLD} "$file"
<thom> dpkg-shlibdeps: failure: ldd on `debian/mozilla-firefox/usr/lib/mozilla-firefox/libsmime3.so' gave error exit status 1
<|trey|> mvo_, hmm, I'm just now reading it... based more on preview... more organized now... (unsupported and supported getting 2 entries, not one...
<|trey|> mvo_, how do you upload pics to the repo?
<|trey|> s/repo/wiki/
<|trey|> Just use html?
<mvo_> |trey|: haven't tried that yet
<|trey|> I really don't think Cox (my ISP would like the traffic :o)
<mvo_> sure :)
<mvo_> it is possible and should be pretty easy actually
<|trey|> mvo_, I don't see it  :(  even looking at what they did, its not clear  :(
<mvo_> |trey|: there is a small "add new item" over the header of the page and below the [contents] [view]  tabs
<|trey|> https://www.ubuntulinux.org/ubuntu/components/ Should contain Multiverse too, incomplete, I can't edit it though  :(
<carlos> latest cpufreq configuration file is broken in hoary
<carlos> -pm_type=pmu #(acpi, apm or pmu)
<carlos> +pm_type=acpi #(acpi, apm or pmu)
<mvo_> |trey|: this one is a "locked" page, I can't edit it too. 
<carlos> under PPC
<mvo_> |trey|: do you want to file a bug about it?
<|trey|> mvo_, wiki is a different site to main, bugzilla has its own, nothing for wiki, thats ok?
<mvo_> |trey|: I think ther their is "other website"
<thom> I HATE firefox
<daniels> thom: firefox doesn't require you to have sprints on the wrong side of the world
<|trey|> thom, haha, at least the RC fixed Java  8)
<thom> |trey|: it doesn't even build on amd64, so that's the least of my worries
<|trey|> thom, indeed, ouch  :(
<trukulo> jdub, r u there?
<jdub> yes
<trukulo> i've got a mascot? for ubuntu
<trukulo> http://www.benaim.org/leones%20imagenes/leon%20corbata.gif
<jdub> heh
<trukulo> you know, the animal and those things
<trukulo> or if you want something more technological
<trukulo> http://mercurio.homeip.net/blog/wp-content/leon_trek.jpg
* thom radiates hate at firefox
<thom> daniels: neither does X. you're on the right side of the world now
<daniels> thom: you say that, but you also allege that this side of the world requires me to by pan^Wtrousers in december.  what's up with that?
<thom> GAR
<thom> GAR GAR GAR GAR GAR GAR GAR
<daniels> so, like, mono
<thom> HATE
<daniels> right now I can't do a mono-aware dbus, something about main
<thom> FASCIST PIGS
<daniels> thom: here, you merge the (totally parallel-developed) modular/monolithic libX11, I'll take Firefox
* thom digs out the ICBM coords for the Mozilla foundation
<thom> hey, lets use autoconf. i hear that has good cross platform love. AND THEN LETS IGNORE IT UTTERLY FOR one library
<daniels> thom: oh dear.  which library?
<thom> the security (smime, ssl etc) libraries
<mvo_> a arch question: how can I "undo" a init-tree. I did it in the wrong dir and how it always complains
<fabbione> dpkg-deb: building package `xserver-xorg' in `../xserver-xorg_6.8.1-0.2_powerpc.deb'.
<thom> so they build that lot with CC=gcc; rather than CC=gcc-3.4
<robtaylor> fabbione: cool :)
<thom> fabbione: can i have some amd64 test love? :-)
<daniels> thom: oh man
<daniels> thom: that's wack
<fabbione> thom: you will test it for me
<daniels> thom: it's already building fine on amd64
* robtaylor feels sorry for thom
<daniels> thom: you should've used your admin supahpowahs to watch for ~fabbione:*.deb on yellow
<fabbione> we finished amd64 like 2 hours ago...
<fabbione> there is nothing on yellow anymore :-)
<thom> fabbione: give me debs then! ;-)
<daniels> *waves hand* there are no xorg amd64 debs
<daniels> thom: when firefox is fixed
<fabbione> thom: within today or tomorrow morning
<thom> daniels: screw you, hippy
<daniels> thom: wouldn't want to distract you from anything, y'know, important, with our toys :)
<daniels> thom: i respect the fact you have an important package
<daniels> thom: you were right
<thom> gimme debs or I'll misdirect you to G-A-Y rather than fabric
<fabbione> thom: there are no debs
<fabbione> i removed all of them from the buildd
<fabbione> and there is a reason for it
<daniels> thom: fabio is the evil buildmaster
<fabbione> otherwise we would have done the first drop today
<daniels> thom: i don't even have an account on yellow
<daniels> thom: i just watch this here buildd
<daniels> and do patchwork
<thom> bah :-)
<daniels> fabio just wandered out (workraved) muttering something about 'ccache' and 'bitching'
<Mithrandir> lamont: poke?
* fabbione opens a bottle of champagne
<fabbione> 2 round on ppc = success
<fabbione> now..
<pitti> fabbione: congrats!
<fabbione> all the archs all alligned
<fabbione> we need to strip the orig.tar.gz and rebuild
<sid77> YEAH
* sid77 adds another bottle ;)
<mjg59> ZORG
<daniels> BONG
<Mithrandir> mjg59: you maintain the pile that is nstx
<thom> hah. firefox has succumbed to my will
<jdub> FIGHT THE GOOD FIGHT THOM!
<Mithrandir> mjg59: can you tell me why I'm  utterly unable to get it to do what I want?
<thom> it now not only buils but doesn't segfault, either
<daniels> mjg59: mith and I are trying to convince bind9 to act as a forwarder to nstx
<jdub> daniels: rock! write a recipe!
<daniels> mjg59: so bind listens on *:53, forwards nstx.* to localhost:5353
<Mithrandir> jdub: we need to get it working first.
<daniels> jdub: working on it
<jdub> Mithrandir: excuses!
<mjg59> daniels: Rock
<mjg59> Mithrandir: Because it's a steaming pile of shit?
<Mithrandir> daniels: have you gotten it working?
<daniels> mjg59: ... any ideas? :)
<daniels> Mithrandir: no
<daniels> i wouldn't be harassing mjg59 if I hadj
<daniels> works if I specify 131.252.208.81 as the nameserver, but breaks badly using anything else
<jdub> fabbione: dude?
<Mithrandir> I can't get it working, no matter what I specify as the NS.
<jdub> fabbione: wanna help out with an ubuntu-it mailing list? :-)
<fabbione> jdub: ?
<fabbione> no
<jdub> hrm
<jdub> that wasn't the wild excitement i was expecting
<fabbione> the guy that asked the mailing list already asked me
<Mithrandir> jdub: try enrico?
<enrico> Mithrandir: yes?
<Mithrandir> enrico: ^^
<fabbione> jdub: i am not interested in being the only maintainer (or 2) following an entire mailing list.
<enrico> I'm busy in the docteam meeting now
<enrico> How can I help you later?
<jdub> fabbione: but... but... where is your national pride?
<Mithrandir> enrico: jdub wants somebody on the ubuntu-it list -- talk to him. :)
<fabbione> jdub: enotime really...
<thom> seb128: what's the magic to make epiphany build with firefox?
<seb128> thom: DEB_CONFIGURE_EXTRA_FLAGS := --with-mozilla=firefox
<seb128> in debian/rules
<mjg59> daniels: And you've hacked nstx to bind to a port other than 53?
<Mithrandir> mjg59: yes.
<Mithrandir>         type forward;
<Mithrandir>         forwarders {
<Mithrandir>         127.0.0.1 port 5353;
<Mithrandir>         };
<jdub> Mithrandir: and you've hacked it to bind only on a particular interface? :)
* enrico has no time for ubuntu-it either
<Mithrandir> jdub: nope
<jdub> enrico, fabbione: you guys! holy cow!
<daniels> mjg59: 5353, as it were
<Mithrandir> mjg59: that should really be a confiuration item
<mjg59> Mithrandir: Yes, yes it should
<thom> ephy is building
<mjg59> File a wishlist bug :)
<thom> and it looks to be using firefox
<thom> seb128: right, i'll fix up the branding and upload
<jdub> thom: rocking! rocking!
<seb128> thom: upload epiphany ?
<seb128> or firefox-dev
<seb128> or both ?
<daniels> hm
<daniels> has anyone here got nstx working with external nameservers?
<daniels> mine works just great with the same machine as the name server, but is total arse with externals
<thom> seb128: firefox
<seb128> ok
<seb128> I'll upload epiphany when mozilla-firefox-dev will be here :)
<thom> rock on
<thom> once this is done, i'll hit up the industrial theme
<jdub> the new one is surprisingly good
<thom> has it fixed the FAYT dialog?
<jdub> forget all your troubles?
<thom> find as you type
<jdub> hrm, dialog?
<thom> hit / and firefox should pop up a box at the bottom of the browser pane
<thom> (assuming you're running hoary and have a 1.0 firefox)
<jdub> oh right
<jdub> on warty box atm
<jdub> sec
<thom> oh well
<thom> downloading now to try
<thom> that'd be a big 'no'
<jdub> thom: whoa
<jdub> thom: yeah, no.
<thom> http://people.ubuntu.com/~thom/industrial-disaster.png :/
<jdub> mm, got same thing here
<jdub> BONG-O!
<thom> it also breaks the "save as" dialog
<thom> i think we'll pass for the time being
<jdub> oh man
<jdub> uuughh
<jdub> i meant to type 'dict trousers'
<jdub> instead, i typed 'apt-cache show trousers'
<bob2> pants!
<daniels> jdub: yeah
<daniels> i thought the huge mistake was that you meant to type 'trousers' in the first place
<thom> trousers: (n) what american-wannabes call pants
<daniels> watch yourself.
<lamont_r> morning
<Mithrandir> lamont_r: nstx is being mean to me.
<Mithrandir> lamont_r: and I suspect bind9 is acting up as well
<lamont_r> Mithrandir: maybe they just don't like you??? :-)
<lamont_r> what sort of "acting up"?
<Mithrandir> seems like it doesn't want to forward packets to nstx, or I'm just dumb.
<mjg59> nstx hates everyone
<mjg59> Mithrandir: It'd probably be a good idea to throw some code in to check whether packets ever get received, though
<Mithrandir> ok, what I have is roughly this:  nstx.err.no is the nstx zone, it is running on vawad, 129.241.93.49.  I'm using another host as my DNS server (129.241.7.7, but that shouldn't matter)
<Mithrandir>  dig -t ns +norecurse nstx.err.no @129.241.93.49
<Mithrandir> that will show you that err.no has a glue record for nstx set up
<Mithrandir> sudo tcpdump -i eth1 -n host 129.241.7.7 and port 53 <-- this doesn't give me _any_ packets.
<Mithrandir> which I find weird.
<Mithrandir> I guess I have a wart somewhere in my setup, but I'm unable to find it.
<daniels> elmo: ping
<elmo> daniels: what?
* lamont_r makes a note to install and configure nstx sometime
<daniels> elmo: would it be possible to get xorg-driver-synaptics built against xorg tonight or tomorrow?
<elmo> daniels: I've no idea - would it?
<fabbione> elmo: we are preparing the first X.org drop
<fabbione> but we need to build xorg-synaptic with xorg
<fabbione> that means getting a hoary chroot (amd64/ppc) updated with X.org
<fabbione> i386 is already there
<fabbione> let say in 2 hours from now, everything should be in place
<fabbione> probably earlier than that
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion and support on #ubuntu | Happy Hoary Trail! | BE THE SIGNAL | Warty release is DONE, long live Hoary | http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html | please do NOT upload ubuntu-meta
<elmo> well give me a shout when you're ready
<fabbione> elmo: i am uploading the "dfsg" sanitized tree now
<fabbione> the one i had around this afternoon was the wrong one
<fabbione> but ccache is populated everywhere
<daniels> elmo: cheers, was just checking if you would be able to do it
<fabbione> so it won't take too long
<fabbione> elmo: btw... you rock!
<nowlin> is it possible to add asus to the laptop list http://www.ubuntulinux.org/community/teams/laptop ??
<nowlin> it dosnt load the asus_acpi and the speedstep-centrino on startup
<pitti> sivang: my server's back!
<mvo_> pitti: good to hear
<pitti> mvo_: I got a standard woody system and have to recover my old stuff though
<mvo_> ohhh
<pitti> mvo_: it's still on the second (raid) disc, though :-)
<pitti> mvo_: just, the installed kernel does not support RAID and stuff...
<mdz> morning
<pitti> mvo_: NOOO! These guys messed up the IDE wiring...
<pitti> Hi mdz!
<fabbione> hey mdz
<fabbione> mdz: see topic
<daniels> morning mdz
<mdz> what's this about ubuntu-meta?
<fabbione> mdz: and please could you tell me what is the right way to modify ubuntu-meta?
<mdz> fabbione: just run ./update in the source tree
<fabbione> mdz: i am kicking X.org on the buildd for preview and i need a modified version of ubuntu-meta for people to get a proper update
<daniels> mdz: needs an update for s/xfree86/xorg/
<fabbione> mdz: ok.. but if i want to dd or change a package
<mvo_> pitti: :(
<fabbione> mdz: do i need to go trough germinate?
<mdz> fabbione: update just syncs with the seeds
<mdz> fabbione: if you just want to change it by hand, just edit the files
<daniels> mdz: so this needs to be changed on the wiki?
<daniels> 56 packages built, 746 left
<daniels> cd build && !mv
<daniels> er
<fabbione> mdz: as i wrote in my email we will have to upload a bunch of packages in sequence
<fabbione> mdz: right now i am preparing an external repo for testing
<fabbione> and if somebody overlap ubuntu-meta with mine.. the upgrade is going to be less nice
<mdz> ok
<mdz> just version it like an NMU
<fabbione> so if possible for one or two days can we avoid to upload ubuntu-meta?
<mdz> sure
<fabbione> i already builded it on 3 archs
<sivang> pitti : yeye!!!!
<sivang> pitti : long live piware.de
<thom> pitti: < infinity> thom : Has Martin Pitt been checking in all his apache1.3 changes to CVS?
<pitti> thom: I did not touch any CVS
<sivang> who is infinity ?
<pitti> thom: I draw the changes from upstream CVS, but I did nothing with any Debian cvs
<thom> pitti: yeah. can you bug mith to give you ssh access and commit them, please? :-)
<daniels> sivang: Adam Conrad, php4/apache2 co-maintainer
<sivang> daniels : thanks
<thom> Mithrandir: ^
<pitti> thom: hmm, fabbione wanted to upload 1.3.33 soon anyway; the changes are contained there
<daniels> mdz: did you get my debzilla request before?
<mdz> daniels: no
<fabbione> yup
<fabbione> guys i will prepare 1.3.33 tomorrow afternoon
<mdz> daniels: done
<daniels> mdz: thankyou
<daniels> mdz: (is pinging you on irc the best way to get this done, or should I be doing something else?)
<mdz> daniels: debzilla is basically a big hack which runs under my uid, so yeah
<daniels> mdz: ill
<mdz> it's a trivial command to import a bug, but it has to run as me, presently
<daniels> right
<fabbione>  dpkg-genchanges -B
<fabbione> dpkg-genchanges: arch-specific upload - not including arch-independent packages
<fabbione> dpkg-genchanges: binary-only upload - not including any source code
<fabbione> dpkg-buildpackage: binary only upload (no source included)
<fabbione> real    16m59.893s
<fabbione> user    9m15.854s
<fabbione> sys     3m3.155s
<fabbione> (hoary-chroot)fabbione@yellow ~/xorg-6.8.1 $ 
* fabbione HATES amd64
<pitti> fabbione: what, the whole xbuild is done in 17 minutes?
<pitti> fabbione: boy, that's fast!
<daniels> (granted, it's not building binary-all, and I suspect it may have been ccached, but still)
<pitti> sivang: they fixed the IDE wiring now :-)
<sivang> pitti : yey. seems like we're getting close to mail
<pitti> sivang: now I must not mess up anything 
<sivang> pitti  : you won't. btw, have you tried to check grub's manual for the same remote config needs you have?
<pitti> sivang: I did
<sivang> pitti : and?
<pitti> sivang: but I will stick to lilo for now, I know it better
<sivang> pitti : ok, whatever brings the server back to life :)
<elmo> fabbione: wait till I setup concordia
<elmo> tho that kind of relies on the KVM not being entirely FCUKED ahem
<fabbione> elmo: concordia? what's that?
* thom <3 amd64
<thom> sometimes
<elmo> fabbione: the new amd64 port box
<fabbione> elmo: is it faster?
<elmo> yep
<mako> mdz: http://people.ubuntulinux.org/~mako/hoary_kickoff-20041025-summary.html
<mdz> does firefox use the GNOME mime system, or something else?
<mako> mdz: ergh.. wrong title
<fabbione> dpkg-deb: building package `xlibmesa3' in `../xlibmesa3_6.8.1-0.2_i386.deb'.
<fabbione> touch stampdir/binary-arch
<fabbione>  dpkg-genchanges -b
<fabbione> dpkg-genchanges: binary-only upload - not including any source code
<fabbione> dpkg-buildpackage: binary only upload (no source included)
<fabbione> real    30m7.048s
<fabbione> user    13m56.844s
<fabbione> sys     6m45.783s
<fabbione> (hoary-chroot)fabbione@macaroni:~/xorg-6.8.1 $ 
<fabbione> damn..
<fabbione> it's only my 2 severs that are fucking slow?
<fabbione> daniels: stop leeching pr0n from them
<daniels> heh
<mdz> ARGH
<mdz> I just followed up to one of those random hoary-changes emails without noticing
<fabbione> touch stampdir/binary-arch
<fabbione>  dpkg-genchanges -B
<fabbione> dpkg-genchanges: arch-specific upload - not including arch-independent packages
<fabbione> dpkg-genchanges: binary-only upload - not including any source code
<fabbione> dpkg-buildpackage: binary only upload (no source included)
<fabbione> real    35m20.553s
<fabbione> user    18m7.915s
<fabbione> sys     6m18.721s
<fabbione> YEAH
<fabbione> and ppc is there
<mako> azeem: thanks for the traffic bug
<fabbione> time to take a snapshot
<mdz> mako: thanks
<mdz> mako: where can I link to the transcript?
<mako> mdz: it's in the same directory
<mako> mdz: or should be
<mdz> mako: thanks
<mdz> all 420k of it
* mako nods
<mako> mdz: in the future, i'd appreciate it if you had <4h meetings. i'm sure you would too :)
<mako> mdz: i'm sending out UT today so i'm not going to post it by itself
<mdz> mako: I'll announce the summary with my update
<mako> mdz: awesome
<mdz> mako: my wrists are in agreement about the meeting duration, believe me
<mdz> but the agenda for that one had been accumulating for 6 months
<sivang> mdz : you mena the last CC / TB meeting?
<daniels> mercifully it was a week or so before daylight savings, so it started at 2am, not 4am
<mdz> sivang: no, the kickoff meeting
<sivang> ah
<fabbione> elmo: are you still around?
<elmo> yes
<fabbione> cool
<elmo> I'm currently stamping a green network cable to death
<fabbione> ehehe
<thom> elmo: elbow drop it off the top of emperor
<daniels> i want videos of that.
<lamont_r> mdz around yet?
<mdz> lamont_r: yes
* mdz points back about 10 lines
<lamont_r> mdz: I don't suppose apt has a config option to override the path to sources.list, eh?
<mdz> lamont_r: of course it does
<lamont_r> kewl
* lamont_r was just finding the full config doc.
<lamont_r> Dir::Etc::SourceList=foo?
* lamont_r grumbles, realizes that way is more work, differenlty
<pitti> sivang: server is back
<pitti> sivang: it bootet from the degraded RAID, but I certainly have to reboot just one more time later
<mdz> jdub: ping?
<daniels> mdz: went to sleep an hour ago
* lamont_r goes to a parent teacher conf, and then lunch.  bbl
<thom> daniels: shame you didn't notice i'd already uploaded php4
<thom> :P
<daniels> thom: OH YOU SUCKER
<thom> like, three days ago
<daniels> thom: when did you do that?
<daniels> oh
<daniels> thanks for closing bug #3000 :P
<thom> didn't see it
<daniels> oh well
<daniels> thanks for the work, in that case :0
<daniels> :), even
<mvo_> http://people.ubuntulinux.org/~mvo/changelogs
<elmo> Kamion: ?
* daniels -> food, stuff
* fabbione goes away to use his ticket to Mars
<fabbione> (one way ticket)
<fabbione> thom: you got the debs
<fabbione> CYA!
<thom> OMFG people are FICK.
<daniels> thom: ...
<thom> ..."ask if we can modify httpd.conf" THAT'S WHAT CONF.D IS FOR CRETIN
<daniels> thom: what? who said that?
<azeem> FICK?
<azeem> thom: did you shout, or was that some cool acronym I didn't know about?
<thom> azeem: a stupid person saying thick
<thom> works best in a northern british access
<thom> uh, accent
<daniels> thom: you already said 'stupid' ;)
<thom> daniels: it's in the backuppc changelog
<azeem> thom: it's 'fuck' in german, so I wondered
<daniels> thom: oh dear
<azeem> or at least roughly
<daniels> wow, gdb is big
<thom> azeem: heh
<daniels> thom: i would have to say the most under-utilised feature of apache/a2's configuration handling has been sites-*
<daniels> thom: mods-* seems to have worked well, but most people seem to have ignored the host stuff
<thom> daniels: to some extent
<mdz> pitti: here?
<daniels> thom: even worse, the backuppc stuff was for a *module*
<pitti> mdz: yes
<daniels> thom: i.e. mods-* and a2enmod
<daniels> thom: which to some extent?
<mdz> pitti: do you know what happened with aptitude's su->sudo changes being lost?
<pitti> mdz: currently repairing my remote server
<mdz> pitti: was it a problem with the automated process or the manual process?
<thom> daniels: yeah
<pitti> mdz: I just repaired it today
<pitti> mdz: I can't really say
<pitti> mdz: I used the merged diff as basis and I thought I got every diff from there
<mdz> I'm sure Keybuk would like to know about it if it was dropped by his tools
<pitti> mdz: missing these changes would have been not easy, it touches a hell of a lot of files
<pitti> mdz: nevertheless it might be possible that I missed it 
<daniels> thom: which part of it was 'to some extent'?
<thom> daniels: oh, some people seem to use sites-*, but it's not really visible to us because packages in general don't
<daniels> right, point
<daniels> i suppose also it's not really a general use thing
<daniels> i suspect my plans for vhost-base were aiming to a vastly wider audience than it was ever going to get
<thom> yeah
<daniels> ho hum
<mdz> pitti: hmm, the changes seem to be present in the 0.2.15.8-1ubuntu1 in ~scott/merged/
<pitti> mdz: then I probably just forgot about them
<pitti> mdz: ah, now I remember. The merged package was a mess
<pitti> mdz: so I took the Debian package and applied the Warty changes
<pitti> mdz: btw, the old patches did not work any more anyway
<mdz> pitti: ah, ok
<pitti> mdz: I rewrote the sudo support today, now it's working perfectly again
<mdz> pitti: we should probably add a config variable for the gain-root program
<mdz> so it can go upstream
<pitti> mdz: I can add that
<mdz> elmo: are we supposed to get mail from katie about warty-security uploads?
<elmo> mdz: no
<elmo> mail is sent at unchecked -> queue/accepted time; obviously that's not an option
<mdz> elmo: I mean in the same way that we do in Debian
<mdz> an Accepted mail goes out for the sourceful upload
<elmo> to the maintainer - the trick on security.d.o is that ALL mail is overriden to team@s.d.o
<lupus_> someone from europe here?
<mdz> can we do the same for warty?
<fabbione> lupus_: yes
<lupus_> can someone conform that winter time is not autoset ?
<thom> fabbione: shouldn't you be out getting drunk
<elmo> dude, it's not a separate archive, if I add GlobalOverrideEmail, you'll get ALL the accepted mail, including hoary etc. :P
<fabbione> lupus_: it was here
<thom> lupus_: it autoset fine for me
<pitti> lupus_: works fine for me
<elmo> I can TODO doing a per-suite GlobalOverride, if you like
<mdz> elmo: oh, you meant _ALL_ mail
<fabbione> thom: waiting for my gf to finish her phone call
<thom> ah
<mdz> elmo: yeah, we need to know when something is uploaded to that queue
<fabbione> that means something between tomorrow and forever
<thom> heh
<thom> pour alcohol on the phone
<fabbione> no way
<fabbione> that will take down my adsl
<thom> heh
<lupus_> how can I see in which package a certain package is
<daniels> dpkg -S
<lupus_> I mean file :)
<azeem> daniels: that only works for files ;)
<fabbione> lupus_: these questions are more appropriate for #ubuntu
<fabbione> this is a developer channels
<fabbione> to discuss development
<lupus_> yes fabbione  I know sorry :)
<daniels> the phone is, apparently, unoccupied at the present moment
<lupus_> run :p
* thom wishes x was smaller
<thom> you guyys suck, make my X smaller
<elmo> thom: that would be a world-tour marathon, not a sprint
<daniels> thom: dude, 5-13, London weather is pissy
<daniels> thom: at least it doesn't fall over every time you upgrade it
<thom> daniels: it was a bracing 12C today
<thom> and sunny and nice
<daniels> thom: it was colder in cph, and I was out for a jog in my singlet and shorts
<daniels> it was lovely
<daniels> you're just weak.  you should try maintaining a Real Package like X, because apparently that toughens you up.
<daniels> anyway, it's time for food in this lovely city.  'nacht'
<thom> no thanks, i'm not maintaining anything that you've massacred again :-)
<thom> night
<daniels> and it's OK, I didn't really mean it.  except the bit about Firefox dying horribly every time you upgrade it.
<daniels> fix that.  yesterday.
<azeem> "our fellow Ubuntista" <- is that the official denotation?
<lupus_> k maybe a dumb idea
<lupus_> but what about screenshots of the apps in aptitude
<azeem> apps in aptitude?
<azeem> you mean tetris?
<thom> YM synaptic
<lupus_> idd synaptic
<thom> and, that would be fairly not trivial to do
<azeem> ah, minesweeper it is
<daniels> s/massacred/improved/
<daniels> not my fault you can't appreciate DBS
<lupus_> sorry I'm mixing names :s
<thom> i appreciate dbs and cdbs equally
<seb128> cdbs
<seb128> cdbs rocks :)
<thom> it rocks as much as DBS, yes
<azeem> cdbs2 is written in shell as well, so it should rock twice as much!
<seb128> :)
<thom> rocking twice as much as nothing is, let me think, still nothing! ;-)
<azeem> depends on your numerical accuracy :)
<azeem> at least some bits are rocking during the execution, so it *will* be > 0, q.e.d.
* thom had a firefly quote in mind for that
* jbailey scrolls back
<jbailey> Oh lovely, It's not serious cdbs flamage.  /me fades away again.
* thom grins at jbailey
<thom> merely a pet whine 
<jbailey> thom: Aside from applying rm -rf to the source tree and providing documentation, is there anything I can do to make it better for you?
<thom> jbailey: i dislike the concept more than the implementation, tbh
<azeem> thom: yeah, code resuse sucks
<azeem> eh, reuse
<jbailey> thom: Fair enough.  Given that people seem to like it (and so you're probably stuck with it), if it can be made easier for you, lemme know. =)
<thom> jbailey: my main problem is trying to debug other people packages with it
<thom> so a nice way to find out exactly what is happening (or documenting such a thing if it exists) would probably make me much happier
<jbailey> thom: What type of information would be most helpful - the stages that it's passing through?  I've added a couple debug modes to cdbsv2 that do an 'set -x' in cdbs so you can see each command as it's executed.
<thom> seeing each command would be great
<seb128> jbailey: what's really missing in cdbs1 is a multi-build :p
* jbailey pats sb on the head.
<jbailey> Yes, dear.
<seb128> that and a complete descriptions of the variables available and the build steps
<jbailey> Yeah, that's a bit suboptimal.  I do have that in the new stuff, though.
<jbailey> 'debian/rules help' will be your friend. =)
<seb128> ie: you want to move some file after the binary install and before the dh_strip, no easy to find what to add
<seb128> yeah, I was speaking about the v1
<jbailey> Yar, you're evil.
<seb128> I'm sure the new one will rock even more :)
<jbailey> food time.
<seb128> have a good lunch :)
* thom -> Rome: Total War
* pitti is happy again, his server is brought back to life :-)
<thom> well, Xorg hasn't broken yet
<sjoerd> pitti: did you have time for pmount stuff, or still swamped in other work ? :)
<pitti> sjoerd: I already implemented the --async/-a option
<sjoerd> nice
<pitti> sjoerd: the -t option (force file system) is implemented, but not yet tested
<pitti> sjoerd: I had to repair my server today
<pitti> sjoerd: for -t I restructured the code, now it looks really better
<pitti> sjoerd: the last problem is the uid checking
<pitti> sjoerd: now the uid checking works well for VFAT, hfs, iso9660, udf, etc.
<pitti> sjoerd: but it does not work for file systems which don't support uid/gid options
<pitti> sjoerd: because pmount then cannot tell which user mounted it
<pitti> sjoerd: by now all users are allowed to pumount such devices if they are mounted in /media
<pitti> sjoerd: there's no trivial solution
<pitti> sjoerd: or do you have an idea how to accomplish this without an additional state file?
<sjoerd> not offhand no
<pitti> sjoerd: anyway, since that is no real regression, I will test the -t stuff now and release it
<sjoerd> cool
<pitti> sjoerd: but before, I just HAVE to try out X.org, sorry :-)
<sjoerd> haha
* sjoerd guesses nobody tried them on a debian system :)
<Mitario> hmm, are there x.org packages for ubuntu already available? I tought I heard something like it
<daniels> good lord, I think I just ate an entire cow
<daniels> I am *so* *full*.  and definitely not coming back online tonight.  'night all.
<daniels> thom: ill!
<daniels> Mitario: not for general consumption yet as there are still no doubt many very bad bugs to work through, but look for an announcement from fabbione and I very, very soon :)
<daniels> bah.
<sjoerd> hehe
<pitti> daniels: night!
<pitti> daniels: happy digesting! :-)
<amu> oo xorg
<amu> daniels: you need some feedback for ppc-port ? 
<daniels> amu: always
<pitti> sjoerd: -t support works fine :-)
<sjoerd> pitti: woohoo :)
<pitti> sjoerd: anything else you'd like to see?
<sjoerd> pitti: not executable for everyone in the debian package :)
<pitti> sjoerd: the packaging already supports that
<pitti> sjoerd: it's a mere variable change in the postinst
<sjoerd> i know/saw
<pitti> sjoerd: but which group to use?
<pitti> sjoerd: I didn't find time yet to ask on d-devel
<sjoerd> dunno.. you were going to send a mail remember ;)
* pitti is still going...
<sjoerd> ah
<pitti> I'll do
<pitti> sjoerd: BTW, are you interested in doing a source code audit?
<pitti> sjoerd: mdz digged though a very early version, but almost everything changed since then
<sjoerd> pitti: if you have the source available, i can probably find some time to dig through it
<pitti> sjoerd: I'll upload it to Hoary and sid soon
<sjoerd> k
<sjoerd> i'm packaging hal 0.4.1, do you have stuff pending for it ?
<pitti> not really
<pitti> I read the announcement though
<pitti> sjoerd: BTW, any plans to put it into Sarge?
<pitti> sjoerd: it has run fine for some weeks now
<sjoerd> same here
<sjoerd> i'm planning to upload this package to sid 
<pitti> nice 
<pitti> brb (hopefully)
<pitti> fabbione, daniels: congrats! Neither the upgrade, nor the restart showed any flaw!
<pitti> fabbione, daniels: YOU ROCK!!!
<sjoerd> would be interesting to know if xorg works on a albook, never got my selfcompiled version working..
<sjoerd> pitti: #279395 is pending for hal currently, which i would like to have fixed..
<sjoerd> stupid vendors.. ging different devices the same usb id's
<Mitario> back
<Mitario> daniels, ok, thanks, i'll look forward to the announcement :)
<seb128> elmo: any way to get a sync for libgda2 1.1.99 (experimental) and libgnomedb 1.1.99 (experimental too) ?
<elmo> seb128: done
<mbb> bugzilla question - 'Assign To:' defaults to amu@tr.debian.net - should I leave that alone, change to debzilla, or ??
<seb128> elmo: thanks
<seb128> mbb: leave it
<seb128> mbb: the assign to is set according to the component you have selected
<Kamion> elmo: yes? (sorry for delay)
<elmo> Kamion: not to worry :)
<elmo> was going to ask about the netboot stuff, but I just reported a bug instead
<flax07> hi there - there seems to be a known problem with install on dell c600 - to do with DMA on cdrom - can anyone advise if there is a way around to install?
<Kamion> elmo: mmkay, ta
* lamont returns home with a G3.  Kamion: this should just boot and work from the warty CD, yes?
<seb128> oh, a guy mailed the ubuntu-fr list with a problem with a G3 today
<seb128> he get this on the boot with warty:
<seb128> pivot_root: No such file or dirctory
<seb128> /sbin/init: 429: cannot open dev/console:
<seb128> kernel panic: attempted to kill init!
<seb128> 
<seb128> is that known ?
<mjg59> lamont: As long as it's not a beige one, yeah
<Kamion> lamont: what mjg59 said; if it's a blue-and-white or later you should be fine
<Kamion> (modulo picky hardware detection nonsense)
<lamont> guess it's blue.. looked more green/teal to me.
<Kamion> seb128: that means that the initrd failed to figure out where the root filesystem is; he should file a bug on probably initrd-tools with as much information about the modules he needs to make his disks go and the filesystem he's using as possible
<mjg59> lamont: That's what I think, but...
<Kamion> lamont: there were various coloured models post-B&W
<seb128> Kamion: ok, thanks
<mjg59> Kamion: Not G3s, though
<Kamion> lamont: sounds like newworld to me, anyway
<Kamion> mjg59: you sure?
<mjg59> Kamion: There were other colours in the iMac range - I don't think the G3 changed
<Kamion> some iMac G3s were green, saith google
* lamont goes to fetch and confirm the blue-green debate.
<mjg59> Kamion: In Mac-speak, G3 usually means the non-iMac G3
<mjg59> (yes, this is crack)
<lamont> hrm.  aqua, lets call it.
<Kamion> mjg59: yeah, I know, but (a) lamont didn't specify iMac and (b) I have no reason to believe he's deeply steeped in Mac terminology :)
<mjg59> Are the ZORG packages available for general testing, or still just internal?
<thom> you could just specify !beige
<mjg59> thom: That's what I did
<mjg59> Aww, man
<thom> ah, so you did
<mjg59> Half an hour to download Hoary packages
<elmo> all your bandwidth...
<thom> X crack is still interneal only
<lamont> Kamion: make that "lamont is known to be very shallow in his mac terminology", and you're closer to correct.
<mjg59> Would be an hour if I hadn't upgraded the ADSL
<mjg59> Yay ADSL
* Mithrandir thinks it is a very stupid idea to build qt on his laptop
<mjg59> Do we have 2.6.9 yet?
<Kamion> no
<mjg59> Bugger
<mjg59> That's going to make life harder
<Kamion> dunno what the plans are there, mdz's probably in sufficiently close contact with herbert to know
<mdz> which particular bit of life?
<Kamion> (lo, speak of the devil and he shall appear)
<mjg59> mdz: I want to produce test kernels for power management. 2.6.9 is the most realistic starting point.
<mjg59> (Alternatively, I backport all the 2.6.9 PM stuff to 2.6.8...)
<thom> Kamion: ah, that explains the walking up walls
* Kamion thanks $DEITY for cdrom-checker
<mjg59> Are there any Warty kernel patches that are /required/ ?
<Kamion> mdz: replied to #2432, btw
<mdz> mjg59: required in order for the rest of warty to be happy?
<mdz> if so, nothing that will cause horrible breakage
<seb128> Kamion: the guy who has the G3 problem says that somebody else fixed the issue by building the kernel with "CMD64{3|6|8|9} chipset support" 
<mjg59> mdz: Yeah. Ok, that makes life easier. I can just drop 2.6.9 in with the Warty config, then.
<Kamion> seb128: reports from somebody else are rarely reliable here, since there are a number of ways that symptom can occur
<Kamion> seb128: he can certainly try it though
<lamont> mdz: was planning to bootstrap sbcl sometime soon, but working on component isolation first.
<seb128> Kamion: ok
<mdz> lamont: ok, please follow up to the list so they know that the request is pending, rather than ignored
<lamont> mdz: replied
<mdz> thanks
<amu> hmm, xorg doesnt work on my ppc :(
<thom> AAAARGH, FIREFOX YOU SUCK
<pitti> amu: on my iBook it runs fine
<amu> pitti: i tried with ati,vesa,fb 
<pitti> amu: it autodetected ati for me (Radeon 9200)
* lamont hands thom a shotguin
<amu> pitti: did your run changes after the reconfigure ? 
<lamont> shotgun, even
* thom radiates massive HATE
<pitti> amu: "run changes"? Whatever, I just upgraded the packages and restarted gdm.
<Mithrandir> thom: still playing with firefox?
* pitti hands thom a giant water gun
<thom> Mithrandir: yes
<thom> Mithrandir: ldd segfaults :/
<Mithrandir> thom: _ew_
<Mithrandir> how does it manage to do that?
<Mithrandir> that requires _skillz_.
<Kamion> holy shit, base-config/hoary didn't totally break
<Kamion> although Desktop is uninstallable, predictably
<Mitario> seb128, here?
<Kamion> uh, just a mild query
<Kamion> why the HELL does http://people.ubuntulinux.org/~cjwatson/testing/warty_probs.html have ANYTHING in it?
<thom> Mithrandir: scary huh
<thom> Mithrandir: ldd on /usr/lib/mozilla-firefox/libsmime3.so
<thom> the same version is fine here
<mjg59> What's the name of the package used for building kernel debs?
<mjg59> As in, the source for the actual debs, not kernel-package
<lamont> elmo about?
<Kamion> mjg59: linux-source-2.6.8.1
<thom> linux-image-2.6.8.1
<mjg59> thom: linux-image doesn't seem to exist?
<Kamion> elmo: can you pull librasqal0 and librasqal0-dev into hoary, please?
<Kamion> mjg59: no, it's definitely linux-source-2.6.8.1
<mjg59> Oh, no, it's part of linux-source
<mjg59> Kamion: Thanks
<thom> sorry, too used to just trusting apt-get source ;-)
<Kamion> we don't do the "one source package for each architecture" thing
<thom> Mithrandir: and the build looks the same, so goddess knows
<mjg59> Hurrah for having a cable modem to download stuff with when I'm swamping the ADSL
<Kamion> libgnomevfs2-common and libwvstreams3-base need to switch dependencies from libfam to libgamin
<Kamion> that's the other reason Desktop is uninstallable at the moment
<thom> Mithrandir: can you grab the firefox source from hoary and see if it builds for you if you have a moment?
<Mithrandir> thom: sure, any particular platform?
<seb128> Kamion: ok, I'll fix libgnomevfs2-common
<Kamion> ta
* Kamion goes back to hide in bed :-/
<thom> Mithrandir: just amd64
<thom> Mithrandir: other two built fine
<thom> and i have amd64 binaries from that source locally, so i dunno what's going on
<thom> hrm, crested got the segfault on rc1-3, and king on rc1-3ubuntu1, so it's not the machine. ber
<Mithrandir> freshening chroot
<Mithrandir> thom: what's the estimated build time?
<thom> 30 minutes or so
<Mithrandir> ok
<mdz> Kamion: rest up and get well
<sjoerd> pitti: hmm if the user is running the right locale it can ofcourse..
<pitti> sjoerd: I did not yet know that VFAT and NTFS always use Unicode
<pitti> sjoerd: but that's actually nice :-)
<sjoerd> pitti: do they, the guy i'm talking to says that he needs to specify iocharset=utf8
<pitti> sjoerd: from mount(8): Character set to use for converting between 8 bit characters and 16 bit Unicode characters. The default is iso88591.  Long filenames are stored on disk  in  Unicode format.
<pitti> sjoerd: so this means that the default is wrong for him
<sjoerd> oh but their converted to latin..
<pitti> sjoerd: great, I just wanted to try that out and how hal 'D's again...
<sjoerd> hehe
* pitti grabs a floppy
<pitti> sjoerd: hmm, I use de_DE.UTF-8 as locale, and umlauts work fine as filenames... How can I test that?
<carlos> seb128: new metacity does "funny" things when executing a OO presentation with full screen option
<carlos> seb128: the panel is there always althought it's hide partially by the presentation
<sjoerd> pitti: also in long filenames ?
<pitti> sjoerd: right, I forgot
<sjoerd> pitti: and you can try to write with iocharset=utf-8 and then remount with default iocharset
<thom> carlos: looks fine here
<seb128> carlos: are you sure that's the new metacity ? no problem here
<carlos> seb128: I think it's metacity, because it handles that, right?
<carlos> hmm
<carlos> let me recheck it...
<carlos> seb128: ok, the problem seems to be the initial focus
<carlos> seb128: the panel has the main focus until I click over the presentation
<carlos> then, the panel is hiden
<seb128> ok, so that's an openoffice.org problem
<seb128> with the new focus stealing preventient mode in metacity the apps need to update their timestamp
<Mithrandir> argh, I broke my power plug.  Again.
<carlos> seb128: do you want a bug report ?
<thom> Mithrandir: d'oh :(
<thom> how did firefuck go?
<seb128> carlos: no time for openoffice sorry, find somebody else. I've a lot to do with GNOME without starting with openoffice ...
<carlos> seb128: I'm asking about a bug report in bugzilla :-)
<carlos> no to fix it now
<seb128> carlos: yes, but not assigned to me
<Mithrandir> thom: /usr/bin/ldd: line 1: 24504 Segmentation fault      LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= ${RTLD} "$file"
<Mithrandir> dpkg-shlibdeps: failure: ldd on `debian/mozilla-firefox/usr/lib/mozilla-firefox/libsmime3.so' gave error exit status 1
<carlos> seb128: don't worry, I use always the default value unless someone tells me other thing
<thom> huh
<Mithrandir> I can't get it to sigsegv by hand, though
<thom> so wtf is dh_shlibdeps up to then?
<Mithrandir> it just calls dpkg-shlibdeps, isn't it?
<thom> yep
<Mithrandir> well, calling that by hand doesn't fail
<mdz> Mithrandir: repeatable?
<thom> mdz: the buildds are doing the same
<Mithrandir> mdz: the buildds and my hoary chroot makes it fall over.
<Mithrandir> might be a chroot issue -- I can test when I get home.
<thom> it built fine for me
<Mithrandir> (my home box is powered off)
<thom> but i'm just freshening a chroot to try it
<mdz> so it blows up when building with dpkg-buildpackage, but not when you run dh_shlibdeps by hand?
<Mithrandir> correct
<mdz> fascinating
<lifeless> spock!
* mdz raises one eyebrow
<mjg59> Hrngh.
* mjg59 almost gets things into a state where he can build them
<mdz> Keybuk: around?
<mdz> mjg59: kernel?
<Keybuk> mdz: yup, briefly
<mdz> Keybuk: wanted to talk with you about ongoing merges for hoary, and how we should manage them
<Keybuk> didn't we talk about that on Tuesday?
<elmo> Kamion: done
<elmo> lamont: am now
<mjg59> mdz: Yeah
<Keybuk> mdz: will be back in an hour or so
<mdz> Keybuk: we didn't get into specifics, did we?
<thom> mdz: hardware database meeting? (we could just do it in LA whilst i'm there)
<mdz> Keybuk: you said you would work on it.  are there no unresolved questions?
<Keybuk> yeah, I'm cooking up a script that takes the "what needs merging" output, does the 3-way diff on it, and files a bug to say it needs checking and uploading
<Keybuk> none that I know of
<mdz> thom: when's that?
<thom> mdz: 11-23
<thom> of nov
<mdz> I'm going to be away during some piece of that, but not all
<mdz> Keybuk: what will you do with packages where a bug is already filed?
<thom> well, i'm in vegas from the 12th to the 17th actually
<mdz> ah, that's better then
<Keybuk> mdz: your debzilla stuff looked like it allows you to add a comment to a bug ... I was going to do that and add a "dude, you're SO SLOW" type comment to it
<mdz> Keybuk: what it doesn't have is a useful query interface to find a bug
<mdz> except by alias
<mdz> though, come to think of it, that's probably exactly what you want anyway
<Keybuk> *nods*
<mdz> alias merge-<source package> or such
<mdz> with a nice database constraint to prevent any accidents
<mdz> Keybuk: ok, I think we're sorted, then, thanks
<Keybuk> kewl
* Keybuk runs off for a bit
<mjg59> I am disappointed that Hoary has not provided me with huge amounts of crack
<thom> oh, just wait :-)
<seb128> thooooooooom
<seb128> thom: you broke the typeahead in my epiphany :p
<lamont> elmo: just deployed the ogre-model sources.lists hack on the buildds.  it should be happy, but please feel free to squawk/beat me if you see anything amiss.
<seb128> thom: need to build firebox with the "typeaheadfind" in the mozconfig
* thom giggles at seb128
<thom> no way dude
<thom> that breaks type ahead find on firefox
<seb128> ok, so switching back to mozilla
<thom> d'oh :/
<seb128> I can't use a browser without a typeahead
<elmo> lamont: neato
<seb128> and I probably not alone
<seb128> +'m
<thom> seb128: indeed
<thom> i got a metric fuckload of bugs when it broke on firefox
<seb128> thom: why enabling "typeaheadfind" breaks the typeahead in firefox ?
<thom> because mozilla sucks
<thom> seb128: they moved from the typeaheadfind extension to FAYT, and if you enable typeaheadfind, it breaks FAYT, but doesn't work itself
<lamont> elmo: what that means, oh archive god, is that all of the unknown section packages that aren't really main will FTBFS now.
<mdz> mjg59: crack should be inbound quite soon
<lamont> mdz: and that means that sbcl is now ready to bootstrap... but first a short break while I panic and go get the kids...
<mdz> lamont: cool
<mdz> do we have any means to test whether build-depends are satisfiable in main, other than trying to build everything?
<mjg59> Argh.
<mjg59> If I do EXPORT_SYMBOL() on something, why would I get undefined reference in... oh, christ, I'm an idiot
* mjg59 goes to hack the configs
<elmo> fuck's sake, how do I unbind C-l in xchat?
<elmo> lamont: blah, sucks
<chrisa> damn
<chrisa> I pressed C-l out of curiosity
<cenerentola> hi there
<mjg59> It links!
<cenerentola> got a big problme
<mjg59> What's the hoary-updates list?
<cenerentola> i did an update&&upgrade under warty...
<mdz> elmo: probably the same way you change other keybindings in xchat: modify the hardcoded values in the source
<mdz> but who presses C-i anyway?
<thom> mjg59: hoary-changes@lists.ubuntu.com
<cenerentola> and when the shell appeared... it started printing things like "dpkg could not...
<cenerentola> "
<cenerentola> and gnome collapsed
<mjg59> thom: Ta
<thom> GAR, stupid firefox just built ok in a chroot for me
<mjg59> Ooh, update-manager exists
* mjg59 lunges for the crack
<jdub> mdz: pong
<jdub> morning all!
<seb128> hello jdub 
<jdub> yo seb128 
<mdz> jdub: I still need for you to update the hoary goals page with the status of your bounty candidates
<pitti> Hi jdub!
<jdub> mdz: ok
<mdz> some of those are "will be done as a bounty, have someone lined up" and others are "bounty, need to find someone", and we need to differentiate them
<seb128> jdub: I've uploaded epiphany/firefox, but I'll probably upload epiphany/mozilla again soon so hurry up if you want to test the firefox one :)
<jdub> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=154034
<jdub> woo :)
<jdub> seb128: oh? it's not good?
<mjg59> The craptop makes nasty noises when I log out
<seb128> jdub: no typeahead at all ... 
<mdz> cenerentola: /topic
<cenerentola> mdz: so?
<mdz> cenerentola: #ubuntu is the place for support
<seb128> jdub: need "typeaheadfind" in firefox, which breaks firefox according to thom ... and using a browser without a typeahead is a pain
<cenerentola> they can't help me
<seb128> jdub: so I guess I'll switch back time to find a solution
<jdub> seb128: i think that's fairly reasonable as a development branch bug
<jdub> seb128: if we work around bugs all the time, no one will want to fix them :)
<mjg59> update-manager looks really, really lovely
<mjg59> Is there a notification applet for it yet?
<mdz> mjg59: upgrade-notifier
<mdz> they aren't quite integrated with each other, yet
<seb128> jdub: so we need to fix it NOW :)
<cenerentola> mdz: i cant get you... have got a broken OS... i need all it up & running and all u can say its: not the right place?
<seb128> jdub: I didn't notice I use the typeahead that much before
<cenerentola> i wouldnt ask here if id not this big big big problem
<seb128> but without it, arrrg
<pitti> mdz: the shadow vulnerability just appeared on full-disclosure
<jdub> seb128: ... welcome to hoary. :-)
<seb128> ah ah
<pitti> mdz: so I could upload now
<mdz> pitti: go ahead
<cenerentola> mdz: and remember that YOUR update&&upgrade broke iot
<cenerentola> ...it
<mdz> cenerentola: I sympathise with your predicament, but the fact that you couldn't get help elsewhere is not a reason to bring your problem to a place where it is off-topic
<seb128> jdub: BTW cool for #154034 :)
<mdz> cenerentola: believe me, if upgrading warty was the cause, there would be a large number of users with the same problem
<mjg59> Oh, rocking
<mjg59> Someone's ported the i830 framebuffer driver to 2.6
<jdub> mdz: i would like a new glibc. can we have one? i promise to feed him and keep him warm.
<mdz> jdub: have you talked to gotom about it?
<mdz> leaping ahead of Debian on glibc smells faintly of crack
<Mitario> mjg59, they will get integrated this week I reckon :)
<thom> mdz: only faintly? you must be getting acclimatised
<mdz> thom: it's faint after it's wafted its way up from down under
#ubuntu-devel 2004-11-16
<mjg59> Mitario: Rocking
<mjg59> So much rock
<jbailey> jdub: Both gotom and I have newer glibc snapshots, you could probably use one of those.
<mjg59> upgrade-notifier just runs in the background and pops up an icon?
<pitti> mdz: could you please have a look? https://chinstrap.warthogs.hbd.com/~pitti/usn-shadow.txt  TIA!
<jdub> mdz: why crack? exposure to bugs with limited testing scale?
<mjg59> Jesus.
<jdub> jbailey: mmm, that's what benh suggested.
<thom> Mitario: dude, this is totally sweet
<mjg59> The Debian patches bring in vast steaming piles of crack. And it's mostly Sven Luther's fault.
<jdub> jbailey: you guys are only stuck due to platform support, right?
<mdz> jdub: glibc is a nontrivial essential package where we don't have a lot of expertise on the team
<jbailey> jdub: Stuck?
<jbailey> jdub: No, waiting for sarge to release.
<mjg59> Sweet, sweet crack
<jdub> jbailey: ahr. usual answer.
<seb128> jbailey: oh, you too ? :)
<jbailey> jdub: We froze glibc 14 months ago.
<pitti> fabbione: still here?
<mjg59> I need a fuckoff-big SMP machine to do these builds
<thom> pitti: i suspect the X team are currently too drunk to type straight
<mjg59> Bloody X team
<pitti> thom: it's a bit urgent, but I wait until tomorrow
<thom> mjg59: kernel? I built inotify support on my x40. no fun *at* all
<mdz> thom: hmm, the firefox open-in-new-tab magic doesn't seem to be working. was that an ubuntu patch?
<mjg59> thom: Aw, shit. Forgot to add the inotify patch.
<mjg59> Ah well, that's not what I'm testing :)
<thom> mdz: no, that was a debian one
<mdz> pitti: the text looks fine; I assume that you examined the code for the facts of the exposure, I cannot verify that part
<thom> mdz: you get new windows all the time now?
<pitti> mdz: okay, then away with it. Thanks for proofreading
<Mitario> phew, that was a large wiki update
<mjg59> thom: Thankfully I'm building this on a 2.4GHz P4, not my laptop...
<mdz> thom: I get stuff opened in the current tab, rather than a new one
<mdz> thom: the option was removed from the config file, too
<thom> mdz: suck :( can you file a bug, i'm just about to pass out
<mdz> thom: sure
<mdz> night
<thom> mjg59: yeah, that'll not be quite so painfull
<mjg59> Oh christ
<mjg59> The C3 has started a GL screensaver
<thom> (well, when this firefox build finishes)
<mjg59> Running on the vesa X server
<thom> rofl
<elmo> GAR
<mdz>     - Removed FIREFOX_OPEN_IN stuff, so that firefox now obeys to "open
<mdz>       links from other applications in" setting. (Closes: #279073) (MH)
<elmo> pitti!
<elmo> you TRAMP
<mdz> thom: looks like there is a setting somewhere which supersedes it
<pitti> elmo: ?
<elmo> pitti: I just did 44 upgrades of perl and NOW you release a USN for shadow?!
<mdz> elmo: it's no biggie
<elmo> HATE YOU ALL
<pitti> elmo: don't shoot the messenger... :-)
<thom> mdz: preferences/advanced/tabbed browsing
<thom> just found it
<pitti> elmo: I waited so long because joey wanted to keep this undisclosed
<mdz> thom: you say that as if the drop-down menus work :-)  I just upgraded firefox while it was running
<mjg59> Oh ARSE
<pitti> elmo: but it just appeared on full-disclosure
<mjg59> Out of disk
<thom> mdz: meh, i do hope they fix that
<thom> otherwise i shall be asking mark for the funding for a small nuclear device
<mdz> thom: ooh, good new stuff there
<jdub> thom: ... but they already use the POWER of xml and javascript. what more can they do?
<thom> and an f16
<mdz> force new window -> new tab
<mdz> things I missed from the tab extension
<elmo> pitti: yeah, just ignorre me, I'm just ranting at the unfortunate timing
<thom> yeah, just a shame they went for the dumb default for the open in thing
<pitti> elmo: perfectly understandable
<pitti> elmo: however, it really doesn't matter for our servers, if you mean that
<pitti> elmo: it's just a flaw with expired accounts, and not even a big one
<elmo> pitti: I know, but my scripts whine at me mercilessly if I leave security stuff unpatched
<thom> hrm, upgrade-notifier appears to have kamikazed out of my notification tray
<jdub> thom: ephy+firefox == fasssssst
<thom> jdub: i bet
<Mitario> thom, uhmm? :)
<thom> no, i'm being stupid
<thom> ignore me
<seb128> jdub: that's because of the missing typeahead :p
<jdub> haha
* thom giggles at seb
<thom> ARGGGGH
<thom> why won't firefox break here
<seb128> this bug is for you thom
<seb128> I'm rebuilding a firefox package here :)
<seb128> there is no evidence in the upstream bugzilla that the typeahead support is broken in firefox
<seb128> I want to test it :)
<thom> it breaks on the buildds. it breaks for Mithrandir. why will it not break here
<thom> seb128: be my guest
<thom> seb128: you'll note, however, that gentoo, redhat, debian, and us all turn typeaheadfind off
<thom> seb128: https://bugzilla.mozilla.org/show_bug.cgi?id=260948 http://bugs.gentoo.org/show_bug.cgi?id=64196
<Mithrandir> seb128: want an account on ravel to debug?
<seb128> debug what ?
<Mithrandir> uhm
<Mithrandir> s/seb/thom/
<thom> Mithrandir: i think i have one, actually
<thom> remind me of the host name?
<Mithrandir> ravel.hpc2n.umu.se
<Mithrandir> nope, you don't have any account.
<pitti> elmo: maybe wait until tomorrow, there is a whole bunch of new flaws that I have to fix
<mdz> pitti: your advisory said that only login was affected, but chfn and chsh are in passwd
<thom> ok, yes please
<Mithrandir> if you want one, drop me a signed mail with user name and ssh key.
<pitti> mdz: argh
<pitti> the title was correct, but the package don't
<thom> jdub: please moderate thom@canonical.com through to hoary changes
<elmo> pitti: DUDE.  I just finished shadow.
<pitti> mdz: sorry for that. 17-2?
<elmo> jdub: you restored to moderating hoary changes?
<mdz> pitti: nah
<seb128> thom: ok ok, sorry for the noise :)
<pitti> mdz: I can at least correct the web site
<thom> seb128: :-)
<thom> seb128: bug marco :-)
<jdub> elmo: it was never moderated, and don't think it's on now.
<jdub> something else is going on.
<thom> jdub:  hoary-changes-bou (  0) Your message to hoary-changes awaits moderator approval
<thom> * a few
<jdub> hrm, no message here...
<jdub> ah, because i am not admin of that list :)
<elmo> I'm off back to the hotel, night all
<pitti> Night elmo!
<seb128> thom: <chpe> wouldn't adding pref("accessibility.typeaheadfind", false) to firefox' default prefs be enough ?
<seb128> thom: do you know where I should make the change ?
<seb128> it's already off
<seb128> nevermind
<thom> seb128: i'll try it again in the morning, but i seriously don't think it's doable
<seb128> but how the typeahead works in firefox for the moment ?
<thom> it uses find as you type (FAYT) which is built in
<seb128> ok
<seb128> thom: 
<seb128> <chpe> ok, I see what the problem is. there's extensions/typeaheadfind, and toolkit/components/typeaheadfind
<seb128> <chpe> they both register the typeaheadfind contract-id
<jdub> http://jimmac.musichall.cz/ikony/i42/evolution-icon.png
<jdub> woo :)
<thom> jdub: caillion has gtk stock icon stuff happening for firefo
<thom> x
<jdub> bonus!
<thom> seb128: does he know how to fix it? :-)
<jdub> that's rad
<seb128> thom: probably, waiting for a reply from him :)
<thom> jdub: http://christopher.aillon.org/blog/dev/mozilla/20041104-stock-icons.html
<seb128> <chpe> it may be as simple as changing the contract ids...
<seb128> <chpe> (they SHOULD have changed them, since the 2 .idl are incompatible! )
<seb128> * chpe tries that
* mjg59 tries this again on the partition with more than 400MB free
<thom> if i can nail down this amd64 ftbfs, i might see if i can land it
<jdub> thom: ... marco helping out with firefox. *cry*
<mjg59> Jesus. There's huge amounts of shit in the kernel that hasn't been updated in years
<thom> jdub: yep
<thom> jdub: gnome + moz integration *is* his bag, baby. so it's not too surprising
<Mitario> umm, cool we have an ubuntu installer?
<thom> Mitario: hm?
* Mitario reads hoary-changes katie@blablabla mail for util-linux
<Mitario> umm, ubuntu-meta
<thom> oh, right
<pitti> night, guys!
<thom> g'night
<mjg59> Argh.
<mjg59> Now it's decided to rebuild everything.
* mjg59 decides not to try to understand the kernel build system
<mjg59> Ironically, the C3 craptop doesn't support the ACPI C3 power state
<mjg59> Hmm. Nor does it have a sleep button.
<Mitario> yaay, upgrade-notifier has a context menu again
<mjg59> Mitario: If I run upgrade-notifier, should I see anything unless there are updates available?
<Mitario> nope
<Mitario> only if there are updates
<jdub> mjg59: it's a NOTIFICATION icon. :-)
<thom> Mitario: is there a cron job or something that would notify the app?
<Mitario> thom, there is a cronjob file in the package, it's only disabled for now because it's probably going to be moved to the apt package
<Mitario> upgrade-notifier is notified via dbus when the cronjob has run
<thom> yeah
<thom> just grabbed the source package :-)
<Mitario> :)
<thom> Mitario/mvo: if synaptic could go away again when it finishes the upgrade, that'd be cool too
<Mitario> when synaptic and update-manager is finished, it will all be integrated in a nice triangle :)
<Mitario> thom, already happens :)
<Mitario> afaik
<Mithrandir> thom: you should be set up now; ravel.hpc2n.umu.se; prod maswan or me if you need anything in any chroot.
<thom> Mitario: didn't just now
<Mitario> hmm, weird
<Mithrandir> maswan: I gave thom an account on ravel
<mjg59> jdub: That's what I thought, but I wanted to be sure :)
* Mitario checks
* mjg59 fixes up more Warty patches to apply against bleeding-edge kernels
<thom> Mithrandir: thanks duder. moz-firefox build deps would be nice if they aren't already there:-)
<Mitario> thom, ah, synaptic is called without --non-interactive, thats why
<Mitario> will be fixed soon :)
<thom> Mithrandir: oh, and can you add me to the hoary chroot?
<mjg59> Shame I absent-mindedly fucked up my source tree, but, hrmph.
<thom> mjg59: heh
<thom> Mitario: cool
<Mithrandir> thom: done.
<Mithrandir> thom: they're in the hoary chroot
<mjg59> With luck, I can get that back...
<thom> Mithrandir: merci bien
<mjg59> xscreensaver really should have an option not to run GL screensavers without hardware GL
<mjg59> Haha
<mjg59> keybuk's favourite libvte bug is still there
<thom> waaagh, i are thoroughly bored of watching firefox compile
<bob2> how long does it take on your amd64 beast?
<thom> fookin' hours
<thom> actually, i'm lying, it's about 40 minutes, and about the same to construct the diff :/
<mjg59> I have a kernel
<mjg59> Now I just need to wait for it to turn into a deb...
<Mithrandir> thom: want ccache?
<mjg59> Urgh.
<mjg59> Why does xscreensaver seem to choose an openGL screensaver every single time?
* mjg59 watches another <1FPS screensaver crawl past
<thom> Mithrandir: if there's space, definitely
<jdub> mjg59: our screensaver selection is almost exclusively GL ;)
<mjg59> jdub: I wish to introduce you to a world of pain
<Mithrandir> thom: installed
<jdub> mjg59: i raised this point myself...
<mjg59> Oh lord why does the kernel build system want to build the docs before giving me the kernel deb?
<Mithrandir> mjg59: it's evil, of course.
<Mitario> i'm off to bed
<Mitario> cya guys
<mdz> mjg59: make-kpkg kernel-image
<mjg59> mdz: Nah, I want a full set of kernels
<mdz> mjg59: oh, you're building the entire linux-source package?
<mjg59> Yeah
<bob2> bah, thanks for crashing, firefox
<mjg59> ARGH.
<mjg59> pivot_root: No such file or directory
* mjg59 wonders what causes that
<bob2> hrm, why is dpkg saying a hal event file has changed?
<mjg59> Ah. My kernel has built without including the vast majority of the modules.
<thom> oops
<mjg59> No, it's built the modules. They just haven't ended up in the package.
<thom> oh good. firefox segfaults on ravel, this makes life easier
* thom really goes to bed
<mjg59> Oh. That would be because I've FUCKED IT UP.
<jdub> night thom :)
* thom giggles at mjg59 
* mjg59 blows away the build tree and prepares to start over
<mdz> mjg59: ccache-able, I hope
<thom> but why does it not segfault when you run the same command manually
<mjg59> mdz: A-ha ha ha.
<mdz> thom: DH_COMPAT?
<mdz> thom: fakeroot?
<mojo__> hi all ppl
<bob2> oh, awesome, firefox's ugly default web browser interface has been replaced with a much simpler and smaller one: http://egads.ertius.org/~rob/firefox.png
<mojo__> Why we still using old version 2.0.1 of libgnomecanvas and libgnomeuimm whilst 2.6 is out
<thom> bob2: heh
<mojo__> bob2: I dun find the default firefox GUI ugly at all
<bob2> mojo__: the new one is much cleaner
<thom> bob2: got extensions installed?
<bob2> thom: no
<mjg59> I want a webbrowser like that
<bob2> mojo__: no extraneous buttons, text boxes, scrollbars or webpages
<thom> a language pack for your crazy not-quite-english?
<mojo__> bob2: lol
<bob2> nope
<mojo__> bob2: yes, it's better
<bob2> another weird thing is that for the past two weeks, I've always had a text cursor in the pages
<thom> killall firefox-bin and try again
<jamesh_> bob2: sounds like a DTD/translation issue
<bob2> ie a little I-bar you can move around with the cursor keys, letter by letter
<thom> mdz: debian/compat is 4; running under fakeroot but don't the buildds use sudo?
<bob2> some do, some don't
<mojo__> bob2: I find that gnome-applet now contains trashapplet so y there is still trashapplet app seperate in our respo.?
<mdz> thom: they all use fakeroot, at least in Ubuntu
<thom> oh, right
<bob2> mojo__: hm, waiting to be removed maybe?
<thom> ber, but i built it locally with fakeroot
<bob2> package removal requires elmo-intervention, aiui
<mojo__> bob2: ok then,
<bob2> thom: ah, started ok this time
<bob2> but now fonts look blurry-as
<bob2> did we sync the fucked fontconfig from sid?
<thom> bob2: you upgraded underneath the poor thing, didn't you?
<mojo__> bob2: it's also good time for us to move to gcc3.4, all libgnome to newer version, I hate keeping all old shit here in my super small sized HDD box
<bob2> thom: um, er, ah
<mojo__> new 2.9.1 just out
<thom> mojo__: um, you realise warty won't change?
<thom> mojo__: hoary has gnome 2.9.1
<mojo__> thom: i know, but just some program up to 2.9.1, the libgnome is still 2.8.1
<mojo__> thom: click on About GNOME
<mojo__> should we get rid of esd and bring jack or polyaudio in?
<thom> mojo__: please read http://people.ubuntulinux.org/~mako/hoary_kickoff-20041025-summary.html
<thom> hrm, upgrade-notifier is multiplying
<thom> i now have 7 of them
<bob2> erm, bizarre, I still have a cursor in the webpage instead of up/down moving line-by-line
<moyogo> hmmm, www links are opened in an existing window of firefox 0.99, how do i get back to a new-window mode?
<jdub> thom: same is happening to me with sesssion dbus daemons :|
<mojo__> moyogo: editing some xml file in the firefox, search for a article in wiki of Ubuntu
<thom> mojo__: preferences/advanced/tabbed browsing
<thom> uh, moyogo, even
<thom> it's an option
<mojo__> thom: hehe, u know a better way, I still play around with xml file
<moyogo> oh, sorry, i meant from other apps, like xchat, gaim, etc...
<mdz> an ode to gnome-terminal
<mdz> gnome-terminal, why are you so slow?
<thom> ARGH
<thom> moyogo: yes.
<mdz> EOF
<thom> moyogo: you need to change the pref in firefox
<thom> then it does the right thing
<thom> mdz: heh
<moyogo> thom: thanks
<thom> why oh WHY does the wiki say "Howto's"
<thom> What does the howto own? 
<mdz> thom: it's a wiki, fix it :-P
<mojo__> quote: Mark Shuttleworth stated that, "GUI installer is on the hoary list, but it has a question mark on it and I won't commit to having a GUI installer for hoary as it will back us into a corner." That said, it something that people will start working on.
<thom> i am with extreme prejudice
<mojo__> so what is our GUI installer? Annaconda, SuSE Yast or Mandrake Installer???
<mjg59> No
<mjg59> It'll be d-i, but graphical
<mojo__> really? cool
<mdz> I suppose it would be in poor taste to upload binaries built on Ubuntu to Debian...
<mdz> damn Debian and its binary uploads
<mojo__> mdz: same opinion here
<mojo__> mdz: we shouldn't merge,
<mdz> mojo__: hmm?
<Kosai> thom: Apostrophes can be used to pluralise, eg. CD's and 1980's.  I imagine the author chose to pluralise because "Howtos" is misparsed, and if you're going with "HOWTOs" then you're accepting that it's an abbreviation and an apostrophe is therefore okay.
<mojo__> mdz: I got this msg: thom: Apostrophes can be used to pluralise, eg. CD's and 1980's.  I imagine the author chose to pluralise because "Howtos" is misparsed, and if you're going with "HOWTOs" then you're accepting that it's an abbreviation and an apostrophe is therefore okay.
<jdub> Kosai: that is incorrect.
<mojo__> sorry
<Kosai> jdub: Which part?
<mdz> Kosai: apostrophes for pluralization
<mojo__> mdz: I got this msg: glade-2: error while loading shared libraries: libgnomedb-2.so.3: cannot open shared object file: No such file or directory
<mdz> Kosai: http://www.angryflower.com/aposter.html
<Kosai> It's clearly not "incorrect", since you'll find it in style guides, and it's the "CDs" from that's traditionally considered incorrect.  You can say that you disagree with it, which is not the same thing.
<mojo__> mdz: when installing it, it doesn't take libgnomedb as its dep, it'd be a problem with the maintainer
<Kosai> s/from/form/
<thom> Kosai: my english teacher would've hung drawn and quartered me if i tried to use an apostrophe for pluralisation
<mdz> mojo__: possibly
<jdub> thom: i would've been extradited to the US.
<Kosai> thom: *shrug* I'm a "CDs" person.  I just wouldn't expect a non-geek to be, and wouldn't profess it as Plain Wrong.
<jdub> thom: by the *education* department.
<mojo__> mdz: darn, I got libgnomedb installed and new it still complains, defintely a bug!
<Kosai> thom: For further insight, consider the phrase "Mind your p's and q's."
<jdub> Kosai: i don't even use apostrophes when i *say* it.
<Kosai> jdub: You say "Mind your ps"?
<Kosai> 'cause that could scare a lot of Unix geeks :)
<moyogo> one could say "Mind your pees and queues"
<Kosai> One could, but I think one would be further elucidating my point.
<mojo__> ppl, can u ppl check for me, whenever u copy a text from different programs and paste it here, it just takes all msg that other chatter just type in and paste it out, it happens here with me, can u guys recheck, thx?
<bob2> mojo__: that would depend on the IRC cilent, but, no, it doesn't happen with irssi + xterm
<Kosai> mojo__: Primary vs. selection clipboards?
<mojo__> bob2: I'm using XChat
<mojo__> Kosai: if u use X-Chat, plese check for me. thx in advance
<Kosai> If you're doing an Edit->Copy, you need to be pasting with an Edit->Paste rather than a middle-click.
<Kosai> I don't use xchat.
<moyogo> xchat's ctrl+v pastes whatever text is selected
<mojo__> darn, this bug happens not only with XChat but also with FireFox, I just pasted some error text from my GNOME terminal, and it just paste all words u guys just talked
<mojo__> werid, it'd be XChat save text in buffer clipboard
<Kosai> mojo__: This is fundamental enough that I suggest it's not a bug, but your understanding of how X11 selections work.
<mojo__> Kosai: can u explain?
<mdz> mako: around?
<Kosai> mojo__: There are two clipboards.  One is copied to and pasted from via Edit->{Copy,Paste} menu commands, one is copied to and pasted from by selecting text to copy and middle-clicking to paste.
<Kosai> If you're mixing those two models, you will not be pasting what you think you copied.
<mojo__> Kosai: oh i c
<mojo__> Kosai: oh ic
<Kosai> (This isn't at all on topic for #ubuntu-devel, by the way.)
<mojo__> Kosai: devel need to learn and updates everyday, don't we?
<mdz> mako: please fact-check https://www.ubuntulinux.org/support/documentation/faq/shipit and update as appropriate so that it answers the new "when are my CDs coming?" FAQ
<mojo__> mdz: I hope the CD Cover is pretty
<mdz> mojo__: they are
* mjg59 builds a working kernel
<mjg59> Well, except that it hasn't loaded the input drivers. Ho-hum.
<mjg59> Hang on. They're supposed to be static.
<mjg59> Hrm.
<mako> mdz: thanks! :)
<mdz> mako: I removed the bit which said we would ship them sometime after warty released :-)
<mako> tomorrow i am mailing everyone who requested a cd and wasn't sent one and will update shipit as well
<moyogo> does firefox 0.99 break sound with flash?
<moyogo> i can't hear a thing but i'm not sure what's the cause
<lamont> mdz: germinate ensures that build-deps are satisfied within the component (tree).   pb was that sbuild used diff logic to pick the build-depends...
* lamont works on bootstrapping sbcl
* lamont bets no elmo.
<lamont> hrm.. arts needs help from someone who cares about universe and kde
<jdub> lamont: that'
<jdub> lamont: that'd be... not any of us! :)
<lamont> jdub: yeah - that's why I just told the -devel community to care. :-)
<jdub> heh
<jdub> yyyaaay!
<lamont> sbcl about to be bootstrapped on ppc.
<lamont> i386 is a bit behind, because it's bootstrapping more packages in the bundel
* lamont wanders off for a little bit
<mdz> zsh: segmentation fault  cvs up -jupstream_version_2_4_{0,1} -d
<mdz> GREAT
<lamont> mdz: :-(
<lamont> mdz: sbcl bootstrapped on ppc, will bootstrap i386 the rest of the way in the morning, need to run to denver tomorrow, which'll nuke a fair part of my day...
<mdz> lamont: what's in denver?
<lamont> (i386 may also get ghc5 and cmucl and maybe even smlnj)
<lamont> wife's dragging me down for a hotel meeting tomorrow lunch
<lamont> so 1 hour meeting, 90 min each way travel :(
<lamont> then saturday I head to the bay area, where I'll be working for a couple of weeks with the conf in the middle, as discussed.
<lamont> mako around?
<mako> lamont: yesah
<lamont> mdz: so tomorrow will be a bit of a strange(r?) schedule for me, but should be productive...
* lamont sleeps
<fabbione> morning guys
<mdz> morning
<fabbione> hey mdz
<fabbione> i feel all strange
<fabbione> it was ages i couldn't sleep this long
<mdz> fabbione: did you sleep well?
<fabbione> yeps
<fabbione> finally
<mdz> a weight was lifted :-)
<fabbione> yeah well
<fabbione> now it needs to hit the archive
<fabbione> that is going to be hard
<fabbione> the other things in the TODO list are long and borig
<fabbione> boring
<fabbione> so mdz.. did you notice any side effect after the upgrade?
<fabbione> other than the keyboard thing
<pitti> Hi guys
<fabbione> mdz: i found the problem for the keyboard thingy
<fabbione> does anybody know how to validate xml data?
<pitti> fabbione: I always use the perl bindings for the Xerces parser (a very good one)
<pitti> fabbione: can do both DTDs and XML Schema
<fabbione> pitti: i found the error
<fabbione> and a way to "validate" it ;)
<pitti> fabbione: "the" error?
<pitti> fabbione: you mean the keyboard layout thingy?
<fabbione> yes
<fabbione> it's a bunch of merge errors in xorg.xml
<fabbione> nothing too difficult to fix
<fabbione> just a royal pain the butt ;)
<fabbione> yup
<fabbione> it took more time to find the gnome application name than to do the fix
<Mithrandir> mdz: uhm, you resolved 692 as notwarty?  Is it nothoary as well?
<cenerentola> can i speak with jeef.waugh
<cenerentola> jeff actually
<daniels> cenerentola: jdub
<cenerentola> that is...
<cenerentola> jdub: got to speak with you...
<fabbione> gooody another X.org bug fixed
<sivang> morning all
* fabbione larts capplets
<sivang> hi fabbione
<fabbione> and libxklavier with a HUGE cluebat!
<fabbione> hi sivang 
<sivang> fabbione : we need your help :) mako said you are to guy to ask for irc channels logging 
<fabbione> sivang: yes...
<fabbione> oh actually.. i need to remember to move the logs to a public place
<fabbione> sivang: i need to know the channel at least ;)
<ChrisH> fabbione: Just out of curiosity... how do you log? I enabled logging in .irrsi and could imagine just copying the files. Is there a decent automatism?
<ChrisH> fabbione: Perhaps a "lurk bot". :)
<fabbione> ChrisH: i use bitchx and i enable logging per channel
<fabbione> a script at night will rotate the logs
<fabbione> nothing too fancy
<ChrisH> fabbione: Ah, okay.
<fabbione> irssi can do the same
<__daniel> hai
<fabbione> ChrisH: and i have "wartylog" that does the job for us
<fabbione> i only forgot to put the logs in  public accessable place ;)
<__daniel> hai seb128
<fabbione> hey seb
<seb128> morning
<fabbione> seb128: should we talk about libxklavier?
<fabbione> ;)
<fabbione> can we change the build-deps and the build system to do something more sane?
<fabbione> like.. build-deps on xlibs, check if /etc/X11/xkb/rules/xorg.xml exists and set the proper values for it?
<seb128> what's the problem ?
<fabbione> if not check if xfree86.xml exists (and not as symlink)
<fabbione> and in case revert to it
<fabbione> seb128: x.org will change xfree86.xml to xorg.xml
<fabbione> there is a compatibility symlink
<fabbione> but the keyboard setup stuff is supposed to use the new one (capplets)
<fabbione> via that lib
<fabbione> also.. the lib ships it's own copy of xfree86.xml
<fabbione> that's really really bad
<fabbione> it should get it from the system directly with the proper builddep
<fabbione> it does it only for tests
<fabbione> but it will spot errors earlier if it uses the system one
<seb128> ok
<seb128> and what's the problem with cdbs so ? :)
<fabbione> it's not urgent tho, but if you can provide us a fix we can test it
<fabbione> seb128: cdbs sucks.. but that's another story :P
<__daniel> could someone of you initiate a sync with libgdamm1.3* (version number 1.3.4-1) in experimental debian? i built packages from debian source and it all went quite fine :-)
<fabbione> __daniel: please mail ubuntu-devel explaing also why we need to sync it
<fabbione> syncing from experimental is not necessarely good ;)
<__daniel> oh ok... thank you, i wondered what was the appropriate way
<seb128> fabbione: feel free to change whatever you want in libxklavier, or let me know what changes do you want exactly if I should do the changes (1.11 has been released yesterday I was going to package it today)
<fabbione> seb128: ok.. than i will wait for the new upstream
<__daniel> fabbione: libgdamm1.3 won't make the systems in general unstable ;-)
<amu> fabbione: on my g4 PB xorg doesnt work. You got mail, about logs and the config  
<Mithrandir> hi amu
<amu> hi Mithrandir 
<Mithrandir> amu: I poked a little bit around in your cd build setup; do you have a design document of some sort?
<amu> Mithrandir: on devel ? which one now i have 3 builds, mmaker, ibuild and a native   
<Mithrandir> amu: on devel, yes.
<amu> Mithrandir: no docs for now ;) 
<Mithrandir> amu: ok, so I have to read code and grok it that way. :)  Which one is the one I should look at?
<fabbione> amu: got it.. daniles is checking, but please use the mail alias next time
<fabbione> amu: can you try set Option "UseFBDev" "false" ?
<amu> fabbione: mail alias ?
<azeem> x-psychos@canonical.com, probably
<fabbione> yes.. read the mail... use xsprintbugs@fabbione.net
<azeem> ah, close :)
<amu> fabbione: yap, also not working ;)
<amu> fabbione: ok
<seb128> elmo_away: hum, reject gtkhtml3.6 if possible .. if that's too late don't worry that's not a big deal
<fabbione> amu: daniels says it's a known upstream bug
<amu> fabbione: sorry, after my xorg session upgrade last night, evolution isnt working anymore :) guess asap i need a reinstalltion
<fabbione> amu: evolution has nothing to do with X
<fabbione> amu: if evolution does trycky things.. it needs to be fixed
<fabbione> amu: anyway.. you should be able to avoid a reinstallation
<fabbione> amu: just do a apt-get install xserver-xfree86
<fabbione> it should deinstall xserver-xorg
<fabbione> and everything should be working fine again
<seb128> what's exactly the problem with evolution ?
<fabbione> amu: we need a backtrace from the debug server
<fabbione> amu: can you help us?
<amu> seb128: run a upgrad to hoary, now removed all evolutions dirs, started it again, and at the point, where i chosse my timezone, it hangs and my syslods goes to 99%  
<amu> fabbione: no prob, tell me what i should do 
<amu> seb128: chosse/choose
<seb128> that's nothing due to x.org
<seb128> that's a bug with GNOME 2.9
<seb128> reported several time and 100% reproducible
<fabbione> amu: install xserver-xorg-dbg
<fabbione> amu: and gdb it
<seb128> amu: reinstalling will not help ... BTW I'm upload 2.1.0 today which will fix the problem
<amu> seb128: before i upgrade, run a backup, now my mails are in the backup. How i can read old mails with evo, no way. Untar everything to a tempdir, reading them with mutt. I thought i should tell fabbione about it and sended him a mail ( with mutt ) about my problems, which i have 
<seb128> sorry but you should  not run hoary if you don't want to deal with any problem
<seb128> that's a devel branch we can't avoid all the bugs
<seb128> you can't create a new account on a fresh evolution installation, but if you have a old ~/.evolution it should just use it, not ask for an account creation and not hang on the tz selector
<daniels> seb128: ah cool, thanks for the new evo stuff
<amu> seb128: no prob with it.I still know how to use mutt :) 
<fabbione> amu: as soon as you can please try to gdb the xserver
<bob2> seb128: would it be better if "totem" Depended on totem-gstreamer | totem-xine, so that gnome-fifth-toe doesn't remove totem-gstreamer?
<amu> fabbione: on work :) 
<fabbione> amu: cool
<seb128> bob2: in debian it does, in warty/hoary we don't use the dummy package so we don't care
<pitti> elmo: Morning! Can you please sync lvm10 1:1.0.8-8 from Debian?
<elmo> pitti: done
<pitti> elmo: thx
<daniels> pitti: you forgot the 'k' and 'bye'
<pitti> daniels: hmm, not yet time for the "bye" part :-)
<pitti> daniels: BTW, I tried to get my VGA out working on my iBook. fabbione promised it would work with x.org, but it doesn't :-((
<pitti> daniels: does that mean I need to keep OS X just for presentations?
<daniels> pitti: how fast is your machine?
<pitti> daniels: 800 MHz
<daniels> pitti: if you don't mind building xorg, I'll feed you a patch that should make it work
<daniels> hnrgh
<daniels> i don't have access to a powerpc, sorry
<daniels> elmo: any chance I could get access to the chroot on adare?
<pitti> daniels: hmm, if I start now, it could be ready by the conference :-)
<bob2> it won't take that long
<bob2> how much disk space does it take?
<daniels> >4GB
<bob2> will pbuilder work or do I need to remember the sbuild incantations again?
<pitti> daniels: btw, the problem seems to be the frame buffer; if I disable UseFBDev, then the external screen works perfectly, but the internal screen flickers; if I enable framebuffer, the internal screen works, but the external doesn't
<daniels> pitti: yeah, that sounds exactly like an fwpll thing
<pitti> daniels: does that ring any bell?
<daniels> bob2: pbuilder should work fine
<pitti> daniels: I even tried to enable this fwpll option, but it doesn't do anything; the patch makes it work?
<bob2> pmdisk should work with dri enabled now, too
<bob2> in xorg land, I mean
<elmo> daniels: done
<daniels> bob2: pmdisk?
<bob2> oh, I'll let you do it then
<daniels> elmo: cheers dude
<fabbione> pitti: chill down dude... it's the first release ;)
<bob2> daniels: = Yet Another Suspend-to-disk System
<pitti> fabbione: hey, I was curious! :-)
<fabbione> pitti: we are happy enough that it works :-)
<fabbione> and not even everywhere 
<daniels> elmo: yellow hates my key
<pitti> fabbione: do you have an idea why the automatic upgrading did not work?
<elmo> daniels: err, yellow's amd64
<fabbione> pitti: no. it works here and it worked for several people
<elmo> you asked for powerpc
<bob2> pitti: were you running hoary before?
<daniels> elmo: sorry, adare
<daniels> elmo: i'll try again with -idiot
<bob2> the upgrade worked perfectly for me
<fabbione> it doesn't need warty or hoary
<pitti> bob2: I had hoary on my desktop, warty on iBook; neither upgrade installer xserver-xorg
<fabbione> it requires you to have ubuntu-desktop installed
<pitti> fabbione: ah, I didn't have ubuntu-desktop
<pitti> fabbione: this could explain the issue
<fabbione> that's why there was a new version in the archive
<daniels> elmo: yeah, works perfectly, thanks
<fabbione> if you remove the standard stuff you are on your own
<pitti> bob2: I did not see any flaws during the upgrade too, but it just kept my old xserver-xfree86 package and did not install the -xorg one
<bob2> pitti: ah, right
<bob2> pitti: sleep on g4 ibook's may happen very soon, btw
<pitti> bob2: even better :-)
<sivang> fabbione : #ubuntu-doc
<sivang> fabbione : :)
<fabbione> sivang: ok.. will do in a sec
<sivang> fabbione : thank you, no need to rush anyways :)
<fabbione> sivang: it takes a minute
<|trey|> Any reason why apt-listbugs isn't installed by default? Would be nice for people running hoary  :)
<bob2> it doesn't integrate into synaptic
<sivang> fabbione : Thank You!
<|trey|> bob2, happen to know if differences with console-data and locales would be reason for "perl: warning: Setting locale failed."? when using APT/dpkg on terminal?
<|trey|> (just making sure due to not being able to set it right now... waiting on it to finish...)
<|trey|> If something else is at fault, it would be nice to know  :)
<bob2> did you generate the locale you're trying to use?
<|trey|> bob2, yup... dpkg-reconfigure locales does that...
<|trey|> bob2, "locale: Cannot set LC_CTYPE to default locale: No such file or directory" "locale: Cannot set LC_MESSAGES to default locale: No such file or directory" "locale: Cannot set LC_ALL to default locale: No such file or directory"
<|trey|> bob2, those are some of the errors I am getting... look like I have to do it again, I have only changed locale in locales... where else should I check?
<|trey|> bob2, rarely do I successfully get UTF-8 working correctly   :(
<bob2> I dunno
<|trey|> bob2, :(
<|trey|> bob2, ahh.. the file it mentions it can't find is /usr/bin/locales (area I copied from didn't contain that... seems important  ;) )
<|trey|> bob2, wouldn't that be part of package 'locales' though? that is installed... idgi  :(
<|trey|> bob2, grr... it seems to work, just farts that out... report bug?
<|trey|> bob2, ugh, to make console use UTF-8, dpkg-reconfigure what? looked at "low" for console-common and console-data... neither ask about locale  :(
* |trey| cries  :(
<Mithrandir> |trey|: locales?
<|trey|> Mithrandir, en_US-UTF-8 is an example of a locale...
<Mithrandir> |trey|: you need to run dpkg-reconfigure locales.
<Mithrandir> I know what a locale is.
<|trey|> Mithrandir, done... thats when I started getting the error...
<|trey|> Mithrandir, its also what I am using though... but why would it be complaining about no /usr/bin/locales? mores to the point, why is it looking for that?
<Mithrandir> /usr/bin/locale, I'd guess?
<|trey|> Mithrandir, ahh, yeah...
<|trey|> Hmm, ok, well thats there... so now I'm really confused  :(
<|trey|> Mithrandir, hmm, I probably haven't restarted X since I generated locale, could that be why?
<Mithrandir> no idea, I dislike utf8
<|trey|> Mithrandir, Ubuntu is switching to UTF-8 everywhere...
<Mithrandir> I know, and it sucks, IMHO.
* jdub looks at Mithrandir 
<|trey|> Mithrandir, whats wrong with it in your opinion?
<Mithrandir> |trey|: it requires me to switch all the bazillion systems I log into at once.
<|trey|> Other then it always giving me errors when I try to use it, I have nothing against it...
<|trey|> Mithrandir, would be better if UTF-8 was configured as part of postinst, afaik, its not though  :(
<|trey|> If it is, it didn't work here, that I can say for sure...
<Mithrandir> |trey|: still won't change all my _other_ systems.
<|trey|> Mithrandir, oh, I don't have any _other_ systems to worry about  :(
<|trey|> Mithrandir, Universal Text Format is a Standard though...
<|trey|> Oh, on a side note... my instuctor marked me off 2 pts on my final lab due to assuring me '//server/location' is not the format for UNC..
<|trey|> Else I would have gotten a 100... damnit, not complying with standards is annoying.
<|trey|> Kinda fucked up though, he knows I mainly use Linux... he should have let it slide, it works damnit, last I checked, things that work are correct?
* |trey| shuts up cuz he's talking to himself...
<|trey|> damnit @ me rambling here... thought I was in #ubuntu, not -devel, sorry  :(
<amu> fabbione daniels: ping 
<thom> Mithrandir: do you have any ideas *at all* on why ldd should segfault? :(
<daniels> amu: pong
* thom pokes Mithrandir some
<seb128> fabbione: ping ?
<fabbione> seb128: pong
<lupus_> Err http://archive.ubuntu.com hoary/main gstreamer0.8 0.8.7-1ubuntu1 (dsc)
<lupus_>   302 Found
<lupus_> no sources available?
<seb128> dunno if that's due to X.org, but the "select to copy and middle click to paste" doesn't work between my emacs and my GNOME apps
<thom> seb128: use a real editor ;-)
<fabbione> emacs is broken
<seb128> it was working before the xfree upgrade :p
<seb128> thom: gedit ? :)
<fabbione> something else is broken
<fabbione> but not X
<seb128> ok
<fabbione> ;)
<fabbione> seb128: that's a definition
<seb128> I just wanted to let you know that the copy/past is broken here
<fabbione> i would need to reproduce it
<fabbione> so from emacs to what?
* fabbione bloats his system with emasc
<seb128> emacs to any gtk+ app
<seb128> gedit for example
<seb128> or gnome-terminal
<fabbione> seb128: probably it needs to be recompiled
<fabbione> i don't think our buildd is there yet
<fabbione> there was a new drop of libxaw that might have break something
<seb128> do you have the problem too ?
<fabbione> yes
<fabbione> i can reproduce it
<fabbione> dunno in xfree86
<daniels> yeah, I blame Xaw
<fabbione> so do i
<seb128> it was working before the xfree->x.org for sure
<fabbione> seb128: well someone will have to fix Xaw applications to use the new interface
<fabbione> reverting xaw isn't really an option
<seb128> ok
<daniels> (and we now have not one, not two, but three different major versions of xaw. yay!)
<bob2> api or abi changes?
<daniels> both
<bob2> what could the possibly be changing in it thesedays?
<bob2> altering the argument list for the drawFuglyText() function?
<daniels> xprint.
<bob2> hahahahahaha
<daniels> it's not funny.
<daniels> pitti: please put http://people.ubuntu.com/~daniels/xorg/radeon_drv.o in /usr/X11R6/lib/modules/drivers, put 'Option "UseFWPLL"' in the Device section of /etc/X11/xorg.conf
* pitti fires up his laptop
<bob2> then I can plug my laptop to a crt and it will Just Work?
<daniels> bob2: Hopefully
<daniels> bob2: (that applies to you, too)
<bob2> rock.
<fabbione> seb128: i am afraid the problem is in gtk*
<bob2> 404
<fabbione> seb128: rebuilt emacs with latest xaw still has the problem
<pitti> daniels: I hacked the default config quite a bit in the meantime. Is the FWPLL option the only one required to get VGA OUT?
<daniels> pitti: i'm told so
<fabbione> seb128: are we sure there are no buildtime flags in gtk to recognize X.org/Xfree86?
<daniels> bob2: yeah, my bad, on the way
<fabbione> seb128: btw.. emacs to xterm works
<fabbione> so it must be the receiving gtk application that goes bong
<daniels> bob2, pitti: try now
<pitti> daniels: still 404 :-(
<daniels> daniels@rookery ~ $ ls -l public_html/xorg/radeon_drv.o 
<daniels> -rw-r--r--    1 daniels  warthogs  2327838 Nov  5 14:10 public_html/xorg/radeon_drv.o
<bob2> it's there for me
<bob2> 2 327 838 bytes
<pitti> daniels: now it works; I think the forced proxy of my ISP has bitten me
<daniels> ahr.
<bob2> 2b44a78ad9de3dcecda5301d8e498ee3  ./radeon_drv.o
<Mitario> hi everyone
<bob2> daniels: right?
<pitti> daniels: I want to kiss you!!!!! IT FINALLY WORKS!
<pitti> daniels: However, just using the option is not enough
<pitti> daniels: I inserted it into another configuration file I hacked before
<jdub> plenty of time for that kind of thing in december
<daniels> pitti: can you pass me the config file?
<jdub> you guys want to share a room? :)
<pitti> daniels, bob2: I will clean up the configuration changes
<seb128> fabbione: ok, I'll have a look
<pitti> jdub: wanna join us? :-)
<bob2> pitti: thanks dude
<jdub> wow-wow-wacka-wacka
<daniels> pitti: ill
<daniels> jdub: i'm already in with sideshow
<jdub> score.
<daniels> bob2: yeah, probably
<bob2> daniels: hah
<daniels> bob2: think I deleted it from my laptop after copying adare->rookery
<bob2> ah well
<bob2> it didn't break pitti's machine, so I'll live
<pitti> bob2: www.piware.de/xorg.conf
<pitti> bob2: however, this is still the messy one
<pitti> bob2: I publish the minimal changes to the wiki after cleanup
<bob2> pitti: yeah, I'm diffing yours and mien to see what to change
<pitti> daniels: thanks a lot, dude! I'm going to wipe OS X now :-)
<daniels> pitti: rad
<daniels> glad to see it works
* pitti starts to sing "The X-Men rock da house"
<bob2> pitti: do you have working ctrl-alt-f1 with your keymap?
<pitti> bob2: yes
<pitti> bob2: at least with my "exec xterm" window manager :-)
<lamont> moo
<pitti> bob2: this is the fastest one to test configurations (with startx)
<pitti> lamont: oink
<bob2> pitti: heh, right
<pitti> I will disconnect my desktop from the monitor now, to hook it to the iBook :-) 
<bob2> pitti: hrm, you're using the "ati" driver, not the "radeon" one
<pitti> bob2: I think these are pretty much aliases
<daniels> bob2: doesn't make a difference
<bob2> ah, cool
<daniels> except where ati fails to properly pass through to radeon because it's crap
<bob2> hah
<bob2> hm, now to find my hitherto useless crt adaptor
<pitti> bob2, daniels: okay, it is enough to add the UseFWPLL option and change UseFBDev from true to false
<bob2> pitti: what's mergefb and enablepageflip do?
<daniels> ... iiiinnteresting
<pitti> bob2, daniels: BTW, falsing UseFBDev alone has always given screen flicker effects
<daniels> i call bong
<pitti> bob2: enablepageflip is IIRC only a speed enhancement
<pitti> bob2: otherwise I have no idea; I blindly played around with some 10 Options
<bob2> pitti: do you get flickering without usefbdev now?
<daniels> mergedfb is so you can do overlays on dual-head
<bob2> = xvideo?
<robtaylor> hmm, i'm still having a problem getting my postinst called on 1st boot :/ 
<pitti> bob2: yes, without the FWPLL option the screen still flickers when not using the framebuffer
<daniels> it is what it says on the box -- it merges both displays into one big fb, so the hardware sees a 3200x1600 (e.g) fb to overlay on to
<daniels> bob2: xv and dri
<bob2> wow, awesome
<pitti> bob2, daniels: BTW, external screen will only work if the monitor is connected _before_ X start; but this is good enough for me :-)
<daniels> pitti: it's probably syncing to the wrong head, then
<bob2> is there any bongness like "you have to have the crt plugged in while booting"?
<daniels> pitti: try Option "DevicePresence" for that
<robtaylor> can anyone help? http://pastebin.ca/1930
<bob2> ah, right
<robtaylor> oop
<robtaylor> wrong channel =)
<pitti> daniels: with which value?
<bob2> daniels: if I start a new X server to test this, will it make the other two running *with* UseFBDev "true" puke?
<sjoerd> daniels: do you know if people with an albook (radeon 9600) have tested xorg with dualhead ?
<pitti> sjoerd: good news!
<pitti> sjoerd: yesterday I still used XFree86 without knowing it
<daniels> pitti: just on its own
<sjoerd> pitti: hehe
<daniels> bob2: arsed if I know.  i used to think it was fairly safe, then I made thom angry
<bob2> hah
<bob2> pitti: are you still Mr HAL, btw?
<pitti> bob2: Yes, I suppose
<pitti> daniels: no noticeable difference
<daniels> sjoerd: no idea, sorry
<daniels> sjoerd: that said, I'd be very surprised if it worked at all
<daniels> it should fail to detect your BIOS and error out
<pitti> daniels: in particular, if I attach the external screen after X start, I just see a dark OpenFirmware output
<pitti> daniels: or was this option to work without framebuffer interface?
<sjoerd> daniels: i didn't get xorg to work when i compiled it myself, but that was some time ago..
<bob2> daniels: does that merge option give me xinerama-type fun if I plug in a crt?
<sjoerd> daniels: i harass you when i get xorg debs for debian..
<amu> daniels: with the xorg-debug package the xserver runs.
<bob2> pitti: should I bug you on IRC or in bugzilla then? :)
<daniels> oh my god, my screen is very colourful
<daniels> amu: 
<daniels> amu: ARGH
<pitti> bob2: if you have enough information, bz is preferred :-)
<bob2> pitti: sure, will do
<pitti> bob2: but we can work it out interactively
<daniels> pitti: DevicePresence assumes all devices (e.g. external CRT) are present so you can attach them later IIRC
<bob2> pitti: it's just hal (or maybe g-v-m) doesn't auto-mount removable media with NTFS filesystems
<pitti> daniels: nope, not even with value "True"
<daniels> amu: can you please provide an strace with -s 1200 of running Xorg :0 -logverbose 999999999 -verbose 9999999999 -ac ?
<pitti> bob2: right, known bug
<daniels> amu: (of the non-debug server)
<bob2> pitti: ah, couldn't find it in bugzilla
<pitti> bob2: my arch head already does this
<daniels> pitti: ahr, suck :\ not really sure then, sorry
<bob2> pitti: is it related to having to mount it ro?
<bob2> pitti: oh, awesome
<pitti> bob2: I just noticed the lack of pmount NTFS support yesterday :-)
<bob2> pitti: ahhh
<pitti> daniels: still, restarting X is not a big deal; it's a huge improvement that it works in principle. Kudos!!! Many thanks!
<daniels> pitti: no worries dude :)
<daniels> enjoy it
<daniels> now to debugging this heisenbug. hoorah!
<daniels> thom: still think firefox sucks now? :P
<pitti> daniels: hmm, but for the general public, this should work out of the box some day...
<pitti> daniels: good luck!
<amu> daniels: tell me just what i've excatly to do, step by step 
<daniels> pitti: yeah, absolutely
<daniels> pitti: ta
<pitti> bob2: my current pmount arch head only mounts it ro anyway
<bob2> daniels: are all these options safe to set in xorg.conf by default?
<daniels> amu: install xserver-xorg, run sudo strace -s 1200 -ff Xorg :1 -logverbose 999999999 -verbose 99999999999 -ac > ihatexorgandthisiswhy 2>&1, send the logfile to xsprintbugs@fabbione.net
<daniels> bob2: no
<bob2> dang
<daniels> bob2: presence or lack thereof needs to be autoprobed, and the docs I have have a hole of sorts in them on that
<amu> daniels: thx
<bob2> daniels: ah
<bob2> well, time to test this baby out
* Mitario going home
<Mitario> cya soon
<pitti> bob2: I really like my laptop now :-)
<pitti> bob2: I change the wiki
<daniels> ah, pll2!
<sjoerd> daniels: scary question. do those debs have a chance to work with debian or are there big changes needed 
<daniels> pitti: i think I see something here that should let it work without fbdev
<daniels> sjoerd: should work ok
<sjoerd> cool.. i'll try to break my system one of these days with them then :)
<pitti> daniels: BTW, enabling fbdev has been the default all the time in Sarge and Warty
<daniels> rad
<daniels> pitti: yeah
<daniels> pitti: but it should fix the syncs everywhere
<pitti> daniels: that would be nice :-)
<daniels> pitti: prepared a patch now, seeing if it builds/applies (it's a very nice diversion from ^%*U#$ BIOS code), if it does I'll drop you another radeon_drv
<pitti> daniels: that would mean UseFBDev no could be the shipped default for all platforms?
<daniels> pitti: i'd hope so
<sjoerd> pitti: do you have the current pmount source available somewhere, if got some time to dig through it toninght
<sjoerd> s/if/i've/
<pitti> sjoerd: you can always check out the arch tree
<sjoerd> location ?
<pitti> martin.pitt@canonical.com--2004
<pitti>     sftp://pitti@chinstrap.warthogs.hbd.com/home/warthogs/archives/martin.pitt@canonical.com--2004
<pitti> sjoerd: oops, of course you have to s_sftp://pitti@_http_
<elmo> pitti: err, that won't work either
<pitti> elmo: right, the password
<pitti> sjoerd: I just send you the current head
<elmo> mirror it to rooekry?
<daniels> pitti: can you please send me your XFree86.0.log? (yes, XFree86, not Xorg)
<pitti> daniels: sure
<pitti> booting again...
<pitti> daniels: http://www.piware.de/XFree86.0.log
<daniels> AIEEEEEEEEEEEEE
<daniels> nothing changed!
<bob2> daniels: no go
<daniels> pitti: will throw you a new module later with the improved fwpll patch and some debugging
<pitti> daniels: for X.org?
<daniels> pitti: itmt, if you want to debug your X server, I would love you forever
<daniels> pitti: yeah
<bob2> daniels: all I seem to get is what looks like openfirmware
<pitti> daniels: meaning, I shall install the debug package?
<daniels> pitti: if you can start XFree86 (debug version) under gdb (WARNING -- MUST DO THIS REMOTELY, REALLY), put a breakpoint in RADEONGetBIOSParamaters and print the value of pInt10, that'd rock
<daniels> pitti: yeah
<daniels> bob2: using pitti's conffile, or?
<bob2> hrm, wait, brb
<daniels> bob2: (remember -- /etc/X11/xorg.conf)
<bob2> yeah, I had usefbdev true, then false a few lines later
<bob2> retesting
<pitti> daniels: ugh, 51 MB. Download ETA 12 minutes...
<daniels> pitti: yeah, sorry :\
<daniels> pitti: (this is xserver-xfree86-dbg, right?)
<pitti> daniels: oh, no
<pitti> daniels: xorg
<daniels> sorry
<daniels> yeah, I kinda need XFree86 to debug the problem any further
<pitti> daniels: downloading...
<daniels> (i suspect that pInt10 == 0 for some bizzare reason on xorg)
<pitti> what a pity that it removes my shiny new xserver-xorg :-)
<daniels> heh
<daniels> oh, hold on
<daniels> the BIOS never gets found
<daniels> ARGH.
<pitti> ?
<daniels> don't worry about -dbg, sorry
<pitti> okay
<daniels> sigh
<pitti> anything else I can do for debugging that?
<daniels> i'll just give you a radeon_drv for xorg with lots of debugging
<daniels> wait until my build finishes ;)
<pitti> okay
<pitti> btw, girlfriend alert in about 40 minutes :-)
<daniels> heh
<daniels> that's possibly the one advantage of being on the other side of the world -- uninterrupted hacking
<pitti> ;-)
<daniels> otoh, i'm not sure it outweighs the negatives
<pitti> well, it's a tradeoff - but I think doing other stuff than _only_ hacking, at least at the weekend, has its good sides
<daniels> yeah
<daniels> absolutely
<daniels> but while I am over the other side of the world and doing not a whole lot much else, could you please throw up your Xorg.0.log? ;)
<pitti> I'm just behind a NAT, so I cannot easily give you an account here
<daniels> yeah, that's fine
<pitti> daniels: well, if you do need an account for debugging, I can dig an SSH tunnel through my server
<lamont> Keybuk: btw, zsh and screen want some keybuk-love
<daniels> pitti: nah, it's OK thanks
<daniels> pitti: plus, you don't want me debugging X on your box, just ask Kamion :)
<pitti> daniels: you mean I shall backup my stuff first? :-)
<daniels> pitti: his face went white in Oxford when I was in the middle of debugging something, and the screen suddenly went blank for a few seconds
<daniels> pitti: nah, it'll just be unusable when I keep on starting X
<pitti> daniels: I wouldn't be here anyway, so I could not frighten
<daniels> ahr
<pitti> but one after the other
<daniels> if it's still a problem in a month, I'll just borrow your iBook or Kamion's Powerbook
<pitti> daniels: go and visit .dk a bit
<pitti> daniels: sure, in .es it will be easier
<amu> daniels: yippi, xorg runs, the problem was /etc/X11/X wasn updated, if i link it by hand to xorg, without any configuration, and run startx, it works well
<pitti> daniels: maybe this time I can actually keep and use my crossover cable :-)
<daniels> heh
<daniels> amu: oh, right
<daniels> amu: rock
<pitti> daniels: last time, I borrowed it to somebody and never found it 
<daniels> amu: seems like XFree86 was loading X.Org modules?
<daniels> pitti: ugh
<daniels> pitti: i blame bob2
<pitti> daniels: nevermind, I got a new one in the meantime :-)
<daniels> pitti: yeah, I've been seeing a fair bit of Kbenhavn :) very, very nice place
<daniels> pitti: ahr
<pitti> daniels: make sure you enjoy the weekend with fabbione 
<pitti> daniels: I mean APART from your laptop :-)
<daniels> pitti: heh :)
<amu> daniels: dont think so, Xfree was totally removed by xorg
<daniels> pitti: yeah, I totally will
* lamont must go get ready for his long drive tomorrow
<lamont> bbl
<daniels> amu: and you didn't have xserver-xfree86-dbg or anything installed?
<amu> now xorg & xorg-dbg 
<daniels> elmo: ping
<amu> rc  xserver-xfree8 4.3.0.dfsg.1-6 the XFree86 X server
<elmo> daniels: ?
<lupus_> there are xorg packages?
<daniels> elmo: how much ice cream would I need to buy you for you to test whether or not xorg works on your powerbook? (i very, very strongly suspect the answer is yes)
<fabbione> amu: did you upgrade from sarge/sid or from warty?
<pitti> daniels: "yes" as a reply to "how much"?
<fabbione> yes = a lot ;)
<amu> fabbione: a new & clean warty installation, upgraded to hoary
<fabbione> amu;
<daniels> pitti: yes -> it will almost certainly work
<fabbione> the upgrade makes sure to change /etx/X11/X
<fabbione> if it didn't that something went wrong from the beginning
<elmo> daniels: dude, I'm 200 miles away from my desktop, my powerbook is my only computer right now
<daniels> elmo: uhm
<daniels> elmo: i'm pretty sure it will work? :)
<pitti> elmo: works fine on iBook G4 (Radeon 9200)
<Keybuk> lamont: keybuk love?
<daniels> elmo: works on amu's as well
<daniels> elmo: just need a last datapoint
<daniels> elmo: but if you want to do it later that's cool also
<elmo> daniels: I'd really prefer to wait till I'm home (tomorrow) if you don't mind - I've just got too much to do at the DC to throw in 'upgrade to hoary and install a new X' to the mix
<daniels> elmo: sure, that's cool.  cheers.
<daniels> (where are the other members of the fabled powerbook cabal when you need them?)
<amu> fabbione: hmm it was like this, probably my mistake was running apt-get install xorg-dbg
<pitti> sjoerd: http://www.piware.de/pmunt-head.tar.gz
<pitti> sjoerd: have to go now, gf calls :-)
<fabbione> amu: that's why i posted a specific procedure :-)
<sjoerd> pitti: nice timing i just wanted to ask you :)
<pitti> sjoerd: I'll return to my computer in about an hour, I suppose
<sjoerd> 404
<sjoerd> argh
<sjoerd> daniels: i've got one, it just doesn't run ubuntu
<amu> fabbione: are there other reports?  except me?
<daniels> sjoerd: how do you feel like potentially breaking it?
<sjoerd> daniels: not a big problem, but i'm leaving for home now
<sjoerd> daniels: be back in an hour or two
<fabbione> amu: nope
<sjoerd> later
<daniels> sjoerd: cool, thanks
<lamont> Keybuk: monster-merge was the last upload of the package, which is ftbfs on 2 (zsh) or 3 (screen) architectures
<Keybuk> oh, file bugs on me
<Keybuk> I'll look over the weekend
<lamont> Keyok
<lamont> damn blind tab-typing
<Keybuk> there is no "ok", so I can never be Keybok :(
<daniels> keybot?
<lupus_> bleh
<lupus_> why is openoffice 2.0 devel in rpm :(
<lupus_> I want deb packages :p
<lamont> Keybuk: that's key<tab>ok
<lamont> because, dammit, nicks should be unique in the first 3 chars...
<lamont> keybuk: actually, screen isn't you
<lamont> mdz: please sync bug#269366 from debain
<lamont> debian
<lamont> sigh
<mdz> lamont: it's already there
<lamont> seb128: would arts be you as well?
<lamont> mdz: color me blind
<seb128> lamont: not really
<lamont> seb128: checking for Qt... configure: error: Qt (>= Qt 3.3) (library qt-mt) not found.
<lamont> guess I'll look at the configure output
<zul> so any kde support yet?
<lamont> zul: no plans for kde to be 'supported' on ubuntu that I know of, but it's known to work on warty/i386
<lamont> ppc needs help
<zul> because im looking for a way to help out
<lamont> zul: current blocker for kde/hoary is arts, which is FTBFS on i386&ppc
<zul> ftfbs?
<lamont> fails to build from source
<zul> ah..
* lamont just tossed them back into the blender, will look at them later today, possibly
<lamont> unless someone else beats me to it
<lamont> (arts is main, so I can play with it... :-)
<lamont> sbcl, cmucl, ghc5 bootstrapped on i386
<pitti> Hi mdz!
<mdz> morning
<seb128> hi mdz 
<thom> morning oh fearless leader
<seb128> mdz: we have already get several dups on bugzilla/list for #2384 this week, I think we should consider to upload the fix in warty
<daniels> morning mdz
<mdz> seb128: if you would like to do a warty-updates upload, the patch looks safe to me
<seb128> ok thanks
<fabbione> hey mdz
<fabbione> mdz: can you test the patch i sent about the xml file please?
<fabbione> mdz: and let me know if that fixes the problem for you?
<elmo> mdz: why's 3118 assigned to me?
<mdz> fabbione: yes, I need to boot one of the machines
<mdz> elmo: because it was fixed in Debian and waiting for the new package to come in
* fabbione just got his sparc station back!
<fabbione> WARTY TIME!
<lamont> fabbione: warty or hoary?
<lamont> hoary is _MUCH_ easier to bootstrap./
<fabbione> lamont: well... 
<fabbione> HOARY TIME!
<lamont> LOL
<lamont> fabbione: start with a current sid chroot.  Build everything once.  use that archive to build a new chroot, and build everything there.
<fabbione> i need to mount the table first
<lamont> then get d-i working
<fabbione> lamont: stop.. i need to first find a place where to mount it
<fabbione> install it
<fabbione> create the chroots
<fabbione> and so on..
<lamont> lol
<fabbione> it will take some time
<fabbione> since i killed my sparc mirror recently.. i think
<lamont> fabbione: that was the 20 second version of the complete instruction set.
<fabbione> lamont: ahah i know :-)
<lamont> like I said, hoary is much easier.
<fabbione> i need to learn the way of sbuild first
<lamont> warty requires finding the right magic snapshot.debian.net spot, etc...
<fabbione> and wait daniel buildd to finish
<tseng> is hoary semi safe atm?
<lamont> fabbione: if it's still being annoying next week, I can give you what I'm using on ia64...
<lamont> tseng: some folks are self hosting.  safe is a relative term,.
<fabbione> otherwise i won't have space where to store the debs
<thom> tseng: it's fine here...
<daniels> fwiw, I've given up on attempting to read /var/mail/daniels with mailx
<tseng> ill give it a go perhaps
<lamont> daniels: lol
<daniels> doesn't scale well to 781 w-b/buildd messages
<fabbione> lamont: nahh i will figure my way around it and bug you if i am really depressed :)
<thom> heh
<daniels> 492 built, 381 to go
<fabbione> lamont: also.. next week is still Xsprint
<fabbione> so i won't do anything fancy until the end
<lamont> fabbione: yeah - I'm doing it without the benefit of wanna-build/buildd.  just good old sbulid and quinn-diff
<lamont> and a shell script or two.
<lamont> stage1 713
<lamont> stage2 820
<lamont> changes files on ia64
<fabbione> lamont: i already some stuff scripted, but it uses pbuilder
<fabbione> lamont: i would really like to find the time to learn the way of sbuild properly
<daniels> sbuild -d h xorg_6.8.1-0.2
<daniels> with -A if you want it to build arch: all stuff
<lamont> fabbione: on my list of things to do is get our versions of sbuild, buildd, buildd-config, and gcc-opt consistant and happy for hoary
<fabbione> lamont: i am not sure how much work X.org will give us in the next weeks, but if it is relatively low i might join you in preparing these things
<lamont> seb128: you're not going to be happy with e-d-s...
<fabbione> lamont: i have been doing X without any break for too long and i start to feel a bit tired of it
<fabbione> i need a little "brain break"
<lamont> fabbione: the biggest issue is that buildd-config conflicts with debootstrap now (both deliver warty.buildd...)
<seb128> lamont: I'm building again, but in a pbuilder now
<lamont> gcc-opt needs a little bit of love to do things a bit better than it does.
<lamont> seb128: same error, fwiw
<seb128> lamont: all the GNOME packages update the control with control.in in the clean target
<seb128> lamont: and the stupid eds doesn't
<daniels> daniels@trider-g7:~/build$ grep 'currently building' build-progress
<daniels> openoffice.org_1.1.2-2ubuntu6: currently building
<daniels> oh god.
<seb128> lamont: just figured that I need to debian/rules update-control
<lamont> daniels: hehe
<daniels> fabbione: don't even breathe on trider, dude, I want the buildd to finish before I leave :P
<lamont> daniels: openoffice.org:         06:29:18 (1 entry, sigma 00:00:00)
<lamont> that's on our buildds
<seb128> are we going to sync oo.o 1.1.3 ?
<lamont> will require a merge, of course.
<daniels> lamont: oh my god.
<lamont> daniels: that's building arch-all as well
<thom> seb128: yeah, it's on my list
<fabbione> carlos: ping
<lamont> without arch all, it's more like 4 hours.
<seb128> thom: ok :)
<lamont> openoffice.org:         04:38:19 (2 entries, sigma 02:21:50)
<lamont> that's ppc
<fabbione> daniels: no no.. i am not going to add more load on the trider-g7
<daniels> lamont: phew, I don't think we're building with -A here
<lamont> slower, but not building arch-all
<fabbione> lamont: my machine is slow.. there is nothing to do about it atm
<fabbione> and elmo doesn't want to gimme concordia
<daniels> oh cool, OOo failed, seemingly
<lamont> hehe
<daniels> /proc needs to be mounted
<lamont> daniels: yes
<thom> daniels: yeah
<thom> OOo is no fun
<lamont> several things require /proc in the chroot
<thom> WTF? this is fucking weird - that fakeroot bug only happens in a chroot
<fabbione> lamont: we should write a policy for it
<carlos> fabbione: pong
<daniels> lamont: yeah, I've got about 5/6 failed on /proc
<fabbione> carlos: do you have time to do a test for me?
<Mithrandir> thom: no, not really.. it shouldn't.
<thom> on my amd64, i can build just fine on a hoary system, but in a chroot on the same system i get the segfault
<carlos> fabbione: if it does not requiere to reboot my computer, yes
<fabbione> carlos: no reboots, probably (not even sure) a logout/login on X
<lamont> applying patch 21-asn-negative-length to ./ .../usr/share/dpatch/dpatch-run:
<lamont> +/usr/share/dpatch/dpatch-run: No such file or directory
<lamont> bad squid
<thom> Mithrandir: there is something very freaky going on here
<carlos> fabbione: ok, tell me
<Mithrandir> thom: kernel issues, possibly?
<lamont> fabbione: I have "so you want to port ubuntu to arch X, supported by debian" and "so you want to build your own bits" papers to write
<thom> Mithrandir: i guess it must be, but why only in a chroot
<fabbione> carlos: as root edit the following file: /usr/X11R6/lib/X11/locale/locale.alias
<fabbione> carlos: go to en_GB section
<Mithrandir> thom: make sure devpts is mounted
<lamont> thom: fwiw, still dies with a good amd64 system outside the chroot...
<carlos> fabbione: I'm there
<thom> Mithrandir: can you do that on ravel?
<fabbione> carlos: and add en_GB.UTF-8<tab_as_manytimes_as_needed>en_GB.UTF-8
<fabbione> save the file
<pitti> elmo: some food for you is arriving :-)
* pitti ducks
<fabbione> carlos: you might have to logout and login again to see if that fixes the problem
<daniels> lamont: so, er, see you in February?
<Mithrandir> thom: done
<lamont> Feb?
<daniels> lamont: the papers
<carlos> fabbione: I have already an entry for en_GB.utf-8
<thom> Mithrandir: still segv
<lamont> heh - hoping to get them written this month
<carlos> en_GB.utf8                                      en_GB.UTF-8
<lamont> _before_ hoary freezes... it's harder if we froze
<Mithrandir> thom: what is the command line you're using?
<daniels> lamont: a friend of mine who admins huge clusters asked about a very small, specific problem, and got the 'so, you've just bought a 300-node cluster' manual
<lamont> it's more of a cookbook..  many steps are prefaced by "do whatever it takes to...."
<thom> Mithrandir: fakeroot dpkg-shlibdeps debian/mozilla-firefox/usr/lib/mozilla-firefox/libsmime3.so >/dev/null segfaults, dropping the fakeroot from the front doesn't
<lamont> daniels: heh
* lamont must run, back in a few hours
<Mithrandir> thom: weird; running it as root doesn't segfault
<thom> no
<fabbione> carlos: it's case sensitive
<fabbione> carlos: note the UTF8
<carlos> ok
<thom> Mithrandir: you see the segfault as a normal user though, right?
<carlos> I cannot logout at this moment, but then I could test other thing...
<mdz> fabbione: your patch fixes the bug for me as well
<fabbione> mdz: cool.. because it's already in for 0.3 :-)
<carlos> hhm, ok I need to logout/login
<mdz> fabbione: do you have a todo list for what needs to be done before uploading to hoary?
<daniels> mdz: yes
<fabbione> mdz: yes
<Mithrandir> thom: yes.
* Mithrandir installs strace
<fabbione> mdz: we need to have the buildd run completed and that is happening in parallel to:
<daniels> Mithrandir: aww, you broke up the flow
<fabbione> 1) branding
<fabbione> 2) patch reviewing
<fabbione> 3) import stuff from Debian trunk
<fabbione> 4) fix ati driver for ppc
<daniels> mdz: a) see buildd run out, b) branding, c) patch audit, d) merge fwpll patch for ati/powerpc, e) break out shared libraries, f) trunk merge (no particular order)
<fabbione> 5) prepare all the other packages that needs to be fixed and go in in sequence
<daniels> g) steal patches from 6.8 branch as needed
<fabbione> well
<fabbione> daniels was typing faster :-)
<daniels> although g is not strictly necessary pre-hoary as it's not an orginisational thing
<fabbione> but that's the stuff more or less
<daniels> or however you spell the stupid word
<fabbione> z) get gtk a clue on copy&paste
<fabbione> hem give
<mdz> z) can wait :-)
<Mithrandir> thom: something is on amusingly large amounts of crack:
<daniels> ) murder xprint and xaw in their sleep
<Mithrandir> fakeroot sh -c 'LD_ASSUME_KERNEL=2.4.1  dpkg-shlibdeps debian/mozilla-firefox/usr/lib/mozilla-firefox/libsmime3.so > /dev/null'
<Mithrandir> /usr/bin/perl: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
<fabbione> mdz: well that's why it is marked z
<daniels> (i'm told this sorts after z in dansk)
<mdz> fabbione: yes, but the list was supposed to be prerequisites for hoary
<daniels> ) make default implementation build really quicker
<daniels> and of course, ') steal concordia
<thom> Mithrandir: um, rock
<Mithrandir> thom: so it might be TLS-related.. somehow.
<fabbione> mdz: dude.. we are 3 days ahead of work and we are still working hard. let's get as much as we can while daniels is here
<fabbione> mdz: some of the stuff like the ati driver for ppc is important
<thom> Mithrandir: *covers eyes*
<fabbione> mdz: we will hit the archive around tuesday
<mdz> fabbione: agreed
<fabbione> mdz: so that we will have 3 more days to crack together
<daniels> mdz: don't forget also that we still have things to do to ease the transition around grumpy
* Mithrandir gives thom a large pile of crack.
<fabbione> mdz: but not before buildd will finish
* daniels stares at the shiny scrolling output in the other xterm.
<daniels> ... concordia ...
<thom> Mithrandir: oh no, amd64 port problems are all you :-)
* thom hands the large pile of crack back
<sjoerd> daniels: still interested in breaking my system ? :)
<carlos> fabbione: same problem
<daniels> thom: so who's maintaining firefox onw?
<Mithrandir> thom: I never asked for TLS to be turned on for amd64.  That's just crackful. :)
<daniels> sjoerd: fo'shizzle
<fabbione> carlos: ok.. sorry.. my ideas are limited.. but it's an harmless gtk error
<thom> daniels: me. Mithrandir just needs to fix fakeroot :-)
<fabbione> carlos: coming from xlibs
<thom> Mithrandir: *g*
<Mithrandir> thom: I seriously need to kill you sometime.
<carlos> fabbione: I know it's harmless, don't worry
<Mithrandir> thom: I'll see what I can do.
* thom promises to procure alcohol in large amounts
<daniels> mdz: oh, and to drag a list discussion in here
<thom> (assuming i don't lose all my cash playing poker with wil wheaton in vegas)
<daniels> mdz: the most amusing part of splitting the modular tree right is when you realise that four libs use internal (i.e. FooI.h) Xt headers
<daniels> mdz: so you actually need to install the entire suite of 'internal' Xt headers in its -dev package for craptastic cruft like Xaw to build
<Mithrandir> thom: can't you bring some real beer from .uk?
<daniels> thom: have they ever considered going anywhere else?
<Mithrandir> thom: if you do that, I might forgive you.
<thom> Mithrandir: certainly
<daniels> thom: i mean, surely you'd get more work done if it wasn't for the prettyflashyshinylights
<thom> daniels: seems not
<daniels> Mithrandir: why from .uk? wouldn't it be easier to just get it straight from .au?
<Mithrandir> daniels: you make decent beer in .au?
<daniels> Mithrandir: fo'sho
* thom falls off his chair laughing
<Mithrandir> daniels: then you bring some as well, next time, and we'll see.
<Mithrandir> .no doesn't make much good beer, sorrily.
<daniels> Mithrandir: er, I won't be in Australia in between now and .es
<Mithrandir> daniels: then get some other aussie to bring some, or bring it for decconf+1
<thom> right, fireworks time
<thom> ciao
<daniels> Mithrandir: we won't need to bring it for december+4 (tentatively titled 'april'), seemingly
<daniels> thom: seeya dude
<daniels> Mithrandir: although canberra isn't a part of australia, so we'll still need to import the coopers ;)
<Mithrandir> daniels: whatever.  Bring me beer! :)
<daniels> Mithrandir: it shall be done
<Mithrandir> thom: it seems fakeroot messes around with LD_LIBRARY_PATH and preloads stuff..
<Mithrandir> LD_PRELOAD=/usr/lib/libfakeroot.so.0 LD_TRACE_LOADED_OBJECTS=1  /lib64/ld-linux-x86-64.so.2 debian/mozilla-firefox/usr/lib/mozilla-firefox/libsmime3.so
<Mithrandir> Segmentation fault
<Mithrandir> boom
<Mithrandir> looks like a normal bug somewhere in fakeroot to ge.
<Mithrandir> s/ge/me
<pitti> lamont: got half a minute?
<lamont> literally
<pitti> lamont: I'm afraid the debs of my squid upload have vanished somewhere
<pitti> lamont: I uploaded to the security queue over an hour ago, and the accepted queue is empty
<mdz> seb128: firefox doesn't seem to want to open .pls files with rhythmbox, but with totem instead
<mdz> seb128: I didn't think that totem could even read .pls files, but surely rhythmbox is a better default
<mdz> seb128: is this a firefox issue or a rhythmbox one?
<seb128> mdz: neither of them, that's the mime system
<seb128> Desktop files associated with audio/x-scpls
<seb128> XMMS.desktop
<seb128> totem.desktop
<seb128> rhythmbox.desktop
<seb128> here
<seb128> and it picks the last one in the alphabetic list IIRC
<mdz> hmm
<mdz> how can we fix it?
<seb128> mdz: could you add a audio/x-scpls=rhythmbox.desktop in /etc/gnome/defaults.list ?
<seb128> and test if that fixes the problem
<fabbione> pitti: ping
<pitti> fabbione: pong
<mdz> seb128: ah, defaults.list has audio/x-scpls=totem.desktop
<fabbione> pitti: 2327, it's probably time to take a look to it.
<seb128> mdz: ok, that's it probably (if firefox uses the mimesystem correctly)
<fabbione> pitti: i would like you to discuss it with the ppc community and come up with the proper fix/solution
<mdz> seb128: yes, that fixes it
<seb128> ok
<seb128> please open a bug on desktop-file-utils as a reminder
* lamont really gone for a while
<mdz> ok
<seb128> I'll fix that in the next upload
<pitti> fabbione: can we do that maybe at the mailing list? We might reach a broader audience there
<fabbione> pitti: sure.. do it in the way you prefer, but my knowledge of ppc is limited
<fabbione> pitti: i need someone that understand the problem 100% to talk with the ppc community
<pitti> fabbione: okay, I will write a mail with the details
<fabbione> and i am not in the position to do it
<pitti> fabbione: I think I have a decent understanding of the problem and impacts
<sjoerd> daniels: sig11 ;)
<fabbione> that's why i am asking you
<daniels> sjoerd: ugh
<pitti> fabbione: added to my ~/.todo :-)
<daniels> sjoerd: do you have xserver-xorg installed?  what version?
<sjoerd> 6.8.1-0.2
<daniels> sjoerd: i suspect it's launching the xfree86 server instead -- with Debian, you might need to force Xorg
<daniels> oh wow
<daniels> what happens if you run sudo Xorg :1 -ac -verbose 9999999999999, from a terminal
<sjoerd> it complains about unresolved in libGLcor.a
<fabbione> sjoerd: that's normal
<fabbione> nothing to worry about it
<Mithrandir> fabbione: do you know if anything has happened to the sparc port?
<ogra> hi guys
<Mithrandir> I recently came across a small cache of U5 and similar boxes.
<daniels> sjoerd: if you could put the full Xorg.0.log somewhere, that would be rad
<daniels> Mithrandir: well, fabbione just got his sparc back today
<daniels> I have an U5 at home too that I should get going ... after Christmas,
<sjoerd> ah i had the wrong resolution configured still..
<sjoerd> now it starts, but the screen turns white slowly
<ogra> i'm looking for a method to get a udi listing for hal on the commandline or in perl ....
<fabbione> Mithrandir: i got my sparc back today
<daniels> sjoerd: ... wha?
<daniels> sjoerd: a slow fade to white?  does it stay at full white?
<sjoerd> ogra: lshal
<fabbione> Mithrandir: planning to put it online sometimes during the weekend
<ogra> sjoerd: thanks ;)
<Mithrandir> fabbione: ok, do you know if we're aiming for a hoary sparc?
<sjoerd> daniels: slow fade to all kind of colors 
<daniels> sjoerd: bonnnng ... you don't have any horizsync/vertrefresh/whatever lines in?
<daniels> sjoerd: does Option "UseFWPLL" help?
<daniels> sjoerd: can you put your Xorg.0.log up somewhere?
<daniels> (does your mother's maiden name start with a F, and was she born on a Sunday?)
<fabbione> Mithrandir: well lamont said that it is much easier to bootstrap hoary than warty.. so i guess yes
<Mithrandir> fabbione: cool. :)
<fabbione> Mithrandir: once i have the buildd at stage2 i will start uploading the packages somewhere
<fabbione> Mithrandir: the problem is d-i
<Mithrandir> fabbione: so you're setting up a buildd and such?
<fabbione> having only one sparc is difficult to test
<fabbione> Mithrandir: yup
<Mithrandir> I can get you more sparcs easily, but I'm not sure I can give away ultras.
<Mithrandir> so that's not too usable
<fabbione> Mithrandir: for me console access would be fine
<sjoerd> daniels: removed modelines, added UseFWPLL true.. still the same
<Mithrandir> fabbione: that should be easy to get.
<fabbione> Mithrandir: and a setup where i can change the kernel/initrd.gz to boot via network is enough
<sjoerd> daniels: do you have ipv6 or just ipv4 ?
<daniels> sjoerd: could you please paste your full config and log?
<daniels> yah, ipv6
<Mithrandir> fabbione: I really want to get that box set up somewhere which is !bedroom, though.
<Mithrandir> or I think my gf will really, really, _really_ kill me.
<fabbione> Mithrandir: eheheh
<seb128> lamont: ah ah, evolution-data-server built this time :p
<fabbione> Mithrandir: it will take quite sometime to reach phase2
<fabbione> so there is no rush.. trust me
<Mithrandir> fabbione: Karianne and I are moving together in the summer and we're certainly going to have a place for servers (she's not as geeky as I, but fairly close), so at least then it should be fine.
<fabbione> ehehe cool!
<fabbione> i am happy about that
<sjoerd> daniels: http://spring.luon.net/~sjoerd/Xorg.1.log
<sjoerd> daniels: and http://spring.luon.net/~sjoerd/xorg.conf
<daniels> (WW) RADEON(0): You may not have enough display bandwidth for current mode
<daniels> If you have flickering problem, try to lower resolution, refresh rate, or color depth
<daniels> does switching to a lower depth help?
<sjoerd> 16 bpp same problem
<daniels> sjoerd: try removing HorizSync/VertRefresh lines
<Mithrandir> do we have madison or something like it?
<sjoerd> daniels: same with twho black lines in the middle
<froud> Under what group would you define training materials in a spec file "Documentation / HTML" or "Documentation / Other"?
<sjoerd> oh UseFBdev true works :)
<daniels> sjoerd: ... hm
<daniels> pitti: ping
<mdz> seb128: another problem I have is that when rhythmbox finishes playing a stream over http, it pops up an error dialog "Unexpected end of stream!" and stops
<sjoerd> strange with Xfree UseFBDev gave troubles
<Mithrandir> thom: does LD_PRELOAD=/usr/lib/libfakeroot.so.0 LD_TRACE_LOADED_OBJECTS=1  /lib64/ld-linux-x86-64.so.2 debian/mozilla-firefox/usr/lib/mozilla-firefox/libsmime3.so segfault only in the chroot?
<mdz> seb128: even though the end of the stream is actually expected
<seb128> mdz: do you have a stream uri to test that ?
<mdz> seb128: I can provide one
<sjoerd> gotta eat
<daniels> sjoerd: i'll throw you a new radeon_drv in a sec
<daniels> seb128: please ask owen taylor about it
<daniels> he knows more about this stuff than myself and fabio have forgotten
<mdz> seb128: I looked at the code, and it seems that it is written to always give that error when a stream ends, without even checking the reason
<daniels> what's more, he's the main gtk guy ;)
<mdz> seb128: I think because it is written for internet radio, rather than streaming files over http
<seb128> mdz: I'll update rb from 0.8.5 -> 0.8.8 now, let's see if that's fixed with the update first
<seb128> mdz: probably yes
<seb128> daniels: ok
<seb128> daniels: but I doubt that's a GTK+ bug, owen would have fixed it upstream
<daniels> seb128: selections and the interactions to do with them are notoriously complex
<daniels> if it was a xorg 6.8 thing, a lot of people would've bitched very loudly
<seb128> daniels: ok, will ping owen about this, that's the best to do :)
<seb128> daniels: I've no idea on how to debug this
<daniels> i have no will to
<seb128> he he
<daniels> seriously, in between Xaw/Xt and GTK ... it's massively complex
<seb128> but somebody will have to ... hopefully owen will be helpful :)
<daniels> otaylor will know it an order of magnitude better than I
<daniels> yeah, he's a very, very smart guy
<mdz> seb128: I also discovered some confusing behaviour in the process of testing this
<seb128> oh ?
<mdz> seb128: when the error dialog comes up, it appears on the current desktop
<seb128> hum, why don't we have a bug report about the rhythmbox merging ?
<mdz> and if rhythmbox is elsewhere, the window becomes unresponsive
<seb128> unstable has 0.8.8 and hoary 0.8.5
<seb128> mdz: ok, that's happening for several app :/
<mdz> I would expect that if the rhythmbox window is hidden, and I click on the panel icon, it would bring up both the window and the error dialog together
<seb128> I've it frequently with epiphany too
<seb128> yeah
<mdz> I thought this worked in the past, but maybe I am thinking of something else
<sjoerd> daniels: k
<pitti> daniels: pong, sorry, phone
<mdz> seb128: hmm, we need a debhelper merge in order to build it
<pitti> lamont: may I bother you again? This time, squid did not build on amd64... (soooooory)
<seb128> mdz: hum, no. I'll merge it now
<pitti> lamont: at least, it was not uploaded to the queue
<seb128> mdz: why do we need a debhelper merge ?
<mdz> dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 4.2.22) 
<seb128> oups
<mdz>  debhelper | 4.2.21ubuntu1 | http://archive.ubuntu.com hoary/main Sources
<seb128> ok, I've already merged it in fact
<daniels> pitti: no worries
<seb128> and I've bumped the Build-Deps too high
<seb128> 4.2.21 is enough
<Mithrandir> ok, the segfault is TLS-related.
<sjoerd> daniels: starting aterm with the composite extension on crashes the server btw..
<daniels> sjoerd: awesome
<daniels> not surprising though
<sjoerd> daniels: that's just generic composite immaturity or .. ?
<cenerentola> jdub: are you there?
<ChrisH> fabbione: I have set up an IRC log of the #ubuntu-* channels on http://workaround.org/cgi-bin/irc (beta). sivang told me that he asked you to put up a log. He didn't know I was working on it already.
<tseng> sorry if i missed this somewhere, but was was the rationale for choosing bogofilter over spamassassin?
<tseng> bogofilter so far has been alot less successful for me
<tseng> after a few weeks of training
<mdz> faster, simpler, more stable and more supportable
<mdz> seb128: rhythmbox ftbfs
<mdz> http://people.ubuntulinux.org/~lamont/buildLogs/r/rhythmbox/0.8.8-1ubuntu1/
<mdz> seb128: it seems the build-depends change did not take effect
<seb128> http://people.ubuntulinux.org/~lamont/buildLogs/r/rhythmbox/0.8.5-1ubuntu2/
<seb128> are successful
<seb128> 1 was the old one
<seb128> 2 is today's one
<mdz> 0.8.8 > 0.8.5
<seb128> hum
<mdz> After installing, the following source dependencies are still unsatisfied:
<mdz> debhelper(inst 4.2.21ubuntu1 ! >= wanted 4.2.22)
<mdz> Source-dependencies not satisfied; skipping rhythmbox
<seb128> rhythmbox_0.8.8-1ubuntu2_source.upload
<seb128> I've uploaded this one
<seb128> one hour go
<seb128> s/go/ago/
<seb128> the 0.8.8-1ubuntu1 is one week old
<seb128> 
<seb128> hum, evolution 2.1.0 is ftbfsing
<stratus> Are you planning to put beagle in hoary? I guess not because it's buggy and written in c#, but...
<tseng> i dont think beagle is hoary material, but id like to see the deps go in so its not such a PITA to build
<stratus> tseng, oic
<cenerentola> jeff:jdub?
<seb128> tseng: what's missing for the deps ?
<stratus> mono?
<seb128> mono is in
<stratus> universe
<stratus> seb128, read: http://www.ubuntulinux.org/wiki/BeagleInstallHowto
<seb128> stratus: using universe is not a PITA for the build imho
<seb128> stratus: tseng was probably speaking about extra stuff missing
<stratus> seb128, maybe inotify.
<daniels> sjoerd: generic composite immaturity, yah
<sjoerd> daniels: did you have a new radeon_drv to test or ?
<daniels> yeah, just finished building while I was out to dinner
<daniels> http://people.ubuntu.com/~daniels/xorg/radeon_drv.o
<daniels> there you go.  if your cat spontaneously catches fire because of that driver, not my fault, and all that.
<daniels> you might want to try various combinations of usefwpll and/or usefbdev
<daniels> when pitti comes back, if someone could point him to that and tell him that should work with *just* usefwpll, that would be great, thanks
<daniels> right now i'm off to the hotel to crash into bed
<daniels> very, very tired
<daniels> goodnight all
<sjoerd> daniels: thanks
<sjoerd> daniels: have a good night of sleep :)
<daniels> no worries, good luck
<daniels> i sure will
<daniels> and a good morning of sleep, and probably a good afternoon of sleep if I don't get bed sores by then ;)
<sjoerd> hehe
<mdz_> seb128: strange; I am not able to reproduce that glade-2/gnomedb thing
<seb128> mdz_: weird, the soname has changed apparently ...
<seb128> $ ls /usr/lib/libgnomedb*
<seb128> /usr/lib/libgnomedb-2.so.1  /usr/lib/libgnomedb-2.so.1.1.0
<mdz_> zsh: no matches found: /usr/lib/libgnomedb*
<mdz_> seb128: on my system it is not even linked with libgnomedb
<seb128> oh
<seb128> you don't have the -gnome version ?
<seb128> glade-gnome-2
<mdz> ah
<mdz> I installed glade-2 because that is where the bug was reported
<seb128> hum, I'm wondering why the rhythmbox build logs are not here
<seb128> I've uploaded the package like 2 hours ago
<mdz> I did not see it on hoary-changes
<seb128> Accepted:
<seb128> rhythmbox_0.8.8-1ubuntu2.diff.gz
<seb128> Announcing to hoary-changes@lists.ubuntu.com
<seb128> I got the ACCEPTED mail
<seb128> and I've it in my hoary-changes folder
<seb128> Fri,  5 Nov 2004 18:30:03 +0000 (GMT)  (19:30 CET)
<Mitario> hi everyone
<Calvin> anyone knows where i can get hold of fabbione's fix : xfree86_4.3.0.dfsg.1-6ubuntu24 ??
#ubuntu-devel 2004-11-17
<mdz> seb128: hmm, still no rhythmbox build logs
<mdz> lamont: ?
<seb128> mdz: yeah, that's weird
<mdz> lamont called, he is involuntarily offline
<seb128> ok
<mdz> no idea why rhythmbox is missing, though
<seb128> perhaps I should try to upload it again
<seb128> but it'll probably get rejected if the previous has been accepted
<mdz> yeah, the source is fine
<thom> Mithrandir: belatedly, yes. it segfaults only in the chroot
<jdub> grr.
<jdub> anyone else having problems with archive.ubuntu.com?
* jdub suspects it might be a local problem though
<mdz> jdub: no problems
<jdub> thanks
<jdub> hrm, wonder if it does ftp
<jdub> ahr, sweet
<jdub> mdz: ok, so how do we deal with the calendar packages issue?
<jdub> do we just sync them from warty?
<mdz> jdub: that's still an elmo question
<mdz> jdub: I think he's out, so send email
<jdub> ok
<mojo_> where is seb128??
<mojo_> seb128, where are u?
<mojo_> you haven't changed the link of the Evolution Shortcut mate, it's still evolution-2.0!!
<tseng> mojo_: works for me
<mojo_> tseng: have u updated to latest?
<mojo_> tseng: it's 2.10 packages
<mojo_> tseng: and seb128 hasn't changed the shortcut from evo-2.0 to evo-2.2
<tseng> yes..
<mojo_> tseng: click on the icon of Evo mate
<tseng> i did, mate
<tseng> lrwxrwxrwx  1 root root 13 2004-11-05 17:05 /usr/bin/evolution -> evolution-2.2
<tseng> 2.1.0-0ubuntu2(/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_main_binary-i386_Packages)(/var/lib/dpkg/status)
<mojo_> tseng: heh?
<tseng> heh yourself
<mojo_> tseng: mine still links to 2.0
<mojo_> tseng: i think I should restart the box
<tseng> im not sure how rebooting will repoint a softlink
<mojo_> tseng: no idea mate, I can fix it easily, but make sure seb128 aware of this
<mojo_> tseng: have u got gtkhtml3.6 installed? (try to remove 3.2 version) and run 'yelp'
<tseng> yes yelp is broken
<mojo_> tseng: thx mate, try run ataxx games mate
<tseng> worksform
<tseng> e
<mojo_> tseng: ???
<mojo_> tseng: darn, lots of programs still use old shit gtkhtml2, I hope they migrate to latest version soon
<tseng> im sure its being worked on
<mojo_> tseng: did u get such msg: FATAL: udev is active on /dev when boot up??
<tseng> i dont believe so
<tseng> you do realize that hoary will be broken
<mojo_> tseng: hehe, I know that it will break, that makes me love it mroe
<mdz> mojo_: the /usr/bin/evolution symlink and the binary it points to are in the same package
<mdz> they cannot be out of sync
<mojo_> mdz: yes, I know but if u check the shortcut of Evolution in Main Menu and in the Panel, u find that seb using evolution-2.0 not evolution
<jdub> only in the evolution mail one
<jdub> which is a local patch
<jdub> mojo_: better than mentioning it here, you should file a bug
<mdz> elmo: well hello
<elmo> ?
<jdub> $ ./universe
<jdub> cabextract
<jdub> ethtool
<jdub> howl-utils
<jdub> mdnsresponder
<jdub> msttcorefonts
<jdub> 
<bob2> not too shabby
<bob2> but you should be using BITSTREAM VERA
<fabbione> morning guys
<bob2> hey fabbione 
<jdub> yo fabbione 
<fabbione> jdub: you can use different versions for warty/hoary
<jdub> $ universe | wc -l
<jdub> 85
<jdub> ^ daily use machine :)
<fabbione> calendar 4.10.<month> for warty
<fabbione> calendar 5.04.<month> hoary
<jdub> fabbione: i know, but i want to know the best solution
<fabbione> that is possible
<jdub> oh right
<fabbione> well i think having two packages with only the version change is the simplest
<jdub> already stuck with the ubuntu-style versioning now ;)
<fabbione> linking across distro is not always the best solution and requires elmo manual help
<jdub> ideally, i'd like to keep the packages the same
<jdub> because they really are the same thing
<jdub> yeah
<mdz> if they are the same, they should be the same
<jdub> yeah
* mdz strokes his beard and reflects on the truism
* jdub strokes his non-imaginary beard :)
<mdz> same situation as when testing and unstable have the same version
<maskie> morning guys --- fyi sabdfl made the front page of the business section of a big daily newspaper here is South Africa yesterday
<jdub> cool
<jdub> marius! of schooltool fame?
<fabbione> huu
<fabbione> nice
<maskie> no ... different one ... but know sabdfl from way back
<fabbione> osti:/usr/src/xorg-6.8.1# dpkg-buildpackage -uc -us -b -B
<fabbione> dpkg-buildpackage: source package is xorg
<fabbione> dpkg-buildpackage: source version is 6.8.1-0.2
<fabbione> dpkg-buildpackage: source maintainer is Fabio M. Di Nitto <fabbione@fabbione.net>
<fabbione> dpkg-buildpackage: host architecture is m68k
<fabbione> MUHA MUHA MUHA :-)
<jdub> maskie: for some reason, there are too many mariuses around the place these days ;)
<maskie> jdub, have noticed ...
<mojo_> can someone check the libgladmm in Synaptic for me? Ver 2.4 is there but not used
<mojo_> libglademm
<bob2> there are multiple versions atm
<mojo_> bob2: thx, my pb
<jdub> i like hoary
<daniels> ok, a request.  if anyone tells anyone using an IGP320/340 chipset to use fglrx, tell them *not* to.  the stock Ubuntu drivers work *fine* with those chipsets, and fglrx does not.  the solution to any problems is not to install fglrx, or SuSE.  please correct anyone saying this (comes up a lot on the forums).  thanks.
* fabbione yawns
<fabbione> m68k is at Makefiles stage :-)
<daniels> let me guess, you kicked off the build last week?
<daniels> hm, back in 20
<fabbione> ehehe
<fabbione> no only this morning
<mjg59> Hrm. Why is sys_mount returning EFAULT ?
<daniels> phat!
<daniels> thom: you can run 'Xorg :1 -ac' with impunity now
<mjg59> Want... crack...
<bob2> you're working on acpi
<bob2> you have all the crack you can eat
<fabbione> gooooody
<fabbione> sparc mirror is done and the sparc is booting :-)
<fabbione> time to install
<fabbione> ok power-off
<fabbione> lom>
<fabbione> LOM event: power off
<daniels> fabbione: awesome :)
<fabbione> too cool :-)
<jdub> fabbione: you're setting up a buildd?
<fabbione> jdub: yes, but not today
<mjg59> fabbione/daniels: What would really, really rock would be a small command-line app that could call the dpms bios routines
<mjg59> So x86 emulation + int 10 code
<fabbione> mjg59: write one for us? ;)
<mjg59> Haha
<bob2> bah
<bob2> new firefox doesn't let me use ctrl-k to nuke lines in next boxes
<mjg59> Gah. Close.
<fabbione> daniels: i am way behind schedule here at home
<fabbione> daniels: do you want to come here after lunch and then we go shopping?
<daniels> fabbione: yeah, sure
<daniels> fabbione: whenever's good for you, just let me know :)
<mojo_> i hope us guys upload the new X.org soon, im dying of patience
<mjg59> Fuck.
<daniels> mojo_: dying of patience?  that's a rare condition
<mjg59> That wasn't the problem at all.
<daniels> mojo_: it will be soon
<daniels> mjg59: OH MY GOD DUDE NO
<daniels> mjg59: please do not encourage that sort of behaviour (userspace int10)
<fabbione> mojo_: when it is ready.
<daniels> mjg59: that said, ddcprobe does VBE calls
<daniels> mjg59: so you could probably steal its code
<mjg59> daniels: Dude, how else can you call the DPMS code?
<daniels> mjg59: most cards seem to have ICan'tBeliveIt'sNotInt10 for accessing VBE
<mjg59> Mm. I'll check ddcprobe, then
<daniels> mjg59: but yeah, fair cop
<daniels> mjg59: what do you want the DPMS code for?
<mjg59> Console blanking
<daniels> ah.
<mjg59> ACPI has no way of blanking the screen
<mojo_> then when can I see a new CD Test for Hoary?
<sivang> tseng : you meant yelp broken on the hoary ?
<daniels> mojo_: there are CDs built already, AIUI
<mjg59> Why the fuck can the kernel not read /sys/block/hda/hda2/dev ?
<daniels> mjg59: bong
<mojo_> daniels: if it's ready, pls give me the link
<daniels> mojo_: not yte.
<daniels> mojo_: if it was ready, there would be links and public announcements
<mojo_> daniels: informe me ok
<daniels> mojo_: there will be next week, sit tight for a few more days
<daniels> mojo_: you will be informed, I assure you
<mojo_> daniels: hehe, thx dude
<daniels> mojo_: (that said, if I /msg'ed everyone who wanted it personally, my wrists would implode)
<mojo_> daniels: lol
<daniels> fabbione: alright, I'm going to go out and find breakfast somewhere -- if you need me in the next 45min or so, SMS me (.au number, on wiki)
<fabbione> ok boot net
<fabbione> Boot device: /pci@1f,0/pci@1,1/network@1,1  File and args: 
<fabbione> 73000 
<fabbione> daniels: no problem... i need to clean the house a bit and mount the table
<fabbione> so take your time
<bob2> mount the table?
<mojo_> fabbione: who's working on the fb GUI boot up?
<bob2> no one, atm
<fabbione> mojo_: Kamion
<mojo_> fabbione: thx
<fabbione> but it's not high priority
<fabbione> meaning that it might or might be not part of hoary
<fabbione> s/might/may
<mojo_> fabbione: that's why I need to rush Kamion
<fabbione> PROMLIB: Sun IEEE Boot Prom 3.10.27 2000/06/22 16:45                            
<jdub> mojo_: no, you don't.
<bob2> mojo_: you can't rush him, he has other things to do
<bob2> mojo_: you can offer to help him, tho
<fabbione> mojo_: it is simply not a goal for hoary
<fabbione> if it will be there good.. otherwise good ;)
<daniels> fabbione: rad
<mojo_> fabbione: my girlfriends refuses to use Ubuntu for Fedora CORE, simply b/c she scares the text init boot up, and just loves something fancy like SuSE or FC
<fabbione> mojo_: rushing people will not change anything.. if you want a GUI installer is much better to offer help, trust me
<fabbione> oh god.. partitioner on serial console at 9600 is a pain
<mjg59> ARGH MORE EFAULTS
<fabbione> actually.. everything on serial console is pain
<bob2> hah, gentoo has weekly rankings for who closed the most bugs
<fabbione> bob2: daniels and i would always be at the bottom of that list
<mjg59> ROCK
* mjg59 wins
<fabbione> hey lamont
<bob2> fabbione: it'd need to be number_of_bugs * difficulty_per_bug * everyone_uses_X_coefficient
<pitti> Hi lamont! Did you get my mail about the failed squid upload? I'm not sure whether I chose the right email address
<fabbione> you should also consider code_complexity
<fabbione> that would kinda allign the situation
<bob2> ah
<sivang> Hi pitti
<fabbione> calculating code complexity is not extremely difficult
<fabbione> and it helps determining dead code too :-)
<fabbione> but you need proper tools to do so
<sjoerd> morning
<sjoerd> pitti: i get a 404 on your tla archive...
<fabbione> jeeee
<fabbione> it's like 5 hours that i can't rsync ubuntu archive
<bob2> fabbione: wouldn't it be easier to just pass it all through squid?
<fabbione> bah better i go and do house work
<bob2> pitti: someone was complaining earlier about hfs+ automounting not working either, could that be related to the ntfs problem?
<fabbione> bob2: and what would be the benefit?
<fabbione> the rsync connections are still limited in numbers
<bob2> fabbione: not waiting 5 hours for a rsync slot :-)
<fabbione> bob2: what is the benefit of caching on hd what is already on hd...
<fabbione> the archive is too big to be cached in ram
<fabbione> so there is no point in doing it
<bob2> fabbione: oh, you have an existing archive you want to sync?
<fabbione> yeps
<bob2> ahhh
<fabbione> anyway
<fabbione> later
<mjg59> Arse.
<pitti> bob2: I think it's fixed now, too
<bob2> pitti: ah, rock
<pitti> sjoerd: I'll look at it later, gotta go now. CU
<fabbione> :217: The file just loaded does not appear to be executable.
<fabbione> HMMM
* mjg59 fucking wins
<mjg59> The craptop does swsusp
<mjg59> Oh, wow
<bob2> hah, good work
<mjg59> Suspend the craptop, resume it, and my ssh session is still alive
<mjg59> Now I just need to shift these patches back into the kernel source and produce debs for people
<bob2> is this a generic or just for that single laptop?
<mjg59> Generic
<bob2> erm, the word fix was missing from that
<mjg59> Well, it's mostly just been getting swsusp working with an initrd
<bob2> will those fixes work with pmdisk, too?
<mjg59> They were merged in 2.6.9
<mjg59> pmdisk and swsusp, that is
<bob2> hrm, I think it still needs a patch on ppc
<mjg59> Oh, yeah
<mjg59> PPC isn't sane yet
<bob2> ah
<bob2> are the swsusp/initrd fixes arch-dependant?
<mjg59> Nah
<mjg59> It's really just to let swsusp be triggered after the initrd has loaded stuff
<bob2> ah, cool
<fabbione> yeppa
<fabbione> the sparc is booting :-)
<mjg59> Wow
<mjg59> The kernel really blows up if you try to run __init code after it's been discarded
<fabbione> that's not surprising
<mjg59> Hurrah. That's a less invasive patch, and still works.
<mjg59> Right. Packages.
<daniels> guh
<fabbione> daniels: did you find breakfast/lunch?
<daniels> fabbione: yeah, found some lunch
<daniels> had to fight a whole bunch of atms
<daniels> none of them like my card
<daniels> so should I head over to Islev, or what?
<daniels> if you still have stuff to do, I still have things I can do here :)
<mjg59> Anyone fancy testing some sweet laptop love shortly?
* ChrisH raises his hand
<daniels> what sort of love?
<bob2> is it fascist x86-only love?
* herzi might if it's ppc stuff
<herzi> bob2, :)
<daniels> bob2: the x40 is love
<daniels> herzi: by the way, there's no way I'm merging that CRTC2 patch
<daniels> herzi: it just randomly stomps all over the CRTC2 offset, with unpredictable results
<mjg59> bob2: It is at the moment, I'm afraid
<bob2> mjg59: hrm, have you been working on 2.6.9 ubuntu mega special edition kernels?
<mjg59> bob2: 2.6.10-rc1, but yeah
<fabbione> daniels: i need to finish to wash some stuff and crash for another hour
<daniels> herzi: the best way to do it is to ensure it gets set properly in the first place (i.e. RADEONInitCRTC2Registers, or whatever they've called that function) rather than killing it at restore
<fabbione> daniels: then we can go shopping
<daniels> fabbione: sure
<daniels> fabbione: swoeet
<herzi> daniels, well, on my machine (an on others of the same type) it works pretty well
<bob2> mjg59: hm, is it worth giving your sources (+ the pmdisk ppc fixup patch) a sping?
<daniels> mjg59: are you doing swsusp too?
<fabbione> daniels: let's say around 3 and half past 3?
<daniels> fabbione: sounds good to me
<fabbione> daniels: ok
<bob2> mjg59: apparently the only issue with it on ppc is that it needs monolithic ide
<fabbione> daniels: shops are pretty close to here so it's no biggie
<fabbione> daniels: also because they close at 5
<daniels> herzi: i'm willing to bet it breaks tv/vga out on many other machines
<daniels> fabbione: ah cool
<mjg59> bob2: Yeah, once I've built the 386 deb I'll build sources
<bob2> mjg59: cool, thanks
<mjg59> daniels: swsusp is now love
<fabbione> ok i am off...
<fabbione> daniels: later
<herzi> daniels, okay
<daniels> mjg59: phat
<daniels> fabbione: seeya dude
<mjg59> It'll be 20 minutes or so until it's finished building
<herzi> daniels, once there are deb-sources for x.org packages i will start to take a look at it (if it's not too heavy for me)
<mjg59> Then I'll just give it a test-run here
<daniels> herzi: i suspect we need some *proper* documentation from ati
<daniels> herzi: you have a radeon 9600 mobility, no?
<herzi> yes
<herzi> i was talking to benh about this and he's got some docs from ati (though no full specs)
<daniels> yeah, I don't have the full specs either
<daniels> and the only people with full specs are unlikely to do DVI/PowerPC properly, sadly
<sjoerd> :|
<jdub> morning herzi 
<thom> daniels: rock
<jdub> where's keybuk? i wanna give him a big sloppy qmail kiss
<daniels> thom: indeed
<daniels> jesus, that's seven firetrucks and two cop cars that have just gone past
<bob2> hah
<bob2> we only had 6 and 1 at my house
<thom> daniels: don't wave at them, they'll find you easier that way!
<daniels> thom: heh
<daniels> thom: good plan
<herzi> hi jdub 
<mjg59> daniels: Xorg's via driver doesn't crash the craptop. It just gives a black screen instead.
<jdub> PROGRESS!
<mjg59> Kernel's being uploaded now
<mjg59> http://www.srcf.ucam.org/~mjg59/laptops
<mjg59> Needs the initrd deb to be installed first
<jdub> doesn't happen to have the "attach dsdt to initrd" patch, does it?
<jdub> hrm, do i need a swsusp package of sorts?
<mjg59> Nope and nope
<jdub> dum de dum
<jdub> rebooting :)
* thom fires up the X40-
<jdub> ahr
<jdub> so, how do i punish this thing? :)
<mjg59> jdub: echo -n 4 >/proc/acpi/sleep
<jdub> so my cpu applet is complete bong now ;)
<mjg59> 2.6.10 ought to have an i830 framebuffer again
<mjg59> Hmm. jdub appears to be failing to reappear
<jdub> so i suppose i'm meant to do something intelligent at bootup, right?
<mjg59> Nope
<mjg59> Oh, yes
<mjg59> Gar, sorry
<jdub> resume=...?
<mjg59> resume=/dev/yourswappartition
<jdub> ahar
<mjg59> If you did a suspend and then didn't resume from it, you'll need to mkswap your swap partition again
<mjg59> And then swapon -a before attempting to suspend again
<mjg59> Whatever you do, never resume from a suspend image if you've mounted a filesystem in between
<jdub> yeah
<jdub> okay
<jdub> i'll try again
<mjg59> Rock
<mojo_> hey ppl
<mojo_> I just got updated the yelp
<mojo_> and now 2 icons for "Help" appears same time at Main Menu
<mojo_> and no such entries for any link in yelp
<Mitario> mornin'
<thom> mjg59: it suspended and came straight back for me
<maswan> Mithrandir: ACK
<thom> ah, mysql
<mjg59> thom: In what way?
<thom> mjg59: "Strange, mysqld not stopped"
<mjg59> Ah, right
<mjg59> Yeah, mysqld seems to be a problem
<thom> works now, lets see if it resumes
<thom> ROCK
<thom> so MUCH ROCK
<thom> (it works)
<mjg59> Rocking
<mjg59> Though jdub seems to be having issues...
<jdub> i should probably get acpi going properly on this machine before bothering with stuff like this :-)
<mjg59> swsusp should work entirely independently of acpi
<mjg59> What sort of behaviour are you getting?
<mojo_> jdub: does new GNOME 2.9.1 Nautilus support SVG viewer? or GNOME eye or Gthumb support
<jdub> mojo_: they have all supported svg
<jdub> mjg59: it didn't power off correctly
<jdub> mjg59: then it booted fairly normally
<mjg59> And you passed resume=/dev/foo ?
<jdub> yeah
<mjg59> Hmm. Interesting.
<mjg59> What does dmesg say?
<jdub> no idea
<jdub> ended up rebooting into my normal kernel
<mjg59> Hmm
<mjg59> If you could grab the dmesg output for a failed resume, that would be good
<mjg59> No urgency, though
<jdub> mmm
<jdub> kinda want to fix my dsdt blues
<thom> mjg59: any plans to do a full build with all the drivers and stuff?
<mjg59> thom: Dude, that should be a full build
<bob2> what's happening with 2.6.9 packages, btw?
<mjg59> What's missing?
<thom> oh, hrm. could be a driver issue, i don't have ipw2100 love
<mjg59> Oh, argh. Hang on, yes, there's a broken firmware loader in that version.
<thom> ahr
<thom> oof, kernel oopsed in ipw2100_pci_init_one
<mjg59> Hmm. No, the firmware loader should be ok there.
<mjg59> thom: Eep
<mjg59> thom: What's the backtrace?
<bob2> hrm, I get "badness in device_Release..." during the install
<mojo_> I love to see Grub2 in Hoary
<mjg59> mojo_: At the point where it's stable, it'll probably be considered
<jdub> mjg59: hrm, you heard what's up with the SD stuff?
<thom> mjg59: one sec, just gonna reboot so i have networking :-)
<mjg59> jdub: Nope
<mjg59> thom: Thanks
<thom> mjg59: www.clearairturbulence.org/ipw2100-oops
<jdub> ok
<jdub> that's it
<jdub> i'm rebuilding my kernel
<jdub> *cry*
<mjg59> thom: Can you try with http://www.srcf.ucam.org/~mjg59/laptops/ipw2100.ko
* thom reboot
<thom> s
<thom> Argh, fs check
<mjg59> Haha
<thom> firmware load failed with that one
<thom> oh, of course it will
* thom fiddles
<thom> mjg59: Firmware ipw2100-1.2.fw not available or load failed
<mjg59> But no oops?
<mjg59> What version of the firmware do you have?
<thom> 1.2
<mjg59> Hrm.
<thom> well, 1.2.fw-2.6.10-rc1-1-386
<mjg59> It's the driver from the hoary kernel, so it /ought/ to work...
<thom> but that's an ubuntu patch to the firmware loading stuff, isn't it? should affect individual modules
<thom> yeah
<mjg59> Can you check whether hotplug seems to load it?
<thom> seems not
<mjg59> But it opens the file?
* jdub waits for kernel to build, though it is surprisingly fast.
<bob2> hrm, booting manually in grub sucks
<bob2> and now it can't pivot_root properly
<thom> mjg59: atime hasn't changed, so i think not
<mjg59> Weird. I'll give it a go here later on.
<daniels> mjg59: cool
<daniels> mjg59: sounds phat
<daniels> mjg59: remind me never to buy a via laptop
<jdub> pain makes you stronger
<bob2> yay, boot harder, ubuntu
<ddaa> Ha... good.
<ddaa> http://www.ubuntulinux.org/wiki/HardwareSupportMachinesLaptops
<ddaa> The T42 instructions works well on my T42p in console.
<ddaa> hu... but that cause the cpufreq applet to go mad...
<daniels> you missed your opportunity to join the x40 cabal
<ddaa> daniels: I want more pixels.
<ddaa> UGA and X40 is pretty much a contradiction in terms.
<daniels> jdub: yeah, and hanging car batteries from your nipples makes them stronger, too
<daniels> jdub: doesn't mean it's a good idea
<daniels> thom: ?
<daniels> http://www.ubuntuforums.org/showthread.php?t=3324&page=1&pp=10
<daniels> has anyone used GnomeBaker?
<daniels> thom: and I can't remember what I pinged you about.  arse.
<ddaa> yay!
<ddaa> Well... I must admit that the ubuntulinux wiki contents rocx
<ddaa> Steps for t42, just totally do the right thing.
<ddaa> The problem is that they are pretty cryptic...
<ddaa> Having some docs on the acceptable markup on that wiki would be useful.
* ddaa goes out and try to find how the hell the ibm-acpi module is supposed to get compiled
<dooteo> hi folks
<dooteo> I've go Advansys SCSI card with 2 CD drivers, but it looks like ubuntu can't find them (scsi card appears on hardware list)
<dooteo> what can I do to see them?
<bob2> the problem with "device manager" is that noe everyone uses it
<daniels> ddaa: um, you shouldn't need ibm-acpi
<daniels> ddaa: doubly so if you're running hoary
<daniels> ddaa: all merged in
<dooteo> bob2: well, but Nautilus is not able too
<ddaa> Mh... it's mentioned on the wiki. I'm not too sure what it is about, probably enabling the suspend key...
<daniels> works out of the box with my x40
<daniels> as I said, it's all merged in :)
<ddaa> Does not work on t42.
<ddaa> mhh... maybe I should put tpb away
<bob2> dooteo: this sounds like a #ubuntu sort of question...
<bob2> yay rhythmbox, ignore all my oggs
<dooteo> bob2: okey here I go. Thanks
<lamont> pitti: lost about 11 hours of connectivity due to a cable cut...
<lamont> finally awake noew..
<ddaa> daniels: I'll try adding that module, just to be sure if it makes any difference.
<fabbione> hey lamont
<ddaa> duh... that beast expands a linux.tar.bz2 in a totally ridiculous amount of time...
<lamont> morning fabbione
<bob2> bloody scrollkeeper
<fabbione> lamont: Unpacking libc6 (from .../libc6_2.3.2.ds1-18_sparc.deb) ...
<lamont> fabbione: kewl!
<bob2> fabbione: you're bootstrapping sparc?
<fabbione> lamont: i installed wb and sbuild from db.d.o, or do you suggest another version?
<fabbione> bob2: yes
<fabbione> but not this night...
<bob2> heh
<fabbione> i am only preparing the sid chroot to start with
<bob2> awesome
<fabbione> we are heading out to eat and get possibly drunk
<fabbione> bob2: problem is d-i. i only have one sparc
<bob2> fabbione: ahh
<fabbione> so someone else will have to kick it
<daniels> helix volunteers
<fabbione> ehhe
* fabbione grabs daniels and take him out in the real world
<pasc> fabbione: keep him away from khebab shops
<fabbione> pasc: why?
<daniels> pasc: nah man, it's not five-star, I couldn't bring myself to go
<daniels> pasc: i'd take you to Souvlaki King in Melbourne if you didn't keep piking
<daniels> you should come get one of the best burgers in the world
<daniels> it's like half a cow
<pasc> I think I'll settle for the best seafood in the universe
<pasc> ;-)
<pasc> but I will come to melbourne one day
<bob2> it's not too bad
<bob2> it's like a pretty good sydney knock-off
<lamont> pitti: sigh.  fixed
<lamont> fabbione: at this very moment, nothing to suggest.
<lamont> I hope to have a repository on the lan sometime soon that has the versions being used on the buildd's, but it's not significantly different
<lamont> (gcc-opt support, package grabbing selection, and per-component sources.lists are all...)
<lamont> if you start by just building main, then you don't care about per-component...
<fabbione> lamont: the only thing i would like to have at phase2 start is a minikatie running on rookery
<fabbione> so that we can evaluate community interest in a certain port
<fabbione> and see if it is worth to ask Mark for real buildd
<daniels> pasc: i'll have to give that to sydney, yes -- the seafood is phat
<daniels> pasc: but our jsbh is better, mio
<daniels> er, imo
<bob2> daniels: does it have a debsig?
<daniels> yes
<daniels> gah
<daniels> ximian-connector build-deps broken
<daniels> can someone please kick seb when he gets in and tell him to add something providing -ldl to x-c's b-d's?
<daniels> ../../gnome/vfsmodule.c:406: error: redefinition of `pygvfs_set_file_info'
<daniels> ../../gnome/vfsmodule.c:372: error: `pygvfs_set_file_info' previously defined here
<daniels> ../../gnome/vfsmodule.c:372: warning: `pygvfs_set_file_info' defined but not used
<daniels> make[3] : *** [vfs_la-vfsmodule.lo]  Error 1
<daniels> make[3] : Leaving directory `/build/daniels/python-gnome2-2.6.0/build-2.3/gnome'
<daniels> python-gnome2 broken also
<azeem> daniels: -ldl? isn't that in libc6-dev?
<daniels> er, sorry, -ldb
<azeem> ah, that one again
<daniels> awesome
<daniels> the xorg buildd is now lying idle for want of anything to do
<daniels> a couple of broken packages but afaict nothing has broken while building against xorg
<daniels> now it's really food and beer time (julebyrg!)
<sjoerd> daniels: have fun 
<mjg59> thom: Ping?
<mjg59> thom: How were you testing that ipw2100 module?
<ddaa> daniels: I am getting the general impression that _maybe_ the hotkeys are already supported, but what is missing is proper acpi scripts.
* ddaa finds this annoyingly complex
<mjg59> ddaa: What are you trying to do?
<ddaa> Getting a T42 to work fully.
<mjg59> ddaa: you want the ibm-acpi driver if you want to be able to use all the hotkeys
<mjg59> Most of them aren't exposed, otherwise
<ddaa> yeah... daniels said it worked out of the box on the X40...
<mjg59> The suspend key should work fine without ibm-acpi
<mjg59> That's the Fn+F4 one
<ddaa> mjg59: but even if I manage to build the module (not sure how) I will still have to write acpi scripts, right?
<mjg59> ddaa: Yes
<ddaa> I got suspend/resume to work on lid events, thanks to some hints by mdz, but I am generally quite at loss with acpi.
<ddaa> BTW, is that stuff actually documented somewhere?
<mjg59> The acpi code sends stuff to /proc/acpi/events which acpid picks up
<mjg59> acpid then uses the contents of /etc/acpi/events to choose what to do in response to them
<mjg59> Generally this is to run a script in /etc/acpi
<ddaa> Now, what are the events, what do they mean, and what are the appropriate actions is knowledge I miss.
<ddaa> My understanding of hardware is pretty much limited to "what runs software" :-)
<mjg59> Heh
<mjg59> The normal things that generate events are the suspend key, the power button, the lid switch and plugging/unplugging the AC adapter
<mjg59> Those all generate standard events, so it's fairly easy to configure them
<mjg59> But ibm-acpi enables all the other hotkeys (Fn+f3, f5, f7, f9, f12) and lets you configure events for those as well
<ddaa> Okay. Now where can I find acpi config stuff for those that makes sense?
<ddaa> I s'pose the stuff in ibm-acpi
<mjg59> daniels's acpi-support-x40 (or whatever it's called) should have some
* ddaa looks for dianel's stuff
<ddaa> Anyway, by looking at the wiki for t42p, I am quite amazed at the amount of unecessary stuff people advocate...
<ddaa> Like using fglrx...
<sjoerd> ls
<sjoerd> beh
<ddaa> mjg59: thanks. daniels' stuff seems to plain just work here...
<ddaa> Now, I just need to get the ibm-acpi thing built...
<mdz> morning
<ddaa> mdz: hello
<ddaa> What's the proper way to set the permissions for /dev/nvram, so it's writable by a non-root group, and in a persistent manner?
<mjg59> Put something in /etc/udev/permissions.d
<mdz> ddaa: hi
<mdz> Kamion: around?
<ddaa> okay... the udev config says "root:nvram" for this dev, but the nvram group does not exist...
<ddaa> Bug.
<ddaa> What's the proper gid for nvram?
<ddaa> mdz: what's the proper package to report that bug against?
<ddaa> Bah... assigned it to udev...
<mdz> ddaa: udev
<ddaa> done
<mdz> it's not clear whether we should have an nvram group, or change it to something else, though
<ddaa> I pointed that out in the bug report :-)
<ddaa> Well... supposedly that should be useful only for people who operate the machine...
<ddaa> local users, I mean.
* mjg59 uploads an updated kernel
<ddaa> Only showstopper left, the video-switch button cause the t42 to hang with a black screen. Using fglrx or ibm-acpi does not fix that.
<ddaa> (I have not tested all the possible combination of modules and kernel options though)
<mjg59> Ok - again, if people could test http://www.srcf.ucam.org/~mjg59/laptops/ that would be good
<mjg59> Needs the initrd package first, and you need to pass resume=/dev/whatever to the grub options
<ddaa> What is it for?
<mjg59> Power management testing
<mjg59> It's got suspend to disk support
* ddaa is willing to test
<ddaa> what should the resume option point to?
<mjg59> Your swap partition
* mjg59 goes out
<zopi> Hi sorry to bother you
<zopi> but I have a strange behaviour with Ubuntu 
<zopi> I have to tried to install Ubuntu on 1.4 Ghz 256 Mo and the installation is very slow
<zopi> display is slow 
<zopi> very strange behaviour
<zopi> using Matrox G400
<zopi> same behaviour for the boot
<zopi> and I don't understand
<zopi> any idea ?
<zopi> I have used reiserfs for the /
<zopi> any bugreport for slow behaviour ?
<zopi> using Warthy 4.10
<ddaa> here, with a g450, I got accelerated video out of the box
<ddaa> You find it slow in comparison to what?
<ddaa> Mhh... btw, that is a #ubuntu discussion
<ddaa> --> #ubuntu
<zopi> I know
<zopi> but no answer
<zopi> that why I ask here
<zopi> sorrry for the inconvenient
<zopi> I have tested with memtest memory has no problem
<zopi> I was running Debian Sid and wanted to test Ubuntu :)
<ddaa> mjg59: tried your kernel
<sivang> zopi : is this a laptop?
<ddaa> on the plus side, swsusp works, and the video-switch key seems to work okay (It does not cause a hang at least, I have not tested with an actual external monitor). However, even if the network modules (ipw2200) 
<ddaa> ... and e1000) are loaded I do not have any /dev/eth* device.
<jdub> yay!
* jdub now has the dsdt hack in his kernel
<ddaa> jdub: what does it do?
<jdub> ddaa: it makes my dell acpi work ;)
<jdub> ie. the battery display, etc. ;)
* ddaa waves into the general direction of ibm.com :-P
<ddaa> mjg59: also, with your kernel, the cpu frequency applet behaves just as badly as when I booted with "apm=on acpi=off nolapic", but the contents of /proc suggest it's using acpi and not apm.
<jdub> ddaa: i got the same thing with mjg59's kernel
<ddaa> 134GHz... schweet, software acceleration!
<lifeless> ddaa: welcome to the club
<ddaa> but -1218013MHz... scary... time travel?
<lifeless> jdub: where dost thou get dsdt luv ?
<ddaa> lifeless: well, the important stuff just works using daniels acpi stuff.
<ddaa> And a stock warty kernel.
<lifeless> what apt repository should I point at for that ?
<jdub> you can't
<lifeless> :[
<jdub> you have to get a compiled dsdt appropriate for your bios/hardware
<jdub> and build it into your kernel
<lifeless> jdub: ah, I was hoping it had improved.
<lifeless> I need someone to decompile & fix my dsdt, don't have time to learn that right now.
<jdub> there's a patch that lets you attach it to the initrd
<jdub> grep voltage /proc/acpi/battery/BAT*/state
<jdub> ^ paste please :)
<jdub> grep -h voltage /proc/acpi/battery/BAT*/state
<lifeless> grep voltage /proc/acpi/battery/BAT*/state
<lifeless> /proc/acpi/battery/BAT0/state:present voltage:         14800 mV
<lifeless> /proc/acpi/battery/BAT1/state:present voltage:         14800 mV
<ddaa> Woah. With mjg59's kernel, the external video _actually_ works. It's not pretty by any means, but it does work...
<lifeless> jdub: battery seems to work just fine, its sleep that has trouble... can get it to go to mem suspend with a little effort, but it won't come back :[.
#ubuntu-devel 2004-11-18
<mdz> what is "e-baking"?
<mdz> oh, maybe he meant banking
<jdub> now i have battery info, i have to figure out why this machine chews so much battery
<thom> mjg59: no ooops, but no firmware load either
* sivang sivang_asleep
<ddaa> Thanks everyone for the help in setting up the T42p. I have updated wiki.ubuntulinux.org. The page contains older more complicated instructions for T42 and a different model of T42p, if you could get the original authors to check and aggregate the instructions, that would be great.
<drbyte> jdub: and what machine is that
<drbyte> (so i can avoid buying one :P)
<pl0vs> ddaa, you should no longer use wiki.ubuntulinux.org bur use www.ubuntulinux.org/wiki
<jdub> ARGH
<jdub> hahahaha
<jdub> man
<jdub> now that acpi is a-ok
<jdub> i can't close the lid of my laptop when i'm using my external monitor/mouse/keyboard
<jdub> because it locks the screen and chvts
<amu> ;) 
* amu 's first burn of the hoary-live-2.6.9-20041107-03.iso
<jdub> woo
<mjg59> thom: Works fine here...
<jdub> yo mjg59 
<jdub> mjg59: did you look into paul's kernel patches much?
<jdub> my laptopt totally chugs the battery life
<mjg59> Paul?
<jdub> paul drain
<jdub> i linked them on -devel
<mjg59> Never heard of him, I'm afraid
<jdub> he's the garnome maintainer
<jdub> but also
<mjg59> (Sorry, just back from robtaylor's. He was in the process of having the council ask him to turn the music off)
<jdub> has recommended patches linked by me from -devel
<jdub> haha
<mjg59> Cool
<mjg59> I'll take a look
<mjg59> (V, v drunk)
<jdub> what's the best way to replicate the kernel builds the buildds do? apt-get source linux?
<jdub> linux-source-... was poo
<jdub> roughly speaking
<mjg59> linux-source-foo, dpkg-buildpackage
<amu> 2 error's hoary compared with warty 
<mjg59> It'll build lots of them
<amu> E: Couldn't find package x3270
<amu> E: Couldn't find package pr3287
<jdub> mjg59: but not how the buildds do it...
<mjg59> Uh. What do the buildds do, then?
<jdub> dunno
<mjg59> How is it different to what the buildds do?
<jdub> linux-source... is not the same as apt-get -b source <blah>
<mjg59> Oh, I see what you mean
<mjg59> I /believe/ that the buildds do it from linux-source, but produce individual packages that have different source dependencies
<Mitario> hi everyone
<Mitario> anyone knows who's maintaining apt in ubuntu?
<bob2> in what sense?
<bob2> it's still mdz's baby
<Mitario> package maintainer
<Mitario> ah, ok
<Mitario> ty
<bob2> ubuntu doesn't have the same sort of package maintainership as debian
<Mitario> well, call it 'standard uploader' then ;)
<Mitario> i mean, i guess someone is a bit more responsible for one package then the rest of the ubuntu maintainers
<mdz> ddaa: thanks for writing up your laptop findings for the wiki
<fabbione> morning guys
<mdz> good morning
<fabbione> hey mdz
<fabbione> mdz: probably today we will do another internal drop
<fabbione> and it should be the last one
<fabbione> tuesday -> archive
<mdz> ready to test when you are
<fabbione> buildd has completed
<fabbione> no failure
<fabbione> mdz: yup.. we are going to split some libraries
<fabbione> and we need to test a new autoconfiguration feature of X.org
<fabbione> if the latter works we can get rid of 90% of the external tools we are using
<mdz> great news on the build test
<mdz> what kind of autoconfiguration does the feature provide?
<mdz> if it could only choose the driver, that would make me so happy
<mdz> because we could ditch discover1 for hoary
<fabbione> mdz: it does everything
<fabbione> just remove /etc/X11/xorg.conf
<fabbione> and try to startx
<fabbione> it detect all my hardware perfectly
<fabbione> including video card
<fabbione> but the keyboard layout
<fabbione> or you can also try to remove one single section only
<fabbione> like the Monitor one
<fabbione> and it should create an autodetected one
<fabbione> problem is that it doesn't save it in the config
<fabbione> there is a tool in X.org to do so, but we need to test it 
<mdz> why save it, if it can do it automatically?
<fabbione> because you might want to customize after?
<mdz> nice to have
<bob2> networkmanager looks awesome
<mdz> E: Couldn't find package networkmanager
* mdz pouts
<bob2> thombot's packaging it
<mdz> yeah
<bob2> which reminds me, his Sources file is broken
<mdz> wow, if you search for 'blackdown deb', the Ubuntu wiki resources are in the top 5 :-)
<mdz> (google)
<fabbione> goody
<fabbione> wanna build and quinn-diff are ready
<fabbione> time to configure sbuild
<mdz> fabbione: why so much infrastructure for just a build test?
<fabbione> mdz: ????
<fabbione> that's for the sparc port of hoary
<mdz> oh, I thought it was for x.org
<fabbione> x.org has been done already
<fabbione> as i wrote before main compiled perfectly
<mdz> so it was doubly surprising :-)
<fabbione> we are not going to kick in universe
<fabbione> but yes.. we did use wanna-build & co also for that
<fabbione> but we had the setup ready before the Xsprint
<bob2> hm
<bob2> cpufreqd's default config uses acpi, which is (afaik) useless on ppc
<bob2> is it a bug that it doesn't modify that based on the arch?
<mdz> bob2: doesn't particularly matter, since cpufreqd is unsupported :-)
<sjoerd> bob2: cpufreqd sets the right type in postinst
<sjoerd> (in debian thatis)
<mdz> hoary and sid have the same cpufreqd
<bob2> yeah, thought I was in a different -devel channel :)
<fabbione> Automatic build of choose-mirror_1.06ubuntu1 on vultus5 by sbuild/sparc 1.170.5
<fabbione> Built successfully
<fabbione> Purging chroot-hoary/build/sparcbuildd/choose-mirror-1.06ubuntu1
<fabbione> YEPPA
<fabbione> time to kick the buildd
<daniels> cool :)
<fabbione> daniels: yeah.. i had to fight with sbuild..
<fabbione> i couldn't understand why it was not using the chroot :-)
<fabbione> daniels: are you on the way here?
<daniels> fabbione: i have to do my laundry at some stage, was thinking of doing that this morning instead of tonight
<fabbione> daniels: ok, take your stuff here
<fabbione> i will drive you to a laundry
<daniels> fabbione: oh cool, thanks
<fabbione> daniels: so we can take a break in the middle of the day
<fabbione> i might have to do some laundry too
<fabbione> daniels: do you think you can do me a little favour coming here?
<fabbione> i am really too lazy to go out right now ;)
<fabbione> nah well
<fabbione> i will go out
<fabbione> getting some fresh air is good :-)
<daniels> fabbione: yeah sure :) that's fine
<daniels> heh
<daniels> so what's the plan?  i was just about to jump in the shower and catch the train
<fabbione> just come here...
<fabbione> it's fine
<SuperL4g> is there a way to pass ESSID and WEP info before you start the install, so I can get connectivity before the first reboot? as it stands right now, I have to do the install without the network, then reboot, then update.  If I could pass the options pre-install it would update everything up front and save about 20 minutes. :)
<daniels> ok, cool
<fabbione> State changes at 2004 Nov 07 10:43:44 for distribution hoary:
<fabbione> --merge-packages(hoary): db3_3.2.9-20 changed from Building to Installed by sparcbuildd as sparcbuildd
<thom> mdz: will probably upload NM on monday or tuesday
<cenerentola> any lovable canonical ppl in here?
<daniels> i don't know about 'lovable' as such ...
* Mithrandir ruffles daniels 
<thom> Mithrandir: fixed fakeroot yet? ;-)
<thom> (i saw the mips bug, which looked more or less identical)
<Mithrandir> thom: possibly, yes.
<thom> oh? rock.
<Mithrandir> thom: it's probably a libc compile bug, I haven't tried upgrading to the new-compiled libc yet, but that's a simple thing to do
<thom> if you need me to test just shout
<thom> i saw your conversation with drow as well. so was it bad nptl/tls options in the build?
<cenerentola> daniels: id like to know all you can tell about the italian ml...
<cenerentola> since the btlug.it [italian ubuntu linux community]  site is now up
<Mithrandir> thom: I think so, but I haven't tracked it yet.  I need to fiddle around a little
<Mithrandir> thom: I miscompiled glibc again, it seems.
<daniels> Mithrandir: yo dude
<zopi> Hi 
<zopi> sorry to bother you
<zopi> for my problem of yesterday
<zopi> slow installation
<zopi> the problem has been solved I have made my Hard Disk in Master
<zopi> in Slave mode the installation is very slow !
<mjg59> zopi: Do you mean the disk was a slave without a master?
<ddaa> mjg59: thanks for pointing out the old wiki issue. Though I put the comments on new wiki and just got the name wrong when writing my message here.
<zopi> mjg59 : yes
<ddaa> Duh... zwiki is terminally confusing...
<ddaa> The tabs change (or do not change) in a completely unpredictable manner :-(
<tuo2>  Umm.. random question.. Is there a good reason why we are using a self-signed certificate on https://www.ubuntulinux.org ?
<bob2> hahaha
<bob2> yes
<tuo2> bob2: care to enlighten me?
<bob2> not sure if I can :-)
<bob2> elmo or thom would be the people to ask
<mjg59> ddaa: Hmm. You shouldn't have /dev/eth*
<azeem> nobody at canonical has expertise with internet certificates I guess ->;)<-
<mjg59> But do you mean that there's no network interfaces?
<bob2> hehehehehe
<mjg59> Well, based on thom...
<fabbione> hahah
<ddaa> mjg59: well, okay... there are not here with warty kernel either...
<bob2> do any unices have /dev/eth?
<ddaa> Neverthell, networking works with warty kernel, but not with yours.
<daniels> bob2: if you asked thom about the ul.o certificate, he'd give it to you :P
* ddaa 's ignorance of kernel things painfully shows
<mjg59> ddaa: Weird. I'm running it fine on here.
<bob2> daniels: hahahaha
<mjg59> ddaa: Does suspend to RAM work with it?
<ddaa> mjg59: yup
<mjg59> Cool. Did you need any kernel arguments?
<mjg59> acpi_sleep=foo ?
<tuo2> azeem: funny. ;)
<ddaa> I used the same acpi_sleep=s3_bios as needed with the current kernel
<ddaa> Did not test w/o it.
* ddaa reinstalls the kernel to test w/o acpi_sleep argument
<mjg59> ddaa: It probably does need it, but there's something else you could test
<mjg59> ddaa: If you could install the video-post package from http://www.srcf.ucam.org/~mjg59/laptops and then add /usr/sbin/video_post to the start of your resume script, that would be good
<mjg59> With a bit of luck, that'll avoid the need for the kernel argument
<ddaa> mjg59: let me test things properly...
<ddaa> about eth1, the error I get is "no such device".
<ddaa> However the device appears in the Gnome Device Manager (I do not know if that means anything)
* ddaa grumbles has he keeps forgetting to run update-grub
<mjg59> ddaa: Does lsmod show that the modules are loaded? Does dmesg say anything?
<daniels> mjg59: what does video_post do?
<mjg59> daniels: soft-boots the video card
<daniels> vbe?
<mjg59> It's pre-vesa, I think
<ddaa> ipw2200 shows in lsmod output
<daniels> mjg59: oh
<mjg59> daniels: But yeah, it does int 10 stuff
<mjg59> ddaa: Hmm. Anything in dmesg?
<daniels> oh my god, it's almost straight ripped from the xfree86 soruce
<ddaa> Yes. Detected, but "Unable to load firmware: 0xFFFFFFFE"
<mjg59> daniels: It is indeed
<mjg59> ddaa: Grr. Weird.
<mjg59> I thought I had that fixed.
<daniels> Keybuk: yo
<Keybuk> yo, hey what's happenin' dude?
<mjg59> ddaa: Oh, damn. Sorry, I managed to miss half the patch.
<mjg59> Ugh. I'll fix that.
<ddaa> mjg59: the network problem is the big show-stopper. The other issue is the cpu freq applet. I have not checked whether freq scaling actually works though.
<mjg59> ddaa: Right, I'll sort out the networking stuff
<daniels> Keybuk: not much, just archifying xorg
<ddaa> Mh... interesting... without acpi_sleep, the machine did not actually hang... the video and the sound were out, but I was able to reboot it by blind-typing.
<Keybuk> fun
<daniels> seems plausible
<ddaa> Did not actually went as far as trying that with the warty kernel...
<mjg59> ddaa: Ok - it'd be great if you could see if video_post brings it back
<ddaa> mjg59: next step
<ddaa> however, after that there is another time consuming test: checking how much batter power it actually consumes over 8 hours.
<ddaa> maybe I'm having false impressions, but I thought the acpi_sleep parameter might be needed to get the proper sleep state.
<mjg59> No, acpi_sleep just changes how the video is reinitialised on resume
<daniels> no, acpi_sleep=s3_bios just runs through the video bios to reinitialise the video card when it comes back
<ddaa> mjg59: kudos! video_post at the start of the resume script makes it happy
<mjg59> Rock
<daniels> noice
<thom> mjg59: "miss half the patch" is that ipw2100 firmware loader related?
<ddaa> mjg59: do you want me to check something for the cpu scaling support, or is the issue well known?
<mjg59> thom: All firmware related
<mjg59> ddaa: If you could, though I think that there's something broken in the realm of ACPI processor management
<mjg59> If you have the cpufreq-acpi module (can't remember what it's actually called) loaded, changing to cpufreq-centrino may be better
<ddaa> mjg59: not that I can have a lot of initiative, but I'd happily run any test you want.
<ddaa> (as long as it does not involve throwing the the lappy on the floor)
<mjg59> ddaa: If you could stop powernowd, rmmod acpi, modprobe cpufreq-centrino and then restart powernowd, that would be good
<thom> mjg59: ah
<ddaa> mjg59: ack
<mjg59> Oh, lord. More of last night is coming back to me.
<ddaa> hu... no acpi module at all...
<ChrisH> mjg59: Did you update anything laptoppy? I could check it out tomorrow at work. (Toshiba Tecra 8100)
* mjg59 wonders why robtaylor|away owns a Shampoo CD
<mjg59> ChrisH: Yeah, though the kernel is a bit broken at the moment :)
<mjg59> ddaa: Hmm. Does modprobe speedstep-centrino work?
<mjg59> (sorry, not cpufreq-centrino)
<ChrisH> mjg59: Just update to newest hoary?
<mjg59> ChrisH: No, this is outside hoary
<ddaa> Mh... modprobe acpi => no such device. No helpful output in dmesg or syslog.
<daniels> mjg59: oh, oh.  is he in trouble?
<mjg59> ddaa: modprobe speedstep-centrino ?
<daniels> mjg59: i have an ogg for that song to hand
<mjg59> daniels: That's... unnecessary
<mjg59> Unless you want to upset anyone in your vicinity
<daniels> mjg59: just wondering if you wanted a copy
<ddaa> modprobe speedstep-centrino: no such device. dmesg says "no table support for CPU model "Intel(R) Pentium(R) M processor 1.70GHz" and "try compiling with CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI enabled"
<mjg59> Hm. Right.
<mjg59> So the problem is in the ACPI processor module.
<mjg59> Thanks, that narrows it down
<ddaa> You're welcome. Thanks for working on making my lappy work :-)
<ddaa> The nice thing with working in Canonical, is that you can whine at the people who actually have the ability to fix the issues :-)
<daniels> mjg59: last night, had you been out all night, and hadn't been home?
<bob2> ddaa: haha
<fabbione> ddaa: remember that some Canonical emploies are dangerous...
<fabbione> ;)
<ddaa> bob2: getting hardware specs from Apple would involve a commando raid...
<bob2> ddaa: I just want someone to break into broadcom's offices 
<thom> broadcom would be much more productive
<thom> has no-one tried using darwin drivers?
<ddaa> fabbione: bah, you are just posturing as a Dangerous Evil X Maintainer. We all know you are a nice dude :-P
<mjg59> daniels: Strictly, no
<bob2> thom: I get errores during modprobe!
<mjg59> thom: Secret plans are in motion
* fabbione open the president bag with the nuclear sodomotron remote control
<mjg59> There are no darwin drivers, AFAIK
* fabbione and points the target to France
<mjg59> There are binary-only Linux drivers for MIPS
<bob2> yeah
<bob2> which I begged kinnison to reverse engineer
<thom> or s/darwin/OS X ; which should be more or less the same no?
<bob2> benh has some tools to sniff what mac os x drivers do
<mjg59> thom: Sure, there are OS X drivers
<mjg59> So I guess you could do something ndiswrapper like...
<thom> mjg59: that was kinda what i was thinking, yeah
<mjg59> But we've got someone working on a better solution
<daniels> mjg59's secret laptop cabal
<bob2> oh, mac ndiswrapper, eeevil
* mjg59 thinks he's fixed the firmware loader
<daniels> (which is later revealed to be a room full of monkeys with albooks)
<mjg59> New packages soon
<bob2> there's a standing offer of as much beer as you can drink for whoever hacks up a working broadcom driver
<daniels> bob2: you forgot the most important stipulation
<daniels> bob2: *cold* beer
<bob2> yeah
<bob2> if they claim it in london, I'll bring an esky to cool it
<ddaa> btw, I was quite surprised at the sobriety of the Canonical dudes in Oxford.
<ddaa> I would have expect much more liberal beer-gulping.
<azeem> they drank whiskey?
<thom> in the hotel? NFW
<ddaa> azeem: stevea drank expensive (and excellent) whisky
<thom> it was more expensive than norwegian beer
<bob2> spain had better be cheaper
<mjg59> We had poor quality wine and vodka from the petrol station
<daniels> the wine wasn't abysmally bad
<daniels> it was drinkable
<ddaa> but really, you'd have to be a bit out of your mind to spend that much money on perfumed ethanol...
<bob2> and poor quality movies to go with it
* ddaa begs bob2 not to resume the Antitrust line...
<daniels> bob2: that you didn't even watch, I might add
<bob2> I tried to watch it
<mjg59> In the real world, when you kill people, they die
<thom> bob2: first time i've seen quality used in any sense about antitrust
<bob2> but it was in the distro room
<bob2> and I was sleepy
<bob2> distro room = bob2's nap room
<ddaa> daniels: It might even been watchable, if it had some kind of sound besides the built-in speakers of a powerbook...
<thom> as demonstrated during the pygtk talk
<daniels> mjg59: it's not just ones and zeroes!
<bob2> thom: hah
<mjg59> 6 minutes to upload this stuff
<mjg59> I want more bandwidth
<daniels> bob2: so how many times did you apologise to jamesh?
<thom> hrm, time to get to sainsburys and back
<bob2> daniels: a dozen on the bus back to london
* ddaa tries videopost with an innocent warty kernel
<daniels> bob2: heh
<bob2> so, I hate you all, i368 owners
<daniels> i368? wassat?
<bob2> bah
<thom> bob2: join the x40 cabal
<mjg59> If this works, then I just need to fix the acpi processor stuff
<daniels> bob2: one day you'll wake up with an iBook LCD in your bed
<bob2> thom: don't tempt me
<ddaa> mjg59: video_post seems to do the right thing with the warty kernel (with acpi_sleep).
<daniels> ddaa: and without acpi_sleep?
<thom> bob2: you know you will, it's just a matter of time
<ddaa> daniels: Hu. I meant _without_
<bob2> daniels: yeah, with a broadcome wireless chip through it's head
<bob2> thom: hah, it is, sadly
<ddaa> daniels: feels like including it in you thinkpad-acpi stuff?
<daniels> bob2: eveeerrrryboooodddyyyyy comes to x40
<daniels> alright, time for me to go do laundry and head back to the hotel
<daniels> in no particular order
<mjg59> Need to check the license situation on video_post first
<mjg59> The guy from Intel hasn't actually included any copyright information
<bob2> I shoulda waited until we had a distro team before buying, so I could copy them
<daniels> mjg59: most of it is ripped *verbatim* from various places in xfree86
<daniels> i'd be stunned if his additions were even copyrightable
<mjg59> Oh, yeah
<mjg59> It's all X11 license based stuff
<daniels> so it'll all be either mit or bsd to egbert eich
<daniels> anyway, I'm out
<mjg59> ddaa / thom: New kernel on http://www.srcf.ucam.org/~mjg59/laptops should fix the firmware stuff
* ddaa is away for a moment
* thom reboots
* azeem looks at irc
<thom> mjg59: does the suspend-to-disk button work for you, ooi?
<thom> mjg59: and still the firmware load problem
<mjg59> thom: With ibm-acpi, yes
<mjg59> thom: Gah. Fuck.
<mjg59> thom: Remember that it won't load the firmware unless /sys is mounted
<mjg59> You're doing a full boot rather than just init=foo?
<thom> yeah, full boot
<mjg59> And it's the same error as before?
<thom> yup
<mjg59> Arse
<thom> yup :/
<thom> ok, i really have to go get milk
<thom> back in about 15
* Mitario wakes up
<Mitario> hello everyone
<sivang> Hey Mitario, what's new?
<Mitario> nothing much really :)
<thom> Mitario: hey, so when i logged out and logged in again, i ended up with about 7 upgrade notification icons
<Mitario> you probably started them all manually? :)
<thom> pretty sure i didn't, but maybe
<Mitario> upgrade-notifier puts every instance of itself in gnome-session
<thom> NetworkManager has some code to ensure it's only in the session once, iirc. might be worth stealing?
<Mitario> ah, good idea
<sivang> Mitario : are you working on the auto update applet?
<Mitario> with michael yeah
<sivang> must be cool thing
<sivang> :)
<Mitario> hmm, no hoary updates the last day?
* mjg59 gives up and moves to a clean kernel tree again
<mjg59> This all gives me increased respect for the kernel maintainers
<play> hi everyone
<play> i have some troubles with K3B and Warty... K3B doesn't detect my DVD burner :( It seems it's a problem with the 2.6.8 kernel. Does somebody know a patch ?
<play> i enjoy very well Ubuntu ! good work ! ;)
<thom> play: #ubuntu is the support channel
<thom> thanks :-)
<play> ok Thom :) Sorry. bye
<ddaa> mjg59: I confirm persistent of the firmware loading problem with your newer kernel.
<ddaa> *persistence
<fabbione> wow
<fabbione> i found a warty chroot from debconf4 :-)
<fabbione> lost in one my machines 
<mjg59> Mm.
<mjg59> Lovely kernel crack.
<mjg59> Argh. Except swsusp has now broken.
<mjg59> Rock
* mjg59 has DPMS management code
<Keybuk> mjg59 is KERNEL BOY
* ddaa can't wait test mjg59's new kernel
* Mithrandir gives mjg59 some more crack
<mjg59> ddaa: http://www.srcf.ucam.org/~mjg59/laptops/http://www.srcf.ucam.org/~mjg59/laptops/
<mjg59> Working firmware, working processor stuff
<ddaa> mjg59: well, actually I am going to way for unison to finish munching my disks :-)
<ddaa> Unless you are going to bed soon, then I'll postpone unison.
* Mithrandir wonders why ddaa thinks mjg59 is on moscow-ish (or more eastern) time.
<mjg59> ddaa: Heh. No, I'll be awake for a while yet
<ddaa> Mithrandir: not thinking time, but working on the Arch team teached me that people can go to bed at any hour, irrelevent of where they actually live.
<ddaa> * not thinking that
<Mithrandir> even in the early afternoon?  I can go to bed anything between 22-ish and 12-ish, but not between 12 and 22, that's just wrong.
<mjg59> Can C do switch statements on strings?
<Mithrandir> mjg59: no
<Mithrandir> how would you switch on a pointer?
<mjg59> Yeah, thought not
<mjg59> It'd make life massively easier, though
<Keybuk> well, you can, provided you're switching on literal equality
<Keybuk> not just strcmp() returning a particular value
<ddaa> mjg59: if you are concerned by performance, you could probably hack something nifty as a "internable string", with compile-time interned values.
<ddaa> But it would probably not fit any definition of "simple".
<Keybuk> yeah, there's a nice quark layer in glib though :)
<herzi> hmm, if i switch to vt01 by pressing ctrl-alt-f1 i cannot get back or get to another vt
<mjg59> If people could test the dpms package at http://www.srcf.ucam.org/~mjg59/laptops/ that would be great
<mjg59> Note: it'll turn the screen off, but won't turn it back on unless you run it with the on argument. It doesn't track mouse or keyboard events.
<daniels> heh, funny you shoudl mention that
<daniels> I was tooling with some Radeon DPMS code in the laundromat
<daniels> just as junkcode
<mjg59> This is really, really simple
<daniels> it compiled; probably didn't even work, but it was fun in any case
<mjg59> And should be entirely hardware independent
<daniels> using VBE?
<mjg59> Yeah
<mjg59> Just call 0x4f10 with an argument
<mjg59> Arse. The craptop only produces one lid event per open/close
<ChrisH> mjg59: well... "dpms standby" worked. But when I try to get back I have a changed resolution. Far wider than high.
<mjg59> ChrisH: Hmm. Was this under X?
<mjg59> Or on the console?
<ChrisH> mjg59: yes, sir
<ChrisH> mjg59: X
<mjg59> ChrisH: How did you try to get back? Just dpms on?
<ChrisH> mjg59: yes
<ChrisH> mjg59: switching to the console (Alt-Ctrl-F1) and back (Alt-F7) restored the resolution.
<mjg59> Weird.
<mjg59> ChrisH: What graphics hardware is this?
<ChrisH> mjg59: Not a notebook actually. ;)
<ChrisH> mjg59: GeForce 5900 XT
<mjg59> Hm. nv or nvidia drivers?
<ChrisH> mjg59: The evil non-free nvidia module (nvidia-kernel-2.6.6_1.0.6106-3).
<mjg59> Heh
<mjg59> Tricky for me to track down, then :)
<ChrisH> mjg59: I could try with "nv" in a few minutes. Just need to finish a Wiki article.
<mjg59> Sure, no problem
<daniels> i blame nvidia
<cenerentola> what about mataro... 
<daniels> cenerentola: yeah, that's nvidia's fault, too
<mjg59> daniels: I'm thinking of this for the stuff that's in /usr/share/acpi-support/screenblank at the moment - downside is that in the absence of a lid event on open, the screen isn't going to come back
<daniels> mjg59: do we know of anything other than the craptop that don't issue a separate lid event?
* ddaa boggles at how insanely fast the t42p is...
<ddaa> the only reason left i have to use my 5 years old destkop is the ability to have _two_ screens... well, and the fact that external video does not quite work yet, too :-)
<mjg59> daniels: I don't know of anything else, but it's a possibility
<mjg59> Unfortunately, I doubt there's a programatic way of us working that out...
* cenerentola is away: I'm busy
<daniels> mjg59: gah
<daniels> ddaa: what sort of video chipset?
<mjg59> T42 ought to be ATI
<daniels> should work OK with atitvout
<ChrisH> mjg59: Do you happen to know where the 'nv' module can be found in the 2.6.8 kernel config? I seem to be blind.
<ChrisH> mjg59: I'm so stupid. Forget it. ;)
* ChrisH has had too much coffee today
<daniels> ddaa: you might want to try xorg and the 'Option "UseFWPLL"' option
<mjg59> ChrisH: There isn't one, as far as I know
<mjg59> It's only a 2D driver, so it doesn't need kernel support
<daniels> ddaa: that should do the trick (possibly in combination with atitvout) when the monitor's plugged in before X is started
<mjg59> daniels: Have you had a chance to test the i830 dual head stuff under xorg?
<daniels> mjg59: if you could ship a big-arse CRT to room 531, First Hotel Vesterbro, Vesterbro 23-29, Kbenhavn, I promise to do my best :)
<daniels> mjg59: it looks pretty promising, though -- supports both pipes separately
<daniels> (iirc you can also pick which pipe overlays go to)
<mjg59> daniels: xorg-common is missing a depends on lsb
<mjg59> /etc/init.d/xorg-common: line 10: /lib/lsb/init-functions: No such file or directory
<daniels> GNAR
<daniels> craaaack.
<daniels> you can just sub in the xfree86-common init script anyway, does the same stuff
<daniels> thanks for the heads-up
<mjg59> /etc/init.d/xorg-common: line 22: log_begin_msg: command not found
<mjg59> Heh
<mjg59> That's just a deb/ubuntu thing, right?
<daniels> yeah, we have all kinds of LSB initscript crack
<ChrisH> mjg59: same effect... nvidia and nv. I have taken photos and will upload them. Give me a sec.
<ddaa> daniels: I can only assume xorg is hoary stuff...
<mjg59> ChrisH: Weird
<daniels> ddaa: hoary + external archive
<daniels> ddaa: read your list mail
<mjg59> daniels: Massive breakage shifting from xfree->xorg if I was using the i830 drm previously
<ddaa> daniels: sure... just have a few hundreds of them
<daniels> mjg59: the bios probably needs poking in a non-vesa way for non-vesa modes
<mjg59> Oopses all over the place
<daniels> mjg59: does it go away if you restart?
<mjg59> daniels: For the DPMS stuff, it shouldn't really matter
<mjg59> But yeah...
<daniels> mjg59: you'd think not ...
<mjg59> Doing it on the console is likely to be safe
<daniels> yah
<daniels> hence the chvts in thinkpad-x40-support
<daniels> which I need to resurrect now I've lost my sources for the new stuff
<mjg59> Christ. Now the firmware loader has broken again.
* mjg59 is confused
<ChrisH> mjg59: http://workaround.org/dpms/
<daniels> mjg59: not my fault!
<mjg59> ChrisH: Haha
<mjg59> That is *so* cool
<ChrisH> mjg59: Very funny. ;)
<mjg59> I've no idea why it's happening, though
<ChrisH> mjg59: Looks like C=64 retro style. Perhaps you should offer a "--no-commodore-64" option.
<daniels> whoa, that's bong
<mjg59> daniels: Is composite on by default?
<mjg59> Ah, yes
<daniels> mjg59: no
<mjg59> Oh, maybe that was elft over from me palying with stuff at some point, then
<daniels> mjg59: Section "Extensions"\n\tOption\t"Composite"\t"Enabled"\nEndSection
<daniels> mjg59: noting that composite and GLX are currently mutually exclusive
<mjg59> Ha, no - I wanted it off
<daniels> what, you don't enjoy X crashing repeatedly? :P
<mjg59> daniels: Strange as it may seem...
<daniels> mjg59: but it's fun ... you can get backtraces and send them to us
<thom> daniels: he's not allowed to play with X till he fixes the firmware loader ;-)
<daniels> mjg59: btw, xorg fixes the only-one-X-instance-at-once problem
<daniels> thom: that's what you think.  but which is more shiny? :)
<thom> daniels: swsusp
<daniels> thom: fwiw, it's 2C right now, and I just went running before in a singlet and shorts.  does London get much colder?
<daniels> thom: yeah, fair point
<thom> is the ultimate shiny
<thom> ok, you're a freak
<daniels> thom: although, in winter, not having any suspend at all and starting X compiles is the ultimate shiny
<thom> london probably won't be any colder than that, no
<daniels> thom: you put it in your backpack and it warms your back a bit :)
<ddaa> mjg59: kernel news: cpufreq works however the firmware for ipw2200 still fails to load.
<thom> heh
<daniels> thom: to be fair, as I said, I was running
<mjg59> ddaa: Hmm.
<ddaa> mjg59: suspend to ram... suspended... and that's about all.
<ddaa> It won't wake up.
<mjg59> ddaa: Weird.
<ddaa> Want me to run some additional diagnostic?
<mjg59> ddaa: What do you mean by won't wake up?
<ddaa> The moon led stays lit, no cpu or hd activity, no reaction to keyboard or lid actions.
<ddaa> It's sleeping for all I can tell.
<mjg59> Right
<nasdaq4088> interesting article: http://www.eweek.com/article2/0,1759,1714680,00.asp#talkback
<mjg59> Have you tried the power button?
<ddaa> Short presses have no effect.
<ddaa> A long press will probably shut it down though.
<mjg59> Try for a couple of seconds
<mjg59> Less than 4, but more than 1
<ddaa> Done. No effect.
<mjg59> Hrm.
<mjg59> Can you reboot it and take a look at the contents of /proc/acpi/wakeup ?
<mjg59> Meanwhile...
<mjg59> Any hotplug gurus around?
<ddaa> mjg59: btw, it's still w/o any acpi_sleep option.
<mjg59> ddaa: Shouldn't make any difference
<ddaa> Not that it should make any difference from what you said.
<mjg59> (Well, in theory)
<ddaa> mjg59: LID
<ddaa> mjg59: LID and SLPB have sleep state = 3 and status = *enabled.
<ddaa> all the rest is sleep state 3 and status disabled except for PCI1 and AC9M which have sleep state 4.
<ddaa> not the * in "*enabled"
<ddaa> *note the *
<mdz> mjg59: what about hotplug?
<mjg59> mdz: How many arguments should the kernel be passing to hotplug when it's loading firmware?
<mdz> mjg59: I'm not sure it passes any arguments; it should send a few environment variables
<mdz> #       ACTION=%s [add or remove] 
<mdz> #       DEVPATH=%s [in 2.5 kernels, /sys/$DEVPATH] 
<mdz> #       FIRMWARE=%s
<mjg59> Ah
<zopi> does acpi=off is writting on the wiki for Via Chipset ?
<zopi> because before enable it Ubuntu was very slow to install and booting !
<mdz> zopi: I have a VIA chipset and it works fine without acpi=off
<zopi> mdz : arf 
<mjg59> ARGH, YOU BLOODY USELESS PIECE OF SOFTWARE.
* mjg59 discovers that the hotplug is trying to send firmware to /initrd/sys
<mjg59> ddaa: Can you try umount /initrd and then rmmod ipw2100; modprobe ipw2100
<mjg59> Hrm. No, that /shouldn't/ be it
<ddaa> mjg59: umount: /initrd: device is busy
* ddaa goes single user
<ddaa> device is still busy
<mjg59> ddaa: Ah - umount /initrd/sys
<mjg59> Then umount /initdr
<mjg59> I see what the problem is...
<ddaa> seems to work better
<ddaa> okay, that I had to fiddle a bit to unfuck resolvconf, but I can now ping the outside world.
<mjg59> ddaa: There's a new initrd-tools at http://www.srcf.ucam.org/
<mjg59> ~mjg59/laptops
<ddaa> no additional action requested besides installing it?
<mjg59> If you could install that and then either reinstall the same kernel image or do mkinitrd -o /boot/initrd.whatever
* ddaa will stick to good'ol dpkg
<ChrisH> Some of you guys are probably still maintaining Debian packages. Are you using Ubuntu on your workstations and doing packages from there? Or do you have a seperate installation for Sid. I'd like to reinstall to Ubuntu but am not sure if I will break anything.
<ddaa> mjg59: dude, you rock
<mjg59> ddaa: Excellent
<thom> ChrisH: use a debian chroot, but i'd strongly recommend you keep a sid partition around for testing
<ddaa> but suspend to ram is stiff fubared
<mjg59> ddaa: That's a bit weird. I've just tested it here.
<ddaa> mjg59: actually, on wake-up, it emits a small bip and the battery led turns on.
<ddaa> Then that's all...
<mjg59> Hrm.
<mjg59> ddaa: Can you try with init=/bin/bash ?
<ChrisH> thom: I'd probably use pbuilder or debootstrap anyway. So I guess it could be possible.
<ddaa> mjg59: not right now, I'm called for dinner.
<ddaa> mjg59: but I'll do when I get back.
<mjg59> ddaa: Heh, no problem :)
<__randy___> Where to do I go to submit a package request for Hoary?
<thom> mjg59: ok, that initrd-tools has fixed wireless for me
<mjg59> ddaa: Hmm, I can reproduce that now
<mjg59> ddaa: Ah, got it
<mjg59> ddaa: It needs the PCI hotplug drivers blacklisted
<Mithrandir> YAY!
<Mithrandir> fakeroot has stopped segfaulting
<thom> cool
<Mithrandir> seems I got completely rid of TLS in the process, though :/
<thom> ah
<thom> possibly not ideal
<Mithrandir> possibly very non-ideal. :/
<lupus_> the 2 icons in the panel
<lupus_> firefox, evolution and help
<lupus_> by which package are they put there?
<seb128_> gnome-panel
<lupus_> because the evolution icon points to evolution-2.0
<lupus_> instead to evolution
<seb128> will be fixed in the next upload
<lupus_> k
<mjg59> Hmm. I'm now very, very confused about the suspend/resume issue.
<ddaa> mjg59: still want me to try with init=/bin/bash?
<mjg59> ddaa: If you could, that'd be great
<ddaa> I s'pose that I should remove ro option too?
<mjg59> init=/bin/bash seems to work fine for me. If I run hotplug, things don't work. If I load the same modules by hand, things do work.
<mjg59> There's something subtle going on
<lupus_> k I have music on a vfat partition
<lupus_> but if you mount a filesystem
<lupus_> you can not point to the link on the desktop
<lupus_> to the filesystem
<lupus_> created by gnome-vfs (g-v-m,hal)
<lupus_> nm
<lupus_> the problem seems to be that the old app does not support this kind :S
<lupus_> in it's fileselector
<ddaa> what's the command to remount root as rw?
<thom> mount -o remount,rw /
<ddaa> I'm definitely not managing to get something out of that init=/bin/bash situation
<ddaa> mjg59: okay, if I hack off /etc/init.d/hotplug, then s3 works okay in single user mode.
<mdz> elmo: around?
<Mithrandir> doko: around?
<ddaa> mjg59: okay, with hotplug hacked off, I can suspend-to-ram and it wakes up okay.
<ddaa> even if full multi-user mode.
<ddaa> of course, suspend to disk, cpufreq, and the ipw2200 (once loaded manually) still work okay
<ddaa> however, the hibernate key is inoperative... but I suppose that's because I am missing some module.
* ddaa awaits further requests
<ddaa> mjg59: wow...
<ddaa> did /etc/init.d/hotplug stop, then pressed the sleep button.
<ddaa> It worked....
<ddaa> Now, try to figure that one out :-)
<ddaa> nevermind, was using warty kernel.... (me blushes)
<mjg59> ddaa: I think  there's some strange timing issue or something
<ddaa> Mh... anything to back that up, or it's just because you just have no idea?
<mjg59> I'm finding that I get some strange messages from acpi under certain circumstances with this kernel
<mjg59> Odd stuff about functions returning AE_TIME
<Mithrandir> thom: it seems libc is at fault, but we build glibc the same as debian, where the problem doesn't show.
<Mithrandir> thom: so I'm thinking of blaming doko.
<Mithrandir> (or gcc)
<mjg59> Which is odd, because there's almost no difference between 2.6.10-rc1-bk17 and 2.6.10-rc1
<mjg59> In terms of acpi, anyway
<ddaa> Well, maybe you can make me a 2.6.10-rc1 kernel so I can test what is going on?
<ddaa> That would narrow the problem somewhat.
<mjg59> Ah - the previous kernel I gave you had more recent acpi
<mjg59> Hang on, let me try something...
<mjg59> Hrm. Damnit, this may require rebuilding all the modules as well.
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | Hoary is here: http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html | Want to help? see https://www.ubuntulinux.org/wiki/HoaryGoals | please do NOT upload ubuntu-meta
#ubuntu-devel 2004-11-19
<mjg59> ddaa: Ok, think I've got it
<mjg59> Newer acpi code seems to help
<mjg59> Just let me do a couple of checks
* ddaa lets mjg59 do a couple of checks
<mjg59> Gah.
<mjg59> No, that's not happy.
<mjg59> Oh, now that's very odd
<mjg59> The video has come back, but the sleep light is still on
<mjg59> Which implies that it's woken stuff up but never called the return from sleep ACPI methods
<mjg59> Gah. No, this is irritatingly broken.
<ddaa> mjg59: I'm turning into a pumpkin
<mjg59> ddaa: Sorry, I'm entirely failing to track down the problem here.
<ddaa> bah... sleep on it... maybe you'll get new ideas.
<ddaa> or maybe give me additional instructions to isolate what in hotplug is breaking.
<ddaa> In any case, goodnight.
<hornbeck> jdub: you around?
<lifeless> mdz: ping
<jdub> hornbeck: yo
(seb128/#ubuntu-devel) hum
<maswan> elmo: We're reducing the frequency of updates for the ftp.acc.umu.se mirror, pending fewer "max connection reached" cron mails.
<fabbione> xorg-redhat-die-ugly-pattern-die-die-die.patch
<fabbione> ahhaha
<fabbione> that's the patch we were looking for
<fabbione> to kill the X pattern
<seb128> nice name :)
<maswan> this way, we'll only get it once a day, like all the other cron mails saying something is broken. :)
<jdub> seb128: ah no, it's okay
<seb128> cool
<robtaylor> fabbione: hurrah! at last!
<fabbione> no it won't be today
<fabbione> i found a bunch of bugs that need to be fixed before release
<robtaylor> fabbione: boh. its only a two line chage ;)
<mojo_> fabbione: y he cheered up? is it b/c X.org out already????
<fabbione> robtaylor: ?
<fabbione> mojo_: what?
<robtaylor> fabbione: i was talking about xorg-redhat-die-ugly-pattern-die-die-die.patch
<robtaylor> <fabbione> ahhaha
<fabbione> mojo_: please write plain english
<fabbione> robtaylor: ahh
<mojo_> fabbione: I just want to ask when the 1st beta CD of Hoary that contains X.org out?
<fabbione> mojo_: we need to get X.org into the archive first
<jdub> mojo_: there won't be a 'beta' until march
<mojo_> jdub: thx for the info
<mojo_> I and my friends has finished creating pure GNOME theme for Downloader X (d4x), I'm looking forward to seeing some maintainers here to include d4x in next release (I still work on optimizing d4x for Ubuntu)
<sivang> Is there a current list of bounties for Hoary already?
* Kamion turns cdimage's cron.daily back on
<Mithrandir> hi Kamion, how's the head?
<Kamion> much better now, thanks
<Mithrandir> good to hear. :)
<thom> morning folks
<jdub> morning thom
<seb128> hey thom 
<Mithrandir> thom: if you have any great ideas on why our libc is broken while the one in Debian is fine, I'd be very grateful.
<Mithrandir> they're built the same way
<thom> exactly the same? if you build the two packages manually you still get brokenness on our one?
<thom> something freaky that linker optimisation does?
<thom> (it seems unlikely, but i thought i'd throw it out there(
* fabbione commits suicide
<Mithrandir> fabbione: please, don't
<fabbione> well
<fabbione> foo 1.0 ships /etc/foo.conf
<fabbione> foo 2.0 ships /etc/foo2.conf
<jdub> thom: i don't think we do linker optimisation for libc
<fabbione> the upgrade doesn't remove foo.conf
<jdub> thom: only gnome packages that do it in debian/rules
<fabbione> if even foo.conf is not modified
<Kamion> fabbione: that's a feature
<Kamion> well, not sure about when it's not modified
<fabbione> Kamion: it sounds a bug to me
<fabbione> and i need to workaround it for approx 20 files
<Kamion> when it's not modified, maybe
<fabbione> i understand perfectly when it is modified
<Mithrandir> thom: I'm going to build the pure64 on hoary and see if that helps.
<fabbione> soooo now i need to add a shit load of checks into upgrade scripts
<Kamion> what does it mean when update-mozilla-firefox-chrome tells me "E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still present. Registration might have gone wrong."?
* fabbione wants to orphan X
<jdub> heh
<thom> Kamion: that you might have old extensions that haven't registered themselves with 1.0 correctly, i believe
<fabbione> jdub: you can adopt it now.. so you can split your l33t composite libraries and fix the 200K bugs as well :-)
<jdub> heh
<jdub> sweet!
* fabbione watches jdub paiting the walls with fresh blood while fighting with Imakefiles
* pinhead shows jdub the pleasure of pain
<Kamion> thom: the thing is that I'm in the process of converting an old extension *to* 1.0, and this error only started to show up in the middle of the conversion
<Kamion> I'd kind of like to know what exactly "might have gone wrong"
<thom> Kamion: oh, right. no idea :/
<cenerentola> jdub: have you got time for me..?
<cenerentola> kamion: i love you
<Kamion> uh, ok
<cenerentola> sorry but is that difficult to speak with any canonical's related with PR?
<cenerentola> are you all going to mataro?
<jdub> everyone in canonical is going to mataro
<jdub> i'm here now
<jdub> what can i help you with?
<cenerentola> ok...
<cenerentola> as you may not know.. an italian ubuntu community was born
<cenerentola> las... 
<jdub> you posted about it on the mailing list
<cenerentola> that was an italian spoken link
<cenerentola> btw... as you said ive contacted the guys from ubuntuforums..
<cenerentola> its all ok for them, the forumll be up in moments.. now what about the mailing list?
<jdub> it's on the way
<cenerentola> thx.. now what about translating the website...
<cenerentola> should i host it on ubuntulinux.it
<jdub> the ubuntu site is translatable
<jdub> speak to lulu 
<jdub> about it
<cenerentola> or that's not necessary, and youre going to host it on ubuntulinux.org
<cenerentola> mind im not talking about the wiki... ok then
<cenerentola> what about the cds? 
<jdub> what about them?
<cenerentola> ive ordered about 90 cds.. for free give-aways
<cenerentola> during the linux day, nation-wide...
<cenerentola> but as otherlugs said theyre not enough...
<lulu> cenerentola: we're looking into linguaplone for the website, but it will be a little while before it's up and running. So, in the interim, we suggest you go ahead and translate, and we can integrate your translation work when it's in place.
<sivang> lulu : have you checked the credential problem on the CMS ?
<lulu> sivang: looking into it :o)
<Kamion> thom: *sigh* was a one-character mistake in the install.rdf file, url:mozilla:... instead of urn:mozilla:...
<Kamion> nice of it to give me such a clear error message so that I didn't have to compare it against another install.rdf file line by line to figure out what was wrong, wasn't it? :)
<thom> Kamion: see my total lack of surprise
<Kamion> heh
<cenerentola> kamion: let me introduce you to the beauties of perl that could do it for you... larry bless
<Kamion> cenerentola: I'm sorry, but you're making no sense
* Kamion <-- already a perl hacker
<Kamion> cenerentola: perl or indeed diff wouldn't have helped, I was comparing the sense of the files not the exact text.
<cenerentola> kamion: it could tell you what words written in a certain manner did appear in only one file
* sid77 hello
<cenerentola> kamion: that was a joke
<jdub> thom: so, a funny thing happened when my acpi started working
<Kamion> ... on the way to the forum
<thom> jdub: ahr?
<jdub> thom: i popped my laptop on the dock, closed the lid, and turned to the keyboard/mouse as usual
<thom> yup?
<jdub> lock and chvt :-)
<jdub> uh oh!
<jdub> :-)
<jdub> so i've been thinking about an NM-like power management controller
<Keybuk> tedious, long-winded and a long wait at the end?
<jdub> also, i can't find a way to figure out if this machine is docked
<jdub> dmidecode | grep Chassis -A 10
<thom> you don't get any events when you dock at all?
<thom> Keybuk: heh
<jdub> ^ returns the docking station stanza if i booted docked
<jdub> well, the USB CD device turns up
<jdub> but otherwise, no
<jdub> i'll have to investigate further
<jdub> though, even if i can find something for this lappy, it's going to be very hard to generalise
<jdub> (one of the benefits of separate windows drivers is setting policy for the particular hardware, not generalising in the OS)
<jdub> thom: read nm list recently?
<thom> jdub: walters VPN stuff?
<jdub> yeah
<jdub> "let's redo dhclient!"
<thom> it's MAJOR crack
<thom> and typical redhat
<thom> sooo, i get an alpha tomorrow
<Keybuk> heh, what kind?
<thom> XP1000
<thom> 500Mhz ev6
<thom> so google tells me
<jdub> you're collecting heaters? :)
<cenerentola> jdub: what about the cds then?
<thom> jdub: i nearly have everything that debian supports bar the silly arches
<thom> well, if you count mips* as silly, i'll have the lot soon
<Keybuk> not bad
<Keybuk> it's just about getting cold enough for me to boot mine up again
<ChrisH> We (Doc Team) are about to install a repository. Is "arch" the tool to use in Ubuntu? I had intuitively used SVN. Or does it really not matter? :)
<jdub> cenerentola: the CDs are being distributed this month
<jdub> cenerentola: please try to keep discussion on channel :)
<jdub> cenerentola: and be patient for answers
<cenerentola> <cenerentola> ive ordered about 90 cds.. for free give-aways
<cenerentola> <cenerentola> during the linux day, nation-wide...
<cenerentola> <cenerentola> but as otherlugs said theyre not enough...
<jdub> cenerentola: the CDs are being distributed this month, if other LUGs want to order CDs, they can too
<cenerentola> they told me to do the job... as they're looking at btlug, as the community center in italy
<cenerentola> ..since
<cenerentola> ...
<jdub> so what's the problem?
<cenerentola> am i allowed to order more cds?
<jdub> yes
<jdub> just go to the site and change your order
<cenerentola> ok thx
<fabbione> ok... the config file issue should be solved
<fabbione> files
* fabbione runs another build
<fabbione> cache hit                         328529
<fabbione> cache miss                         19900
<fabbione> it's not like i have been speding cpu cycles on anything else :-)))
* fabbione grabs some food
<seb128> fabbione: I've forgotten to mention it, but since the Xfree -> X.org I get "Gdk-WARNING **: locale not supported by Xlib" and "Gdk-WARNING **: cannot set locale modifiers" when I start a GNOME app
<thom> seb128/fabio: me too
<seb128> cool :)
<Kamion> jdub: so, given that I've just built the first probably-working Hoary CD set, when do you reckon would be a good target for Array CD 1?
<jdub> Kamion: so i've been thinking about hoary cds
<jdub> Kamion: i kinda think it's a bit weird to have announced testing cds so early ;)
<Kamion> depends on your point of view :)
<jdub> ;)
<jdub> making installer changes already?
<Kamion> (impossible to get installer testing any other way)
<Kamion> well, I did just do the mass merge from Debian
<Kamion> and yeah, expect a number of early installer changes
<jdub> let's just do it then ;)
<jdub> though probably make the announce blurb scary enough
<jdub> so that people don't feel that CD availability == 'beta' or encouragement, etc.
<Kamion> can I put in a request for array cds to be scheduled for Wednesdays this cycle? :)
<jdub> totally
<jdub> wednesday is the optimal day
<Kamion> the sounders being on Monday tended to result in me coming in after the weekend to find they were totally hosed
<jdub> mmm, they weren't meant to be monday ;)
<Kamion> after a while, they weren't. :-)
<Kamion> ok, let's make this Wednesday's cron.daily run be Array CD 1 then
<jdub> i dunno why i copied the older gnome style calendar
<jdub> i'll fix that up 
<Kamion> give it a couple of days to settle
<Kamion> beta> yeah, I set the CD label to "Alpha"
<Mithrandir> "early crack". :)
<fabbione> seb128, thom: i always got that message since X4.1.0
<fabbione> if you can figure out what is wrong it would be cool
<seb128> ok
<Kamion> jdub: (historically, the two-week CD cycle has been pretty good at making me get off my arse and finish my current round of changes, too :))
<jdub> :-)
<thom> elmo: please sync wireless-tools from unstable
<fabbione> elmo: please sync apache from unstable
<fabbione> apache1.3
<seb128> elmo: please sync gnumeric 1.3.93 from experimental
<fabbione> elmo: please xorg from fd.o
<fabbione> ;)
<jdub> haha
<seb128> oups, gnumeric 1.3.93 is in unstable
<seb128> but still, need a sync
<doko> mithrandir: could you solve your glibc build problem?
<Mithrandir> doko: nope :/
<Mithrandir> doko: the problem goes away if I turn off TLS
<Kamion> seb128: any news on that fam/gamin thing in libgnomevfs2-common?
<seb128> gnome-vfs2 (2.8.3-0ubuntu3) hoary; urgency=low
<seb128>   * debian/control.in:
<seb128>     - Build-Depends on libgamin-dev | libfam-dev.
<seb128> installed here
<seb128> I've forgotten to upload ?
<Kamion> could be, dunno, just looking at germinate output
<seb128> Kamion: I was probably waiting to restart a session with the new package to be sure that all is ok
<Kamion> ah
<seb128> Kamion: uploading now
<jdub> seb128: i've been using gamin on warty for ages now, btw :)
<Kamion> I'll go fix libwvstreams3-base now
<doko> mithrandir: did you prepare a new ia32-libs-openoffice.org package, or can I upload one without lib32gcc1 when I update to the new gcc-3.4.3 package?
<Mithrandir> doko: no, I haven't done it.
<Mithrandir> so please upload a new one in sync
<fabbione> doko, Mithrandir: is it normal that gcc fails all the test suite and still considered to build fine?
<fabbione> FAIL: gcc.c-torture/compile/20000504-1.c,  -O3 -g  
<fabbione> i see pages and pages of stuff like this
<doko> which architecture?
<fabbione> sparc
<doko> 3.3, 3.4, snapshot?
<fabbione> 3.3
<doko> on the buiildd?
<fabbione> yes
<doko> 20001226 is the only testcase that fails at http://buildd.debian.org/fetch.php?&pkg=gcc-3.3&ver=1%3A3.3.5-2&arch=sparc&stamp=1098710590&file=log&as=raw
<fabbione> hmm weird
<Mithrandir> fabbione: I don't know anything about gcc. :)
<fabbione> ok cool
<fabbione> config file transition is ok
<fabbione> people might have to merge manually if they did some modifications, but that's how it is
* fabbione wonders if daniles is still alive
<doko> fabbione: are you working on a sparc port?
<doko> daniel alone in Copenhagen, part II?
<fabbione> doko: yes to the sparc port
<fabbione> daniel was very very ill this morning
<fabbione> he wrote me in pvt "brb"
<Kamion> ouch :(
<fabbione> and he didn't come back anymore
<Mithrandir> ew
<fabbione> i think he has been hitted by danish primes ;)
<Kamion> hang on, I thought you guys were in the same building?
<fabbione> i might have to go and take a look if he doesn't resurrect within dinner time
<fabbione> Kamion: he still sleep at the hotel
<Kamion> ah
<fabbione> my house is a building site
<fabbione> i don't really have place for people to sleep here
<fabbione> he barely has a chair where to sit :)
<Kamion> well, hope he gets well soon
<fabbione> yeah i am pretty sure he will be alright
<thom> grah, are any of the gnome anoncvs mirrors even vaguely up to date?
<seb128> define "vaguely"
<jdub> depends on your definition of 'up to date'
<thom> less than 2 days delta?
<tseng> that reminds me, whats up with the tarball feed on pgnome/news
<jdub> tseng: dunno, noticed it but haven't checked
<tseng> hrm
<fabbione> daniels is still alive :-)
<thom> goodo
<doko> elmo: please sync gcc-3.3 from unstable
<fabbione> and the ati driver fix is compiling now
<Mithrandir> so you haven't been able to kill him with danish food, yet?
<fabbione> time to mount the metal bars on the dinining table :-)
<fabbione> Mithrandir: nope :(
<doko> danish "food"? flavours and colour addons dominate danish food (although a good hot dog ...)
<fabbione> doko: he had a hot dog yesterday evening
<fabbione> that's why he is close to die
<doko> feed him danish soft ice cream, that will help ;)
<carlos> seb128: new evolution does not let me send any mail...
<carlos> seb128: is it a know bug?
<seb128> no
<carlos> seb128: it gives me connection refused, but the server works from a direct telnet session
<seb128> carlos: not a ssl issue ?
<carlos> seb128: the smtp + ssl is activated after the connection is done (it uses also the port 25)
<carlos> let me change the smtp server...
<seb128> carlos: it that ok if you don't use an ssl connection ?
<carlos> seb128: testing it, btw, after the upgrade the auth option for the smtp is disabled, I need to renable it by hand (but i'm not able to test it at the moment)
<carlos> seb128: yes, the problem is the "Use Always SSL option"
<carlos> for sending, without it, it works
<seb128> ok, so that's not an evolution problem apparently :)
<carlos> are you sure?
<carlos> Same options, same server, evolution 2.0 worked without problems...
<seb128> the last bug reports about this have been closed a NOTXIMIAN IIRC
<seb128> saying that's due to the server which is buggedf
<seb128> -f
<amu> moinD
<seb128> hi amu 
<carlos> seb128: could you give me an URL for that bugreport, please?
<fabbione> amu: we have a fix for that segfault you were getting with X.org
<seb128> carlos: I've http://bugzilla.ximian.com/show_bug.cgi?id=68444, but it was with an imap server .. looking for mail sending
<carlos> seb128: don't worry
<carlos> I will search for it
<carlos> I thought you had it located already
<fabbione> workrave is yelling and screaming at me
<fabbione> bbl
<seb128> carlos: have you tried to wait some minutes ?
<Mithrandir> did we ever get a ical feed with meetings and stuff?
<carlos> seb128: some minutes?
<carlos> for what?
<carlos> the problem is that it does not reachs the server or it tries to connect to the wrong server
<seb128> carlos: to get the mail sent
<carlos> the server logs does not have any connection attempt logged
<carlos> seb128: yes, and same error
<seb128> oh, you have an error ?
<seb128> I thought is was just hanging
<seb128> ok, so probably not the same issue I was thinking of
<seb128> if you open an upstream bug please Cc: me :)
<carlos> ok
<carlos> :-)
<carlos> seb128@debian.org or canonical.com?
<seb128> debian
<carlos> ok
<seb128> I've not created different accounts with the new email
<sivang> seb128 : have you patched #2221 yet?
<seb128> sivang: no, so many bugs, I've not had time yet :/
<seb128> sivang: if you want to test the fix that would be nice :)
<carlos> seb128: I will look at it tonight after work hours, I can use my local smtp server until it's fixed
<sivang> seb128 : got it! :)
* sivang finally found a reasonable patch to test
<sivang> seb128 : did you track down the bug at all ? or just attched the proposed patch?
<sivang> seb128 : I mean, I understand what happened in the perl code, just not sure when it did :)
<seb128> I've not added anything
<seb128> the upstream devel has attached the patch which has been commited in the CVS
<sivang> seb128 : ok, I will test the fix
<jdub> far out
<jdub> stupid bogofilter
<jdub> gar gar
* jdub reads "we punched you in the face again!" in the bogofilter NEWS file
<thom> time to try NM with a wired connection, lets see how badly this breaks
<thom> badly
<thom> oh well
<Kamion> d'oh! I never uploaded the merged countrychooser
<elmo> thom/fabbione/seb128/doko: done
<seb128> thanks
<fabbione> elmo: also x.org? ;)
<fabbione> elmo: thanks btw.. you still rock!
<Mithrandir> elmo: seems we don't have elfutils in universe, could you sync that?
<sladen> does anyone have pictures from Oxford of the usplash whiteboard?
<elmo> Mithrandir: I don't see it in Debian ?
<elmo> Mithrandir: #221761
<elmo> fabbione: just apache, I'm afraid
<thom> elmo: grazi :-)
<Mithrandir> elmo: sorry, I'm trying to track down what the package is; I need it for some glibc debugging.
<Mithrandir> elmo: argh, ok.
<thom> sladen: i thought someone had it, but can't recall who
<sladen> thom: that's what I thought too.
<sladen> thom: can you remember who else was around and awake?
<Kamion> it didn't all get transferred to the wiki?
<sladen> Kamion: yes, hopefully.  I'm drawing to draw up all the documentation I can
<thom> sladen: Kinnison ?
<fabbione> daniels: you around?
<daniels> fabbione: yeah, just got in
<daniels> reading email now
<daniels> the fruit didn't help any, but I'm at least capable of basic mobility now
<Mithrandir> daniels: how are you feeling?
<daniels> like utter crap
<Mithrandir> what happened?  stomach revolt?
<daniels> quite violent armed revolution, yes
<daniels> so I spent most of today in bed; dragged myself up and went out to find some real food and got some fresh air before, starting to feel vaguely human again
<fabbione> any arch guy around?
<daniels> lesson #2 for the week: pasting URLs into mutt can cause mail loss
* sivang wonders if there is any way of feeding mutt with food from stdin
<daniels> just paste http://www.happycow.net/europe/denmark/copenhagen/ into the folder of your choice
<daniels> list folders recommended (glad I didn't lose any personal/non-archived mail)
<ddaa> fabbione: wassup?
<fabbione> ddaa: i am having a problem with baz
<fabbione> to tag a release
<fabbione> and i was searching a simple wy to do an "export"
<ddaa> tag was phased out in favor of switch
<ddaa> oops
<ddaa> * in favor of branch
<ddaa> Which does tag+switch
<daniels> ddaa: the problem is that xorg--debian--6.8.1-0.3 is apparently an invalid version
<daniels> can the version not have a - ?
<fabbione> branch: invalid version name -- xorg--debian--6.8.1-0.3
<ddaa> daniels: no, it cannot
<daniels> tagging for every debian revision is pretty important to us, because it's the only way to ... ah crap
<ddaa> if you want to call you revisions by arbitrary names, use a one-line config
<daniels> any way around this, other than a text file noting that 6.8.1-0.3 == --patch-9?
<daniels> have a config that looks like '6.8.1-0.3 xorg--debian--6.8.1--patch-9'?
<ddaa> The usual practice is to create a 'dists' category with all configs.
<daniels> any documentation I should be reading on configs?
<fabbione> ddaa: ok.. what about "export"?
<ddaa> daniels: no, make the arbitrary version the name of the config file
<mdz> lifeless: pong
<ddaa> the content of the configs only gives the revision and the directory name to get to.
<ddaa> fabbione: how generic an export do you want?
<ddaa> Want support for spaces and other weird stuff in file names?
<fabbione> ddaa: like cvs export or svn export
<ddaa> The "simple" export, until it's implemented in baz, looks like:
<fabbione> ddaa: i want something that works indipendently of what i have
<ddaa> (me checks if that's not already in the wiki, that's a faq)
<ddaa> fabbione: the fully general one is a bitch, let me look
<daniels> ddaa: oh, right
<ddaa> because of drug-abuse^W^W pika-escaping in inventory output
<fabbione> ok
<daniels> ddaa: so, echo versions/6.8.1-0.3 xorg@canonical.com/xorg--debian--6.8.1--patch-9 > dists/version-6.8.1-0.3 ?
<fabbione> i think i will be faster removing .arch by hand
<ddaa> daniels: would call it something like dist/xorg/6.8.1-0.3, and It would use a fixed source tree name (e.g. xorg) instead of "versions/6.8.1-0.3"
<ddaa> uuu
<ddaa> configs/xorg/6.8.1-0.3
<daniels> ddaa: ok, thanks
<fabbione> daniels: ok. i killed the arch stuff.. i will release with what's in the archive now
<ddaa> fabbione: let me look, there is probably a script around
<fabbione> daniels: mind to take care of tagging?
<fabbione> ddaa: i have done already thanks
<mdz> morning
<ddaa> fabbione: why ask for something if you cannot be bothered to wait 5 mins for the answer?
<Kamion> fabbione: you could just use dpkg-buildpackage's support for excluding files
<Kamion> then you can just build out of a working tree
<ddaa> fabbione: notwithstanding that you make me feel like an idiot.
<fabbione> ddaa: because i am in short of time. sorry. nothing to make you feel like an idiot
<fabbione> Kamion: oh nice.. thanks. i will look into that
<Kamion> you want the -i option
<fabbione> ddaa: again.. thanks. i appreciate anyway and having an official way to do so is better
<daniels> fabbione: i'll start building up some configs tonight
<fabbione> ddaa: i am still here listening..
<daniels> fabbione: i might have to drop off in a bit (or maybe I'll just put some gloves on and sync my mirror) because my hands are freeeeeeeeeezing ;)
<Kamion> fabbione: the default value for -i already ignores {arch} and .arch-ids, though
<Kamion> fabbione: unless you're building a native package, you should just be able to build away ...
<ddaa> fabbione: okay, it's going take a little time, the recipe on the wiki is shit.
<fabbione> Kamion: ah ok.. i need to see how it interact with dpkg-source -b
<fabbione> ddaa: ok thanks :-)
<Kamion> fabbione: this is in dpkg-source
<fabbione> Kamion: even better :-)
<fabbione> anyway... 6.8.1-0.3 is building.. expect a drop in a hour or so
<fabbione> tomorrow we will go live
<fabbione> FASTEN YOUR SEATBELT BABY!
<fabbione> daniels: i will leave as soon as i can update the package files
<fabbione> daniels: gf is pretending some time with her
<fabbione> daniels: and i can't say she is not right
<daniels> fabbione: sure, tha's fine
<daniels> fabbione: if you need me to ssh in, check progress, upload, whatever, let me know
<daniels> fabbione: i've got a while till I'll go back and crash
<fabbione> daniels: nah i have evertything under control
<fabbione> daniels: go and rest
<fabbione> and come back alive tomorrow
<daniels> awesome
<fabbione> daniels: get ready for a long run :-)
<daniels> heh :)
<Kamion> elmo: any idea where wvstreams 3.75.0-1ubuntu3 went? I got an ACCEPTED mail, but the actual package seems to have disappeared into the ether
<fabbione> elmo: do you think you can be around tomorrow when we upload x.org?
<daniels> fc3 out with gnome 2.8
<azeem> what version is NLD featuring?
<tseng> 2.6
<tseng> if it matters.
<tseng> from what ive seen so far, it doesnt feature anything revolutionary
<tseng> a bit of integration with with novell network services
<tseng> and the openoffice improvements ximian has had for about a year now
<Mitario> hello everyone
<fabbione> daniels: only ppc missing :-)
<daniels> fabbione: rad
<fabbione> it's building the debs now
<fabbione> ok.. they are all up
<daniels> sweet
<fabbione> mail is on the way
<fabbione> chroots are clean again...
<daniels> so we do the split and then upload?
<daniels> (tomorrow)
<fabbione> daniels: yes. split -> test -> test -> test -> test -> test -> test -> upload
<fabbione> daniels: than we need to run to the airport and catch the first plane directed to any unreachable island in the pacific
<daniels> heh, cool :)
<daniels> australia is pretty unreachable in late december, i discovered :P
<daniels> plus, we have no internet there
<fabbione> yeah.. but people must not know where we are going
<fabbione> ;)
<fabbione> anyway
<fabbione> i am off :-)
<fabbione> everything is in place
<fabbione> mail is out
<fabbione> daniels: if you see mako around ask him to prepare an official announcement
<fabbione> or something
<fabbione> cya tomorrow
<daniels> ok, sure
<daniels> night dude
* Kamion has languagechooser changes that at least make a brave attempt to do UTF-8 by default
<daniels> Kamion: nice one
<daniels> ok, I'm heading back to the hotel (battery virtually dead, should attempt dinner anyway) now, might be online later on depending on how I feel
<Kamion> does anyone know if .UTF-8@euro locales are useful for anything?
<daniels> else, see you all tomorrow
<Kamion> default currency choices or something?
<Mithrandir> Kamion: they're not useful.
<Kamion> are they identical to .UTF-8?
* Kamion looks at #274491
<seb128> Kamion: #1755 
<Kamion> yeah, that's pretty much the same as Debian #274491
<Kamion> ah, but with more useful information
<seb128> yeah :)
<Kamion> ok, so the installer shouldn't perpetuate those
<justdave> I was hoping Apple would have updated Disk Utility in 10.3.6 (just came out a couple days ago) so it wouldn't crash when you try to burn Ubuntu images, but no such luck.
<ddaa> fabbione: in case you read the backlog, here is the excruciatingly complete recipe to export an arch tree: http://wiki.gnuarch.org/moin.cgi/Arch_20Recipes#export
<fabbione> ddaa: cool!
<ddaa> fabbione: It's also likely that fai has something packaged for that.
<ddaa> In the medium term, baz should have something built-in, too...
<fabbione> nice
<ddaa> Now, you understand why I could not answer right away? :-)
<fabbione> sorry but mine wasn't a complain
<fabbione> i don't want you to feel that way
<ddaa> Np.
<fabbione> but yes i understand :-)
<Kamion> fai? argh, name-clash
<ddaa> Kamion: yeah, yeah... feel free to propose another name to abentley... anyway, most/all of it is probably going to be folded into baz eventually.
<ddaa> fabbione: I just got irked by the "how can I do this? <scramble to find the correct, non-obvious, solution> Nevermind, I did it by hand." But I understand you were in a rush. So no problem.
<fabbione> ok...
<fabbione> gotta go for real now
* ddaa -> dinner
<Mitario> is there a way to check which version of ubuntu is installed? (hoary, warty for example)
<amu> less /etc/lsb-release
<Mitario> ah!
<Mitario> ty
<Kamion> elmo: can I have busybox-cvs-floppy-udeb, di-utils-bootfloppy, load-floppy in main please?
<amu> Kamion: maybe i'm little late, but happy birthday! 
<Kamion> amu: thanks :-)
<Mithrandir> Kamion: do you remember what we did about the netboot branding thingies?
<Mithrandir> Kamion: (as elmo reported in 3246)
<Kamion> it's just choose-mirror, branding like any other
<Kamion> looks branded to me
<Mithrandir> hmm, why does elmo say it's not?
<Kamion> the only mention of Debian I see in choose-mirror is in fuzzy templates
<Kamion> ah, the version in warty had some missing branding
<Kamion> it's fixed in hoary
<Mithrandir> oh, ok
<Mithrandir> care to comment that on the bug?
<Mithrandir> or should I
<Mithrandir> ?
<Kamion> just did
<Kamion> Mithrandir: a generated file had been branded rather than the file from which it was generated
<Mithrandir> heh, ok.
<Mithrandir> but that's fixed now?
<Kamion> yep, I fixed it when doing the merge from Debian to hoary
* Kamion claims first "done" blood on HoaryGoals
<Mithrandir> Kamion: bah, you rock, as usual. :P
<Kamion> don't worry, the rest are a lot harder :)
<doko> mithrandir: did you get a mail about my ia32-libs-openoffice.org upload?
<Kamion> Mithrandir: can you reproduce #2651?
<cenerentola> ciao
<daniels> Kamion: ohnoyoudinnit
<Kamion> ?
<daniels> Kamion: <418A6337.7020401@canonical.com> on Thu, 04 Nov 2004 18:13:27 +0100 says you didn't claim first blood :P
<Kamion> daniels: I see no "done" on HoaryGoals :)
<daniels> Kamion: ber
<Mithrandir> Kamion: I can try tomorrow evening or so.
<Mithrandir> thom: what's the easiest way to redirect people from www.foo.com to www.bar.com; both are on the same site, and I'd like deep links to be redirected properly as well.
* vuntz dteste son ordinateur
<amu> damm, freenode expect now a running ident? 
<ChrisH> It did that always. But you can REJECT that port and still get in.
<amu> looks like the last 30min. I cant join :( 
<carlos> how could I see why aptitude is trying to install gstreamer-editor?
<thom> Mithrandir: same VirtualHost ?
<Mithrandir> thom: preferably, yes.
<Mithrandir> I know I could use mod_rewrite, but it's so totally overkill. :)
<thom> with different vhosts it's trivial - RedirectMatch /(.*) www.bar.com/$1 in the foo.com VirtualHost
<Mithrandir> I could set up different virtualhosts, but it's silly, IMHO.
<thom> otherwise, you're in mod_rewrite territory - you'd need to do a RewriteCond for the host, then RewriteRule similar to the redirect i just gave you
<Mithrandir> that's even more silly.
<thom> agreed (on both counts)
<Mithrandir> it's less work to write another apachemodule.
<Mithrandir> renamevhost or something.
<thom> but if both are the same virtual host, why bother?
<Mithrandir> one is going away at some point.
<Mithrandir> so it's a gentle nudge for people to see the new url and update.
<Mithrandir> (raw.no -> err.no)
<thom> urgh, it never works
<Mithrandir> of course it doesn't work, but it doesn't hurt either.
<Mithrandir> it doesn't work 100%, it works the first 80% or so.
<Mithrandir> which leaves the second, third and fourth 80%.
<carlos> Mithrandir: the best option IMHO is a Redirect Permanent 
<carlos> with that google like applications will update the links to the new URL
<Mithrandir> carlos: I don't care about google, it'll pick up the new url fast enough.
<Mithrandir> carlos: I care about people remembering URLs.
<carlos> Mithrandir: the redirect permanent is like the RedirectMatch
<carlos> so the people will see alse the new url
<Mithrandir> carlos: yes, but it requires another vhost.
<carlos> but as you already know, you will need two virtualhost entries
<Mithrandir> which is silly.
<Mithrandir> thom: what's a simple, standalone module I could use as a template?
<|trey|> Mplayer in hoary used to provide codecs as part of the package, legal problems with that?
<thom> Mithrandir: mod_example? :-)
<Mithrandir> thom: it should be in its own source pkg.  I'm goddamn lazy. :P
<thom> heh
<|trey|> Without the codecs, might as well not have mplayer around  :(   no w32codecs package makes it useless  :(
<thom> i need to package mod_zeroconf soon, that's pretty trivial. but i'd just grab the apache2 source and look in modules/experimental/
<mdz> |trey|: I do not find that to be accurate
<pitti> |trey|: I wouldn't go that far; for me mplayer works just great without any w32 codecs
<|trey|> pitti, I can't play any movies that I have around now... for me, that makes my players useless  :(
<pitti> |trey|: odd, I can play everything - DivX, DVDs, MPEGs, ...
<pitti> |trey|: which codecs do you use?
<|trey|> before the last upgrade, they all worked, thats why I have them around...
<Mithrandir> thom: already at it
<|trey|> pitti, the old mplayer-* packages used to include those codecs... last upgrade switched to marillats packages... these don't have codecs, and no w32codecs available...
<|trey|> I forget who was maintainer before, but it wasn't Christian...
<pitti> |trey|: ah, this may be a bug; I compiled mplayer myself, with all codecs
<|trey|> pitti, you should upload that package then, far more useful  :)
<pitti> |trey|: I did not package it, I just compiled the upstream sources
<pitti> |trey|: I doubt that many people would like my version :-) No gui at all, just command line :-)
<pitti> |trey|: but it is very fast because of this :-)
<|trey|> pitti, atleast replace -nogui  :) thats what I use anyways  :)
<lifeless> mdz: pingpong
<mdz> lifeless: hi
<sjoerd> pitti: did you have time to look at your arch thingie
<lifeless> so yeah, tla in warty.
<pitti> sjoerd: I tried it myself and got the 404
<|trey|> pitti, would be greatly appreciated... seems silly to not provide the codecs when we provide mp3 etc already in multiverse  :(
<pitti> sjoerd: however, I do not know why; it works fine with a browser
<sjoerd> pitti: ah ok, them i'm not doing something stupid :)
<pitti> sjoerd: I also tried to replace '@' with '%40', but that didn't do it...
<sjoerd> pitti: it tries to access it with webdav stuff
<pitti> sjoerd: I'll ask an arch guru how to confine that to plain http
<sjoerd> ;)
<mdz> lifeless: yeah?
<lifeless> I thought it might be faster to chat here, rather than bug back n forwarding.
<mdz> lifeless: I outlined the options in bugzilla; what makes most sense to you?
<mdz> lifeless: have you talked to asuffield by any chance?
<mdz> that's the best option from where I sit: Debian updates to more recent tla, and we follow Debian
<lifeless> not about this specifically, but I have in the past. When Tom labels a new release as having happened, then asuffield will update his debian package for tla.
<Mithrandir> asuffield is alive in #debian-devel on opn now, fyi
<lifeless> I guess I'm more interested in the policy: I'm rather confused that we are considering updating tla in warty at all.
<lifeless> asuffield does have daily debs of toms current code too.
<mdz> lifeless: we aren't considering updating tla in warty
<mdz> but in Ubuntu (i.e., hoary)
<lifeless> ah, so this is for hoary. Right.
<lifeless> I'd do a ubuntu-versioned package of baz after we release 1.0
<lifeless> and let tla 1.3 come when it comes. 
<mdz> it only needs an ubuntu version if it's a Debian package that's different in Ubuntu
<mdz> 1.0-1 is fine for this
<mdz> ok, sounds good
* Mithrandir gets crushed under mod_example.
<thom> yay, bye bye fam
<pitti> thom: does that mean that gamin is now activated in Hoary?
<thom> seems so, yeah
<opi> Hello
<opi> I've come across funny thing in DI
<opi> having same problem with Ubuntu and Debian Sarge (netinstall)
<pitti> sjoerd: I released pmount 0.3 which fixes all of your issues
<opi> how do you think, where should I put my raport? DI developers, Ubuntu Bugzilla? Both? :)
<pitti> sjoerd: it's now at my hp and I just uploaded the debian package
<pitti> opi: bugzilla is preferred for bugs 
<sjoerd> pitti: cool, nice work ;)
<pitti> opi: if you have general questions or an installation report, then mail might be better
<mdz> opi: search bugzilla _before_ filing a new bug
<opi> mdz: okey
<sjoerd> pitti: only the group thingie is left then ?
<opi> pitti: well, I just try to put new software on old box
<pitti> sjoerd: yes
<pitti> sjoerd: well, and of course the missing uid checking for ext2 and the like
<opi> pitti: first time I've got Installation running without problem, but I've messed up and decited to restart
<opi> pitti: after that (I do not know why) DI didn't go behind module loading stage
<opi> pitti: for both Ubuntu and Debian
<opi> I know it sounds funny
<pitti> opi: did you change any hardware since then?
<opi> nope
<pitti> opi: did you check the CD for faults?
<opi> it was separated by 15 secs of reboot
<opi> pitti: ISO had good MD5 (my other box is installed from it)
<opi> pitti: and CDR looks ok
<pitti> opi: you can boot the CD in expert mode and test the CD in the menu
<opi> pitti: ok, I didn't knew about Test in expert
<opi> pitti: I only did ,,custom'' before ;)
<sjoerd> pitti: what was the behaviour if it can't get the uid again ?
* sjoerd forgot
<pitti> sjoerd: it just allows it
<pitti> sjoerd: it = unmounting
#ubuntu-devel 2004-11-20
<mdz> Kamion: around?
<Kamion> mdz: briefly, but about to go to bed. what's up?
<hazmat> mdz, any thoughts on the jdk stuff?
<jdub> hazmat: it's something that would end up in multiverse, if anywhere
<mdz> Kamion: nothing to wait up for, just wanted to chat about germinate/cd/installer stuff
<mdz> hazmat: I posted to -devel about it
<Kamion> mdz: I'll be around tomorrow evening, if you like
<mdz> Kamion: sounds fine, good night
<mdz> Kamion: feeling better?
<Kamion> mdz: much, yeah, kicked off most of it on Friday and Saturday
<Kamion> mdz: good catch on bugreporter-udeb, btw, that had been at the back of my mind for ages and managed to fall out
<pitti> night everybody!
<hazmat> mdz, i was referring to the private emails sent re licensing
<hazmat> and distribution
<mdz> hazmat: oh, regarding gentoo?
<hazmat> yeah
<mdz> I don't think it gives us any direct course of action
<mdz> we could certainly ask for different licensing terms
<hazmat> i'm not sure how it fits into the licensing policy on the ubuntu site.. but it does appear that it would be possible to make an agreement by talking with folks at ibm.
<Kamion> the question would be what it means for Ubuntu derivatives
<mdz> how it fits into the licensing policy is that since no source code is available, it won't go in main, and thus won't go on the CD
<mdz> and thus won't be installed by default
<hazmat> ok
<mdz> but if we can redistribute it, it can go in the package repository so that users can easily install it if they want it
<hazmat> i'd just like to see some option for package based installation of java apps/systems
<hazmat> cool
<mdz> to be honest, I think that the free java situation is better than most people think
<Kamion> if it's under restrictive terms (either to us or to derivatives of Ubuntu), it should go in restricted or multiverse so that we aren't pretending to people that it's free
<mdz> and that if someone invested serious effort in looking at the free java implementations, finding the most appropriate one, and integrating it well with the system, it could turn out quite nicely
<Kamion> a large part of the licensing policy is about not lying to people
<mdz> Kamion: right, it would only be eligible for multiverse
<hazmat> mdz, gcj is useable for certain classes of apps. but for alot of things from azurerus (bt client) to tomcat, its just not going to work.
<mdz> I got tomcat to start up with gij a couple of years ago
<mdz> it didn't serve requests, of course :-)
<mdz> but that was quite some time ago now
<mdz> my understanding is that kaffe and sablevm are more complete than gij
<Kamion> night folks
<hazmat>  interesting.. i'll take a look, thats cool re tomcat
<hazmat> mdz, but it would require also packaging up those apps differently i assume then a jre based package install?
<hazmat> for gcj that is
<mdz> hazmat: gij is a bytecode interpreter
* hazmat is learning more by the second ;-)
<hazmat> cool, i'll take a look, thanks
* lamont_r goes to spend the evening with his sister et al.
<Matt|> ummm... after the hoary updates this afternoon, gnome takes much longer to load. Any ideas why this might be? is it because of the removal of the fam package?
<mdz> Matt|: I wouldn't expect so
<Matt|> hi mdz 
<Matt|> sorry if this is the wrong chan for that question
<Matt|> i haven't changed anything else except for updating hoary
<Matt|> mdz, any further ideas? you haven't seen this problem?
<mdz> no, I haven't
<Matt|> :(
<Matt|> you think i should leave it?
<Matt|> mdz?
<mdz> I'm sorry, but I'm quite busy and can't help you with this just now
<Matt|> ok np
<mdz> maybe someone on #ubuntu can
<Matt|> sorry for pestering
<tuo2> mmm..
<tuo2> netspilty goodness.
<jdub> mdz: are we fundamentally set on 'no cd re-releases'?
<jdub> mdz: "The Ubuntu installation took four more hours because of all the updates it had to drag down over my crappy 128kb/s line, but it was worth it. I particularly like the chocolate colour they use for the background. Mmm, chocolate."
<mdz> jdub: I don't think I buy that figure, even at 128kbps
<jdub> where are we at in MB?
<mdz> I'd estimate ~20
<mdz> which at 128kbps is ~20 minutes
<mdz> and we deliberately made it optional to download updates from the network for exactly this reason
<mdz> a single xfree86 update could be more than all of the existing updates combined
<mdz> and they will happen, especially the day after a point release
<jdub> yeah
<jdub> by the six or twelve month point, it might be significantly larger
<mdz> Mark and I discussed the idea of security update CDs, which I think solves the problem in a nicer way than point releases
<mdz> release a CD with _only_ the security updates, which automagically installs them when you insert it
<mdz> then warty stays warty forever
<mdz> no confusion over which version of the install CD you downloaded
<jdub> oh right
<jdub> would version-confusion really be a problem?
<mdz> it already was for us during the pre-warty period
<jdub> that makes sense though
<jdub> because that's pre-final
<jdub> the version actually matters
<jdub> the installer's changing, etc.
<mdz> point releases also require install regression testing
<mdz> while security update CDs don't
<jdub> mmm, there's currently no way to use those directly from the installer though
<jdub> (minor)
<mdz> it wouuld be so trivial if we hadn't disabled autorun :-/
<mdz> (assuming it works in warty if enabled)
<lupus_> is it normal if you make a link with nautilius and then move the link to another dir
<lupus_> it can not find the app it was pointing to anymore?
<lupus_> nm 
<lupus_> I see the problem
<fabbione> morning guys
<mdz> morning
<fabbione> mdz: you are supposed to be in holidays.. no?
<fabbione> ;)
<fabbione> hey doko
<fabbione> doko: gcc-3.3.4 was giving tons of FAIL
<fabbione> i am trying to build 3.3.5 now
<fabbione> i saw in the changelog something about sparc
<fabbione> perhaps the 2 are related
<doko> moin fabbione
<doko> with x.org?
<fabbione> no no.. i am talking about the sparc port
<fabbione> gcc was failing all the test suite
<fabbione> i am not building x.org yet on sparc
<fabbione> phase1 of main yet :-)
<doko> ugh, could you have a look at build/gcc/testsuite/*.log to see if the failures do have the same cause? if you want to speed up the build, maybe set WITHOUT_LANGUAGES=ada,java,objc,f77,treelang
<fabbione> i guess the next 3 packages will take ages
<fabbione> doko: sorry.. i already killed the chroot
<fabbione> i am going to check 3.3.5
<fabbione> the other one was 3.3.4-9ubuntuX
<fabbione> but if it will fail i will grab logs for you
<fabbione> take into account this is a sid chroot building ubuntu packages for the first time
<fabbione> --take(hoary): gcc-3.3_1:3.3.5-2 changed from Needs-Build to Building by sparcbuildd as sparcbuildd
<fabbione> --take(hoary): gcc-3.4_3.4.3-0ubuntu0 changed from Needs-Build to Building by sparcbuildd as sparcbuildd
<fabbione> --take(hoary): perl_5.8.4-4 changed from Needs-Build to Building by sparcbuildd as sparcbuildd
<fabbione> this means at least 4 days of work
<doko> wondering what is different from unstable...
<fabbione> doko: in theory nothing
<fabbione> since it's a sid chroot
<fabbione> well we will see
<fabbione> in the worst case i will figure a way to give you access and poke around :-)
<fabbione> hmmm
<fabbione> this is sparc64...
<fabbione> i wonder if it is using automatically the call to sparc32 before building
<fabbione> well i will take a look and see
<fabbione> it's nothing urgent atm
<doko> it fails in stage1?
<doko> the call to sparc32 isn't done automagically, IIRC I explicitely call 'sparc32 dpkg-buildpackage ...'
<fabbione> doko: that's what i am afraid of in buildd/sbuild setup
<fabbione> i will see when it goes to the testsuite again
<fabbione> but other packages buildded fine
<Mithrandir> fabbione: that mail to -devel will just cause everybody to try to install hoary. :)
<fabbione> good
<fabbione> so they will probably learn that playing with unstable is not a good idea
<bob2> then they will whinge
<bob2> and say "ubuntu is unstable, LOLZ!!!1 Im r going back 2 gentoo."
<doko> fabbione: touching /etc/disable_64_gcc will ensure, that -m32 is append to the arguments, iff you call 'gcc'.
<fabbione> doko: interesting..
<fabbione> i will try that switch if it will still fails
<Mithrandir> thom: moo?
<jdub> bob2: "u may have x.org, but warez my window shadowz? HA HA! rofl"
<bob2> jdub: and then when composite is enabled, "omg ubuntu is teh slowz0r"
<fabbione> and teh unst4bl3
<Mithrandir> heh
<fabbione> given that daniels is alive and awake
* Mithrandir notes the video capture on the p150 is surprisingly good.
<fabbione> jeppa.. new compiler!
<fabbione> bye bye ccache :-)
<fabbione> ah crap 
<fabbione> i need to hack the hp441
<fabbione> none of the obviuos passwords work
<Mithrandir> tried 31337?
<Mithrandir> :P
<fabbione> ehehe
<fabbione> user1 user2 user3 user4 no passwd :-)
<fabbione> root passwd is now owned :-)
<fabbione> warty live is pretty useful
<bob2> heh, what were they preinstalled with?
<fabbione> mandrake
<bob2> ew
<fabbione> the boot sequence is nice..
<fabbione> i took some pics..
<fabbione> the X config is easy
<fabbione> now the real issue is to understand how much they did patch to make everything working
<fabbione> kernel is custom
<fabbione> i know that X wants a patch to work in that environment
<fabbione> and i can't check all the audio devices (yet)
<fabbione> MY EYES
<fabbione> there is KDE3.1
<mvo_> good morning!
<fabbione> hey mvo_ 
<fabbione> http://www.fabbione.net/hp441/IMG_0358.JPG
<fabbione> doesn't it look cute?
<doko> fabbione: you need flat screens.
<bob2> you have entirely too much hardware, fabbione 
<fabbione> doko: ehehe
<fabbione> bob2: it's never enough when you maintain X
<bob2> fabbione: hah
<pitti> mvo_: Hello Mr. Dipl.-Inf! Congratulations for finishing your Diploma and university!
<mvo_> hey pitti 
<mvo_> thanks a lot!
<bob2> oh, congrats, mvo
<bob2> do we get you fulltime now?
<mvo_> bob2: yes :)
<Mithrandir> mvo_: you're done?  Congrats! :)
<mvo_> Mithrandir: yeah! thanks. yesterday was my research presentation, now it's done
<Mithrandir> I envy you.. I'm doing a project now, then diploma thesis in spring.
<mvo_> it feels good when it's over, diploma thesis was a lot of work
* amu sings the happy birthday song for justdave 
<justdave> :)
* mvo_ joins amu in singing the birthday song for justdave
* doko joins without a microphone, maybe better so ...
<pitti> Happy birthday, justdave!
<daniels> justdave: happy birthday :)
<mvo_> hi rabidbt 
<mvo_> hi rburton :)
<rburton> haha
<rburton> hi nci)
* mvo_ grummbles about the tab-completion of xchat
<Mithrandir> justdave: congrats :)
<ChrisH> Hmm. Has anyone else seen conflicts between libxklavier8 and libxklavier9 when dist-upgrade'ing to hoary?
<bob2> yes
<bob2> something.xml?
<ChrisH> Yep.
<ChrisH> Purging ...8 isn't wise either since it wants to remove some hardly used things like "nautilus". ;)
<ChrisH> Perhaps I should file a bug report.
<seb128> libxklavier9 Replaces libxklavier8
<bob2> I got it a couple of days ago, it might be fixed now
<seb128> no, it's not
<seb128> nobody reported anything, I've not changed anything so ...
* ChrisH reports
<ChrisH> seb128: like a bugzilla entry?
<seb128> yes
<bob2> I figured it was a x.org thing
<seb128> but you could start by giving the error/pb here :)
<seb128> perhaps, I've not idea of what your are talking about, out of the fact that's a libxklavier problem
<bob2> sure, getting ahead of myself, sorry :)
<ChrisH> seb128: Ok. :) Just upgraded from warty to hoary. Everything went well unless that upgrading libxklavier8 failed because of conflicts in an XML file (need to scroll back to see what it was).
<ChrisH> seb128: Currently libxclavier8 and libxclavier9 are both installed so the "Replaces" or "Conflits" didn't seem to work.
<seb128> ChrisH: the weird thing is that libxklavier9 has a "Replaces"
<ChrisH> seb128: If I want to remove libxclavier8 now I wants to remove many base packages.
<seb128> I've not set a Conflicts
<ChrisH> seb128: "Replaces" should be sufficient.
<seb128> that's why I've not set the conflict for the moment :p
<seb128> $ apt-cache show libxklavier9 | grep Replace
<seb128> Replaces: libxklavier7, libxklavier8
<ChrisH> seb128: I can even reinstall libxklavier9 and it does not start to remove anything else.
<seb128> it's not supposed to remove something
<seb128> do you still have the exact error message ?
<ChrisH> seb128: I try.
<daniels> seb128: um, you need Conflicts as well
<bob2> they can't conflict
<fabbione> or otherwise remove that xfree86.xml
<bob2> tons of stuff is built against 8 still
<daniels> Conflicts: otherpackage (<< versionwhereyoumovedthefileover)
<fabbione> and use /etc/X11/xkb/rules/xfree86.xml
<daniels> if they both provide the same file at the same time, the only solution is alternatives
<bob2> ah
<fabbione> all of this because libxklavier upstream is a sadist developer that loves to duplicate mess around
<fabbione> like if one xfree86.xml isn't enough source of problems
<ChrisH> seb128: Can't get it to spit out the error message again. Scrolled out of my terminal buffer.
<seb128> ChrisH: ok ...
<fabbione> seb128: 9 tries to overwrite /usr/share/something/xfree86.xml
<seb128> it has a Replaces
<fabbione> it's the same error i told you about yesterday
<seb128> that should not be a problem
<fabbione> it is not enough
<seb128> why ?
<fabbione> you need to conflicts
<fabbione> see what daniels wrote above
<seb128> I know but if I don't that I totally fuck GNOME time to rebuild all the packages
<seb128> s/don't/do/
<seb128> so I'll add the conflict later
<fabbione> seb128: sane thing to do: kill xfree86.xml from /usr/share
<seb128> but it's probably needed 
<fabbione> that's the only thing you really need to do
<daniels> huh? why is libxklavier providing its own xfree86.xml anyway?
<fabbione> seb128: use /etc/X11/xkb/rules/xfree86.xml please
<seb128> ok
<seb128> I'll try this
<fabbione> daniels: it uses it as test suite (build time)
<daniels> blargh
<fabbione> and even tho.. that's stupid
<daniels> just build-dep on xlibs, or xlibs-data
<fabbione> it should use the X provided one
<thom> Mithrandir: oink?
<Mithrandir> oink
<thom> Mithrandir: that was in response to your moo of earlier
<Mitario> lo everyone
<Mithrandir> thom: oh, do you think you could test a libc package for me?
<Mithrandir> before I upload it?
<Mithrandir> thom: ravel:~tfheen/hoary/libc6_*.deb
<thom> sure
<cenerentola> ciao
<Mithrandir> thom: they work on ravel, if they don't blow up on your system, I think they're fine.
* thom hops in the shower while that downloads
<Mithrandir> thom: also please see if it fixes the fakeroot issue
<thom> was gonna, yeah
<thom> do they for you?
<Mithrandir> yup
<thom> rock, what did you change?
* tuo2 laughs.
<Mithrandir> thom: removed GLIBC_PASSES += nptl
<Mithrandir> since we use nptl anyway and TLS.
<thom> ah
<thom> yeah, they solve the fakeroot issue for me
<Mithrandir> yay.
<thom> and nothing else has broken :-)
<Mithrandir> that's neat.
<Mithrandir> I guess I can upload, then. :)
<thom> please do
<madduck> lamont: ping?
<robtaylor> who'se working on laptop support?
<bob2> mjg59 is Mr Mad Phat Laptop Support
<Mithrandir> at least mr mad. :)
<robtaylor> heh.. *at least* ;)
<Mithrandir> he's crazy.  A really good guy.
<robtaylor> mjg59: shampoo rock. thats all i have to say.. are you around? 
<robtaylor> Mithrandir: mjg59 and tbm were at my housewarming on saturday - a good time was had by all :)
<ddaa> bob2: mjg59 _almost_ got my t42p fully functional on sunday, but then he gave up. For some unknown reason, hotplug was breaking acpi and prevented wakeup...
<bob2> hah
<bob2> close tho
<robtaylor> ddaa: t42p?
<robtaylor> ibm?
<ddaa> robtaylor: yeah
* robtaylor tries to think how hotplug could break acpi :/
<robtaylor> v. odd
<ddaa> yeah
<ddaa> his guess was that hotplug triggered a timing problem
<ddaa> race condition or something like that
<robtaylor> what were the symptoms?
<ddaa> you can check the log for sunday, he gave some data...
* ddaa looks for an url
<ddaa> but then you do not have his source package either
<robtaylor> ah, just interested ;)
<ddaa> http://people.ubuntu.com/~fabbione/irclogs/ubuntu-devel-2004-11-07.html
<ddaa> at the bottom of the page
* daniels sets the amd64 and powerpc buildds off and racing each other.
<robtaylor> ddaa: hmmmmm
<robtaylor> ddaa: sounds like thats gonna need a bit of kernel tracing to figure it out..
<ddaa> *shrugs*
<ddaa> not my dept, really
<robtaylor> heh, indeed
<elmo> Kamion: done - and wvstreams wasn't going in because mdz broke katie, fixed/worked around now
<mjg59> robtaylor: Yo
<Kamion> elmo: heh, ok, thanks. Out of curiosity, what was broken?
<Kamion> elmo: hopefully that should pull libfam out of desktop, btw
<elmo> mythmusic has gotten into some very confused state - the files are in the pool, but not the DB, AFAICT
<Kamion> yuck
<Kamion> oh, bleh, the priorities in our override file are fucked, makes it a pain to use dselect
* Kamion must go through and work out which need to be demoted to < standard
<elmo> yeah
<elmo> I started on that before warty released but never finished - I think I managed to demote anything not in main at least
<fabbione> hey elmo
<daniels> elmo: when do you expect to be around today?
<elmo> hey fabbione
<elmo> daniels: the rest of the day, I guess
<daniels> elmo: cool; hi, btw :)
<fabbione> elmo: testing the last bits for X.org here
<fabbione> we will need your help to get it in the archive
* cenerentola is away: I'm busy
<Kamion> lamont: can we start doing daily d-i builds for Hoary?
<elmo> fabbione: ok
<daniels> elmo: should be two NEW (xorg and xorg-driver-synaptics) for two removed (xfree86 and xfree86-driver-synaptics) for core stuff
<daniels> elmo: plus an xcompmgr package at some stage also
<daniels> elmo: (the new source packages coming with a crapload more binary packages, because we know lamont enjoys pain)
<fabbione> and people will have to complain to jdub for them
<jdub> fabbione: hrm?
<seb128> fabbione: the copy/paste with emacs is supposed to be fixed ?
<elmo> seed syncage ---> baby jesus == :-(((
<fabbione> seb128: no
<seb128> ok
<daniels> elmo: wouldn't that be baby jesus == :'(
<seb128> because it's not :p
<fabbione> jdub: for all the libs you want splitted to look 31337
<fabbione> seb128: the problem is not emacs
<fabbione> i can copy & paste from emacs to xterm for eg.
<fabbione> the problem are gtk1 application as carlos wrote already on the mailing list
<elmo> figlet                                     | figlet                           | apache (Build-Depend)          
<elmo> WTF?
<fabbione> ahahhaah
<daniels> elmo: baby jesus isn't crying, he's just confused
<fabbione> that's something we changed in debian
<jdub> fabbione: why so?
<seb128> fabbione: yeah, I know, I speak about emacs because that's the anoying part for me :p I don't know how the copy/paste internals work ...
<fabbione> jdub: "why so" what?
<daniels> seb128: it's gtk1 crack
<carlos> seb128: use gvim :-P
<seb128> $ apt-cache show emacs21 | grep gtk
<seb128> $
<jdub> fabbione: what do the X libs have to do with me?
<fabbione> jdub: you have been complaining that we are not 31337 if we don't show libxcomposite & CO.
<fabbione> not me
<fabbione> that leads to a 16 libraries split
<fabbione> * 3
<fabbione> lib
<fabbione> lib-dev
<fabbione> lib-dbg
* jdub hasn't been "complaining", i've just pointed out a problem with the current packages
<robtaylor> mjg59: hey :) done any playing about with toshiba tecras?
<fabbione> jdub: you pointed out a non-existing problem :-)
<robtaylor> mjg59: (oh, and did you enjoy the party? :)
<fabbione> anyway
<fabbione> now
<fabbione> there are 48 more packages
<jdub> fabbione: there are no dynamic libs for xcomposite atm - that problem exists...
<fabbione> as soon as we finish to test we will upload
<fabbione> and what is the problem if i ship them static?
<Kamion> we need a Unicode character for "baby jesus" to simplify elmo's equations
<fabbione> Kamion: lol
* Kamion was thinking of the bad-taste version: a crucifix, but with a smaller human figure ...
* Mithrandir looks at elmo staring at the figlet build-deps for apache and snickers.
<elmo> fabbione: dude, figlet's in non-free
<fabbione> elmo: it's still in main
<jdub> fabbione: um, i'm not criticising your work here, dude, i'm just pointing out an issue that will need to be solved at some stage for hoary.
<fabbione> jdub: if you can explain me the issue...
<mjg59> robtaylor: Haven't touched a tecra, so no real idea. And yes, what I remember of it...
<fabbione> jdub: once i provide you the headers and the lib to link with.. what do you miss?
<jdub> fabbione: currently we only have static xcomposite libs. at some stage, we should also have separate dynamic lib packages.
<mjg59> Is the Xcomposite ABI frozen yet?
<daniels> mjg59: yes
<elmo> fabbione: yeah, the maintainer didn't, err, manage to transition it to non-free yet
<fabbione> elmo: ah ok...
<fabbione> elmo: i will fix it for the next upload. don't worry
<daniels> i think fabio's point was that libxcomposite has always worked, it's just been non-dynamic up until now; splitting stuff out into dynamic packages caused a massive split so we've now got ~48 new packages
<Kamion> elmo: hm, #274950 about that is closed?
<fabbione> elmo: but it's too much fun to see a dynamic buildlog changing "size" according to the arch it's building on
<Mithrandir> elmo: so we need to reimplement figlet in a free fashion.
<fabbione> elmo: and according to the buildd maintainer
<Kamion> Mithrandir: track down the original authors, they clearly intended it to be free but just didn't put the right boilerplate on it
<Kamion> well, some of them, anyway
<Mithrandir> Kamion: any idea if they've been talked to yet?
<Kamion> Mithrandir: no clue
<Kamion> elmo: can I have rootskel-bootfloppy too, please?
* Mithrandir waves to berge 
* berge waves to everyone.
<Berge> Greetings.
<Berge> I'm setting up Ubuntu on a laptop here. So far, I'm impressed (-:
<Berge> Though it lacks a decent GUI-way (since this friend of mine (really!) likes GUI) of configuring wireless interfaces.
<Berge> So Mithrandir points me to Network Manager.
<Kamion> yeah, we'll be getting NetworkManager in Hoary
<robtaylor> mjg59: heh. good, good :)
<Mithrandir> doesn't thom have some debs lying about?
<fabbione> libs/db3_3.2.9-20 [required:uncompiled] 
<elmo> Kamion: yeah, the maintainer thought he transitioned it, but he ended up putting the source in main, the binary in non-free and broke - I unbroke it and let him know a couple of weeks ago I think
<Berge> I found those..
<fabbione> does it mean is going to be built?
<Kamion> elmo: d'oh
<Kamion> elmo: should I reopen that bug?
<elmo> kamion: yeah, probably a plan
<elmo> rootskel-bootfloppy done
<Kamion> .changes file looks like it was the source in non-free and the binary in main
<Kamion> elmo: done
<fabbione> elmo: if i flush the binary packages in one archive and i re-run quinn-diff with an update Packages file, will the old packages be rescheduled for build?
* Kamion inches towards being able to build Ubuntu floppies, one "day" at a time. :)
<elmo> fabbione: should be, yes
<Kamion> though what I'll test them on I'm not quite sure; guess I can do an i386 install with floppies on amd64, for true retro value
<fabbione> elmo: so it's normal that wanna-build --list=installed
<fabbione> gives a short list of packages?
* fabbione isn
* fabbione isn't really sure
<elmo> fabbione: 'installed' means "built - nothing needs done", if you flushed the archive, you'd expect most evertything to be in 'needs-build'
<fabbione> elmo: so basically wanna-build is "inconsistent" and i need to kill its db
<elmo> *shrug* it's usually the quickest way to get w-b to behave, yeah 
<fabbione> ok
<fabbione> it's not a problem really
<fabbione> i figured that i was building 64 bit binaries for sparc
<fabbione> and that's why gcc was failing
<fabbione> so i need to rebuild everything anyway
<fabbione> (not that it did build that much)
<cenerentola> sorry does someone know where lulu is?
<fabbione> elmo: danke! it's working now
<lulu> cenerentola: I'm dealing with your request at the moment. I will email you shortly.
<cenerentola> lulu: you're precious
<cenerentola> ahhh...
<cenerentola> who's gonna come with me on saturday night in mataro?
<daniels> god, I love adare almost as much as I adore concordia
<daniels> xorg is looking good thus far on powerpc and amd64; of course, thanks to the fact i386 is crap, it's probably totally broken there :P
<fabbione> except that i386 is the only arch where we can do real testing atm :P
<carlos> Anyone knows why aptitude wants to reinstall any package I remove with synaptic or dpkg ?
<thom> because aptitude sucks monkey nuts, and has a solipsism complex
<daniels> someone should fix that
<Kamion> sigh, 2.6 installer floppies are way oversized
<Kamion> -rw-r--r--   1 root root 1017902 2004-11-08 16:09 vmlinuz
<Kamion> -rw-r--r--   1 root root  689701 2004-11-09 12:49 initrd.gz
<fabbione> uh??
<fabbione> can't we split the initrd on the second floppy?
<Kamion> fabbione: we do
<fabbione> oh
<Kamion> this is just what's needed on the first floppy
<fabbione> "oversized"
<Kamion> I suppose I could strip out USB storage modules, but that's a big functionality kick
<fabbione> hmmm
<fabbione> do you target these floppies to install from non-bootable cdrom?
<ddaa> thom: aptitude rocks. Therefore what you call "solipsism complex" is just the rest of the world not adapting to aptitude :-)
<ddaa> thom: but if you can tell me about something else that handles automatic removal of uneeded packages...
<fabbione> ddaa: debfoster or deborphan
<thom> ddaa: um, you're on even more drugs than usual
<carlos> thom: I thought aptitude was the "recomended" application by Ubuntu team over apt-get ...
<mojo> hi everyone
<fabbione> carlos: that locale error is not an error
<fabbione> carlos: it's a warning
<mjg59> ddaa: Ok, I have what seems to be a sane kernel :)
<thom> carlos: i don't remember anyone saying that :-)
<carlos> fabbione: yes, sorry
<carlos> fabbione: I know, I always confuse it
<seb128> thom: do you know that firefox is ftbfsing on amd64 ?
<carlos> fabbione: I mean, I know it's harmless, but I always talk about it as an error where I should say warning
<thom> seb128: yes
<carlos> thom: I don't remember I saw it O:-)
<carlos> thom: I don't remember where I saw it O:-)
<thom> mithrandir has fixed glbic
<thom> glibc
<mojo> when seb128 upload the new 1.0 Firefox???
<seb128> thom: ok, just wanted to be sure. Some people were complaining yesterday because devhelp is broken (out of sync between the amd64 and all packages) 
<thom> mojo: i'll probably upload it tomorrow morning
<mojo> cool
<thom> seb128: yeah :( nasty fakeroot/NPTL issue
<seb128> ok
<mjg59> ddaa: Uploading it now. It does STR and STD here
<thom> i'll wait till i can check lamont has refreshed the buildds then push a 1.0
<mojo> seb128: I went to the GNOME board, they said they fixed the blur SVG image issue of gnome-games in 2.9.1 but I still find SVG images in Solitaire and some other games are still blur
<ddaa> mjg59: I cannot test it right now (I training my lappy to be a production machine), but I will _surely_ do it.
<mjg59> ddaa: Rock
<seb128> mojo: you filled a bug report ?
<mjg59> robtaylor: Got a kernel here for you to test if you have a chance
<mojo> seb128: not yet, still wondering is it Ubuntu bug or GNOME itself bug
<ddaa> thom: not an drug, i have tried deborphan, and it is not effective.
<mojo> seb128: the Clear Recent Document's Clear Button does not work here, maybe u should have a check on this
<mjg59> It's confusing, though. I seem to be using almost identical ACPI code.
<thom> ddaa: when you say that a well built system should change because one app can't play nice with it, you're on drugs.
<ddaa> actually, aptitude takes the right approach: auto-marking needs to be done in the package manager.
<mjg59> Oh, arse. This won't have the acpi_wakeup_address->physical address thing.
<seb128> mojo: there is a bug report about it, do you have "gamin" installed ?
<ddaa> thom: there was a smilie
<ddaa> I have extensive first hand experience in software with a solipsism complex. And I assure you that at least _some_ people would push that line.
<thom> automarking, sure. but reinstalling something that dpkg has marked as removed? no.
<mojo> seb128: let me check
<Kamion> fabbione: cd_drivers or net_drivers, you choose
<ddaa> thom: sure. It's on crack. But it's the only package manager that does automarking...
<mojo> seb128: yes, I got "gamin" already installed
<Kamion> fabbione: if you use cd_drivers as the driver floppy, it'll retrieve more udebs from CD; if you use net_drivers, it'll retrieve udebs from a networked archive
<seb128> ok
<fabbione> Kamion: kill the net driver if the floppies are done to be able to access the cdrom
<seb128> mojo: in fact I've the problem too, I'll work on this later
<Kamion> fabbione: no.
<Kamion> fabbione: WHY?
<fabbione> hmmm
<Kamion> fabbione: net_drivers is a SEPARATE FLOPPY
<Kamion> as is cd_drivers
<fabbione> Kamion: you said before that you can kill usb keyboard whatever to make 2.6 fitting in one floppy
<fabbione> ahhhh
<fabbione> ok
<Kamion> the boot floppy knows how to load more floppies and a bit of hardware and that's about it
<fabbione> soi tought that perpaps you can kill netdrivers from the floppy and get tehm from cdrom
<Kamion> I didn't say anything about USB keyboards
<Kamion> please look at the package list before continuing :)
<fabbione> Kamion: never mind me.. really.. i just got confused
<mojo> seb128: and Trash can't empty files too!!!!
<seb128> mojo: that's a devel branch, use warty if you want a stable system
<mojo> seb128: ofcourse I know, I'm testing it with u guys now
<seb128> ok, so don't "!!!!!"
<seb128> just report problem, I'm already working on something
<mojo> seb128: sorry, abit sentimental with Ubuntu, (really love Ubuntu )
<Kamion> anyone understand http://people.ubuntulinux.org/~lamont/buildLogs/w/wvstreams/3.75.0-1ubuntu3/wvstreams_3.75.0-1ubuntu3_20041109-1202-i386-failed ?
<daniels> Kamion: sure, jadetex exited with status 1 for some reason
<fabbione> daniels: probably he would like to know the reason :-)
<daniels> jade:E: cannot open "/usr/lib/sgml/stylesheet/dsssl/docbook/nwalsh/print/docbook.dsl" (No such file or directory)
<daniels> jade:E: specification document does not have the DSSSL architecture as a base architecture
<daniels> could well be related
<mojo> seb128: please include d4x in Hoary, I got my friends working hard to create a pure GNOME theme for it + some hack on icon and about menu
<thom> mojo: you need to suggest it on the wiki, then we'll discuss it and the tech board will make a decission on whether it's suitable
<Kamion> hm, there was some alternatives bug I dimly remember ...
<mojo> thom: OK I willm but the thing is I can't maintain nor create the package, I'm new to Deb file, can someone give me a hand??
<Kamion> surely d4x has a Debian maintainer already
<Kamion>        d4x | 2.5.0rel-1 |      unstable | source, i386, powerpc
<Kamion> so I don't see why somebody needs to "create the package"
<mojo> Kamion: I want to make an optimized + hacked menu and theme for Ubuntu
* daniels watches concordia run laps around adare.
<Kamion> daniels: aha, turned out to be that docbook-dsssl recently dropped the /usr/lib/sgml compatibility symlinks
<pitti> ddaa: does this tbp daemon run as root?
<daniels> Kamion: sensational
<daniels> Kamion: who needs 'em? :)
<Kamion> daniels: untested fix uploaded :-)
<daniels> heh
<pitti> ddaa: if so, we could easily fix #3292 without introducing a new group
<Kamion> it's all /usr/share/sgml now
<daniels> aj: oi
<thom> Mithrandir: libc upload? :-)
<daniels> Kamion: oh, you may know
<daniels> Kamion: does britney log stuff anywhere?
<daniels> Kamion: e.g. is there an easy way for me to get a delta of testing from oct 7th->19th
<daniels> Kamion: (hypothetically)
* thom goes to rescue an Alpha
<jvw> daniels: just diff the packages files obtained via snapshot?
<daniels> hm, point
<Kamion> daniels: britney doesn't really log usefully, no
<jvw> daniels: it's how this historical madison thingy works, anyway :)
<jvw> (that aba was referring to)
<daniels> jvw: ah, heh
<jvw> (not exactly, it dumps all packages files in a database, first, but ok...)
<robtaylor> mjg59: for tecra?
<ddaa> pitti: I cannot be positive, but I do not think that running it as root would be possible or a good idea.
<pitti> ddaa: so this is not a daemon?
<mjg59> robtaylor: Generic nice ACPI love
<ddaa> One major feature is the ability to bind shell commands to special keys.
<pitti> ddaa: just an userspace program?
<ddaa> pitti: yup
<pitti> ddaa: argh; I find it totally ugly to give normal users the capability to mess up their BIOS settings
<ddaa> it it does not even double-fork
<pitti> ddaa: this sounds like a suid root problem
<ddaa> ?
<daniels> WHOO WHOO WHOO WHOO!
<daniels> amd64 is *go* for xorg.
<pitti> ddaa: meaning, I think it makes more sense to have tbp suid root and leave the device as root-only accessible
<pitti> daniels: GO, X-MEN, GO!
<daniels> and my god is concordia a beautiful machine
* ddaa tries
<mjg59> pitti: That's require some extra code for tpb
<pitti> ddaa: it might me slightly better to have tbp setgid nvram, and create the group
<pitti> mjg59: ?
<mjg59> pitti: It can be configured to run applications
<ddaa> pitti: it works okay with sudo
<mjg59> So you'd need to drop privileges
<ddaa> except, of course, the custom command for special keys is run as root...
<ddaa> here it is bound to x-terminal-emulator
<pitti> mjg59: it sounds like the tbp design is screwed up from the ground up
<pitti> there should be a daemon which communicates with /dev/nvram and an userspace program that talks to the daemon
<mjg59> pitti: Oh, and it'll read arbitrary configuration files. So that'd have to be disabled, too, otherwise the user can get information about the contents of shadow (for isntance)
<ddaa> so, now, it spawn a root terminal...
<pitti> ddaa: ah, I see the problem
<mjg59> pitti: Yes, in the brave new world of sensible messaging busses, that's be the right way of doing it
<pitti> ddaa: however, I cannot test this program here
<pitti> mjg59: any quickfix idea?
<pitti> mjg59: _apart_ from putting users into nvram?
<mjg59> pitti: No
<ddaa> pitti: I'd happily let you play with it in mataro.
<mjg59> If you're going to make the binary suid or sgid, it needs heavy reworking
<pitti> ddaa: good idea, we can find a solution there
<pitti> mjg59: suid root with sensible privilege dropping shouldn't be so difficult
<pitti> mjg59: that's not the same as using sudo
<mjg59> pitti: At the moment, I think it reads the config file before trying to open /dev/nvram
<mjg59> So you'd need to change that
<pitti> mjg59: the command would still have getuid() == normal user, but can use root privileges for accessing the device
<mjg59> Seriously, it will need chunks rewriting
<pitti> mjg59, ddaa: agree to fix that in Mataro? Then I can "deprivilegize" it and we can test it on ddaa's machine
<pitti> mjg59: sure
<mjg59> It's also never been audited
<mjg59> So it's entirely possible that the user will have access rights to nvram anyway
<pitti> mjg59: well, not by now
<pitti> mjg59: since /dev/nvram is only accessible as root and tbp is  not suid root currently (AFAIUI)
<mjg59> What's the argument against adding the user to nvram?
<pitti> mjg59: access to nvram means access to BIOS settings, right?
<pitti> mjg59: at least that's the documentation
<mjg59> pitti: Uh. But tpb will have access rights to nvram. And we have no confidence that tpb can't be made to run arbitrary code
<mjg59> pitti: Correct
<mjg59> But the default user has physical access to the machine anyway
<pitti> mjg59: and I _don't_ want user viruses to mess up the BIOS
<pitti> mjg59: not necessarily
<mjg59> It's CMOS
<mjg59> It's not the flash
<mjg59> The worst they can do is reset the machine to system defaults
<pitti> mjg59: in our university, the computers are locked, but the CD-ROMs are accessible
<daniels> mjg59: ... which is still not cool ...
<mjg59> They can't rewrite the BIOS itself
<pitti> mjg59: but they can alter the boot sequence, i. e. boot from CD-ROM
<mjg59> pitti: They could open the machines in any case
<pitti> mjg59: I could break our university's computers with this
<lupus_> does the new pmount also support non removable devices?
<lupus_> in the new version
<pitti> mjg59: no, as I said, our machines are physically locked
<pitti> lupus_: what do you mean?
<mjg59> pitti: They could use a hacksaw
<pitti> mjg59: people _might_ notice that :-)
<mjg59> pitti: But fundamentally, making user-level programs suid or sgid is insane
<lupus_> pitti pmount will give error if you use it for a partition on the harddrive
<mjg59> The author won't have written it with security in mind. It's going to require a full audit. It'd make more sense to rewrite it from scratch.
<pitti> mjg59: well, sgid nvram is no worse than putting the user into nvram
<pitti> lupus_: right, that's our current policy
<mjg59> pitti: Except that you're giving people a false sense of security
<lupus_> k so policy is still the same in the new version ? :)
<mjg59> Which *is* worse than making it obvious
<mjg59> If you'd prefer it to be done in a client/daemon sort of way, I'll look into writing one
<pitti> mjg59: hmm, I still believe in minimizing privileges, so if only tbp has the privilege rather than all programs, I'd favor that
<pitti> mjg59: in fact client/daemon seems to be the sanest solution
<pitti> mjg59: minimal daemon which runs as root and has a very tight interface
<mjg59> It ought to just be a dbus setup
<ddaa> Apparently, the only thing it needs nvram for is setting the volume...
<pitti> mjg59: basically it just had to verify the input values and pass it to nvram
<mjg59> ddaa: Oh, that's a point. Yeah, read access to nvram would be enough.
<ddaa> I cannot see what else it needs it for.
<mjg59> So, uh, why are we having this discussion again? :)
<pitti> mjg59: ? I thought it also wants to change the volume?
<pitti> mjg59: changing sounds like writing acces
<mjg59> pitti: We can do without that functionality
<mjg59> There's volume buttons on the machine
<pitti> mjg59: so we could leave /dev/nvram to root:group 0640?
<mjg59> Yeah, that'd do 
<pitti> mjg59: and which group?
<ddaa> pitti: ?
<pitti> ddaa: audio?
<mjg59> nvram makes sense
<ddaa> The whole. issue is that write access is neede.
<mjg59> Since that's what it is
<mjg59> ddaa: Write access is needed for a tiny amount of the functionality
<ddaa> mjg59: tiny critical amount of functionality.
<pitti> mjg59: then we must create yet another group
<mjg59> ddaa: Sorry, which functionality?
<ddaa> sound volume control
<mjg59> ddaa: It works fine without being able to write. 
<ddaa> well, that's prolly another bug, but the mixer applet is ineffective.
<mjg59> ddaa: That code is only used if you want it to jump a different number of steps
<mjg59> If you leave it as default, it doesn't do anything to it
<pitti> mjg59: so the sound volume is _not_ set by writing into /dev/nvram?
<mjg59> pitti: There are two mixers on Thinkpads
<mjg59> pitti: There's the one on the sound hardware, and there's a separate hardware one
<ddaa> mjg59: ok, that's essentially a worthless feature.
<mjg59> pitti: When you press the volume keys, it alters the hardware one, not the OSS/Alsa one
<mjg59> pitti: The code is so that you can alter how much the volume buttons change the volume by. It's not a very useful feature.
<pitti> mjg59: I see. The older thinkpads (that I know) still had a physical slider... How nice... :-)
<pitti> mjg59: ah, I see. Sounds as if it can safely be dropped
<azeem> pitti: could you program that slider to behave as a cross-fader? :)
<pitti> mjg59: so #3292 is basically just about fixing the udev entry from root:nvram to root:root?
<pitti> mjg59: btw, since the group does not exist, which group does udev assign to it?
<ddaa> root
<pitti> so this is only a cosmetic issue after all
<mjg59> pitti: If you make the device 644, then the group doesn't matter
<ddaa> pitti: no, that's pbd bug
<ddaa> s/pbd/tpd/
<pitti> mjg59: I have no problem with read access
<ddaa> stupid tlas
<pitti> mjg59: if it helps in any way, that is
<mjg59> pitti: Only issue there is that on some machines the CMOS password will be readable and crackable
<pitti> mjg59: oh, right
<mjg59> Which then puts you back where you started
<pitti> mjg59: so does read access provide any feature that we want to have?
<mjg59> Without read access, tpb doesn't work
<pitti> mjg59: at all?
<mjg59> When you press keys, the BIOS writes new values into nvram so that it can default to them on next boot
<pitti> mjg59: I thought it would need access just for this volume stepping?
<mjg59> tpb watches the changes in these values
<mjg59> It doesn't do anything otherwise
<pitti> hmm, tricky
<pitti> so basically we just need to rewrite this tiny part? Reading out /dev/nvram as root and do all other stuff as user?
<mjg59> Yes
<mjg59> So split it into a dbus daemon and client
<mjg59> That way the client side can eventually be merged with clients for other hotkey devices
<pitti> ugh, isn't dbus a bit heavy for this?
<pitti> but for my sake
<mjg59> pitti: dbus is going to be running anyway
<pitti> mjg59: so, a nice TODO for mataro, I think
<mjg59> Reinventing another message passing interface is just going to hurt
<pitti> mjg59: unless you want to do it earlier :-)
<pitti> agreed
<pitti> mjg59: I'll sum that up in the bug report.
<pitti> mjg59: can I assign the bug to you then?
<mjg59> pitti: Hrm. I'd prefer not to right at the moment
<pitti> okay
<ddaa> yay... just figured out how to rewrite the sender-address with postfix... will make pqm happy!
<daniels> ok, guys, if you are planning on uploading something to the archive -- PLEASE ASK MYSELF AND FABBIONE FIRST
<daniels> (by the way: amd64 builds just fine; i386 builds and works just fine; powerpc is still building because the G5 Xserve is apparently slow)
<Kamion> why the archive lock?
<fabbione> dunno.. ask daniels 
<fabbione> for me it's enough nobody uploads ubuntu-meta
<daniels> Kamion: put it this way -- uploading 0ubuntu2 in a couple of hours would really suck
<fabbione> on the otherside some Build-deps might need updates
<daniels> Kamion: we'd just like to be reeeeeeeeeeeeeeaaally sure nothing breaks :)
<Kamion> daniels: mkay, well, do you mind me fixing this second round of wvstreams build failure?
<fabbione> Kamion: we are only waiting for adare to finish
<fabbione> question of few minutes
<fabbione> and then we upload
<daniels> Kamion: go nuts :)
<daniels> Kamion: (that's not going to impact on xorg ... but if someone went and changed a library we b-d on from under us, f.e.)
<Kamion> elmo: oh, any chance of king's hoary chroot being fixed to have the en_GB locale installed to match its environment, so that build logs are a bit less insanely noisy?
<elmo> Kamion: can I just change's locale to be C?
<Kamion> WFM
<elmo> (and if so, how)
<Kamion> oh, uh, dunno
<Kamion> depends on the process that's chrooting into it I guess
<elmo> hmm, well I could purge locales in base - will that do the trick? :)
<elmo> hmm, someone did - maybe that's the problem
<fabbione> mput ubuntu-meta_0.6* xorg-driver-synaptics_0.13.6* xorg_6.8.1* 
<fabbione> 52064874 bytes transferred                                     
<fabbione> Total 11 files transferred
<fabbione> elmo: now it's up to you and your gf's
<elmo> heh, lamont already tried to fix this, but typoed /etc/environmment (sic)
<elmo> Kamion: should be good now
<fabbione> ubuntu-meta ACCEPTED
<fabbione> xorg_6.8.1-0ubuntu1_source.changes is NEW
<fabbione> xorg-driver-synaptics_0.13.6-0ubuntu1_source.changes
<fabbione> is NEW
<daniels> elmo: thanks
<fabbione> holy fucking shit
<fabbione> xorg_6.8.1-0ubuntu1_source.changes ACCEPTED
<fabbione> UHA UHA UHA
<daniels> WARTHOGS DANCE!
* pitti screams
* fabbione vanishes from planet earth
<pitti> You really unleashed the beast?
<daniels> pitti: yeah, dude
<pitti> fabbione, daniels: congrats!
<fabbione> thanks pitti 
<Kamion> elmo: he's not alone, that was typoed thus in base-config for ages too
<fabbione> pitti: now it's all up to you to do scurity code review
* fabbione grins
<pitti> fabbione: of the complete code? This will take me until tomorrow, then
<Kamion> elmo: maybe he ran base-config new or something
<Kamion> hooray, congratulations X team
<daniels> Kamion: thanks dude :)
<pitti> fabbione, daniels: BTW, will up upload this into experimental?
<daniels> not yet
<daniels> still needs updates for all the other debian architectures
<fabbione> pitti: we also need to sync all debian changes and other stuff first
<fabbione> it's not really a simple step get it into debian
<pitti> fabbione: oh, don't hurry
<pitti> fabbione: you already did a Herkules job with xorg
<pitti> fabbione: I'm just curious :-)
<fabbione> pitti: it will still be me uploading to experimental
<fabbione> but i need to sync scripts and stuff
<pitti> fabbione: did Branden say anything about X.org BTW?
<fabbione> not at all
<fabbione> he prepared a SVN repo for me where to commit
<fabbione> and merge debian changes
<fabbione> we have 2 sand boxes at the moment
<fabbione> one for a monolithic drop
<fabbione> and one for a fakesplit
<fabbione> so what we will do is to import/merge the monolithic
<fabbione> and than keep splitting
<pitti> ah. AFAIK you already came quite far with the split, right?
<pitti> it would be a pity to see this work being lost
<fabbione> no no
<fabbione> there is not too much code that is splitted
<fabbione> manly the autodetection stuff
<daniels> yeah, but I need to do some upstream work on the modular tree before we can start migrating
<fabbione> that we might as well kill with X.org
<daniels> and I want to start remembering what the outside world looks like first ;)
<fabbione> or rework to a minimal stage
<pitti> daniels: btw, are you still in .dk?
<daniels> yeah
<pitti> daniels: Here in .de we had the first snow today. I bet this is something unusual for an .au citizen :-)
<daniels> cool!
<Kamion> elmo: will the build tree from wvstreams_3.75.0-1ubuntu4_20041109-1439-i386-failed still be around?
<pitti> cool is the right word
<daniels> yeah, we only get snow up in the ski fields, way up in the mountains
<azeem> pitti: where in germany are you?
<daniels> melbourne winters are relatively time
<pitti> azeem: Dresden, south-eastern border
<azeem> people from the Ruhrgebiet stared at me over irc when I said it snowed here
<azeem> ah
<azeem> pitti: are you from Dresden, or do you just happen to live there?
<pitti> azeem: I was born in Leipzig, but moved here in 1990.
<elmo> Kamion: yeah
<elmo> Kamion: want it ?
<daniels> elmo: thanks dude, much appreciated
<Kamion> elmo: yes please
<elmo> Kamion: http://people.ubuntu.com/~james/wvstreams-3.75.0.tar.gz
<elmo> daniels: np
<elmo> doh
<Mitario> hey guys
<pitti> sjoerd: Hi!
* Mitario is back
<pitti> sjoerd: BTW, I fixed my archive mirror, http should work now
<Mitario> rburton, here?
<sjoerd> pitti: cool
<rburton> Mitario: i am
<sjoerd> pitti: any changes since 0.3 ?
<Mitario> rburton, have you seen the http://www.ubuntulinux.org/wiki/PackageManagement page?
<pitti> sjoerd: no
<rburton> oh no
<sjoerd> pitti: k, i was just reading that so :)
<Mitario> rburton, hmm, maybe you could add some summary about your pkg management app there? (just a suggestion)
<pitti> sjoerd: no, I recreated the archive with the '-l' switch to generate .listing files; that caused the 404 (or, rather, their lack)
<elmo> AIEE
<elmo>    * Split the following libraries out from xlibs-static-dev/xlibs-static-pic
<elmo>      into their own libfooX/libfooX-dbg/libfoo-dev packages:
<elmo> daniels: why?
<daniels> elmo: some of them weren't meant to be static in the first place (it was just easier that way) e.g. libxfixes/libxdamage/libxcomposite, et al
<daniels> elmo: and some of it was to ease the transition to the modular tree, where everything is modular and built shared
<elmo> ok, as long as they're going to be shared eventually, and/or separate source packages
<daniels> there was just no point having all that stuff static when its API hadn't actually changed in years
<daniels> elmo: um, they *are* shared now
<daniels> elmo: hence libfooX ;)
<daniels> elmo: and they will all eventually be separate source packages, yah
<elmo> oh, ok - that wasn't obvious (to me) from the changelog entry
<daniels> sorry
<elmo> no need to apologise, my assumption
<daniels> i blame fabio, he's sort of radiating itaglish at me ;)
<elmo> anyway, it's building now - I had to force rman through to main first, thanks to Lamont's new enforcement of buildd component-segregation
<mdz> is there no CC meeting today?
<daniels> mdz: good morning.  do you moderate u-announce?
<daniels> elmo: cheers dude
<mdz> daniels: I think jdub does, but I can. why?
<daniels> mdz: xorg announcement in the moderation queue
<mdz> mako: community council meeting in #ubuntu-meeting
<tseng> mmm, xorg
* Mitario waiting for it to arrive in the x86 repo :)
<Kamion> elmo: thanks, turns out current docbook-dsssl cleverly set %html-ext% back to ".htm"
<tseng> i cant wait for dynamicclocks
<tseng> save a little power.
<daniels> tseng: give it a couple of hours
<tseng> daniels: cant wait i say!
* tseng goes back to work
<thom> well, that was the least fun i've had in a long time
<daniels> thom: whahappened?
<thom> carrying an alpha about a quarter k
<thom> in heavy rain
<daniels> good god
<mdz> Keybuk: /join #ubuntu-meeting please, need tech board representation in the CC meeting
<mdz> daniels: does xorg need to go to -announce, rather than -users/-devel?
<fabbione> mdz: yes
<fabbione> we need to reach as many people as possible
<daniels> mdz: i would much much much rather it did
<fabbione> specially regarding the problem section and how to upgrade
<daniels> mdz: especially bearing in mind that, after 'htf do I be root', it's the most frequently asked question, empirically
<mdz> -announce targets many people who don't even use ubuntu yet
<mdz> agreed on the basis of the fact that so many people seem to want it :-)
<mdz> (even though they don't seem to know why)
<mdz> just approved it
<daniels> thanks very much
<fabbione> mdz: i fully agree that they don't know why :-)
<Mitario> to get that cool eye-candy ;)
<fabbione> that is unstable and slow?
<Mitario> people don't seem to mind, as long as it looks good
<sjoerd> Mitario: well, i don't like being thrown out of X when starting an aterm :)
<Mitario> people who only want it to look good don't start aterms :p
<Mitario> aren't expected* ;)
<daniels> an entertaining read: http://diswww.mit.edu/bloom-picayune/crypto/14238
<daniels> From: "Yeomans, Andrew" <Andrew.Yeomans@DRKW.com>                                                                               
<daniels> To: Daniel Stone <daniel.stone@canonical.com>                                                                                   
<daniels> Subject: Out of Office AutoReply: Announcing X.Org packages for Hoary                                                          
<daniels> mdz: please nomail him on the lists
* carlos really hate when people activates the out of office service being subscribed to several mailing lists
<lupus_> is it possible to xorg yet?
<daniels> lupus_: not in the archive yet
<daniels> amd64 is in the archive, but arch:i386 and arch:all packages are missing, so you can't do a full upgrade.  but i386 just recently finished successfully ...
<lupus_> hehe
<lupus_> I'm readdy to test it :p;
<fabbione> http://people.no-name-yet.com/~lamont/buildLogs/x/xorg/6.8.1-0ubuntu1/xorg_6.8.1-0ubuntu1_20041109-1603-i386-successful
<fabbione> uhuhu
<fabbione> missing powerpc
<lupus_> ready
<lupus_> nvidia has upgraded there drivers btw
<lupus_> they now should work with kernel 2.6.9
<daniels> (arch:i386 and arch:all debs are up)
<tseng> gaimin is in also it looks like
<fabbione> lupus_: there is an open bug already
<fabbione> it will be done sometime during next week
<lupus_> whill it have the inotify patch then?
<lupus_> so gamin and beagle can be tested 
<tseng> there is none in the kernel yet, no
<fabbione> lupus_: i am talking about nvidia drivers
<tseng> beagle needs alot more than inotify.. not hoary material i think
<lupus_> it will depend on if you guys include mono or not :)
<daniels> i386, amd64, powerpc, all debs in the archive
<daniels> have at it, guys
<tseng> apt is holding the server back, but i installed it anyway.. worksforme
<daniels> you need to dist-upgrade rather than upgrade
<tseng> i did dist-upgrade
<Kamion> elmo: what's needed to get the "Task: ubuntu-desktop" line off libfam0c102?
<Kamion> elmo: I thought it would disappear automatically once all the dependencies on it went away
<tseng> xbase-clients is waiting on libxkb
<tseng> i dont see what was wrong with -server
<pitti> sjoerd: I just sent the plugdev mail to d-devel. Finally...
<Mitario> hmm, ok running xorg on x86 here :)
<elmo> Kamion: cron.sync, which is what runs germinate, only runs daily 
<Kamion> ah
<elmo> I'll force it through now
<Kamion> can I bribe you to run that manually? this should be the last piece for working CDs
<Kamion> aha, thanks
<daniels> mdz: thinko in the announce, the recipe for enabling Composite is one letter off.  worth sending a follow-up, or nay?
<sjoerd> pitti: woohoo
<elmo> daniels/fabbione: do any of the NEW packages in xorg need to stay in main?
<pitti> sjoerd: it got a bit lengthy, but I wanted to explain it properly
<mdz> daniels: to -users or -devel if you think it's appropriate, not to -announce
<mdz> -announce needs to stay as low-noise as possible
<mdz> next time around, maybe include a URL to a wiki page, rather than inlining instructions
<daniels> mdz: yesh, sure
<daniels> elmo: hm?
<daniels> mdz: ok, sorry
<elmo> daniels: my archive vs. seed sync script wants to demote most/all of them to universe
<mdz> elmo: how many?  can you paste a list?
<daniels> elmo: bah, cracktastic.  demote libFS to universe but the rest should stay in main pls.
<daniels> elmo: (recompiles will pick up dependencies on all of them except libfs6, really; libxau6 is depended on by some package called libx11-6 and xserver-xorg, f.e.)
<daniels> elmo: actually, just wait
<daniels> elmo: apparently libfs is used by other stuff
<fabbione> elmo: please keep all in main
<elmo> libdmx1-dbg, libfs-dev, libfs6-dbg, libxau-dev, libxau6-dbg, libxaw8-dbg, libxaw8-dev, libxcomposite-dev, libxcomposite1, libxcomposite1-dbg, libxdamage-dev, libxdamage1, libxdamage1-dbg, libxdmcp-dev, libxdmcp6-dbg, libxevie-dev, libxevie1, libxevie1-dbg, libxfixes-dev, libxfixes3, libxfixes3-dbg, libxinerama-dev, libxinerama1-dbg, libxkbfile-dev, libxkbfile1-dbg, libxkbui-dev, libxkbui1-dbg, libxres-dev, libxres1, libxres1-dbg, libxss-dev, libxss1-dbg
<elmo> , libxvmc-dev, libxvmc1, libxvmc1-dbg, libxxf86dga-dev, libxxf86dga1-dbg, libxxf86misc-dev, libxxf86misc1-dbg, libxxf86rush-dev, libxxf86rush1, libxxf86rush1-dbg, libxxf86vm-dev, libxxf86vm1-dbg, xdmx, xfree86-common, xserver-xfree86, xserver-xorg-dbg 
<daniels> elmo: but since they were static, this sort of crap won't start showing up until we see things start recompiling against the dynamic versions
<elmo> mdz: ^--
<fabbione> we will dig into what is really needed tomorrow
<fabbione> ok?
<daniels> mdz: (there are some new libraries but almost all of them were originally static-only, and now have dynamic libraries also -- 1989 was summoning xlibs-static-dev)
<mdz> the -dev and -dbg stuff should get added to the supoprted seed
<daniels> yes
<sjoerd> pitti: guess that explains it nicely, let the flames begin :)
* pitti already fears the usual Debian flamefest
<pitti> sjoerd: I hope that Marco d'Itri supports it; we need udev support to do it properly
<sjoerd> pitti: is it a big problem tha he doesn't ?
<sjoerd> pitti: the only difference is that programs running in the plugdev group can't access drives directly right ?
<pitti> sjoerd: well, not quite
<pitti> sjoerd: hal would not be able to detect anything on the drives, too
<pitti> sjoerd: I think it is required for media checking
<pitti> sjoerd: e. g. for card readers
<sjoerd> oh, right
<sjoerd> still not sure about giving normal users direct access too, but let's see what others think
<sjoerd> hal could use a major overhaul anyway, splitting the parts that touch the disk out would be nice for one thing
<seb128> thom: are you working on the oo.o 1.1.3 merge ?
<elmo> mdz: qt b-d's firebird - bug?
<elmo> (err, over-abbreviated that.. as in, should I file one...)
<mdz> elmo: ugh, yes
<sjoerd> pitti: btw the pmount code looks nice, i can only nitpick :)
<pitti> sjoerd: nitpicking appreciated :-)
<sjoerd> pitti: in a few days, when i'm finished reading it :)
<pitti> sjoerd: I'm looking forward to any improvements :-)
<pitti> sjoerd: I tried my best to write safe and robust code; it got a bit lengthy, but that's the price if you want to program safely in insane^WC
<thom> seb128: i'm on holiday dude, i might look if i have time tomorrow
<daniels> thom: ps: firefox 1.0 is out!!
<thom> daniels: ... thanks
<thom> when Mithrandir uploads libc6 i'll do an upload
<seb128> thom: oh, don't worry. I just have a bug about the gnomevfs support which is fixed in 1.1.3, and I was wondering if you are the right guy to reassign i
<seb128> s/i/it/
<sjoerd> pitti: oh, if you could try not to mix up spaces and tabs, then it would be nice for me to read.. but you may just as well ignore this comment :)
<daniels> thom: no worries
<daniels> thom: oh wow, nice work
<daniels> thom: I was just aimlessly trolling as a form of gloating over xorg ;)
<thom> seb128: yeah, i habve the merge bug, so you might as well :-)
<thom> seb128: actually, since xorg is dne, assign it to daniel :P
<seb128> thom: I'm not asking for any work during your holidays :)
<pitti> sjoerd: hmm, actually I really like tabs, but I can change vim to use spaces instead
<lupus_> now xorg is there shouldn't metacity be recompiled?
<daniels> thom: oi! watch yerself
<sjoerd> pitti: try to set your tabstop to 2 or 4 and you'll see what i mean :)
<pitti> sjoerd: well, a tab is 8 spaces, and has ever been...
<sjoerd> pitti: that's a valid opinion, but there are others 
<lupus_> daniels, will the xorg uses the old keyboard driver?
<pitti> sjoerd: what's the quickest way to convert tabs to spaces?
<lupus_> xorg.conf that is
<sjoerd> pitti: sed ?
<pitti> sjoerd: I'd use a for loop with sed -i s/\t/        / or so
<sjoerd> ;)
<pitti> sjoerd: I did that
<pitti> sjoerd: wow, the diff looks funny
<lupus_> daniels, can't you replace  Driver          "keyboard" to Driver "kbd"
<pitti> sjoerd: IIRC vim has something that emulates tab, but does not use them. softtabstop?
<sjoerd> i guess
<lupus_> on upgrade
<sjoerd> pitti: i use set sta                 " <tab> in indent inserts sw spaces!!
<sjoerd> ok that was a fscked paste
<pitti> sjoerd: do you also have a correct one?
<pitti> Hi lulu
<daniels> Keybuk: heh, picking on thom -- you're a bastard :)
<sjoerd> pitti: use -> set sta
<daniels> lupus_: i don't think it will be a problem but if it is, we can replace it
<lupus_> Keyboard is the old driver
<daniels> yeah, but iirc there hasn't been any functionality change
<lupus_> obsolete :)
<daniels> has there?
<daniels> obsolete != not working :P
<pitti> sjoerd: committed and pushed to the mirror. Can you please verify that the mirror works? And that it looks okay now?
<lupus_> true
<lupus_> but if you get bugreports :)
<sjoerd> pitti: seems to work fine
<daniels> lupus_: yeah, we'll do a migration if strictly necessary; we already migrate xfree86 xkb -> xorg, etc
<Keybuk> daniels: *giggle*
<sjoerd> pitti: you're too good :) (and i want nitpick that it doesn't fit in 80 chars ;)
<sjoerd> s/want/won't/
<pitti> sjoerd: well, there are lines that don't fit
<pitti> sjoerd: I don't like to break strings
<vuntz> jdub: ping ?
<pitti> sjoerd: hmm, smarttab does not quite do the right thing. I think, it's rather expandtab
<sjoerd> pitti: oh hmm
<sjoerd> pitti: judging from the comments in my config file it's probably a combination
<sjoerd> et is when your doing it manually, sta is when vim indents for you
<pitti> sjoerd: I now use shiftwidth=4, softtabstop=4, expandtab
<pitti> sjoerd: hmm, why do people insist to redefine the tab width? Tab is unusable if that is done
<sjoerd> pitti: i do it because i dont like 8 space indents
<pitti> sjoerd: me neither
<pitti> sjoerd: but this does not have much to do with each other
<lupus_> is the xcomp* package already available?
<daniels> no
<daniels> won't be until later tonight
<daniels> because i'm leaving right now for a couple of hours, been at the computer for pretty much 13h straight
<m_tthew> daniels: thanks for the work, my upgrade went smoothly.
<lupus_> k daniels :)
<Keybuk> how curious
<Keybuk> we managed to base our ghfaxviewer package on a version not on snapshot.dn
<lupus_> there is a problem with gaim when you get an email
<lupus_> and click ok
<lupus_> gedit is openend
<lupus_> instead of a browser
<lupus_> it does not know that .html should be openend with firefox
<lamont_r> moo
<Keybuk> seb128_: heh, uh ... yeah
<Keybuk> it's probably better it you resolve those kinds of bugs the other way :p
<Keybuk> (ie. mark the old one a duplicate of the new)
<Keybuk> otherwise you'll just get another bug filed when Debian upload a new version
<seb128_> hey Keybuk 
<seb128_> why ?
<seb128_> oh ok
<Keybuk> merge-o-matic uses the alias of the bug to avoid repeat filings
<Keybuk> only the new bugs have those
<Keybuk> (you could also just set the alias of the old bug to merge-gdm :p)
* thom slaps keybuk
<thom> i was reading the titles of my emails going "what the fuck is that crackwhore on about, acpi-support isn't *in* debian"
<seb128_> Keybuk: ok, thanks for the explanation :)
<Keybuk> thom: heh, I needed to test it did a real-component/UNKNOWN flip ok
<seb128_> Keybuk: apparently it gets the alias from the dup
<seb128_> oups, nevermind
<seb128_> I was mis-interpreting the "Bug 3444 has already taken the alias merge-gdm. Please choose another one."
<Keybuk> ah, d'oh
<mdz> Keybuk: so currently-open merge-o-matic bugs are real and valid and should be paid attention to?
<Keybuk> hmmm....
<Keybuk> mdz: yes.
<seb128_> Keybuk: not sure about this message ... 2 bugs can't have the same alias ?
<Keybuk> apparently not, hmm
<elmo> does 'Save as' work for anyone in firefox?
<Keybuk> mdz: any that get opened or commented on now are real bugs
<elmo> I'm getting "The link could not be saved.  The web page might have been removed or had it's name changed" or something
<thom> elo
<thom> elmo: works for me
<mdz> Keybuk: so there are non-real ones which are already open?
<Keybuk> mdz: no, there were just one or two non-real ones which I closed as NOTABUG
<Keybuk> so any opened now, being opened now, or being commented on now are real
<thom> jdub: new firefox industrial theme fixes the whack search box
<Keybuk> >>> print bz.bug_id_from_alias("Ubuntu", "test-scott")
<Keybuk> None
<Keybuk> >>> print bz.bug_id_from_alias("Ubuntu", "test-scott", all=True)
<Keybuk> 3412
<Keybuk> >>> bz.clear_alias(3412)
<Keybuk> \o/
<Keybuk> right ... fixed that potential bug :p
<Keybuk> if anyone has queries on the bugs, just comment on them, the reporter is set to me so I can look what it's done
* Keybuk goes for food
<fabbione> lamont_r: ping
<lamont_r> yo
<Kamion> xlibs-dev is currently installable, isn't it?
<Kamion> I'm hoping that the britney output is just temporary
<fabbione> lamont_r: what is keeping xorg 1ubuntu1 from being built?
* lamont_r decides taht that he'll upgrade to hoary when he gets home, rather than risking the laptop while out of town.
<lamont_r> fabbione: checking
<fabbione> Kamion: yes, daniels already uploaded a fixed version
<fabbione> but it's not built yet
<lamont_r> fabbione: package name is xorg?
<fabbione> and that's scary
<fabbione> yes
<fabbione> i am afraid of circular build-deps
<fabbione> lamont_r: if that is the problem we might have to build 1ubuntu1 manually on a chroot that has not been upgraded
<elmo> eh, xorg built for at least i386 and amd64
<Kamion> fabbione: ah, ok
<lamont_r> fabbione: give it a break..
<elmo> I just haven't been forcing it through as fast
<lamont_r> was signed about 15 minutes ago
<fabbione> uh ok
<fabbione> sorry.. the buildd pages weren't updated
* fabbione needs a break
<fabbione> sorry guys
<lamont_r> fabbione: http://people.ubuntulinux.org/~lamont/buildLogs/x/xorg/...
<fabbione> my really really bad
<fabbione> i was looking in the old dir :(
<fabbione> elmo, lamont_r: sorry
<lamont_r> fabbione: and http://people.ubuntulinux.org/~lamont/buildLogs/Lists/hoary.all.i386
<fabbione> Kamion: everything should be alright as soon as powerpc finishes to build
<elmo> fabbione: it's cool dude, chill out :)
<Kamion> ok, I'll roll a CD then if stuff is installable
<fabbione> Kamion: only on i386 and amd64
<fabbione> ppc needs 1ubuntu1 
<fabbione> ok i am off to relax
<fabbione> thanks guys :-)
<mdz> fabbione: thanks and enjoy :-)
<mdz> fabbione: the sharks are feeding
<mdz> soon there will be the sound of thousands of people simultaneously saying "oh" and realizing that they can't tell the difference from outside
<lamont_r> evo and gpg are happily together, yes?
<thom> mdz: heh, yep
<mdz> thom: just wait until the requests for firefox 1.0 start rolling in
<mdz> if they haven't aready; I'm not yet at the bottom of my ubuntu-bugs mailbox
<fabbione> mdz: eheheh
<thom> there's a thread on -users already
<fabbione> i am just a bit overexcited to see 5 weeks of very hard work out
<thom> i've not seen a bug report yet
<fabbione> neither did I 
<fabbione> but it's too early
<thom> fabbione: i mean requesting firefox 1.0
<fabbione> ahhh
<fabbione> sorry
<fabbione> they bitched today on irc :-)
<fabbione> about firefox
<Mitario> hmm, what is the policy to upload something to dist-security?
<Mitario> warty-security or hoary-security thatis
<mdz> Mitario: http://www.ubuntulinux.org/wiki/SecurityUpdateProcedures/view?searchterm=security
<Mitario> ok ty
<Mitario> damn, my procedure won't work then :)
<Mitario> is there a possible way to fetch the 'current stable' of ubuntu somewhere? (release name)
<Mitario> so the current upstream stable, not the version a user has installed locally
<mjg59> daniels: Any idea where int10 e6 comes from?
<mdz> Mitario: not sure what you mean
<cenerentola> ciao a tutti
<Mitario> mdz, well, in the upgrade apps i'm writing with michael, it would be a really cool feature if the app could automatically detect if there is a distribution upgrade available (for example if hoary is released as the new stable), the upgrade app can then show a dialog like 'Would you like me to modify your software sources and upgrade to Hoary?)
<cenerentola> is jdub with us at the moment?
<mdz> Mitario: ok, I see
<mdz> Mitario: seems like we require a meta-meta-index :-)
<Mitario> so I first tought just update the upgrade-app package with a metafile which says hoary is the new upstream dist, but because of the security upload policy that won't be possible
<Mitario> cause the update of the metafile is not really a security 'bug'
<cenerentola> mitario: id like to ask you a question... is warty freezed?
<Mitario> cenerentola, yes it is :) afaik
<Mitario> mdz, or we could have some internet location with a metafile which lists the current distribution where I could have a peek with the app internals :)
<cenerentola> is it bullet proof... or you have just forgot that it exists
<Mitario> i'm pretty sure warty is in freeze :) cause it has been released
<cenerentola> Mitario: why dont you modify apt
<cenerentola> so noone is working on its security issues?
<cenerentola> mitario: i think it will be easier to let apt [a pluggable script]  to do the job or not?
<Mitario> oh, wait, i see what you're talking about now
<Mitario> yes, the upgrade apps work together with apt
<cenerentola> i know that
<cenerentola> well i really seem stupid sometimes.. but im not..
<Mitario> well, elaborate your ideas please :)
<cenerentola> ...:;)
<Kamion> cenerentola: frozen except for security
<cenerentola> kamion: thx...
<Kamion> cenerentola: obviously we couldn't release a distribution and then ignore its security issues
<cenerentola> cause i was thinking of unistalling ubuntu...
<cenerentola> kamion: debian-way... i love it
<cenerentola> mitario: i havent ever seen apt-code..
<cenerentola> but i think that a scripting language will do it nicely... since my idea its not definitive...
<cenerentola> my desk-mate at the uni is mad for plug-ins...
<cenerentola> so why dont extend apt... apt-get with a metafile checker...
<cenerentola> arghhh... found it...
<cenerentola> why not glueing [is it right?]  apt-get with mmm ive used a program that check the best apt sources
<cenerentola> i cant remember its name, but we.. you could merge that code, its already done
<mdz> cenerentola: warty is not only frozen, it's _released_
<mdz> Mitario: there already is a metafile for each release, the Release file
* Kamion looks at http://people.ubuntu.com/~cjwatson/testing/hoary_probs.html with some puzzlement
<mdz> Mitario: but in order to see whether there was a newer release, you'd need a higher-level index (hence meta-meta)
<Mitario> mdz, yes indeed
<mdz> cenerentola: what are you talking about, regarding security issues?
<cenerentola> no... newer releases..
<cenerentola> no.. you could simply add and change a variable... like svn
<cenerentola> and that program, whose name i forgot, did the job...
<mdz> you keep saying 'no' in response to questions which do not have boolean answers
<mdz> Kamion: which bit?
<cenerentola> i mean... other than checking the metafiles, also changing the sources.list
<cenerentola> mdz: are you talking with me?
<mdz> apparently not :-)
<cenerentola> where are you from?
<mdz> <mdz> cenerentola: what are you talking about, regarding security issues?
<cenerentola> ... mmm sorry i misunderstood...
<Kamion> mdz: everything from ubuntu-desktop down really
<cenerentola> mdz: nothing in particular... i was just wondering if warty had been forgotten
<mdz> cenerentola: why would you think that?
<Kamion> cenerentola: please do us the favour of not assuming that we're criminally negligent :-)
<cenerentola> <Mitario> mdz, well, in the upgrade apps i'm writing with michael, it would be a really cool feature if the app could automatically detect if there is a distribution upgrade available (for example if hoary is released as the new stable), the upgrade app can then show a dialog like 'Would you like me to modify your software sources and upgrade to Hoary?)
<cenerentola> kamion: never say no...
<mdz> cenerentola: so because Mitario is writing an application to assist with upgrades, you infer that warty is neglected?
<cenerentola> mdz: sorry i was joking...
<cenerentola> mdz: well im used to the debian-way where you have 3 kind of package..
<mdz> Kamion: puzzling
<cenerentola> mitario was talking about 2 kind...
<mdz> Kamion: does that still happen if you run it on the current archive?
<cenerentola> mitario: what about the apt thing... is it crap?
<Mitario> apt rocks
<Kamion> mdz: can't say easily
<cenerentola> mitario: no what a said, is it crap?
<Mitario> umm, not it isn't
<Mitario> no*
<Kamion> mdz: that's fairly current data though
<cenerentola> mdz: btw, will you host me in your bathroom in mataro? bcause lulu wont...
<mdz> Kamion: it seems very confused
<mdz> Kamion: evolution doesn't even build evolution1.5 anymore
<mdz> cenerentola: I can't fault her for that
<Kamion> mdz: but it's still in the archive
<cenerentola> well can i open this discussion... i think its unfair... mark can afford the presence of the ubuntu's community represantives[1 person per nation] 
<Kamion> mdz: in general the assumption that britney is wrong can be eliminated by Occam's Razor :-)
<mdz> Kamion: is that normal?
<mdz> for a binary to remain in the Packages file after its source disappears from Sources?
<cenerentola> ... because id love to come.. but my family cant afford it
<Kamion> mdz: they're only removed semi-automatically
<Kamion> mdz: i.e. elmo runs rene every so often and does roughly what it tells him to do
<Kamion> at least that's how it works for Debian
<mdz> fascinating
* lamont_r lunches
<cenerentola> so whos gonna host me?
<daniels> mjg59: e6? no, sorry
<mdz> cenerentola: an email will go out soon regarding conference sponsorship, you can watch for it for more information
<cenerentola> im the italian community administrator.. you should consider me as your friend
<daniels> cenerentola: dude, chill
<cenerentola> martini?
<mjg59> daniels: Looking more closely - the routine is called xf86ExtendedInitInt10_E6 but actually calles IntE6
<mjg59> Which seems to somehow result in a load of other interrupts being called
<daniels> mjg59: i profess ignorance by choice
<daniels> mjg59: vbe isn't really my forte; all I know is DDC and a little too much about EDID, sorry
<mjg59> Heh
<mjg59> I'd rather switch this code to be using vm86 for simplicity of testing, but it's not keen on that
<daniels> amd64 has no vm86, though
<daniels> xfree86/xorg uses x86emu for hysterical raisins, but supporting amd64 appears to be a neat side effect ;)
<mjg59> daniels: Yeah, I was going to worry about that later :)
<Mitario> yeah, daniels your work rocks! xcompmgr is damn slow, but it rocks and is really good looking :p
<Mitario> daniels, thank you and your mate for all the hard work you have done :)
<daniels> heh, thanks :) i'm sure fabbione will appreciate the compliment also
<Mitario> fabbione, many thanks!
<Mitario> fabbione, same I said to daniel :)
<cenerentola> good job...
<cenerentola> great job
<Kamion> fabbione,daniels: can one of you update the hoary seeds for xorg, please?
<daniels> Kamion: on the wiki, or in a package somewhere?
<Kamion> xfree86-driver-synaptics is still mentioned in desktop and xserver-xfree86-dbg is in supported
<Kamion> in tla
<cenerentola> is it safe to upgrade ?
<daniels> Kamion: which archive do I need to pull?
<Kamion> tla register-archive sftp://chinstrap/home/warthogs/archives/ubuntu-devel@lists.ubuntu.com
<daniels> cheers
<Kamion> tla get ubuntu-devel@lists.ubuntu.com/seeds--hoary--0
<daniels> s/tla/baz/ ;)
<Kamion> or that :)
<daniels> Kamion: do I need to list stuff that should be there implicitly?
<Kamion> implicitly?
<daniels> e.g. xbase-clients now deps libxkbfile1/libxkbui1, do I need to add both of those, or does that just happen automagically?
<Kamion> oh no, germinate takes care of dependencies
<daniels> ah, phat
<Kamion> all you should need to do is s/xfree86/xorg/g
<mdz> Kamion: can you update SeedManagement with those instructions?
<Kamion> mdz: sure
<mjg59> Ah, I see how this works now
<daniels> Kamion: i suppose I should update supported seed with all the new xorg packages?
<mdz> mjg59: that kind of talk makes me worry
<Kamion> daniels: what sort of thing?
<mdz> Kamion: -dev, -dbg
<Kamion> check with mdz, I guess
<Kamion> ah, that sounds ok
<mdz> -dev and -dbg for anything which is already supported is OK
<mdz> and in fact would be nice to automate someday
<daniels> a lot of stuff in xlibs-static-dev is now built shared also; as well as that, there's new fixes/damage/composite libs, plus xevie (useful with composite) and dmx (distributed multihead x -- VERY VERY cool)
<Mitario> going to bed
<Mitario> nn all
<Kamion> mdz: done
<mdz> Kamion: seedmanagement? thanks
<Kamion> yep
<mdz> for a moment I wondered if you suddenly got the urge to hack on germinate :-)
<Kamion> not today :-)
<Kamion> I should get round to setting up that thing to mail seed changes to hoary-changes
<cenerentola> mdz: we were talking about packages, so if i want to install xorg or new packages, should i change the repository in sources.list to hoary's?
<cenerentola> .
<daniels> Kamion: seeds--hoary--0--patch-7 committed, please let me know if I've tanked anything
<elmo>    o grepmap
<elmo>    o update-manager
<elmo>    o upgrade-notifier
<Kamion> daniels: looks ok to me
<elmo> can the appopriate person add them too , pls?
<elmo> mdz: btw, I assume you still hate wwwconfig-common?
<mdz> elmo: if thom and fabbione hate it, I hate it too
<Kamion> daniels: seems ok
<elmo> WFM, new bug on backuppc coming up
<mdz> elmo: grepmap should get some wider testing before being added to base
<mdz> I think likewise for update-manager and upgrade-notifier wrt desktop
<mdz> I suppose we can add them all to supported for now
<Kamion> daniels: I turned off signature verification on the update cron job, though, 'cos I realised I probably didn't have your key in my keyring there
<Kamion> I guess I'll get bitchmail about that
<daniels> Kamion: 9f9f324a, from subkeys.pgp.net
<Kamion> daniels: oh yeah, I know how to get it, point is the cron job doesn't
<elmo> mdz: that'd be nice - with the new buildd facisim, it's more important I fix seed syncage quickly and having less false positives would help
<mdz> GAH
<elmo> mdz: oh, and while you're there, you could drop 2.4 support :)
<mdz> Kamion: I can't update from the seeds archive anymore?
<mdz> ********************************
<mdz> SIGNATURE DEMANDED FOR ARCHIVE
<mdz>   ubuntu-devel@lists.ubuntu.com
<mdz> BUT NO RULE PROVIDED
<mdz> "DEMANDED"
* mdz pummels tla
<Keybuk> heh
<mdz> elmo: I have changes in my working directory, once someone tells me how to beat tla into submission i can do that too
<daniels> mdz: echo gpg --clearsign > ~/.arch-params/\=signing/ubuntu-devel@lists.ubuntu.com
<Kamion> mdz: it's always been a signed archive
<lupus_> what was wrong with xorg that there are new packages :)
<daniels> lupus_: minor upgrade errors that we haven't caught in our testing
<Kamion> elmo: buildd fascism?
<elmo> Kamion: component segregation - main can now only be built with packages from main etc.
<Kamion> aha
* Kamion is still totally confused by britney's output, and goes to try to reproduce it
<mdz> Keybuk: do you have your tla-to-human phrasebook handy?}
<mdz> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<mdz> that's like "permission denied" or something, right?
<Keybuk> yup, pretty much
<Keybuk> it also could mean you need to do "tla update"
<Kamion> drwxrwsr-x    3 daniels  warthogs     4096 Nov  9 21:25 ++revision-lock-held--patch-7--matt.zimmerman@canonical.com--1a5de7a0671f3
* daniels scratches his head.
<daniels> dpkg-shlibdeps: warning: could not find any packages for /usr/X11R6/lib/libXfixes.so.3 (libXfixes.so.3)
<daniels> dpkg-shlibdeps: warning: unable to find dependency information for shared library libXfixes (soname 3, path /usr/X11R6/lib/libXfixes.so.3, dependency field Depends)
<Kamion> tla lock-revision -b?
<Keybuk> ah, tla lock-rvision -b
<daniels> daniels@catsby:~/canonical/xapps/xcompmgr/xcompmgr-1.1.1+cvs.20041109% cat /var/lib/dpkg/info/libxfixes3.shlibs 
<daniels> libXfixes 3 libxfixes3
<mdz> Keybuk: ah, so it's "you tried to commit, but I blew up and didn't let you, and left a lock behind"?
<Keybuk> pretty much, yeah
<Keybuk> it likes doing that
<mdz> what's the arg to lock-revision that I need?
<Keybuk> -b
<Keybuk> (break)
<daniels> Keybuk: ideas on the shlibs bong?
<mdz> Keybuk: usage: tla lock-revision [options]  revision
<Keybuk> mdz: tla lock-revision -v $(tla tree-version)
<mdz> lock-revision: invalid revision name (ubuntu-devel@lists.ubuntu.com/seeds--hoary--0)
<elmo> damn, tla's so intuitive
<Keybuk> uh, stick a --patch-7 on that :p
<daniels> and you want -b, not -v
<mdz> tried that
<mdz> lock-revision: revision not locked -- ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-7
<mdz> is that tla-speak for "I did what you told me"?
<daniels> no
<Keybuk> then do "-u"
<Keybuk> rather than "-b"
* mdz bangs his head on the desk
<Kamion> we love tla really
<mdz> lock-revision: error unlocking revision ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-7 -- lock not held
<Keybuk> bleh
<Keybuk> try it without either :p
<elmo> the TLA  game - keep banging your head until tla doesn't hurt
<daniels> mdz: so what happens now if you try to commit?
<Kamion> failing that, go into the archive and nuke the lock ...
<mdz> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<mdz> still
<Keybuk> *snicker*
<mdz> Kamion: help? :-)
<Keybuk> mkdir -p patch--7/++revision-lock/+contents
<mdz> Keybuk: you must be shitting me
<Keybuk> rm -rf ++revision-lock-held*
<Kamion> mdz: try now
<Keybuk> mdz: I often get an image of 'tla' as a kind of Nelson figure
<Keybuk> going "ha-hah" at you when you try and do something sensible
<Keybuk> ;-(
<daniels> Keybuk: so, er, dpkg and shlibs
<mdz> what's the difference between ~/.arch-params/signing and .../=signing?
<daniels> Keybuk: *harass* *harass*
<daniels> mdz: whatever tla said is right, and whatever I said is wrong
<daniels> mdz: that aside, not much
<Keybuk> mdz: =signing works, signing doesn't
<Keybuk> "signing" clearly isn't a tla config file, you can type it without performing finger-yoga
* mdz cleans up the lock AGAIN
<Kamion> uh?
<Kamion> I have ~/.arch-params/signing/
<Kamion> and it works
<Keybuk> ugh
<Keybuk> Kamion is right
<Keybuk> it's =ids and =locations, but "signing"
<mdz> ok, I'm still broken
<Keybuk> .arch-params/signing/=default
<mdz> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<mdz>     tree: /home/mdz/data/src/canonical/seeds/hoary
<mdz>     revision: ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-8
<daniels> Keybuk: yay! i was right
<mdz> and no locks in sight
<daniels> mdz: so when you do tla lock-revision -b ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-8, it claims it isn't locked?
<Keybuk> mdz:  do you have permission to write to the lock?
<mdz> daniels: you win the tla russian roulette prize
<daniels> mdz: if I die, #ubuntu will be bitching about xcompmgr packages forever ;)
<Kamion> patch-7/++revision-lock/+contents is missing
<mdz> drwxrwsr-x   10 cjwatson warthogs     4096 Nov  9 21:46 /home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--hoary/seeds--hoary--0
<mdz> mdz@chinstrap:/home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--hoary/seeds--hoary--0 $ groups
<mdz> warthogs cdimage security_team porting_team
<Keybuk> it's not locked
* Kamion mkdirs it
<daniels> mdz: try committing now
<Keybuk> Kamion: beat you!
<daniels> daniels@catsby:~/canonical/xapps/xcompmgr/xcompmgr-1.1.1+cvs.20041109% baz lock-revision -b ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-8
<daniels> lock-revision: unkown lock state for ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-8
<daniels>    (lock was in transition -- consider retrying)
<daniels> daniels@catsby:~/canonical/xapps/xcompmgr/xcompmgr-1.1.1+cvs.20041109% baz lock-revision -b ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-8
<daniels> lock-revision: revision not locked -- ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-8
<mdz> is this bug in bugzilla already?
<mdz> or do I get the pleasure?
<Keybuk> mdz: rant away
<daniels> mdz: 'ui is utter crap'?
<mdz> leaving the lock behind
<daniels> Keybuk: speaking of bugs ... dpkg-shlibdeps!
<mdz> I still can't commit
* daniels smiles sweetly at Keybuk.
<Keybuk> daniels: I'm dealing with X.org xkb bugs right now
<daniels> Keybuk: swap you?
<daniels> mdz: this is when you scream for jblack/lifeless
<mdz> same error
<Kamion> let me try a test commit here
<mdz> lifeless is asleep, trying jblack
<Kamion> well, I *had* the same error, but the mkdir -p fixed it and my commit went through
<Kamion> mdz: can you try your commit normally, no extra funny stuff?
<daniels> shit, getting kicked out of here in 15min
<mdz> ok, I'm updating and retrying
<mdz> seems to be working
<mdz> yep, done
<Kamion> I shouldn't've bothered making this a signed archive
<mdz> filing bug
<Kamion> well, britney on little with a recently-synced archive agrees
<Kamion> now to persuade it to tell me why
<elmo> Kamion: about what?
<Kamion> that gnome-<lots-of-stuff> is uninstallable
<carlos> mdz: did you saw the discussion at debian-desktop about usplash?, should any ubuntu developer participate in the thread?
<mdz> elmo: so grepmap, upgrade-notifier and update-manager are now seeded
<mdz> carlos: I don't think I'm on that list
<Kamion> daniels: libxft1/libxft1-dbg are still built from Source: xfree86
<Kamion> daniels: are they going to disappear?
<elmo> mdz: cheers
<carlos> mdz: they are talking about a splash solution for Debian
<Kamion> daniels: and if so, what'll you do with xlibs-dbg?
<carlos> and I'm sure they will be happy to participate on usplash development
<daniels> Kamion: yes, and violently so
<daniels> Kamion: er, whaddya mean about xlibs-dbg?
<Kamion> still depends on libxft1-dbg
<daniels> oh, right, ISWYM
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | Hoary is here: http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html | Want to help? see https://www.ubuntulinux.org/wiki/HoaryGoals
<daniels> this is the sound of me updating xlibs-dbg's dependencies on hoary
<daniels> s/hoary/xorg/
<mdz> elmo: 2.4 removed now also
<daniels> and with that, I'm getting kicked out of the net cafe.  night all, see you in the morning.
<elmo> heh, #280491
<elmo> night daniels
<mdz> Kamion: how often is your public checkout of the seeds updated?
<mdz> Kamion: I'd like to update ubuntu-meta
<mdz> Kamion: debootstrap needs updating as well; do you have a semi-automatic widget for that?
<amu> nice idea, i should try os.chroot()
<Keybuk> daniels: have it ticking nicely now \o/ ... upgrade threw away my changes to xkb because it turned the file into a symlink
<elmo>    o mozilla-firefox-gnome-support
<elmo>    o xdmx
<elmo> what about those two ?
<Kamion> mdz: you shouldn't get more than 17 minutes lag
<Kamion> mdz: yeah, I have a magic debootstrap updater
<mdz> elmo: mozilla-firefox-gnome-support sounds like something we want in desktop, assuming it works
<mdz> elmo: NFC what xdmx is
<elmo> Description: Distributed Multi-head X server
<elmo>  Xdmx is a proxy X server that uses one or more other X servers as its display
<elmo>  devices.  It provides multi-head X functionality for displays that might be
<Kamion> odd; britney apparently throws out capplets very early, judging from the diagnostics I can get; it doesn't even seem to bother looking at its dependencies
<elmo> Kamion: it'll be libxklavier?
<elmo> The following packages have unmet dependencies:
<elmo>   capplets: Depends: libxklavier8 but it is not installable
<elmo> which got rene-removed recently 'cos it's NBS (supsed by libxklavier9)
<Kamion> how come it installs fine on my box?
<Kamion> oh, blah, right, I haven't removed obsolete packages
<elmo> kamion: doesn't in a clean chroot for me? 
<elmo> mdz: it's one of the new xorg things </redundant>
<Kamion> think seb128'll mind if I just rebuild capplets?
<Kamion> mdz: what base changes should I expect in debootstrap?
<mdz> Kamion: -modutils
<mdz> same as the ubuntu-meta I just uploaded
<Kamion> elmo: thanks for that, I could have spent hours poking at britney :)
<elmo> Kamion: doubt [he'll mind]  and np :)
<elmo> mdz: how come ubuntu-desktop doesn't depend on ubuntu-base ?
<mdz> elmo: intuitively it doesn't seem like it should
<Keybuk> I suspect we should let users chose to just break one of the meta-packages, not both
<Kamion> mdz: ironically I have to wait for ubuntu-meta, because ubuntu-base is seeded and used to depend on modutils
<mdz> Kamion: heh
<mdz> -rw-rw----  1 mdz mdz 248 2004-11-09 22:20 /tmp/ubuntu-meta_0.7_source.upload
<mdz> Kamion: should be there fairly soon
<Kamion> ok, control-center uploaded
<Kamion> thom: mozilla-firefox 1.0 is apparently going into Debian tonight-ish
<jdub> 09:17 < thaytan> daniels: nice clean upgrade :)
<jdub> 09:23 < thaytan> no xcompmgr tho
<jdub> ^ heh
<cenerentola> hi see you
<cenerentola> good night
<m_tthew> fabbione: I caught daniels already, but missed you. awesome job with x.org, my upgrade went off without a hitch. very impressive.
<mdz> thom: do you know anything about the gnome-support stuff?  something we want?
<lupus_> daniels, are you daniel stone?
<mdz> lupus_: he is, but he isn't here
<mdz> mvo|hockey: are you back?
#ubuntu-devel 2004-11-21
<jdub> http://osdir.com/Article2346.phtml
<jdub> ha ha ha
<jdub> "Well, my goodness! It seems as if we're in for an upset. Despite previous polls, it appears that the Ubuntu Nude Man has sneaked ahead of Voting Machines in the final count. It seems that, in the evilness stakes this month, moral values beat the invasion of a self-electing junta of semi-sentient tabulating machines. Ubuttnaked Guy wears the Evil crown, and not much else, and invites us all back to his pad for some Twister and a toast... to evil!"
<mjg59> I'm close to wanting more extensive testing of PM stuff
<mjg59> Looks like we should be able to manage support for a decent range of Thinkpads, Dells, Toshibas and Sonys
<jdub> is there a "file stored *in* the initrd" solution for loading DSDT foo?
<mjg59> No
<mjg59> It's too late by the time the filesystem code is running
<jdub> boh, seriously? yeesh
<mjg59> You need a sane ACPI table before you do any PCI setup
<jdub> bong
<jdub> so tacking it onto the end of the initrd is the only "sane" solution
<jdub> what about another file pointed to by grub?
<jdub> kernel=blah, initrd=blah, dsdt=blah ;)
<mjg59> Yeah, extending grub so it loaded the dsdt and passed the address to the kernel would work
<mjg59> But you'd need to extend the linux boot protocol
<mjg59> That's the way FreeBSD does it, BTW
<jdub> ahar
<jdub> that'd be handy
<jdub> i'm going to cry rebuilding my kernel all the time
<mjg59> The dsdt-in-initrd thing is easy enough
<mjg59> Just add a hook to mkinitrd
<mjg59> The infrastructure is there already. When you install a deb, it builds a new initrd on the fly.
<jdub> yeah
<jdub> but didn't you just say you couldn't do that? :)
<mjg59> Uh
<mjg59> On the end of the initrd, rather
<jdub> oh right, yeah
<jdub> but we didn't accept that patch
<lamont_r> moo
<Kamion> hi lamont
<lamont_r> evening Kamion
<jdub> morning
<mjg59> jdub: It's the least invasive way of doing it. Upstream won't take it because the acpi guys want people to fix their BIOSes instead.
<mjg59> But, unsurprisingly, that's unlikely to happen much...
<lamont_r> mjg59: first step in getting them to fix their bios is to obtain > 10% market share
<Kamion> we're working on that one ..
<mjg59> lamont_r: Yeah
<lupus_> has gnome decent dualview and tv-out support (I mean you can turn them on and put a window on them)
<jdub> lupus_: X does :)
<mjg59> lupus_: Uh, ish
<mjg59> It's X that's responsible for that, and Gnome can then display stuff on it
<mjg59> But it's not easy to switch it on or off on the fly at the moment
<jdub> mjg59: do you think it's a relatively sane solution?
<mjg59> Oh, argh
<mjg59> Does Hoary have the fontconfig version that fucks up if you switch on sub-pixel anti-aliasing?
<mjg59> jdub: Of the solutions, I think it's the sanest
<mjg59> It doesn't break anything unrelated
<jdub> there have been quite a few comments about font bongery
<mjg59> The fontconfig maintainer forced the autohinter on if you're using subpixel anti-aliasing
<mjg59> Which is crack
<lifeless> daniels: looking for me ?
<Kamion> can some Xish person look at http://people.ubuntulinux.org/~lamont/buildLogs/c/control-center/1:2.8.1-0ubuntu3/control-center_1:2.8.1-0ubuntu3_20041109-2312-i386-failed please?
<Kamion> ah, I appear to be missing a build-dep on libxkbfile-dev
<lupus_> why is network-manager not yet in hoary?
<lupus_> ic that it is in a seperate repository
<mjg59> lupus_: Because it doesn't work
<lupus_> hehe I wonder how long it will take for me to break my system :)
<mjg59> netapplet works better at the moment, but is less cool in the long run
<mjg59> Right. I need to add a couple more patches to the kernel, make it depend on initrd-tools, update acpi-support and then we're set
<lupus_> btw when I switched to gamin
<lupus_> fam package is still installed and running famd
<lupus_> shouldn't the gamin package say it can't be installed together with fam 
<lupus_> or does running both give no problems
<tseng> they dont exactly conflict
<tseng> what should happen is something needs to depend on gamin to pull it in on dist-upgrade
<tseng> because gnome gets all wacky when you switch from libfam to libgamin and gamin isnt around
<tseng> nautilus + g-panel try to connect
<tseng> fam will just be dropped from the meta packages and go away on new installs i presume
<lupus_> k
<jdub> mmm, ubuntu-desktop will depend on gamin
<tseng> sounds like a plan
<jdub> though fam will still be there
<tseng> mm?
<jdub> unless i make the libgamin libs conflict with fam
<jdub> or something like that
<lupus_> uhu
<jdub> which is roughly scary
<jdub> Kamion: ping
<tseng> libgamin conflicts with libfam
* Keybuk takes jdub's crack away
<Keybuk> "Conflicts" is not to be used for "I think this package smells" :)
<jdub> Keybuk: thought so :)
<tseng> the packages do, at least. i assume its for good reason
<lupus_> libfam is uninstalled
<lupus_> but fam isn't
<jdub> lupus_: yes
<lupus_> when you install gamin
<jdub> tseng: yes, those ones do because they conflict at the file level with each other
<jdub> Keybuk: *however*
<Keybuk> assuming people used aptitude or synaptic, fam will be automatically removed when ubuntu-desktop no longer depends on it
<lupus_> but when people upgrade to hoary from debian or warty how do you make it uninstall fam then?
<jdub> Keybuk: if libgamin replaces libfam, and fam doesn't work with libgamin, then surely a conflicts would be relatively sane? :)
<jdub> lupus_: thus far, we don't
<Keybuk> lupus_: it'll happen automatically because it was installed as a dependency of ubuntu-desktop, and nothing depends on it anymore
<tseng> libgamin + fam doesnt seem to work here
<jdub> if you're using aptitude
<Keybuk> jdub: synaptic does it too, fwir
<tseng> nautilus hangs waiting to connect, then fails and proceeds to act flakey
<tseng> i imagine thats readily reproducable
<jdub> Keybuk: so it's not a file conflict, it's a compatibility conflict
<Keybuk> jdub: no, Conflicts actually require the complete and utter removal (including postrm) of the package before the conflicting is installed
<Keybuk> when combined with meta-packages, it creates a small dependency hell
<jdub> so can we make libgamin 'not like' fam in some way?
<Keybuk> that'd probably result in some intelligent behaviour such as the removal of ubuntu-desktop and anything else depending on fam before the new packages could even be unpacked
<mdz> Keybuk: the aptitude magic won't happen, because it was installed as a task
<mdz> not as a dependency
<Keybuk> mdz: I thought we installed the meta-package now, and not the task?
<mdz> Keybuk: nope
<Keybuk> oh, boo, hiss, etc.
<mdz> the metapackage happened way too late in the release cycle for that
<Kamion> jdub: yes?
<jdub> Kamion: n/m
<Kamion> ok
<Kamion> bleh, that libxklavier change wasn't as simple as I thought
<jdub> Kamion: just attempting to tackle the libgamin vs. fam issue :)
<Kamion> turns out (a) X.Org build-dep changes and (b) source-level changes for libxklavier are required
<amu> FYI, the xorg packages works fine on a sid ( ppc ) 
<Keybuk> jdub: this is what "upgrade notes" are for :)
* Kamion hopes seb128 won't hurt him
<Kamion> Keybuk: we so need Breaks
<jdub> it won't actually cause any problems
<Keybuk> we do ineed
<jdub> but fam and portmap are there needlessly
<Keybuk> doogie's reading -dpkg ... maybe he'll contribute some code :p
<Kamion> you wish
<Keybuk> :o)
<Kamion> just a shame that implementing Breaks would lightly touch nearly all of dpkg
<jdub> Breaks?
<Keybuk> jdub: a gentler version of conflicts
<jdub> ah, which is what i'd want
<Keybuk> The basic idea is that, roughly, Breaks is to Conflicts as Depends is to
<Keybuk> Pre-Depends. Conflicts requires that the conflicted-against package
<Keybuk> isn't even unpacked when the conflictor is unpacked, while Breaks allows
<Keybuk> the two packages to coexist on the system but (with --auto-deconfigure)
<Keybuk> deconfigures one of them. Breaks would be appropriate in cases where
<Keybuk> Conflicts: foo (<< some-version) is currently used to indicate that foo
<Keybuk> needs to be upgraded to some-version or newer in order to work with the
<Keybuk> conflictor.
<Keybuk> (me quotes an old Colin mail :p)
<jdub> so many thingies
<jdub> what do you call those?
<jdub> depends/pre-depends/conflicts/etc?
<Keybuk> "relationships" :)
<jdub> mmm
<elmo> "shiny"
<jdub> heh
<Keybuk> though I'm all for naming the field "Anally-Violates"
* lamont2 kicks acpi
<Keybuk> kick thom, more fun
<lamont2> so, how do I unblank an X server?
<lamont2> vt7 is boring - totally black,
<pitti> Night everybody!
<lamont2> the other vt's are more interesting...
<lamont2> and I'd rather not restart X to fix this obvious lidbutton.sh/X interaction bug...
<srbaker> guh
<tseng> xset dpms force on do anything?
* lamont2 checks
<lamont2> tseng: that produces a usage message.. :-)
<tseng> works here..
<lamont2> xset dpms force on does nothing
<lamont2> per xset q: dpms is enabled, monitor is on.
<lamont2> however, nothing shows on the Xserver vt...
<lamont2> fabbione/daniels still awake?
<lamont2> how very amusing... X died/restarted finally...
* lamont2 looks at the log
* Kamion finds the diff from GNOME CVS required to make control-center work with new libxklavier
<mdz> how come the hoary-changes messages for my uploads come From: "Ubuntu Installer", while most others come from the uploader?
<elmo> the email you used wasn't whitelisted
<Keybuk> Changed-By: Matt Zimmerman <mdz@debian.org>
<elmo> katie@jackass:~/scratch $ grep mdz /srv/ftp.no-name-yet.com/katie/katie.conf 
<elmo>      "mdz@alcor.net";
<Keybuk> instead of Changed-By: Matt Zimmerman <mdz@canonical.com>
<elmo> (and of course *@canonical.com is whitelisted too)
<mdz> hmm, I wonder how that happened
<mdz> I could have sworn I changed my $DEBEMAIL a long time ago
<mdz> the one thing dch *doesn't* have an option for is the maintainer name/address
<elmo> aren't you an emacs user?
<mdz> oh, I know what it is
<mdz> that was ubuntu-meta
<mdz> whose changelog is automagically generated by a script
<mdz> which invokes dch
<elmo> why would any card carrying emacs user use dch vs. debian-changelog-mode?
<mdz> my ubuntu-changelog-widget script sets DEBEMAIL for me
<mdz> elmo: seems a lot easier to use from python
<mdz> I use debian-changelog-mode for interactive editing
<Keybuk> elmo: emacs takes too long to start? :)
<elmo> card carrying emacs users always have a copy open :P
<Keybuk> yeah, but it might be in the wrong window, or directory
<mdz> yeah, that's like complaining that firefox takes too long to start
* Keybuk always has an emacs open somewhere
<Keybuk> but usually uses vi to edit things
<thom> they're usually wearing white coats backwards, too
<Keybuk> otherwise I'd have to find the terminal with emacs open, then remember the path to the debian/changelog I wanted to open, edit it, save it, then find the terminal I was working in before again, then build the package
<Keybuk> far easier to just "dch" :p
* elmo disowns keybuk from the emacs club
<Keybuk> elmo: if someone can make the X version of emacs not suck, I'll be happy
<Keybuk> but all the time it sucks, it's emacs-nox for me
<jdub> elmo: he wants pretty fonts, basically.
* mdz hands gnuclient to Keybuk
<Keybuk> mdz: can't open a new window
<mdz> Keybuk: dude, it can execute arbitrary elisp forms
<Keybuk> because emacs is in a terminal
<mdz> wtf is emacs doing in a terminal? :-P
<Keybuk> <Keybuk> elmo: if someone can make the X version of emacs not suck, I'll be happy
<mdz> I thought you were saying it sucked because you had to play the cwd game
<Keybuk> http://descent.netsplit.com/~scott/ugl-emacs.png
<Keybuk> the X version on the left is far too wide and ugly for me to use
<lamont_r> mdz about?
<mdz> lamont_r: yes
<jdub> Keybuk: can't just fix the fonts?
<Keybuk> jdub: edd once compiled the Xft version of emacs, but never got it to run -- it has had little love
<Keybuk> the patch won't even apply now, let alone compile or run
<lamont_r> mdz: about 820 packages from main are built for ia64 - does it make sense to drop them into w-b and the archive?  worst case elmo winds up moving the Packages files to grumpy and dropping them from hoary
<thom> why didn't they use pango/gtk for the main window when they have done so for the menus?
<Keybuk> thom: allegedly it's so custom that it's impossible
<thom> meh.
<Keybuk> so I have an emacs open to work in and use as an IDE, and when I want another editor for anything, I use vi :p
* lamont_r considers getting a "not a child rapist" button. :-)
<jdub> thom: new ff industrial theme does look nice
<Keybuk> 1.0.5?
<jdub> 1.0.6
<thom> 1.0.6
<thom> jdub: yeah
<thom> if i get bored of packing tomorrow i'll do a 1.0 ;-)
<jdub> is packaging the theme still a pita?
<Keybuk> oh, what did that fix?
<jdub> heh
<thom> Keybuk: it's fixed that the search box was utterly broken on debian/ubuntu installs
<jdub> and there were file selector problems
<Keybuk> oh right, not noticed anything with 1.0.5 but then I haven't really stressed it :p
<thom> yeah, those too appear fixed
<jdub> hrm, that was fixed in 1.0.5, as it happens
<jdub> he hasn't said anything about 1.0.6 on his blog
<jdub> (changes, that is)
<Kamion> remind me what I have to do when GNOME hangs at the splash screen?
<Kamion> no icons at the bottom
<Kamion> gnome-settings-daemon is spinning
<jdub> Kamion: got libgamin and no gamin?
<Kamion> jdub: got both
<jdub> hrm
<jdub> http://www.google.com.au/firefox
<Keybuk> jdub: pretty
* jdub kicks daniels for posting xorg announce to announce list...
<jdub> takes a long time to connect to ftp stuff in nautilus
<Kamion> ok, how might I have broken gnome-settings-daemon?
<mdz> Kamion: you don't need InstallerSeed stuff in the wiki anymore, right?
<jdub> the only thing i can think of that's tweaked it recently would be libgamin/gamin
<mdz> I turned the other Seed pages into lists of proposals
<mdz> but since InstallerSeed won't get proposals, I think it's obsoleted by the arch archive
<Kamion> mdz: nope
<Kamion> jdub: trying now after installing libxxf86misc-dev
<Kamion> the xorg stuff is conspicuously missing transitional dependencies for things that used xlibs-static-dev
<lamont_r> mdz: at any rate, I think ia64 is ready to be in the archive, and would certainly benefit from being there.  your call.
<jdub> Kamion: hrm, was this from a futzy control-center build post-xorg?
<jdub> oh, pre-xorg...
<Kamion> jdub: it's from the one I'm doing now to try to get it working with an xklavier that's actually in the archive
<jdub> yuck
<Kamion> jdub: I made a no-brainer upload fiddling the build-dep, and now that it's broken I feel obliged to do a proper job rather than leaving it broken
<mdz> lamont_r: I don't have a problem with it in principle
<mdz> any other considerations?  mirrors?
<elmo> as long as there's not going to be an ABI change, mirrors shouldn't be a factor
<elmo> (and there's not going to be an ABI change :)
<mdz> elmo: was talking about ia64
<elmo> so was I ?
<jdub> hrm
<mdz> elmo: adding a new architecture doesn't impact mirrors?
<mdz> I assumed it meant dumping a few extra gigs on them
<elmo> oh, well, yes, there is that
<mdz> and additional churn
<elmo> sorry, I was talking in terms of, if it didn't - for whatever reason - make hoary
<elmo> it'll be ~7Gb impact for mirrors - plus the initial churn
<jdub> u,
<mojo> good morning every1
<mojo> check out this new theme for d4x
<mojo> http://xlife.zuavra.net/temp/gnomeria-ubuntu.png
<Kamion> what is it that spawns gnome-settings-daemon?
<Kamion> I want to strace it
<mdz> gnome-session, I'd imagine
<Kamion> ENOSUCHPROCESS
<mdz> it's invoked as x-session-manager via alternatives
<Kamion> aha
<Kamion> I tried stracing that, though
<mjg59> thom: Still awake?
<mdz> I think when I was chasing this stuff, I ended up replacing gnome-settings-daemon with a wrapper script
<Kamion> hm, probably a good plan
<thom> mjg59: barely
<thom> mjg59: what can i do you for?
<mjg59> thom: Oh, ok - I'm working on exciting! Hot! New! acpi scripts
<mjg59> If you'll be around in a couple of minutes you can take a look
<thom> rock and roll
<m_tthew> anyone else using amd64+xorg heavily?
<thom> i'm so staying awake then
<thom> m_tthew: i've been running it since monday...
<thom> m_tthew: as my primary system
<m_tthew> thom: do you seem to be losing mouse events occasionally?
<thom> m_tthew: not that i've noticed
<m_tthew> I'm having some transient oddness since going to xorg and I'm trying to confirm ym sanity
<m_tthew> thom: ok, thanks
<m_tthew> my*
<robertj> where is the trendy place to put /etc/X11/XF86Config-4 in xorg?
<mdz> robertj: trendy?
* thom notes that Alpha XP1000s are not the lightest pieces of kit ever to grace a desk
<robertj> hehe, ;)
<lupus_> are there plans to integrate lm-sensor and smartd in ubuntu?
<lupus_> so you check your systems health :)
<mjg59> thom: http://www.kern.srcf.ucam.org/~mjg59/laptops/
<mjg59> I've managed to fuck my machine royally while looking at this, so I'm going to reboot now in order to test it :)
<mjg59> It adds scripts, but doesn't add events for all of them
<mdz> lupus_: there was a proposed goal for Hoary to integrate SMART; see /topic
<lupus_> and lm-sensor ? 
<lupus_> or is their something familiar
<mjg59> thom: Oh, and I forgot to add the rmmod button; modprobe button thing (but that ought to be obvious enough)
<mjg59> Hang on, I'll reboot and then test it myself...
<thom> k k
<lupus_> if I apt-get grepmap
<lupus_> it will just work?
<mjg59> thom: Heh. Couple of minor issues - give me one more moment...
* thom thinks mjg59's testing was not as successful as he hoped
<thom> heh
<Kamion> lupus_: depends what you want it to do
<Kamion> lupus_: it's not really for end-user use
<thom> mjg59: sorry dude, i have to hit the hay now
<thom> i'll look in the morning
* lamont_r dinners
<mjg59> thom: No problem - the ones on the site now should work
<lupus_> k I think I found a bug
<lupus_> can someone verify
<lupus_> with latest xorg
<lupus_> ctrl+alt+backspace will stop X
<lupus_> but not restart it
<lupus_> I just get the terminal then
<Kamion> that's up to your display manager
<lupus_> can someone test this
<Kamion> if you kill X forcibly too many times, it may get bored and give up restarting it
<Kamion> I've been using ctrl-alt-backspace lots just now with Xorg, it works as normal with gdm
<lupus_> I only did once after reboor
<lupus_> hmm
<lupus_> weird then
<sivang> is there anything I shouldn't bee douing while dist-upgrading ? Just got
<lupus_> going to bed now 
<sivang> it broken.
<sivang> kdelibs-bin and kcontrol conflicts on /usr/bin/filesharesets
<Kamion> universe is unsupported, as you well know :)
<sivang> ah right :)
<sivang> kde will stay out :), in universe..
<mjg59> So much rock
* mjg59 finishes off ACPI scripts that automatically unload network devices and which handle sound power management
<mjg59> Ok. The contents of http://www.srcf.ucam.org/~mjg59/laptops should work on a wide range of machines
<mjg59> I heartily encourage anyone with an x86 laptop to try them out
<mjg59> There's a decent chance of working ACPI suspend to RAM, and if that doesn't work then there's a good chance of working suspend to disk
<Kamion> I hate hangs in mallopt()
<Kamion> I especially hate them on architectures without valgrind
<mjg59> Ha
<jdub> mjg59: got dsdt/initrd patches? :)
<mjg59> jdub: Dude, it's in there
<jdub> yay
<mjg59> Oh, shit
<mjg59> Missed one (moderately important) ACPI patch
<mjg59> jdub: But go ahead and try that stuff, anyway
<mjg59> Or give me 10 minutes (or less) and I'll have a slightly better package :)
<mjg59> ARSE.
* mjg59 accidently forces an entire package rebuild
* jdub gives mjg59 ten minutes ;)
<mjg59> SHIT
<mjg59> Where has my debian directory gone?
<Kamion> a kernel package?
<mjg59> OH YOU FUCKING BASTARD
<mjg59> For reasons I do not understand, debian/rules just blew away my debian directory
<mjg59> Including all the patches
* mjg59 cries
<Kamion> mjg59: what package?
<mjg59> ACPI test kernels
<Kamion> do you have a fully up-to-date kernel-package?
<mjg59> Mm?
<Kamion> if not, upgrade and read the rant in the changelog on this very subject
<mjg59> That is going to make life... awkward.
<mjg59> Arse. I have headers but no source file.
<mjg59> ARGH.
<Kamion> I believe the current version contains a workaround as well as a rant
<mjg59> On the bright side, there's relatively little work involved in recreating it
<mojo> ^o^, X.org up, thx fabbione, nice exp here
<mjg59> Sigh.
<jdub> mjg59: :-(
<mjg59> jdub: Heh
<mjg59> jdub: Just try the ones up there, anyway
<jdub> ok
<mjg59> I'll worry about it later
<jdub> need all those debs?
<mjg59> Yeah
<mjg59> Need the initrd one installed first
<Kamion> segfault inside *ORBit*? how the hell did gnome-settings-daemon get there ...
<jdub> ok
<Kamion> Oh. gconf. Fuck.
<jdub> Kamion: ouch.
<mjg59> ACPI is so my bitch
<jdub> eugenia makes baby jesus cry
<mjg59> Except on the craptop
<mjg59> Or some HPs
<Kamion> this is only electric fence's idea of a segfault, mind you
<mjg59> And my other Thinkpad
<mjg59> But the last of these is a driver bug
<Kamion> the new Firefox find widget rocks my world
<jdub> it's way sexy
<mjg59> jdub: You'd better be grabbing packages, boy
<jdub> am! am!
<jdub> mjg59: rebooting...
<Kamion> oho!
<Kamion> XklConfigInit() helped
<jdub> hrm
<jdub> mjg59: so, i put it in S3 sleep
<jdub> and woke it up by hitting the power button
<jdub> (this is in very single user mode, init=/bin/sh)
<mjg59> Ok
<jdub> how do i turn the screen on? :)
<mjg59> Heh
<mjg59> Try running video_post
<mjg59> The scripts do that automatically
<jdub> aha
<jdub> uh oh
<mjg59> echo -n 3 >/proc/acpi/sleep; sleep 1; /usr/sbin/video_post
<mjg59> Mm?
<jdub> ok
<jdub> that did the crazy "my lcd screen is about to blow up" effect
<mjg59> Ah
<mjg59> Ok
<mjg59> You need to do this:
<mjg59> Add
<mjg59> option VBERestore true
<mjg59> (but with normal quotes)
<mjg59> to /etc/X11/xorg.conf (or whatever)
<mjg59> In the device section
<mjg59> And then boot fully and press the sleep button
<jdub> note that i wasn't running X at all by then
<mjg59> Yeah
<mjg59> We need X to fully reinitialise the screen
<jdub> aha
<mjg59> Though this depends on the hardware
<jdub> also, i now have a buttload of ide controller modules loaded
<jdub> ooh, and now i'm getting buffer i/o errors on uba
<jdub> exciting
<jdub> mjg59: given that i wasn't in X before, should i try without the vberestore change?
<mjg59> They're all loaded in 2.6.8, but in 2.6.8 you could unload them again
<jdub> ahar
<mjg59> jdub: Add the vberestore change - it seems to be needed on various i855 machines
<jdub> ok
<mjg59> And remember to restart X :)
<jdub> doing so :)
<jdub> wha-hey
<jdub> suspended correctly from X
<jdub> aaaand...
<jdub> haha
<jdub> the power button woke it up and halted the machine :)
<mjg59> Haha
<jdub> the screen came on correctly in console mode though :)
<mjg59> Oh, rock
<pasc> jdub: I get that when I resume my laptop
<pasc> so I need to unload the buttom module before I suspend
<mjg59> jdub: Does the /etc/acpi/prepare.sh script have rmmod button at the top of it?
<jdub> heh
<jdub> saw that on the list
<jdub> hold on
<mjg59> I have a sudden feeling I may have forgotten that
<jdub> booting again :)
<mjg59> Ha, no
<mjg59> It doesn't
<jdub> woo :)
<mjg59> Add that, and see whether it works
<jdub> after the chvt?
<jdub> oh top
<mjg59> Yeah, right at the top
<mjg59> Has the added advantage of reducing bouncing
<jdub> we have glowing power light indicating suspend
<mjg59> So far so good
<jdub> we have console
<jdub> haha
<jdub> we have shutdown
<mjg59> Ha
<jdub> i don't actually have a sleep button
<jdub> i have a power button
<mjg59> Uh
<mjg59> How are you triggering the sleep?
<jdub> echo -n 3 ...
<mjg59> Oh, right
<mjg59> That's not going to work
<jdub> oh
<mjg59> How do you not have a sleep button?
<jdub> hrm
<mjg59> It's normally Fn+one of the F keys
<jdub> i have a suspend function button
<jdub> yeah
<jdub> i'll see if that works
<jdub> those keys are affected by the dsdt foo
<jdub> some don't work
<mjg59> Yeah, but the spec requires (well, strongly encourages) at least one of them
<jdub> yeah, i don't think it's doing bong all
<jdub> can i fake it?
<mjg59> Just to test, can you do /etc/init.d/acpi stop
<mjg59> And then cat /proc/acpi/event
<mjg59> And press Fn+all of the keys
* Kamion mails seb128 about the control-center stuff, and crashes
<jdub> mjg59: acpid?
<mjg59> jdub: Sorry, yes
<mjg59> Oh, it ought to be Fn+Escape
<jdub> button/sleep SLPB 00000080 00000003
<jdub> it is
<mjg59> Rock
<mjg59> Restart acpid, switch to X, hit Fn+Escape
<jdub> hrm, i am in X :)
<mjg59> Heh
<mjg59> Skip that step, then
<jdub> nah, not happy
<mjg59> Hrm.
<mjg59> In what way?
<jdub> same as before - no effect at al
<jdub> all
<mjg59> ?
<mjg59> Oh, I see
<mjg59> Fuck, I'm useless
<pasc> *sigh*
<mjg59> jdub: Can you grab http://www.srcf.ucam.org/~mjg59/laptops/acpi-support_0.10_i386.deb ?
<pasc> sounds like I'm going to have to switch my laptop to ubuntu too if it has such mad laptop support =-\
<mjg59> jdub: Install that and do Fn+Escape
<mjg59> I managed to copy files in the wrong direction at one point...
<mjg59> pasc: All of this will end up in Debian (eventually)
<jdub> pasc: why the sad face? :)
<mjg59> Probably post-Sarge, though
<mjg59> There's too much that needs to go into the kernel to make it practical right now
<jdub> mjg59: AHA!
<jdub> we have sleepy power light
* jdub presses power button to wake it up
<jdub> we have flashing screen
<mjg59> Tension...
<mjg59> It ought to (with luck) result in xscreensaver
* jdub switches to vt1
<pasc> jdub: well i'm already doing most of my debian stuff from within a chroot on an ubuntu desktop
<jdub> it does indeed!
<mjg59> WHO IS YOUR FUCKING DADDY?
<jdub> mjg59: so we totally need to send a key/mouse signal to xscreensaver when it wakes up ;)
<jdub> mjg59 IS MY DADDY!
<mjg59> jdub: Dude, that rocks
<pasc> does anyone know where bob2 is btw?
<mjg59> We are going to have totally mad-phat laptop support
<jdub> mjg59: i have this really bizarre usb spew though
<jdub> pasc: sydney
<jdub> mjg59: *everything* comes back up properly
<mjg59> jdub: Yeah, there will be weird USB spew
<mjg59> The drivers are excessively chatty
<jdub> new to 2.6.9?
<jdub> i'm getting all kinds of buffer i/o errors and stuff
<jdub> unable to read partition table
<jdub> there's no disk in there :)
<pasc> mjg59: do you have stuff for debian already?
<pasc> mjg59: or is this a "in the future" kind of thing?
<mjg59> pasc: Not for Debian, yet
<mjg59> It needs kernel patches
<mjg59> jdub: Heh
<mjg59> Yeah, 2.6.9 wants to tell you all about itself
<mjg59> pasc: Post-Sarge, I'll be looking at getting all this infrastructure into Debain
<mjg59> The problem is that it requires coordinating the kernel, initrdtools and the acpi userland tools
<mjg59> And that's going to be pain
<pasc> yeah
<jdub> ubc...
<mjg59> ubc?
<jdub> usb block device, it seems
<mjg59> Ah, right
<jdub> no longer sdX
<mjg59> Heh
<mjg59> But if you ignore the errors, it all comes back?
<mjg59> I've tried to be smart about unloading network drivers, which are the normal reason for breakage nowadays
<mjg59> It's possible it needs to do the same for sound drivers, but that's going to be far, far messier
<jdub> oh, usb stuff seems to be unrelated
<pasc> my main problems on my toshiba was the usb stuff
<mjg59> Probably easier to fix all the sound drivers...
<jdub> it's just reiniting the usb foo on wakeup
<jdub> hrm
<jdub> sound
<mjg59> pasc: 2.6.9 is much better for usb
<pasc> cool
<jdub> no problems with sound
<pasc> sounds like I need to upgrade then
<mjg59> Once we have video sorted, sound is the next big problem
<mjg59> jdub: Heh. Except there almost certainly would be if you were playing any when you suspended.
<jdub> ooh, that sounds like fun
<pasc> mjg59: you can start working on my next problem with suspend too
<mjg59> pasc: At this rate I'm going to have to start charging people
<pasc> when you knock the bottom of my laptop, sometimes the battery moves 
<mjg59> Ha
<mjg59> Blue-tac
<jdub> okay
<pasc> and then it doesn't resume properly ;-)
<mjg59> Fixes everything
<jdub> that was not appreciated
<mjg59> jdub: Yeah. Don't Do That (at the moment, anyway)
<mjg59> We need to get in touch with the ALSA people
<jdub> mpg123 is now in D state :)
<mjg59> jdub: Other thing that you can do is hack the /etc/acpi/events/lidswitch script to suspend on lid closure
<jdub> very tempting
<jdub> did you hear my surprise at unexpected functionality once i got acpi going?
<mjg59> In the long run, we'll have support for checking whether there's an external monitor plugged in
<mjg59> And if so, not lock the screen when you close it
<jdub> aha
<jdub> :)
<tseng> mjg59: thatd be killer
<jdub> the top line of my console has funny flashing bits
<tseng> ive been fighting that here
<jdub> after wakeup
<tseng> jdub: same here, but it goes away.
<tseng> oh suspend, not lidclose lock
<jdub> i wonder if xorg will have support for i855 external vga crap
<mjg59> jdub: Under what circumstances?
<mjg59> jdub: xorg has support for non-mirrored output
<mjg59> So you can have separate content on both
<jdub> mjg59: when hitting the suspend button, the top line on the console flickers (rows of pixels on and off), and stays that way after wakeup
<jdub> ahar
<jdub> mjg59: so does this kernel have wacky swsusp stuff in it?
<tseng> i wonder if doing the non-mirrored output i could get a higher res on the CRT
<mjg59> jdub: Just the console, or in X as well?
<mjg59> jdub: It has swsusp stuff in it, yes
<jdub> not fussed
<mjg59> jdub: Sorry, are there any flickering lines in X?
<mjg59> jdub: Add a resume=/dev/hdawhatever to /boot/grub/menu.lst and do update-grub
<jdub> no flickering lines in X
<jdub> X is in glorious resumed technicolour
<mjg59> Cool
<bob2> pasc: yo
<mjg59> As long as you installed the initrd-tools package before the kernel, just adding the resume line should result in echo -n disk >/sys/power/state doing hot suspend to disk action
<jdub> grr.
<jdub> even with 2.6.9, my digital sound output still has this zinging noise
<mjg59> Now, if only I knew why the craptop and keybuk's HP didn't work...
<bob2> beats a short, sharp bong.
<mjg59> jdub: You're going to be the envy of your friends now, you know
<mjg59> Working ACPI is still a thing of wonder
<jdub> i will have to find a crowd of people to impress
<jdub> debsig
<mjg59> Haha
<mjg59> IN THE FUTURE THERE WILL BE ACPI
<jdub> AND YOU WILL BOW DOWN BEFORE IT
<hornbeck> when do we get inotify
<hornbeck> ??
<mjg59> Man, I'd better get a wedding invitation after this
<jdub> dunno
<jdub> haha
<bob2> I for one welcome our new ACPI overlords
<mjg59> jdub: We need more testers
<mjg59> Find more testers
<jdub> make your repo suckable
<jdub> and ping ubuntu-devel :)
<mjg59> Oh man
<mjg59> I'll do that in the morning
<mjg59> It's 04:20 here
<jdub> heh
<mjg59> jdub: I keep subscribing to ubuntu-devel but I never here anything after I go to the confirmation link
<jdub> oh?
<mjg59> No idea why
<jdub> want me to sub you?
<mjg59> Yeah, thanks
<jdub> preferred address?
<mjg59> mjg59@srcf.ucam.org is good
<jdub> done
<mjg59> Thanks!
<fabbione> morning guys
<lamont_r> evening fabbione
<lamont_r> I have a question for you fabbione
<lamont_r> sometime after X is blanked (lidbutton.sh), it won't come back... how do I whack it enough to wake it up?
<fabbione> lamont_r: is that on a laoptop?
<lamont_r> yes
<fabbione> i am not sure what lidbutton.sh does...
<fabbione> is that x.org or xfree86?
<lamont_r> xf86 - stock warty
<lamont_r> it does this:
<lamont_r> su $user -c "(xscreensaver-command -throttle && xscreensaver-command -lock)"
<lamont_r> xset dpms force off
<lamont_r> and if I wake it up soon enough, then all is happy.  if not, then it's not so happy.
<fabbione> does the laptop die completely? or only X=
<fabbione> ?
<lamont_r> only X.
<lamont_r> black screen.
<lamont_r> other vt's are happy
<fabbione> hmmmm
<fabbione> it would be nice to 
<fabbione> strace it
<fabbione> and see what is going on...
<lamont_r> I tried 'xset dpms force on' and a few other things...  eventually X died.
<fabbione> or gdb the -dbg version
<lamont_r> and restarted --> all well.
<lamont_r> likewise, ctl-alt-backspace is a known "fix" :-(
<fabbione> hell no
<fabbione> but there is a lot of code that i don't know in X
<fabbione> it's simply too big
<lamont_r> yeah, way big.
<lamont_r> I figure I'll worry more after I switch over to xorg.
<fabbione> ehe
<fabbione> hmm
<fabbione> i really really don't like this phase one on sparc
<fabbione> lamont_r: i keep getting tons of failure on the gcc test suite
<fabbione> but i don't understand why
<fabbione> the chroot is a fresh sid
<fabbione> (phase one)
<fabbione> so there is really no difference on what is building
<fabbione> and gcc has been imported from sid
<lamont_r> fabbione: yeah - saw interesting failures on other architectures as well.
<lamont_r> are you trying to build warty or hoary?
<fabbione> hoary
<fabbione> so it's basically recompiling gcc from sid in a sid chroot right now
<lamont_r> which should work.
<fabbione> exactly
<lamont_r> or bug doko, would be my activity.. :-)
<fabbione> i think i know what it is
<fabbione> i am afraid it is still trying to build 64bit binaries
<fabbione> and i need to change the call to dpkg-buildpackage
<fabbione> i had to do the same ith pbuilder
* fabbione resets the buildd and starts from scratch again
<fabbione> mdz: ping
<fabbione> pool/universe/x/xorg/xfree86-common_6.8.1-1ubuntu1_all.deb
<fabbione> THIS IS REALLY REALLY REALLY REALLY BAD!
<fabbione> it has to be into main!
<lamont_r> fabbione: that's an elmo overrides thing, I expect.
<lamont_r> trivial fix, just requires a whack.
<fabbione> i know
<fabbione> but all xfree86 -> xorg upgrades are broken without that piece
<fabbione> it is required to migrate some config files
<fabbione> and to force the switch over to xorg-common
<daniels> lifeless: I was, yeah
<daniels> KeyserSoze: oh, neat
<daniels> lamont_r: sup
<doko> morning
<doko> lamont_r, fabbione: I'll start a gcc build in a current sid env to reproduce the failures ...
<lamont_r> doko: thanks
<fabbione> doko: i am trying to build again using sparc32 in front of dpkg-buildpackage
<fabbione> apparently the /etc/disable_64_gcc is not enough
<doko> you could disable the biarch compiler. (debian/rules.defs)
<daniels> new from the forums: 'FGLRX sucks for ATI, why can't I get 3D?'
<daniels> just look in the first part of your subject!
<lamont_r> daniels: remind me to make you help me get taht working in spain...
<daniels> lamont_r: fglrx ... working?
<daniels> lamont_r: you'd better have some pretty incredible bribes lined up
<daniels> lamont_r: what sort of video chipset do you have?
* daniels guffaws at #3542.
<lamont_r> radeon 7500
<lamont_r> that's the home desktop though...
<bob2> hah
<lamont_r> laptop is ati rage mobility p/m agp 2x...
<lamont_r> which I gather might be 2d?
<ik5pvx_> X Window System Version 6.8.1 (Ubuntu 6.8.1-1ubuntu1 20041109183716 root@terranova.warthogs.hbd.com)
<ik5pvx_> great job!
<fabbione> ehy ik5pvx_ !
<fabbione> thanks :-)
<fabbione> there are still a bunch of bugs to fix
<fabbione> but tho
<ik5pvx_> only gotcha I had, I had to manually install xserver-xorg. Is that intended for this testing phase ?
<fabbione> no
<fabbione> if you have ubuntu-desktop installed
<fabbione> everything is smooth
<fabbione> if you customize your desktop you are on your own
<ik5pvx_> oh, that's it.. I think I removed ubuntu-desktp because it asked to install stuff I don't want. It's all right then. If I can find some time, I'll later try to upgrade the other install I have (the clean install for test purposes). BBL
* lamont_r sleeps
<daniels> lamont_r: hm, rage mobility, should get very, very basic 3d out of it
<daniels> lamont_r: i'll check it out in spain, but no fglrx needed!
* sid77 'morning
<doko> fabbione: please email me the build/gcc/testsuite/*.log files 
<fabbione> doko: i will if it keeps failing
<fabbione> but i am pretty sure it's related to the call to sparc32
<doko> started a build on an ultrasparc IIi ...
<fabbione> doko: cool
<fabbione> doko: with or without sparc32 ?
<doko> with sparc32
<fabbione> doko: it would probably be more useful without
<fabbione> or both
<fabbione> well up to you
<doko> let's wait, the testsuite will finish on Friday, then I can check without.
<fabbione> doko: i am faster on my netra :-)
<fabbione> i will test both again and let you know
<fabbione> if i only still had access to the e10k :-)
<fabbione> make -j 32 ;)
* sid77 study time!
<fabbione> seb128: hey
<fabbione> seb128: are you using a pure utf8 locale on hoary?
<fabbione> (and x.org and co?)
<seb128> fabbione: yes
<seb128> oups, and hi fabbione ;)
<seb128> fr_FR.UTF-8
<fabbione> seb128: please try to revert to a non-utf8 locale
<fabbione> and check the copy&paste again
<seb128> ok
<fabbione> a friend of mine doesn't have that problem at all
<fabbione> gedit <-> emacs both directions work
<tuo2> so, what's doing?
<fabbione> apparently problems with copy and paste
<seb128> fabbione: ok, no problem in fr_FR@euro
<daniels> seb128: cool!  i say the problem is that xaw sucks, in that case
<seb128> and I don't get these "Gdk-WARNING **: locale not supported by Xlib"
<seb128> "Gdk-WARNING **: cannot set locale modifiers" 
<seb128> neither
<fabbione> i think utf8 code in x.org is too immature
<seb128> anybody has a fc installation somewhere to test ?
<seb128> they are using utf-8 for a while and X.org
<fabbione> seb128: i did check all x.org patches in fedora
<fabbione> there is nothing related to utf8 :(
<fabbione> is it possible that applications requires a rebuild on top of x.org?
<seb128> I'm not sure it works on fc, but it would be nice to test
<seb128> that would be weird ...
<daniels> which version of libXaw is emacs or whatever linked against?
<daniels> but I suspect the killer is locale not supported by Xlib
<seb128> daniels: that's a general problem with gtk+1.2 apps, not only emacs
<daniels> i would love a chroot install of fedora to poke around in
<fabbione> i don't have the CD of fc to check
<rburton> daniels: ping?
<daniels> rburton: yo, pong
<rburton> daniels: why does Xproto explicitly define _XOPEN_SOURCE=500?
<rburton> it's breaking my compiles!
<rburton> (as with that the BSD and GNU extensions get turned off)
<rburton> do i really have to add #define _GNU_SOURCE to everything?
<daniels> no they don't :) you just need -D_BSD_SOURCE and -D_GNU_SOURCE also
<daniels> um, yeah
<daniels> hold on a sec
<rburton> _GNU_SOURCE turns on _BSD_SOURCE
<daniels>         * xproto.pc.in:
<daniels>         Force define of _XOPEN_SOURCE; FD_SET et al depend on fds_bits
<daniels>         presence, which is an X/Open special and thus only guaranteed with
<daniels>         _XOPEN_SOURCE. I'd love to do this in Xpoll.h, but <sys/select.h> has
<daniels>         a habit of being included earlier than Xpoll.h.
<rburton> waaa
<daniels> basically, we're shit out of luck if people manage to include <sys/select.h> before Xpoll.h, which happened a hell of a lot, as it were
<daniels> (if you find a better solution, pleeeeeeeeeeeeease send me a patch because I hate it also)
<rburton> let it break if people include stuff in the wrong order?
<plovs_work> mdz, is there a hoary-wish page in the wiki?
<daniels> rburton: given there's no defined order, there's no 'right' order as such ...
<pitti> Morning
<cenerentola> hi
<daniels> pitti: morning
<mvo_> morning pitti 
<daniels> justdave: btw, what's the process for getting bz components resynced?
<justdave> there's a script in the warty-bugs directory on macquarie, feed it a text file with the full package list, one per line, and it'll create components for any that don't have them yet.
<justdave> I think it's addcomponents.pl or something like that
<daniels> ok, don't have access to macquarie, will ping mdz when he wakes up.  cheers.
<justdave> otherwise if there's one or two you're missing they can be added manually.
* justdave suspects it's the entire suite of xorg stuff though
<fabbione> justdave: only 3 packages
<fabbione> hem no
<fabbione> sorry
<fabbione> a bit more than that
<daniels> fabbione typoed
<daniels> he typed '3', but really meant '67'
<daniels> mdz: could you please resync bz components please?
<pitti> Morning steve, doko, nmf, seb128!
<seb128> hi pitti !
<doko> morning
<Mithrandir> thom: *prod*
<Mithrandir> oh well, incoming glibc.
<seb128> anybody has an opinion on 3550 ?
<seb128> pmount is supposed to handle that ?
<thom> Mithrandir: hiya
<thom> thank you :-)
<daniels> thom: 'morning sir
<thom> ello
<doko> elmo: do we sync packages from experimental as well, or unstable only?
<Kamion> fabbione,daniels: was xlibs-static-dev meant to depend on the stuff you guys split out of it for transitional purposes?
<seb128> hey Kamion 
<Kamion> hi seb128
<Kamion> let me stick that control-center package I did somewhere so you can tell me how much crack I'm on
<elmo> doko: experimental only on demand
<seb128> Kamion: the libxklavier problems, settings-daemon hanging are fixed in the GNOME head branch
<daniels> Kamion: no
<Kamion> where was the hang fix?
<Kamion> I looked
<seb128> Kamion: they just not have made a release for 2.9 ...
<daniels> Kamion: we'll deal with the very few FTBFSes caused by missing B-Ds on the new packages
<daniels> Kamion: like a year on, half of Debian still B-Ds on xlibs-dev, and that's crap
<doko> elmo: please sync python2.4 (beta2) from experimental 
<Kamion> seb128: the problem I had was that libgswitchit was using XklConfig*() without having called XklConfigInit()
<Kamion> seb128: which results in a very obscure hang (or segfaults, depending) in the middle of libxkbfile
<daniels> Kamion: sounds a lot like trying to use python-apt, except without all the clarity of instructions
<Kamion> yep
<Kamion> seb128: so I stuck XklConfigInit in gnome-settings-daemon/gnome-settings-keyboard-xkb.c right after XklInit
<seb128> Kamion: one min, I'm looking in the changes
<Kamion> seb128: http://people.ubuntu.com/~cjwatson/control-center/
<daniels> Kamion: if the package fails because it can't find oldX.a or X10.h, it's time to talk to a little more than the Build_Deps with an axe
<Kamion> daniels: problem with control-center was that the package subtly broke more than failing, with some of them
<daniels> Kamion: was the c-c problem xklavier, missing b-ds, or both?
<Kamion> both
<daniels> crack
<daniels> if you want to just assign me the bug for anything that ftbfs and b-ds on xlibs-static-dev (or xlibs-static-pic), i'd be happy to cop that
<Kamion> seb128: shout if I should upload that or if you're taking care of it; I want to get a fix in ASAP so that I can finally build working CDs, though
<seb128> Kamion: I'm working on it
<Kamion> ok, thanks
<seb128> Kamion: but I'm pretty sure they fixed that upstream too, so I'm considering to upload the CVS snapshot of the 2.9 branch
<Kamion> I can't see it in CVS
<seb128> my jhbuild used to hang a few days ago
<seb128> and it doesn't anymore
<Kamion> hmm
<tuo2> can someone explain to me the difference between sounders and ubuntu-devel mailing lists?
<seb128> and I've spoken about this problem with gnomevfs devel a few days ago who pinged me later to said it was fixed or at least workarounded
<Kamion> fair enough
<mvo_> we have quite a few package with section "contrib/section" (e.g. jde and lots of others). do you think that this may confuse users? I got a bug about it (#3369) and I'm unsure what to do about it
<Kamion> tuo2: sounder == off-topic chat; ubuntu-devel == development
<Kamion> tuo2: sounder was our beta testers list before we went public
<Kamion> but that's historical now
<tuo2> ah. ok.
<seb128> Kamion: http://bugzilla.gnome.org/show_bug.cgi?id=156986
<tuo2> Kamion: thanks. I kept seeing references to it on devel mailing list
<Kamion> seb128: thanks
<seb128> Kamion: apparently the fix is on libxklavier
<seb128> 2004-10-31 21:00  svu
<seb128>         * libxklavier/xklavier_config_xkb.c:
<seb128>         Fixing the xkbcomp command line. Ubercool!
<pitti> elmo: can you please sync "tiff" from sid?
<mjg59> thom: We got suspend working for jdub
<daniels> jdub: so that's why I get an X300, so I can wait like two months longer to get working suspend :P
* sid77 hello
<Astharot> sid77: ma tu sei di piacenza ?
<sid77> o_O
<sid77> yeah
<Astharot> az :P
<sid77> who are you?
<sid77> I'm thinking about someone in the lug
<Astharot> yes ^_^
<sid77> lol
<thom> mjg59: holy crap
<thom> a dell that works?
<daniels> mjg59: what was the magic bullet?
<fabbione> doko: gcc is failing again
<Kamion> seb128: ah ...
<fabbione> doko: do you want me to send you the log file now, or should i wait it will finish ?
<Kamion> seb128: (I needed to change libxklavier's build-deps too: s/xlibs-static-dev/libxkbfile-dev/)
<seb128> Kamion: I'm building your package now, if it works fine I'll upload that for the moment, time to sort that with upstream
<mjg59> daniels: New kernel, my evil as fuck video reinit magic
<seb128> Kamion: your solution seems to be right
<Kamion> cool :)
<seb128> thanks for tracking the problem :)
<daniels> Kamion: wait -- do not upload c-c yet
<Kamion> daniels: -> seb128
<daniels> seb128: libxkbfile1's shlibs are sort of a little bit broken
<daniels> xorg -1ubuntu2 coming in a bit
<mjg59> thom: You should take a look at that acpi-support package
<seb128> daniels: how short ?
<elmo> pitti: done
<mjg59> daniels: Is it easy to add xorg.conf options by default on a driver-dependent basis?
<elmo> doko: for 'main' ?
<daniels> seb128: dunno, probably about 3h by the time I eat lunch and upload it and the buildds get it
<daniels> mjg59: yes
<mjg59> daniels: It seems that we want Option vberestore on for i810
<elmo> daniels: btw, that libstdc++5-dev was minor, I hope you have lots of other reasons to upload too :)
<seb128> elmo: could you remove trashapplet from hoary ?
<pitti> elmo: thx
<mjg59> Edd isn't able to resume without it
<seb128> daniels: ok
<fabbione> seb128: that the aussie placed the wrong simlinks around
<elmo> seb128: ? what replaces it ?
<doko> currently on the phone ...
<seb128> elmo: it's a part of gnome-applets now
<daniels> mjg59: craaaack
<seb128> elmo: and it already has the conflicts/provides/replaces for like 1 week
<daniels> elmo: yes -- fix shlibs and symlinks across the board, add missing libxevie* files, fix libxext-dev vs libx{damage,fixes,composite,evie,dmx}-dev conflicts
<mjg59> daniels: All it does is use VBE to save and restore video state, rather than just relying on what the driver thinks is useful
<elmo> seb128: ok, cool
<mjg59> daniels: The manpage claims it's broken in some places, but I haven't been able to find one yet
<daniels> mjg59: oh cool
<daniels> mjg59: that sounds sensible, because at last count there were 37 unique i8xx video BIOSes
<Kamion> seb128: should trashapplet be removed from the desktop seed, then?
<daniels> for which we have the docs for exactly none
<seb128> Kamion: yes
<elmo> seb128: done
<seb128> thanks
<Kamion> seb128: done
<daniels> mjg59: so using vbe whereever possible (the entire i8xx mode-setting code is vbe) is eminently sensible
<seb128> Kamion: thanks :)
<elmo> gar.  python's strptime() can't parse 'date -R'
<mjg59> daniels: This is disabled by default because it causes lockups on some platforms.
<mjg59> It doesn't say /what/ platforms, irritatingly
<daniels> mjg59: no, because that would be sensible
<daniels> mjg59: although if you get lockups on VBE, i810 in general will be a total minefield
<Kamion> elmo: craaaaaaaaaack
<daniels> mjg59: tempting to just enable it per default and find out what breaks, partially in service to science and partially out of morbid curiosity
<mjg59> daniels: Rock
<thom> mjg59: should i be staying with 2.6.10pre or running the 2.6.9 you have up?
* daniels -> food
<mjg59> thom: Does suspend/resume work with that 2.6.10pre?
<mjg59> I'd strongly recommend the 2.6.9 for now
<mjg59> It seems more solid than the other ones
<elmo> seb128: dude, you so need a better internet connection :)
<thom> sus/res works for me
<thom> on 2.6.10
<mjg59> Does cpufreq?
<seb128> elmo: that's not my connexion, I've restarted my GNOME session to test Kamion's changed, but since I use a graphical IRC client ... :)
<thom> if i have speedstep-centrino loaded, yes
<thom> if i have acpi loaded, no
<seb128> Kamion: ok, works fine. Do you want an upload now or should I wait on the new X.org upload ? (we can still do a second upload for the shlibs later)
<Kamion> seb128: I guess waiting on xorg is the right thing, I don't know how broken the shlibs are :-/
<mjg59> thom: Oh, anything in /proc/acpi/processor ?
<thom> mjg59: no
<seb128> Kamion: ok
<Kamion> I have to leave in four-and-a-half hours today, so I suspect I won't get working CDs before I leave
<mjg59> thom: Ah, ok - I know what version you have now :)
<thom> heh.
<mjg59> You won't be getting C2/C3 powersaving on the processor with that kernel
<thom> righto
* thom grabs 2.6.9
<rburton> mjg59: you'll know this -- in 2.6 my x20 correctly clocks down to 466mhz when i take the mains out, but i can't seem to push it back to 700mhz if i want to. should i be able to with cpufreq?
<mjg59> rburton: Depends if it's doing speedstep or throttling
<mjg59> But yeah, in principle
<rburton> oh hang on
<rburton> it's clocked up still
<rburton> if i don't run cpufreqd it doens't drop or something
<mjg59> Don't use cpufreqd. It's rubbish.
<mjg59> Use powernowd instead
<rburton> l
<rburton> powernowd gets the thumbs up from me
<jdub> morning
<seb128> hey hey jdub 
<lupus_> jdub, are there plans to include lm-sensors in hoary?
<lupus_> I see smartd is already planned
<daniels> lm-sensors is very difficult to get right
<daniels> loading the right module on my machine involves a lot of guesswork, and a solid lockup if you get it wrong
<lupus_> Why are drivers for other devices easily found but not for i2c?
<mjg59> lupus_: Because there's no standard way of device identification
<mjg59> lupus_: Probing the i2c bus can destroy hardware
<elmo> because they're the backstreet homeless of devices
<lupus_> destroy hardware :s
<lupus_> joy
<jdub> lupus_: i think it's already listed on the wiki
<thom> mjg59: looks good; i've added stopping mysql and dbus to prepare and restarting them in resume and that gets everything working here
<daniels> thom: why stopping those two?
<thom> daniels: cos mysql and NetworkManager especially don't allow you to suspend if they're running
<mjg59> thom: Rocking
<jdub> thom: (if we had dependency-based init scripts...)
* jdub runs :-)
<mjg59> thom: Those scripts ought to be fairly generic
<mjg59> (No idea if you've taken a look at them or not)
<thom> mjg59: indeed, been reading through them
<thom> nice work!
<mjg59> So, that leaves us with the lid switch
* thom notches yet another one on the mjg59 beer list
<mjg59> Which has two cases - on power and off power
<mjg59> On power, we probably want to just blank the screen (unless the external video is in use, which we /ought/ to be able to tell once the video acpi support goes in)
<daniels> thom: at this rate, he'd better not bring his X40 the next time he sees you, or he'll be edwarded
<elmo> thom: WTF kind of crack is that - why would mysql care?
<daniels> thom: NM is cracktastic
<mjg59> elmo: It's something to do with signal handling
<mjg59> The problem is how we blank the screen
<mjg59> The easy solution would be to chvt away from X, do a dpms off and then on open do a dpms on and chvt back to X
<mjg59> But:
<mjg59> Not all hardware gives us the second lid event
<thom> oh, lovely
<thom> so we could end up never turning the screen back on?
<mjg59> Yeah
<mjg59> So, instead we can leave it up to X (since if we use X's dpms code, X will power it back up when someone hits a key)
<mjg59> But X doesn't always have working DPMS, especially if you're using the vesa driver
<daniels> s/ always//; s/, especially.*//
<mjg59> daniels: WTF does the vesa driver not have DPMS support?
<mjg59> The bright side is that /most/ hardware will blank the screen itself on lid close
<mjg59> So the combination of X dpms and just letting the hardware get on with it should be fine
<daniels> mjg59: i don't know, but I'd rather not find out
<jdub> argh, bong, no gossip again
<thom> mjg59: so in the on power case, we probably just want to lock the screen and throttle xscreensaver, and then let the hardware get on with it?
<jdub> thom: can we send xscreensaver a 'show lock dialogue' or send some mouse/key events to the X server when the lid is opened again?
<lupus_> gnome-screenshot is gone in hoary
<lupus_> can someone verify this
<jdub> lupus_: it's in gnome-utils, which hasn't been released yet
<mjg59> thom: And do an xset dpms off
<Kamion> lupus_: see ubuntu-users
<lupus_> ah k
<mjg59> thom: With luck, that'll get the backlight switched off
<thom> ok
<thom> and now the entertaining case, on battery
<mjg59> thom: Also need to decide how to hook up the suspend to disk case, but that's a separate issue
<mjg59> thom: Ok. The right thing to do is to suspend to RAM if the lid is closed and on battery.
<mjg59> Except that some people would prefer this to happen after a few minutes rather than immediately.
<thom> mjg59: presumably suspend-to-disk would wind up in Computer/Log Out as a menu option 
<mjg59> thom: Yeah
<mjg59> thom: In an ideal world, we have user-settable policy
<thom> nod
<mjg59> Which probably wants to be dbus based
<mjg59> Then we can give them a nice little GUI
<thom> this is hard until we have dbus based powermanagement
<jdub> (yay yay yay)
<thom> aye
<jdub> elmo: ping
<thom> that way we get consistent love over ppc/x86/amd64 too
<mjg59> Yeah
<elmo> jdub: ?
<mjg59> amd64 uses acpi too, so that's easier
<thom> anyway, until then, i guess we can have a config file so that people who _want_ a timeout can just set one
<thom> but we default to just suspending instantly?
<mjg59> Yeah
<mjg59> So the real question now is how we do stuff by default...
<mjg59> We probably ought to add support for S1 as well, since that'll work everywhere
<mjg59> Well, except on hardware that doesn't support it, of course
<mjg59> But S1 needs dpms calls either side of it, because it won't usually blank the screen otherwise
<mjg59> The craptop works fine in S1
<thom> (we also need to work out a policy for APM, too. although that _should_ be easier)
<thom> windows suspend is S1 by default, right? 
<daniels> thom: yes, you have to go start->shut down->standby(s3)/hibernate(s4)
<daniels> so we'll be beating them in that regard if we pull this off
<mjg59> It /is/?
<mjg59> That's crack-tastic
<Kamion> jdub: can you set me as maintainer for partman* in bugzilla?
<doko> elmo: For python2.4, I would propose main, but I'm unsure if I'm allowed to. the final python2.4 release is scheduled for December.
<thom> hm, just thinking it would be far less of a support hassle to go down the same road, but make it really easy for people to switch to S3
<mjg59> daniels: The X40 doesn't do S1, so this certainly isn't always the case
<mjg59> thom: S1 gives... little power saving
<doko> fabbione: failing to build, or failing in the testsuite?
<elmo> doko: can you mail/ask mdz/jdub and get sign off on a) importing it, and b) asking where to import it?
<thom> mjg59: so i'm reading - Standby by default is S1, but if you set it in the bios it'll use S3 instead
<thom> mjg59: nod
<Kamion> jdub: also netcfg
<mjg59> thom: Ah - I see what you mean. I think most laptops default to S3.
<jdub> Kamion: ok
<mjg59> But yeah, Award BIOSes tend to let you choose
<doko> elmo: ok, jdub, listening?
<thom> can we get the information out of the bios? is there a consistent "suspend me harder" flag?
<jdub> doko: please mail devel, cc mdz/me
<Kamion> hm, and debconf might not hurt either
<daniels> thom: DAMNIT MAN
<jdub> Kamion: hrm, perhaps email a list :)
<doko> jdub: ok
<daniels> thom: my t-shirt just became a multi-purpose coffee-removal-from-laptop tool
<mjg59> thom: Not that I know of
<thom> mjg59: figures
<Kamion> jdub: where?
<jdub> Kamion: oh, just to me
<mjg59> thom: S3 is expected to Just Work on modern hardware (in the Windows world, anyway) so I suspect that if there is anything it'll be in the Windows driver files
<Kamion> jeff.waugh@c.c?
<jdub> yeah
<thom> mjg59: ugh.
<thom> mjg59: hardware database time, again
<mjg59> Yeah
<daniels> that and a large list of modules which are known to not cope well with power management
<mjg59> I suggest we get this stuff into Hoary and default to S3, then pick up the pieces
<mjg59> Revert it before release
<Kamion> jdub: sent
<thom> right, so test it as hard as possible, but not necessarily go through with it
<thom> ughfull, but the sensible route
<mjg59> thom: Sure, except possibly for whitelisting stuff
<cenerentola> sorry but ive got connection problems..
<daniels> (this is my current plan with Composite, if we can get it off the ground at all)
<cenerentola> ive also reported thi error--- *** Couldn't look up your hostname
<cenerentola> ...mmm sorry
<elmo> suspend stuff seems so much harder on i386 - it "just works" on my powerbook now ;-)
<mjg59> thom: Other thing that needs doing is adding apm to /etc/modules by default
<daniels> elmo: you're speaking to three x40 owners here :)
<cenerentola> it gives an error for eggdesktopentries.c line 223
<mjg59> elmo: Haha. Yeah, to a large extent it /is/ harder on i386 - PPC leaves more up to OF
<thom> cenerentola: dude, wrong channel
<daniels> mjg59: (of also doing sane things like setting up your video hardware for you so you don't have to care anywhere near as much)
<cenerentola> sorry
<thom> mjg59: will that do the right thing consistently - ie, only give you apm suck if acpi is turned off?
<mjg59> thom: Yes
<daniels> thom: if module load order is guaranteed, then yes
<mjg59> daniels: Doesn't matter - acpi has to be static
<daniels> thom: if acpi is lodaed, apm goes 'oh shit i think that's acpi peace for real though' and buggers off
<daniels> oh, in that case, yeah
<mjg59> thom: In that case we also want a handy script that people can run in order to send us their DMI data along with whether it worked or not
<thom> indeed
<mjg59> I think we'll be in good shape on most modern hardware
<mjg59> But it'll be interesting to see
<thom> it should be fun, definitely
<mjg59> thom: Oh, Edd reported functionality on his Sony
<mjg59> He doesn't get text consoles back, but he gets X
<thom> mjg59: score! that's a good start, anyway
<mjg59> (As of yesterday)
<mjg59> That's why we do the extra console-changing dance at the end
<thom> yeah, i was wondering about that
<mjg59> Oh, the dpms program uses vm86, so it won't run on amd64
<thom> oh joy
<mjg59> video_post has an x86 emulator, so it'll be fine
<mjg59> Now that I understand what video_post actually does, it ought to be possible to put the dpms functionality in there
<cenerentola> thom: you may be right but there's no one able to help in #ubuntu
<Kamion> that's not a reason to bring support stuff here; if nobody can help on IRC, try the mailing list, or report a bug if that's appropriate
<thom> mjg59: i'm going to attempt to bend the wiki to my will and write this stuff up
<mjg59> thom: Rocking
<daniels> 05:13 :::: Irssi: #ubuntu-devel: Total of 79 nicks 0 ops, 0 halfops, 0 voices, 79 normal
<daniels> 05:13 :::: Irssi: #ubuntu: Total of 300 nicks 0 ops, 0 halfops, 0 voices, 300 normal
<daniels> also, virtually everyone in #ubuntu-devel is in #ubuntu, so
<daniels> thom: good luck on the first count
<Kamion> how goes that xorg fix?
<daniels> Kamion: just quadruple-checking *.links files before I scp to chinstrap
* sid77 bye all
<jdub> "Oxford University Computing Services (OUCS), which provides services to staff and students around the university, will complete its move to open-source PostgreSQL as the back-end database for most of its systems over the next year."
<jdub> ^ nice!
<sladen> presumbly they were using mysql before ;-)
* thom drums fingers and waits for the wiki
<elmo> yeah, but they found it couldn't survive a suspend/resume cycle :-P
<mjg59> elmo: Oh, it survives - it's the suspend/resume cycle that doesn't
* elmo runs screaming into a wall
<daniels> how tragic, their main database x300s won't be able to go into s3 :P
<jdub> Kamion: done
<Kamion> jdub: great, thanks
<Kamion> elmo: please sync partman-lvm to unstable
<sladen> mjg59: if lid_closed && on_battery && !kismet_running
<daniels> sladen: not that you get to keep your centrino modules around a switch to s3, anyway
<elmo> Kamion: done
<sladen> thom/daniels: in XP, if you press shift at the Log-Out screen, the standby changes to hibernate (why they didn't put both, I don't know)
<thom> EW
<thom> (yay discoverability)
<daniels> oh my god, crack
<Kamion> elmo: partman-partitioning too
<daniels> still, goes nicely with XP's 'someone just forced open my eyelids and poured speed in' UI
<elmo> Kamion: done
<cenerentola> daniels: http://www.pastebin.com/118552
<Mithrandir> fabbione, daniels: you rock.
<daniels> Mithrandir: what've we done this time?
<thom> Mithrandir: http://people.ubuntulinux.org/~lamont/buildLogs/g/glibc/2.3.2.ds1-18ubuntu2/ :(
* Mithrandir whacks thom with firefox' forgetfulness.
<Mithrandir> it doesn't remember it should have middlemousecontenturl.
<Mithrandir> thom: well, it's not _failed_ at least. :)
<thom> true
<Mithrandir> daniels: my xorg upgrade Just Worked.
<daniels> Mithrandir: ill
<Mithrandir> that's what you've done.
<fabbione> amen
<fabbione> daniels: I TOLD YOU TO CHECK THE ANTI-MITHRANDIR PATCH!
<fabbione> :P
<Mithrandir> fabbione: help me remember to buy you beer in .es
<mjg59> Keybuk: Does your machine have ACPI S1?
<fabbione> Mithrandir: ehehe
<Keybuk> no... not that I'm aware
<Keybuk> syndicate scott% cat /proc/acpi/sleep
<Keybuk> S0 S3 S4 S4bios S5
<mjg59> Ok
<GeorgeD> daniels: beer or 3 for you next time i see you (luv meet i suppose)
<sladen> mjg59: S1 is just basically putting the processor into HALT ?
<fabbione> daniels: i guess we will spend 3/4 of DecConf drunk :P
<mjg59> I'm planning on getting hold of tbm's and using his docking station to do some more debugging
<daniels> GeorgeD: heh, not until January at least, thanks though
<daniels> fabbione: heh
<mjg59> sladen: Yeah, CPU state isn't lost
<daniels> Kamion: 6.8.1-1ubuntu2 uploaded
<Mithrandir> fabbione: you say that as if it's a bad thing.
<fabbione> Mithrandir: i am not used to high alchoolic level :)
<fabbione> not anymore at least
<Mithrandir> well, you need training, then.
<jdub> hahahaha
<jdub>    * debian/patches/990_ubuntu_accept_enabled_for_extensions.diff: accept
<jdub>      Enabled and Disabled for the Extensions section, so what I said in my
<jdub>      -announce mail actually works.
<jdub> 
<jdub> daniels: SIPPER!
<daniels> jdub: hey, you bitched at me for sending the *one* announce mail :P
<Kamion> "I typoed. I know, let's change X"
<daniels> Kamion: seemed sensible at the time
<Kamion> :-)
<jdub> heh
<jdub> daniels: nah, just the list you chose ;)
* Keybuk toys with moving his desktop to hoary as well
<cenerentola> daniels: youre way  doesnt work
<daniels> jdub: ah, heh
<mjg59> Hmm.
* mjg59 gets the craptop to S1, but notes that the CPU fan doesn't switch off
<mjg59> thom: Heh. One issue...
<mjg59> S1 seems to need the button module loaded in order to be able to wake up
<thom> hahaha
<thom> suck.
<daniels> heh, oops
<daniels> mjg59: if by 'fan', you mean 'speaker' ...
<Keybuk> *giggle* ... "Cc 'elmo' didn't match anything"
<daniels> Keybuk: troup
<mjg59> thom: So the sleep script needs to check what state we're going to and deal with it appropriately
<thom> fun. 
<daniels> hooray
<mjg59> thom: Not sure what the best fix is - IIRC, acpid serialises calls, so naive locking won't work
<mjg59> Hurrah. So, I can get the craptop to suspend and switch off its screen.
<mjg59> Of course, it has no way of switching the fan off from software.
<Kosai> mjg59: Ooh.  I'm impressed that you've got somewhere with it.
<mjg59> Kosai: This is by doing S1 rather than S3
<mjg59> S3 is still fucked
<Kosai> Ah.
<Kamion> Keybuk: can you make the merge-o-matic look at openssh/experimental rather than unstable?
<jdub> mjg59: the fan is necessary for the on-board flame detection feature.
<zul> i was wondering how you go about fixing those merge-o-matic bugs on the bugzilla
<mjg59> Heh. So, it stops the CPU, it switches off the screen and it stops the hard drive
<mjg59> But there's no way we can pretend that it's suspending if the fan is still going
<Kamion> zul: download merge candidate prepared by Scott, compare diffs side by side, make any necessary changes, upload
<Keybuk> Kamion: I guess ... it'd need a config file somewhere, but it's do-able
<zul> ok
<Kamion> zul: occasionally give up on the automerge and do something else entirely
<zul> hehe
<Keybuk> basically apply the changes in .dropped by hand, then make sure that _ubuntu.{patch,debdiff} and _merged.{patch,debdiff} are identical, or you can explain anything missing
<fabbione> Keybuk: can you kindly disable that automatic bug thing sync with debian stuff for xfree86?
<zul> i dont have upload access so if anything breaks should i attach it to the bug report?
<Keybuk> fabbione: no, elmo has to do that
<fabbione> Keybuk: ok
<Keybuk> I assume it'll stop automatically when we don't have xfree86 in the archive
<fabbione> elmo: can you please do the above?
<fabbione> Keybuk: no.. i am going to do another XFree86 upload
<fabbione> but with time and quiteness
<Keybuk> oh?  are we having both in our archive?
<fabbione> only to have xserver-xfree86
<daniels> we do not have an xfree86 source package for hoary
<fabbione> daniels: yes we do
<fabbione> the source is still there
<fabbione> we uploaded xorg_6.8.1.orig.tar.gz
<fabbione> that has nothing to do with xfree86_4.3.0
<Keybuk> then don't we *want* to continue updating our xfree86 package against Debian?
<fabbione> Keybuk: no
<Keybuk> why not?
<fabbione> it is only for a temporary amount of time
<daniels> can someone run madison on the archive to verify whether or not we have xfree86 in the archive for hoary?
<sivang> using hoary : anybody noticed how slow nautilus is? it's taking me about ages to navigate through the directory tree..
<Keybuk> fabbione: how temporary?
<jdub> sivang: have you upgraded adn not installed gamin?
<fabbione> Keybuk: xserver-xorg is way new for us
<daniels> sivang: install gamin
<fabbione> and not that many people have tested it yet
<fabbione> Keybuk: if something is really broken on xorg server
<fabbione> the user is still able to install xfree86 (server) easily
<fabbione> until we don't fix the problem and kill the old server
<sivang> jdub : strange, it's been downloaded - but wasn't installed using dist-upgrade..
<jdub> sivang: do you have ubuntu-desktop installed?
<fabbione> xorg hasn't been around enough to be able to kill xfree86 from one day to another
<fabbione> Keybuk: we are talking about a few weeks.. not years
<sivang> jdub : was also not installed, although downloded. installing now
<sivang> jdub : got some gtk assertions failing, when installing. from eggdesktopentries.c
<sivang> but in the end, it's now back to speed :) 
<sivang> thanks jdub
<seb128> sivang: these assertions are coming from update-desktop-databasa probably
<seb128> sivang: is there an hoary system ? do you have mplayer uptodate from multiverse ?
<sivang> fabbione : do we get to set up funkey vertrefresh rates using the new xorg? or just use the same crafted modes lines from xfree..?
<fabbione> sivang: xorg = xfree86+morebugs+morecracks
<fabbione> i leave up to you the answer to your question :-)
<sivang> fabbione : great! Starting to feel like sid again...:)
<daniels> hopefully there's sufficient laptop timing detection code (maybe the stuff from ATI does it) that we can kill horizsync/vertrefresh in the config file altogether
<daniels> ... but not in the very near future
<Kamion> zul: hm, merges may be best left to the Ubuntu maintainer it's assigned to, but yeah, pretty much
<zul> k
<Kamion> zul: install patchutils and attach the debdiff against the Debian version, probably
<Kamion> daniels: madison> yes, you do
<Kamion> cjwatson@little:~$ madison-lite -s hoary -S xfree86
<Kamion>    libxft1 | 4.3.0.dfsg.1-6ubuntu25 |         hoary | amd64, i386, powerpc
<Kamion> libxft1-dbg | 4.3.0.dfsg.1-6ubuntu25 |         hoary | amd64, i386, powerpc
<Kamion>    xfree86 | 4.3.0.dfsg.1-6ubuntu25 |         hoary | source
<Kamion> xserver-xfree86 | 4.3.0.dfsg.1-6ubuntu25 |         hoary | amd64, i386, powerpc
<Kamion> xserver-xfree86-dbg | 4.3.0.dfsg.1-6ubuntu25 |         hoary | amd64, i386, powerpc
<daniels> Kamion: thakns
<daniels> Kamion: i take it madison isn't accessible to mere mortals? (elmo?)
<Kamion> madison itself requires direct database access => login on jackass
<sivang> seb128 : checking..
<Kamion> madison-lite can operate on any mirror
<daniels> oh, cool
<Kamion> it's the equivalent of grovelling through Packages and Sources files, but less boring
* mjg59 mails ubuntu-devel
<jdub> mjg59: go go go!
<azeem> is http://www.ubuntulinux.org/wiki/ConferenceAttendees supposed to look unreadable?
<Mithrandir> azeem: no
<Keybuk> it's on the new Wiki ... so I guess "yes" :p
<Mithrandir> the new wiki is doooog sloooow
<Mitario> hi everyone
<mvo_> hi Mitario 
<Mithrandir> azeem: I'm trying to unbreak it.
<azeem> thanks
<Kamion> looks like it's set to the wrong markup type
<Mithrandir> yeah, which broke all the line breaks.
<Mithrandir> but the wiki is so slooooooooooooooow
<Mitario> mvo_, i've been brainstorming a bit about a way to fetch the current upstream stable, I have not found a definit solution though :)
<Mitario> i think we could have a file onlinw somewhere
<mvo_> Mitario: I haven't yet thought about it
* Mithrandir considers giving up fixing the wiki, as it's too slow.
* Mithrandir gives up
<zul> that was quick :)
<Mithrandir> somebody else can have the fun, zwiki and I are not friends, it seems.
* Kamion has a go
<Kamion> hmm, it's not clear that that helped
<Kamion> does zwiki's moinmoin markup support tables?
<Mithrandir> I couldn't get it to, but that gui widget Just Did The Wrong Things for me.
<jdub> Kamion: ours is fixed to handle it, so i hear
<Mithrandir> it worked before that last person added himself.
<Kamion> ah, it's helpfully done an HTML->moin conversion for me, brokenly
<Kamion> I'm fixing it again
<lamont_r> morning
<Keybuk> jdub: rock @ gnome-menus
<Mithrandir> Kamion: that was probably what threw me off, and I'm impatient today.
<seb128> Keybuk: have you tried it ?
<Keybuk> no, I only just saw the mail
<jvw> the annoying thing about this wiki is that it doesn't support outright reverts...
<jdub> Keybuk: yeah :)
<Mithrandir> jvw: the annoying this is it seems to be run on a 0.5MHz uC with 2k of ram which uses external donkey-based storage, so it's _dog_ slow.
<Keybuk> jdub: did you read my crackful musing on nautilus/filechooser type-ahead btw?
* sid77 hi
<jvw> Mithrandir: frustrated :-)?
<jdub> Keybuk: having a bar like firefox/
<Mithrandir> jvw: not the least. :P
<Keybuk> jdub: yeah, so as you start to type an entry box appears at the bottom to match your typing
<Keybuk> jdub: if you didn't put a /, it'd also highlight in the list whatever matched
<jvw> Mithrandir: the editor doesn't even have vi-keybindings
<rburton> Keybuk: i think jrb proposed that at some point
<jdub> Keybuk: might be better than the current find box stuff
<Mithrandir> jvw: editor?  You mean the form field?
<jdub> Keybuk: have you used the gtk+ 2.5 file selector yet?
<Keybuk> jdub: it's changed?
<Kamion> Mithrandir: fixed
<jvw> yeah. primitive, eh? vi was longer around that a form field :)
<Mithrandir> Kamion: ty
<thom> Mithrandir: the depressing thing is that's it's a dual xeon and is utterly unloaded
* jvw gives a go at fucking it up again
<Keybuk> jdub: ah, neat, so that already does something like it :p
<jdub> kinda
<Mithrandir> thom: takes a while for anything to come through the pipeline on those beasts, you know.
<jdub> plus you can just type / and it pops up the location box
<Keybuk> though that doesn't complete quite the same way :-/
<Mithrandir> thom: you should rather have gone for the amd64 boxes. :)
<jdub> Keybuk: it's a bit rough, yeah
<thom> yes.
<Mithrandir> thom: and you must remember to remove those "sleep(5)" around in the code.
<jvw> hm, it barfs on me logging in now...
<Keybuk> hopefully by es-conf, I'll actually have some free time to code rather than hand-wave my ideas :o)
<Keybuk> oh, #6 at http://lists.gnu.org/archive/html/libtool/2004-11/msg00132.html :o)
<sivang> strabge, new copying from a cd to hd take shorter time, however it doesn effect the other system prformance. this is something I am not familiar with in linux..
<jdub> Keybuk: is that a libtool goal?
<sivang> wonder if this is connected somehow to that gamin thingy :)
<Keybuk> jdub: it's a proposed one for 2.1 yes
<Kamion> Keybuk: #7 *yay*
<Kamion> is #2 the one that makes libtool disappear on Linux?
<Keybuk> largely, it still has to do a fair bit of work on Linux to battle stupid developers
<thom> seb128: you get a day off for "britain rescued us" day or something? ;-)
<Kamion> seb128: control-center should be uploadable now
<thom> AAARGH, epiphany's done the focussing-the-wrong-tab trick again
<jdub> heh
<daniels> thom: when's the UK's 'america saved us' day?
<thom> daniels: same day as australia's one
<KeyserSoze> hello ppl
<daniels> thom: you're confusing that with our 'foreign policy rights firesale' day
<jdub> haha
<daniels> thom: so, recount to me the tale of WW2
* daniels ducks.
<fabbione> hey KeyserSoze 
<thom> daniels: wrong war, dude
<KeyserSoze> could someone please update the enlightenment package to 16.7.1?
<KeyserSoze> sup fab
<fabbione> KeyserSoze: hacking on x.org as usual
<fabbione> KeyserSoze: is that version in debian already?
<KeyserSoze> unstable I believe so
<KeyserSoze> let me check
<fabbione> jdub: do we any policy for not allowing syncs from sid?
<daniels> thom: the one where you picked on the big kids and then ran out of money and sold your colonies off
<fabbione> (when it goes to universe)
<Kamion> daniels: 11 November = armistice day following WW1
<Kamion> hi infinity
<KeyserSoze> fabbione: nope
<infinity> Hey.
<daniels> Kamion: timely discussion, it seems
<KeyserSoze> deb is still behind even on unstable
<mvo_> pitti: do you mind if I upload a new aptitude this evening with changelog download enabled again?
<Kamion> daniels: don't look at me, I'm from the colony that was unfortunate enough *not* to get sold off
<thom> KeyserSoze: we're not going to package stuff that we don't care about, sadly. too much to do anyway
<pitti> mvo_: no, why I should?
<daniels> Kamion: as was my great-grandfather; something about potatoes
<pitti> mvo_: if ubuntu changelogs are actually available now?
<KeyserSoze> thom: thx... just trying to prove a point
<thom> KeyserSoze: um, what point?
<KeyserSoze> nothing its ok
<mvo_> pitti: yes, for now on people.u.o/~mvo/changelogs
<pitti> mvo_: nice :-)
<mvo_> indeed :)
<pitti> mvo_: this should revert many patches
<mvo_> pitti: yes, I'm building right now :)
<fabbione> thom: more than we don't care about. is that there are no debs in debian to sync from
<pitti> mvo_: have fun, I have to go now. CU tomorrow!
<thom> fabbione: yes, which is why i said "we're not going to package stuff" :-)
<infinity> No debs of what, exactly?
<KeyserSoze> no worries I'll roll my own .debs
<fabbione> infinity: latest enlightment?
<jdub> fabbione: for hoary, or warty?
<seb128> Kamion: ok
<fabbione> jdub: hoary
<seb128> thom: ah ah :p
<fabbione> jdub: last time i checked *WARTY* was released
<jdub> fabbione: unless there's ubuntu changes, we ought to be able to sync whenever
* thom grins at seb
<jdub> fabbione: check with elmo/lamont if they've already got a sync routine going, though
<thom> jdub: it's not in unstable yet, that's the point
<jdub> fabbione: that's why i saked :)
<fabbione> jdub: ok...
<jdub> thom: oh
<jdub> ok, now i don't grok
<Keybuk> the sync routine is in full speed swing
<Keybuk> elmo syncs stuff that's changed in unstable and we haven't changed
<seb128> I've to go, bbr
<Keybuk> and punts the list of things that changed in both to mom, which does the merge and files bugs
<seb128> Kamion: I've to go now, if you want to do a control-center upload just drop the 23_.. patch and updated the build-dep on libxklavier to 1.11
<seb128> Kamion: I'll do the upload when I come back if you don't do it
<Kamion> seb128: ok, will do it now then, thanks
<seb128> np
<daniels> can we please blacklist xfree86 from the syncage? :)
<jdub> thom: so what was the question about...?
<daniels> Kamion: xorg 6.8.1-1ubuntu2 is in, should be safe to upload
<daniels> Kamion: just check that anything using libxkbfile.so.1 gets a dep on libxkbfile1 before you upload though
<Keybuk> Kamion: on, wrt to the experimental thing ... the trouble is that elmo only checks unstable; so as soon as we leap ahead in versions you won't get any further sync suggestions until unstable catches up with experimental
<thom> jdub: KeyserSoze wanted enlightenment updated to the latest, which isn't in unstable
<jdub> oh
<elmo> eventually, I plan to keep better track of where we sync stuff from, then I can keep track of experimental stuff too
<KeyserSoze> I'm building my own debs
<KeyserSoze> its cool
<fabbione> elmo: mind to check if that version of enlightment is in experimental?
<elmo> fabbione: there's no enlightenment in experimental
<fabbione> KeyserSoze: this is something that we might need in general later
<fabbione> KeyserSoze: not just for enligh
<fabbione> elmo: thanks
<jdub> lamont_r: ping
<infinity> When did lamont become treadsafe?
<daniels> one thread for each buildd
<elmo> AFAIK he isn't.  he knows martial arts, I wouldn't tread on him, IIWY
<daniels> elmo: hey, I know martial arts also
<daniels> elmo: unfortunately I am hopelessly out of shape and my knees won't let me sustain any form of usage whatsoever
<daniels> elmo: is he *good* at it?
<elmo> I dunno - why don't you piss him off and find out for us? :)
<lamont_r> jdub: yo
<jdub> hey lamont_r 
<lamont_r> infinity: roving
<jdub> lamont_r: what's the status of the DC livecd builds?
<jdub> or should i be asking amu for the details?
<Kamion> bleh, my new debootstrap is BROKEN
<lamont_r> jdub: I need to check with amu on that
* Kamion discovers an exciting new "feature" of diversions
<lamont_r> jdub: the status is that the last drop I'm currently aware of required that root run it in the real root, or it failed to build a working CD.
<Kamion> or of debootstrap, I'm not sure which
<daniels> elmo: that's a great idea!
<Kamion> if you have a package that adds a diversion and installs a file in the same place, and you put that package in debootstrap's "required" section, then debootstrap will first extract it ignoring diversions, then unpack/configure it normally, which will give you both the file *and* the diverted copy
<spazzy> Hi
<Keybuk> that's just a debootstrap feature
<Keybuk> it unpacks stuff by just untarring it
<Kamion> if the copy that gets dropped in in place of the diverted file happens to be a wrapper script that calls the diverted file if it exists, you get an infinite loop
<spazzy> How can we make request about adding software ?
<Keybuk> rather than using dpkg, which knows about diversions
<Kamion> Keybuk: yes, I know about that, but the comment I just made turns it from an expected feature into something really exciting :)
<Mithrandir> Keybuk: it's kinda hard to use dpkg when it's not unpacked yet, no?
<spazzy> because Ubuntu will be great if there was directly a CD, DVD burning application
<Keybuk> spazzy: nautilus-cd-burner exists
<jdub> spazzy: you can use nautilus-cd-burner now, we're looking at coaster for hoary.
<spazzy> ok
<Keybuk> the trouble with, e.g. k3b is: Depends: k3blibs (>= 0.11.12), kdelibs4 (>= 4:3.2.3), libart-2.0-2 (>= 2.3.16), libarts1 (>= 1.2.3), libasound2 (>> 1.0.5), libaudio2, libaudiofile0 (>= 0.2.3-4), libc6 (>= 2.3.2.ds1-4), libesd0 (>= 0.2.29-1) | libesd-alsa0 (>= 0.2.29-1), libfam0c102, libgcc1 (>= 1:3.3.4-1), libglib2.0-0 (>= 2.4.1), libice6 | xlibs (>> 4.1.0), libmad0 (>= 0.15.1b), libogg0 (>= 1.1.0), libpng12-0 (>= 1.2.5.0-4), libqt3c102-mt (>= 3:3
<Keybuk> .2.3-3), libsm6 | xlibs (>> 4.1.0), libstdc++5 (>= 1:3.3.4-1), libvorbis0a (>= 1.0.1), libvorbisfile3 (>= 1.0.1), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), libxrender1, libxt6 | xlibs (>> 4.1.0), zlib1g (>= 1:1.2.1), cdrecord (>= 4:2.0+a18-1), cdparanoia (>= 3a9.8), mkisofs (>= 1.10), kdelibs-data (>= 4:3.1.4-2), kdebase-bin
<spazzy> and the googlefight between totem-xine and totem-gstreamer ? :)
<Keybuk> that's a lot of stuff to drag in for just one app :p
<jdub> spazzy: we can't ship totem-xine by default due to legal issues.
<daniels> Keybuk: wow, impressive
<spazzy> arf
<spazzy> ok
<spazzy> Hoary will include bootsplash ?
<spazzy> did see on roadmap
<Kamion> not by that name
<daniels> usplash
<spazzy> didn't see on the roadmap
<spazzy> bootsplash not good ?
<Kamion> nope
<Kamion> it broke the installer when we tried to add it for warty
<Kamion> don't go there.
<daniels> god I hate the forum icons
<spazzy> ok
<sjoerd> jdub: if you can't ship totem-xine, you also can't ship gst-ffmpeg or ?
<daniels> like one of a BIG GREEN ARROW pointing to the post
<jdub> sjoerd: nup :)
<jdub> sjoerd: same issue
<daniels> what's the alternative?  a huge icon saying 'IGNORE THIS POST IT IS CRAP'?
<jdub> sjoerd: (same code...)
<spazzy> and last question sorry :)
<spazzy> why not integrated xmms or zinf ?
<spazzy> by default ?
<fabbione> ah ok
<fabbione> osp
<fabbione> ECHAN
<jdub> spazzy: rhythmbox
<daniels> today's sage advice: 'Removing ubuntu-desktop will not ruin your the default "setup" of the OS. It is basically just a list of applications that make the install easier.
<daniels> Its kind of like shopping .... you use the shopping list to help you get the food, but when your done putting all the food in your car after paying for it ... you don't need the list anymore. Or do you? Well ... I guess if you want to keep to the default shopping list! LOL'
<spazzy> jdub : yes 
<sjoerd> jdub: that's why i asked.. i'm curious about what debian is gonna do
<sjoerd> we'll see in due time :)
<elmo> jdub: btw, how's the polypaudio thing playuing out ?
<spazzy> thank you for the answer
<spazzy> great work you have done
<jdub> elmo: lennart's fixing lots of stuff.
<jdub> elmo: not sure atm
<spazzy> I hope xfce 4.2 arrives soon on Ubuntu :)
<jdub> elmo: have been playing with the possibility of jack+esound
<Keybuk> spazzy: it should be in universe?
<spazzy> 4.2 ??
<spazzy> nope
<Keybuk> is it in Debian?
<spazzy> nope
<spazzy> Paquet: xfce4
<spazzy> Version: 4.0.5-1
<spazzy> Priorit: optionnel
<spazzy> Section: universe/x11
<spazzy> Responsable: Martin Loschwitz <madkiss@debian.org>
<Keybuk> ah, well ... that's just a package we take from Debian, so until the Debian maintainers upload it there it won't turn up in Ubuntu
<spazzy> okidoki
<sid77> flashy
* Kamion uploads a now-hopefully-working debootstrap, and skedaddles to the theatre
<Kamion> I'll be back for a bit later on this evening
<daniels> have fun
<stratus> Where can i see at wiki the list with requested packages for hoary? Packages that are at 'universe', for example.
<lamont_r> stratus: universe is "everything else" - that is, things not on one of the lists
<stratus> lamont_r, i know but have you a page at the wiki with requested packages for hoary?
<lamont_r> stratus: wiki.ubuntu.com/HoaryHedgehog has links
<stratus> lamont_r, thanks
<thom> lamont_r: please can you sign glibc on crested? :-)
<lamont_r> thom: gah
<spazzy> there isn't a rescue mode on the cd, it would be great 
* lamont_r goes to fix the &%)^* mail config...
<thom> lamont_r: i've fixed the mail config now 
<spazzy> I have to make mkboot to rescue 
<thom> did so this morning
<daniels> lamont_r: how are you enjoying the xorg builds?  now with 2192-char Binary lines
<lamont_r> thom: wanna fix king too, and see if yellow is configured at all?
<daniels> anyway, I'm sure someone said something about fresh air and stuff
<lamont_r> thom: done
<thom> king is fixed, yellow isn't configured at all
* daniels -> fresh air, food, walking around, hotel, iced tea, generally other things that are not X code which is sort of starting to make my eyes BLEED LIKE HELL, really
<lamont_r> daniels: ubuntu doesn't care
<lamont_r> thom: uploaded
<thom> danke
<elmo> lol - #280632
<infinity> I question his assertion that is works in /usr/bin/ and /tmp...
<infinity> But I love the example in ~ :)
<infinity> elmo : He's filed two of those.  #280491
<mdz> morning
<tim1> good evening
<amu> hi mdz 
<mdz> thom: here?
<thom> mdz: mostly packing, but yeah
<mdz> thom: could you resurrect your earlier email about the hardware database and send a copy to ubuntu-devel to start a proper discussion about the hardware database?
<thom> mdz: it's already been linked in the thread, but sure
<elmo> why does gnome-cups-icon take so much damn CPU time, and can I kill the damn thing?
<mdz>     !!uri
<mdz> PANIC: exiting on botched invariant
* mdz pummels arch
<mdz> Keybuk: do you know the translation for that one?
<Keybuk> what was the command?
<mdz> Keybuk: make-archive
<thom> isn't that arch's default "something bwoke" message?
<mdz> tla make-archive apt@packages.debian.org--apt apt@packages.debian.org--apt
<mdz> aha
<mdz> apparently that's arch-speak for "I want the location parameter to be a fully-qualified path"
<mdz> changing that last bit to `pwd`/... works
<Keybuk> yeah
<thom> heh
<Keybuk> "not not a url"
<jdub> mdz: s/arch/tla/
<mdz> jdub: are you saying it's fixed in baz?
<jdub> mdz: being fixed in baz, yeah
<mdz> who's packaging baz for hoary, btw?
<jdub> no one atm
<jdub> there's a per-checkin repo
<jdub> but no point doing a package until 1.0, according to lifeless
<mjg59> I'm getting insufficient ACPI feedback love
<jdub> I LOVE ACPI
<Keybuk> jdub: dude, fix -changes
<jdub> although my suspend button doesn't always work
<jdub> Keybuk: see discussion elsewhere
<Keybuk> jdub: nutwits keep mailing it
<mjg59> jdub: Man, if you don't tell me these things, how am I supposed to increase your love quota?
<jdub> look at your other tab
<jdub> mjg59: but i just did!
<mjg59> It doesn't always work
<jdub> so you know how before, it didn't work with acpid running?
* lamont2 screams at acpi
<mjg59> Haha
<lamont2> fabbione? 
<lamont2> mjg59>?
<lamont2> help!
<elmo> if we manage to release hoary without baz, we should just all give up and go home
<mjg59> lamont: Hello
<lamont2> I close the lid, wait 10-20 minutes, and it won't unblank
<lamont2> the other vt's all work just fine.
<thom> elmo: dunno about you, but i'm already at home
<elmo> err, well, the "go home" part doesn't really work, but YKWM
<jdub> mjg59: now it doesn't even have an acpi event when acpid is not running
<jdub> elmo: we'll have baz in hoary
<jdub> elmo: 1.0 is very soon
<mjg59> jdub: Hmm. If you rmmod button and then modprobe button, does it start generating events?
<jdub> sudo rmmod button just hung
<mjg59> lamont2: That's very, very odd
<mjg59> jdub: Bong
<jdub> 16366 pts/2    D+     0:00  |               |   \_ rmmod button
<mjg59> jdub: Anything in dmesg?
<jdub> no, just more usb noise
<mjg59> Gar
<jdub> Buffer I/O error on device uba, logical block 0
<jdub>  unable to read partition table
<mjg59> I suspect some sort of interrupt or timing issue
<mjg59> If you reboot the machine, do you get button events again?
<jdub> oh man
<jdub> :)
<mjg59> lamont2: When did this start?
<lamont2> mjg59: has always been the case
<mjg59> Weird.
<lamont2> acpid processes the lid open event, but screen stays blank
<mjg59> What sort of hardware?
<mjg59> lamont2: If you comment out the xscreensaver calls in /etc/acpi/lid.sh, does it stop misbehaving?
<lamont2> sony vaio pcg-fxa53
<lamont2> mjg59: I'll comment them out now and see what happens the next time I accidentally leave the lid closed too long. :-)
<lamont2> currently the only known recovery is ctl-alt-backspace, which is a little bit annoying
* lamont2 bounces
<jdub> mjg59: works fine after a reboot
<jdub> mjg59: btw, on resuming, the lcd-dying-glow started happening, until it switched to X
<jdub> back soon
<amu> Sun released a live CD of Java Desktop System
<mdz> amu: interesting, URL?
<amu> it's a morphix ;) 
<mjg59> jdub: Yeah, it will do
<amu> mdz: http://www.osnews.com/
<sivang> hmm..printing doesn't work on hoary? seems the gui cups admin in gnome is badly unresponsive...
<amu> mdz: download need the hole day :) now i got it ..  
<Mithrandir> amu: they had one of those a long time ago as well, didn't they?
<jdub> yeah, they have
<amu> Mithrandir: yap, still the same.... 
<Mithrandir> well, then it's nothing interesting.  Nothin java about it.
<Keybuk> mdz: no luck with apt-rpm
<Keybuk> cvs [login aborted] : connect to cvs.conectiva.com.br(200.140.247.68):2401 failed: Connection refused
<mvo_> Keybuk: IIRC they  have a svn repository
<amu> Mithrandir: just loopmounted the iso, and i saw its a knoppixlike :) 
<Keybuk> mvo_: it starts off from half way through the development
<Keybuk> they never imported the CVS history into it, fwict
<mvo_> Keybuk: I can talk to the apt-rpm maintainer about it if it's importend
<amu> Mithrandir: suse is the only one, who think before they do something. It's also a with cloop, but the boot and startprozess much more better than the knoppix isos
<mdz> Keybuk: gah
<mdz> Keybuk: so they killed the cvs repository and started svn from scratch, not using cvs2svn or whatever?
<elmo> aiee.  it's so so wrong that modern emacs can do inline images
<mdz> mvo_: if you could try to get a tarball of the CVS repository, that would be incredibly helpful
<Keybuk> mdz: *looks* like it
<mvo_> mdz: sure, I will ask gustavo. is it to import the stuff into an arch branch?
<mdz> mvo_: it is to get the change history in order to merge some stuff and bring the forks closer
<mdz> we need to be able to go all the way back to where they forked from Debian
<ChrisH> btw, is arch a lot different than svn?
<mdz> yes
<mvo_> mdz: I ask him
<Keybuk> notably http://cvs.conectiva.com.br/ thinks it's a mailman server now :p
<Keybuk> mdz: yeah, confirmed; they just imported the upstream APT into SVN and then imported their CVS HEAD over the top of it
<Keybuk> no history there
<mdz> GAH
<mdz> corrupt pristine (failed inode signature validation)
<Keybuk> nuke it
<mdz> it should not even be looking in that directory
<mdz> it is complaining about an archive in some subdirectory of my cwd
<Keybuk> oh, arch goes wandering across your filesystem looking for pristine trees :p
<mdz> this was a tla tag command
<mdz> did it fail?
<Keybuk> yup
<mdz> one never knows with arch
<Keybuk> I've often wondered whether it climbs back up the filesystem, and if so whether it'd steal other user's pristines
<Keybuk> descent pyarch% tla missing -Dscf $(<{arch}/+upstream)
<Keybuk> ^ I swear, some of the "every day" tla commands are obscene
<Keybuk> if I get RSI, I'm sueing Tom Lord
<mvo_> gustavo is looking for the old repository now. let's hope he finds it :)
<mdz> mvo_: great, thanks
<mvo_> n
<mvo_> np
<mvo_> :)
<carlos> jdub: polypaudio is doing bad things
<carlos> jdub: I'm getting noise instead of the "normal" sounds
<jdub> has it eaten anyone yet?
<carlos> yes, my event sounds :-)
<jdub> :)
<jdub> weird, haven't seen that before
<carlos> until today, it just stop playing sounds
<carlos> but today instead of that it makes sounds
<carlos> like the doom ones :-P
<jdub> if you want to ping lennart about it, that'd be cool - we're still not officially committing to it yet :)
<carlos> it's not a joke
<carlos> jdub: ok
<carlos> jdub: will do this weekend, too busy now. Thanks
<carlos> I'm too used to jabber...
<carlos> grr
<jdub> heh
<mdz> Keybuk: http://chinstrap/~mdz/cvsballs/apt-rpm.tar.bz2
<mdz> Keybuk: courtesy of gustavo via mvo
<Keybuk> exxxxcellent
<Keybuk> 2002.07.23.18.00.00 ... looks like the branch point :p
<Keybuk> isn't CVS's "give me the base of the branch" feature GREAT
<Keybuk> because -r1.1 is bad, precious
<mdz> isn't the "give me the base of the branch" "feature" equivalent to "decode the RCS version number"? :-)
<Keybuk> not if you want to checkout trunk as it was imported
<Keybuk> -r1.1 will give you every single file at it's first revision
<Keybuk> including those added later
<mdz> ah
<Keybuk> so you have to grep through the ,v files and find a time which was after the initial import, but before the first change ... then check that out with -D
<mdz> so which arch changeset does 2002.07.23.18.00.00 correspond to?
<Keybuk> dunno yet
<Keybuk> that's the "difficult" bit <g>
<mdz> if the answer is "none", do we cry?
<Mithrandir> Keybuk: you can't know for sure that -r1.1 exists for all files, even. :)
<Keybuk> still waiting for rookery to checkout 1,303 revisions
<mdz> I don't suppose tla has a handy "checkout relative to <this> and use hardlinks where nothing changed" feature
<mdz> oh, it does have "hardlink to revision library" though
<Keybuk> I've often wondered whether that takes into account permission changes
<Keybuk> ie. will it break the hardlink if the permissions change?
* Keybuk suspects not
<Keybuk> and that might explain why I have so many random permission fiddles when using tla
<daniels> mdz: yo, dude
<rcaskey_> daniels: mucho thanks for beating xorg into shape
* daniels stares.  Someone replied to his ubuntu-announce X.Org mail with just the headers, and list signature.
<daniels> rcaskey_: no worries -- props to fabbione also
<daniels> ah, that's what I wanted to ask you
<rcaskey_> it enabled a luser like me to compile eye candy that crawls my system to a crawl, for that a sincere thank you
<rcaskey_> compmgr is very fun with built in i810 video
<daniels> (yeah, I have an i855)
<lamont_r> mjg59: should I uncomment the -unthrottle as well?
<lamont_r> er, comment that is.
<lamont_r> mjg59: hrm.. should proc/acpi/ac_adapter/*/state say off-line, despite the fact that the power is plugged in?
<daniels> lamont_r: no
<mjg59> lamont_r: No, but that's not unusual
<lamont_r> acpi
<lamont_r>      Battery 1: charging, 100%, charging at zero rate - will never fully charge.
<lamont_r> lamont@rover3:~ $ cat /proc/acpi/ac_adapter/*/state
<lamont_r> state:                   off-line
<rcaskey_> Are the bottlenecks mostly composite bottlenecks?
<lamont_r> which basically means that lid.sh is not unthrottling...
<mjg59> lamont_r: Ah
<mjg59> lamont_r: Is that the stock Warty kernel?
<lamont_r> OTOH, doing that manually from another vt doesn't tend to unstick things
<lamont_r> mjg59: stock warty everything
<lamont_r> it even has ubuntu-desktop installed. :-)
<Keybuk> mdz: oh, man!
<mjg59> lamont_r: Might be worth trying my test kernel
<lamont_r> ok.
<mdz> Keybuk: hmm?
<Keybuk> descent arch-test% ls -l foo
<Keybuk> -rwxrwxr-x    1 scott    scott          25 2004-11-10 19:51 foo*
<Keybuk> descent arch-test% tla changes
<Keybuk> * looking for scott@netsplit.com--test/test--test--0--patch-2 to compare with
<Keybuk> * comparing to scott@netsplit.com--test/test--test--0--patch-2
<Keybuk> -- 
<Keybuk> foo is executable, and there's no local changes
<Keybuk> but, wait!
* mdz waits for the punchline
<Keybuk> descent scott% tla get scott@netsplit.com--test/test--test--0
<Keybuk> * ensuring library has scott@netsplit.com--test/test--test--0--patch-2
<Keybuk> * from revision library: scott@netsplit.com--test/test--test--0--patch-2
<Keybuk> * tree version set scott@netsplit.com--test/test--test--0
<Keybuk> descent scott% ls -l test--test--0--patch-2/foo
<Keybuk> -rw-rw-r--    1 scott    scott          25 2004-11-10 19:56 test--test--0--patch-2/foo
<mdz> how did you arrive at that state?
<mdz> rookery certainly seems to be enjoying itself
<Keybuk> init-tree, import, changes, touch foo, add foo, commit, changes, chmod +x foo, commit
<Keybuk> ie. just made sure at each step of the way that I had it in my revision library
<mdz> Keybuk: you shouldn't need to checkout _all_ 13xx revisions; we know that conectiva branched sometime before 0.5.5
<mdz> <=0.5.5, that is
<Keybuk> the changes is probably redundant, because commit would've done the equivalent anyway
<mdz> how do I cherry-pick changes with tla?  replay?
<Mithrandir> mdz: star-merge?
<mdz> Mithrandir: won't that get me everything that came before?
<Mithrandir> I thought not, not if you specify the patch
<Keybuk> replay
<Keybuk> replay blah@blah--blah--blah--patch-999
<Keybuk> will just apply that one patch
<mdz> thanks
<mdz> hmm
<mdz> mvo__: I got conflicts in merging your patch-3
<daniels> mdz: yah, replay usage for cherrypicking is on ArchCheatSheet IIRC
<mdz> my understanding of tla conflict handling is that now I get to SUFFER
<mvo__> mdz: sorry for that
<daniels> mdz: s/conflict handling // and you're starting to get somewhere
<mdz> mvo__: I don't understand why
<mvo__> mdz: in what files?
<mdz> that changeset should only have 0.5.27->0.5.27.1, no?
<mdz> mvo__: debian/rules
<mvo__> could it be the "dh_installcron" I added?
<mdz> mvo__: why would that be part of patch-3?
<mdz> patch-3 seems to contain a ton of changes which were not part of 0.5.27->0.5.27-1
<mdz> er, .1
<mvo__> ah, ok. 
<mvo__> it was 0.5.26->0.5.27.1
<mvo__> tla was at 0.5.26 IIRC
<mdz> hmm, that's odd
<mdz> lifeless won't be up yet
<mdz> but that sounds like the import is not running
<mdz> there is much more in CVS beyond 0.5.26
<Keybuk> on the MAIN trunk?
<mdz> yes
<mdz> apt--MAIN--0 has up to 0.5.26
<mdz> but there was since a 0.5.27, and is a 0.5.28 in progress
<mdz> none of which is in arch
<mdz> it's as if it stopped syncing
<Keybuk> [DIR]  apt--MAIN--0/             20-Sep-2004 18:37    -   
<Keybuk> drwxrwsr-x   14 jgg      aptcvs       4096 Nov 10 13:15 apt
<Keybuk> yeah, looks like it
<daniels> culus commits to apt still?
<mdz> lifeless: when you wake up ^^^^
<mdz> daniels: no
<mdz> he owns the directory, though
<Keybuk> (file) sk.po 	(graph) 	  1.3 	 7 days 	 piefel 	 Updated Slovak from Peter Mann (Closes: #279481)
<Keybuk> (file) nl.po 	(graph) 	  1.13 	 12 days 	 piefel 	 Updated Dutch from Bart Cornelis (Closes: #278697)
<Keybuk> there's definitely updates since the 20th Sep
<Keybuk> 0.5.27 predates that though
<mdz> mvo__: one thing I had consisdered was that some folks might want to check for updates more than once per day
<mdz> e.g., security
<mvo__> elmo will not like a e.g. 4h cron job I guess
<Keybuk> mvo__: 4 hour cron jobs don't play well with anacron
<mvo__> mdz: but we can do it of course
<Keybuk> mdz: to me it looks like the APT Arch sync hasn't happened since mid-June
<Keybuk> which is odd, because we didn't even start them until August/September, heh
<mdz> mvo__: do you know how frequently the RH tool checks for updates?
<mvo__> mdz: no, but I can find out :)
<mvo__> mdz: the suse default seems to once per night
<mdz> mvo__: I suppose once/day is sufficient, and we can give them a "check now" menu option if they want to check immediately
<mvo__> mdz: agreed
<mdz> mvo__: I sent you email with a few small changes
<mvo__> mdz: thanks!
<Keybuk> mdz: btw, can I reopen the question of anacron for hoary?
<mdz> mvo__: I think there is a wishlist bug open against apt for this, if you can find it we can close it :-)
<mdz> Keybuk: sure, ubuntu-devel@
<mvo__> mdz: :)
<Keybuk> * Checking patch-1071
<Keybuk>   - Fuzzy match (6)
<Keybuk> that looks the absolute closest
<Keybuk> (for apt-progeny)
<mdz> Keybuk: what's the fuzz?
<Keybuk> apt-progeny apt--MAIN--0--patch-1071 (fuzzy 6)
<Keybuk> that's the only result for that one
<Keybuk> >>> (changed, new, gone, moved) = dirsums.diff(arch_sums, dir_sums)
<Keybuk> >>> new
<Keybuk> ['doc/fr/manpage.refs', 'doc/manpage.links', 'doc/manpage.log', 'doc/manpage.refs', 'doc/pt_BR/manpage.refs', 'doogie.txt'] 
<elmo> mvo: checking for updates is pretty cheap
* Keybuk fumes quietly
<Keybuk> must...not...agree...with...lifeless
<Keybuk> / $Id: acquire-item.cc,v 1.1 2002/07/23 17:54:50 niemeyer Exp $
<mvo__> elmo: so we could do a "apt-get update" every say 4h ?
<Keybuk> mvo__: why that regularly?  once a day sounds sufficient to me
<elmo> mvo: I think the servers could cope, yeah
<elmo> just don't GMT the crontab :)
<Keybuk> where's jackass gone?  oh, right, UPDATE TIME!
<Keybuk> mvo__: every 4 hours just sounds a bit "... MUST!HAVE(*$UPDATES!*$*OH YEAH! ..."
<Keybuk> and would be deadly for people on reduced bandwidth, like a modem or GPRS laptop users
<mvo__> Keybuk: totally agreed 
* Keybuk votes for cron.daily
<elmo> keybuk: heh, GPRS laptop users, i.e. you and the other two ;P
<Keybuk> and an "Update Now" button for the obsessed
<Keybuk> elmo: heh, it works pretty well :p
<mvo__> Keybuk: the update intervall is a config option anyway
<Keybuk> mvo__: how does it do it?
<mvo__> Keybuk: it basicly write a "stamp" file that is checked then
<Keybuk> you need to be root to run apt-get update ... so how do you elevate ?
<mvo__> Keybuk: the cron-job will be part of apt and run as root
<mvo__> for the "update now", we will run it with gksudo
<Keybuk> right ... can we not have an ordinary cron job please?
<Keybuk> unless it checks on_ac_power
<mvo__> Keybuk: you think "apt-get update" takes too much power?
<Keybuk> mvo__: it'll spin all the disks up
<Keybuk> so yes
<Keybuk> "all the disks", heh
<Keybuk> "the disk"
<mvo__> is there a easy way to find out if we are on power? 
<jdub> RAID-5 in your HP? :)
<Keybuk> on_ac_power
<Keybuk> I'm assuming we're shipping this with "off" as the default anyway?
<mvo__> Keybuk: correct
<mvo__> unless you install "upgrade-notifer" that turns it into "once per day"
<mvo__> I'll add the "on_ac_power" check
<jdub> jdub@lazarus:~ $ on_ac_power
<jdub> jdub@lazarus:~ $ echo $?
<jdub> 255
<jdub> ^ expected result on a desktop machine?
<mvo__> jdub: same here :)
<Keybuk> jdub: yeah, you check $? -eq 1 for a laptop on battery
<Keybuk> cf. /etc/init.d/anacron
<daniels> on_ac_power returns 1 on my batteried x40
<jdub> Keybuk: nice
<Keybuk> mvo__: I still vote for just sticking it in cron.daily personally
<mvo__> Keybuk: that's the current plan
<mvo__> I was just asking for opionions for the alternatives :)
<Keybuk> that way it'll be deferred correctly if laptop users have anacron installed
<mvo__> out of curiosity, does cron.hourly behave sane too?
<Keybuk> no
<jdub> do we run anacron on acpi ac plugin events?
<Keybuk> jdub: anacron isn't in main, cf. ubuntu-devel
<jdub> yeah
<Keybuk> mdz has a wishy-washy dislike for it *ducks&runs* :p
<jdub> mean does anacron
<Keybuk> jdub: it adds an /etc/apm/event.d thing, not ACPI
<Keybuk> thom could add -x /usr/sbin/anacron && /etc/init.d/anacron stop/start thing to acpi-support though
<jdub> so when i plug in, upgrade-notifier should say "you have updates, powered one!"
<Keybuk> jdub: yup
<Keybuk> mvo__: is the notification icon going to sit in the panel being annoying, or just appear when there are updates?
<mvo__> it will only appear if updates are available
<mvo__> and vanish once you installed them
<Keybuk> nice
<Keybuk> can it download the .debs and put them in /var/cache/apt/archives while it waits for you to get around to clicking it? :p
<mvo__> yes, it's pretty nice I think. it listens to dbus events and will update it's status if it gets them
<thom> it's actually a _notification_ *shock*
<thom> but yes, only running anacron when on battery would seem reasonable
<daniels> heh.  having local xorg debs does you wonders: Need to get 15.5MB/174MB of archives.
<mdz> Keybuk: looks like a CVS vs. tarball diff
<elmo> what's the equivalent of .xinitrc for a gnome session ?
<mdz> Keybuk: (apt)
<mdz> elmo: ~/.gnome2/session
<mdz> computer->desktop preferences->sessions is the preferred way to edit it
<lamont_r> libxklavier...  missing build-deps, sadly
<elmo> mdz: mmk
<lamont_r> elmo: is the unknown section stuff something that I could help figure out?
<thom> mdz: thanks for doing the initial ZDHW wiki page
<elmo> LOL
<elmo> if you move the top panel to the right, you get fist-size super-blurry icons
<thom> yes
<thom> it's a FEATCHUR
<daniels> heh
<elmo> lamont: not really - I know what it is - I'll have another ago in a bit - I just need to finish migrating my desktop to gnome proper
<daniels> 'yeah, a Big Mac meal thanks' 'would you like small, large, or FIST?'
<lamont_r> elmo: I know that productivity bump too well - wasn't too long ago that I did it myself... :-(
<elmo> so.. I really don't want to give up gkrellm.. is there anyway to integrate this thing somehow?
<mdz> there are various applets which should fulfill the same basic control freak needs
<mjg59> thom: Uh, only running anacron when on battery?
<elmo> mdz: nah I've tried them on my laptop - they suck
<elmo> but then the laptop doesn't have the res to justify gkrellm over them
<thom> um, um. i know what i mean :-)
<thom> mjg59: ^
<daniels> mjg59: by the way, have you ever noticed how insanely, stupidly, slow mode switches are on i810?
<mjg59> daniels: Video mode switches? Nope.
<daniels> mjg59: when I start another Xorg instance (with -novtswitch, mind), changing over to the other VT takes a good seven seconds
<daniels> mjg59: and about five seconds for subsequent switches
<daniels> mjg59: that's same res/depth
<mjg59> How long from X to console?
<lamont_r> elmo: gkrellm looks cool.. thanks for mentioning it.
<daniels> mdz: AH! that was it
<daniels> mdz: would you be happy with a default dhclient policy of 'don't set a hostname'?
<daniels> mdz: (or, 'leave the hostname alone')
<mdz> Keybuk: so is that all that lifeless will need to set up the import?
<mjg59> It's damn cold here tonight
<daniels> mdz: i'm currently unsure whether ?dms will survive a hostname change (the authentication stuff on that side of the world is crack, planning to go test by fire when I get kicked out here in 10min), so that would allow us to start gdm before dhclient fo'sho
<lamont_r> daniels: ew!
<daniels> lamont_r: *shrug*, getting hostnames via DHCP in anything other than the initial setup is crack anyway imo
<lamont_r> daniels: what you need isa 'change my hostname' event for X, eh?
<daniels> lamont_r: ha ha
<lamont_r> daniels: true - and really should be trying to give dhcp a hostname
<daniels> lamont_r: oh man
<daniels> lamont_r: as in, killall Xorg && Xorg?
<mdz> daniels: hmm, I didn't even remember that it would do that
<mdz> daniels: yes, I think it's sane to default to leaving it alone
<Keybuk> mdz: for apt-progeny, yes ... if he starts it there and imports following all the hundreds of copies they did, it'll go in
<daniels> mdz: ill, thanks
<lamont_r> daniels: no, no.  without killing - just "fix everything" :)
<daniels> mdz: i'll give it a going over tonight
<Keybuk> mdz: apt-rpm will come up shortly, once sed has finished stripping all the $Id...$ from everything :p
<Keybuk> rookery is my bitch <g>
<lamont_r> Keybuk: so that's why it's been dog slow lately.
<daniels> lamont_r: sure, but when I emerge, you can buy me a beer, because I'll be of legal drinking age in the US
<lamont_r> heh
<daniels> mdz: -novtswitch is done, btw
<lamont_r> that's what, 6 years from now? :-)
<daniels> mdz: oh wait, I already told you
<daniels> lamont_r: ease up ;) half that
<lamont_r> lol
<Kosai> Hm.  Any plans for a PPC live CD?
<thom> we'd love one. thanks ;-) 
<daniels> thom: triple play!
<lamont_r> bbl
<sjoerd> daniels: with the latest xorg debs, using usefb = false and usefwpll = true works
<mdz> thom: when are you coming through LA, again?  do you want to send me a copy of your itinerary?
<thom> mdz: sure, will ping it you now
<thom> i think you're out of la for most of the time i'm there, but lets see :-)
<lifeless> mdz: pong
<lifeless> ah, apt syncing, let me look into that right now.
<thom> mdz: biff
<elmo> thom/mdz: mozilla-firefox-locale-es has been removed in debian - ok to remove it from hoary/main ?
<thom> elmo: seems reasonable to me
<mdz> elmo: yeah, update the seed as well
<elmo> mdz: gar, fascist
<mdz> elmo: pinko
<elmo> oh, well, I guess I can repropose all the the stuff I'm still using from universe
<thom> elmo: just don't get ideas about whacky GREEN TERMINALS, retro boy! ;-)
<elmo> thom: meh, you're just jealous of my hardcore old skool skillz
<thom> old skool rapping skillz, maybe
<bob2> MC ELMO
<thom> shoutin' out to the L3 massive!
<elmo> thom: I'm pretty sure those guys in the cage next to us are entirely convinced I'm insane - esp. when I really did start shouting at and physically abusing that broken green cat5 the other week
<thom> elmo: yeah, we do get some massively funny looks when they have sun engineers in the house
#ubuntu-devel 2005-11-21
<slomo> BenC: you can get an updated libraw1394 here: http://slomosnail.de/~slomo/temp/
<sladen> does anyone have access to wiki backups from 2 weeks ago (or shell access to the webserver)
<sladen> trying to get back the laptoptestingtemplate that somebody deleted and then overwrote
<Riddell> whiprush_: for fridge's in the news section http://business.bostonherald.com/technologyNews/view.bg?articleid=112160&format=text
<mdke> sladen, henrik has access to them. failing that, the admins
<whiprush_> Riddell: on it!
<mdke> whiprush is a fridge machine
<Riddell> whiprush_: also Kubuntu came third here if you havn't seen it http://www.linux-community.de/Neues/story?storyid=18337
<whiprush_> okey
<Riddell> and Mark got the "Outstanding contribution tons of Linux/open SOURCE"
<whiprush_> wow, that last link is awesome.
<whiprush_> gonna ask silbs about a press release though.
<whiprush_> I think they prefer the press release to accompany a story
<mvo> whiprush_: thanks for your blog entry on gdebi!
<whiprush_> mvo: yeah it's rocking so far, worked on everything but skype, but that's because their .deb depends on something not in the archive anymore.
<whiprush_> opera and gizmoproject .debs worked.
<mvo> whiprush_: rock, it figured all the dependencies right and installed them? *nice*
* mvo beams
<whiprush_> as far as I can tell
<mvo> whiprush_: well, if the stuff works and neither apt/synaptic/gdebi itself found any incosistencies in the cache it should be fine (gdebi will check the cache before and after the install)
<whiprush_> I haven't really put it in a complicated situation yet though.
<mvo>  you already tested two debs I haven't tested :) 
<whiprush_> maybe I'll post something in the forums, those people are all about third party debs.
<neuralis> mvo, gdebi seems like really cool technology, but i really, really hope we never ship with it enabled by default.
<mdke> yeah good idea for the forums
<mvo> sounds like a good idea, I got a request about a backport of the required changes in python-apt/vte. I will look into this tomorrow
<mdke> does it give an error if it can't find the dependencies?
<mvo> neuralis: you have security concerns?
<whiprush_> for sure it knows if the installed version is newer, which I thought was nice.
<mvo> mdke: yes, it will do dependency analyis before the install
<mdke> cool
<mvo> mdke: it will never break the apt cache (unless there is a bug in it of course), but it is pretty careful
<mdke> sounds good
<mdke> if we shipped it by default though, it might encourage people to install packages from outside the distribution and dodgy places like marillat or people's blogs.
<neuralis> mvo, yes, very much so. the fact we have such an enormous package repository gives us an amazing way out of the security hell of competing operating systems.
<neuralis> mdke, exactly.
<mdke> but it is a good tool to have
<mvo> people install all kinds of crazy things right now and complain that dpkg -i breaks things
<mvo> but I agree that security is a big issue here
<neuralis> mvo, it's a great tool, i just think it should not even be considered for shipping with a default install. mentioning it on the wiki means those users who care can find it easily, but those users who are tempted to just download a deb and double-click it don't get pwned.
<mvo> neuralis: I see your point. one issue we have is that we can't ship/distribute all software (think of skype or opera). shouldn't we offer it to users then to make the install of those easy?
<mdke> it's a difficult problem
<mdke> how to give users choice, and prevent them from breaking their systems?
<mdke> the age old problem ;)
<mvo> yeah :)
<neuralis> mvo, it's a cost/benefit thing. gracefully handling the special cases (skype, opera, etc) is not worth directly sacrificing this phenomenal advantage we have with being able to keep users' systems secure.
<neuralis> mvo, i agree we should find a good solution for the most common special cases - but i think we should never consider making a double-click deb install a reality.
<dholbach> users will always install the latest crack, i think it's rather a matter of "raising awareness" instead of "making it harder for them to 'do it'"
<mvo> neuralis: it will never be a simple double click, they will always have to enter their password and confirm the install with clicking on "Install"
<mdke> dholbach, totally agree
<mvo> but yeah, we shouldn't make it too easy
<magnon> daniel!
* mvo waves to magnon 
<magnon> hey
<daniels> 'morning dholbach
<dholbach_> hey daniels, magnon :)
<magnon> hello other daniel as well
<dholbach_> :)
* magnon makes dinner and prepares for some merging
<devint> Is it just me who's saying this, or is the i386 version of Ubuntu much more polished than the amd64 version?
<HrdwrBoB> no
<HrdwrBoB> it's the same
<devint> you would think so right?
<devint> however, i had several problems with the amd64 version, but the i386 -- everything works, it even detected my monitors maximum resolution correctly
<daniels> yes, resolution detection doesn't work properly on amd64 yet
<daniels> but, ironically, laptops are better supported
<devint> my network card works, when in amd64 it doesn't, the lilo install procedure works in debian-installer, when in amd64 it doesn't...just more polished, i must say
<HrdwrBoB> why are you using lilo
<devint> because grub takes over 2 minutes to get to the grub menu when you have both a SCSI hdd and IDE hdd installed
<devint> very annoying
<devint> and inescapable, i might add
<daniels> works fine for me, with sata and ide.  but this is a #ubuntu question rather than #ubuntu-devel.
<devint> that's assuming there's a workaround, correct?
<devint> because if the installer program doesn't recognize this by default, then it is most certainly an #ubuntu-devel question
<daniels> that's what it did out of the box; bug reports are for bugzilla.ubuntu.com, support questions are for #ubuntu, #ubuntu-devel is just for specific, detailed, development discussion
<dholbach> good night
<mvo> good night
<kbrooks> is making linux distros too easy ... dangerpis?
<kbrooks> dangerous
<kbrooks> referring to:
<wasabi> Yes. Users should not be trusted with computers. Obviously we should institution a world wide computer users licensing system.
<kbrooks> 'mvo neuralis: it will never be a simple double click, they will always have to enter their password and confirm the install with clicking on "Install"'
<mdke> erm
<mdke> wtf
<kbrooks> mdke: ?O
<mdz> infinity: ping
<infinity> mdz : pong.
<mdz> infinity: good morning.  I wanted to check with you regarding that VGA mode change for usplash etc.
<mdz> infinity: do you have those changes somewhere ready to go already?  they should go in quite early
<infinity> mdz : I'll need to shove the vga16fb change into Ben's next kernel upload.
<mdz> infinity: oh, it requires kernel changes? hmm
<infinity> And since there's another upload right around the corner for other reasons, I think It's reasonable to expect we can do it in a day or two, and get testing/exposure of the new mode by the weekend.
<infinity> mdz : Well, it requires changing the default mode for vga16fb, which (unlike other framebuffers) is hardcoded.
<mdz> infinity: can't we change the mode at runtime rather than changing the hardcoded default?
<infinity> mdz : Not with the driver as it currently stands.
<mdz> infinity: so it's not only the default mode, it's the *only* mode? ;-)
<infinity> Looks like it, yes.
<infinity> It would be reasonably trivial to make the module take arguments, but it certainly doesn't appear to right now.
* infinity goes to find some lunch, then will come back to blow up random VGA resiters on his girlfriend's computer.
<tseng> kinky
<BenC> mdz: ping
<mdz> BenC: pong
<BenC> mdz: I want to do something in the BTS to cleanout the old bug reports
<BenC> mdz: like mass NEEDSINFO for anything that hasn't had any activity in > 6 months, and give it 2 weeks before I close them
<BenC> s/BTS/bugzilla/
<mdz> I don't think assuming NEEDINFO in that case is safe
<BenC> NEEDSINFO meaning "tell me if it still applies to breezy"
<ogra> night all
<BenC> with a message in addition to the status change
<mdz> ok
<mdz> that should be mostly reasonable then
<mdz> you should be able to do that with an advanced search + "change several bugs at once"
<BenC> yeah, I just want to get it down to something manageable
<BenC> I really want a better handle on the bugs for dapper
<mpool> are breezy bugs being filed into malone now?
<Riddell> mpool: no, don't think so
<mpool> anywhere else?
<mpool> or just to the list?
<Riddell> bugzilla
<mpt> bugzilla until flag day
<zakame> flag day?
<mpt> A flag day is any day on which there is a large, non-interoperable change from one system or process to another
<zakame> ah
<mpool> rather like sweden changing which side of the road they drive on
<daniels> not so much a flag day as a sign day in that case
<daniels> haw haw
<mpool> the very definition of non-interoperable :)
<bmonty_laptop> elmo: are you familiar with the motu-tools that \sh wrote??
<Kinnison> Night all
<floam> how long does it usually take something to propagate to apt once it's source has been uploaded?
<spstarr_home> hmm, is there a wiki on how to build the debian/ubuntu installer for dapper? I wanna add FAI support bits
<daniels> the installer bits in dapper currently won't work at all, and dapper is very uninstallable anyway
<spstarr_home> hmm
<infinity> daniels : Pessimist.
<daniels> infinity: well, noting that d-i's merges aren't done yet, and zlib is allegedly uninstallable, along with other stuff :P
<mae> hrmm
<infinity> Picky, picky.
<infinity> Ouch, britney is angry.
<infinity> Oh, it's not as bad as it looks.
<infinity> Mostly libssl fallout.
<infinity> And assorted..
<daniels> ... ephemera.
<spstarr_home> well, I got it built, albeit a very rough installer
<spstarr_home> (source)
<spstarr_home> haha, the installer won't let me quit :)
<jianggw> what is the difference between ubuntu-devel and ubuntu-motu?
<daniels> -devel is for core development stuff, and generally pretty in-depth stuff
<daniels> motu will help you get involved and they're much better at showing you the ropes
<jianggw> http://www.ubuntulinux.org/community/processes/teams/ ,why can't I find a team named ubuntu-develop?isn't there such a team? 
<crimsun> no, there's no such team.
<crimsun> these are better asked in -motu probably
<jsgotangco> there's an lp core team though
<jianggw> https://launchpad.net/people/ubuntu-dev ,https://launchpad.net/people/ubuntu-core-dev/ ,I find two teams.why not list them in http://www.ubuntulinux.org/community/processes/teams/ ?
<crimsun> jianggw: because those two are more hierarchical than http://www.ubuntulinux.org/community/processes/teams/ shows
<jianggw> thanks.Is the leader of each team appointed by community council or self-appointed?
<jianggw>  http://ubuntuforums.org/attachment.php?attachmentid=3590&d=1132034495 is a structure chart of community drawn by me.Is it correct?Who can help me draw a better and correct one?
<jsgotangco> wow an org chart
<marilize> Burgundavia: ping
<Burgundavia> marilize, pong
<JaneW> who handles PHP?
<marilize> Burgundavia: we can send you CD's without covers.......
<Burgundavia> marilize, excellent. It was more a preliminary inquiry. If everything goes to plan, I will need several hundred for the dapper release
<infinity> JaneW : I do.
<marilize> Burgundavia: thats fine, at least we  know now we can do it..........but when you decide to do it, just give enought time when you order....
<Treenaks> morning all
<Burgundavia> marilize, if and when it happens, it will be well coordinated with malcolm and yourself
<JaneW> infinity: can I forward you an e-mail from a local guy here who sent a warning to all his users claiming PHP etc is all broken in breezy?
<marilize> Burgundavia:  great
<infinity> JaneW : Uhm, sure.  It's definitely not broken in breezy.
<JaneW> infinity: I found the e-mail a bit annoying myself...
<infinity> JaneW : I do have a security release to do, if that's what he's referring to, but it's for pretty non-critical stuff.
<infinity> (I should still do it rather soon, though)
<infinity> JaneW : If he thinks it's broken in other ways, I'd like to know what he's on about.  It works well for thousands of other users.
<infinity> JaneW : Wow, okay, that was just nonsensical.
<JaneW> infinity: yup
<infinity> Would you like me to respond to you, or to whim directly?
<infinity> s/whim/him/
<Burgundavia> infinity, the jump from php4 to 5, does it break many apps?
<infinity> Burgundavia : Pretty much none.
<infinity> Burgundavia : There's a very short README in the php5 doc directory about possible upgrade caveats, in practice almost nothing will break.
<JaneW> infinity:  feel free to respond to him - cc me though please
<Burgundavia> infinity, thanks
<infinity> JaneW : Sent.
<JaneW> infinity: thanks
<Burgundavia> JaneW, how did planner work out for you?
<Nafallo> elmo: please sync ttf2pt1 from unstable (ubuntu override okey)
<JaneW> Burgundavia: busy adding resorces right now, it looks nice, simple and straightforward. Thanks
<tepsipakki> argh, my kernel got the kubuntu usplash-image after upgrading to 2.6.15-2.2 ;)
<Nafallo> elmo: please sync ttt from unstable (ubuntu override okey)
<dholbach> good morning
<fabbione> tepsipakki: usplash is not managed by the kernel.
<fabbione> blame usplash
<siretart> fabbione: hi
<siretart> fabbione: do you have a minute?
<fabbione> siretart: hi, yeah
<siretart> fabbione: it is because of 2 binary packages, which are binary ALL (arch independent), but can only be built on sparc. is there any change to get them into ubuntu?
<fabbione> what's up?
<siretart> namly proll and openhackware
<fabbione> eh?
<siretart> yeah, quite annoying
<fabbione> arch: all means arch: all
<siretart> yes, I know
<fabbione> they must be able to build everywhere
<fabbione> if they don't it's a bug in the pkg
<siretart> but they are not
<siretart> I know
<siretart> but the debian maintainer disagrees
<fabbione> fix the pkg :)
<fabbione> who is the debian maintainer?
<siretart> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322300
<siretart> I'm searching for proll
<siretart> Maintainer for openhackware is Guillem Jover <guillem@debian.org>
<siretart> aah, and the thing about proll is, that it build-depends on sparc-utils, which is sparc only
<tfheen> siretart: the maintainer is wrong in the openhackware case at least.
<fabbione> dude...
<fabbione> read the stuff again
<fabbione> he is talking about ppc
<fabbione> a B-D on sparc-utils doesn't make it buildable on sparc
<siretart> oh, I'm sorry, I mixed up ppc and sparc
<fabbione> but clearly the maintainer is utterly wrong
<Treenaks> sppcarc ?
<siretart> fabbione: but a B-D on sparc-utils guarantees FTBFS on !sparc
<fabbione> siretart: how is the B-D specified?
<siretart> http://people.ubuntu.com/~lamont/buildLogs/p/proll/18-1/proll_18-1_20050607-1857-i386-failed.gz is the buildlog (short)
<fabbione> Build-Depends: sparc-utils [sparc]  ?
<siretart> Build-Depends-Indep: debhelper (>= 4.0.0), sparc-utils
<fabbione> siretart: in that case only our i386 would fail and you still don't care. it's a ppc only app with buggy pkg.
<fabbione> fix the pkg :)
<siretart> there are 2 packages. openhackware is ppc, right, I'll look deeper into that
<fabbione> siretart: read the last comment from Peter on the bug
<siretart> the other one is proll, which Build-Depends-Indep
* siretart rereads
<siretart> fabbione: yeah, he gives an analysis about the problem
<siretart> fabbione: I was rather asking about a short term solution for ubuntu. 
<fabbione> siretart: the correct solution is to make the pkgs Arch: ppc
<siretart> the problem here is, that qemu DEPENDS on both packages. I'm currently working around this in degrading the DEPENDS to a Recommends: field
<siretart> the Depend makes it obviously uninstallable on ALL arches in ubuntu
<siretart> fabbione: that would 'break' qemu
<fabbione> oh crack
<siretart> I agree that the correct solution would be to make the pkgs arch dependent, but the maintainers seem to disagree, because they want qemu to work
<siretart> morning Michael!
<fabbione> hold on
<fabbione> you mean qemu Depends: foo
<fabbione> where foo is this _all crack package?
<siretart> yeah
<fabbione> and i assume that package contain real ppc binaries
<fabbione> that can only be built on ppc
<mvo> good morning siretart !
<siretart> they contain ppc and sparc firmware, AFAIU
<siretart> binaries, in fact, yes
<fabbione> i miss something here
<fabbione> how can he build _all from both sparc AND ppc at the same time
<siretart> no
<pitti> Kamion: could you please promote the approved stuff on https://wiki.ubuntu.com/UbuntuMainInclusionQueue to help a couple of FTBFS?
<siretart> fabbione: openhackware is about ppc, proll is for sparc
<fabbione> ah ok
<siretart> both with a bit different, but similar problems
<fabbione> so same technique applied to 2 different pkgs
<siretart> fabbione: openhackware only builds on ppc, and proll B-D on a sparc only package
<fabbione> insane
<siretart> yeah, but I didn't invent that ;)
<dholbach> can anybody contact bugzilla?
<dholbach> ..ubuntu.com
<siretart> it happens to work on debian, because there maintainers are uploading binary packages
<fabbione> siretart: i think something like that will require buildd admins to build stuff manually
<fabbione> siretart: yes i know
<siretart> fabbione: okay, but you are the sparc buildd admin :)
<fabbione> siretart: i can probably do the sparc side of it, given that i can upload _all.deb (and i am not even sure)
<fabbione> but we need to discuss a more general solution for this
<siretart> okay. lets ask infinity then when he arrives
<fabbione> yeah
<fabbione> i need more coffee in the meanwhile
<siretart> same here :)
<siretart> dholbach: bugzilla.ubuntu.com works for me [tm] 
<dholbach> siretart: now it works for me... only terribly slow ... hrm
<siretart> dholbach: perhaps there are some malone import scripts shaking bugzilla?
<dholbach> siretart: no idea... but sounds like the perfect opportunity to take my dog out
<siretart> :)
<mvo> dholbach: have fun!
<sivang> Good morning all
<siretart> hi sivang 
<siretart> infinity: around?
<Nafallo> elmo: please sync tzc from unstable (ubuntu override okey)
<mvo> infinity: in one of the build-logs (i386) I noticed that lsb_release -i -s seems to have returnd "Debian". is this fixed?
<Mithrandir> Kamion: if you could ping me when you're around and have a little bit of time, I'd be grateful.  I need somebody to bounce cdebconf plugin stuff with.
<infinity> mvo : Can you be more specific?
<infinity> siretart : pong if it's something quick, if it's not, mail me.  I'm not actually working right now.
<mvo> infinity: I CCed you on a bugreport about the problem (#19632)
<siretart> infinity: okay, I'll ping you tomorrow. its not quick and important
<mvo> infinity: http://people.ubuntu.com/~lamont/buildLogs/s/synaptic/0.57.5.1ubuntu2/synaptic_0.57.5.1ubuntu2_20051114-1545-i386-successful.gz
<mvo> infinity: that is the bit with the "lsb_release" returns "Debian"
<infinity> mvo : And how can we tell this from the log? :)
<infinity> root@rothera:~# lsb_release -a
<infinity> No LSB modules are available.
<infinity> Distributor ID: Ubuntu
<infinity> Description:    Ubuntu (The Dapper Drake Release) Development Branch
<infinity> Release:        6.04
<infinity> Codename:       dapper
<infinity> That's the same buildd, same chroot, and same versions of lsb-release as before.
<mvo> infinity: hrm ... interessting (telling by looking at the cp 00list.Debian <- that name is derived from lsb_release)
<mvo> infinity: hm, same version everything? oh well, I'll dig into it and see if it's not me :/
<infinity> Keep me updated, but I don't see any obvious issues on this side.
<dhonn> we should have a bubble tip when you mouse over the gnome-panel.  Something like, right click here for more options
<seb128> elmo: glib2.0 sync please
<Nafallo> elmo: please sync uim ulogd from unstable (ubuntu override okey)
<siretart> seb128:  I read debian is going away from shipping schemas in /etc. Will we ubuntus follow that?
<seb128> siretart: we already do since hoary
<seb128> siretart: ls /usr/share/gconf/schemas/
<siretart> seb128: aah, so the remaining cruft in /etc/gconf/schemas is considered as buggy?
<seb128> siretart: not really buggy, it doesn't matter
<seb128> siretart: /etc/gconf/schemas files are not removed on update because they are conffiles
<dholbach> elmo: could you please sync mdbtools from sid, ubuntu override is ok
<siretart> seb128: aah, I see. thanks for heads up
<seb128> np
<seb128> the move is done by dh_gconf
<seb128> so it's automatical
* mvo reboots
<siretart> mdz: acpi-support in breezy Recommends: network-manager, which somewhat breaks automatic installations with universe enabled. Would you accept a package to breezy-updates, which removes the Suggest on 'network-manager'?
* seb128 guess it's not the right time to get a reply from mdz
<siretart> seb128: whats up with him?
<seb128> he's like middle of the night for his tz
<seb128> s/he/it/
<siretart> oh. I see
<siretart> which timezone is he?
<neuralis> siretart: he's in LA, which is -9 hours from you, i believe
<siretart> okay. thanks
<Nafallo> elmo: please sync plib from unstable (ubuntu override okey)
<Kamion> pitti: promotions in progress, thanks
<pitti> Kamion: nice; we need to update the wiki, did you promote all?
<Kamion> IN PROGRESS :-)
<Kamion> I'm updating the wiki as I go
<pitti> ah, cool; thanks
<Nafallo> elmo: please sync torch3 from unstable (ubuntu override okey)
<Kamion> pitti: ok, all done
<JaneW> who handles the menus in ubuntu and more specifically what is displayed in each i.e. app name vs function?
<Nafallo> morning Simira :-)
<dholbach> JaneW: it's handled in every software package itself
<JaneW> dholbach: I have a specific request to change for instance OOo impress -> Presentation and gedit -> Text Document
<Simira> morning
<JaneW> dholbach: with edubuntu we previously discussed making the menu entries more descriptive too because the app names are not very clear most of the time.
<JaneW> hi Simira 
<Kamion> that issue has been discussed back and forward for quite a while ...
<dholbach> JaneW: hm, traditionally the entry describes the function of the app, like "text editor" or "web browser"
<Simira> marilize: the letter worked out, somewhat. The only ultimate way to avoid the tax problems though, seems to be setting the total value less then 20 regardless of the amount of cd's.
<Simira> JaneW: good morning! How are you?
* mvo waves to the sword-fighting woman
<dholbach> JaneW: doko and Mithrandir maintain openoffice, seb128 and i do gedit
<seb128_> JaneW: gedit is a texteditor, "Text Editor" is correct, we are not going to change it :)
<Simira> :D mvo: wanna fight? ;)
<marilize> Simira: good, I'm glad it worked out :)
<Simira> wb JaneW :) How are you?
<Simira> marilize: I've written a "howto" for the Norwegians. Want to link to it from Shipit?
<jane_> Kamion: is there any agreement or will the status quo remain?
<seb128_> jane_: did you get what I said to JaneW about gedit?
<marilize> Simira: great thanx, you can send it...
<mvo> Simira: I would love to see a video or a live-demo someday :D
* doko thinks about putting a g into the OOo package name ...
<Simira> mvo: I don't have any of me. there's a couple on http://flammensorden.laiv.org though, by friends of mine.
<Simira> marilize: marilize@canonical?
<seb128_> doko: I've some menu changes for openoffice
<seb128_> doko: let me know when you have planned to do an upload
* mvo takes a loook
<marilize> simira: yes
<marilize> .com
<Simira> done
<dholbach> Simira: good to know that "bilder" is still "bilder" for me :)
<JaneW> seb128: no I was disconnected after : Kamion that issue has been discussed back and forward for quite a while ...
<JaneW> Simira: I am well thanks and you?
<doko> seb128: not before mid december
<Kamion> JaneW: it's at least in part a Mark thing
<pitti> Kamion: bah, seems that I forgot two small perl libraries to make the po4a chain work
<seb128_> doko: k, I'll have to do an upload so
<seb128_> doko: should I drop you a patch with my changes or something?
<Kamion> pitti: libxml-simple-perl for libparse-debianchangelog-perl
<Simira> JaneW: not too bad. Trying to get a lot of work done before the weekend. :-)
<Kamion> and libtie-ixhash-perl for that
<Simira> dholbach: that's good :-)
<pitti> Kamion: right
<pitti> Kamion: will do reports for them soon (gtk still needs to build anyway)
<Kamion> pitti: and libyaml-perl for libmodule-build-perl too ...
<ogra> Kamion, he wanted a drag and drop interface to assemble your own menus at the edubuntu summit ...
<doko> seb128: yes, file it as a report
<pitti> Kamion: btw, gnutls12 is a no-brainer - just a new version
<Kamion> pitti: ok, done
<ogra> JaneW, we never talked about renaming the apps, just grouping them different (while i agree that OOo impress should have a more descriptive name)
<\sh> re
<JaneW> ogra: hi, but I do thing the education menu needs descriptive names too, can we do that?
<ogra> JaneW, for the menus, yes, for the apps... i would object ...
<seb128_> JaneW: gedit is a texteditor, "Text Editor" is correct, we are not going to change it :)
<seb128_> (what I said before)
<ogra> there goes his alter ego :)
<tseng> i knew there were 2 of him
<ogra> heh...
<ogra> hi tseng 
<JaneW> seb128: yes I just looked at that, not sure what the user's issue is with that...
<tseng> hi
<JaneW> ogra: I am not sure I follow what you mean?
<\sh> looks like I need another job...to whom I have to send my CV? :)
<ogra> JaneW, we can rename and restructure menus, but not app names ...
<JaneW> ogra: sure that's all I want obviously the app name is the app name, but the menu item pointing to it should be descriptive
<seb128> there is some menu items that are not optimal and we can work with upstream to get them fixed though
<ogra> as we talked... having a task driven menu system for edubuntu with diffrerent profiles for different tasks ... 
<JaneW> ideally and providing there's enough space I am all for appname - function e.g. 'KTouch - Typing Tutor' etc
<kbrooks> \sh: :)
<seb128> JaneW: if you want to read the GNOME policy about this: http://developer.gnome.org/projects/gup/hig/2.0/desktop-integration.html#menu-item-names
<ogra> JaneW, if we can fix it upstream, thats fine, but i wouldnt start changing names for well known apps, its 1.) confusing and 2.) we could hire someone to just care for these changes all the time, it generates a lot of extra work
<JaneW> ogra: I think te menu groupings is another issue, which needs to be resolved too, the descriptions would be global to that and apply no matter what groupings/masks were chosen
<JaneW> seb128: thanks
<JaneW> ogra: so if I understand it correctly does the upstream decide how it will display in the menu on installation?
<seb128> you're welcome
<ogra> JaneW, currently menu profiles are easily doable with sabayon (thats its purpose)
* Nafallo sees the word "hire" ;-)
<Kamion> JaneW: at the moment (as I understand it) descriptions of individual menu items are stored in the relevant packages, not centrally (which is a good thing) and changes to them will apply to Ubuntu and Edubuntu so it needs to be carefully coordinated
<JaneW> Nafallo: down boy!
<ogra> lol
<Nafallo> :-)
<Kamion> JaneW: the upstream may or may not ship a .desktop file which includes the menu item name; the packager may override it, at the cost of having to redo all translations
<pef> hello
<JaneW> Kamion: oic, so if one particular app is confussing consistently we should approach the upstream and request that they make it easier to dechiper.
<ogra> exactly
<seb128> JaneW, Kamion: the name for a menu item is the "Name=" field of /usr/share/applications/<app>.desktop
<JaneW> ok
<\sh> Do we have a list of the "official visitors of UBZ" with names and email addresses? I just forgot to ask the impilinux guys for their email addresses
<tseng> I bet info@impilinux.co.za works. (http://impilinux.co.za/)
<JaneW> \sh: cvd could give it to you
<JaneW> \sh: although you may need to pay her, esp if you want to use the list to spam us all ;)
<dholbach> that's how ubuntu sustains itself: get mail adresses, sell them to spammers
<dholbach> :-p
<ogra> hey, cool idea ... we could make a universe package with addresses ;)
<neuralis> dholbach, and the launchpad "confirm email address" feature is just a cog in the conspiracy machine!
<dholbach> neuralis: you know it :)
<pitti> Kamion: ok, I finished the review and the reports, wiki updated
<Kamion> pitti: promoted, thanks
<sivang> ogra: maybe we could hack in a script, that  fetches source packages of pakcages we want to change from a db, scans the desktop files, reaplces the names through a lookup table, repackages the sources, and ready for duploads ? 0:-)
<sivang> hrm, s/we/you guys/ ;-)
<Kamion> sivang: and automatically translates all the changed names with artificial intelligence?
* sivang runs aways
<sivang> did I say anything ? :)
<Mithrandir> grmf.  We hatesss code duplication.
<Kamion> oh bugger, I have to update all the *-meta/update scripts
<janimo> Kamion, couldn't those use a common update script somehow, instead of being out of sync w/ eachother?
<janimo> build-dep on a package which has update
<slomo> elmo: please sync wavpack from debian... ubuntu changes can be dropped
<janimo> and only provide the derivative name as a param for it
<janimo> or something
<Kamion> janimo: I guess it could go in germinate
<Kamion> janimo: project for another day, though :)
<janimo> Kamion, when you have time to brief or mail me with what it takes for DYO iso building I am all ears :)
<Kamion> janimo: did I give you references to the code?
<janimo> no
<janimo> besides germinate whic I know about
<Kamion> ok, install the bazaar package
<janimo> not bzr?
<Kamion> not yet, no
<Kamion> I'll convert at some point
<janimo> I have both already anyways
<janimo> baz & bzr I mean
<Kamion> baz register-archive http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005
<Kamion> baz get colin.watson@canonical.com--2005/cdimage--mainline--0 cdimage
<Kamion> cd cdimage && baz build-config configs/devel
<Kamion> that should get you started
<Kamion> you'll need a complete local mirror
<janimo> complete as in 70Gb? :)
<janimo> which subset I need
<Kamion> for xubuntu, main+restricted+universe with whatever architectures you need
<Kamion> you can get away with only including the packages you want to put on the CD, if you feel like maintaining a mirror like that
<janimo> can I use apt-proxy or I need a full mirror frm the start?
<Kamion> you need it all locally from the start; you're going to end up downloading it all anyway
<janimo> oh joy, with 20Kbytes/ps
<Kamion> I guess you could run the requests for everything you need through apt-proxy to seed it
<Kamion> naturally you will need a somewhat well-connected host; I assume you weren't planning to serve CD images off a host with 20K/s anyway
<janimo> nope I was hoping someone else will do this :), butI'll see what I can do
<janimo> maybe do it and get someone to duplicate the steps on better linnked host
<Kamion> you'd need to teach a number of bits of that code about xubuntu; I'm happy to take those patches
<janimo> would it make sense to try getting xubuntu pkgs in main first?would that ease something?
<Kamion> that would make life a lot easier in general, yes
<janimo> do I need one wiki page/package for mainInclusionreport? They are most coming from same source with same security (lack of) background etc.
<Kamion> by the time that's done we *may* be able to reconsider building the images centrally, depending on what the load on cdimage and me looks like at that point
<janimo> oh that would be great
<Kamion> but I can't promise
<Kamion> you need one wiki page / report per source package, for tracking purposes
<Kamion> we need to be able to go back later and see "why did we add that anyway?"
<janimo> ok
<juliux> doko, dholbach ping
<dholbach> juliux: pong
<juliux> dholbach, do you have breezy cds?
<dholbach> juliux: no
<juliux> dholbach, do you know somebody in germany who can send us some to the linuxworldexpo in frankfurt?
<dholbach> juliux: http://www.murrayc.com/blog/permalink/2005/11/15/gnome-at-linuxworld-expo-frankfurt/
<juliux> dholbach, hehe there we get the cds from, there are no more cds
<juliux> dholbach, that is the problem
<dholbach> juliux: sorry, that's everybody i know who was provided with a big bunch of CDs in germany
<\sh> wooohoooo....
<\sh> 100 Ubuntu ShipIt CDs spread this morning at ISH HQ 
<\sh> two school classes were visiting us...70 people, age around 16-23...all Ubuntu Branded now 
<ogra> cool
<Riddell> ISH may be getting a few more support calls in future
<\sh> Riddell: no...I will#
<\sh> 30 people from NOC Monitoring are  Ubuntunized, too :) 
<\sh> I just had a presentation about ubuntu linux now...15 mins with 3 people here who were interested to replace their windows on their machines at home
<janimo> \sh, did orders from pre breezy get migrated or do  Ineed to place a shipping req with the LP id?
<\sh> janimo: no...I just placed a new order during pre-ordering period of breezy via the new ship it system
<janimo> thanks
<\sh> 200 still left...I have to check if we need more cds during the linux days in essen (3.-4. December)
<Mithrandir> Kamion: newt-plugin-detect-keyboard.so just built out-of-tree here. \o/  No idea if it works yet, though.
* Mithrandir goes to celebrate with a cup of tea.
<seb128> infinity, lamont-away, Kamion: could you give a retry to abiword build?
<seb128> elmo, Kamion: could you sync gtkmathview from Debian?
<Kamion> Mithrandir: cool
<Kamion> seb128: abiword> done
<Kamion> seb128: sync> s/, Kamion//
<seb128> Kamion: I've ", Kamion" because I've pinged elmo like 2 hours ago for a sync and doesn't work, and if we want to roll a CD this week better to not wait 4 hours for every single fix
<seb128> so if you can do it to speed up
<seb128> other way that's fine too, but that will be slower to get a installable state again to roll a CD
<Kamion> seb128: elmo asked me not to do it unless he was away very long-term, because it causes problems when he tries to get up to date again; so no
<seb128> Kamion: k, fine with me, thanks anyway
* mvo whines aobut bugzilla
<seb128> grumpf
<seb128> so
<seb128> with folder/a and dir/
<seb128> cp -a folder/a dir/
<seb128> creates a dir/a with Debian
<seb128> and breaks with dapper
<ogra> ugh
<seb128> which breaks GTK build
<dholbach> ouch
<ogra> that will break a lot more than GTK ...
<seb128> yeah
<Kamion> breaks how?
<seb128> dir/ is not a directory: No such file or directory
<seb128> cp: target dir/ is not a directory: No such file or directory
<seb128> grumpf
<doko> working outside a chroot?
<seb128> I've not tried with a chroot
<ogra> seb128, is your coreutils package up to date ? 
<seb128> GTK doesn't build on my dapper
<seb128> same source package build with a Debian experimental pbuilder
<Kamion> our coreutils is in sync with Debian unstable at the moment
<Kamion> is your Debian installation up to date?
<ogra> yes, but the package was updated yesterday ...
<Kamion> I know] 
<seb128> Kamion: ii  coreutils                5.2.1-2.1                The GNU core utilities
<seb128> is the pbuilder working
<seb128> (not update)
<Kamion> that's out of date
<ogra> 5.93 
<seb128> ii  coreutils                5.93-2                   The GNU core utilities
<seb128> is my box
<seb128> (breaking)
<Nafallo> elmo: please sync tla from unstable (ubuntu override okey)
<BenC> anyone here have the ipw2200 where it didn't work with 2.6.15-2.2, and also anyone with a USB atmel wireless?
<BenC> need 2.6.15-3.3 tested
<seb128> so
<seb128> cp -a folder/a dir/a works
<seb128> cp -a folder/a dir/a/ breaks
<seb128> and both work with previous coreutils
<Kamion> I think that's correct actually
<Kamion> at least arguably
<Kamion> a/ refers to the contents of an existing directory
<seb128> maybe, that still breaks working stuff
<seb128> ie: the GTK build :)
<Kamion> well, using dir/a/ to refer to a nonexistent directory is extremely confusing
<seb128> I agree and will fix the GTK package
<Kamion> it has different behaviour depending on whether you've created the directory yet ...
<seb128> yeah
<Mithrandir> Kamion: hmm, how would we know what plugin to depend on?  If we have the kbd-chooser, like today, it would have to depend on the right plugin (or maybe it could use anna-install) depending on the frontend.
<Kamion> Mithrandir: I think I'd been thinking of doing cdebconf-newt-detect-keys Provides: cdebconf-detect-keys Debconf-Frontend: newt, kbd-chooser Depends: cdebconf-detect-keys, and anna checks Debconf-Frontend:
<Kamion> or something like that
<Mithrandir> that'd work, yes.
<Kamion> pretty much the same way as we currently handle Kernel-Version:
<Kamion> janimo: at the very least it looks like I'm going to end up making *-meta/update use python modules from germinate ...
<janimo> Kamion, cool
<mvo> elmo: please sync guile-1.6 from debian (override ok)
<seb128> libcurl3 Depends on ca-certificates which is universe
<seb128> is somebody working on that?
<seb128> that makes openoffice2 and some other stuff uninstallable
<Kamion> Removed debconf from minimal-ia64
<Kamion> d'oh. this can't be right
<Kamion> ah, debootstrap, she is confused
<sbalneav> Morning all!
<ogra_> hey sbalneav 
<sbalneav> Hey there ogra_!
<sbalneav> How's it going?
<ogra_> fine ...
<sbalneav> We had about 60cm of snow here yesterday.  I was out with the snowblower, doing my driveway, and 5 other neighbors driveways.  My hands are swollen up today.  Makes it hard to type :(
<ogra> phew
<Treenaks> where is that?
<ogra> winnipeg 
<Treenaks> ah
<mvo> doko: around?
<doko> mvo: yes
<mvo> doko: I want to request a sync for jade, you made it use g++-3.4, debian is using 4.0. any special reason or can I go ahead with the sync?
<mvo> (it seems to build fine with g++-4.0)
<mvo> (#19209)
<ddaa> Hey, who's our official printer guru?
<mvo> ddaa: pitti AFAIK
<ddaa> mh... not here ATM
<mvo> ddaa: was the synaptic import successful (/me ducks)
<ddaa> The server is just too unreliable :(
<mvo> ddaa: right, thanks for keeping on trying. I'll probably ask for a tarball of the svn dir instead or something
<ddaa> Yes, getting a clone of svn repo on a stable host for the initial import would be a quick way of fixing the problem.
<ddaa> I could probably hack cscvs to be less picky though. But no time for that ATM.
<mvo> ddaa: thanks, I'll ask for a tarball then
* Kamion decides to split out a 'boot' seed; I'm tired of handling certain bits of minimal specially
<doko> mvo: yes, use 4.0 when possible
<ogra> Kamion, are there plans to rename the "server" CD option ? else i'd like to rename it at least for edubuntu ... its a bit confusing there
<mvo> elmo: please sync jade from debian (override ok)
<mvo> doko: thanks
<Kamion> hmm, no, maybe that won't work
<Kamion> ogra: not right now, no
<Kamion> ogra: feel free to suggest a different name for Edubuntu
<ogra> i will ... have to think about it ...
<ogra> "bare" or "core" probably ... lets see 
<mvo> elmo: please sync mpack from debian (override ok)
<mvo> "core" sounds good to me
<ddaa> Since pitti is not around. I'll ask my quick question here: is there a (vaguely) sane way of getting gutenprint-5.0.0-rc1 up and running on breezy, short of packaging it. Failing that, is it possible to get a specific chosen driver working? I tried "configure --with-cups --prefix /opt/gutenprint-5.0.0-rc1" but it still tries to overwrite (at least) one system file in /usr...
* mvo thinks that "bare" sounds like "naked". but that might be just me
<ogra> at least better than server for a distro that does a server install by default :)
<ddaa> also tried to just pick the ppd i needed, but that's obviously bogus and did not work.
<Kamion> ogra: 'custom' was the original name before Mark asked me to change it to improve server messaging
<Kamion> (i.e. because the "Ubuntu is just for desktops" meme was spreading too far)
<ogra> but "custom" sounds like i have to customize something ...
<Kamion> well, you probably do if you're just installing the base system
<ogra> true ...
<mvo> elmo: please sync ots from debian (override ok)
<BenC> anyone here ever experience the "k8 clock runs at double speed" bug?
<mvo> elmo: please sync opensp from debian (override ok)
<Nafallo> BenC: how to check it? :-)
<BenC> Nafallo: if your clock runs twice normal, then you have it (you'd know if you did)
<Nafallo> I don't :-)
* mvo has a k8, but hasn't noticed this problem yet
<BenC> my k8 Sempron laptop had it, but I don't have that laptop anymore
<BenC> just wondering if 2.6.15 fixes it
<ogra> mine shows 15:26 ... which should be right for my TZ
<BenC> it's real noticable
<BenC> you have to boot with noapictimer to get it to work right
<BenC> even pings twice a second
<Treenaks> BenC: did you get the "screenshot" pic correctly? :)
<BenC> Treenaks: yes, thanks
<BenC> haven't had a chance to look at it yet, just fixing the easy stuff and getting ppc to build so I can upload -3.3 today
<Treenaks> easy stuff like firmware? :)
<BenC> yeah, I got the ipw2200 fixed
* ddaa tries the obviously foolish thing of building the debian/testing package
<HiddenWolf> BenC, dude, do you sleep?
<mdz> siretart: the Recommends should be changed to a Suggests, and yes, that's fine for breezy-updates
<BenC> hidden: whem the computer is compiling, I sleep :)
<HiddenWolf> BenC, hah, ok. :)
<BenC> luckily I have a slow computer
<Nafallo> hehe
<Kamion> mdz: so, I'm doing a big shake-up of the *-meta/update scripts, in order to make them support a few new bits of syntax in the seeds which we need them to support now
<Kamion> mdz: (doing this by making them use germinate's python modules)
<mdz> Kamion: will you have them pull directly from bzr while you're there?
<mdz> ah
<mdz> what's the new syntax?
<Kamion> mdz: bzr> not yet, but I will eventually, yes
<Kamion> mdz: well, kind of old syntax actually, but "Languages: ar as at ..." / "language-pack-${Languages}"
<Kamion> mdz: in the process I ran smack into the weird way that linux-* and the bootloaders are handled in the minimal seed (because we don't want debootstrap to install them), and decided I didn't really want to hardcode the list of exceptions in yet another place
<Kamion> mdz: so I'm splitting out kernels and bootloaders from the minimal seed to a new 'boot' seed
<mdz> hmm, ok
<Kamion> that won't be installed by debootstrap, and ubuntu-minimal won't depend on it, but it will obviously end up on CD images
<Kamion> this was necessary because once we started using germinate to parse the seeds, germinate noticed that grub and yaboot in the live seed were duplicated from minimal, and ignored them
<Kamion> seems to work so far, although I haven't tried a CD image build in the new world order yet
<HiddenWolf> BenC, dare I ask why 2.6.15 is so troublesome?
<BenC> HiddenWolf: it's not really
<BenC> or are you having problems with it?
<Treenaks> BenC: he's scared of it now :)
<HiddenWolf> BenC, your changelogs made me cry of fear. :P
<mdz> BenC: you did write in the changelog "I know it's broken"
<BenC> that was just to alleviate all expectations of "perfect" :)
<BenC> the correct statement would have been "I don't expect this to work for everyone, so you shouldn't either"
<siretart> BenC: does the new 2.6.15 package have any expectations about the userland? (like udev from dapper or something like that)
<xhaker> it seems to work great.. shaved of 3 seconds at boot.. but is this 2.6.15 or 2.6.14? shouldn't 2.6.15 depend on udev 0.71 ?
<mdz> I don't think anyone has expectations of perfection, certainly not in dapper ;-)
<BenC> siretart: so far, it's working ok for me, except that pmount and stuff doesn't seem to want to believe that the cdrom is mounted and open it (like in gnome)
<xhaker> siretart, kinda my question too
<mdz> xhaker: I don't think so; I believe the reverse is true (newer udev will require 2.6.15)
<BenC> mdz is correct
<Nafallo> BenC: aha! that's the kernels fault.
* Nafallo just something to blame ;-)
<BenC> :P
<Nafallo> insert found on relevant place :-)
<BenC> the kernel did it's job and mounted it...gnome needs to handle it from there :P
<mdz> BenC: I get a corrupted vga16fb on my laptop with 2.6.15
<Treenaks> mdz: everyone did, I guess
<ogra> yup
<ddaa> well, it looks like it actually worked...
<BenC> usplash is broken for starters, but I've not been able to test vga16fb (except on a machine where it didn't work in breezy)
<ddaa> whoever's closest to the backport guys could mention that datum: gutenprint from debian/testing appears to be compatible with breezy
<BenC> using vesa I was able to get it working (vga=0x### on the kernel cmdline)
<xhaker> works here with vga too
<xhaker> my only gripe is i can't compile fglrx
<mdz> doko: what happened with hplip? it looks like your split to hplip-base was reverted
<BenC> mdz: I need to revisit vga16fb, we had some minor hacks in breezy for it to make it modular, it's possible I missed something
<ogra> xhaker, who needs 3D accel in development.... there is no time for playing anyway ;)
* BenC watches bugzilla choke down the mass bug changes
<doko> mdz: I'll have a look
<mdz> Mithrandir: see above regarding hplip; that was your merge?
<Mithrandir> mdz: yes, I thought it was split, then merged in d-i.  Sorry. :-(
<fabbione> BenC: i will probably need some help with -security for this release. There are some weird things going on
<xhaker> ogra, i don't even play.. it's just curiosity why it doesn't build
<Mithrandir> s/d-i/debian/
<fabbione> BenC: 
<ogra> xhaker, heh ..
<fabbione>   SYSMAP  .tmp_System.map
<fabbione> Inconsistent kallsyms data
<fabbione> Try setting CONFIG_KALLSYMS_EXTRA_PASS
<fabbione> i have seen that error once already
<fabbione> but i don't remember how we did fix it
<Mithrandir> mdz: I'll fix it.
<BenC> odd, add that config option
<mdz> Mithrandir: thanks
<BenC> it's a hack, but it will get the job done
<Mithrandir> mdz: (but I want to test this cdebconf stuff I'm working on fixed first)
<fabbione> BenC: yeah it does.. apparently :)
<fabbione> anyway i am out of here for today
<doko>  * Merge hplip-base and hplip packages.  Current upstream code makes it
<doko>       a losing battle to try to keep the two separate
<doko> mdz: ^^^
<fabbione> later guys
<mdz> doko: that's unfortunate
<Mithrandir> uhm, $ file initrd
<Mithrandir> initrd:
<Mithrandir> mdz: why is it a problem?
<mdz> Mithrandir: iirc, it pulled in some dependencies we didn't want in the desktop (or perhaps in main)
<mdz> all I see in anastacia.txt is python-qt3, though, which seems reasonable enough
<Mithrandir> I can disable the qt stuff if we don't want it, I guess.
<BenC> actually, we never touched vga16fb, just vesa for modular
<BenC> so if vga16fb is broken, it's not our (my) fault :)
<mdz> Mithrandir: I don't see a problem with it; doko would know what the issue was for sure
<mdz> BenC: it doesn't look like you changed the status of this mass of bugs
<BenC> mdz: doh, I missed that, it wont let me set them to needsinfo
<BenC> but it let me set them to P5, which I think is pretty empty
<doko> Mithrandir, mdz: afaik, that's the only interface to check for the ink status, focus the print-head etc
<doko> but maybe the best thing to do for now :(
<Treenaks> BenC: re: 2129: what other info is needed? or is it being marked by mistake?
<Mithrandir> hmm, so for some reason, cdebconf doesn't see the module.  Or ignores it.
<doko> mdz: does a bug import from debian to malone work, or can we import bug reports (even universe) to bugzilla (allocator change)?
* Kamion -> school run
<BenC> Treenaks: probably mistake
<ogra> oh, there is snow outside !
<BenC> Treenaks: bugzilla wont let me search by "no comments added for > 6 months"
<BenC> ogra: there shoud be snow where I am, but for some reason I have to have the AC on still
<BenC> way too hot for this time of year
<ogra> BenC, i'd have no objections to chang with you :) i *hate* snow
<BenC> don't get me wrong, I love this weather, but it just feels wrong :)
<ogra> heh
<ogra> but your place seems to be similar to mine ... in the middle of nowhere :)
<BenC> pitti: hey
<pitti> Hi
<ogra> pitti, spending your free day on irc ? :)
<BenC> pitti: you had the atmel usb wireless, correct?
<mvo> BenC: I have one
<BenC> mvo: i386?
<mvo> pitti: hey pitti, do you mind if I fix #10174 (you touched dhcp3-client last)?
<BenC> Treenaks: oh, and you had ipw2200, right?
<mvo> BenC: amd64, but I can install a i386 dapper if needed
<pitti> ogra: we just watched a cute movie about penguins :)
<BenC> I need 2.6.15-3.3 tested for atmel usb, and ipw2200 firmware updates
<pitti> mvo: merge? sure, anyway, I don't sit on it
<Treenaks> BenC: ok, I'll try that tonight when I'm home
<BenC> I have i386 images built
<ogra> pitti, ah, cool
<BenC> Treenaks: ok, thanks
<pitti> BenC: btw, after resuming from STD, USB did not work any more with yesterday's kernel
<pitti> BenC: I'll test it soon, but not now
<mvo> BenC: how long will a amd64 build take?
<BenC> mvo: not sure
<jsgotangco> hello
<HiddenWolf> Woei, de vlieg is dood.
<HiddenWolf> whoops
<HiddenWolf> sorry
<BenC> http://people.ubuntu.com/~bcollins/2.6.15/ if anyone wants to test it
<trulux> pitti: hey
<BenC> is there anything wrong with closing bugs in bugzilla after they've been resolved for some time?
<ogra> nope
<pitti> BenC: I never understood the difference between resolved/fixed and closed
<pitti> or, rather, I was never told
<HiddenWolf> pitti, fixed -> "i believe it should work now"  - closed -> "over and done with"
<HiddenWolf> something like that?
<BenC> I've always done resolved, but I'd like to flush all of them to closed
<Diziet> Whose bright idea was renaming the mozilla-firefox package, anyway ?
<BenC> kernel has 729 "Resolved" bugs, going back as far as bug #52
<mvo> Diziet: iirc it was someting with there trademark policy 
<HiddenWolf> BenC, i'd say close em. unless there's any debate about if they're still unsolved. :P
<jdong_> so, can anyone here gimme an estimate of when breezy-backports stuff will start building?
<BenC> well, I'm not about to go through each one, so mass close, and if any debate exists I'll reopen
<Diziet> mvo: ?!
<mvo> BenC: feel free to ping me when amd64 is ready, I'm happy to test
<BenC> mvo: ok
<mvo> Diziet: IIRC/AFAIK it can only be called "mozilla firefox" for official buils or something 
<jdong_> mvo: correct -- our FF is too patched for it to be considered MOZILLA Firefox
<BenC> we should call it "Ubuntu Browser" like AOL does :)
<Mithrandir> Diziet: http://www.mozilla.org/foundation/trademarks/policy.html
<Diziet> And this is not true of Debian's ?
<Chipzz> talking about which
<ogra> and get a ubuntu logo as throbber ? 
<Chipzz> is there a ff 1.5 beta package yet? :P
<jdong_> mvo: SuSE/Fedora/FreeBSD are fairly vanilla, and have gained permission to be mozilla-branded
<jdong_> Chipzz: I was told it's in the works
<BenC> ogra: a Dapper Drake doing the dapper dance
<ogra> lol
<mvo> jdong_: thanks for clarifing
<Diziet> chipzz: That's what I'm doing now.  I'm just merging the control files and then I'll make it fail to build.
<jdong_> LOL
<siretart> Diziet: there has been a giaant discussion in debian-legal and debian-devel about the 'mozilla-firefox' package in debian
<Diziet> siretart: Oh joy.
<Diziet> And what did they decide ?
<jdong_> hmm, where have we heard about Debian getting into legal flamewars recently ;)
<Diziet> Don't tell me: they decided the licence was non-free and we all had to beat ourselves with birch branches.
<siretart> Diziet: thats the funny part. I think the discussion ended in an agreement of the firefox foundation admitting, that the debian firefox package are good enough to retain the branding 'mozilla-firefox'
<jdong_> heh, we don't have any hope of that!
<Diziet> There were 25k lines of diff between upstream 1.0.7 and Debian's.
<siretart> and honestly, I'm still confused by that flamewar
<jdong_> Why _do_ we patch our Firefox so much?
<siretart> jdong_: because vanilla firefox is broken like hell?
<Diziet> 1.5beta is going to be _much_ less patched.
<jdong_> Diziet: sweet, thanks
<jdong_> would it be (perhaps) FASTER?
<jdong_> ;)
<Diziet> Hey, what do I know ?  I'm just wading around up to my eyeballs in a giant morass of C++ and JavaScript.
<siretart> jdong_: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mozilla-firefox&archive=yes to get an impression
<jdong_> siretart: oh? I've been a pretty heavy user of vanilla FF... what's wrong with it?
<jdong_> siretart: yes, but why is Ubuntu Firefox specifically so slow in Breezy?
<siretart> it is? *shrug*, not for me ;)
<HiddenWolf> breezy as a whole isn't the fastest, to be honest.
<ogra> for me neither
<Diziet> Most of the diffs between upstream 1.0.7 and breezy have been somehow incorporated upstream, but in many cases in a substantially rewritten way.
<Diziet> I suspect that the slowness is something to do with i18n and/or UTF-8.
<Diziet> Or possibly pango.
<jdong_> #15534 for those unfamiliar
<HiddenWolf> Diziet, rewritten in a good or bad way?
<Diziet> Pass.  I didn't get as far as trying to do a code review on 50kloc of diffs to font and graphics handling.
<jdong_> lol
* mvo sobs a bit about baz
<jdong_> is elmo still ultra-busy with ubz and such?
<ogra> mvo, you dont like bzr ? 
<Nafallo> jdong_: ubz is over.
<jdong_> ok
<jdong_> so any idea why elmo still isn't queuing up Backports builds for me?
<ogra> jetlag ? 
<Nafallo> syncs?
<Nafallo> elmo: thanx :-)
<jdong_> so he should be back to normal fairly soon, right?
<jdong_> right?
<ogra> i costs me normally about 3 days until its near normality ...
<Kamion> jdong_: I heard mutterings that breezy-backports will be opening once dapper's on launchpad; but that could be scurrilous rumour for all I know
<Nafallo> jdong_: no idea. why don't you ask him?
<jdong_> I have been unsuccessful in contacting him
<Kamion> jdong_: I know elmo's been moderately busy with meetings, his job not being *solely* administering the archive
<ogra> Kamion, backports was officially opened last week
<BenC> I'm glad no one is next to the bugzilla machine, it's probably crying right now
<jdong_> e-mail, never really found him on IRC.....
<Kamion> ogra: it was? news to me
<jdong_> Kamion: yes, it has
<jdong_> there are 20-30 packages waiting to be built
<HiddenWolf> BenC, you mass-closed those bugs? :)
<ogra> Kamion, yes, elmo opened it on the old build arch for now
<BenC> damn right
<jdong_> Kamion:  I know it's not his sole job, but if he's going to have 7+day lag, I think we need to change something
<jdong_> his response speed was excellent in hoary-backports
<BenC> jdong_: change what you feed him, I think he prefers pop-tarts and munchkins
<jdong_> lol
<Mithrandir> and pepsi max.
<zakame> there's no sugar
<Nafallo> eeew! pepsi :-P
<jdong_> well, I gotta go... class is almost over....
<jdong_> have fun, everyone
<BenC> blasphemy, pepsi is all goodness!
<BenC> uh oh, I think jdong made elmo mad
<Nafallo> coca cola and jolt is the stuff.
<BenC> I miss jolt, they don't sell it around here anymore though
<Nafallo> BenC: oh? :-)
<Nafallo> I stopped with *caffeine* :-)
<Nafallo> it wasn't good for me :-)
<BenC> cigarretes, jack daniels and caffeine
<BenC> not so much the jack, but the other two are a real problem for me :)
<HiddenWolf> BenC, stereotypical. ;)
<Nafallo> I will never start with nicotine :-)
<BenC> hidden: my front yard is a cow pasture, sue me :P
<Amaranth> nicotine and caffeine, the two things that get me through an all night coding session
<BenC> Amaranth: amen
<Amaranth> the jack is for after the session
<BenC> stop the caffeine jitters
<HiddenWolf> Amaranth, try working during daylight, might save you the all-nighters. :P
<BenC> *stops
<Amaranth> although i don't really drink so...
<Amaranth> HiddenWolf: daylight? what is this daylight you speak of?
<Amaranth> actually i only pull all nighters like that when i've got a deadline for something
<Amaranth> or during summer
<BenC> speaking of cigarettes...
<Amaranth> too cold here
<Amaranth> i've gone out twice and only smoked about half a cigarette each time before my fingers froze
<Mithrandir> Kamion: I have something which mostly works, apart from the fact that it claims that my plugin is malformed.  I'll investigate that further tomorrow, since I have to go for an RPG session now.
<HiddenWolf> Mithrandir, you nerd. ;)
<Kamion> Mithrandir: ok, have fun. "Malformed plugin module" means that it can't find the <frontend>_handler_<plugin-name> symbol.
<seb128> elmo: could you sync gtk+2.0 from Debian incoming?
<mdz> BenC: so far I haven't had any reason to distinguish between RESOLVED and CLOSED in our process
<slomo> BenC: did you get the url of my updated libraw1394 package?
<siretart> is elmo actually processing syncs today?
<seb128> he just did some
<mvo> siretart: I got a bunch just now
<siretart> elmo: could you please have a look at my key?
<Nafallo> siretart: yes
<mdz> Znarl: is there nothing that can be done about macquarie?
<mdz> Znarl: it's a big problem for us not to be able to work with bugzilla
<Znarl> mdz : I know, I saw the nagging this morning.  :/
<mdz> I have a backlog of 1400 bugs to look at, and it takes about a minute just to load up each bug in a browser
* seb128 does non-bug stuff for the moment, bugzilla is too slow to work with
<neuralis> mdz: *hint*specs*hint* and then bugs? :)
<doko> mdz: does a bug import from debian to malone work, or can we import bug reports (even universe) to bugzilla (allocator change)?
<BenC> mdz: not sure what the purpose is either, but for whatever reason, I'm changing them all to closed, so maybe it will help me later :)
<mdz> doko: it should be possible to import them to malone, yes
<BenC> if only so I can get some accurate bug statistics for dapper cycle
<mdz> BenC: I don't think it will be helpful, and it produces a lot of unnecessary mail. probably best to leave them alone unless we have a reason to do so
<Nafallo> what's up with dapper-changes? my syncs katie told me about 40 minutes ago haven't ended up there yet.
<BenC> the statistics is my main thing
<mdz> BenC: which statistics?
<BenC> when dapper releases, I want to be able to see that X number of bugs were resolved, and do a mass closing after dapper again for the next cycle
<BenC> s/statistics/accounting/
<BenC> maybe that makes more sense
<[splinux] > hi all
<mdz> you've just landed another 50 emails in my inbox
<BenC> is there a way to do it so it doesn't send email?
<mdz> if the idea is to count how many bugs were closed during the cycle, there are surely easier ways
<Nafallo> oh
<Nafallo> maybe that's why _I_ don't recieve mails :-P
<BenC> well, I stopped the process
<mdz> thanks
<mdz> bugzilla does have a reporting facility which may very well give you the report you want
<mdz> without changing status information
<Nafallo> but then again, the build-logs stopped also :-/.
<BenC> maybe it's just my nature, but I hate leaving them unclosed :)
<mdz> of course, by the time dapper releases we'll have migrated to malone anyway, and the bugzilla distinction of resolved vs. closed won't exist there anyway
<BenC> very true
<siretart> is there a timeframe for that? we hat someone earlier today in #ubuntu-motu asking that
<mdz> Znarl: can we run jamesh's job on a different machine?
<siretart> timeline, even
<mdz> siretart: no, there isn't
<siretart> okay
<BenC> is lp deemed production ready yet for dapper, or are they still working out some of the stuff from ubz?
<dieman> are we to submit all bugs to malone yet, or bugzilla or what?
<BenC> damn, I might aswell finish this up, closed 500 of the 729 bugs already anyway
<dholbach> dieman: universe -> malone, main -> bugzilla
<xhaker> dieman, main to bugzilla.. 
<dieman> ok
<BenC> maybe I'll do 50 a day till it's done :)
<dieman> still main to bugzilla
<xhaker> BenC running your 2.15.3 kernel now
<xhaker> anything you want feedback on?
<BenC> do you have a ipw2200 of atmel usb?
<BenC> *or
<xhaker> ipw2200 :P
<BenC> is it working?
<xhaker> it is
<BenC> sweet
<BenC> thanks
<xhaker> only change is the firmware right? drivers are still 1.0.8?
<dieman> ipw2200 rocks :)
<xhaker> it's spitting out a warning but i don't think it's important
<BenC> xhaker: yeah, I updated from 2.3 to 2.4 firmware
<xhaker> checking dmesg
* mvo reboots and sees if he can make his machine crash with a zd1211 usb stick
<xhaker> http://cdimage.ubuntu.com/daily/20051114/dapper-install-i386.jigdo
<xhaker> ups
<xhaker> not this
<xhaker> [17179595.184000]  Warning: PCI driver ipw2200 has a struct device_driver shutdown method, please update!
<dieman> BenC: oh, so your why bugzilla is going at glacial pace ;)
<mdz> dieman: no, that's a separate issue
<dieman> oh
<dieman> noticed all the closed bugs i just got :)
<Kamion> Riddell: should amu really still be the Maintainer: of kubuntu-meta?
<BenC> dieman: yes, I beat on bugzilla, and I feel a lot better now :)
<Riddell> Kamion: not really
<xhaker> BenC.. there are other errors/debug lines in the dmesg for ipw2200 but i had them before
<BenC> xhaker: interesting, I'll have to do a build without that function defined and see if it still works
<Kamion> Riddell: thought not
<Riddell> Kamion: I'll change that on next upload, or you can if you're about to uploda
<Kamion> Riddell: I only noticed after upload unfortunately
<Nafallo> BenC: I think you (temporarily) stopped katie from sending me mail ;-/.
<xhaker> BenC, lines like [17179695.116000]  ipw2200: Failed to send CARD_DISABLE: Command timed out. and [17179857.460000]  ipw2200: Unknown notification: subtype=40,flags=0xa0,size=40
<xhaker> i doubt that helps tho
<xhaker> must be something beyond build skills
<BenC> xhaker: probably best to see the ipw2200 maintainers about that one...if it works, that's all I care about (especially if it did the same in breezy)
<xhaker> s/skills/scope
<BenC> mvo: you have a zd1211?
* mvo is back after his system had a really bad freeze
<BenC> mvo: that's what I heard about zd1211 driver
<BenC> did Alt+SysRQ work at all?
<mvo> BenC: yes, send you a mail about it, makes my system crash on ifup though
<BenC> ok
<mvo> BenC: other people (beside me) have the problem as well? interessting. well, alt-sysrq does work, but +t does not show anything :/
<BenC> no IOMMU for amd64!?!
<mvo> BenC: that's what the kernel tells me
<BenC> maybe I need to do a 32bit DMA mask for that driver
<BenC> mvo: no, no other reports, I just didn't make the connection that the email was from you at first
<BenC> mvo: ok, zd1211 dma is on my todo list now
<BenC> I'll let you know I get something to test
<mvo> BenC: cool, thanks! I'll try to find a i386 box to test it there as well
<mvo> (and the atmel thing)
<BenC> sounds like zd1211 will work on 32-bit
<BenC> probably just a 64-bit issue with high dma memory
<BenC> would be good to know if it did or didn't though
<BenC> mvo: thanks for the testing
<Diziet> Maybe I should get more RAM for this box so I can keep a firefox tree or two in core.
* mvo reboots to test the new kernel
<xhaker> :(
<xhaker> i'm trying to reproduce the daily build of the 14th using jigdo and i already got some not found 400 errors :(
<xhaker> i guess mvo had a bad enconter with the kernel
<mvo> BenC: both zd1211 and at76c503 work fine on 2.6.15-3-686 i386 (installed from people.u.c)
<Kamion> xhaker: yeah, jigdo doesn't have a very long life for daily builds. Try 20051115.2 jigdo, and if you really want 20051114 then rsync back from that.
<xhaker> Kamion, 15.2 has some bad stuff going on :( it has some broken dependencies right?
<ogra_>   dbus-1-utils: Depends: dbus but it is not going to be installed
<ogra_> E: Broken packages
<ogra_> E: Could not satisfy build-dependency.
<ogra_> *grumble*
<ogra_> updating pbuilder frequently is like playing russian roulette currently ...
<Kamion> xhaker: entirely possible. daily builds right at the start of a release cycle are not expected to be sane.
<xhaker> Kamion, rsync back from 15.2 -> 14 is that even possible? *rsync noob alert*
<Kamion> xhaker: yes
<xhaker> i just don't want to download the whole .iso
<BenC> mvo: excellent, thanks
<BenC> mvo: pretty much makes the zd1211 problem a 64-bit issue, and I'm pretty sure it's a simple fix...I'll get back to you on it
<mvo> BenC: cool, thanks
<xhaker> Kamion, thanks.. i got it :P
<doko> Kamion: is flight-1 still scheduled for Friday? is there anything that needs to be fixed for the build?
<seb128> pitti: around?
<xhaker> seb128, look what you've done :\          ;)
<Kamion> doko: theoretically Thursday; we'll see, there's an awful lot of main<->universe churn at the moment that's making it difficult to tell
<xhaker> true
<doko> Kamion: tell me, I'm currently preparing syncs and renamings for the allocator change, which I can delay
<Kamion> doko: I think I already asked if those could be delayed
<mdz> BenC: what criteria did you use to select "old" bugs?  I just saw one (5828) which had an insightful comment on October 24th
<BenC> mdz: I used dates of last change, unfortunately "last change" does not have a way to include a comment being added
<mdz> odd, I'd expect a comment to be a change
<BenC> me too
<BenC> I'll revert that one
<Kamion> Mithrandir: your shadow merge just became urgent; adduser needs it
<Amaranth> hey, if wine comes with an mp3 decoder shouldn't it be in multiverse?
<BenC> mvo: I have a patch in -3.3 for zd1211, when it's done compiling I'll ping you
<BenC> mdz: one thing I've not heard so far with 2.6.15 is anyone reporting that CDROM's are broken from the DMA enable
<xhaker> BenC, what do you mean?
<BenC> xhaker: for dapper DMA is enabled by default for cdrom's
<BenC> prior to this it has always been disabled by default
<xhaker> my cdrom reports udma2
<BenC> I expect a blacklist will start soon enough though
<Nafallo> BenC: I've had that in my hdparm.conf for ages so ;-)
<mdz> BenC: I don't think we'll get broad feedback on that until we make 2.6.15 the default kernel in dapper
<Nafallo> s/so\ //
<BenC> mdz: as soon as lrm is ready, I'm going to update linux-meta
<Kamion> uh
<Kamion> can this be post-Flight-1 please?
<BenC> Kamion: how long till Flight 1?
<Kamion> a day or two, depending on how soon I can make it all work
<BenC> that's good timing then
<BenC> I don't expect it to happen till next week
<dilinger> BenC: nice to see that.  disabling DMA for cdroms just seemed like a bad idea
* dilinger recalls the bug regarding that
<HiddenWolf> dilinger, not catching a drive for which it breaks is a bad idea too. :P
<Kamion> dilinger: there are bugs both ways round :(
<dilinger> HiddenWolf: yes, but there's a blacklist for a reason
<dilinger> why penalize all cdroms/chipsets when it's merely a select few?
<doko> Mithrandir: are you currently working on shadow sync?
<HiddenWolf> dilinger, I doubt it's just a handful.
<Kamion> doko: Mithrandir said he was going out for the evening, so I'm working on it now
<doko> hmm, I really need a _new_ dapper chroot for the installability tests
<dilinger> HiddenWolf: the bug reports i've seen seem to imply that
<dilinger> i've personally not had a problem w/ DMA enabled on cdroms except for an ancient PIIX3 system
<ogra> has anyone else seen problems with dbus in pbuilder ? 
* mvo goes to have dinner now
<sivang> Kamion: flight 1 is the codename of the periodical builds? (foremly known as colony and sounder? ) :)
<ogra> dont forget array
* ogra cries about his pbuilder
<Kamion> sivang: yes
<mdz> BenC: what happened to the changelog for 2.6.15-1.1?
<mdz> BenC: there were a number of significant changes besides merging 2.6.15, e.g. the config changes, unionfs, etc.
<BenC> mdz: how do you mean?
<mdz> but the changelog only mentions  merging and git
<BenC> mdz: I didn't start the changelog till near the end, so it's a little thin
<mdz> BenC: it also dropped all of the pre-2.6.15 changelog entries
<BenC> well, it was a completely new tree, so everything from 2.6.12 didn't really apply
<BenC> 99% of everything was just taking the patches from breezy
<mdz> BenC: unless you dropped all of the changes which were in 2.6.12, it does apply
<Kamion> carlos: msgcat --use-first so totally rocks
<BenC> mdz: I could say "pulled patch XXX from breezy", but that's not that informative
<mdz> BenC: you could leave the old changelog entries in the file, and that would be informative
<mdz> BenC: that's what we've done for all of the previous kernels
<carlos> Kamion, ;-)
<BenC> mdz: what about the 2.0.29 entries?
<mdz> BenC: the changelog is all of 60k; I'm not worried
<mdz> there's no reason to drop all of the history just because it's a new upstream
<BenC> mdz: My goal was to make the debian/changelog pretty broad in scope, and use a script to pull all the UBUNTU changes from git-log in a ChangeLog-2.6.15.UBUNTU like Linus does for release
<BenC> mdz: all of the real info is in git-log anyway
<mdz> BenC: git cannot be a prerequisite for getting useful changelog data any more than CVS is
<BenC> mdz: I wasn't talking about making people use git to get the history
<BenC> mdz: my feeling is that this is a new tree, with new source, and new development. It isn't based on anything else, so the changelog was somewhat irrelevant in showing what was actually going on
<mdz> BenC: it is based on the breezy tree, which was based on the hoary tree, and so on
<mdz> all of those patches you pulled into 2.6.15 were dated and documented in the previous changelog entries
<BenC> it's based on the breezy patches, which are listed in git, and will be extracted and installed with the kernel
<BenC> actually a lot of them were not all that documented to begin with
<BenC> I can pull the previous kernel changelog stuff if you think it's really relevant, but I just didn't see the point when everthing was being reworked and redocumented anyway
<mdz> when we get regressions in dapper, we're going to look in the changelog to try to narrow down what happened
<mdz> the changelog is now useless for that
<BenC> what good is the previous changelog for breezy/dapper regressions in the kernel?
<BenC> regressions are usually found with diff, not vi, atleast in these sorts of cases
<mdz> you must be joking
<BenC> ok, we have a vga16fb regression between breezy and dapper, how will the changelog help?
<BenC> I'm not kidding, the changelog doesn't say enough to fix anything like that
<mdz> it won't, because you didn't document any of your changes in the changelog
<BenC> I didn't change anything
<mdz> but in addition to that, you've thrown away all of the previous changelogs for no apparent reason
<BenC> I said I would pull them back in
<mdz> we didn't throw away the changelogs when we started using baz; I don't see why you want to do that when moving to git
<BenC> with baz, I'm sure you did a mass checking
<mdz> if you added or removed any patches when going to 2.6.15, that should be in the changelog
<BenC> and not start with a fresh tree and commit each patch/driver individually
<mdz> (and I'm sure you did add and remove patches)
<BenC> didn't add, but certainly, some patches were obsoleted by upstream
<mdz> unionfs?
<BenC> well, yeah, unionfs
<slomo> pitti_: are you already working on getting debhelper merged? otherwise i would try it and give it to you for review
<seb128> the first one that break all GNOME by merging debhelper and pushing a new dh_gconf because the new gconf win a extra point
<seb128> just a way to say to be carreful on that
<BenC> mdz: you're right, I could have duplicated all the git log info into debian/changelog, and still can, but it would have added a considerable amount of time to do it
<seb128> Debian made a bunch of nontrivial gconf changes
<seb128> and updated dh_gconf according to that
<seb128> *don't* push a new dh_gconf before we change gconf
<BenC> right now, I can get all that info and add it on
<seb128> or every app using gconf will blow
<mdz> BenC: if you made all of the appropriate notes in git's log, surely it can just be reformatted for changelog
<slomo> seb128: ok, you convinced me... i won't touch it ;)
<mdz> I've done that with baz logs for ages
<BenC> mdz: correct, and my intention was not to flood the debian/changelog, but instead of a seperate changelog that showed all the details
<seb128> I'll update gconf next week for information
<BenC> *instead have a
<mdz> BenC: why would it be any more of a flood than the previous changelog entries?
<BenC> it's not, it'll be there in -4
<BenC> all of it, previous and current
<mdz> thanks
<pitti_> slomo: I already merged it last week
<slomo> seb128: it's already merged... but didn't build
<pitti_> slomo: but we can merge the new version again, it has some fixes
<slomo> lol
<slomo> ok :)
<seb128> pitti_: read what I said
<pitti_> slomo: right, it needs some main inclusion love
<seb128> pitti_: be warned than the new dh_gconf is likely to break every single app using gconf
<seb128> pitti_: since we didn't migrate gconf to use the new script it requires
<pitti_> seb128: really? even in compat level 4?
<seb128> pitti_: Debian introduced a new gconf-something tool and dh_gconf use it now to register the schemas
<seb128> pitti: our gconf is recent enough in version for the test but doesn't has the feature
<pitti> seb128: how does that break existing packages which don't use dh_gconf?
<pitti> ah, cdbs?
<seb128> so yes, every single postinst trying to register a schemas is likely to blow
<seb128> pitti: every single GNOME package registring a schemas uses dh_gconf for that, it writes the postinst part
<dholbach> elmo: please sync ocaml from sid, ok to override ubuntu changes
<seb128> k, time for dinner 
<seb128> bbl
<dholbach> bon appetit :)
<ogra> was anybody able to build a package that has dbus build deps today ? 
<ogra> i just set up a completely new pbuilder, it still breaks with a message that dbus-1-utils cant be installed
<ogra> dholbach, did you build anything dbus related today ? 
<dholbach> no, i shouldnt think so
<ogra> hmm
<ogra> The following packages have unmet dependencies:
<ogra>   dbus-1-utils: Depends: dbus but it is not going to be installed
<ogra> E: Broken packages
<ogra> E: Could not satisfy build-dependency.
<ogra> no go here ... 
<elmo> Riddell: ?
<dholbach> if you login to the pbuilder and try to insatll them manually?
<ogra> i'll try 
* ogra wants fatsre disks
<ogra> *faster
<ogra> hmm, same error
<ogra> ahh
<ogra> its adduser thats broken
* ogra screatches head ....
<ogra> why does dbus depend on adduser ??
<Diziet> Urgh, it looks like I have a bunch of mess to clear up in this merge.
<Diziet> By dapper+1 we'd better have a good working hct.
<dholbach> elmo: please sync findlib from sid, ok to override our changes
<elmo> dholbach: done
<elmo> (both)
<dholbach> elmo: thank you very much, if you now sync gmetadom from sid and override our changes, i'm happy :)
<dholbach> merci beaucoup
<ogra> dholbach, dont upgrade your pbuilder ... its shadow thats broken, pending merge. this will affect a lot of packages ...
<dholbach> ogra: thanks for notifying, but it's too late already - slomo and i had the conversation yesterday :)
<dholbach> regarding shadow
<ogra> oh, ok
<slomo> touching /etc/shadow fixes it for now ;)
<ogra> slomo nope, not that
<ogra> the package shadow is not installable at build time, thats something else
<slomo> ah ok... yes
<ogra> i had to fix my pbuilder yesterday as well
<elmo> dholbach: done too
<dholbach> merci
<sistpoty> elmo: could you please add my key (8D7FCA91) to the keyring for universe uploads? (rt.admin.canonical.com #784)
<robertj> mvo: are you about? gdebi is b0rk here...sudo --: command not found
<dholbach> robertj: sudo not found?
<robertj> err something of that sort apparently
<dholbach> robertj: could you look up, what the message is?
<dholbach> robertj: do you have gksu installed?
<robertj> I mean that's the message, I'll give you the preceeding when this strace is done
<Nafallo> elmo: hi! did you sync ttf2pt1?
<xhaker> Kamion, you there? 
<xhaker> Kamion, i'm trying rsync -Pz --stats rsync://cdimage.ubuntu.com/daily/20051114/dapper-install-i386.iso
<elmo> Nafallo: nothing to sync?
<mvo> robertj: do you have gksudo latest version insalled (from dapper)?
<xhaker> and guess what.. doesn't work
<robertj> mvo: I'll check when this is done stracing
<slomo> BenC: when will we get a ppc buildable 2.6.15 kernel? ;) and did you get the url to my updated libraw1394?
<robertj> gksu is old, upgrading
<Nafallo> elmo: oh. you must have done that one earlier then :-). I lost my katie-mail for it somewhere.
<Nafallo> elmo: thanx anyway :-)
<Kamion> ogra: I'm fixing shadow, but it's a not-entirely-small job
<Kamion> xhaker: the rsync base URL is rsync://cdimage.ubuntu.com/cdimage/ not rsync://cdimage.ubuntu.com/
<Kamion> xhaker: you can use 'rsync -av rsync://cdimage.ubuntu.com/cdimage/...' to just do a directory listing
<xhaker> thank you.. i was already reading some spanish page in the wiki
<ogra> kAMIYES, I READ THE BUG, THANKS FOR THAT
<ogra> oops, sorry
<BenC> slomo: -3.3 will get ppc building, and please email me the URL for libraw
<slomo> BenC: adress? benc@u.c?
<BenC> mvo: ping
<BenC> bcollins@u.c
<hunger> BenC: You are the kernel person of ubuntu, aren't you?
<BenC> hunger: that's what they told me in Montreal, so who am I to argue :)
<hunger> BenC: Any plans for xen kernels yet once that gets into the vanilla kernel tree?
<mvo> BenC: pong
<slomo> BenC: mail sent
<hunger> BenC: I'm asking as I am rolling xen debs just now:-)
<BenC> mvo: amd64 kernels at p.u.c/~bcollins/2.6.15/
<BenC> hunger: can you elaborate on what xen is?
<BenC> and I'm guessing that if it's not in 2.6.15 yet, it wont get in, so it's very doubtful it will be a dapper feature
<mvo> BenC: downloading now
<hunger> BenC: Xen is basically a microkernel that provides a virtual architecture for other OS kernels to run on concurrently.
<BenC> hunger: not going to happen for dapper, I'm sure
<hunger> BenC: Redhat and suse are trying to get that into vanilla kernels.
<BenC> hunger: dapper+1, if you want it, you should start specing it now :)
<hunger> BenC: Yes, I would have been surprised if it did.
<Riddell> elmo: hi
<hunger> BenC: There is a spec. Xen even used to be a breezygoal.
<elmo> Riddell: what's the deal with gettext-kde?  it got uploaded once, we discussed it on IRC (unfortunately I forget, and didn't record the details), and it ended up getting REJECTED.  now it's back?
<BenC> ah
<ogra> BenC, it was dropped... it was a SoC bounty that didnt work out right ... 
* hunger should write up his thoughts on Xen in ubuntu and mail that to the list.
* Nafallo upgrades to that amd64 kernel BenC had URL to.
<hunger> ogra: It was?
<ogra> and fabbione has some objections against xen iirc
<BenC> Nafallo: yeah, let me know how it works out for you too
<ogra> hunger, yup
<hunger> ogra: Oh, SoC bounty, read ubuntu bounty:-)
<Riddell> elmo: it was rejected in the hope that we might be able to use the normal gettext.  discussed with carlos as UBZ that isn't possible and the best way is to just use this version 
<BenC> hunger: find the spec on wiki.u.c and update that
<hunger> ogra: Anyway, what are the feelings about xen? I get mixed signals on it;-)
<BenC> hunger: is it anything like UM?
<hunger> ogra: Some people seem to be seriously in favour of it, others seem to be very critical.
<ogra> hunger, better talk to fabbione ... i'm no kernel guy ... but he was seeing some issues with it ...
<hunger> BenC: Somewhat... It has stronger separation between the OS kernels.
<hunger> BenC: and it can run more than linux:-)
<BenC> sounds interesting
<BenC> hunger: how do suse and redhat support this in their products?
<hunger> BenC: It is. SuSE, Redhat and IBM are pushing it.
<BenC> are they shipping anything based on it yet?
<Riddell> elmo: shall I re-upload?
<hunger> BenC: IIRC FC4 has it, and I heared opensuse supports it as well.
<elmo> Riddell: why isn't it possible?  
<BenC> so they install xen first, and then their OS becomes an instance of xen?
<hunger> BenC: I doubt that they will support it fully before they get it into the vanilla kernel.
<BenC> or does xen require Linux to run
<hunger> BenC: redhat assumes a timeframe of about 2 month for that. We will see how realistic that is.
<BenC> 2 months is right about when 2.6.16 devel will open up :)
<hunger> BenC: Xen is a microkernel. You load that via grub plus linux (plus initrd).
<BenC> they need to hit that 2 week window when 2.6.16 starts taking patches
<hunger> BenC: The linux kernel is adapted to run on the Xen hypervisor instead of the real hardware.
<Riddell> elmo: because the patch used by kde is not portable to current gettext
<BenC> guess I'll read up on it when it hits the kernel
<BenC> sounds like it's doing mainframe work in software :)
<hunger> BenC: The new intel and amd cpus have support for that in HW:-)
<elmo> Riddell: ok, reupload for now if you want
<Riddell> elmo: thanks
<hunger> BenC: Xen can even run windows next to linux on such boxes:-)
<elmo> Xen can't run standard windows
<hunger> BenC: No need for changes to the OS kernel if the CPU extensions are there;-)
<BenC> so how do you switch between consoles of such machines, and does it support things down to like video accel (GL) and such?
<hunger> elmo: It can on VMX-enabled CPUs.
<elmo> hunger: in Xen 2?
<hunger> BenC: You assign the HW to one virtual machine. That has full access and can export that as virtual devices if needed (and supported).
<hunger> elmo: No. Xen 3 has that kind of support in the works.
<elmo> right, and Xen 3 isn't out yet, and won't be for Dapper timeframe
<hunger> elmo: From what I read they want to release that in about 2 month).
<hunger> elmo: Sure. I am not interested in getting xen into dapper.
<hunger> elmo: I am just curious whether there is interesst with other people to get it into dapper+x (whenever xen makes it into the vanilla kernel).
<slomo> hunger: i'm interested in xen ;)
<BenC> hunger: short answer is, if people are interested, it will get spec'd at the developer summit for that release
<hunger> BenC: Good answer. So basically I shouldn't bother till there is a spec for a release?
<BenC> hunger: well, you should bother to do the spec if you are that interested :)
<BenC> get it prepared for dapper+n
<hunger> BenC: Good... so I'll try to think about how to do it and ask people for there oppinion on how to do it till then.
<mvo> BenC: a nice oops, but no freeze :)
<mvo> BenC: zd1211
<BenC> mvo: still an oops?
<BenC> can you email it to me?
<BenC> actually, that's right, it froze before
<Kamion> mdz: are we going to promote hplip to main, then? (re the earlier discussion)
<mvo> BenC: mail send
<BenC> mvo: thanks
<hunger_> Sorry, lost my connection.
<dholbach> wb seb :)
<Nafallo> are we talking about hplip in ubuntu-desktop or just supported?
* Nafallo think it would be ugly to bring in qt3 on his nice gtk-system :-P
<Kamion> Nafallo: main
<hunger_> Hi Kamion.
<Kamion> desktop is rather definitely a subset of main
<Kamion> hi
<Nafallo> for me main = desktop+standard+minimal+ship+supported :-)
<Pazzo> hi all! my Breezy desktop is using LOTS of memory and as I don't like it to do so I tried to discover who is gonna wast all my memory...
<Pazzo> ...I'm running gnome, 8 desktops with evolution, xchat, lots of terminals, notepads, thunderbird as a newsreader, amule from time to time, oo2 etc...
<BenC> mvo: ok, it doesn't like GFP_DMA when it has to grow the slab...not sure what to do here
<BenC> mvo: in all honesty, I think this is an amd64 bug (I've seen the dma problem in other drivers)
<Pazzo> I discovered that most memory is used by two shared libraries, both part of libpango1.0-0
<Pazzo> (and probably caused by firefox to use all this memory)
<Pazzo> forgot to mention: there are also some firefoxes running on this 8 virtual desktops, each of them with lots of tabs
<mdz> Kamion: currently I don't see any reason not to
<mdz> Kamion: might be good to check with doko first
<Pazzo> currently memstat shows me:
<Pazzo> 426836k: PID  4607 (/usr/lib/pango/1.4.0/modules/pango-basic-fc.so)
<Pazzo> 426836k: PID  4607 (/usr/lib/pango/1.4.0/modules/pango-basic-fc.so)
<Pazzo> 256692k: PID 18807 (/usr/lib/pango/1.4.0/modules/pango-thai-fc.so)
<Pazzo> (sorry for posting the same line twice)
<hunger_> Pazzo: So grab the sources and fix it:-)
<mvo> BenC: no problem, if you need more testing, let me know
<Pazzo> hunger_: step by step please :)
<Pazzo> I'm here to find out if someone else has the same issue
<Pazzo> I know that firefox uses a lot of memory - but that's too much
<hunger_> Pazzo: I'd guess those modules contain unicode informations (wild guess only!).
<Pazzo> and it seems kinda strange to me that libpango is atm using >750 megs of ram on my host
<hunger_> Pazzo: Maybe you could try to avoid surfing to thai sites? ;-)
<Pazzo> no thai site, sorry
<Pazzo> I'm wondering about the pango-thai-fc.so too!?
<hunger_> Pazzo: Well, I have no real clue what goes wrong here.
<Kamion> doko_: ^-- hplip in main?
<Kamion> Nafallo: incomplete list - but anyway, main is the union of the 'all' outputs from germinate for the ubuntu, kubuntu, edubuntu, and ubuntu-server seeds for all architectures
<Kamion> Nafallo: (incomplete> you were missing 'live', 'installer', 'casper', and as of this afternoon 'boot')
<hunger_> Pazzo: I get the basic-fc loaded as well. uses about 8k.
<Nafallo> Kamion: ah, right :-).
<Pazzo> hunger_: may be I should post a bug report regarding this somewhere?
<dholbach> "somewhere" would be upstream rather than ubuntu and looking at recent  blog entries, they're working on it
<hunger_> Pazzo: You can always put it into gnome's bugzilla.
<Pazzo> closed all firefoxes, pango calmed down
<Pazzo> but there is also:
<Pazzo>  429520k: PID  4607 (/usr/share/locale-langpack/de/LC_MESSAGES/glib20.mo)
<Pazzo> hmm... cool, this one is caused by amule
<hunger_> memstat gives a total mem usage of ~280MiB here:-)
<Pazzo> what does amule do with >400mb langpack???
<hunger_> Pazzo: No idea.
<Pazzo> and evolution has 181320k => /usr/share/locale-langpack/de/LC_MESSAGES/gnome-vfs-2.0.mo
<seb128> how do you get those numbers?
<hunger_> Pazzo: How much RAM is on your system?
<Pazzo> seb128: memstat
<Pazzo> hunger_: 1gb + 1gb swap
<Pazzo>  430152k: PID  4607 (/usr/share/fonts/truetype/ttf-bitstream-vera/VeraSe.ttf)
<Pazzo> ????
<Pazzo> (4607 -> amule)
<hunger_> Pazzo: none of the fonts loaded here needs more than 8MiB. VeraSe.ttf is 80kiB.
<hunger_> Pazzo: actually only 60. You are doing something wrong:-)
<sistpoty> seb128: memstab seems to read /proc/%d/maps and calculate hi-lo from the inode
<sistpoty> memstat even
<Pazzo> forget it - amule is using 430152k - don't know why it shows the font
<Pazzo> amule really eats lots of memory - but that's ok, I don't need it and don't care about
<Pazzo> but wth is firefox eating that much memory?
<neuralis> Pazzo, firefox is very sloppy with deallocating memory -- if you use it for long enough without closing the entire application, it'll eat a LOT of ram.
<Pazzo> extensions loaded: webdeveloper, adblock, english & german language pack, dom inspector
<Pazzo> neuralis: exactly - that's what I have here :(
<Pazzo> I'm using 8 virtual desktops, sometimes also more of them
<Pazzo> lots of terminals, notepads, OOo, evolution etc
<Pazzo> and 1-2 firefox windows on 3-4 desktops
<Pazzo> lots of tabs in each firefox
<Pazzo> this system is running 24 hours a day and I really hate it to close 6-7 firefoxes with ~50 tabs more times a day to free my memory
<Pazzo> that's evil
<Nafallo> BenC: you had rt2500, right? have you got a working diod when it's ifconfig up'd? :-)
<Pazzo> before installing ubuntu I have been running debian sarge (was "testing" at this time" for something like a year - and I didn't have this problems there
<lucas> Nafallo: rt2500 is the driver/chipset, not the card, and this might depend on the card
<lucas> Nafallo: I have a rt2500 pcmcia card, and I have a led that tells me it's ifuped
<Nafallo> lucas: worked with the rt2500-driver. doesn't with rt2x00.
<lucas> I'm not sure of the one I use. I use the one in breezy.
<Nafallo> seems network-manager can't see the card either :-/.
<Nafallo> lucas: breezy == rt2500
<BenC> Nafallo: rt2500pci only sort of works for me
<BenC> Naffallo: it connects to the AP, but drops a lot of packets, and eventually stops working
<Nafallo> I wish I had an AP to test it with...
<Nafallo> network-manager doesn't recognise the card anyway :-P
<BenC> does iwconfig recognize it?
<Nafallo> yes
<Nafallo> ehm
<Nafallo> Quality=100/0
<BenC> if you can ever test it, I'd be interested in the results
<Nafallo> I will put WRT54G on my xmas wishlist then ;-)
<Nafallo> how long to we have before we have to revert back to rt2500 (and rt2400, rt2570)?
<BenC> not long
<Kamion> mdz: I'm off to bed soon, and will be up for the distro team meeting tomorrow morning - any chance you could mobilise people in the meantime to fix enough uninstallables to get CD builds working?
<dholbach> i'm off now, see you tomorrow
<daniels> oh god, distro team meeting
<daniels> i'd forgotten about that
<Nafallo> daniels: yes. you have stuff to do right now? I could need your help getting tightvnc synced. I can't get it to find the fonts by default :-/.
<Nafallo> s/synced/synced\ or\ merged/
<Nafallo> why is dapper-changes so slow this evening?
<Mithrandir> doko_/Kamion: Not _right now_, but yes, I'm working on shadow.  I was intending to do it tomorrow, really.
<elmo> shadow's done?
<daniels> Nafallo: there's a DefaultFontPath define
<elmo>     shadow | 1:4.0.13-6ubuntu1 |        dapper | source
<Mithrandir> elmo: possibly, I just came home.
<daniels> Nafallo: the delta from 1.2.9-6{,ubuntu1} should be pretty tiny and portable; what's up?
<mdz> Kamion: send me a hit list if you have one
<Nafallo> daniels: I used the merged version, which looks like it keeps your patch. that one has the correct dirs but tightvncserver still errors out the same way as in that bugreport :-/.
<daniels> Nafallo: hrm
<Nafallo> indeed :-)
<Simira> daniels: have you fixed my bug yet? I'm still using Windows XP....
<Kamion> Mithrandir: too late, done :)
<Kamion> Mithrandir: sorry if I stepped on your toes, but was urgent
<daniels> Simira: yeah, worked out what it was finaly
<daniels> Simira: (well, janimo caught it before I got to it)
<dholbach> bye
<daniels> Simira: Option "Accel" in the Device section should fix it
<Mithrandir> Kamion: no problem. Reason it took a little was I was waiting for a fix from bubulle which hit two days or so ago and I was working on something else yesterday (iirc).
<daniels> dh	night
<dholbach> bye daniels
<daniels> Nafallo: so if you vim the binary, do you see /usr/share/X11/fonts/misc?
<Kamion> mdz: I don't - my only comments are to wait until shadow builds everywhere before doing serious triage (adduser uninstallability takes out a bunch of stuff), and that the curl uninstallables need an inclusion report for ca-certificates (or modification of curl)
<Mithrandir> Kamion: any excellent ideas what to do about "code which debconf plugins might need, but shouldn't go into the core"?  (See get_text_{height,width} in src/modules/frontend/newt/newt.c for an example.
<Kamion> Mithrandir: not tonight :)
<Nafallo> daniels: hmm, no. if (!$fontPath) {
<Nafallo>   $fontPath = "/usr/X11R6/lib/X11/fonts/Type1/,". etc...
<Keybuk> is something up with Bugzilla?
<Keybuk> it's stalling when getting pages
<Kamion> Keybuk: macquarie's load is 13
<Keybuk> sweet
<Seveas> Ben Collins has been flooding the zilla
<Kamion> Seveas: that's hardly the problem
<Seveas> kernel bug weeding
<Kamion> Keybuk: jamesh has been doing bzr imports or something like that on macquarie
<HiddenWolf> Seveas, 700 bugs only, say 2000 mails. :P
<Kamion> there's some enormous gpg operation happening at the moment
<Seveas> gpg --recv-keys * 
<Seveas> :)
<Kamion> pretty much
<elmo> seriously?
<daniels> Nafallo: ah, yeah
<daniels> Nafallo: that'd do it :) i fixed it in the X server, not in the Perl script
<Kamion> elmo: yeah, the gpg stuff and a buildbot instance
<HiddenWolf> So bugzilla to malone is still being prepared?
<Nafallo> daniels: so the bug was never really closed then? ;-)
<Kamion> it's niced, but ...
<mvo> Keybuk: mind if I upload a dhcp3-client that fixes #10174?
<Kamion> the stuff jamesh is doing *could* be related to bugzilla-to-malone (he's been working on that), although I don't immediately see how
<daniels> Nafallo: *cough*
<Nafallo> :-)
<Simira> daniels: hum, I don't think I got your answer, I got disconnected
<Nafallo> good to know. been wondering what went wrong with the sync :-)
<lifeless> Kamion: its check pending reviews
<Keybuk> mvo: which bug is that?  Bugzilla won't tell me this week
<lifeless> Kamion: which is workflow for launchpad
<Keybuk> is that the "dhclient tries to do lo too" one?
<Kamion> lifeless: that kind of load on macquarie seriously impairs the distro team's work
<mvo> Keybuk: dhclient without arguments removes ipv4 adress from loopback
<lifeless> stub is going a baz0import
<Keybuk> mvo: yeah, go for it -- I don't have any particular hold over that
<lifeless> Kamion: its load average 2.5
* Kamion -> bed
<mvo> Keybuk: ok, thanks. I wanted to ask first because it's assigned to you
<Keybuk> make sure it still works with pitti's recent derooting frenzy
<lifeless> Kamion: surely thats not enough to be a problem ?
<Kamion> lifeless: it wasn't earlier, and bugzilla has been running like a drain most of today
<lifeless> ah.
<mvo> Keybuk: will do, thanks
<lifeless> so its bugzilla being slow you are concerned about ?
<Kamion> yes
<Kamion> anyway, I shall let others be concerned about it while I sleep :)
<lifeless> woo boy you gpnna love malone ;)
* mvo suspects it's a secret plot to make the switch easier for us
<lifeless> oh, and a pqm test run.
* seb128 took that as a bug triage vacancy
<seb128> no way to do any bug triage with this slowness anyway
<HiddenWolf> seb128, you've got gnome.org bugzilla to work with. :P
<lucas> the wiki is often slow too
<daniels> Simira: Option "Accel" in the Device section should fix it for you
<lucas> can't define "often" and "too" tho ;)
<seb128> bugzilla take like 1min to load a page atm
<seb128> and that's not to commit changes, just to open a bug
<mdz> siretart: acpi-support approved, thanks
<lifeless> ah, macquarie, not hcinstrap. my bad. ,ore caffiene please
<Simira> daniels: I'll try then *reboots*
<lifeless> ok, it is multiple concurrent debzilla syncs
<lifeless> GARH.
<lifeless> I hope the others are blocked on acquiring the lock.
<elmo> it's mostly that insane gpg import
<lifeless> yes
<elmo> I just hope he's using keyserver.ubuntu.com :(
<lifeless> I think I recognize that as the trusted key scan
<Seveas> seb128, wuss, I did bug triage today (through the mailinglist and on average 5 bugzilla pages loading):)
<seb128> Seveas: nice :)
<seb128> I didn't :p
<Keybuk> elmo: could there be a slight accident on macuqarie, that we could blame on the OOM killer, and that unfortunately leaves lock files lying around
<Keybuk> waiting five minutes for a bug status change to submit is ... irritating
<elmo> I think there could be a kill -STOP accident
<Keybuk> oh, that's much better
* mvo goes to bed now
<Simira> daniels : yay, seems to work! Only gdm didn't restart properly. But I can live with that
<daniels> Nafallo: cool
<Stormx2> hey
<Stormx2> are there any plans for a graphical installer for dapper?
<Mithrandir> yes
<Stormx2> Fedora Core Style?
<Nafallo> daniels: can't get it to work whatever I do with that file. any other ideas? :-)
<HiddenWolf> Stormx2, no, livecd-based
<Stormx2> HiddenWolf: I wouldn't really know how that would work! ^.^
<HiddenWolf> Stormx2, search the wiki for ubuntuexpress
<Stormx2> HiddenWolf: OK :)
<Simira> juhuu, I work!
<HiddenWolf> Simira, is that unusual for you?
* HiddenWolf hides
<Simira> HiddenWolf : somewhat
<Nafallo> hehe
<Simira> hm, can I make my webcam work as well? Then it would really make my day...
<Simira> Mithrandir : I don't know what I'm doing. You'd better come help me out on this one
<Simira> Mithrandir : the script said a lot of things I didn't understand
<slomo_> daniels: i can confirm bugzilla #18975 and that the workaround actually fixes the problem... so maybe adding these symlinks is worth a thought :)
<daniels> Nafallo: hrm, not sure, sorry
<daniels> slomo_: yes, been meaning to investigate what's up with that one, but we do have a known workaround
<Nafallo> daniels: want me to upload anyway since it's not more broken than before? ;-)
<HiddenWolf> daniels, what's the status of X nowadays? somewhere halfway between breezy and sanity?
<Nafallo> BenC: wb :-)
<daniels> HiddenWolf: naf	sure, why not ;)
<daniels> hidd	still getting there, yeah
<BenC> terrible, gdm is too close to gpm when you want to do "/etc/init.d/gpm restart"
<HiddenWolf> daniels, any serious breakage coming up? ;)
<Mithrandir> BenC: easy fix, don't use gpm.
<BenC> I can't live without gpm
<daniels> HiddenWolf: nah, not that I'm aware of
<BenC> it's my console buddy
<daniels> certainly nothing on the breezy level of breakage
<daniels> i'd get shot by the community people and fired by mdz
<Mithrandir> BenC: get rid of the console. :-)
<HiddenWolf> daniels, that is sad news. :P
<slomo_> daniels: probably some hardcoded paths... i think this workaround is the only way to get it working again without yelling upstream
<Stormx2> Hey dev guys, what can I do for dev-wise. Should I go and learn a scripting language like Python?
<BenC> Mithrandir: what, and lose touch with my roots? :)
<BenC> Stormx2: see topic
<Stormx2> Repo maintainers, I saw.
<BenC> HelpingWithBugs is what I was talking about :)
<BenC> or do you mean dev-wise as in learning to be a developer?
<Stormx2> Yeah
<Stormx2> I mean I've coded before, PHP-Wise
<BenC> learn something useful, like C
<tseng> -1 Flamebait?
<BenC> it wasn't meant to belittle other languages, just that C is so broad in scope
#ubuntu-devel 2005-11-22
<tseng> http://www.oxygen-icons.org/?cat=3
<tseng> oh hey what does that top row of icons look like to anyone?
<tseng> (and yes that is flamebait)
<HiddenWolf> BenC, bull, it's just the easiest for linguisticly challenged nerds to brag about. ;)
<HiddenWolf> I know C is something they first learned in pre-school. :)
<Stormx3> Back
<Stormx2> Stupid internet.
<Keybuk> elmo: please sync autofs, all Ubuntu changes are in the Debian package
<Keybuk> elmo: also please sync dsdo
<HiddenWolf> poor elmo
<HiddenWolf> he's being worked to exhaustion.
<Keybuk> yeah, those buttons are hard work to push :p
<Keybuk> elmo: and htmldoc
<Keybuk> (was rebuild only)
<Simira> Nafallo : I keep getting you @ubuntu.com mail in return
* BenC unleashes 2.6.15-3.3 on the buildd's
<BenC> we _should_ get a ppc build out of this one
<Nafallo> Simira: oh? nafallo@ ?
<BenC> doko_: ping
<Simira> Nafallo : that's it
<BenC> doko_: FYI, I had to use gcc-3.4 for ppc64, so it ain't dead yet
<Nafallo> Simira: you might want to try later, seems all mail I'm getting now are from several hours ago. might be something odd happening somewhere :-/.
<Simira> Nafallo : It's the second time I got it
<Nafallo> Simira: does it give a reason?
<HiddenWolf> BenC, do you have a massively interesting changelog for us? :)
<Simira> Nafallo : found it. It's rejecting my "@localhost.localdomain" address :p
<Nafallo> lol
<Nafallo> same as I had when I tried to send to you before ;-)
<Simira> Nafallo : but you did get the other mails, right?
<Nafallo> Simira: to magicalforest.se? yes :-)
* Simira points Mithrandir  towards bed
<Nafallo> :-)
<Simira> Mithrandir : you.... feel.... sleepy ... 0_0
<Nafallo> hmm
<Nafallo> that worked on me
<Keybuk> elmo: and pxlib (debian took our changes)
<Keybuk> and reiser4progs (gcc 4 change taken by debian)
<HiddenWolf> that shadow upload fixes 66 bugs in debian?!?
* HiddenWolf jaw-drop
<Nafallo> Keybuk: yay! 24h to faster boot ;-).
<Nafallo> infinity: ping
<Keybuk> elmo: and finally, can you sync zope-debhelper -- not sure why that was even an ubuntu rev
<Nafallo> infinity, lamont-away: could one of you look if there is a dep-wait on plib and clear it please? :-)
<Keybuk> Nafallo: well, maybe 24h
<Keybuk> just been doing some merges
<Nafallo> Keybuk: you still rock :-)
<HiddenWolf> Keybuk, what's in 24h?
<Nafallo> "I'm currently working on a total rewrite of the hardware detection stuff
<Nafallo> that should hit the archive within the next 24 hours or so"
<Nafallo> :-)
<HiddenWolf> Nafallo, which could also mean total breakage. ;)
* HiddenWolf ducks
<Nafallo> that's why I run dapper
<Keybuk> oh, it'll break everything, muahahaha
<Nafallo> it can be exciting ;-)
<Keybuk> well, it'll break anyone not running 2.6.15
<Keybuk> talking of breaking things ...
* Nafallo runs 2.6.15-3 :-)
* Keybuk does a manual mom run to redo those packages hit by a bug I introduced earlier
<daniels> HiddenWolf: 'could'?
<HiddenWolf> daniels, well, I'm giving him some credit. ;)
<HiddenWolf> daniels, could is the polite version of "shall certainly" in this case. ;)
<Keybuk> I am, after all, rewriting it all in Java
<Nafallo> ;-O
<Nafallo> boot-time: 5h :-P
<daniels> Keybuk: dude, what about flash?
<Nafallo> wow
<Keybuk> Nafallo: nothing unusual in yours
<Keybuk> looks pretty much like a stock dapper, without the silly ski-slope xfs produces for readahead
<Nafallo> nope, not yet anyway :-)
<Nafallo> I use ext3 :-)
<Keybuk> shame you don't have earlier, as it'd be interesting to see how much of a speed-up you got from depmod (if any)
<Keybuk> removal of depmod, that is
<Nafallo> I think I installed right after reading your mail about it :-)
<Nafallo> anyway, any new features will be shown in there ;-)
<Keybuk> yeah
<lamont-away> Nafallo: just passing through, but see http://people.ubuntu.com/~lamont/buildLogs/Lists/dapper.all.$arch
<Nafallo> lamont-away: oki, thanx
<Nafallo> yepp, dep-waits
<Keybuk> elmo: please sync analog (change taken by Debian)
<Nafallo> needs to be cleared.
<infinity> Nafallo_away : Cleared.
<elmo> Keybuk: all done
<Keybuk> elmo: thanks
<Keybuk> disregard the /msg ping too ... I was gonna ask whether you had some fancy "find the orig" script, because my "generate a changes file" thing had a typo in it and I wasn't including them for the first few I did this evening
<Keybuk> but then realised that they'd all only been revision changes
<Keybuk> elmo: you missed reiser4progs
<elmo> oh, you didn't prefix it with elmo, so it wasn't highlighted.  done anyway
<tseng> elmo: you tell him
<devint> hey gang
<devint> well, i'm trying my hand at my first ubuntu application, and i was wondering what package do i install to get the gnome headers like gnome.h? gnome-dev doesn't seem to work
<bob2> packages.ubuntu.com allows you to search by filename
<bob2> as does apt-file
<doko_> BenC: that should be fixed with the next 4.0 upload
<Evaso> hi guys any gnome team here?
<HiddenWolf> Evaso, #ubuntu-desktop
<Bicchi> what do i need to install to be able to use gtkmm in ubuntu? 
<sajd> libgtkmm-2.4-dev
<Bicchi> got that allready
<devint> can somebody please tell me where i can find a tutorial to install the gnome development headers like gnome.h and glide.h?
<devint> gnome.h: No such file or directory
<devint> why am i getting that?
<Keybuk> BenC: ping?
<Keybuk> elmo: please sync pxlib
<elmo> Keybuk: huh?  I already did
<Keybuk> hmm, the changes didn't show up so thought I must've missed that
<Keybuk> or is the list server just being slow?
<elmo> dunno, but madison says there's a non-ubuntu version in dapper
<Keybuk> ok
<BenC> Keybuk: ping
<Keybuk> BenC: it seems that the "standard" place for firmware to live has changed
<Keybuk> I just noticed that the new udev looks in /lib/firmware rather than /lib/hotplug/firmware
<BenC> ah
<BenC> Keybuk: that may be a driver trying to be specific about the location
<BenC> or is that coded somewhere else?
<Keybuk> it's coded
<sajd> is the updated 2.6.15-3.3 only for amd64 or are the i686 debs just lagged ?
<Keybuk> we could always just keep using the old path
<BenC> sajd: lagged
<sajd> ok
<BenC> sajd: it's done building, just has to make it's way into the archive
<sajd> cool
<Keybuk> wanted your opinion on which is the best idea, updating to the "new" path or just keep using the old one
<BenC> Keybuk: makes no difference to me
<BenC> changing it would require changes to kernel-wedge I think
<BenC> kernel-wedge or make-kpkg, not sure which one
<Keybuk> most HOWTOs seem to be being slowly updated to the new path, so it might make sense for us to make that change too
<Keybuk> or it might make sense to make that change later
<BenC> if we're going to do it, now's the time :)
<Keybuk> yeah
<Keybuk> we're already dropping /usr/lib/hotplug/firmware and /usr/local/lib/hotplug/firmware too
<Keybuk> so maybe now is the time to just change all the paths :)
<BenC> let's make it happen then
<Keybuk> I can see it being used in kernel-wedge
<Keybuk> ok, fixed the one :)
<Keybuk> nothing in kernel-package about it
* sajd tries new kernel
<Keybuk> BenC: linux-source-2.6.15-2.6.15/debian/post-install has a bunch of references too
<Keybuk> I'll let you change those
<BenC> Keybuk: ok, I'll take care of those
<sajd> the boot-splash was known to be broken right?
<mdz> yes
<sajd> booted fine on my ThinkPad T41, had to revert tho since i need the madwifi drivers :/
<shadeofgrey> hey has anybody seen hidde recently?
* Keybuk reboots into the kernel that linux-restricted-modules forgot
<infinity> keybuk, benC : l-r-m is waiting on the new xorg to actually build, which is waiting on the next glibc upload.
<daniels> and the next glibc upload is waiting on new binutils.
<daniels> (new binutils upstream, at that.)
<pitti> Good morning
<crimsun> just a note: if you use 2.6.15-3.3 and wpasupplicant in dapper with ipw2200, you should modify /etc/default/wpasupplicant to use the wext driver (options="-Dwext") instead of the ipw driver.
<Lathiat> hrm whys that
<Lathiat> ipw got merged and fixed to use wext?
<crimsun> ipw is now in-kernel, yes.
<Lathiat> i assume wext = wireless extensions
<crimsun> yep
<JaneW> **Reminder**  Dapper Development Status Meetings in #ubuntu-meeting in 1 hour.  
<Keybuk> Rejected: linux-wlan-ng_0.2.2+dfsg-6ubuntu1.dsc refers to linux-wlan-ng_0.2.2+dfsg.orig.tar.gz, but I can't find it in the queue or in the pool.
<Keybuk> ^ Anyone want to own up? :)
<crimsun> hmm, main package, not me. :-)
<minghua> Is there any plan about the libfreetype6 ABI change problem?
<minghua> At least the shlib version should be bumped
<fabbione> **Reminder**  Dapper Development Status Meetings in #ubuntu-meeting in 30 minutes.
<mdz> morning
<mdz> marilize: hey, your UBZ photos are not on the wiki yet
<marilize> mdz: hi babes, yes, i know, i have it on F-spot, but i was just trying to figure out how to download everything at once to flickr...
<fabbione> hey mdz
<pitti> elmo: texinfo sync,  please
<pitti> Hi dholbach 
<dholbach> good morning, hi pitti
<seb128> hey dholbach
<seb128> pitti: hi too :p
<pitti> Hi seb128 
<pitti> dholbach, seb128: plesae do not set syncable merge bugs to pending
<seb128> pitti: I had a good question for a french translator yesterday
<pitti> dholbach, seb128: I set them to ACCEPTED now and change the bug title to make it searchable
<pitti> PENDING will confuse MOM
<dholbach> pitti: i see
<dholbach> pitti: thanks for clarifying :)
<seb128> pitti: is there any plan to roll language-pack candidates before the stable monthly update? So translators can play with them and squash some ugly typos and stuff?
<pitti> seb128: hrmnnngpokecarlos
<seb128> pitti: ACCEPTED doesn't really match my workflow
<pitti> seb128: rosetta export is disabled ATM
<pitti> seb128: mine neither
<Keybuk> pitti: I would've thought PENDING is perfect
<pitti> seb128: but if you accept the bug and change the title to 'package foo can be synced', it is not too ugly
<seb128> hi Keybuk
<pitti> Keybuk: but MOM files a new bug when one is pending
<Keybuk> though I guess that's me thinking if a new version comes in, it might make you rethink the "yeah, sync it" thought
<mdz> marilize: a likely story!
<seb128> pitti: no, but PENDING is made for that ..
<pitti> seb128: I know, but MOM doesn't
<Keybuk> does elmo actually read Bugzilla anyway?
<seb128> teach to MOM
<Keybuk> he bitched at me earlier when I assigned some merge bugs to him that needed syncing :p
<pitti> Keybuk: no, it is just to remind me to request syncs
<pitti> Keybuk: so I keep requesting them until they are actually done (then I close the bug)
<seb128> Keybuk: I would say no, I've reassigning a bug for a package removal and pinged him on IRC 3 month later since the package didn't got removed :p
<seb128> same for me
<pitti> Keybuk: I just search for 'sync' and get a package list that I push to elmo
<Keybuk> ah, I use the status whiteboard for that
<seb128> dholbach put PENDING when he ask for a sync and close when the package has built correctly
<Keybuk> I was quite amused yesterday while doing merges
<seb128> which is a slightly different usecase :)
<Keybuk> I'd forgotten just how much mom's output was optimised for my workflow <g>
<fabbione> 3 minutes to meeting
<Keybuk> made me wonder how everyone else processes them, and whether they've adopted something similar to mine, or come up with different ways of doing it
<pitti> Keybuk: I used pending, but then we had that big confusion with several bugs about a package
<seb128> I put PENDING when I ask to elmo on IRC
<seb128> I don't close them because he's not always around and sometimes I've to ask again
<seb128> this way it's clear the bug is beeing worked, and it's easy for me to know what bug should be fixed now
<pitti> seb128: that's what I mean, pending won't be respected by mom, she will file a new bug on further changes
<fabbione> *** 1 MINUTE ***
<Kamion> Keybuk: maybe in that -devel-announce post you might like to emphasise *why* you've made that change ...
<seb128> teach to it
<marilize> mdz: ja ja, whatever, will let you know when its done! I
<Keybuk> Kamion: which post?
<Kamion> Keybuk: the MOM -MERGE change
<Keybuk> the one I quickly deleted out of the queue again? :p
<Kamion> heh
<Keybuk> because it didn't work
<Keybuk> making invalid source packages means mom can't produce debdiffs <g>
<mdz> BenC: development meeting is beginning on #ubuntu-meeting right now
<Kamion> pitti: so ca-certificates is required for libcurl3 nowadays:
<Kamion> +  * Started using the system-wide CA certificate file (closes: #308514).
<pitti> Kamion: saw it, should not be a problem, but I'll take a look at it
<Kamion> pitti: is this a relatively non-crackful thing for main?
<Kamion> ok, thanks, we need this sorted out today one way or the other
<pitti> Kamion: I'll clean up anastacia today
<pitti> Kamion: a bunch of well-known CA certs is certainly worthwile for main; I wonder whether Firefox has its own copy?
<Burgundavia> Keybuk, NM and atheros don't like each other?
<seb128> pitti: uploading 0.9 package would require some packaging work, NEW process, Conflicts/Replaces, etc
<pitti> seb128: no, not uploading, just for me
<Burgundavia> Keybuk, only on resume from hibernation I have found
<seb128> pitti: the Debian maintain has decided to wait for 0.10 to upload, first week of december
<pitti> seb128: but it's not that urgent
<seb128> pitti: hum, I can probably get you that next week
<pitti> seb128: I have lots of other stuff to play with, so never mind
<Kamion> pitti: we can ask Diziet when he wakes up
<Kamion> Keybuk: udev> intersection of Debian and SuSE rules, not union?
<pitti> Keybuk: now that we have 2.6.15 to play with, what's the plan with uploading udev?
<pitti> Keybuk: I also need to update hal for the new kernel
<pitti> and we should get these changes in pretty early IMHO
<pitti> infinity: speaking of mass-rebuilds, we finally have openssl 0.9.8 in dapper main; do you have a clever script to do the mass rebuild?
<sivang> Good morning
<pitti> Hi carstenh 
<pitti> moin carlos 
<pitti> carlos: is rosetta export running again?
<carlos> pitti, not yet
<carlos> I will try to fix it later today
<carlos> with latest version of our codebase
<carstenh> hi pitti 
<pitti> mvo: https://launchpad.net/distros/ubuntu/+spec/language-pack-vs-support requires changes to the lang selector - how many dev days do you estimate for that?
<mvo> pitti: please ping me again after the meeting, I'm not sure about the scope of the changes
<pitti> mvo: it needs to additionally install openoffice.org-l10n-lang etc. for translation support
<Keybuk> Kamion: uh, did I answer your question before my ISP decided to explode?
<seb128> pitti: one of the current installability issue is libcurl3 Depends on ca-certificates which is universe, are you working on it?
<Burgundavia> Keybuk, did you get my comment about atheros and NM?
<seb128> it breaks vorbis-tools, openoffice2.org and probably some other stuff
<pitti> seb128: that's anastacia covered, will do it today, and work with Kamion
<Kamion> Keybuk: no
<Keybuk> Burgundavia: what was your comment?
<pitti> seb128: I don't expect any problems for main
<seb128> pitti: what is anastacia?
<mvo> pitti: if that is all, it shouldn't be more than a day (at most)
<Kamion> seb128: http://people.ubuntu.com/~mdz/anastacia.txt
<pitti> seb128: http://people.ubuntu.com/~mdz/anastacia.txt
<pitti> oops
<seb128> thanks
<Burgundavia> Keybuk, NM works for me on initial boot but fails on resume from hibernate (on wireless that is)
<Kamion> seb128: automatic report of inconsistencies between germinate output and the actual contents of main/universe
<seb128> I look on http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html usually
<Kamion> seb128: both are useful
<Burgundavia> Keybuk, that the problem you are referring to?
<pitti> that's installability
<Keybuk> Burgundavia: Atheros can't do a scan and hold on an AP ... so every 30s when NM does an essid scan, atheros cards forget their essid/ap/key settings and drop off the network
<Burgundavia> hmm, never seen that
<pitti> seb128: anastacia evaluates main vs. universe inconsistencies
<seb128> pitti: yeah, I though that installability what was matter to roll a CD :)
<Kamion> anastacia-reported inconsistencies often lead to uninstallability, but sometimes to unbuildability
<seb128> pitti: gotcha, thanks
<Keybuk> Kamion: there's strange crack in the names outside of the intersection ... names randomly assigned for no noticeable reason, I figure the intersection is a sane base and then decide to rename things later
<Kamion> seb128: it's kind of like fixing symptoms versus causes, depending
<Kamion> Keybuk: hm, ok
<Keybuk> like /dev/umad => /dev/infiniband/0
<Keybuk> things we don't have explicit NAME= rules for just get the default kernel-assigned name
<minghua> dholbach: ping
<dholbach> minghua: pong
<mvo> pitti: this "sudo test thing" can probably solve a few issues we have with gksudo as well, right?
<minghua> dholbach: do you plan to do anything about libfreetype6?
<pitti> mvo: might be
<Kamion> doko: is hplip ok for main? anastacia wants to promote it, it just needs an "ok" not a report
<mvo> pitti: like testing before the run if the user actually has to type a password
<minghua> dholbach: at least bump the shlib version?
<pitti> mvo: no, that won't work
<pitti> mvo: sudo -t will never ask for a password
<minghua> dholbach: it really should be renamed to libfreetype6a or something
<pitti> mvo: oh, wait, you mean for the 5 minute ticket? I thought it already does that?
<Kamion> doko: if so, we'll also end up pulling qt into desktop, which is suboptimal
<Kamion> however it may be better than no CD build
<dholbach> minghua: i will talk to the debian maintainers... i'd really like to be in sync with them
<mvo> pitti: right now we don't deal with NOPASSWD in sudoers well, I was wondering if that change could help us here as well
<Keybuk> isn't a "sudo test" an absolutely gaping security hole that would allow any user process to spin testing sudo until the user enters a password, then exploit it while the ticket is till open? ...
<mvo> pitti: but apparently not :/
<Kamion> Keybuk: it could do that anyway
<minghua> dholbach: okay, thanks
<pitti> Keybuk: the only thing 'sudo -t command' does is to check whether the user has the privilege to do so
<doko> Kamion: Mithrandir did want to look at it today, but temporarily adding it might be ok as well (if space permits)
<Keybuk> Kamion: true, but it'd show up a lot in the log
<pitti> Keybuk: it's the same as trying 'sudo command' right away
<seb128> minghua: there is not a lot to do, we probably don't want to diverge from Debian for something like that
<minghua> dholbach: I'm keeping libfreetype6 hold here in my dapper, hoping to catch anything wrong
<Kamion> Keybuk: we could make sudo -t log too, if it doesn't already
<pitti> Keybuk: (but without a password)
<Kamion> although I guess that'd be a lot of log noise
<Keybuk> pitti: does it show up as an intrusion in the log if the user doesn't have privilege?
<Kamion> (for menus)
<pitti> Keybuk: and the spin testing is already there
<seb128> minghua: what is wrong with the new version? you use .app applications?
<pitti> Keybuk: no
<minghua> seb128: I understand it's a Debian problem
<Keybuk> see, that's what worries me
<infinity> pitti : Yeah, but we already have "sudo -l" which won't tell you what you are allowed to run until AFTER you're authenticated.  Surely, there must have been a reason for that.
<Keybuk> otherwise you may as well just make sudoers readable by everyone
<pitti> Keybuk: you can already have a process that ptraces other processes to check whether they can sudo
<Kamion> infinity: sudo -l tells you EVERYTHING, sudo -t is just one command
<Keybuk> the reason it's not is that you're not supposed to be able to find out whether or not you have permission to do something
<pitti> infinity: right, because that would be an information disclosure
<minghua> seb128: no, I don't use .app stuff, but Chinese users generally have more unofficial packages installed
<infinity> Kamion : Sure, but if what you really want to know is "sudo -t su -", you win. :)
<pitti> infinity: but for -t you have to specify the complete command with arguments, so it's not an info disclosure
<Kamion> infinity: it's just a logging question though
<Kamion> infinity: if sudo -t logs, that's no different from just trying it
<seb128> minghua: get those package officially to the distro so we can consider them
<minghua> seb128: and now it's hard to tell if the are using a package linked to 2.1.10 while using 2.1.7
<Kamion> but we are going to end up with a lot of log noise whenever a non-rootly user logs into GNOME
<Keybuk> but sudo foo logs for a reason ... so a sysadmin can tell a user tried to run something they have no privilege to do
<Keybuk> shortcutting that seems wrong
<Kamion> I dunno, I thought this was better than the previous suggestion in the spec
<Kamion> perhaps I was wrong
<minghua> seb128: by unoffical I mean both unoffical softwares and unofficial versions
<pitti> Keybuk: how should it be dangerous to check whether I can execute something as sudo?
<pitti> Keybuk: i. e. why should I log that?
<Keybuk> pitti: it allows a hacker to "test" the system for weaknesses
<seb128> minghua: that's not a distro issue, you can't expect us to make sure than unofficial software we don't know about work fine
<minghua> seb128: some people distribute the same packages in archive but some additional patches
<Keybuk> and escape detection
<Keybuk> sudo logs for a reason
<seb128> minghua: that's their issue imho
<minghua> seb128: I'm not trying to make a big fuss about it
<infinity> pitti : "sudo -t foo && sudo foo" circumvents your running of "sudo foo" and getting logged for not being allowed.
<pitti> Keybuk: true, but in this case it is a weakness that is clearly intended in sudoers
<seb128> minghua: if they choose to do that instead of working the distro they have to assume the distro changes
<Keybuk> pitti: it's not clearly intended, because sudoers is not world-readable
<Keybuk> if you were supposed to be able to find out "for free" who can do what, sudoers would be open to all
<pitti> infinity: I'm open for better ideas
<seb128> minghua: yeah, just making clear that they have to take responsabilities for what they do
<pitti> Keybuk: you won't get a list of commands each user can execute
<minghua> seb128: okay, thanks for the explanation
<pitti> Keybuk: you can just brute force
<Keybuk> pitti: but you may as well
<Keybuk> you could just take the password off "sudo -l" for the same effect
<infinity> pitti : Sure, but in most cases, you're interested in a pretty specific set of commands (like "su -")
<pitti> Keybuk: no, that's not the same
<Keybuk> pitti: it is
<seb128> minghua: anyway no lib should breaks its ABI without changing the soname, but that's an upstream issue, we don't want to change the soname over Debian/Upstream
<Kamion> Mithrandir: is hplip going to be a quick thing, or should I start the process of adding it to desktop?
<infinity> pitti : I'm not looking for the user who's allowed to restart apache, but do nothing else. :)
<Keybuk> you're not supposed to be able to find out what users can and can't do without trying
<seb128> minghua: we would make ubuntu binary uncompatible with those
<pitti> Keybuk: sudo -l without password would give you the allowed commands right away
<Keybuk> that's like being able to find out whether a username exists on a server using ssh
<pitti> Keybuk: whereas with -t you have to find them out
<minghua> seb128: yes I understand the "keep sync with upstream/debian" thinking here
<Keybuk> instead ssh does the right thing, and pretends the user exists whether it does or doesn't
<Keybuk> pitti: for cmd in /usr/bin/*; do sudo -t $cmd && echo $cmd; done
<Keybuk> easy
<pitti> Keybuk: no
<pitti> Keybuk: sudo can be restricted to certain parameters
<infinity> pitti : I understand what you're arguing, but if you want root on a machine, you're going to test for a tiny subset of commands at first, and probably find someone who can run one of them.
<Keybuk> sure, but in our default configuration, it's not
<pitti> infinity: true
<infinity> pitti : Which isn't much less information than what you get from -l
<minghua> seb128: but a shlib version bump won't cause too much incompatibility, will it?
<pitti> infinity: but all we talk about is information disclosure
<minghua> seb128: and if debian bumps as well, we can always catch up
<pitti> but since we *want* to have a small disclosure in order to get the spec, we have to sacrifice a bit
<infinity> pitti : "userbob can run 'su' as root" is pretty good information.  Knowing anything beyond that is pointless. :)
<pitti> alternatively I could add logging to sudo -t
<Keybuk> I think the spec is wrong if it requires forgoing the entire point of having the security in the first place
<pitti> Keybuk: if I add logging to sudo -t, how much would that change?
<pitti> Keybuk: IMHO nothing at all
<pitti> if an intruder can get root, he can disable/remove the logging himself
<infinity> For the average system, it changes nothing.  For the paranoid log hunters, it changes a lot.
<Keybuk> if an intruder can get root, you have a bigger problem
<infinity> pitti : Remote syslogging, etc.
<infinity> pitti : Not everyone logs sudo locally.
<pitti> anyway, I can add logging if you want
<Keybuk> the point is that it allows me to find out whether an intruder is *trying* to get root, and take appropriate action on the compromised account
<pitti> but it would generate a lot of clutter
<seb128> minghua: no, shlibs bump would hurt
<seb128> s/would/wouldn't/
<Keybuk> I'd rather have the chatter than not be able to find out that an account on my server had been compromised and the intruder was trying to use sudo to get root and testing various parts of the system
<pitti> infinity: that doesn't really convince me TBH
<seb128> minghua: but we should get that done on the Debian side
<infinity> And yes, the logs will be nearly useless for "checking to see if I'm being pen-tested" on a graphical system that uses sudo -t all the time. :/
<pitti> infinity: if somebody is really that paranoid and reads sudo logs, he will give sudo privs very carefully, otherwise it is just pointless in the first place
<minghua> seb128: sure.  I'll probably ping Debian maintainer, then
<pitti> Keybuk: k, no problem
<Kamion> mm, I'm coming round to Keybuk's POV here
<infinity> pitti : True, but this feature is a big gotcha to anyone who's used to sudo's previous behaviour and doesn't know it's been introduced.
<Keybuk> even if I didn't think there was any way the intruder could get root, I'd want to disable the account anyway
<minghua> seb128: thanks for your time.
<seb128> minghua: thanks
<Keybuk> not to mention inform the real owner that it's time for them to revoke their gpg/ssh keys, etc.
<Keybuk> if you make sudo hide intrusions, you've broken it
<seb128> minghua: you're welcome
<pitti> Keybuk: why hide intrusions?
<infinity> pitti : And, while the logging may be next to useless on a GUI system (with how we're planning to use it), adding this extra sudo option to a server box without logging it would make me very nervous.
<Keybuk> pitti: the attacker would use "sudo -t ..." on things rather than "sudo thing" and show up in the log
<Keybuk> you'd be letting them test the system and get away with it] 
<pitti> Keybuk: but at that time the intrusion already took place?
<pitti> anyway, I don't mind adding the logging
<Keybuk> pitti: exactly
<Keybuk> so I, as a sysadmin, need to disable accounts and stuff
<infinity> pitti : Intrusion t othe user account took place, not necessarily root priv elevation.  (knowing how to get into someone's account doesn't necessarily mean you know their password)
<Keybuk> but I can't
<Keybuk> because the evil pitti decided that sysadmins no longer need to know about suspicious user behaviour
<infinity> pitti : So, those hints are very useful for disabling accounts double-time, and then starting an audit.
<Keybuk> so that compromised user doesn't show up as doing anything naughty
<Keybuk> a user trying to sudo things who isn't allowed _is_ suspicious behaviour
<Keybuk> in fact, every time I've seen it, it's been a compromised account
<infinity> (or a typo)
<Keybuk> (or me typo'ing and showing up in my own logs)
<pitti> Keybuk: maybe, but what other chance do we have to find out whether or not an user can execute stuff in the admin menu?
<pitti> Keybuk: this is a general goal conflict
<Keybuk> pitti: why not just look at the user's groups and hardcode the knowledge of which one "by default" gives admin privileges
<pitti> Keybuk: that's not enough
<Keybuk> sure it is
<pitti> Keybuk: warty did not have the admin group
<seb128> Keybuk: we already do that
<Keybuk> add it
<pitti> Keybuk: and admins can configure sudo differently to not use admin
<Keybuk> *shrug* users can do all sorts of silly things to their system, doesn't mean we should support them
<pitti> testing for admin group would only cover the default case of Ubuntu
<Keybuk> fundamentally breaking the security between root and user is not the solution
<pitti> Keybuk: carefully restricting sudo perms is not silly
<Keybuk> we only support the default case of Ubuntu
<mvo> Keybuk: it will hurt people that run a system that was upgraded since warty, we hadn't had the group back then
<infinity> Eventually, we have to give up on warty upgrades.
<infinity> It was called warty for a reason.
<Keybuk> pitti: it's certainly not sillier than giving attackers a free way of finding out what they can do on a system
<pitti> Keybuk: so you mean we should only give people the rough distintion between 'can do everything' and 'nothing'?
<pitti> Keybuk: as I said, I can add logging to sudo -t, no prob
<Keybuk> I'd rather that than break sudo
<mvo> Keybuk: mind if I reassign #19728 to you? it's basicly "please implement dpkg triggers"
<mvo> infinity: point taken
<Keybuk> mvo: *shrug* I don't do dpkg stuff in Ubuntu -- iwj seems to own that here
<infinity> pitti : Logging of sudo -t would make me happy, but this is only because I don't give a hoot about security on most desktop systems.  I doubt everyone will feel the same way.
<mvo> Diziet: mind if I reassign #19728 to you? it's basicly "please implement dpkg triggers"
<mvo> Keybuk: thanks
<pitti> infinity: if you use sudo under X on a desktop, then you already sacrifice more securiy than you could ever lose without sudo logging
<infinity> pitti : On a desktop system, where we slam out a billion sudo -t requests all the time, it becomes less effective. :/
<infinity> pitti : Fair point.
<pitti> infinity: so frankly, I don't care about the desktop case
<pitti> but I see your point in using sudo on servers
* Keybuk neither
<Keybuk> I couldn't care less whether it logs or not on the desktop
<infinity> pitti : For the server case, I'm happy with it logging, it effectively makes sudo -t a more userfriendly way of doing "sudo foo || echo 'damn, it broke'"
<Keybuk> it's the server I care about, where sudo is pretty much the standard tool for getting root
<pitti> infinity, Keybuk, Kamion: ok, so we agree to add logging to -t and keep the current spec?
<infinity> Well, that's three whole people who agree.  Quick, make it log, and upload it!
<Keybuk> and I don't see an easy way of breaking sudo on the desktop while leaving it intact on the server
<Kamion> as far as the spec goes, I'm happy with either adding logging to -t or (holding my nose) hardcoding the group knowledge
<Kamion> sorry, dowledge
<Keybuk> why holding your nose?  you're back from Quebec now
<infinity> Keybuk : Logging with -t seems to be the compromise you'd want, there.  (nothing changed on the server side, hideously broken on the desktop)
<Kamion> if we do the latter we should document why so that somebody doesn't come along later and replicate the same mistake
<Keybuk> infinity: yeah, if it logs more than one "test" per login -- there's a gnome-panel bug to fix
<infinity> Hardcoding group knowlege is terribly inelegant, I'm fine with "-t", as long as it logs the same way as "sudo foo"
<pitti> Keybuk: one test per desktop file
<Kamion> Keybuk: there are tests for a couple of different things, so it'll be more like three or four than one
<Keybuk> pitti: yeah, that's what I figure it sane
<pitti> Keybuk: since somebody might be entitled to run network-admin, but not users-admin
<Mithrandir> Kamion: hplip> I think we're going to keep the merge, as Debian has merged and there's just python-qt3 which needs to be put into main.
<Kamion> pitti: we should make the panel test once for each general category, for efficiency reasons if nothing else
<Keybuk> not one test per desktop file per menu open
<pitti> Keybuk: no, of course not per menu open
<Kamion> Mithrandir: which means libqt in desktop
<Keybuk> 'cause if the panel is re-testing everything every time a menu is opened, a gnome-panel bug of old has reared it's head again :p
<Mithrandir> Kamion: we don't want that?
<seb128> Mithrandir: what is this ugly hplip stuff?
<Kamion> Mithrandir: we've successfully resisted it since warty
<infinity> Mithrandir : Prefereably not.
<Mithrandir> Kamion: ok, I can just skip building the control panel and stuff?
<Mithrandir> seb128: HP inkjet support
<Keybuk> you can build it and stick it in a separate package not-in-desktop?
<Kamion> Mithrandir: doko said that that was the only interface to that functionality at present
<seb128> Mithrandir: I've a menu item for it which start a really ugly dialog saying that I have no HP printer configured
<seb128> and just exit
<Mithrandir> heh, how.. useful.
<infinity> Quite.
<infinity> Please, just split the package.
<seb128> where I have an HP printer configured ... (Deskjet 930C)
<Kamion> we could also downgrade python-qt to a Recommends or Suggests
<Kamion> recalling the Debian tech-ctte decision on cardinfo
<Nafallo> cli is of as much use as the qt-crap from what I've seen.
<infinity> (and remove the .desktop file)
<Mithrandir> Kamion: it's still the issue of it installing a desktop file, which it doesn't in Debian, but that's easily fixed.
<Kamion> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517
<infinity> Kamion : Ahh, memories.
<doko> Mithrandir, Kamion: that would be possible as well, the core does not depend on qt, and if you don't delete the generated .py files, you don't need the python-qttools as well
<Kamion> (page down to the end, it's enormous)
<Mithrandir> Kamion: oh, the pcmcia-cs tech-ctte stuff.
<Mithrandir> Kamion: yeah, sure, we can demote it and not install the .desktop file?
<Kamion> doko: which of the hp-* binaries in /usr/bin/ need python-qt?
<Kamion> just hp-toolbox?
<seb128> Mithrandir: yes, please drop the menu entry
<Kamion> doko: will compileall.py blow up in the postinst if we don't have python-qt?
<doko> Kamion: hp-unload and hp-toolbox
<Mithrandir> seb128: done.
<doko> Kamion: it should not
<Kamion> right, settled then
<Kamion> Mithrandir: doit :)
<seb128> Mithrandir: thanks
<Kamion> we might also want to make those tools print a helpful message if python-qt isn't installed
<Kamion> they already have an 'if not utils.checkPyQtImport():' that we could trivially piggy-back off
<doko> Kamion: I'm assigning a bug report to me about these things, won't do them now
<Kamion> doko: it's today-urgent, so if you don't have time, let Mithrandir do it
<Mithrandir> I'm doing it _now_
<Mithrandir> as in, the changelog is written, I just need to build and test, really.
<doko> Kamion: yes, besides the helpful messages in each and every tool
<Kamion> Mithrandir: thanks, I'll handle the seed/*-meta changes
<Kamion> doko: two tools, per your earlier comment
<pitti> infinity: easy - the change involved reverting three patch hunks, easy :)
<pitti> hm, yay word duplication
<Kamion> and it's a one-liner in each case
<ddaa> hey pitti
<ddaa> I heard you are the printing guy around.
* pitti sings LALALALAAA and tries to not listen
<pitti> wb JaneW 
<JaneW> pitti thanks
<JaneW> seems like hylafax was causing my problem...
<JaneW> I uninstalled and things seem back to normal now :)
<ddaa> pitti: just wanted you to know that I have compiled and installed gutenprint-4.99-cvs-whatever from debian testing on breezy, and, well, it appears to just work.
<ddaa> Except for the annoyingly long and ugly printer names.
<pitti> ddaa: oh, gutenprint is the successor to foomatic, right?
<ddaa> successor of gimpprint
<pitti> ddaa: I happened to do some cupsys changes, but I'm not really an expert in drivers
<ddaa> I'm not too clear how all those bits relate, though :)
<ddaa> pitti: well, I though you would be the best person to put that datum into.
<pitti> ddaa: so you suggest to replace gimp-print by gutenprint?
<ddaa> Now I can get my Epson Stylus CX3650 to work right. (before that, it would not ever use cyan, at all).
<ddaa> pitti: well, if you can stick that into dapper, improved printer support is kind of a sensical business feature :)
<Kamion> I understood gutenprint was on the merge queue already
<ddaa> Then all is fine.
<pitti> thanks ddaa!
<ddaa> Might be nice to have a backport though.
<Kamion> rearranged package names are typically awkward to backport
<Kamion> but to some extent that's up to the backports guys, anyhow
<ddaa> Kamion: the debian packaging keeps the old name.
<ddaa> the only glitch I had was a stray gimpprint-something-data package left around broken after dpkg -i.
<Kamion> it ships a lot of *gutenprint* binary packages as well
* ddaa checks
<Mithrandir> Kamion: uploaded.
<Kamion> Mithrandir: thank you
<Treenaks> didn't they change names?
<ddaa> Mithrandir: right, the source package produces a bunch of gutenprint packages and a couple of transitional gimpprint packages.
* ddaa goes back to something he knows what he talks about
<viviersf> why did you guys deside to make usplash
<viviersf> and not to use bootsplash
<viviersf> just out of my own curiocity ?
* Mithrandir sends ddaa a ICMP REDIRECT Kamion
<Treenaks> viviersf: because bootsplash is a kernel patch; usplash is all user-level code
<viviersf> and that helps why ?
<Kamion> viviersf: bootsplash was way too intrusive; for example when we tried it out in August 2004 it broke our installer
<Treenaks> viviersf: kernel patches are scary, and likely to break when new kernels arrive
<Kamion> in ways extremely non-trivial to work around
<Kamion> usplash meant that we could enable it much more selectively, and hack it more easily
<Kamion> ddaa: I'm not sure they're entirely transitional - they seem to have real content - but I haven't looked at it in detail and don't intend to do so today. :-)
<pitti> mvo: <pinging back after the meeting> 
<ddaa> NP, worksforme, just wanted to share experience
<Kamion> sure, thanks
<pitti> mvo: I don't know the langselector code, but do you think that half a day is enough to get the additional installation of translation packages?
<Kamion> seb128: does gnome-panel just need a retry on powerpc/ia64, do you think?
<Kamion> checking for CLOCK... configure: error: Package requirements (gtk+-2.0 >= 2.7.1 libgnomeui-2.0 >= 2.5.4 libecal-1.2 >= 0.0.97 libedataserverui-1.2 >= 1.2.0) were not met.
<Kamion> ^-- powerpc
<pitti> infinity: urgh, now I get an email about each failed sudo -t attempt
<seb128> Kamion: let me have a look
<Kamion> seb128: OTOH build-deps seem sufficient ...
<Kamion> thanks
<pitti> JaneW: ok, all my specs but one (which depends on mvo) have time estimates now
<JaneW> pitti" awesome thanks, you are a star!
<Kamion> infinity: can you give-back curl/powerpc? the build seems stalled
<JaneW> pitti: is it dependant on one of mvo's goals or just on mvo in general?
<pitti> JaneW: I hope that he can do the language selector changes since its his code
<seb128> Kamion: nothing obvious, please give it a retry. If it doesn't work I'll debug (do we have a ppc chroot somewhere?)
<Kamion> seb128: davis
<Kamion> seb128: retrying, thanks
<seb128> np
<mvo> pitti: I'll do the changes, no problem. I just need to have a look at the spec again about the scope 
<mvo> ^---- JaneW 
<pitti> mvo: thank you very much 
<JaneW> mvo / pitti: ok thanks
<pitti> Kamion: the part of installer which displays the 'download additional language support' needs a string change to point out that this also includes translations for various packages (OO.o, Firefox, and Thunderbird in particluar); shall I file this as a bug?
<slomo_> elmo: please sync gtkhtml from debian/unstable... ubuntu changes can be dropped
<Kamion> pitti: yes, archive-copier; but I don't like being that specific about distribution details, just file a bug saying it needs improvement to handle that case better
<pitti> Kamion: ok, thanks
<zyga> morning
<Kamion> seb128: could you rebuild epiphany-extensions against libosp4c2, please? (it's currently libosp4)
<Kamion> I'll do openjade and openjade1.3
<seb128> Kamion: sure
<Kamion> thanks
<seb128> np
<Mithrandir> Kamion: can you grab something else?  I'm looking at it already.
<viviersf> Kamion, the installer
<viviersf> which part detects windows xp 
<Mithrandir> Kamion: seems just to be a rebuild required, though.
<viviersf> for mutli boot ?
<Kamion> Mithrandir: ok, that and openjade1.3 then; for openjade I suggest you revert to the Debian version
<Kamion> Mithrandir: (the libosp C++ transition seems to have been a bit botched in breezy)
<Kamion> viviersf: os-prober, with help from the bootloader installer packages
* Kamion claims tex4ht
<viviersf> thx Kamion 
<Kamion> and if somebody could take wv2 (just needs a rebuild against new libgsf, I think?), I'd be grateful
<viviersf> btw Kamion thx for the help with generic module loading, it helped allot
<Kamion> cool, np
<seb128> Kamion: will do wv2
<Kamion> ta
<seb128> Kamion: wv2 should be synced from Debian
<seb128> elmo: please sync wv2
<viviersf> hmmm Kamion no package contains : os-prober
<Kamion> viviersf: apt-get source os-prober
<Kamion> viviersf: do not expect pieces of the installer to be available as .debs
<viviersf> nope
<viviersf> just forgot to click on the : source packages 
<viviersf> tick box :)
<viviersf> old habbit of mine
<viviersf> when i look for source
<viviersf> i download via web
<seb128> I'm away for less than 1 hour, bbl
<Kamion> pitti: not to are-we-there-yet you or anything, but ca-certificates: are we there yet? :) I've done a first pass over the uninstallables and I think it's the only one that's still a major problem for CD builds
<mvo> emacs complains about "Undefinied color" in dapper. does anyone knows a fix?
<Mithrandir> Kamion: hmm, openjade1.3 seems fine to me?
<Mithrandir> mvo: make it depend on xrgb, possibly.
<Kamion> Mithrandir: it depends on libosp4?
<mvo> Mithrandir: thanks, but that's installed
<Kamion> Mithrandir: oh, powerpc is just out-of-date
<Kamion> Mithrandir: in fact everything is out-of-date
<Mithrandir> Kamion: ah, ok, and libosp4 still exists.
<Mithrandir> (hence not uninstallable)
<pitti> Kamion: 'k, rescheduling :)
<Kamion> Mithrandir: I've kicked rebuilds
<Kamion> infinity: never mind, I've kicked curl, looked stale
<Mithrandir> Kamion: so I shouldn't touch openjade1.3 at all?
<Kamion> Mithrandir: right, should be fine after a rebuild
<Kamion> Mithrandir: I only noticed it because it had a knock-on effect on sgml2x
<Mithrandir> Kamion: ok
<pitti> Kamion: ok, the package seems highly useful and does not contain any binaries (arch:all)
<pitti> Kamion: it creates a whole lot of symlinks in /etc/ssl/certs which might be regarded as clutter, though
<Kamion> well, it clearly has an effect on packages' security policy
<Kamion> hence asking you :)
<Kamion> I'm not bothered about the symlinks per se
<pitti> Kamion: it means that packages looking for cert validation will regard certs signed by these CAs as trusted, probably
<Kamion> hm, it asks its "new certificates" question at critical priority
<pitti> this might not always be intended, though
<Kamion> oh, maybe not
<pitti> Kamion: I got no questions
<Kamion> sorry, was wrong
<Kamion> by default it trusts all new certificates
<pitti> Kamion: I'd rather disable these symlinks, they make me a bit nervous
<pitti> but maybe that's just my wrong gut feeling
<pitti> providing these certs to mozilla seems ok
<Mithrandir> I'm investigating libapt-front (and tagcoll)
<Kamion> so you'd like to change the default for trust_new_crts to "no"?
<pitti> but at least I use /etc/ssl/certs for my own certs
<pitti> Kamion: I just looked at the pkg for two minutes, I guess I need some more time
<Kamion> I think /etc/ssl/certs is the only mechanism it has for providing certificates to applications
<Kamion> as the system-wide certificates directory
<pitti> it installs certs into the mozilla dir as well
<Kamion> I don't see that in the postinst?
<pitti> Kamion: but since the package will be installed by default, we should be a bit more careful
<pitti> Kamion: oh, might be my fault - I misread /usr/share/ca-certificates/mozilla/ as /usr/share/mozilla/...
<Kamion> right, I don't think mozilla looks there
<pitti> hmm - so a cert that is signed by one of these CAs will be trusted if the CA is in /etc/ssl/certs probably
<Kamion> believe so
<Kamion> as I say we can trivially disable that by changing the default to "no", but it will be awkward to transition from that if we change our minds later
<Kamion> we could say "yes, but we'll audit the list of certificates before dapper to ensure they're sane"
<pitti> Kamion: hm, having these certs from a trusted Ubuntu package might be useful, but I don't know how many people trust Ubuntu packages as well as the certs themselves
<Kamion> they're trusting the browser, which we provide
<Diziet> mvo: Just seen your activity on 19728 (`defer font cache ...').
<pitti> Kamion: or rather, they probably trust our libssl package
<Kamion> pitti: right
<Kamion> if they build it themselves, they can point it at a different certificates directory (/etc/ssl/certs isn't the upstream default, IIRC)
<Diziet> mvo: I agree that triggers (I used to call them hooks) would help with this.
<pitti> hm, since very few people will do the maths by hand, it seems that trusting the certs and trusting the libssl package are the same, so we might as well just go your way
<pitti> Kamion: ok, so we should check the certs after UVF and sync freezes, I guess
<Kamion> pitti: I'm not sure I have "my way" as such, but ok :)
<mvo> Diziet: what do you think, is it something hard to add (given that it's not done yet, it seems to be :)
<pitti> Kamion: <Kamion> we could say "yes, but we'll audit the list of certificates before dapper to ensure they're sane"
<pitti> Kamion: this was what I meant
<Kamion> pitti: ok. I've made a note in wiki/UpstreamVersionFreeze
<Kamion> pitti: ok to promote, then?
<pitti> Kamion: yes, fine for me
<Kamion> done
<Kamion> (thereby proving that the quickest way to get something into Ubuntu main is to make something crucial depend on it in Debian in a way that's awkward to remove ...)
<Diziet> mvo: So yes, I would like to do it.  OTOH I'm not sure what the priority of it ought to be.  I've got a few high priority feature goals on my plate, obviously.  I should probably see how I get on with those first.  Unless you think we can persuade mdz/sabdfl that this is important to sort out.
<mvo> Diziet: it would be interessting to measure how much time we could save on a regular install/dist-upgrade by postponing the "ldconfig/fontcache/scrollkeeper" stuff to the end
<pitti> jordi: ping
* mvo vaguely remembers that the installer does some tricks here already
<Kamion> yes, for scrollkeeper (it diverts scrollkeeper-update and runs it later)
<Diziet> mvo: That's an easy thing to measure: just stub it out for the installation and then run it at the end by hand.
<Riddell> seb128: how do you let all malone bugs through to desktop-bugs without having to approve each From address?
<zyga> mvo: that's a good idea
<Diziet> kamion: Eeeewww.
<Kamion> is ldconfig safe to run at the end?
<Kamion> Diziet: yep, it's ugly - saves a lot of time though
<Diziet> kamion: I'm not sure.  I remember thinking about that the other day.
<zyga> also if anyone is looking at the installer
<zyga> if you choose non-english locale perl complains alot
<Kamion> scrollkeeper-update is O(n^2) to run as-you-go, because it doesn't cache things
<Diziet> Well, yes, it would.  I'm not saying it shouldn't have been done.  Just grimacing :-).
<zyga> (about missing locale, since it's generated later)
<Kamion> zyga: as in, on initial install?
<zyga> Kamion: yes
<zyga> it's nothing dangerous but it litters the screen alot
<zyga> I thing it's safe to default to C until the locale is actually generated 
<Kamion> AFAIK we generate the locale before anything interesting is done in /target
<zyga> hmm
<Kamion> if that's not the case then it's a bug
<Kamion> at what point exactly does perl complain, and where are you seeing this?
<Kamion> and what version of Ubuntu are you installing?
<zyga> Kaminon: I'll install breezy on a spare box today and confirm this, okay?
<Kamion> sure
<zyga> breezy
<zyga> I'm sure it was before the reboot
<Diziet> Anyway, I was going to go out this morning to buy a bigger buffer cache.
<zyga> in fact, I'll just fetch a spare drive and try it at once
<Kamion> zyga: so you saw it in /var/log/syslog or /var/log/messages?
<zyga> Kamion: on the third or fourth vt
<Kamion> right, same thing
<zyga> Kamion: I'll have the answer in a few minutes
<Kamion> mvo: I'll probably do the same thing in the installer for fc-cache at some point, too; apparently it has a similar problem
<mvo> Kamion: fair enough. having it solved in general would still be cool
<Kamion> oh, yeah, absolutely
<mvo> :)
<zyga> mvo: is there any trgger functionality similar to what rpm has in dpkg?
<zyga> so that package A can be notified when package B is installed?
<Kamion> naturally the fewer weirdo hacks the installer has to do, the better
<zyga> (s/installed/whatever/)
<mvo> zyga: not that I know of, but Diziet is probably better to talk to
<Kamion> zyga: no, that's the point of this discussion (approximately)
<zyga> no no I'm asking because of another thing
* zyga misread,  sorry Kamion
<zyga> (my locale stuff could be triggered when someone installs/removes a language pack
<zyga> it would be trivial to integrate it with existing system this way)
<mvo> zyga: there is also a proposal about "classes" in dpkg, that may be more appropriate here
<Kamion> language pack maintainer scripts call scripts on install/remove which you could divert and hook into
<Diziet> buffer cache> Damn, no, I'm not, because they're not in stock.
<zyga> Kamion: actually that's easier :-)
<Kamion> it might not be quite as elegant but it's certainly doable without dpkg changes right now
<zyga> thanks for the suggestion
<pitti> zyga: we will soon modify the locales package to provide more generic hooks
<pitti> zyga: right now you have to modify glibc to modify the scripts
<zyga> pitti: what?!
<Kamion> pitti: no, you can divert the scripts and put other ones in their place
<Diziet> zyga: http://www.dpkg.org/Triggers, `Alternative Design' (ie, the one Wiggy and I came up with.)
<pitti> Kamion: ah, divert. ok, sorry
<zyga> pitti: I thought kamion was talking about postinst postrm or something similar
<Kamion> I was
<zyga> triggers are badly needed IMHO
<Kamion> they've been badly needed for about eight years ;-)
<pitti> zyga: you mean hooks?
<Kamion> (but people have survived)
<zyga> pitti: hook is not a trigger IMHO
<zyga> (but in this case it's proably the same topic)
<pitti> zyga: right
<pitti> zyga: but triggers might eventually be implemented, hooks won't according to Keybuk 
<pitti> zyga: ah, k, finished reading backlog now
<Diziet> The thing that is described on that wiki page as `triggers' is what I always used to call `hooks'.  What did Keybuk mean by `hooks' ?
<Kamion> pitti: could you loosen mozilla-locale-fr's Depends a bit? it looks like they just need to be weakened by dropping the -1, to me
<Kamion> unless there's something specific in the packaging that they depend upon
<pitti> Diziet: I mean something like /etc/dpkg/postinstall.d
<pitti> Diziet: so that you can do actions after installing/removing certain/all packages
<Diziet> Oh, that's very lame and doesn't make any sense.
<pitti> Kamion: sure
<pitti> Diziet: but would be highly useful for some special purposes
<zyga> pitti: it could have some uses
<pitti> Diziet: apt has hooks, but that's not generic enough since peopl might use dpkg directly
<Diziet> Ohhh!  The light dawns.  The apt people did some silly thing so now people want to shove it down the stack.
<Diziet> What the wiki calls triggers are the answer to this question, anyway.
<pitti> Diziet: how are hooks silly?
<Kamion> you have to invoke those extra processes every time no matter what
<Kamion> triggers allow being more selective
<pitti> Kamion: they have different use cases
<Kamion> they have a subset of use cases
<Diziet> What Kamion said, and also they can't be done right because the design is incoherent.  In particular the error handling is going to be broken no matter what.
<pitti> Kamion: so, a trigger is for things like calling ldconfig, a hook is for cases like 'update desktop translations of these packages from langpack data'
<Diziet> The latter can be done with triggers too.
<pitti> Diziet: but that requires changing all postinsts
<Diziet> No.
<zyga> I like the state idea
<Diziet> See `Alternative Design', which is what ought to be implemented.
<Diziet> Well, the design should be finished first :-).
<zyga> installing a package may leave it in the state that says 'needs foo' 'needs bar'
<Kamion> argh, curl fails to build on powerpc
<zyga> after the instalation you could finish all missing states but I wonder what should happen (or if it's allowed) for states to be dependant on one another
<Diziet> Much as this is an interesting conversation, I should go and wade around in firefox some more.  Without my bigger buffer cache, boohoo.
* Kamion goes for breakfast and coffee while a test build runs
<pitti> Diziet: ah, interesting
<Mithrandir> I've done tex4ht
<pitti> Mithrandir: oh, did you change the kpathsea build dep?
<Mithrandir> pitti: yes
<pitti> Mithrandir: I was going to do that in 5 minutes, cool
<Mithrandir> pitti: it built fine, at least.
<Mithrandir> ogra: you have editproducts, right?
<pitti> Kamion: m-locale-fr done
<zyga> Kamion: installing breezy now
<pitti> seb128: ok, so should I hold back the debhelper merge? it is FTBFS right now since it waits for an universe package
<pitti> seb128: but you said that it will break many packages due to gconf changes?
<pitti> seb128: what's necessary to fix that?
<dholbach> pitti: he's away atm
<Kamion> pitti: AFAIK we need newer gconf (or some other bit of GNOME) first
<Kamion> Mithrandir: 10:20  * Kamion claims tex4ht
<Kamion> Mithrandir: (and already uploaded
<Kamion> )
<zyga> pitti
<zyga> pitti: what do you think about patching gconf to use gettext to lookup localized strings?
<Kamion> pitti: m-l-fr> thanks
<pitti> zyga: hm, /me is not really a gnome expert
<zyga> pitti: i18n wise it would be good but I'm not sure about usefulnes of such act
<Mithrandir> Kamion: oh well.
<Mithrandir> Kamion: didn't you do sgml2x?
<zyga> looking at the installer, do you think that adding noatime to all /target locations would break anything?
<Kamion> Mithrandir: no, it didn't need changes, it was just openjade*
<Mithrandir> Kamion: oh, ok.
<Kamion> zyga: I'd rather not, access times are not useless
<Kamion> for example popularity-contest cares
<zyga> Kamion: just for the installer
<janimo> seb128, what exactly are the upcoming gconf changes?thx
<seb128> Riddell: we don't send bugs to a list I think, but motu guys do
<seb128> janimo: what Debian did
<Mithrandir> Kamion: for my cdebconf external widget build stuff, should I spend a little time cleaning it up and upload to dapper?
<Kamion> zyga: I don't see a win there sufficient to justify the code
<seb128> janimo: splitting the package to get ride of the circular depends, using a new tool to register schemas, moved defaults to /var, use one concatened file
<zyga> Kamion: the code is minimal, but noatime could give a significant win in install time IMHO
<Kamion> Mithrandir: sure. want me to take care of getting it upstream once it works?
<Kamion> zyga: you're welcome to try it out and produce numbers
<zyga> Kamion: :>
<pitti> Kamion: I'll fix hevea
<zyga> Kamion: too bad I didn't time the install 
<janimo> ok thanks. IIRC gconf depended on other gnome libs too in breezy, that no longer seems to be true
<Mithrandir> Kamion: sure, if you'd like.
<Kamion> zyga: the bulk of the installer's work on the target filesystem is after reboot, and we can't special-case that
<zyga> hmm
<pitti> infinity: is there a way to ensure that debhelper 5.x is not built until we fix gconf?
<pitti> infinity: it's currently in dep-wait (or should be at least)
<janimo> seb128, any chances gdm upstream be interested in ubuntu debian/pacthes ?
<janimo> the power mgmt one specifically
<seb128> pitti: the change is
<seb128>    * dh_gconf: delegate schema registration the gconf-schemas script,
<seb128>      which moves schemas to /var/lib/gconf, and require gconf2 2.10.1-2,
<seb128>      where it can be found. Closes: #327209
<seb128> 
<Kamion> /usr/bin/ld: dynamic variable `_SDA_BASE_@@gssapi_krb5_2_MIT' is zero size
<seb128> but we don't have a gconf-schemas script
<Kamion> ^-- what's breaking the curl/powerpc build, ugh
<seb128> pitti: and the Depends is made for Debian, it Depends on something we already ship without the fix (we have 2.12 they have 2.10, so they bumped to 2.10-something which is already satisfed for us)
<zyga> Kamion: how about a trigger ;-)
<seb128> janimo: yeah, if they are done correctly
<dholbach> janimo: you could point them to the patch in a bug report or better on their list?
<janimo> I mean the ones there are already in our debian/patches
<Kamion> ah, libkrb53 issue fixed in Debian, will sort that out ...
<seb128> janimo: there is a lot of patches here, you can't make a rule for different points
<seb128> janimo: some maybe, some not
* pitti scratches his head about hevea
<janimo> ok I mean, have you tried pushing them upstream so far?
<pitti>   hevea: Depends: ocaml-base-nox-3.08.3 which is a virtual package.
<seb128> janimo: which one?
<pitti> in source package: Depends: gs, netpbm(>=2:9.10-1), tetex-bin, ocaml-base-nox-3.09.0
<seb128> janimo: again different patches, different situations
<pitti> ah, never midn
<pitti> infinity: please give back hevea
<pitti> Kamion: ^ that should make it installable again
<janimo> none iin particular, I was interestred whether there is an ongoing pushing up or the ones we altready have are not upstream material
<seb128> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327209 is the dh_gconf patch we want to revert for the moment
<janimo> so I was just curious in general
<zyga> Kamion: ping
<zyga> Kamion: I've found the bug 
<seb128> janimo: again, some are upstream material, some are not
<zyga> Kamion: before reboot, preconfiguring packages gives lots of: perl: warning: Setting locale failed.
<zyga> LANGUAGE= (unset)
<zyga> LC_ALL = (unset)
<zyga> LANG= "C.UTF-8"
<seb128> janimo: https://wiki.ubuntu.com/DesktopTeam/TODO ... I've listed the hibernate to work with upstream here
<zyga> Kamion: locale-gen has kicked in some time after
<seb128> janimo: the secure action menu needs a bunch of work and I'm not sure upstream would be interested
<Kamion> zyga: locale-gen is meant to be called from a base-installer hook though
<seb128> janimo: we have changes from Debian which I don't get why we do this (like not using .profile)
<Kamion> zyga: which packages are being preconfigured?
<zyga> Kamion: installation-report
<Kamion> zyga: ah, probably apt-installed packages are installed before the locales are generated
<pitti> infinity, seb128: nevermind, the debhelper dep-wait is already cleared, it fails for a different reason now
<Kamion> zyga: minor bug, I won't worry about it too much, but thanks anyway
<zyga> Kamion: I'm not sure I understand but I'm glad to help :-)
<seb128> pitti: either revert the patch I pointed or wait monday when I'll transition gconf
<Kamion> zyga: it's just a slight mistake in the order that things happen in base-installer
<Kamion> should be harmless
<pitti> seb128: if reverting the patch is fine for you, I'd rather do it now
<zyga> I'm still not thru reboot yet
<seb128> pitti: go for it
<Kamion> pitti: I think infinity might have crashed; I've given-back hevea
<pitti> Kamion: ok, thanks
<Kamion> (was dep-wait on a virtual package so I can see why it didn't work automatically)
<zyga> just a thought...
<zyga> if the user has a smp box the installer could add the default -smp kernel 
<Kamion> zyga: it does if the kernel is on the CD
<Kamion> zyga: it isn't on the CD because we don't have space
<zyga> Kamion: ah, I see
* zyga waits for netinst ubuntu
<Kamion> zyga: this has been discussed a number of times, and we took the explicit decision to go with the current arrangement. However, with our 2.6.15 kernels, the default i386 kernel is SMP-capable.
<zyga> 2.6.15?
<Kamion> zyga: you can already netboot; http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/images/netboot/
<zyga> isn't 14 the latest
<Kamion> zyga: no
* zyga needs to check kernel more often
<Kamion> it's 2.6.15-rc1 but anyway
<Nafallo> 2.6.15-rc1
<hunger> Will those kernel debs hit main anytime soon?
<zyga> Kamion: someone should add that image to the list available on ubuntu.com
<Kamion> zyga: I'm happy with the current arrangement
<zyga> Kamion: why, netinst makes lots of sense and it's hard to discover on the website
<Kamion> hunger: they're already in main; they'll become the default after Flight CD 1
<Kamion> zyga: the installation manual links to them, and I don't want to go through the faff of re-publishing them on cdimage
<Kamion> BTW this is netboot not netinst; "netinst" has a specific meaning in Debian which isn't this
<zyga> Kamion: I mean, get mini cd, fetch rest from the net
<zyga> that's netinst, right?
<Kamion> no, Debian netinst CDs include the base system on the CD
<hunger> Kamion: Cool! When will the flight CDs get out?
<Kamion> hunger: when they're ready
<Kamion> hunger: the less people hassle me today, the sooner it'll be
* zyga becomes silent
<hunger> Kamion: OK, I'll shut up.
<Kamion> thank you :)
<ogra> Mithrandir, sorry, was afk... nope, i only have editusers
<Mithrandir> ogra: ook
<ogra> Mithrandir, i think mvo has editproducts
<Mithrandir> mvo: do you?
<mvo> Mithrandir: yes
<mvo> Mithrandir: what do you need?
<Mithrandir> mvo: can you make infinity the default assignee for mozilla-thunderbird bugs?
<mvo> Mithrandir: yes
<Mithrandir> mvo: thanks
<pitti> mvo: why did you add 'file' to debhelper's build-depends? it needs to be -indep anyway, but I don't know the reason
<Kamion> pitti: that's obsolete, I got joeyh to fix the underlying reason
<Kamion> namely that it was running dh_something in debian/rules just to test whether it worked
<pitti> ah, thanks
<mvo> Mithrandir: it looks like he is already default assignee?
<Kamion> dh_shlibdeps I think
<Mithrandir> mvo: oh, ok.  Good, then
<Kamion> oh, oops. erm, don't bother with the current dapper install CDs, folks
<Kamion> they're missing grub because I forgot to 'baz update'
<Mithrandir> "ouch"
<Treenaks> "oops"
<Mithrandir> infinity: any chance you could look at why tagcoll doesn't seem to build?
<Mithrandir> it was accepted an hour ago, but doesn't seem to have built yet
<Treenaks> m68k? :P
<Kamion> misc/tagcoll_1.5-1ubuntu1: Dep-Wait by buildd+terranova [optional:out-of-date] 
<Kamion>   Dependencies: latex
<Kamion> Mithrandir: I take it I should give that back?
<Mithrandir> Kamion: yes please.
<ogra> pitti, ping
<Kamion> Mithrandir: done
<Mithrandir> Kamion: aren't dep-waits supposed to clear automatically?
<Kamion> Mithrandir: not if they're on nonexistent packages
<Mithrandir> ah
<Kamion> i.e. the package never becomes available so they never clear; bear in mind dep-waits are sometimes set on packages not in the building package's explicit dep-wait list
<pitti_> Hi ogra 
<Kamion> (e.g. toolchain, indirect build-deps, etc.)
<Kamion> seb128: the gnome-panel rebuild broke in the same way
<Mithrandir> are anybody working on readline4?
<Kamion> Mithrandir: those two packages are NBS and will be removed once nothing (build-)deps on them
<seb128> Kamion: k, I'll debug that
<Mithrandir> Kamion: ah, ok.
<fabbione> NBS?
<Kamion> not built from source
<fabbione> ahh
<Kamion> Mithrandir: but no harm going round figuring out what needs to be updated
<Chipzz> hmmm
<Chipzz> this is bad:
<seb128> infinity, elmo: could you install the build-depends for gnome-panel on davis dapper chroot?
<Chipzz> adduser: Couldn't parse `/etc/adduser.conf':29.
<Chipzz> adduser: Couldn't parse `/etc/adduser.conf':30.
<Chipzz> adduser: Couldn't parse `/etc/adduser.conf':31.
<Chipzz> adduser: Couldn't parse `/etc/adduser.conf':32.
<Chipzz> ...
<Chipzz> and a lot more of these
<Mithrandir> Kamion: ok, I'll do that, then.
<fabbione> seb128: afaik infinity doesn't have chroot powers.. Znarl and elmo do, but the best way is to file an rt request
<Mithrandir> Kamion: we want to chuck libreadline4 out completely, right?
<pitti> Mithrandir: right
<pitti> Mithrandir: most packages will do with a rebuild against 5 (this was true for all packages that I did)
<pitti> Mithrandir: however, some might need changes
<Mithrandir> pitti: ok, which have you done?
<seb128> fabbione: how do rt requests work?
<pitti> Mithrandir: postgresql-X.Y, curl, a few others I forgot about
<Mithrandir> pitti: ok
<Mithrandir> I'm grabbing bc, ftp so far.
<fabbione> seb128: just send a mail to rt@admin.canonical.com with what you need done. that's it
<seb128> fabbione: thanks
<Kamion> Mithrandir: that one isn't urgent so feel free to skip potentially risky ones
<Mithrandir> Kamion: ok.  Doesn't seem to be any very risky ones, possibly with the exception of parted and gdb.
<pitti> Mithrandir: only 14 packages in main that need 4, that seems manageable
<desrt> fabbione; nobody reads that address :)
<desrt> fabbione; except for a very polite python script :)
<Kamion> Package libebook-1.2 was not found in the pkg-config search path.
<Kamion> seb128: ^-- root problem
<fabbione> desrt: you wish :)
<pitti> Mithrandir: we should watch out for Debian merges
<pitti> Mithrandir: e. g. mdbtools was converted to 5 in debian
<pitti> Mithrandir: do you want a list of all packages that use 4?
<Mithrandir> pitti: "apt-cache rdepends libreadline4" is a good approximation, isn't it?
<seb128> Kamion: hum ... 
<seb128> grep "libebook" configure*
<seb128> $
<pitti> Mithrandir: sure, if you can restrict it to main
<Kamion> Package 'libebook-1.2', required by 'libedataserverui', not found
<Mithrandir> pitti: pbuilder login gives me that.
<Kamion> perhaps the relevant -dev should depend on libebook1.2-dev
<pitti> Mithrandir: ok, fine for me :)
<seb128> Kamion: $ apt-cache show libedataserverui1.2-dev | grep Depends
<seb128> Depends: libedataserverui1.2-6 (= 1.5.2-0ubuntu1), libgnome2-dev, libedataserver1.2-dev (= 1.5.2-0ubuntu1), libaudiofile-dev, libbonobo2-dev, libcamel1.2-dev, libebook1.2-dev, libesd0-dev, libgconf2-dev, libgcrypt11-dev, libglib2.0-dev, libgnomevfs2-dev, libgnutls11-dev, libgpg-error-dev, liborbit2-dev, libpopt-dev, libtasn1-2-dev, libxml2-dev
<seb128> it does
<Kamion> Depends: libedataserverui1.2-6 (= 1.5.1-0ubuntu2), libgnome2-dev, libedataserver1.2-dev (= 1.5.1-0ubuntu2)
<Kamion> ^-- on powerpc
<seb128> utch
<seb128> what version is that?
<Kamion> 1.5.1-0ubuntu2
<seb128> 1.5.2-0ubuntu1 ?
<seb128> ah
<seb128> it's outdated
<Kamion> good catch, I'll give that back
<seb128> [   ]  evolution-data-server_1.5.2-0ubuntu1_20051115-1709-powerpc-given-back.gz 
<seb128> k
<Kamion> it wasn't, though
<seb128> hey, that's weird
<Kamion> I don't know exactly what given-back there corresponds to but it seems to require manual action
<seb128> can you give it a retry?
<Kamion> alrady done
<Kamion> +e
<seb128> cool
<Nafallo> Kamion: could you give-back tipptrainer on powerpc please?
<Nafallo> Kamion: and ia64.
<Kamion> Riddell: please rebuild koffice against the new imagemagick (libmagick++9-dev)
<pitti> seb128: ok, new debhelper uploaded with the gconf patch reverted
<seb128> pitti: thanks
<pitti> seb128: I tested it with eog, seems to work fine now
<seb128> cool
<pitti> seb128: please just ping me when gconf is ready
<Kamion> Nafallo: done on ia64, but powerpc needs whatever library is responsible for this symbol to be rebuilt first:
<pitti> then we can re-applu
<Kamion> /usr/bin/ld: dynamic variable `_SDA_BASE_@@WXU_2.6' is zero size
<Kamion> (should just need a no-changes rebuild with new binutils, like I just did for krb5)
<Mithrandir> Kamion: maybe wx 2.6?
<pitti> Mithrandir: oh, mdbtools can be synced, this gets rid of another libreadline4
<Kamion> Mithrandir: right
<Mithrandir> pitti: don't tell me, tell elmo/Kamion. :-)
<Kamion> (probably)
<Kamion> check with objdump -T <various libraries> first
<Kamion> Mithrandir: s,/Kamion,,
<elmo>   mdbtools | 0.5.99.0.6pre1.0.20050409-1.2 |        dapper | source, amd64, i386, ia64, powerpc
<elmo> so s/elmo// too :P
<Mithrandir> heh
<Mithrandir> so it just needs a rebuild.
<Mithrandir> actually, it doesn't.
<slomo_> elmo: please sync gtkhtml from debian/unstable... ubuntu changes can be dropped as always ;)
<Mithrandir> pitti: it's already done
* pitti closes the bug
<seb128> elmo: wait for gtkhtml
<seb128> slomo_: which one is that? the GNOME 1 ?
<slomo_> seb128: yes... i won't touch the core gnome2 stuff without asking you ;)
<Nafallo> Kamion: ah, oki. that's the way it works :-).
<Nafallo> Kamion: thanx
<seb128> elmo: k, gtkhtml fine with me :)
<elmo> slomo/seb128: done
<slomo_> elmo: thanks :)
<Mithrandir> seb128: can you or dholbach do gnome-pilot against newer libreadline, please?
<dholbach> Mithrandir: i can do that
<Mithrandir> dholbach: thanks
<slomo_> BenC: will the ppc kernel build failure also be fixed with new binutils?
<BenC> I hope so
<seb128> elmo: have you done wv2?
<seb128> dholbach: go for it
<pitti> elmo: can you please sync texinfo?
<pitti> Hi jbailey 
<elmo> BenC: huh?
<jbailey> Heya Martin (and everyone)
<elmo> BenC: got a pointer to the problem/patch?
<elmo> seb128: no, missed it sorry, done
<elmo> pitti: done
<pitti> thanks
<seb128> elmo: np, thanks
<BenC> elmo: problem with ppc64 is a relocation error during vmlinux linking
<BenC> buildlogs shows it
<BenC> I can disable CONFIG_HMT to get around it for now
<pitti> Mithrandir: I'll tackle readline for gdb unless you want to
<Mithrandir> pitti: way ahead of you, already uploaded.
<elmo> BenC: and is it definitely fixed in newer CVS or do you just hope it is? :)
<pitti> k :)
<elmo> (asking for the changelog)
<BenC> elmo: I just hope :)
<elmo> ok
<Mithrandir> pitti: start at the other end of the list with quagga, parted, mysql-client and lua50?
<slomo_> bbl
<viviersf> ffs
<seb128> pitti: BTW gconf is not broken, stop saying "fixed gconf", it's just not transitionned yet to a new format :p
<viviersf> does any1 know why im having troubles installing grub
<pitti> Mithrandir: hm, for dapper we should probably drop mysql 4.0 and go to 4.1
<viviersf> from live cd etc ?
<Mithrandir> pitti: agreed, and I think infinity would be happy about that too.
<pitti> Mithrandir: given that it is already in main...
<Kamion> viviersf: what version?
<Mithrandir> pitti: especially given that mysql-server (4.0) is broken on ppc
<viviersf> version of ?
<viviersf> ubuntu ?
<Kamion> viviersf: the live CD
<viviersf> lol
<viviersf> impilinux
<viviersf> based on breezy
<viviersf> i tried : 
<viviersf> grub 
<Kamion> well, look in /cdrom/pool/main/g/grub/ to see if it's there
<pitti> Mithrandir: k, I fix -4.1 then and check what is necessary to drop 4.0
<Kamion> er, no, cancel that
<Kamion> check 'dpkg -l grub'
<viviersf> heh
<pitti> brb
<dholbach> i prepare some food... be back later
<viviersf> yes Kamion its on
<viviersf> i do this :
<viviersf> grub
<viviersf> root (hd0,0)
<viviersf> setup (hd0)
<viviersf> quit
<viviersf> i get no errors
<viviersf> but the thing just dont boot
<viviersf> grub-install /dev/hda doesnt work
<viviersf> so i dont know what to do
<Kamion> viviersf: I'm afraid I'm excruciatingly busy today; if somebody else could help you that would be good
<Kamion> you will need to give more details though, "doesn't work" is never very helpful
<viviersf> it does not say anything when it tries to boot
<viviersf> its just stops before grub loads
<viviersf> ajmitch, saw it :/
<ogra> whom do i have to poke for initramfs now, was that Keybuk or infinity ?
<Kamion> ogra: normally infinity
<ogra> oki, hanks
<ogra> +t
<jbailey> ogra: If you have occasional questions, I'm still following development on it, just not doing it.
<jbailey> ogra: (If the timezones work out better that way)
<viviersf> ah yes jbailey 
<viviersf> dont you know anything bout grub /
<viviersf> ?
<ogra> jbailey, i just want to get rid of that "sleep 3" in the nfsmount script :)
<ogra> its still there and slows down booting thin clients :)
<Mithrandir> elmo: please sync pilot-link, ok to override Ubuntu changes.
<elmo> err
<elmo> pilot-link_0.11.8-10ubuntu4_source.changes
<elmo> REJECT
<elmo> Mithrandir: so, talk to whoever that is?
<Mithrandir> elmo: that was uploaded by me.
<Mithrandir> elmo: I didn't look if we needed to merge.
<Mithrandir> (sorry)
<Kamion> the reject was just for distribution: unstable anyway ...
<jbailey> ogra: Sounds lovely.  Wasn't it there so that the network had time to sync up?
<Mithrandir> I take that as a sign I should take a break. :-)
<elmo> yeah, I know, but it freaks me out when someone says "please sync" at the same time as someone is uploading it
<jbailey> ogra: Otherwise a switch may not have actually completed spanning tree and the like.
<ogra> jbailey, nope, only for debugging the issue ... 
<elmo> done anyway
<Mithrandir> elmo: sorry, I should have mentioned it.  Mea culpa et errare humanum est.  And thanks.
<ogra> jbailey, its from the time where mdz thought it was a network issue ... 
<ogra> it can go safely
<jbailey> Ah, okay.
<jbailey> infinity is doing the uploads these days, best to email him.
<ogra> which we solved by setting the klibc value for nfs mounts right ...
<ogra> yup
<ogra> i'm not in a hurry ...
* Kamion gives curl another kick, hopefully sorting out a chain of stuff on powerpc
<jbailey> Clearly you are if 3 seconds is too long to wait... ;)
<ogra> heh
<ogra> nope, my users are :)
<ogra> which falls in your realm now ;)
<viviersf> omw
<viviersf> im gonna use lilo
<viviersf> watch me :/
<viviersf> or is there issues with lilo ?
<\sh> wtf 
<\sh> Get:21 http://archive.ubuntu.com dapper/main qt3-apps-dev 3:3.3.5-1ubuntu1 [2402kB] 
<\sh> Get:22 http://archive.ubuntu.com dapper/main sip4 4.3.1-1ubuntu1 [184kB] 
<\sh> Get:23 http://archive.ubuntu.com dapper/universe gcc-snapshot 20051112-1 [56.6MB] 
<\sh> gcc-snapshot?
<viviersf> lo,l
<Treenaks> sip? gcc-snapshot phones home?
<Treenaks> in the literal sense?
<pitti> elmo: please sync mysql-dfsg-4.1
<\sh> Treenaks: python-qt3 merge that is
<Riddell> sip is qt python binding helper, not phones
<\sh> but for what reason I need gcc-snapshot...lets see who pulls it in
<Riddell> Kamion: will do koffice along with libstdc++ merge
<\sh> grmpf
<Treenaks> Riddell: oh, it's not the voip thing?
<\sh> Treenaks: no
<\sh> Traxer|off: sip4 is just a type of swig for qt stuff
<\sh> Treenaks: i mean...not Traxer|off 
<Kamion> Riddell: thanks
<\sh> and this is somehow horrible
<\sh> c++abi2-dev
<Mithrandir> I'm grabbing libtunepimp
<\sh> doko: when is the new libstdc++ transition happening?
<seb128> Kamion: e-d-s build failed, something triger -ldb without having the correct Depends, trying to figure what now
<dholbach> \sh: after the first cd is out
<doko> \sh: after flight-1
<\sh> doko: k..so I should not take any calls from work over the weekend :)
<sivang> \sh: you should never take calls from work on the weekend, unless it's FOSS related :)
<Kamion> seb128: want any help? it's the last blocker I think
<\sh> sivang: well...I'm just a callboy for this company...I'll earn per call between 60 and 80  (only for the call) and after that, they pay all the working time during night or weekends...
<seb128> Kamion: I'll let you know, I get a pbuilder with the Build-Depends atm, so I can grep the .la and figure if there is something wrong with them
<sivang> \sh: ah then that's pretty cool actually, no?
<sivang> \sh: actually, we shoudl probably take this to PM 
<\sh> sivang: it's preety annoying...especially then, when I try to sleep...and dreaming about hula girls ;)
<Kamion> seb128: ugh, evolution-data-server builds its own internal copy of libdb?
<\sh> i'll compile python-qt3 now...time for a smoke
<seb128> Kamion: yeah
<Kamion> gross
<Mithrandir> Kamion: it sucks, yes.  Very much, so.
<seb128> I already had this discussion with upstream and pitti
<sivang> \sh: lol
<Mithrandir> seb128: and me. :-P
<seb128> and infinity :p
<Kamion> hah
<seb128> upstream argue that's the only sane way to make sure it doesn't break if you share your data between different distros
<seb128> ie: they are not going to change that
<Mithrandir> seb128: the only sane way to make sure it doesn't break between distros is to use something else than libdb :-)
<seb128> that too :)
<Kamion> seb128: doesn't mean we have to build the built-in one ;)
<Mithrandir> we should just patch out the libdb in e-d-s and patch in my tdb backend. ;-)
<seb128> Kamion: Debian does use the system libdb, but we had some issue with that when we tried
<seb128> didn't want to break it before a stable, we are probably to change that soon since we are early for dapper
<seb128> Kamion: the bug comes from kerberos4kth-dev
<seb128> /usr/lib/libkafs4.la:dependency_libs=' /usr/lib/libroken.la -ldb /usr/lib/libkrb.la -lcrypt -lcom_err -lcrypto -lresolv'
<seb128> /usr/lib/libotp.la:dependency_libs=' -lcrypto /usr/lib/libroken.la -lcrypt -ldb -lresolv'
<seb128> /usr/lib/libroken.la:dependency_libs=' -ldb -lcrypt -lresolv'
<mvo> elmo: please sync tagcoll from debian (override ok)
<jordi> pitti: you might want to consider taking alsa from experimental in dapper
<HiddenWolf> jordi, isn't that crimsun's
<jordi> HiddenWolf: no idea. it was pitti before :)
<elmo> pitti: done
<seb128> Kamion: I upload a krb4 with the fix
<Kamion> thanks
<Diziet> Aargh, now I have to run this script again because I forgot a pair of "".  I really should know better.
<Mithrandir> mvo: uhm?
<Mithrandir> mvo: the version in Debian doesn't build for us.
<Kamion> seb128: (it didn't build from source as it was anyway)
<mvo> Mithrandir: there is a new upload that fixes the build problem (#19770)
<Mithrandir> mvo: oh, ok.
<mvo> Mithrandir: or am I overlooking something here?
<Mithrandir> mvo: if there is, then it should be fine.  I just fixed it a few hours ago.
<seb128> Kamion: what didn't build from source?
<Kamion> seb128: krb4
<Kamion> the previous version in dapper, I mean
<seb128> oh, k
<pitti> jordi: right, that's what I wanted you to ping about
<pitti> jordi: did you already use it for some time? is the rc safe?
<torkel> isn't it time to start thinking of dropping kerberos4kth? See Debian #315059
<pitti> Kamion: I was away for lunch, and dapper_probs.html seems out of date - what's still missing?
* mvo needs to run to the townhall, bbiab
<Kamion> torkel: on this I think we can happily follow Debian
<Kamion> pitti: it was updated pretty much at the point you said that
<Kamion> pitti: I think all the remaining pieces are now just waiting for builds
<pitti> neat, thanks
<Kamion> krb4 -> evolution-data-server -> gnome-panel is about it; the rest is not CD-critical
<Mithrandir> elmo: please sync libmusicbrainz-2.1
<Mithrandir> (overriding ubuntu changes is ok)
<torkel> Kamion: yeah. Hopefully the new heimdal will move to unstable soon and they will drop krb4
<Mithrandir> why do we even build with krb4 support?
<seb128> torkel: we had the question some time ago to use krb or heimdal, we picked krb ... is that wrong?
<pitti> seb128: any chance to use krb5? krb4 is on the list of packages we'd like to kill
<seb128> pitti: we use both
<seb128> not sure if that's useful, I don't know that enough
<torkel> seb128: krb and kerberos4kth are not the same thing
<seb128> I've just turned all the option proposed by upstream
<seb128>         Kerberos 4/5:     yes/yes (MIT)
<torkel> it was kerberos4kth I was speaking about
<seb128> torkel: pitti was speaking about krb4
<thierry_> I'm doing a bash script, where I edit some files with gedit, I'd like the script to wait that I finished my modifcations before it continues.... how could I do that?
<seb128> thierry_: action1 && action2
<thierry_> k
<torkel> seb128: which of mit krb and heimdal to use is probably just a matter of taste.
<seb128> thierry_: action1; action2 too ... depending if you want to continue or not depending of the return of action1
<seb128> torkel: we picked the first one so :)
<torkel> seb128: :-)
<thierry_> seb128 : but the problem is that when gedit open, the terminal think the command is finishied
<thierry_> finished*
<seb128> thierry_: no
<seb128> thierry_: enter "gedit && ls" on a command line
<thierry_> gedit just opened and ls displayed before I close gedit
<seb128> thierry_: do you already have a gedit running?
<thierry_> ho yes... wait
<seb128> it reuses the running one in this case and return directly
<thierry_> seb128 : cool working! thanks
<seb128> np
<thierry_> seb128 : just one little last thing : a command give me two lines of output, how can I give a variable to each of them?
<thierry_> do I absolutely need arrays?
<seb128> what language?
<thierry_> bash
<seb128> dunno
<thierry_> k thanks anyway
<sistpoty> thierry_: maybe s.th. like x=$(cmd); x1=$(echo ${x} | head 1); x2=$(echo ${x} | tail 1)
<Kamion> you want more quoting there really, i.e. "$..."
<Kamion> always put double quotes around $... in shell unless you know why you shouldn't
<sistpoty> that's why i wrote s.th. _like_ ;)
<Kamion> I'm just trying to encourage good shell before people get into bad habits.
<sistpoty> Kamion++ ;)
* zyga looks out the window to appreciate the first snow this season :-)
<thierry_> so this should be this : x="$(ls | find $package*.dsc)"; x1="$(echo ${x} | head 1)"; x2="$(echo ${x} | tail 1)" ?
<Mithrandir> ls | find?
<Mithrandir> that doesn't make very much sense. :-)
<thierry_> ho yeah doesn't need ls... sorry
<sbalneav> Morning all
<sistpoty> thierry_: maybe you'd also quote ${x} in echo... but just try it in bash (I haven't ;)
<Kamion> yes, and no point in the {}
<Kamion> if you don't quote "$x" then echo and the shell may interpret metacharacters in the value of $x, will collapse whitespace, etc.
<thierry_> kamion : yeah that's what I was thinking
<Kamion> <cjwatson@cairhien ~>$ foo='a  b  c'
<Kamion> <cjwatson@cairhien ~>$ echo $foo
<Kamion> a b c
<seb128> elmo: I've uploaded alacarte which is a renaming of smeg, can you remove smeg when you accept alacarte?
<Kamion> ok, I'm going to have to go in fifteen minutes; I have a prior engagement this afternoon. Looks like I won't be around to start a CD build for some hours
<Kamion> please keep the archive working while I'm gone :)
<seb128> Kamion: smeg package has been renamed to alacarte, is that ok if I update the seed according to that?
<Kamion> seb128: post-flight-1 please
<seb128> k
<Kamion> but yes, after that
<seb128> elmo: don't drop smeg yet so please :)
<torkel> fabbione: ping?
<Kamion> seb128: krb4 FTBFS in the same way I noticed the old version doing on powerpc
<Kamion> /usr/include/openssl/ossl_typ.h:144: error: syntax error before numeric constant
<Kamion> make[4] : *** [ftpcmd.o]  Error 1
<seb128> Kamion: will look on it
<seb128> Kamion: for now I can workaround it with an e-d-s explicit Build-Depends if you want
<seb128> let's try to fix it first
<Kamion> it's not going to be done before I leave in any case
<Kamion> please ping buildd admins to retry evolution-data-server and then gnome-panel if that proves to be necessary
<seb128> k
<chmj> elmo: bgoffice sync please, ubuntu override ok
<thierry_> how can I see by a command if a ubuntu package is unstable or not
<Kamion> "unstable"?
<Kamion> anyway, #ubuntu please
<thierry_> Kamion : yeah in the changelog there's breezy breezy-updates or unstable as distribution
<ogra> thierry_, unstable means its synced 1:1 from debian
<thierry_> ogra : so when we do updates to this we put it to dapper or unstable?
<ogra> thierry_, if you upload to the ubuntu archive it must be dapper ... if it gets synced from debian itstays as is
<thierry_> ogra : well I want to apply a patch for dapper, so any unstable package should be dapper?
<ogra> any package you touch and upload must be dapper ... 
<thierry_> ogra : and sending a patch to malone is like uploading?
<ogra> nope
<ogra> a maintainer has to review it, add it and upload it
<ogra> in the end there is uploading involved in this process indeed
<ogra> but if you say malone, this onversation should probably be in #ubuntu-motu
<thierry_> so when sending a patch to malone, I put the distribution as dapper right?
<thierry_> ogra : k sorry
<ogra> yes
<ogra> seb128, does the sabayon version you just uploaded already include pessulus ?
<seb128> yeah
<ogra> cool :-D
<seb128> previous one already did
<thierry_> how can I set a environment variable like DEBFULLNAME ?
<ogra> with export
<thierry_> like export DEBFULLNAME="my name" ?
<ogra> yup
<azeem> thierry_: you can set that in ~/.devscripts as well I think
<azeem> or something like that
<zakame> or in your ~/.bashrc
<fabbione> torkel: pong?
<Nafallo> DEBEMAIL is even better :-)
<torkel> fabbione: have you seen: http://www.clusterfs.com/pr/2005-11-16.html
<fabbione> no
<fabbione> not yet at least
<fabbione> torkel: it's unlikely we will add lustre, but i will take a look to it
<zul_^> arent you suppose to be in school fabbione
<fabbione> i am supposed to be going there
<fabbione> waiting my wife to bring back the car
<fabbione> she is late.. as usual
<torkel> fabbione: there is at least a chance now :-)
<zul_^> ah..<bite my tongue>
<zakame> hihi
<torkel> fabbione: there are patches for newer kernels in their bugzilla
<fabbione> torkel: the one in the pkg are for 2.6.6
<fabbione> no way it's even gonna make it
<torkel> fabbione: there are patches for at least 2.6.13 in the bugzilla
<fabbione> still too old and start adding an FS out of unreviewed bugzilla patches is no no no
<torkel> fabbione: https://bugzilla.lustre.org/show_bug.cgi?id=9421
<fabbione> torkel: if you want you are welcome to prepare a patch on top of our kernel
<fabbione> i am not going to allocate time on it
<sistpoty> fabbione: an off-topic question: is there a debian-way of building a kernel-module (like install kernel-headers, use includes from xyz... I'm not thinking of a packaged module to be built with kernel-package here)
<zakame> sistpoty: make-kpkg modules-image iirc
<JaneW> Diziet: ping
<zakame> where modules to be built are in MODULE_LOC
<sistpoty> zakame: nope... it's a module from the faumachine-project, they are working on. so it's not packaged or s.th.. they just want to set up compilation in the debian way (preferably not having a kernel-source around)
<fabbione> sistpoty: you can use module-assistant
<zakame> sistpoty: module-assistant
<sistpoty> fabbione, zakame: ok, thx... I will take a look at this (and how m-a actually compiles it)
<fabbione> sistpoty: you will still need to B-D on the correct linux-headers
<fabbione> sistpoty: i did something like that in the redhad-cluster-suite
<fabbione> sistpoty: where i ship the -source for the cluster modules
<fabbione> if you follow the same packaging/logic it should work
<sistpoty> fabbione: thx... i will take a look at this. but now it's not yet done enough for packaging ;)
<pitti> elmo: please sync libnss-db
<seb128> grumpf
<seb128> if somebody has an idea on how to fix the krb4 ftbfs with openssl 0.9.8 he's welcome to do it
<seb128> that's a blocker for flight-1 :/
<seb128>                  from ftpcmd.y:45:
<seb128> /usr/include/openssl/ossl_typ.h:144: error: syntax error before numeric constant
<seb128> make: *** [ftpcmd.o]  Error 1
<BenC> what's that line look like?
<fabbione> who did upload krb4 last?
<seb128> typedef struct conf_st CONF;
<fabbione> seb128: it looks like you win :D
<seb128> fabbione: what is the price? :)
<BenC> what is CONF defined as?
<fabbione> seb128: that you get to fix it? ;)
<bmonty_laptop> elmo: did you have a chance to look at the sync request emails I sent you?
<BenC> sorry, I don't have the headers available
<fabbione> anyway i am off for real now
<fabbione> later
<zul_^> liar
<BenC> seb128: give me a minute, and I'll look at that error
<seb128> ossl_typ.h:typedef struct conf_st CONF;
<seb128> BenC: thanks
<seb128> hum, hum
<thierry_> how could I take "bittornado-0.3.11" and put only "bittornado" in a variable (in bash)
<seb128> thierry_: please use an another chan for generic bash questions
<thierry_> seb128 : wich one?
<BenC> foo=$(echo $foo | sed 's/-.*//')
<zakame> thierry_: #bash ?
<BenC> or do that :)
<thierry_> zakame : thanks didn't know it existed
<zakame> thierry_: hehe, np :)
<BenC> seb128: my best guess is that krb4 is defining CONF to something else, and it is breaking because of that
<BenC> seb128: if you add -save-temps to CFLAGS it should keep the .i file from preprocessing and you can look at that to see if it's correct
<\sh> foo=$(echo $foo|awk -F"-" '{ print $1 }'
<\sh> foo=$(echo $foo|awk -F"-" '{ print $1 }')
<\sh> there are always two ways...the sed way or the awk way ,-)
<seb128> BenC: let me try that
<BenC> seb128: if the build is somewhere I can get to, I can look a little deeper and probably provide a fix
<seb128> BenC: ftpcmd.i from krb4 has one CONF from a enum and one from a struct, should not be an issue
<BenC> sure it is
<seb128> BenC: apt-get source -b krb4 and you have it
<seb128> if you run current dapper
<seb128> I can put the build on a ubuntu box if you want
<BenC> the .i file would be helpful, then I can just look at the sourc
<seb128> k
<neuralis> \sh: or |cut -d- -f1, which is shorter ;)
<mdz> morning
<\sh> neuralis: ok...many ways are leading us to one solution :)
<BenC> morning mdz
<seb128> hi mdz
<mvo> hey mdz 
<sivang> morning mdz 
<zakame> hi mdz 
<mdz> JaneW: around?
<JaneW> mdz: yes
<mvo> seb128, BenC: I think I have the reason
<BenC> mvo: well the reason is that CONF is a enum, which is processed as a numeric index, which breaks the typedef, the fix isn't that apparent
<seb128> BenC: ftpd/ftpcmd.i on my chinstrap userdir
<seb128> BenC: hum, right
* lamont-away looks around for daniels so he can whack him with bug #18483
<mvo> BenC: right. looks like it should be save to just give the enum a more descriptive name?
<BenC> mvo: not sure, I can't tell if it will break the command protocol
<BenC> I think if you rename it, it should be ok
<BenC> since it uses a string with the enum name for parsing
<mvo> BenC: it looks to me like it's save to rename the constant as long as the token remains the same
<BenC> yeah
<BenC> seb128: try renaming CONF in ftpcmd.y to FTPD_CONF (just the places where it uses the enum, not the string and such)
<dholbach> we've been slashdotted: http://linux.slashdot.org/article.pl?sid=05/11/17/1418206&from=rss :)
<seb128> BenC: will try that, thanks
<BenC> seb128: no problem
<siretart> hi
<siretart> mdz or anyone else: do you know if someone is doing any efford in getting opera (yeah, the commercial closed sourced stuff) in multiverse?
<siretart> someone from plf is asking if we are going to have it in ubuntu or whether they should package it..
<Kmirno> Hi
<siretart> Kmirno: I just asked
<mdz> siretart: is it redistributable?
<siretart> mdz: thats the problem: we did not find any statment about redistribution terms on the opera website :/
<ptlo> siretart, there's a page about mirroring (there are some requirements for someone to host a mirror for opera) at http://www.opera.com/download/mirrors/specs/ , maybe that can hint at their standpoint
* siretart looks
<Nafallo> mail them? can't be that hard? :-)
* Nafallo hits the shower
<ptlo> specifically,: "Registered mirrors agree to carry all browser files that Opera produces.", "Note: If your site prefers to carry only specific platforms or languages, you are free to host whichever files you choose. However, your links to these files will not be posted at Opera"
<siretart> yeah, perhaps we should just ask them if we would be allowed to redistributed packaged version of their binaries
<siretart> Kmirno: would you ask them via email and CC me?
<Kmirno> siretart: what mail ?
<Mithrandir> siretart: they provide .debs which are reasonably sane.
<[splinux] > hi all
<siretart> Kmirno: asking them if we are allowed to redistribute packaged binaries of their software.
<Mirno> I need your mail if you want to be CCed Simira 
<Mirno> oops
<Mirno> siretart: 
<Mirno> oh I already have it
<Mirno> nether mind
<Mirno> ever*
<Mirno> never*
<Mirno> arrg
<Kmirno> siretart: I found No emaiul adress for opera
<siretart> Mirno: my email is 'siretart@ubuntu.com'
<Kmirno> siretart: they have a contact form here http://www.opera.com/contact/
<Kmirno> siretart: but no email
<lamont-away>  /usr/include/openssl/ossl_typ.h:144: error: syntax error before numeric constant
<lamont-away> krb4 unhappiness
<siretart> Kmirno: better than nothing
<Kmirno> siretart: ha
<ogra> lamont-away, see backlog ;)
<lamont-away> ogra: heh - ok
<Kmirno> siretart: they have some stuff for redistribution, you register and you get the terms
<lamont-away> ogra: that's wrt krb4, or something else?
<Kmirno> siretart: http://composer.opera.com/composer3/register.dml
<\sh> seb128: gnometris is set to sgid ... which doesn't work :)
<lamont-away> (not that I really particularly care about krb4, mind you...)
<ogra> lamont-away, thats about krb4
<seb128> \sh: http://bugzilla.ubuntu.com/show_bug.cgi?id=19668
<seb128> \sh: dholbach did this update :p
* mvo waves to siretart 
<pitti> elmo: please sync nas
<mdz> Mithrandir: how do we look for installable CDs/livefs?
<siretart> huhu mvo 
<_rob^> mvo: installing either gksu or its deps fixed me up for gdebi. Also python-vte is in universe right now...
<mvo> _rob^: thanks! (python-vte is something I would love to see in main)
<mvo> _rob^: so gdebi does work for you? 
<_rob^> mvo: yep I updated from an old version to last nights
<\sh> seb128: looks like there is an issue with cdbs then, or dh_fixperms doesn't work correctly
<_rob^> and i'm installing nvu right now
* mvo is happy
<_rob^> is it processing deps twice?
<_rob^> once to ask for confirmation and again when installing?
<lamont-away>   ubuntu-desktop: Depends: hplip-base but it is not going to be installed
<lamont-away>                   Depends: python2.4-librdf but it is not going to be installed
<lamont-away>                   Depends: python2.4-pycurl but it is not going to be installed
<lamont-away> that was the last scheduled run failure
<mvo> _rob^: yes, when you use it as a user it can't install, you have to switch to root for that
<lamont-away> add gnome-applets and gnome-panel in a couple places
<_rob^> is there a way to cut that down?
<mvo> _rob^: I can't think of one right now
<seb128> \sh: they need to be sgid game to write the scores to /var/games
<_rob^> it seems like finding out your package is broken after authing is not a big deal if it doesn't install anything
<_rob^> I guess it really is worse for a modem user though
<wasabi_> mvo: don't suppose any thought has been put into making gdebi accept that .apt file idea I had? :)
<mvo> _rob^: well, that is certainly doable. and it should be ok for modem users because it will not download anything 
<mvo> wasabi_: *cough* no. but it would not be hard to add (especially nowday when we have sources.list.d)
<wasabi_> Ahh you didn't know we had that.
<wasabi_> Err
<mvo> _rob^: that is, it won't download when it detect that it can't satisfy dependencies
<wasabi_> I didn't know we had that
<lamont-away> mvo: there's support for sources.list.d???? since when?
<mvo> wasabi_: it's very recent
<_rob^> mvo: it would be good if there were a way to precalculate while a user was reading the package description
<wasabi_> That kicks ass.
<lamont-away> mvo: debian and ubuntu?
<mvo> lamont-away: the last apt upload
<mvo> lamont-away: in debian with the next apt upload :)
<mvo> lamont-away: you like it?
<mvo> lamont-away: or are you about to kick me for it?
<mvo> _rob^: that's another nice idea, just do the cache reasding in the background
<lamont-away> mvo: I don't dislike it, there are times that it would make life easier.
<lamont-away> unless, that is, you _want_ me to kick you .....
<mdke> dholbach, will you be around in the docteam meeting tomorrow at 14 utc? the "single source" thing is on the agenda
<wasabi_> mvo: some other crazy idea just hit me. Not sure if I like this crazy idea... but it hit me none-the-less.
<lamont-away> but I didn't think you were into that sort of thing.
<dholbach> mdke: yeah
<mvo> lamont-away: I take (gentle) beatings only from females ;)
<lamont-away> 'zactly
<wasabi_> mvo: instead of .apt files, now, with gdebi, a ISV can distribute a .deb. That .deb can install the gpg key and a sources.list.
<wasabi_> That sounds a little hacky, but I don't know.
<wasabi_> It might be moving the logic into just the right place.
<lamont-away> wasabi: if the deb installs a gpg key before it's validated, then we may as well just remove signed archives from existance
<lamont-away> since that would defeat the whole purpose.
<wasabi_> ?
<pitti> Kamion: I think a lot of the current breakage is due to libmysqlclient14 uninstallability; I guess mysql-common is still in NEW, right?
<pitti> elmo: ^
<wasabi_> It wouldn't install a key until the user accepted to install the .deb itself.
<lamont-away> wasabi: the idea is to validate the .deb against a known-trusted key _before_ you install some random deb.
<mvo> wasabi_: the problem remains that it must trigger a apt-get update 
<_rob^> mvo: OS X does somethign really nasty in that regards but I don't knwo what
<wasabi_> And the sources.list wouldn't be present unless a debconf question asked the user if they want to track updates.
<_rob^> mvo: it says that it must run a program to determine if you can install the software and you auth to run that
<wasabi_> Where can I find gdebi anyways?
<lamont-away> wasabi_: and how does the user know that the deb he's installing is in fact the deb that the purported author originally shipped, and not the one that I replaced the key in at the same time that I trojaned the binaries?
<ogra> wasabi_, ubuntu-devel ML
<mvo> wasabi_: source or deb? source is bzr, deb is at http://people.ubuntu.com/~mvo/gdebi
<wasabi_> lamont-away: same way we know the Ubuntu CD we download is in fact the real one.
<mvo> lamont-away: we need signed debs!
<wasabi_> There has to be an initial moment of trust, where you trust a vendor.
<lamont-away> wasabi_: because we have a trusted key that signed an md5sum file somewhere?  OK.
<wasabi_> And that trust can extend to the update process safely.
<\sh> seb128: well...how do u train gtk to understand this_
<wasabi_> lamont-away: trusted by who? :)
<wasabi_> The fact is, if an ISV is distributing a program, I have to initially trust the ISV to deliver me his public key.
<ogra> wasabi_, the strong gpg set ?
<lamont-away> wasabi_: well, in this case, the ubuntu archive automatic signing key is signed by some 'james troup' guy, who is in the well connected set, and known to be employed by canonical to do archive maintenence...  so I trust that key...
<wasabi_> okay? We're talking about people who have no relation to canonical.
<wasabi_> Like, oh, VMware.
<lamont-away> and the CD signing key is (or should be) signed by Kamion, same story
<wasabi_> At some point I have to go to https://www.vmware.com and verify that the softwae I download really comes from some random company I want to believe.
<lamont-away> vmware has people with keys in the global ring of trust who could sign such a key, etc.
<mvo> I tend to think that that random installing of deb is rare, and if people do that, they should be aware that they should at least do it over ssl (and have a cert they trust)
<lamont-away> mvo: right
<wasabi_> If you ever touch commercial software, it's not rare.
<mvo> but yeah, I agree with your concern
<wasabi_> So it's a basic question.
<wasabi_> Do we want to assist ISVs
<lamont-away> mvo: but the notion that installing some deb will modifiy /etc/apt/trusted.gpg is just a tad bit scary
<wasabi_> Or do we want to independently package everything.
<wasabi_> I'd personally like to be able to buy VMware and "Click Here To Install"
<ogra> wasabi_, whats the prob for an ISV to get a signed trustable key ? 
<wasabi_> Instead of running some shell script magic.
<lamont-away> mvo: not that there's anything preventing it from happening today, of course.
<ogra> i dont see the issue
<mvo> it will only do it via the apt-key command
<mvo> lamont-away: I mean, I see you point, but it's not scarier than the "radnom-binary-install" package we have today (e.g. for realplayer)
<lamont-away> mvo: if some random deb did 'cat >> /etc/apt/trusted.gpg', it'd work.  it'd violate policy to hell and gone, but it'd work...
<lamont-away> mvo: true
<wasabi_> Does Canonical want to be the gate keeper for ISVs keys?
<wasabi_> That's anohter question.
<wasabi_> MS made the choice to be so, for drivers.
<mvo> I don't think we want to
<ogra> wasabi_, thats what the keyservers ar or
<wasabi_> it didn't work very well imo
<ogra> *for
<lamont-away> mvo: I guess my point is that since those keys are fully trusted regardless of the source and name of the package, I'd like to personally be involved in the decision to add said key to trusted.gpg
<seb128> lamont-away: can you set an evolution-data-server build when krb4_1.2.2-11.3ubuntu2 is available?
<mvo> lamont-away: yes, that's true. that's what wasabi_ was saying about the "do auto-track of updates from this vendor" question I guess. the problem is that once you allow the install of a deb, than it really dosn't matter anymore because that deb can do whatever it wants anyway
<_rob^> wasabi: I would htink Ubuntu Foundation would be the org to looka fter that stuff
<seb128> lamont-away: ppc build that's it
<lamont-away> seb128: it'll ftbfs before that, yes?
<lamont-away> mvo: yeah
<seb128> lamont-away: it already ftbfsed
<seb128> lamont-away: it needs a retry when krb4 is built
* lamont-away just gave back most of the non-auto-dep-wait failures in main..
<lamont-away> seb128: just ppc? or everywhere?
<seb128> lamont-away: evolution-data-server? just ppc, it did build on other arches
<lamont-away> seb128: OK.  I'll make sure I kick it once it gets back to me
<mvo> wasabi_: let me know if you want to hack on gdebi, I'm happy to assist
<seb128> lamont-away: thanks, that's the remainer blocker for flight-1
<seb128> lamont-away: when e-d-s is built then gnome-panel need to be retried
<sistpoty> elmo: please sync childsplay-plugins, ubuntu override ok
* lamont-away wishes make would build
<lamont-away> seb128: the 2 ppc buildd's are currently building: krb4 and ghc6
<seb128> lamont-away: rock
<wasabi_> Yeah, my original ThirdPartyApt idea had some way to only track updates from a certain vendor for certain packages, but mvo reminded me that all of these updates are installed as root anyways.
<wasabi_> So it doesn't matter. If a vendor wants to screw with your system, he can, period.
<lamont-away> seb128: krb4_1.2.2-11.3ubuntu1 is FTBFS
<pitti> sjoerd: ping
<seb128> lamont-away: yeah, that's why I said krb4_1.2.2-11.3ubuntu2 :p
<lamont-away> heh - ok
<wasabi_> Now, if we want to prevent that, we're looking at a major deviation.
<lamont-away> the krb4 that was building was 3ubuntu1
<seb128> oh, k
<wasabi_> Like, to install third party .deb's into a seperate root.
<wasabi_> Like the n770 does.
<wasabi_> (which imo is pretty cool)
<wasabi_> mvo: I'd like to. ;)
<mvo> wasabi_: making it instller for the n770 a bit nicer is on my list for when I have some free days :)
<wasabi_> I'm a bit curious about their approach to third aprty things...
<wasabi_> /var/lib/install, and the install user.
<wasabi_> Interesting idea.
<mvo> it's pretty clever
<mvo> even 3rd party apps can't root it
<wasabi_> Yeah.
<mvo> and the user never gets root
<wasabi_> We could futz with a similar thing for gdebi... ;)
<lamont-away> seb128: dep-waited (eds and gnome-panel)
<seb128> lamont-away: thanks
<mvo> wasabi_: it's tempting :) but relocating means thatthe source for the packages needs to be modified (because a lot of them expect e.g. /etc/ as their config path)
<_rob^> mvo: mind if I dcc you a mockup of what gdebi might look like?
<wasabi_> Yeah. We do have a clean base to start with right now though, we have no third party ISVs that provide .debs
<wasabi_> Of any magnatude anyways.
<mvo> _rob^: try, I'm not sure if I have working dcc
<wasabi_> It would be interesting to if nothing else, add support for it.
<robertj> whee
<robertj> it's 1992 again!
<mvo> wasabi_: yes, I put it on my todo
<neuralis> mvo, doing it that way (separate location) also means you'd get people like me to shut up about security and be happy about shipping it with a default install.
<mvo> robertj: looks nice, did you talked to mpt? he made similar suggestions
<robertj> nope
<mvo> neuralis: heh :)
<wasabi_> Hmm. Could work out. I can see where some packages would require root access anyways.
<wasabi_> VMware being the prime example.
<wasabi_> As it needs kernel modules.
<wasabi_> gdebi could install unsigned packages into a subdir, but signed ones into /
<wasabi_> that'd be interesting.
<robertj> mvo: I really like the package info but I kinda wish there was a standard applet for investigating that
<robertj> mvo: so that you could get that same info post install as well
<neuralis> wasabi, whose signatures does it trust?
<wasabi_> Canonical.
<wasabi_> Just brainstorming.
<mvo> robertj: you mean it should look like the synaptic dialog? or what do you mean with post-install?
<robertj> anyway off to lunch
<robertj> mvo: let me look at synaptic for a second
<wasabi_> mvo: where can I find gdebi?
<mvo> wasabi_: source or deb?
<wasabi_> Both. ;)
<neuralis> wasabi, so that might not be a bad compromise. most stuff can live in a subdir; if it can't, one of the motus can perhaps inspect it and sign it, which would let it get installed in /.
<robertj> wasabi http://people.ubuntu.com/~mvo/gdebi/
<mvo> wasabi_: deb: http://people.ubuntu.com/~mvo/gdebi
<mvo> robertj: thanks :)
<mvo> wasabi_: src is a bzr archive at http://people.ubuntu.com/~mvo/bzr/gdebi--main
* mvo loves bzr
<wasabi_> I need to learn it still.
<robertj> mvo: wow I've never even seen the properties menu on the packages before, that's cool
<robertj> I was thinking something more "applied" in nature for mid-level users
<mvo> wasabi_: very, very easy: bzr {get,diff,commit,merge}
<robertj> "It installs these menu entries, here are the docs, here is the licence" that sort of thing
<mvo> robertj: right, some of this is tricky, but it looks like it's a good idea
<robertj> but anyway, I think that is relatively minor
<robertj> but more than anything, the #1 thing you can do is change the text as you go
<robertj> just "Preparing to Install" "Installing - X%" "Application Installed" or something of that sort
<mvo> yeah
<robertj> No need for a terminal menu
<robertj> err revealer
<robertj> if someone needs a terminal revealed they will go run it in a terminal
<wasabi_> Wonder if there's anyway for a package to install other packages in the postinst.
<pef> hello !
<mvo> robertj: I would love to kill the terminal, but some packages still use "read" in the postinst
<mvo> very few fortunately, but they still exist :/
* mvo  grumbles about evil postinsts
<robertj> mvo: can you just hide it then?
<ogra> mvo, its just a matter of running a sed script over the whole source archive ;)
<mvo> or redirecting stdin to /dev/null!
<ogra> robertj, read means it waits for user input
<wasabi_> Hmmm. Hmmmm.
<lamont-away> wasabi: 'man at' :-)
<wasabi_> Ugh.
<wasabi_> That doesn't work out anyways. Has to do the install with the same frontend that the original package was installed with
<lamont-away> seb128: btw, gthumb is unhappy, too.
<lamont-away> make[1] : Entering directory `/build/buildd/gthumb-2.6.8'
<lamont-away> cd . && /bin/sh /build/buildd/gthumb-2.6.8/missing --run aclocal-1.7
<lamont-away> aclocal: configure.in: 12: macro `AM_PROG_LIBTOOL' not found in library
<seb128> lamont-away: yeah, I already told to dholbach who made the upload
<lamont-away> ok
<lamont-away> did you fix heimdal when you fixed krb4? (same error)
<lamont-away> mvo: vscreen.cc:973: error: 'struct sigaction' has no member named 'sa_restorer'
<lamont-away> please fix aptitude.
<robertj> ogra: well I thought it just needed to read from a null sink or something that still required a terminal for some reason
<lamont-away> (sa_restorer is optional - memset the struct to zero, then fill in the non-zero fields...)
<robertj> ogra: but if your package is not using debconf then...too bad
<mvo> lamont-away: hu? what arch?
<lamont-away> mvo: ia64/hppa
<lamont-away> halley is a good test machine, IIRC
* mvo grumbles about niche archs
<mvo> lamont-away: thanks
* lamont-away grumbles about people assuming optional fields exist in structs
<ogra> robertj, you can put a pipe in place and send \n for the reads, but fixig the packages should be the way to go ...
<lamont-away> if it builds on halley, it's golden
<mvo> ogra: *argggg*
<lamont-away> heh... elmo: dapper chroot on halley, if you would be so kind...
<ogra> mvo, one \n every second ;)
<lamont-away> ogra: that's _VILE_
<robertj> ogra: indeed, but the easy way is "Don't expact grandma to use gdebi to install your broken packages"
* mvo runs fast!
<lamont-away> robertj: but do expect her to use it for your non-borken ones.
<ogra> yeah
<robertj> lamont: yup, sound good
<lamont-away> aspell --lang=fi create master ./fi < fi.wl
<lamont-away> /bin/sh: aspell: command not found
<wasabi_> mvo, gdebi doesn't run update-desktop-database I don't think
<lamont-away> bad ispell-fi
<ogra> mvo, no, serious, do you have a list with packages with broken postinst scripts ? 
<ogra> mvo, could be a good motu project for post feature freeze :)
<pitti> mdz, Kamion: is it a bad time to upload a new hal now? shall I wait until after flight-1?
<lamont-away> pitti: I just sent you mail, fwiw
* lamont-away giggles at perl modules
<lamont-away> make[1] : Entering directory `/build/buildd/libio-socket-ssl-perl-0.97'
<lamont-away> PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
<lamont-away> t/01loadmodule.....ok
<lamont-away> t/02settings.......Use of uninitialized value in getprotobynumber at /usr/share/perl/5.8/IO/Socket/INET.pm line 133.
<lamont-away> Use of uninitialized value in socket at /usr/lib/perl/5.8/IO/Socket.pm line 80.
<lamont-away> Use of uninitialized value in socket at /usr/lib/perl/5.8/IO/Socket.pm line 80.
<lamont-away> (that's on i386)
<pitti> lamont-away: *boggle* fetchmail built fine for me here...
<lamont-away> pitti: maybe your dapper isn't the same as my dapper...
<mvo> ogra: no, I don't have a list
<pitti> lamont-away: hm, just unpacked the source again, it still builds
<pitti> grrrr
<jbailey> pitti: grrrr at me?
<lamont-away> jbailey: nah - at fetchmail
<lamont-away> iz ftbfs
<pitti> jbailey: no :) at fetchmail, which is ftbfs on buildd and works on my box
<jbailey> Ah, okay. =)
<jbailey> Just making sure I hadn't annoyed the world for something unintentional.
<jbailey> If I'm going to piss people off, I'd like to make it good. =)
<lamont-away> jbailey: whereas intentionally annoying the world is SOP?
<pitti> lamont-away: I really don't understand - the only patch is de.po.patch; there is no such thing like 01pop3sec
<jbailey> lamont-away: My guidance councellor told me to have goals, my basketball coach told me consistancy was good.
<pitti> lamont-away: sure that this is the right build log?
<jbailey> lamont-away: Noone can say I didn't listen to my teachers.
<mdz> pitti: what will hal break?
<pitti> lamont-away: http://people.ubuntu.com/~lamont/buildLogs/f/fetchmail/6.2.5.4-1ubuntu1/ -> all successful
<lamont-away> pitti: looking more
<pitti> mdz: nothing, it works fine for both 2.6.15 and 2.6.12
<lamont-away>       253 Log for failed build of fetchmail_6.2.5-18ubuntu1 (dist=dapper)
<lamont-away>       253 Log for failed build of fetchmail_6.2.5-18ubuntu1 (dist=dapper)
<pitti> lamont-away: that's Mithrandir's failed build
<lamont-away> doh
<pitti> lamont-away: I already uploaded 6.2.5.4
<lamont-away> pitti: you can go back to sleep now...
<lamont-away> sorry about that
<pitti> lamont-away: you really scared me :)
<lamont-away> dpkg-deb: failed to open package info file `debian/lib32z1/DEBIAN/control' for reading: No such file or directory
* lamont-away beats Mithrandir with ia32-libs
<lamont-away> (ia64 is ftbfs)
<pitti> mdz: I'm just asking because of CD packages stabilization for flight-1
<lamont-away> seb128: uh.... -3ubuntu1 is still the current version of krb4.....   just thought  you'd like to know and all that.
<lamont-away> ah, was just accepted, it appears.. nm
* lamont-away gets ready to go to work
<sjoerd> pitti: pong
<pitti> Hi sjoerd 
* lamont-away wanders off
<pitti> sjoerd: I merged hal 0.5.5.1 and fixed the 'do not restart' bits
<pitti> sjoerd: also, I fixed the dbus invocation (s/reload/force-reload/)
<pitti> sjoerd: http://people.ubuntu.com/~pitti/patches/hal_0.5.5.1_ubuntu.diff is the diff in case you are interested :)
<sjoerd> pitti: why force-reload ?
<pitti> sjoerd: because it is a policy violation to use reload
<pitti> sjoerd: and reload does not exist in at least Ubuntu's dbus
<pitti> sjoerd: reload is optional, force-reload is mandatory
<sjoerd> hrm, need to check policy in that case
<sjoerd> well for dbus reload is reload your config file in debian now and force-reload is restart, which you don't want
<pitti> sjoerd: anyway, merging was nice; ubuntu specific changes are minimal :)
<sjoerd> pitti: cool, nice to hear
<pitti> sjoerd: but if debian's dbus has a proper reload, then force-reload should do the same
<sjoerd> pitti: right, need to change that then
<pitti> sjoerd: also, the current experimental package does restart hal
<pitti> sjoerd: due to some maintscripts bugs
<sjoerd> couldn't remember anymore if we said just not to restart dbus, or also not restart hal
<dilinger> jbailey: you missed a rousing cdbs3 discussion in #d-d, btw :p
<jbailey> dilinger: Ah?  Got logs? =)
<torkel> fabbione: we have to have lustre running so we have to patch the kernel anyway. Primarily it will be against the breezy kernel though
<pitti> sjoerd: oh, in Ubuntu we restart neither
<sjoerd> pitti: currently restarting hal on upgrade is still intentionally.. and i would prefer to keep it that way
<pitti> sjoerd: ah, ok
<pitti> sjoerd: then ignore these bits from the debdiff
<sjoerd> k
<pitti> sjoerd: since that breaks some apps, we don't restart hal in Ubuntu any more
<dilinger> jbailey: http://mouth.voxel.net/~dilinger/cdbs3
<sjoerd> i thought that it was the dbus restarting that breaks stuff
<pitti> both
<sjoerd> :(
<Robot101> sjoerd: by default, libdbus abort()s your app if dbus disconnects it
<dilinger> wow, CFS finally release lustre 1.2.x
<sjoerd> Robot101: i known, stupid behaviour, you can turn it off though.. But anyway we don't restart dbus anymore on upgrades
<dilinger> s/release/gpl'd/
<Robot101> sjoerd: yeah, because most applications don't bother restoring their state to it when disconnected
* Diziet lights the blue touchpaper in debian-{policy,project}.
<crimsun> elmo: please sync wpasupplicant from sid
<Kamion> pitti: please don't upload hal, unless you have already
<Kamion> mdz: status: mysql breaking (investigating now), parted spewing annoying error on install which is technically cosmetic (also investigating but will take longer), rest *should* be ok although I have a test install running now to make sure there are no other gotchas
<pitti> Kamion: not yet
<pitti> Kamion: I think mysql-common is in NEW
<Kamion> lamont-away: phew, I *did* remember to sign the cdimage signing key
<Kamion> pitti: it's not
<pitti> Kamion: or something
<Kamion>  Binary only promotions to main
<Kamion>  ------------------------------
<pitti> Kamion: hmm; it should be built from the 4-1 package
<Kamion>  o mysql-client-4.1 mysql-server-4.1                          {mysql-dfsg-4.1}
<Kamion>    [Reverse-Depends: mysql-client, mysql-server] 
<Kamion> that would do it
<pitti> aah
<Kamion> I've promoted those two
<pitti> Kamion: but does that explain the uninstallability of libmysqlclient14?
<pitti> Kamion: we have the source in main anyway and should drop 4.0 for dapper
<Kamion> hm, no
<pitti> Kamion: it depends on mysql-common, which is not available for 4.1.15
<pitti> jsut for 4.0.20
<pitti> I don't know why, the package built fine
<Kamion> eep, archive-copier failed for WEIRD reasons
<Kamion> and that would be because debootstrap has gone insane. mumble
<pitti> Kamion: argh, eek - -common is built from mysql-dfsg-5.0
<pitti> Kamion: it just contains /etc/mysql/my.cnf though, so we could fix that easily
<Kamion> pitti: mysql-dfsg-5.0 isn't in the archive
<pitti> question is jsut whether we want 4.1 or 5.0 in dapper (yay versionitis)
<pitti> Kamion: ok, I'll fix that for now; I have -4.1 build a common package if that is fine for you
<Kamion> in dapper it's built from mysql-dfsg, which is too old to satisfy libmysqlclient14's versioned dep
<Kamion> pitti: sure, please also upload mysql-dfsg to stop it building -common
<pitti> Kamion: we might just sync it, but I didn't check
<pitti> Kamion: Debian has -5.0 in unstable now
<pitti> Kamion: so Debian does not build -common from -4.1 and 4.0 any more
<Kamion> right, let's leave that until *after* Flight 1, enough breakage for one afternoon ...
<pitti> Kamion: ok, let's get 5.0 and ditch 4.1 and 4.0 later then; I'll fix 4.0 and 4.1 for now
<pitti> bah
* Kamion fixes archive-copier
<mdz> Kamion: what's mysql breaking?  server CD?
<pitti> the world...
<Kamion> /home/cjwatson/src/ubuntu/seeds/dapper/desktop: * python-mysqldb
<pitti> mdz: libmysqlclient is uninstallable
<pitti> -14
<Kamion> yay python \o/
<pitti> Kamion: oh, nothing more? heaps of packages depend on the lib, I expected more...
<doko> Kamion: just remove python-mysqldb from the seeds for now?
<Kamion> pitti: could be, haven't checked
<Kamion> doko: it's about as fast to fix mysql, I think
<Kamion> I'm not in the mood for workarounds just at the moment; we have time to do it right
<mdz> pitti: ah
<Kamion> doko: and indeed there's also python2.4-librdf
<ajmitch> morning
<Nafallo> morning ajmitch :-)
<slomo> hi ajmitch :)
<pitti> Kamion: ok, I hope I fixed it; package is building now
<Kamion> anyone know how I identify whether a device is a CD-like drive or not?
<pitti> yep
* pitti looks
<pitti> Kamion: there should be a 'media' attribute in sysfs
<Kamion> can't see one
<Kamion> 'find /sys/ -name media' returns nothing
<pitti> Kamion: erm, sorry - /proc/ide/<blockdev>/media
<Kamion> will it always be 'cdrom'?
<pitti> Kamion: it is 'disk' for hard drives, 'cdrom' for cdroms
<Kamion> it seems to be missing for this hard drive
<pitti> hmm
<Kamion> oh, duh, because it's SATA
<Kamion> what about for SCSI CD drives?
<pitti> Kamion: that's at least what udev relies on
<pitti> Kamion: SCSI: sysfs helps there, CD-ROMs are block devices type '5'
<Kamion> this is going to be a real mess to do from C
<pitti> Kamion: no idea about USB ones - maybe they behave like SCSI
<Kamion> /sys/block/*/device/type ?
<pitti> Kamion: should be
<pitti> Kamion: however, no SCSI cdrom here
<Kamion> for a change I was actually sort of hoping for an ioctl :-)
<pitti> Kamion: however, for my USB flash drive, /sys/block/sda/device/type == 0
<pitti> Kamion: hmm, wait, we might try something else
<Kamion> I suspect randomly issuing CDROM_DRIVE_STATUS to see what happens isn't a great idea?
<pitti> Kamion: which CD-ROM types do you have?
<Kamion> pitti: personally? just IDE
<pitti> me too
<pitti> hmm
<pitti> Kamion: CDROM_GET_CAPABILITY could also work
<Kamion> ooh, probably quicker
<pitti> Kamion: http://people.ubuntu.com/~pitti/scripts/cdcaps.py
<pitti> Kamion: that gives me an "invalid argument" for HDs and a proper capability value for CD-ROMs
<pitti> Kamion: that needs cdrom group privilege, though, so not everybody can do it
<Kamion> that's fine, in this context I'm root
<Kamion> (this is in parted_devices in the installer)
<pitti> ah
* pitti taps foot - build, damn mysql, build!
<Nafallo> Kamion: wxwidgets rebuilt on powerpc, could you give back tipptrainer for me please? :-)
<Kamion> Nafallo: not right now, ask lamont or infinity
<Kamion> buried in code
<Nafallo> oki, I understand.
<Nafallo> lamont-away, infinity: wxwidgets rebuilt on powerpc, could one of you give back tipptrainer for me please? :-)
<lamont-away> Nafallo: dopnme
<Nafallo> lamont-away: meaning done? :-)
* Nafallo should really learn some more langs than swedish and english.
<lamont-away> yeah - damn keyboard has extra keys on it. :-)
<Nafallo> thanx :-)
<pitti> Kamion: yay, mysql works. I upload it now
<Kamion> pitti: thanks a million for the CD help, looking good
<pitti> \o/
<pitti> so mysql is the last issue?
<Kamion> so far ...
<Kamion> I'm leaving RSN though, promised to meet Kirsten at 8pm and I'm already going to be late
<mae> how can i regenerate the hostkey for ssh
<mae> sshd
<ogra> mae, thats a #ubuntu question, man ssh-keyscan
<Kamion> no, man ssh-keygen
<ogra> Kamion, why not keyscan ? 
<Kamion> because that scans keys, it doesn't generate them
<Kamion> and it scans keys from other hosts, too
<ogra> oh, i thought it also generates
<Kamion> anyway, partman fixed, I'm off for a while, see you
<ogra> sorry for the misinfo then
<mdz> pitti: are we ready to attempt new CD builds?
<pitti> mdz: mysql is uploaded, but yet built
<mdz> pitti: ok, once it's installed I'll turn the crank
<mdz> pitti: only powerpc in so far
<pitti> mdz: almost there
<pitti> mdz: amd64 is in accepted
<pitti> mdz: i386 debs arriced :)
<seb128> re
<seb128> cool, e-d-s/evo/panel ppc are built now
<seb128> lamont-away: thanks for dep-wait/retry
<pitti> mdz: when are the cron.dailies again?
<seb128> pitti: you have a dapper ppc?
<pitti> seb128: not an up to date one
<pitti> seb128: but I can upgrade it
<mdz> pitti: :03 and :33
<seb128> pitti: don't bother
<seb128> pitti: jbailey got a "ERROR: Unbound variable: make-mutex" when running "/usr/games/sol --variation freecell", I was just curious to know if that happen for everybody on ppc
* jbailey points to the clock.  It's after core hours.  I would *never* play solitaire during my work day, of course. =)
<Nafallo> jbailey: :-)
<pitti> jbailey: I *had* to play a round of planetpelgiun-racer today to test the new SDL merge :)
<pitti> penguin, even
<jbailey> pitti: Yeah, I miss the old days where the best network tester we had was doom. =)
<lamont-away> seb128: np
<pitti> fooishbar: Hi Daniel! Why another nick today?
<jbailey> pitti: Stalker.
<ajmitch> jbailey! :)
<jbailey> ajmitch: Hey!  You back in .nz now?
<ajmitch> yeah
<ajmitch> got back yesterday
<daniels> (whoops)
* jbailey drags the how-was-the-trip conversation to #chug.
<ajmitch> :)
<Nafallo> daniels: morning :-)
<pitti> mysql-client-4.1 | 4.1.15-1ubuntu1 |        dapper | amd64, i386, powerpc
<pitti> mdz: GO, Matt! :)
<mdz> going
<Nafallo> :-)
<mdz> er, cron.daily isn't finished yet
<mdz> so this is unlikely to work
<mdz> killing it
<Nafallo> daniels: ping :-)
<daniels> Nafallo: pong
<Nafallo> will we have libxaw8-dev in the dappercycle?
<daniels> nope, never
<daniels> if I get my way
<Nafallo> oki, I'll continue to add ubuntu1 on the stuff that dep-waits on it then :-)
<daniels> there shouldn't be much at all?
<Nafallo> three packages yet. don't know how many all of them are.
<mdz> pitti: ok, really building now
<ogra> yay
<Nafallo> but I'll upload them when I have them all :-)
<daniels> Nafallo: cool, thanks
* Nafallo will need a buildd-admin at that time aswell ;-).
<Nafallo> np
<dholbach> have a nice evening
* lamont-away wonders if it's kamion or mdz that's building livecds
<mdz> lamont-away: me
<mdz> lamont-away: how badly is it broken?
<lamont-away> ppc still had uninstallables
<lamont-away> amd64/i386 hit the jackass-timing-window
<lamont-away> amd64 hit it first thing, i386 hit it at the very end
<lamont-away> that is, a rebuild on i386 should work just fine
<lamont-away>   ubuntu-desktop: Depends: python-mysqldb but it is not going to be installed
<lamont-away>                   Depends: python2.4-librdf but it is not going to be installed
<lamont-away> that was ppc
* lamont-away double checks
<mdz> that should be fixed in the current archive
<mdz> my livefs build script seems to have been broken by the recent changes
<mdz> please kick off new builds
<lamont-away> ppc is installable now.
* lamont-away kicks a set off then
<lamont-away> mdz: running now - just building ubuntu, did you also want base/kubuntu now, or later?
<mdz> lamont-away: immediately after would be grand
<lamont-away> mdz: ok
<mdz> lamont-away: now that we're mailing failures, can I get on that mailing list?
<spity> hi
<lamont-away> mdz: shortly
<spity> i guess you've already read this http://lists.debian.org/debian-release/2005/11/msg00080.html - how will that affect ubuntu?
<lamont-away> mdz: your @u.c address added to the target for any failed datacenter livecd build
<ajmitch> spity: already discussed on ubuntu-devel
<spity> whoops, i must have missed that, sorry
<ajmitch> we have a nice list of packages to rebuild :)
<lamont-away> Adding system user `cupsys'...
<lamont-away> Adding new user `cupsys' (100) with group `lpadmin'.
<lamont-away> chage: the shadow password file is not present
<lamont-away> adduser: `/usr/bin/chage -M 99999 cupsys' returned error code 15.  Aborting.
<lamont-away> dpkg: error processing cupsys-client (--configure):
<lamont-away>  subprocess post-installation script returned error exit status 2
<lamont-away> mdz: ^^
<lamont-away> Setting up cupsys-client (1.1.23-10ubuntu4) ...
<lamont-away> addgroup: Couldn't parse `/etc/adduser.conf':29.
<lamont-away> that might be the root of that....
* lamont-away tries pushing it back to the top of the hill
<spity> ajmitch: do you remember name of that thread?
<mdz> lamont-away: what happened to /etc/adduser.conf?
<sistpoty> spity: maybe this one? "library renaming due to changed libstdc++ configuration" (11/14)
<lamont-away> mdz: that's just it - it looks fine....
<lamont-away> FIRST_SYSTEM_UID=100
<lamont-away> that's line 29
<lamont-away> for example
<spity> sistpoty: oh, i'm blind :) thanks
<lamont-away> neato.  hppa livecdfs built
<mdz> lamont-away: but not the others?
<lamont-away> mdz: adduser.conf is barfing on every line that has an underscore in the LHS token name
<lamont-away> and only on those lines
<mdz>         if ((($var, $val) = /^\s*(\S+)\s*=\s*(.*)/) != 2) {
<mdz>             warnf(_("Couldn't parse %s:%s.\n"),$conf_file,$.);
<mdz> looks pretty reasonable to me
<mdz> is its locale fucked?
<lamont-away> locale should be 'POSIX'
<mdz> can't reproduce here
<mdz> has to be something with the build environment
<ogra> shadow was broken very recently, is this the fixed version ?
<lamont-away> kicking another run that'll dump env at the start of the build
<sajd> I got the same adduser.conf warnings during depper updates today, one warning for every non-comment line
<mdz> oh, you're right, it's only a warning
<mdz> lamont-away: ah, my adduser was out of date
<mdz> can reproduce the warning now
<lamont-away> Adding new user `cupsys' (100) with group `lpadmin'.
<lamont-away> chage: the shadow password file is not present
<lamont-away> adduser: `/usr/bin/chage -M 99999 cupsys' returned error code 15.  Aborting.
<lamont-away> that'd be the fatality
<mdz> lamont-away: it doesn't prevent adduser from doing the right thing, though
<mdz> yeah
<mdz> mizar:[~]  sudo chage -M 99999 cupsys
<mdz> mizar:[~]  echo $?
<mdz> 0
<lamont-away> note the lack of /etc/shadow in the livecdfs
<mdz> Version: 1:4.0.13-6ubuntu1
<mdz> chage failing if /etc/shadow is missing seems like reasonable behaviour
<lamont-away> so /etc/shadow is now required on all ubuntu systems?  wasn't in breezy
<mdz> perhaps cupsys didn't call chage before
<pitti> mdz: cupsys is still the same as breezy
<mdz> dunno then
<ogra> adduser, shadow and coreutils changed ...
<mdz> lamont-away: can you test in a breezy chroot?
<mdz> whether it's chage which changed 
<lamont-away> mdz: I just updated my hppa chroot, and coreutils was the upgrade - rerunning the livecd build there to see if it now dies.
<lamont-away> which is to say, testing a dapper livecd build in a breezy chroot is (a) non-trivial and (b) would require me to use a buildd as a devel machine (mucking about evily), which I've promised elmo I won't do.
<jbailey> lamont-away: Wow.  How many toenails were removed before that promise came out? =)
<mdz> lamont-away: just confirmed the same chage behaviour on breezy
<mdz> "chage: the shadow password file is not present
<mdz> " and exit status 3
<lamont-away> jbailey: none - I promised myself that about the same time elmo asked for.
<lamont-away> mdz: so wth???
<mdz> lamont-away: you're sure shadow didn't exist before?
<Nafallo> daniels: what's the replacement for xviewg-dev? :-)
<mdz> lamont-away: oh
<mdz> lamont-away: new adduser calls chage
<lamont-away> ah, that'd do it
<mdz> lamont-away: however
<mdz> it's supposed to cope
<mdz>   * versioned depends on passwd >> 1:4.0.12 because of the changed
<mdz>     chage exit code (now, 15) in the "shadow passwod not enabled"
<mdz>     case. Earlier versions return 3 or even a normal 1 in that case.
<Nafallo> daniels: never mind.
<mdz>     if (&systemcall('/usr/bin/chage', '-M', '99999', $new_name)) {
<mdz>         if( ($?>>8) ne 15 ) {
<mdz> lamont-away: can you check the exit code being given by chage in your chroot, and the version of passwd?
* lamont-away notes that the phrase "supposed to" is frequently a statment of mis-function
<lamont-away> <lamont-away> adduser: `/usr/bin/chage -M 99999 cupsys' returned error code 15.  Aborting.
<lamont-away> <lamont-away> that'd be the fatality
<lamont-away> looks like '15'
<mdz> lamont-away: I think that 'ne' should be a '!='
<lamont-away> so string compares would be bad there, eh?
<pitti> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339670
<lamont-away> mdz: so we're waiting on a new adduser then>?
<mdz> lamont-away: testing
<lamont-away> mdz: I need to run off, so you'll need to kick the builds...
<mdz> lamont-away: ok
<lamont-away> terranova, royal, king: bin/BuildLiveCD ubuntu
<lamont-away> or 'bin/BuildLiveCD ubuntu kubuntu base'
<mdz> I'm having one of those moments where i've fixed the bug but this bit of code isn't actually running
<lamont-away> and it'll build all 3, in that order.
<lamont-away> hehe
* lamont-away back later.
<mdz>         if( ($?>>8) != 15 ) {
<mdz>             print "HELLO HELLO2\n";
<mdz> doesn't print HELLO HELLO2
<mdz> aha
<mdz> sub systemcall {
<mdz>     my $c = join(' ', @_);
<mdz>     print ("$c\n") if $verbose==2;
<mdz>     if (system(@_)) {
<mdz>         die ("$0: `$c' returned error code " . ($?>>8) . ".  Aborting.\n")
<mdz>           if ($?>>8);
<mdz> yay for adduser
<Diablo-D3> hey guys
<Diablo-D3> any word on when vim will get fixed?
<daniels> could you possibly be any less specific?
<mdz> Diablo-D3: mu
<lamont-away> Diablo-D3: this is the channel where you would propose your patch to fix it.
<Diablo-D3> daniels: yup, but it might take a bit of effort.
<gonso> hey all!  this the right place for laptop-related questions?  web site pointed to this channel.
<lamont-away> #ubuntu is where you'd ask your question
<Diablo-D3> gonso: try #ubuntu-laptop
<Diablo-D3> lamont-away: I'd propose a patch, but I'm not sure whats going on
<mdz> Diablo-D3: it's working fine here
<Diablo-D3> all the files have been moved to /usr/share/vim/vim64 yet vim is still looking in /usr/share/vim/vim63
<daniels> if you have a detailed bug report, please file one (and no, 'vim doesnt work' does not count) at https://bugzilla.ubuntu.com/enter_bug.cgi?product=Ubuntu
<Diablo-D3> daniels: its already been filed afaik
<Diablo-D3> but I cant find it
<Diablo-D3> but I know I've seen it
<Diablo-D3> daniels: that, and arent we supposed to use launchpad for everything now?
<daniels> so search on vim.  spamming the development channel is not the answer.
<daniels> not yet, no.
* Diablo-D3 wants bugzilla.ubuntu to dddddddiiiiiiiiiieeeeeeeeeee
<mdz> uploaded adduser 3.78ubuntu1
<daniels> Diablo-D3: if you're not going to remain on-topic, please leave.
<LaserJock> Kamion: ping?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | http://cdimage.ubuntu.com/daily/current/
<sebest> hello, what is the status of dot ubuntu
<mdz> daily CD build looks good from the outside
<Diablo-D3> daniels: why must you always attempt to pick a fight? you know this is why quite a few people don't like you.
<mdz> LaserJock: he's off for the night
<mdz> Diablo-D3: please keep the noise in this channel to a minimum
<LaserJock> mdz: darn, thanks though
<Diablo-D3> mdz: this is what I'm asking daniels to do.
<daniels> sebest: if there's any new movement, it will almost certainly be documented at the spec page.  if there's nothing there, then there's almost certainly been no movement on the spec.
<sebest> daniels, thanx i asked because i thought the spec wasn't update since ubz
<Kamion> mdz: you didn't start install CD builds before archive-copier and partman-base were built, did you?
* Kamion goes to check
<mdz> Kamion: what versions do we need?
<Kamion> hm, looks ok
<Kamion> LaserJock: yes?
<mdz> Kamion: aren't you supposed to be at the pub?
<Kamion> mdz: I was
<LaserJock> Kamion: I have found some source packages that don't have a "Section:" in them. They are in the debian-installer section on debian
<elmo> ok, so if I do Build-Depends: foo, bar 
<elmo>  blah
<LaserJock> Kamion: crimun suggested that I talk to you about it
<Kamion> LaserJock: nobody in their right mind cares about source packages without sections
<elmo> ok, so if I do Build-Depends: foo [anarch] , bar (>= 1) | foo (>= 1), if apt and/or sbuild will DTRT?
<mdz> elmo: meaning install bar even on anarch?
<Diablo-D3> http://bugzilla.ubuntu.com/show_bug.cgi?id=19783
<Diablo-D3> if anyone cares.
<elmo> oh, sorry, foo c/r/provides bar
<LaserJock> Kamion: so it's not a problem?
<Kamion> LaserJock: no
<elmo> mdz: meaning you must install foo on 'anarch', but bar or foo will do elsewhere
<Kamion> unless you can explain something concrete it breaks rather than "I noticed an inconsistency"
<mdz> elmo: yeah, should work 
<Kamion> argh, grub still isn't on current CDs
<mdz> hmm, awty doesn't cope with a lack of d-i daily builds
* Kamion does another 'baz update'
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510
<mdz> ;-)
<Kamion> good call
<ogra> heh
<sistpoty> so i can't ask about my dapper's bird flu here?
<Diablo-D3> -_-
<Diablo-D3> sistpoty: thats not even funny to joke about
<sistpoty> sorry
<Diablo-D3> we all know there are no viruses for linux.
* daniels sighs.
<mdz> sistpoty,Diablo-D3: please, we're trying to get some work done in here
<sistpoty> again: sorry
<Kamion> (install CD rebuild running)
<mdz> Kamion: seems much faster now
<Kamion> 15 minutes instead of an hour or so, yeah
* daniels frowns at mcpp.
<daniels> mdz: can you remember if stripping trailing spaces from a #define is considered bad form? it is, yeah?
#ubuntu-devel 2005-11-23
<mdz> daniels: dunno
<mdz> trailing whitespace on macro definitions sounds like IOCCC material
<Kamion> that seems an entirely sane thing to do
<Kamion> I can send you a PDF of the C99 standard if you like
<daniels> no, thanks
<Kamion> decomposition into tokens and whitespace (including comments) happens before execution of preprocessing directives
<daniels> unless you want me to email you the ICCCM or something equally thrilling straight back
<daniels> okay, cool
<mdz> Adding to CD 1 : pool/main/g/grub/grub_0.95+cvs20040624-17ubuntu7.dsc pool/main/g/grub/grub_0.95+cvs20040624.orig.tar.gz pool/main/g/grub/grub_0.95+cvs20040624-17ubuntu7.diff.gz
<mdz> or more interestingly, Hardlink: /srv/cdimage.no-name-yet.com/scratch/ubuntu/tmp/dapper-amd64/CD1/pool/main/g/grub/grub_0.95+cvs20040624-17ubuntu7_amd64.deb => /srv/cdimage.no-name-yet.com/ftp/pool/main/g/grub/grub_0.95+cvs20040624-17ubuntu7_amd64.deb
<daniels> mcpp was writing out one space for whitespace separators, so #define FOO bar\n, was going to 'bar '; I changed it to always skip separators, but that means that #define FOO bar \n, goes to 'bar'
<Kamion> mdz: the slowest bits of the build now are (a) syncing the archive (which can speed up quite a bit once we switch to launchpad, since inter-component symlinks in the pool will always be universe->main, never main->universe as they sometimes are now) and apt-ftparchive
<mdz> Kamion: is apt-ftparchive not using a cache?
<Kamion> mdz: as far as I know it is; there's certainly an apt-ftparchive-db/ in scratch
<mdz> Kamion: in scratch, meaning it's not persistent across builds?
<Kamion> no, scratch is persistent across builds
<Kamion> it's randomly wipable, but persistent
<sistpoty> lamont-away: anything unusually on floe today (2042
<sistpoty>  +) 
<Kamion> hmm, the cache is of stuff in scratch/.../tmp/... - does it by any chance invalidate on timestamp?
<mdz> Kamion: I don't think it does
<Kamion> it might just be md5summing everything to check it's still the same, or something
<Kamion> or forking gzip a load of times?
<mdz> it should only be forking gzip for the Packages files, which shouldn't take long
<mdz> an strace with timestamps would be interesting
<Kamion> mdz: oh, it's using generate, and apt-ftparchive(1) says that the db has no effect on the generate command
<Nafallo> infinity, lamont-away: could one of you please clear the dep-waits on aewm crossfire crack-attack eli mixxx after 23:33 UTC, thanx.
<Kamion> is that actually true?
<mdz> Kamion: I think that's referring to the command line option only
<mdz> for generate, you should use BinCacheDB
<mdz> inside the config file
<Kamion> we're using Dir::CacheDir
<Kamion> Dir::CacheDir "$APTTMP/$CODENAME-$ARCH/apt-ftparchive-db";
<Kamion> is that insufficient?
<Kamion> it seems to be creating packages-$(ARCH).db
<mdz> yeah, that should be OK
<mdz> is the .db of a believable size?
<Kamion> 11MB
<Kamion> I'll get you an strace -tt at the next opportunity
<Kamion> but last time I straced it, I seem to remember it forking processes for every .deb
<Kamion> or at least lots of .debs
<mdz> it takes an unexpectedly long time on jackass too
<mdz> could just be buggy
<Kamion> install CD builds done
<mdz> that explains why my rsync just slowed to a crawl
<mdz> yay for I/O
<mdz> we have a package called crack-attack?
<ogra> mdz, my gf is addicted to it
<Nafallo> :-)
<daniels> how on earth have you not managed to encounter crack-attack?
<Nafallo> it's actually real fun :-)
<daniels> it was frozen-bubble before frozen-bubble ever frozen-bubbled
<ogra> in fact that was the reason why i had to install her warty back then
* mvo installs crack-attack
<mdz> I have played enough games for a lifetime
<ogra> heh
<mdz> well, spent enough time playing games at least
<mdz> mostly just a few different ones
<kentborg> Is this the place to ask about compiling and installing custom kernel?
<pitti> kentborg: no, #ubuntu please
<kentborg> OK, thanks.
<sistpoty> elmo: please sync cycle from unstable, ubuntu override ok
<kentborg> How can I find out how the stock initrd was made?
<Kamion> which stock initrd?
<kentborg> Kamion: Breezy Badger
<kentborg> Kamion: 686
<kentborg> Kamion: or, more specifically, initrd.img-2.6.12-9-686
<Kamion> kentborg: it's generated by mkinitrd on your system when the kernel is installed
<Kamion> there is no one stock initrd for everyone
<kentborg> Kamion: When I try to generate one, I get a very different result (contents and beavior) from the one I didn't explicitly make.
<Kamion> oh, sorry, breezy, mkinitramfs not mkinitrd
<mdz> yay, i386 livefs build succeeded
<Kamion> d'oh, base-config fails
* ogra downloads
<Kamion> E: failed to rename /var/lib/aptitude/pkgstates to /var/lib/aptitude/pkgstates.old - save_selection_list (2 No such file or directory)
<kentborg> Kamion: I tried mkinird, let me see if I have better results with mkinitramfs. Thanks.
<mdz> amd64 as well, but powerpc failed
<robertj> http://www.oxygen-icons.org/?cat=3 <-- yummy icons...
<Kamion> kentborg: ok, please ask over on #ubuntu if you have further problems there
* Nafallo uploads :-)
<Kamion> pkgstates.new exists but pkgstates doesn't; eh?
<kentborg> Kamion: No one seemed to know over there. I am currently digging through the kernel-team archives. Thanks.
<Kamion> kentborg: I'm sorry, we're just trying to prepare a release in here is all
<Kamion> this has never been intended as an escalated support channle
<Kamion> el
<Evaso> anybody could try to apply this patch to warty and breezy?: http://bugzilla.gnome.org/show_bug.cgi?id=321671?
* Kamion -> bed
<ogra> mdz, where do you hide the live iso ? 
<mdz> ogra: I said livefs, not live iso
<ogra> oh... 
<ogra> ok
<SEJeff> Would anyone be willing to add support in dapper for the zoom button in the Microsoft Natural Ergonomic 4000 keyboard if it meant I bought one for them?
<mdz> I'm waiting for powerpc and then I will do live CD builds
<Nafallo> infinity, lamont-away: could one of you please clear the dep-waits on egoboo playmidi ppracer ppxp sage seyon xbill xmoto xpilot-ng xruskb xsysinfo after 00:33 UTC, thanx.
* Nafallo goes to bed, goodnight all! :-)
<ispiked> where is the cvs root for the current ubuntu kernel?
<SEJeff> ispiked: ubuntu uses bzr not cvs
<bob2> no
<bob2> it uses git
<mdz> ispiked: http://www.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/
<bob2> http://www.opensubscriber.com/message/kernel-team@lists.ubuntu.com/2404862.html
<ispiked> basically, what I'm trying to find out is what patches are being applied to the most current kernel. 
<ispiked> how close is it to Debian's kernel?
<SEJeff> ispiked, apt-get source linux-image-386
<ispiked> SEJeff: that'll be the most current one?
<SEJeff> yes
<ispiked> SEJeff: thanks.
<mdz> no
<mdz> that will get you the source for linux-meta
<bob2> very different to Debian's, since Debian does not take feature patches
<mdz> ispiked: the changelog lists the patches included
<ispiked> mdz: which changelog?
<ispiked> bob2: so it's not even related to Debians?
<mdz> ispiked: the changelog in the package, as found on an installed system
<bob2> yes
<ispiked> mdz: yeah, I found that one, but that's only for my kernel (2.6.12). I know that there's been more work done since then, so I want to find out what patches went in since then.
<mdz> ispiked: then, logically, you would look in the same place with a newer version
<ispiked> mdz: yes, but where would I find that newer version?
<mdz> ispiked: in dapper
<ispiked> mdz: so apparently work has just started on the 2.6.15 kernel?
<mjg59> ispiked: See the topic of #ubuntu-kernel
<mjg59> There's a git tree for current development work
<ispiked> is there any reason they chose to use git over cvs? does git have advantages for kernel dev. or something?
<mjg59> git is used for upstream
<mjg59> It makes it much easier to merge in upstream changes automatically
<lifeless> ispiked: kernel dev uses git.
<SEJeff> ispiked, cvs isn't that great. That is why most use more modern SCM like bzr or svn
<tseng> mjg59: tangentially, broken usplash it to be expected?
<mjg59> tseng: Is it?
<mjg59> I've no idea
<mjg59> I haven't had time to shift to dapper yet...
<mdz> mjg59: 2.6.15 seems to have horked vga16fb
<ogra> tseng, 2.6.15 ?
<tseng> ogra: yes.
<mdz> at least for usplash purposes
<ogra> thats normal it seems
<mjg59> mdz: Horked vga16fb, or it's just not getting loaded?
<mdz> mjg59: loads, but displays garbage
<mdz> garbage with vaguely the right palette
<ogra> it even shows some scrolling stuff
<mjg59> Oh, right. Fun.
<robertj> SEJeff: you should look up the cost to buy the thing and post it as a launchpad bounty
<SEJeff> robertj: I have one. It is $50 and I will buy one for anyone willing to make it "just work TM" for dapper
<SEJeff> robertj: Do more of the developers look at launchpad for bounties?
<robertj> SEJeff: I would hope so
<mdz> live cd build started, will be 20051118.1
<ispiked> SEJeff: it?
<mdz> bbl
<robertj> ispiked: http://www.microsoft.com/hardware/mouseandkeyboard/features/zoomslider.mspx
<SEJeff> ispiked, http://www.everythingusb.com/microsoft_natural_ergonomic_keyboard_4000.html
<robertj> does it just work like a scroll wheel?
<ispiked> I'd be willing to put up a bounty to get suspend resume working on SATA.
<SEJeff> robertj: No
<daniels> getting proper magnification support in X requires well-accelerated Composite, which won't happen in the dapper timefrmae
<SEJeff> robertj, and none of the function keys work
<daniels> SEJeff: you don't have an f-lock button?
<robertj> err ctl+scroll or whatever it is
<daniels> if you do, press it
* SEJeff is an idiot. I just got the keyboard today
<ogra> mjg59, http://people.ubuntu.com/~ogra/usplash.png
<robertj> ogra: is that going to be the new default for dapper?
<ogra> heh, yeah
<ogra> new digital modernism
<mjg59> ogra: Woo, cool
<mjg59> That's a VGA mode issue, I think
<robertj> is the ScaryText(tm) going to remain?
<mjg59> robertj: Ideally not
<robertj> every time I see it I think "Reticulating splines"
<mjg59> Do we have a d-i built with 2.6.15 yet?
<mjg59> If so, does it have the same issue?
<mjg59> If not, it's probably a bogl issue
<robertj> which is what is stuck in my head as being symbolic for something complicated you don't need to know about and is done by the time you realize what has happened
<robertj> and also as something most people don't have any idea about ever unless they get a dictionary
<robertj> ahh 529.wav for you still with sc2k
<crimsun> hmm, I take it we should be building against ssl 0.9.8
* robertj discovers the Rhuminate button
<mdz> daily live build is up (untested)
<ogra> grmbl... and the rsync server seems limited to 2 connections per ip
<mdz> freetype has broken firefox, grrr
<infinity> Nafallo_away : All your dep-waits are cleared.
<ogra> infinity, ping
<infinity> ogra : I just spoke 2 minutes ago. :)
<ogra> infinity, yes, i'm sleepy sorry ...
<ogra> infinity, you are the one to poke for initramfs-tools now ? 
<infinity> So I'm told. :)
<ogra> infinity, there is a "sleep 3" in the nfs script we added for debugging klibc once ... it slows my thin client boot down or 3 secs, culd you delete it please ?
<ogra> /usr/share/initramfs-tools/scripts/nfs ine 36
<ogra> *line
<infinity> Are you positive it's not needed?
<ogra> yes
<ogra> mdz added it to avoid a timeout ... but it didnt really help
<ogra> it was forgotten after we found that klibc had the wrong timeout settings for nfs mounts
<ogra> so it can be dropped now
<mdz> but that didn't fix the problem either
<mdz> apparently
<ogra> it doesnt time out anymore
<ogra> just the first boot is slow ...
<infinity> The comments in #12942 lead me to believe it's fixed...
<ogra> yup, i think the timeout on first boot is not related ...
<ogra> s/TIMEOUT/delay/
<ogra> whoops ...
<ogra> ECAPS
<infinity> Anyhow, I'll happily remove the sleep (and any sleep I run across that can't properly explain itself)
<ogra> yeah :)
<ogra> mdz, seen #19407 yet ? 
<mdz> no
<crimsun> uhh, sorry to whoever already uploaded vegastrike_0.4.3-3ubuntu1_source.changes
<ogra> that was Nafallo
<crimsun> yeah, I should have read the list first :/
<ogra> did youupload 3ubuntu2 ?
<crimsun> no, I duplicated his work I think
<ogra> but that was rejected then, wasnt it ?
<crimsun> yeah
<crimsun> just wanted to alert in case it spams the REJECT
<ogra> i think it goes only to you (and elmo)
<jsgotangco> hey ogra doing an all-nighter?
<ogra> nah
<ogra> about to go to bed
<jsgotangco> ahhh
<ogra> night
<jsgotangco> night
<note>  /msg nickserv set unfiltered on
<note>  /msg nickserv set unfiltered off
<tseng> note: you missed.
<dabaR> Hi. In synaptic, if I see a possible improvement, who can I talk to, to implement it, and get it accepted by Ubuntu?
<dabaR> Such as the Mark additional required changes dialogue does not have a title.
<dabaR> And some other nuances in the GUI.
<crimsun> file bug report(s) in bugzilla on the package
<dabaR> I would like to make the changes myself.
<ispiked> dabaR: so make them, make a diff and attach it to the bug.
<dabaR> OK, I will do so, I was asking because I never did any work on such a thing yet.
<desrt> dabaR; you should find that ubuntu has a very low barrier for becoming involved
<dabaR> Right, like just now...:)
<dabaR> I already know what to do.
<desrt> fwiw: ubuntu is switching over to using launchpad to track bugs
<desrt> might want to get an account there and use that instead of the bugzilla
<ispiked> aww.
<desrt> launchpad.net
<ispiked> I love bugzilla.
<desrt> me too... but such is the way of things :)
<dabaR> I do have an account there, as I started using Ubuntu right away when it was released(which was on my birthday by some chance) and I did a small amount of translation work there. I also hang at #ubuntu often.
<Burgundavia> dabaR, you need to talk to mvo. Synaptic is very much in maintence mode right now
<Burgundavia> dabaR, the things on the horizon are gnome-app-install and smart
<lamont-away> Nafallo_away: anything that was dep-wait libxaw8-dev isn't anymore
<fabbione> morning
<fabbione> infinity: ping?
<Burgundavia> morning fabbione 
<Burgundavia> fabbione, what is the status of multiseat?
<fabbione> Burgundavia: up for adoption
<Burgundavia> fabbione, just wondering. Figured
<fabbione> it hasn't been maintained for a while
<fabbione> dead project .. sort of
<Burgundavia> why was it developed?
<fabbione> as a base for the community to pick it up and continue it
<Burgundavia> ok
<fabbione> given the very low interested i think we can safely say that it's dead
<marilize> morning all :)
<Burgundavia> morning marilize 
<fabbione> but it was working
<Burgundavia> fabbione, ok
<fabbione> hey marcin 
<fabbione> bah
<fabbione> marilize: 
<fabbione> Burgundavia: afaik it doesn't require much love.
<fabbione> it needs to have the x config writer sort of updated to the new one
<fabbione> and some sound love
<Burgundavia> ok
<fabbione> that at the time was not possible to complete because i was lacking the hardware for testing
<fabbione> but it might need more by now
<fabbione> like keyboard/mouse hotplug
<fabbione> not sure.. really
<Burgundavia> I should talk to me company
<Burgundavia> we might be able to adopt it
<jsgotangco> nice
<fabbione> eheh  nice :)
<fabbione> have fun tho
<Burgundavia> fabbione, I work for http://userful.com/
<fabbione> i see
<fabbione> well that would make sense
<Burgundavia> hence we might have a few people that know a little bit about multiseat linx in general
<fabbione> yeah the multiseat setup is not difficult really
<fabbione> our Xserver already contains all the patches required to do that
<fabbione> including the hotplug signal to reinit mouse/keyboard
<fabbione> if you will start on the project, i will give you an head up on the code
<fabbione> or daniels can
<Burgundavia> sounds good
<viviersf> why does hal depend on X libraries ?
<Keybuk> all the cool kids do these days
<Keybuk> there's a 12-step programme for breaking the dependency, but it's not well subscribed
<viviersf> chmj, why does hal depend on X libraries ?
<fabbione> viviersf: because all the cool kids do these days
<chmj> viviersf: you shoudl ask pitti, he will prolly have a good answer 
<viviersf> kk
<chmj> morning fabbione 
<viviersf> fabbione, it not about that hal on the initrd.gz doesnt have x so its not needed
<fabbione> hi Chipzz 
<fabbione> bah
<fabbione> i hat completion
<fabbione> hi chmj 
<fabbione> viviersf: i doubt there is hal in the initrd.gz
<viviersf> ah wait
<viviersf> im thinking about hotplug
<viviersf> soz
<fabbione> hotplug is going to die anyway
<fabbione> so what is your concern exactly?
<fabbione> hi pitti
<viviersf> fabbione, no man
<viviersf> i made mistake
<viviersf> dont worry bout it
<fabbione> ok
<fabbione> i am not worried at all.. really
<hunger> viviersf: What is going to replace hotplug? Will the scripts in /etc/hotplug stay?
<viviersf> hunger, i dont know
<viviersf> that you have to ask piiti
<chmj> < fabbione> hotplug is going to die anyway
<pitti> hunger: it will be replaced by a small set of udev rules
<HiddenWolf> pitti, any ETA?
<hunger> pitti: I have a couple of custom scripts in /etc/hotplug. Do you know of any instructions on how to transfer them to the new system?
<Keybuk> hunger: no, /etc/hotplug is going
<Keybuk> new scripts should be moved to /lib/udev (or similar) and activated with a udev rule
<Keybuk> so if you had a script for USB printers, you might have a rule that did BUS=="usb", KERNEL="lp[0-9] *", RUN+="/lib/udev/fiddle-with-usb-printers"
<Keybuk> with an == where I put = <g>
<hunger> Keybuk: OK, so I'll do that instead.
<hunger> Keybuk: Let's see whether I can manage that:-)
<hunger> Is pcmcia going, too? I read in the kernel changelogs that it got merged with hotplug.
<Keybuk> I'll write up a HOWTO at some point over the next 6 months
<Keybuk> ya know, I have no clue as far as pcmcia is concerned
<hunger> Keybuk: Any ETA for the change?
<Keybuk> one minute it seems to be, one minute it isn't
<Keybuk> pcmcia is certainly part of the kobject stuff now
<Keybuk> so theoretically, you don't need cardmgr
<Keybuk> but cardmgr still does things, so maybe you do
<hunger> Keybuk: Yeap, that was my impression, too:-)
<Keybuk> hunger: maybe today ... depending how much work I get done
<hunger> Keybuk: Too few users for pcmcia nowadays I guess.
<Keybuk> yeah
<HiddenWolf> Go keybuk!
<HiddenWolf> hunger, not true.
<hunger> Keybuk: OK, I'll reserve some time over the weekend to fix up xen:-)
<HiddenWolf> hunger, all those el-cheapo student laptops with plug-in wifi cards.
<hunger> HiddenWolf: Oh, you are right of course.
<Keybuk> the HardwareDetection spec pretty much describes what we're going to be doing
<Keybuk> breezy does:
<HiddenWolf> I doubt pmcia will die any time soon.
<Keybuk> kernel calls /proc/sys/kernel/hotplug, which is udevsend, which sends a message to udevd, which starts udev, which runs hotplug, which picks an appropriate hotplug agent from /etc/hotplug, which calls grepmap to parse the /lib/modules/$VER/*.*map files to find the modules, and then loads the modules, and does other crap
<Keybuk> dapper will do:
<Keybuk> kernel sends event over netlink socket to udevd, which runs the rules itself, one of which is "modprobe $MODALIAS" (a variable set by the kernel to identify the modules you need to load)
<Keybuk> for the "other crap" in dapper, you'd just need to add a udev rule
<Keybuk> a good example is /etc/udev/rules.d/hdparm (in current dapper)
<Keybuk> except that file is completely bogus, lol
<Keybuk> la la la
<Keybuk> clearly I did that one while jetlagged
* hunger is afraid that this new system will mess up my virtual network setup completly:-(
<hunger> Hehe... more suff to play with.
<Keybuk> how does it work, I'm entirely happy to sit down and figure it out with you
<Keybuk> basically where you had a general /etc/hotplug/$SUBSYSTEM/$SCRIPT that becomes a udev rule that looks like SUBSYSTEM=="$SUBSYTEM", RUN+="$SCRIPT"
<hunger> Keybuk: Lots of tun and vif interfaces connected to various bridges.
<Keybuk> but you get all sorts of new flexibility to put all the "should I do this?" logic in the udev rule, rather than the script
<Keybuk> the fun comes trying to convert a usermap into a udev rule
<hunger> Keybuk: The "problem" is that this has to work with the scripts from Xen and Co.
<Keybuk> right
<hunger> Keybuk: By the way: Will /etc/network/if-*.d still be supported?
<Keybuk> the good news is that what we're doing now is the same as SuSE
<hunger> Keybuk: Even with NetworkMagic?
<Keybuk> and hopefully everyone else will tag along too
<hunger> Keybuk: Usually that is a reason to run and hide;-)
<Keybuk> heh, /etc/network/if-*.d don't work in breezy -- but yes, they should work
<Keybuk> nah, the SuSE hotplug guys are sane
<hunger> Keybuk: They do here...
<Keybuk> they work if the card is brought up after boot
<Keybuk> but not if its brought up at boot time
<hunger> Keybuk: Oh. Haven't even noticed that yet.
<hunger> Keybuk: Since standby started to work stortly before breezy I have not seen the need to reboot;-)
* freeflying is away: Away at the moment
<hunger> Keybuk: Thanks for the informations! I'll not keep you from your work any longer:-)
<Keybuk> you're not keeping me
<Keybuk> I'm currently grinning, because it wasn't me who wrote that bogus hdparm.rules file, but it came from Debian
<Keybuk> Working for this Company has warped my mind
<Keybuk> it's magazine day, and on the back of SFX is an advert for "HE-MAN: A Christmas Special"
<fabbione> ahahah
* Treenaks calls the MOTU
<Keybuk> if we ever have a fancy-dress party at a conference, dholbach is doomed; it's the red furry underpants and boots for him
<seb128> :)
<Keybuk> unfortunately this would mean \sh would have to go as she-ra
* Treenaks dies from shock
* freeflying is back.
<dholbach> hi
<Keybuk> dholbach: we were just talking about you
<dholbach> Keybuk: oh really? about what?
<Keybuk> about your costume if we ever have a conference fancy-dress party (furry red underpants and boots)
<dholbach> Keybuk: who had that much imagination?
<Keybuk> nobody, SFX just has a big he-man advert on the back and my mind is still warped
<mvo> haha
<ajmitch> remind me not to turn up to that party :)
<dholbach> Keybuk: if i was about to wear that dress, what would you wear?
<seb128> dholbach: you don't want to know :p
<seb128> don't be scared :)
* mvo makes a note to buy dholbach this special dress
<dholbach> seb128: if i'm going to turn up in a silly dress, i don't want to be the only one :)
* seb128 makes a note to take his camera
<Keybuk> ya know, I have absolutely no idea ... suggestions gratefully received on a postcard
<dholbach> "furry red underpants and boots" ...
<seb128> I'll have to take pictures of that
<Keybuk> I don't lead the MOTU ... though if I get to swing a big sword around ... <g>
<seb128> Diziet: around?
<sivang> Morning all!
<viviersf> Kamion, you got any suggestions to get a ubuntu system down to bout 120 mb /
<viviersf> ?
<HiddenWolf> viviersf, xfce. ;)
<viviersf> erm HiddenWolf 
<viviersf> thats a dumb comment
<fabbione> viviersf: you could start looking at ubuntu-meta
<fabbione> and start trimming that down 
<viviersf> even without gnome or kde its 300 mb
<viviersf> and ive removed allot
<viviersf> thx fabbione 
<viviersf> lemme look
<fabbione> perhaps rename it to something like microubuntu-meta
<HiddenWolf> hm
<HiddenWolf> I figured ram. :)
<fabbione> viviersf: did you try the server install?
<viviersf> nope fabbione 
<viviersf> im remove all unneeded stuff
<fabbione> start from there
<viviersf> cos xorg still has to be on
<fabbione> iirc it's about 200Mb
<fabbione> oh
<fabbione> meh
<viviersf> ya its being a mission
<HiddenWolf> viviersf, I'd say strip it down to ubunt-minimal with debfoster, then add xorg again.
<viviersf> k how big is a ubuntu-minimal install ?
<viviersf> in hdd space
<fabbione> iirc about 200MB
<fabbione> but it can go down than that
<viviersf> kewl
<viviersf> lemme look thx
<fabbione> but there is NO X there
<fabbione> X is kind of big to pull in
<viviersf> i need x 
<viviersf> for nxclient
<HiddenWolf> X is like, big.
<viviersf> nah not that big
<viviersf> k look 
<viviersf> here is the thing :
<viviersf> i need a distro
<viviersf> then i compress it with squashfs
<viviersf> and then it must be 32mb :(
<viviersf> so 100mb odd will be perfect
<viviersf> before its compressed
<viviersf> atm its 300 before 
<viviersf> so lemme try the cutdown ubuntu 1st
<carstenh> grep-status -nsPackage -FPriority "required" will tell you which packages you really need, excluding apt, kernel and bootloader
<JaneW> Reminder: Could everyone with Dapper Specs please  go into the Spec on LaunchPad and in the Update Status section add their Estimated Developer Days for implementing the spec. Thanks.
<Keybuk> JaneW: is that the number of days to implement the spec if you had no other work to do, and could focus on it for every hour of the day
<Keybuk> or the number of days taking into account being distracted on IRC, dealing with e-mail, bug reports, merges, etc. along the way?
<Keybuk> or is it the number of days /from now/ that you expect the spec to be completed, bearing in mind all of the above and other specs in front of it in the priority queue?
<JaneW> Keybuk: arrgh
<JaneW> Keybuk: I would say do the estimate in issolation, if someone was given that spec how long would it take them to implement (assuming they didn't need to study for 3 years first to understand it!)
<Keybuk> and should I take into account the fact that on most days I'm only really productive on a given task for maybe a couple of hours a day?
<Keybuk> not that it really matters, I guess
<Keybuk> I'll probably just pick a random number and multiply by 10 like I usually do <g>
<Keybuk> it's turned out to be an uncannily accurate guess 
<pitti> JaneW: I did not consider it as ETA, but as pure work time for that very goal
<JaneW> Keybuk: no I think let's say this task would take 10 full days (i.e. 8 hour days)
<hunger_> Keybuk: Hey, that's my algorithm, too! ;-)
<Keybuk> so 10 full 8 hour days would equate to 40 "normal" days ?
<JaneW> well need to load balance for ppl with high operational over heads 
<viviersf> ij carstenh , i got required list, now how do i get the reverse of it ?
<Keybuk> in my experience of many different companies, all of whom tried this "time estimating" thing, the best way to work out how long something will take is to do it, then work out how long it took you
<JaneW> Keybuk: so if you have 10 goals and they are all 100 days, clearly that's too much, and we'd need to redistribute or clone you or something...
<Keybuk> it's easier, and more accurate, than the eternal "keep track of how far off our estimates of time were so we can improve our ability to estimate"
* Keybuk has yet to find anyone who can accurately estimate the time a project would take
<Keybuk> not that I'm cynical about the whole "man days" thing, or anything, you understand
<JaneW> Keybuk: yeah sure, but you should know if it;s a one day, one week or one month kind of a task more or less
<JaneW> Keybuk: we are mainly doing it it try to prevent overloading ppl as badly as last time
<carstenh> viviersf: use something like cmp $(...) $(dpkg --get-selections | grep -v deinstall | greo install | awk '{print $1}')
<Keybuk> Keybuk's Laws of Software Engineering
<Keybuk> 1) it will always take longer than you think
<carstenh> where ... is the code you already have
<Keybuk> 2) the time something will take is raised to the power of the number of people involved
<JaneW> Keybuk: and in my expereince you can justify more resources without dreaded metrics
<Keybuk> 3) specifications are the best way of documenting exactly how it _won't_ be implemented
<Keybuk> JaneW: more resources = see keybuk's second law :p
<JaneW> Keybuk: yes but with 20-50 ppl involved some attempt at organisation is required
<pitti> Keybuk: these are all mere corollaries of Murphy's law :)
<Keybuk> I'm a very unpopular estimator :-/  I once angered management by claiming something would take 18 months to do, and they informed me they couldn't tell the customer that
<carstenh> viviersf: should be <() instead of $() of course
<Keybuk> 18 months later, the customer had gone elsewhere because they got fed up with being repeatedly told "just another month" for the 18th time
<siretart> hi folks
<pitti> Keybuk: reminds me of Scotty's '8 weeks' estimate in Star Trek 4
<pitti> anyway, back to kernel testing
<Keybuk> pitti: that's so true though :)  ALWAYS multiply your estimates, so if you get it done quicker, you seem like a miracle worker; and if you don't, you can't be blamed
<siretart> does anyone know if daniels is actually aware that his new xorg 7 servers ftbfs?
<Keybuk> siretart: almost certainly; he probably doesn't care though :-(
<siretart> okay :(
<Treenaks> siretart: he does know. it's waiting for new binutils/libc afaik
<viviersf> ok any1 here know how you clear the mbr
<viviersf> and not with lilo -M
<fabbione> viviersf: these are more #ubuntu questions, but you can use dd
<viviersf> fabbione, i asked there yesterday and it didnt work
<viviersf> they didnt know how
<fabbione> ask again really
<fabbione> users change a lot from day to day
<fabbione> and this isn't a support channel
<mvo> ogra: is tipptrainer a edubuntu app? or do I need to talk to the motus about it? (if it's not a edubuntu app, have a look, it's very useful)
<Nafallo> mvo: it's in universe atleast. I was last-uploader ;-).
<dholbach> mvo: so you now know who to flame :)
<Nafallo> :-)
<hunger> dholbach: Uses do like to express there eternal gratitude, they never flame! ;-)
* mvo whishs that would be the case
<JaneW> Keybuk: my last job was a place where 18 months would go by arguing about what to do, and how to do it, and how much it would cost, and then they'd want it done urgently in 3 weeks!
<Keybuk> JaneW: ahhh, spec-driven development <g>
* Keybuk blinks at X
<Keybuk> it's ok, I didn't need a mouse cursor
<Keybuk> I wonder whether that's a new X bug
<Keybuk> or the "don't modprobe psmouse before the USB stack" bug
<Keybuk> looks like iz kernel bug
<Keybuk> ...now, where did I read all about that bug and why it happens and how we fix it?
<Kamion> ok, last night's install failure turns out to be fixed in Debian's aptitude; merging
* \sh has a big big big big problem...and I wonder who is responsible for this
<Nafallo> lamont-away, infinity, Kamion: could one of you please clear the dep-wait on mixxx (ia64 and powerpc), thanx :-).
<HiddenWolf> \sh, see a doctor
<fabbione> \sh: they don't allow to cut heads anymore.. even if empty :)
<Keybuk> \sh: what is your problem?
<\sh> Keybuk: one sourcecode, no diffs, but not the same size of the orig.tar.gz, means our orig.tar.gz of gajim is some bytes smaller then the orig.tar.gz from debian  
<Nafallo> \sh: wanna know why? :-)
<fabbione> score
<Nafallo> we don't have debian/ in the .orig.tar.gz IIRC.
<Kamion> \sh: wouldn't be the first time it's happened
<\sh> Nafallo: in this version 0.8.2 there is no debian dir even in debian
<Nafallo> oh?
<Kamion> you either have to fake a new upstream version, or wait for a new one from upstream to resolve the problem
<Nafallo> hm, right. no debian/.
* Nafallo still wants head in ;-)
<\sh> Kamion: I think this is the best solution...0.9 should hit the world one week before x-mas
<Keybuk> heh, mom gets mightily confused by that
<Keybuk> and it's pretty random which .orig.tar.gz you get, too
<\sh> Nafallo: no there are too many bugs inside the tree
<\sh> Keybuk: yes..but it's somehow very strange
<Nafallo> bugs are here to be solved ;-)
<\sh> -rw-r--r-- 1 shermann shermann 1204727 2005-09-06 19:30 gajim_0.8.2.orig.tar.gz
<\sh>  <- ubuntu version in archive
<\sh> -rw-r--r-- 1 shermann shermann 1216657 2005-09-11 17:47 gajim_0.8.2.orig.tar.gz
<\sh>  <--- in debian and in MoMs merge dir
<Kamion> so whoever uploaded 0.8.2-0ubuntu1 probably did so before 0.8.2-1 was uploaded to Debian, and either we repacked the .tar.gz by mistake, or Debian did, or both
<Kamion> does this surprise you?
<Kamion> (or repacked deliberately, even; sometimes there are reasons for that, e.g. non-DFSG-free content in .tar.gz)
<Nafallo> I actually took the .orig.tar.gz from gajim.org with uuscan :-)
<Keybuk> source tarball is a .bz2
<Keybuk> (upstream)
<Kamion> ah, there we go
<Keybuk> so it's been re-bzipped by both, probably at different times
<\sh> Kamion: I used the orig upstream tarball..and the debian maintainer should use it too...but he is as well source upstream...
<Keybuk> uh, re-gzipped
<Nafallo> \sh: you didn't. I brought in 0.8.2 :-)
<Kamion> \sh: you will have to deal with this problem at frequent intervals for many packages where we have packaged upstream versions before Debian did
<hunger> *LOTS* of dangling symlinks have accumulated on my system since I originally installed hoary:-(
<\sh> for 0.8.1 that was...for 0.8.2 was did that
<Kamion> \sh: you might as well get used to it :)
<Keybuk> hmm
<\sh> Kamion: for sure...but it freaks me out ;)
<Keybuk> the Debian size matches the .tar.gz you can sneak if you dirname the path on the webpage
<\sh> thats the only difference...ours matches 0.8.2.orig and debians is 0.8.2 ,)
<Keybuk> uuuuusually you can just ignore it
<Keybuk> if there's an orig in our archive, you're not uploading another one anyway
<Keybuk> so you just go "la la la, I so didn't notice, honest" and upload the diff.gz
<Kamion> you can't sync until the clash is resolved with a new upstream version though
<\sh> i'll wait now for 0.9 thats it.
<hunger> Does fakeroot on purbose install stuff into /usr/lib64 on a non-64bit machine?
<Kamion> pitti: postgresql-8.0 demoted to universe
<pitti> Kamion: yay
<pitti> Kamion: I just uploaded a new language-support-ku with an aspell-ku dependency
<pitti> Kamion: I reviewed aspell-ku, it's ok
<Kamion> pitti: ok, promoted
<pitti> Kamion: (this will make the Kurdish users a lot more happy :) )
<pitti> thanks
<pitti> hmm, s/more happy/happier/, right?
<Kamion> right
<pitti> Bonjour Monsieur Bacher
<dholbach> pitti: seb taught us a lesson in #ubuntu-desktop: "<seb128> no french guy would say Bon Jour"
<pitti> mvo:    * debian/patches/leave-lo-alone.patch - don't take away the address of the loopback interface (ubuntu #10174)
<pitti> mvo: lol, dhcp really tried to get a new address for loopback?
<pitti> dholbach: so what's the more colloquial way? (and I'm not a french guy :) )
<Nafallo> Bonjour != Bon Jour :-)
<hunger> ARG! Launchpad drives me crazy.
* Nafallo likes Salut better anyway ;-)
<seb128_> dholbach: yeah, that's not 2 words, pitti got it right :)
<pitti> ah :)
<mvo> pitti: yes :) long standing bug
<mvo> pitti: and worse, gnome fails in strange ways without lo
<seb128_> mvo: this bug sucks, my laptop doesn't get an IP on boot with 5.10 because of some bug
<seb128_> so I need to run dhclient
<seb128_> which breaks my GNOME by unsetting the lo IP every time :p
<mvo> seb128_: it should be fixed now (fingers crossed)
<seb128_> nice
<cribeiro> hi. first time here. I'm writing a spec on the launchpad, it's audio related
<ogra> hmm, none of yesterdays liveCDs work 
<cribeiro> so I assume this is the correct channel (to debate specs)
<dholbach> cribeiro: if you wrote it, it might be the best to raise awareness on it on the mailing list - i will surely catch more eyes there, but if you have questions, you can clearly ask them here as well
<cribeiro> dholbach: nice to know. I'm still drafting it. So it needs discussion.
<cribeiro> it started out as a simple spec for a control-panel style app to configure SoundFonts.
<cribeiro> But know I'm thinking about extending the idea further.
<cribeiro> dolbach: can you spare a minute? if it's off topic let me know...
<cribeiro> dholbach: my original intent was to have a tool to configure (add/delete) SoundFonts. But soundfonts come in deb packages.
<cribeiro> the problem is - there is no easy way to tell for sure which packages contain soundfonts.
<cribeiro> or ttf fonts, or LADSPA plugins.
<cribeiro> So my idea, still a bit flurry, is:
<cribeiro> is there any way to mark packages (deb packages, I mean) as containing only a certain type of file... in such a way that a specialized app (a control-panel app) could be used to addd/remove it???
<dholbach> cribeiro: -> query
<\sh> elmo: please sync kdiff3 from unstable, ubuntu changes can be dropped
<Kamion> infinity: would it be possible to bump aptitude up the buildd queue? the buildds seem to be rather slow right now ...
<infinity> Kamion : Yeah, I should also check into why they're slow. :)
* infinity putters off to look.
<infinity> Oh, feh.
* pitti sighs at his bugzilla inbox
<\sh> elmo: please sync grip from unstable, ubuntu changes can be dropped
<Nafallo> infinity: ?
<bmonty_laptop> elmo: please sync fetchyahoo from unstable, ubuntu changes can be dropped
<bmonty_laptop> elmo: please sync filelight, I see you have incorporated the ubuntu changes :)
<pitti> elmo: what is necessary to get current dapper pmount into breezy-backports? I already mailed u-backports@ recently, but no response
<pitti> elmo: tons of users want to mount their floppies, which fails with breezy's version
<seb128> pitti: that's not a candidate for -updates?
<pitti> seb128: hmm, the 0.9.6 changes are pretty big
<pitti> seb128: OTOH it works now for several weeks in dapper
<pitti> Hi BenC
<BenC> hey pitti
<seb128> Keybuk: is hct supposed to work atm?
<seb128> Keybuk: 
<seb128> /usr/bin/hct: Sorry, an unhandled server fault occurred: error
<seb128> get-source: bug-buddy was supposed to be available through HCT but that gave me an error, will try with apt.
<seb128> :/
<\sh> elmo: please sync bzr from unstable, ubuntu canges can be dropped
<robertj> mvo: you around?
<mvo> robertj: yes
<robertj> you want to try to hop onto that vnc session again?
<Kamion> \sh: er, bzr/unstable is behind bzr/dapper
<Kamion>        bzr |      0.6-2 |      unstable | source, all
<Kamion>        bzr | 0.6.2-0ubuntu1 | dapper/universe | source, all
<mvo> robertj: please /msg me the ip :)
<\sh> Kamion: well...nice...
<\sh> Kamion: moment...why is it hmmm...
<\sh> i need really new glasses...
<\sh> ha..mom happyness and \sh blindness
<robertj> mvo: ok it should be in your msg buffer
<\sh> elmo: please forget what I said thx
<\sh> elmo: about bzr
<mvo> robertj: thanks, it is. apparently I can't /msg you because I'm not registered or something :/
* mvo grumbles about freenode
<robertj> mvo: yeah you have to register your nick on this network :(
<jbailey> robertj: You can also turn that feature off on your account
<robertj>  /msg nickserv register foo /msg nickserv identify foo
<sbalneav> Morning all
<\sh> robertj: there is no need to...adjust your settings
* robertj tries to figure out how
<\sh> robertj: actually I never got irc spam...only wall-ops from lilo about "there could be irc spam thats why we nagging the user"
<robertj>  /msg nickserv help unfilterd apparently
<robertj> ok
<robertj> try now
<jane_> Reminder: All Dapper Specs owners please  go into the Spec on LP and in the 'Update Status' section add the Estimated Developer Days for implementing the spec (not taking into account your other workload, just how long that spec on it's own should take to implement). Thanks. https://launchpad.net/distros/ubuntu/dapper/+specstable
<Diziet> `Please only provide an estimate if you are relatively confident in the number.'
<jbailey> jane_: By owner, do you mean "assign" ?
<jane_> jbailey: yes
<seb128> jane_: please stop flooding this chan with your announcements :p
<jane_> seb128: hey that was 2 announcements!
<jane_> ;)
<jane_> seb128: trying to catch all time zones
<jane_> seb128: should I ping you separately?
<seb128> jane_: we have a wonderful -announce list for that now :)
<seb128> jane_: no, I've my specs open atm, will do right now, maybe that will make you stop :-P
<JaneW> seb128: ok I promise to stop
<JaneW> seb128: and I'll use the -announce list if ppl read it and comply
* JaneW would like to not clash with ppl this cycle ;)
<seb128> JaneW: don't worry there is no clash :) I just think a mail to -announce would work and you would no need to put some pressure on the people here by asking every few hours 
<JaneW> seb128: ok, I understand, and you do have a valid point
<JaneW> au revoire
<seb128> JaneW: BTW is there something to do to get a spec listed on https://launchpad.net/distros/ubuntu/dapper/+specstable if it's not atm?
<JaneW> seb128: yes
<neuralis> seb128, target to release: dapper should do it, i think.
<JaneW> seb128: is it on https://wiki.ubuntu.com/DapperGoals?
<JaneW> cos that's the list mdz put together yesterday of what he thinks should be in, and I added those
<seb128> JaneW: nop
<JaneW> if it;s not there, get mdz to ok, and I can add it
<JaneW> which is it?
<JaneW> I'll make a note and ask mdz
<seb128> JaneW: was wondering about rhythmbox-ipod which is medium priority and assigned to me
<JaneW> is it likely to get done?
<seb128> if I've some days to work on it probably
<seb128> upstream is working on it, that's just a matter to coordinate a bit and to work with them
<seb128> I'll probably do it as a personnal goal even if it's not listed anyway
<HiddenWolf> seb128, you just bought an ipod? ;)
<JaneW> ok I added it ;)
<seb128> HiddenWolf: not yet, but it's planned
<seb128> JaneW: thanks! I've updated all my specs, enjoy ;)
<\sh> gentlemen...anyone here who can provide me with a running ppc ssh login with a working dapper pbuilder or dchroot...where I can compile and test some software for dapper? it should have a working kubuntu desktop installed (inside the dchroot) and I need somehow a limited sudo access to install build-deps...  
<JaneW> seb128: aewsome, thanks :)
<JaneW> awesome too
<HiddenWolf> seb128, making gnome faster just got a bit easier for you. new glib and pango releases. ;)
* JaneW is gone... bye
<seb128> HiddenWolf: those are not dapper material
* mvo needs to run, bbl
<HiddenWolf> seb128, too risky even now?
<dholbach> bye mvo
<seb128> HiddenWolf: no, but 2.9/2.10 is planned for after dapper
<seb128> they don't have 6 months cycle as GNOME
<ogra> seb128, but [WWW]  https://launchpad.net/distros/ubuntu/+spec/faster-gnome-startup is on the goals page...
<neuralis> \
<Kamion> sigh, live CD is busticated
<seb128> ogra: and it has nothing to do with a new glib or gtk?
<ogra> Kamion, yes, all arches
<HiddenWolf> "I know that we are a bit late (with 2.13.2 already behind us), but I
<HiddenWolf> have done a GLib 2.9.0 release today [1] , and Behdad will follow with a 
<HiddenWolf> Pango 1.11.0 release as soon as possible."
<ogra> seb128, but if it speeds you up ...
<seb128> it doesn't speed anything afaik
<ogra> ah, k
<Kamion> ogra: I don't see any bug reports from you about it?
<ogra> Kamion, oh, sorry
* Kamion is getting tired of (re-)discovering all the issues for himself
<ogra> does anybody know in which package i find the dl module for python
<\sh> dl-modul? dynamic loader? 
<ogra> yes, for dlopen etc
<neuralis> ogra, comes bundled with python
<ogra> >>> import dl
<ogra> Traceback (most recent call last):
<ogra>   File "<stdin>", line 1, in ?
<ogra> ImportError: No module named dl
<ogra> was it renamed ? 
<neuralis> python2.4: /usr/lib/python2.4/lib-dynload/dl.so
<ogra> hmm
<seb128> WFM
<ogra> hmm, works on breezy ... but not on dapper amd64
<Kamion> ogra: perhaps you only have python-minimal installed
<ogra> i doubt that ...
<Kamion> hmm, indeed dl.so isn't in python2.4_2.4.2-1_amd64.deb
<\sh> ogra: u read the doc about dl?
<ogra> \sh, nope
<ogra> something amd64 specific ? 
<\sh> http://www.python.org/doc/2.4.2/lib/module-dl.html
<\sh> last sentence "This example was tried on a Debian GNU/Linux system, and is a good example of the fact that using this module is usually a bad alternative."
<ogra> \sh, yes, that one i've seen
<ogra> \sh, its not my program that uses it 
<\sh> ogra: hmmm...
<\sh> PLEASE ! someone has to fix evolution..this is now the 50th time today it freezes because of nothing
<seb128> Kamion: should we be upload frozen for flight1-cd? I only do menu item changes atm but I don't know if/when you need to get the archive in sync on all the archs?
<jsgotangco> good night =)
<seb128> \sh: do you do quick actions? debug backtraces of the lock are welcome
<\sh> seb128: it's the same backtrace I provided to upstream...it never changed.
<zyga_> my dear python loving friends, I've installed libapache-mod-python2.4 and I cannot really get past the hello-world test, is this a bug or should I keep googling
<seb128> \sh: bug number?
<Kamion> seb128: uploads of source packages with both arch: all and arch: any binaries are potentially painful, because out-of-sync binaries can then cause uninstallability
<Kamion> seb128: I don't want to slow people down too much by freezing the archive entirely, though
<ogra> doko, ping 
<\sh> seb128: 317790
<seb128> Kamion: no, those are apps, arch any ... but that can create revision diff between arch time to get everything built, dunno if the CDs have to ship the same revisions
<doko> ogra: speak up ;)
<ogra> doko, any idea why dl is not in python2.4 for amd64 ? 
<Kamion> seb128: I'm not really bothered about that for an alpha release
<Kamion> ogra: the URL \sh pointed to says:
<Kamion> Note: This module will not work unless sizeof(int) == sizeof(long) == sizeof(char *) If this is not the case, SystemError will be raised on import.
<ogra> oh
<ogra> k
<ogra> blind me, doko: unping then ...
<seb128> Kamion: k, thanks
<pitti> seb128: hm, any idea where teuf usually hangs out?
<pitti> seb128: I can't find him on Freenode or gimpnet
<seb128> pitti: he's on GIMPNet usually, he disconnected ~40 min ago
<seb128> pitti: for what do you need him? 
<pitti> seb128: he can reproduce the 'cannot eject bug #5049, and offered me to debug this together
<seb128> ah, cool
<seb128> I'll let you know when he's online
<seb128> he's on #nautilus, #rhythmbox usually
<pitti> seb128: I also mailed him, but thanks
<seb128> k
* pitti discovers that only one package holds libmysqlclient10 in main and goes to fix that
<HiddenWolf> pitti, spring cleaning. ;)
<pitti> ReducingDuplicates spec :)
<pitti> having three different client libraries and two mysql versions in main hurts
<ogra> HiddenWolf, its autumn here
<HiddenWolf> ogra, duh! ;)
<ogra> heh
<HiddenWolf> pitti, yeah. why is that anyway?
<pitti> well, it happens
<seb128> pitti: what is this package?
<pitti> seb128: libsasl2-modules-sql
<pitti> cyrus-sasl2 source
<seb128> oh, k
<seb128> pfiou, not a GNOME stuff :)
<Riddell> Kamion: a few questions: what's the status of flying-1, what's the status of kubuntu daily CDs and should we have a kubuntu flying-1?
<mdz> Kamion: what's busted on the live CD?
<pitti> Hi mdz
<ogra> mdz casper it seems
<mdz> ogra: ...
<mdz> ogra: did you try it?  what did you see?  any error messages?
<ogra> something about cramfs wrong magic ...
<ogra> and it tries to install coreutils 
<seb128> hi mdz
<mdz> Riddell: kubuntu daily install CD build failed with some permission errors, likewise for daily-live
<ogra> i have to boot one again to get a precise msg... give me a moment
<mdz> hi all
<mdz> I would find it extremely unusual for casper to try to install coreutils
<mdz> to say the least
<mdz> cramfs wrong magic is a perfectly normal message from the kernel
<ogra> its one of the mssages i saw
<Riddell> mdz: who to poke to fix that?
<mdz> Riddell: it might just need to be re-run
<mdz> ask Kamion when he returns
<lamont-away> libgd2 build-deps gnulib.  main vs universe.  sigh
<pitti> seb128: sorry, I forgot again how to deep-debug package uninstallability; could you give me a hint about that? AFAIK you know that
<pitti> seb128: I cannot install libmysqlclient14-dev libdb4.2-dev heimdal-dev at the same time
<seb128> pitti: sudo apt-get install -o Debug::pkgProblemResolver=true heimdal-dev kerberos4kth-dev libmysqlclient14-dev ?
<Kamion> mdz: kbd-chooser; it's fixed
<pitti> seb128: ah, that's what I was looking for, thanks
<Kamion> mdz: a block of old code removed from the end of a shell script that didn't have 'exit 0' at the end, so it exited with the return code of whatever happened to be executed last, which in this case was '[ -n "" ]  && ...'
<pitti> seb128: ah, got it - heimdal-dev wants libdb4.1-dev, which conflicts with libdb4.2-dev
<pitti> yay for a billion libdb versions
<Kamion> Riddell: I asked you to fix koffice, and you said you'd do it when the C++ allocator transition was happening
<seb128> pitti: drop 4.1 :)
<Kamion> Riddell: koffice is part of kubuntu-desktop, therefore it is not currently possible to build working Kubuntu images
<Kamion> I tried
<pitti> seb128: we want to drop everything but 4.3 anyway, but I don't know how much that breaks (in terms of database compatibility)
<seb128> I hate libdb
<Kamion> mdz: I'm currently doing a d-i rebuild to pick up the new kbd-chooser
<seb128> pitti: don't break my e-d-s :)
<Riddell> Kamion: worth me fixing that now?  and any others to be fixed?
<ogra> mdz, its console-tools, not coreutils, and indeed apt-install tries to install it ... the final error comes from main-menu:
<pitti> seb128: it won't work with 4.3?
<Kamion> Riddell: it's always worth fixing uninstallables. the list is in the usual place, http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html
<mdz> ogra: see above; Kamion has fixed it
<seb128> pitti: I've not tried, it uses 4.1 upstream, Debian uses 4.2
<seb128> pitti: I just fear to make us incompatible with the rest of the world by using different versions
<ogra> mdz, ah, k ... was in the other room
<Kamion> Riddell: koffice is the only Kubuntu-relevant problem I know of
<mdz> Kamion: what are the errors in the log about?
<mdz> diff: /srv/cdimage.no-name-yet.com/scratch/kubuntu/tasks-previous/daily-live/dapper/boot: No such file or directory
<mdz> etc.
<pryzbyj> can i tell an ubuntu user to add a debian ftp server to /e/a/sources.list ?
<neuralis> pryzbyj, generally, no.
<pitti> seb128: ok, so the database format is the same in 4.{1,2,3}, just the log format changed
<pryzbyj> why?
<yoni> Hello, I know this probably isn't the place to ask - but i'm having a really weird problem. gnome won't come up, because libpng is screwed up. i've reinstalled from repositories and the same error continues. any ideas why?
<pryzbyj> and, what does it take for them to install my package saods9
<seb128> yoni: try #ubuntu-desktop
<neuralis> yoni, yes, this isn't the place to ask. try #ubuntu-desktop or file a bug or post to the ubuntu-users list.
<pryzbyj> maybe apt-get -b source ?
<pitti> seb128: i. e. as long as an app does not use transactions, the libdb versions are compatible
<seb128> pryzbyj: because Ubuntu and Debian may have different package with the same versions by example which will confuse apt
<Nafallo> pryzbyj: saods9 |    3.0.3-1 | http://localhost dapper/universe Sources
<pryzbyj> i see; if they pin everything down, will that be sufficient to prevent breakage?
<seb128> pitti: cool. Seems that's fine for e-d-s since Debian guy didn't have any issue to switch from 4.1 to 4.2
<pryzbyj> i just searched packages.ubuntu.com ..
<neuralis> pryzbyj, dapper is the next release that's being worked on
<Nafallo> pryzbyj: http://people.ubuntu.com/~lamont/buildLogs/s/saods9/3.0.3-1/
<pryzbyj> oh ok
<Kamion> mdz: oh, right. the one you cite is harmless (it just means there's no previous build), but the real error is due to a non-group-writable directory, which I've just fixed. I hate how baz is so picky about the group-writable bit
<neuralis> pryzbyj, you can try having the user download the .deb and install it by hand. if it works, great, if not, it gets more complicated.
<pryzbyj> what, with dpkg?
<neuralis> yes.
<pryzbyj> you mean the debian .deb then, not ubuntu?
<neuralis> yes.
<pryzbyj> ok supposedly that failed, but i'm not confident that we're communicating well .. seems to be a language prob
<Nafallo> pryzbyj: if you look at the URL I sent you, you will see that your package fails to build from scratch. you might want to fix that? :-)
<pryzbyj> yea, i see
<neuralis> pryzbyj, you can check the versions of your package's dependencies in ubuntu vs. those in debian, which should tell you if it's possible for the ubuntu user to install your debian .deb with dpkg.
<Nafallo> the best path would be to fix that in debian, and then the package gets auto-imported.
<pryzbyj> yea
<mae> mm
<mdz> Kamion: er, yeah, pasted the wrong line. I meant the EACCES at the end
<pryzbyj> well another upload is already on its way
<mae> auto imported on next cycle
<mae> not in current stable release
<mae> :)
<Nafallo> pryzbyj: kewl :-)
<pryzbyj> what is: powerpc-given-back.gz
<Kamion> mdz: could you (non-urgently) merge colin.watson@canonical.com--2005/casper--fixes--0? various small fixes to bugs I noticed while fixing the real problem
<pryzbyj> ...powerpc-given-back.gz in the build failures
<Kamion> pryzbyj: it means "ignore this if you aren't a buildd admin"
<pitti> Mithrandir: ping
<pryzbyj> renamed to such after a buildd problem is discovered?
<Kamion> no, generally speaking it means that the build was unlucky enough to run while apt-ftparchive was running on ftp-master, and therefore got confused
<pryzbyj> ic
<mdz> Kamion: eeek, conflicts abound
<Kamion> mdz: it was against the breezy branch, because to start with I thought it might be urgent; want me to update it to main?
<mdz> Kamion: ah, that'd be better, yes
<mdz> all the .po files conflict
<Kamion> perhaps you should merge the breezy branch into main first ...
<Kamion> that would probably sort it out
<Kamion> I did a debconf-updatepo in the breezy branch which you merged there, but not in main
<Kamion> and some translation updates
<mdz> heh, yes. that gives me the conflicts to sort out again ;-)
<Kamion> they're probably just in the po file headers
<mdz> yeah
<Diziet> Aha!  They have my bigger buffer cache now.  I shall go and fetch it.
* Kamion pushes a cron.daily through so that he can start building CDs
<mdz> ogra: why package ltspfs and ltspfsd separately?
<ogra> mdz, becaus upstream does that ?
<ogra> they are two separate sources, i can ask scott if he might merge them 
<neuralis> ogra: i don't think it's a logical grouping, if i'm remebering correctly. fsd is what runs on each thin client, fs is what runs on the server to access the fsds, isn't it?
<ogra> neuralis, we only talk about the source package
<neuralis> ogra, ah. nevermind.
<ogra> its less maintenance work to have one source that spits out two binarys
<ogra> but i dont want to merge the sources on every upgrade, so upstream must/should do that
<mdz> Kamion: merged.  I think I'm going to move it over to bzr now
<Kamion> mdz: righto
<ogra> do we need to keep the "--" naming schemes for bzr archives ? 
<Kamion> ogra: no
<ogra> yay
<Kamion> c.f. the seeds for example
<ogra> i thought there was a policy ...
<Kamion> bzr is more free-form about it than baz is
<ogra> yup
<mdz> Kamion: http://people.ubuntu.com/~mdz/bazaar/casper/
<mdz> I have no idea what happens to the branch relationships during a conversion like this
<mdz> hopefully it magically DTRT
<Kamion> mdz: I had to deal with this for the seeds; after all the branches have converted, you need to use 'bzr fetch-ghosts' on the other branches to import their history, and you very likely want to use Kinnison's re-weave-inventory on it too (which I think has been integrated into bzrtools now)
<ajmitch> morning
<mdz> Kamion: so I chdir to mainline and fetch-ghosts breezy, e.g.?
<Kamion> mdz: right; possibly the other way round too if you've merged the other way at any point
<Kamion> oh, breezy was a branch from mainline, so definitely the other way round too
<mdz> Kamion: hmm, it succeeded but didn't seem to do anything
<mdz> did it both ways
<Kamion> 'bzr log' to see whether it shows merges
<mdz> a later rsync showed no files changed
<mdz> it shows merges, but apparently they were already there
<Kamion> maybe the import found them; it won't have found merges from my branches
<Kamion> the current bzrtools daily automatically re-weaves on fetch-ghosts; good, that saves trouble
<mdz> Kamion: it probably was able to find them because both branches were in the same archive
<HiddenWolf> hah, I just found a nice old ubuntu review in a national newspaper.
<Kamion> yeah, if you imported the whole archive at once rather than one branch at a time
<mdz> Kamion: I did it a branch at a time
<Kamion> but no, bzr log in mainline looks wrong
<HiddenWolf> It lists the lack of windows software as a pro. "You can browse without any worries, there are no frogs that'll jump on your desktop to promote ringtoes, or other anoying software"
<Kamion> it should have indented sections with the logs from breezy on each merge from breezy
<HiddenWolf> ringtones. :/
<mdz> ok, that is consistent with fetch-ghosts not changing the branch
<Kamion> hm, this import is buggy AFAICS
<mdz> ii  bzr            0.6.2-0ubuntu1 bazaar-ng, the next-generation distributed v
<mdz> ii  bzrtools       0.7+20051103-0 Collection of tools for bzr
<Kamion> the revisions indicating a merge should have multiple parents (look in 'bzr log --show-ids')
<Kamion> compare with e.g. any kubuntu seeds branch
<mdz> do I need different versions?
<ajmitch> probably the latest daily of bzr?
<mdz> my bzr seems to be the same as dapper; bzrtools is newer from jbailey's archive
<Kamion> I don't know; would be worth asking #bzr
<mdz> Kamion: what did you use for converting the seeds?
<Kamion> mdz: an installation on chinstrap
<Kamion> which is one of lifeless' "you must use EXACTLY these versions" specials
<mdz> gah
<Kamion> it could be that bzr and bzrtools just have to be a bit more in sync - as I say, check with #bzr, I'm just guessing at this point
<mdz> yep
<pryzbyj> so, saods9 fails with "mktclapp: can't open "/usr/lib/tcl8.4/http2.5/http.tcl" for reading", presumably on all archs.  but that file is in package tcl8.4, which is a build dep?!
<pryzbyj> http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=%2Fusr%2Flib%2Ftcl8.4%2Fhttp2.5%2Fhttp.tcl&searchmode=searchfiles&case=insensitive&version=breezy&arch=i386
<Kamion> pryzbyj: the failure I see in the latest i386 build is quite different
<Kamion> g++ -O2 -fPIC -I/usr/include/tcl8.4 -DHAVE_SYS_UN_H -DHAVE_SYS_SHM_H -D_LARGEFIL
<Kamion> E64_SOURCE -D_FILE_OFFSET_BITS=64  -I. -I../vector -I../../include -I/usr/X11R6/
<Kamion> include/X11   -c -o widget.o widget.C
<Kamion> ../vector/vector.h:50: error: expected ',' or '...' before '&' token
<Kamion> ../vector/vector.h:50: error: ISO C++ forbids declaration of 'Matrix' with no ty
<Kamion> pe
<pryzbyj> ok that one is fixed
<Kamion> ../vector/vector.h:61: error: expected ',' or '...' before '&' token
<Kamion> ../vector/vector.h:61: error: ISO C++ forbids declaration of 'Matrix' with no ty
<Kamion> pe
<Kamion> ../vector/vector.h:70: error: 'BBox' does not name a type
<Kamion> (excuse the paste)
<pryzbyj> ok that one is fixed; is the other failure an early tcl problem, then?
<Kamion> in general you should only bother with the latest (non-trivial) logs in http://people.ubuntu.com/~lamont/buildLogs/s/saods9/3.0.3-1/
<pryzbyj> ok
<jbailey> mdz: Eh?  How did you wind up with a mismatch?
<mdz> jbailey: see #bzr
<mdz> Kamion: the new branches in the same place look more reasonable
<Riddell> Keybuk: do you know if there are plans for more advanced init scripts in ubuntu, e.g. including a status function?
<Kamion> mdz: what was the problem?
<Kamion> mdz: bzr: ERROR: urllib2.HTTPError: HTTP Error 403: Forbidden
<Keybuk> Riddell: dapper+1
<mdz> Kamion: fixed
<mdz> Kamion: just a "these are not the versions you're looking for"
<Kamion> mdz: oh, so current daily of everything worked?
<mdz> Kamion: no, current daily of everything fails unspectacularly on fetch-ghosts
<mdz> apparently things are complicated
<Kamion> what versions should I be using if I want to do imports, then?
<mdz> I was not able to learn the answer to that question
<Keybuk> whatever is in lifeless' home directory, of course
<Keybuk> that's always the right answer
<Keybuk> to any question
<Keybuk> apparently
<Keybuk> oops, M-x cynical-mode
<Kamion> mdz: what did *you* use? :)
<Kamion> mdz: looks like you still need to fetch-ghosts
<seb128> Keybuk: 
<seb128> $ get-source pmount
<seb128> /usr/bin/hct: Sorry, an unhandled server fault occurred: error
<seb128> Keybuk: is that a known issue?
<pitti_> Keybuk: oi, with your reference package? :)
<seb128> pitti_: seems it does that with every package for me
<mdz> Kamion: revno 29 has all sorts of nice indented merges
<Kamion> mdz: did you push?
<mdz> Kamion: I think in the end I used bzr.integration from chinstrap for both import and fetch-ghosts
<Keybuk> seb128: no, not known
<Keybuk> I'll look into it
<seb128> Keybuk: thanks
<mdz> Kamion: have pushed again for good measure
<Kamion> mdz: no shiny indentation love here
<mdz> Kamion: bzr log -r 29 has no love?
<Kamion> mdz: bzr.integration on chinstrap will probably require the reweave rubbish, FYI - use 'bzr fix' from bzrtools daily
<Kamion> mdz: main or breezy?
<mdz> Kamion: main
<mdz> that's the breezy->main merge I did today
<Kamion> mdz: fresh get with no HTTP proxy, no love
<Keybuk> pitti_: ?
<pitti_> Keybuk: !
<pitti_> what's up?
<pitti_> hrm, an underscore again? *grumpf*
<Keybuk> pitti_: so, what's the expected breakage with 2.6.15 ... I've not been expecting (or experiencing) any?
<pitti> Keybuk: the whole gnome desktop just does not react to hotplug events any more
<pitti> Keybuk: I did not yet wasted thoughts about this
<Keybuk> that's odd, sounds much more like a hal bug
<Keybuk> assuming hal has a udev rule? :)
<Keybuk> or is it simply that hal isn't being run
* Keybuk can't find the old /etc/hotplug.d/default/hal.hotplug thing
<Keybuk> but I do have a (very crackful) /etc/udev/rules.d/*hal*
<pitti> Keybuk: hm, thinking about it, hal and pmount actually work
<Keybuk> so is probably just a gnome-vfs bug then
<seb128> Mithrandir: the hplip menu item is still around with your change
<Keybuk> *giggles*
<pitti> Keybuk: i. e. devices are mounted, but gnome does not react to it
<seb128> iz gtk bog?
<Keybuk> definite gtk bog
<Keybuk> though that hal.rules file is classic
<Keybuk> ENV{SEQNUM}=="[0-9] *" ?! ... of course the event has a sequence number
<pitti> Keybuk: I don't now, and until the basic kernel/udev/hotplug stuff is sorted out, we should just leave it alone IMHO
<Keybuk> ENV{UDEVD_EVENT}=="1" ?! ... what other kind where you expecting
<Keybuk> though the classic is:
<Keybuk> ACTION="remove"
<Keybuk> I suspect they _really_ wanted ACTION=="remove"
<Keybuk> anyhoo, yes, we probably shouldn't debug it too hard until new udev and kernel are ready
<pitti> yep
<pitti> that guy uses dapper, he should share the pain :)
<Keybuk> in particular, that should be something far more like RUN+="socket:/org/freedesktop/hal"
<Keybuk> instead of forking things
<Kamion> new install/live CDs up, may stand a better chance of working now
<Kamion> please test and report problems to me
<ogra> sigh ... 48 minutes for a seed push
<Kamion> ogra: how are you pushing?
<Kamion> and what version of bzr?
<ogra> i tried a simple bzr push first ... but that timed out eery time, now i'm using it with sftp url 
<ogra> which at least doesnt time out
<ogra> the current one from jbauleys archive
<ogra> jbaileys
<seb128> jbailey: did you figure what is wrong with freecell?
<jbailey> seb128: I haven't.  I've noticed that it's the only gnome-game that seems to use threading though. =)
<jbailey> And I've also learned that threading in Scheme kinda scares me.
<elmo> bmonty_laptop: filelight won't sync; different orig.tar.gz's
<xhaker> jbailey, gnometris doesnt load here
<siretart> elmo: without wanting to annoy you, but is there any problem with my key?
<xhaker> jbailey, (gnometris:19549): Gtk-WARNING **: This process is currently running setuid or setgid.
<jbailey> xhaker: What's the bug number?
<xhaker> sorry for the bug report here
<xhaker> don't think i opened one
<jbailey> xhaker: It's all good. =)
<elmo> crimsun: same problem with wpasupplicant; different orig.tar.gz's
<seb128> jbailey: https://launchpad.net/distros/ubuntu/+source/gnome-games/+bug/4537 .. weird
<jbailey> xhaker: If you could please, I see the same behaviour, and I can confirm it for you.
<elmo> siretart: I'm getting to it, sorry I'm still backlogged from trying to catch up after ubz
<jbailey> xhaker: But this appears to be a SUID problem rather than a threading-in-scheme problem.
<bmonty_laptop> elmo: ok, i'll do a merge debdiff then, thanks
<xhaker> jbailey, just figured it was the same package you were working on
<siretart> elmo: okay. I was just a bit confused, no problem
<seb128> jbailey, xhaker: we have a bug about this. That's GTK which doesn't like the setgid games (which is used to write scores)
<jbailey> xhaker: For me, the problem is in Freecell, which is part of Aisleriot.
<seb128> different issue
<xhaker> seb128, is the bug already reported?
<xhaker> the setgid one?
<mdz> jbailey: any reason bzr-integration doesn't provide bzr?
<seb128> xhaker: it is
<seb128> xhaker: http://bugzilla.ubuntu.com/show_bug.cgi?id=19668
<jbailey> mdz: Nope.  Lemme double check with lifeless to make sure he has no objections to that.
<xhaker> seb128, thanks
<jbailey> lifeless: (Whenever you wake up, dear)
<seb128> xhaker: np
<jbailey> seb128: Found the problem with sol.  Lemme fix. =)
<seb128> jbailey: cool. What is it?
<jbailey> seb128: Guile not compiled with thread support on ppc, but is on i386.
<seb128> ah, NOTGNOME, cool :)
<seb128> jbailey: do you have a 5.10 ppc?
<seb128> https://launchpad.net/distros/ubuntu/+source/gnome-applets/+bug/4602 mention the same kind of issue and the guy is not using dapper
<seb128> ups
<seb128> https://launchpad.net/distros/ubuntu/+source/gnome-games/+bug/4537
<jbailey> seb128: My ppc box is running dapper atm, I could do a chroot if I needed to, or dust off the other ppc box.
<seb128> don't bother
<seb128> I guess I can get the information from the build log
<Amaranth> yay, alacarte is in :)
<seb128> thanks to you !
<jbailey> seb128: Oh ugh.
<jbailey> seb128: So to run freecell I have to implement quickthreads on ppc?
<jbailey> You clearly hate me. =)
<Amaranth> btw, has anyone used the "browser appliance" with vmware player?
<Amaranth> seb128: so is the rest of the stuff to go with it (gnome-panel patch, i think) waiting on flight 1
<lamont-away> sigh.  libgtk-java needs -ffunction-sections on hppa.  grumble
<mdz> Kamion: have you already done a new livecd build with the new d-i?
<ifvoid> hey!
<ifvoid> is anything wrong with nl.archive.ubuntu.com?  apt-get complains about an invalid signature
<Riddell> Kamion: new koffice is in the archive new
<Nafallo> ifvoid: you should probably ask the admin, not us :-). this channel is for the development of Ubuntu.
<ifvoid> but the key didn;t change recnetly or so?
<Amaranth> no
<Amaranth> ifvoid: usually you get key errors when the mirror is updating, try again in 10 minutes
<ifvoid> ok thanks
<Diziet> Excellent.  New server disk works; just need to pvmove everything now which I can do with everyhing working.  And my workstation has 3x the RAM.
<zyga> uh
<zyga> guys do you think it's fine for gam_server to eat 56% of ram+swap?
<zyga> It's still running if anyone wants to have a look
<zyga> it currently eats 489MB of real memory
<dholbach> have a nice evening
<xhaker> you too dholbach 
<seb128> zyga: https://bugzilla.ubuntu.com/show_bug.cgi?id=13449
<zyga> seb128: thanks alot
<seb128> np
<zyga> seb128: is it possible to attach valgrind to a running process? 
<zyga> (I never tried anything like that)
<zyga> so far I SIGSTOPped that memory hog
<seb128> not sure, you can try
<zyga> checking
<zyga> seb128: do you think this could be caused by the same mechanism that was present in the malloc example I showed you before?
<seb128> maybe
<Amaranth> wow the only thing in my system tools is system monitor, good job
<Amaranth> oh, everything else is just hidden
<Kamion> mdz: yes
<Riddell> Kamion: so what's the status of ubuntu flying and should we try for a kubuntu flying?
<Kamion> Riddell: ok, thanks, kubuntu daily running now
<Kamion> Riddell: (a) flight not flying :-) (b) Ubuntu install/live are ready for testing but tests incomplete (c) if you can coordinate the required testing, sure
<Amaranth> is there a breezy mini iso?
<Kamion> Amaranth: archive.ubuntu.com/ubuntu/dists/breezy/main/installer-*/images/current/...
<Amaranth> err, those aren't isos
<Kamion> http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/images/netboot/mini.iso certainly is
<Amaranth> oh, netboot
<Kamion> mdz: do you mind *terribly* much if the live CD boot text for Flight 1 is wrong (i.e. looking like the install CD) as long as it's fixed afterwards?
<Kamion> I've fixed it but it'll take a d-i upload
<Diablo-D3> Hey guys.
<Diablo-D3> Why does universe contain helix-player?
<Diablo-D3> or rather, why does it include the completely useless stripped down helix-player?
<crimsun> it's not useless, and this is a MOTU question
* Diablo-D3 asks again in #ubuntu-motu
<mdz> Kamion: I don't mind at all
* netjoined: irc.freenode.net -> brown.freenode.net
<Kamion> i386/live pass
<Kamion> Kubuntu live filesystem building
<Kamion> Riddell: Kubuntu daily 20051118.2 should be good for you to test
<HWolf> Diablo-D3, stripped of non-free codecs.
<Diablo-D3> HWolf: yes, we had this discussion
<Riddell> Kamion: great, thanks
<Diablo-D3> HWolf: in #ubuntu-motu I mean
<Diablo-D3> HWolf: its just that why is helix-player even packaged when its totally useless, and redundant
<Amaranth> HWolf: it's not stripped, afaik, it just doesn't come with any codecs
<Diablo-D3> when I said stripped, I meant from upstream
<Diablo-D3> helix contains nothing useful.
<Diablo-D3> to make it useful, you need to use realplayer instead
<Amaranth> Diablo-D3: It's not getting removed, end of discussion.
<HWolf> helix upstream doesn't have real support either, afaik.
<Diablo-D3> HWolf: *I just said that*
<Amaranth> nope
<Amaranth> helix + real codecs = realplayer 10
<Diablo-D3> Amaranth: this is what was wrong with debian imo
<Diablo-D3> too much useless shit packaged
<Amaranth> Diablo-D3: Almost of the packages come directly from debian. And this channel has many debian maintainers in it...
<Amaranth> err, almost all
<Diablo-D3> aaand just because debian packages it doesnt mean we should inherit it.
<Amaranth> It's automatic.
<Diablo-D3> maybe it shouldnt be?
<Amaranth> Diablo-D3: Go through every single package in main, restricted, universe, and multiverse and for every package you think shouldn't be there write a paragraph detailing why.
<Amaranth> Diablo-D3: If you think that will take too long you know why it's automatic.
<Diablo-D3> I cant do it for all
<Amaranth> Someone would have to.
<Diablo-D3> simply on the fact that I dont use all
<Kamion> one useful approach might be to package the extra codecs for multiverse
<Amaranth> You can't do it all, that's the answer for why it's automatic.
<Diablo-D3> Kamion: doesnt work that way afaik
<Kamion> Diablo-D3: then fix that :)
<Diablo-D3> Kamion: helix just cant use rp codecs
<Amaranth> Kamion: The only codecs I know of are the real ones and you can't make them work in helix.
<Diablo-D3> Kamion: cant, its rigged upstream for it not towork
<Diablo-D3> however, other players can use realplayer codecs 
<Diablo-D3> such as mplayer
<Kamion> seems like it'd still be useful for freely-encoded content ...
<Amaranth> mplayer uses the win32 realplayer codecs
<Amaranth> which are illegal to distribute, have, etc
<thierry> seb128 : you told me to not force the icon extension (for absolute icon path bug) but check this one https://launchpad.net/distros/ubuntu/+source/lbreakout2/+bug/3242
<xhaker> Kamion, any changes in d-i from daily 14 to daily 18?
<thierry> seb128: it got fixed and it forces the extension
<Kamion> "proprietary software does more" isn't a reason to remove free software, even if it's not as capable yet. If we followed that argument to its logical conclusion there would be no Ubuntu at all.
<Kamion> xhaker: daily d-i builds incorporate newer versions of various udebs
<Diablo-D3> Kamion: both kde and gnome's default video player can play everything helix does
<Kamion> they're mostly automatic
<Diablo-D3> Kamion: and does it in a saner way
<Kamion> xhaker: see individual changelogs (or dapper-changes) for details
<Amaranth> Diablo-D3: gedit and kate and vim and emacs all do the same thing
<Amaranth> Diablo-D3: Which one should we keep?
<seb128> thierry: it doesn't mean it's optimal
<Diablo-D3> vim of course.
<Diablo-D3> ;)
<thierry> seb128 : I know but should someone reopen it for that?
<Diablo-D3> Amaranth: actually, $gnome_default, $kde_default, and vim.
<xhaker> Kamion, daily 14 seemed to "forget" to depmod -a at the first boot
<Diablo-D3> (yes, I hate emacs)
<Amaranth> Diablo-D3: Exactly, this is your opinion.
<Amaranth> Diablo-D3: Someone might like helix as it is.
<Amaranth> crimsun said he uses it
<thierry> seb128 : like changing the last patch and resending it? (thing I could do) But I can't reopen it...
<Diablo-D3> Amaranth: I was kidding, btw
<Kamion> xhaker: hardware detection in dapper d-i before 20051114/15 or so was basically broken
<Diablo-D3> Amaranth: all four are package worthy
<Kamion> debian-installer (20051026ubuntu2) dapper; urgency=low
<Kamion>   * build/pkg-lists/base: Switch back to module-init-tools-udeb for now;
<Kamion>     busybox modprobe doesn't support all the options we need and doesn't
<Kamion>     seem to have good enough alias and blacklist support.
<Kamion>  -- Colin Watson <cjwatson@ubuntu.com>  Tue, 15 Nov 2005 13:01:24 +0000
<Kamion> xhaker: ^--
<seb128> thierry: ask to bmonty_laptop on IRC
<Amaranth> btw, is it bad that the 2.6.15 kernels in dapper can't seem to use scsi drives?
<thierry> bmonty_laptop : could we reopen malone bug 3242 ?
<xhaker> Kamion, do you think i should get flight1 then? i've installed daily 14.. i don't think it would change much besides depmoding?
<seb128> Mortas_: around?
<slomo> elmo: ping?
<HWolf> Amaranth, it'd think so.
<Mortas_> seb128: yep
<mdz> xhaker: by 'first boot', do you mean from the CD or the hard disk?
<seb128> Mortas: I've comment on your UniverseDesktopFileAbsolutePath, this page is an error (no offense)
<xhaker> mdz, the first boot from the harddisk before installing the rest of the packages..
<Mortas> I'm not easily offended, so don't worry
<seb128> Mortas: that should be UniverseDesktopFile, no reason to limit the fix a one single point where you can as well run the validator and make everything conform
<xhaker> it complained right at the begining that it couldn't load vesafb module.. i use vga=792
<mdz> xhaker: in that case, that's normal
<mdz> depmod doesn't run at boot anymore in dapper
<xhaker> mdz,i think it's just modules.dep that inst generated
<xhaker> yes
<xhaker> that
<mdz> xhaker: in the initramfs or in userland?
<seb128> making the patch, filing the bug, uploading the fix, sending upstream is the work. So as well changing the other point when you do this
<Mortas> seb128: good point, at the time I only ran into that one issue but making it a page for multiple issues is always good ofcourse
<mdz> in either case, it's generated long before boot time
<mdz> xhaker: if you saw an error message, we need to see an exact copy of it
<seb128> Mortas: other point, your example force the extension which seems to be wrong
<seb128> Mortas: a theme variant can have .jpg or .png or .svg
<seb128> filename speaking
<seb128> should be "filename"
<seb128> no "filename.jpg"
<xhaker> mdz, something along the lines of "Couldn't locate module (/usr/lib......./vesafb.ko)"
<xhaker> mdz, it's the first thing that showed up after grub
<ogra_live> mdz, i386/live is fine ...
<mdz> ogra_live: cheers
<Amaranth> that reminds me, i need to figure out how to make pyxdg only use an xpm if it can't find an svg
<Mortas> seb128: I've changed the example
<ogra_live> next ppc ...
<seb128> Mortas: thanks
<thierry> seb128, Mortas : I'm the one that did about every patch that here linked on that page, and seb128 told me all that so all the patch listed are ok (well I think)
<thierry> Martas_
<ogra> mdz, ppc live doesnt boot... i try a new media ..
<bmonty_laptop> thierry: you can reopen #3242 if you want, please make sure you put a reason why
<minghua> hi bmonty_laptop, got your message
<bmonty_laptop> hey minghua 
<minghua> bmonty_laptop: the new debdiff looks good, just one nitpicking: you probably want to keep the old ubuntu changelogs
<minghua> bmonty_laptop: so people have the context for the ubuntu specific chagnes
<bmonty_laptop> minghua: good point
<bmonty_laptop> I'll change that, plus I'm not sure if it is necessary, but I'm interested in some other folks looking at the rationale to not bring in the libfam0c102 name
<thierry> bmonty_laptop : I don't have the right to reopen the bug, and my reason is that the applied patch forces the extension, it shouldn't
<bmonty_laptop> thierry: the debdiff removes the absolute path
<thierry> bmonty_laptop : yes but it force the extension look at https://wiki.ubuntu.com/UniverseDesktopFileAbsolutePath
<thierry> bmonty_laptop : it shouldn't have a .png or .xpm
<bmonty_laptop> thierry: ah, ok...I see.
<bmonty_laptop> I think we should open a new bug for that, the absolute path issue is fixed
<thierry> mmm ok then going to do it
<bmonty_laptop> thanks for showing me that
<thierry> np
<thierry> bmonty_laptop : ok but the patch is not applied on the breezy source... so where do I get the source to make the change? and how?
<thierry> bmonty_laptop : it would be far more simpler to just take the last patch, take off the extension, and resend it
<bmonty_laptop> thierry: the patch won't be applied against breezy, only dapper
<bmonty_laptop> you can use "apt-get source lbreakout2" to get the source package though
<thierry> ok so I get the source of breezy?
<bmonty_laptop> I made the change to the patch, I'll upload it
<bmonty_laptop> thierry: it depends on what is in your sources.list
<thierry> bmonty_laptop : ok so please close bug 4619 (sorry I opened it too fast ;)  )
<sivang> mdz: I don't mean bug, but have my email got to you eventually? (re: HomeUserBackup)
<Kamion> xhaker: that's a known usplash bug, I believe; it hardcodes module paths which have changed
<bmonty_laptop> thierry: actually, I think it is better to have a new bug since I'll have to do the debdiff against the source package in dapper
<thierry> bmonty_laptop : will you send the patch to the bug or do you want me to fix it?
<thierry> bmonty_laptop : and is it better to send a .debdiff or a .patch? 
<bmonty_laptop> thierry: you can fix it if you want, and it is easier for people to sponsor your upload if you send a debdiff
<Kamion> xhaker: I've made a note of it for the errata; I think vga16fb usplash still works fine
<bmonty_laptop> thierry: we should move over to #ubuntu-motu
<Kamion> xhaker: I'm impressed that you got a working install out of 20051114, but given that you did, you should just be able to upgrade as normal
<ogra> Kamion, did you test ppc/live already ? i dont seem to be able to boot it ...
<Kamion> ogra: I've burned it, will test in a moment
<ogra> ah
<ogra> it was a media problem
<Kamion> ok, good start :)
<ogra> this ancient g4 doesnt eat CDRW
* Kamion goes to try it
<ogra> a normal CD-R works now
<Pygi> ah :/
<sistpoty> elmo: please sync kvirc from unstable, ubuntu override ok
<ogra> Kamion, mdz, ppc/live is good ...
<mdz> splendiferous
<mdz> sivang: it's in my queue
<thierry> seb128 : is it the end of the world if I sent .patch file to solve bugs in malone?
<janimo> which are the packages that bugzilla does not know about? It does not autocomplete libgnutls-dev, and if entered by hand it says 'unknown component'
<seb128> thierry: no :)
<Kamion> powerpc/live pass until bad sectors on the cloop killed it (I blame the media)
<thierry> seb128 : but is it better to have .debdiff files?
<Kamion> i386/server fail, no preseed files; will have to respin install CDs
<Kamion> (will kill Kubuntu CDs too)
<Kamion> Riddell: ^--
<seb128> thierry:  no, better to have a patch for the desktop file so it can be sent upstream
<Riddell> Kamion: so current CDs are scrap?
<Kamion> Riddell: install CDs are, I'm afraid; live CDs should be OK
<Kamion> (they don't rely on preseeding)
<Riddell> Kamion: ok
<Kamion> I'm fixing the issue now
<thierry> seb128 : bmonty_laptop just told me it was better to have a .debdiff ...
<seb128> thierry: depending of the people I guess, .patch/.diff is fine for this, don't bother
<Kamion> hmm, weird, I get cdebconf-priority's question displayed to me just before reboot into second stage
<Kamion> it's harmless but odd
<thierry> seb128 : ok
<Kamion> tempted to errata it
<Kamion> I think our busybox init patches might have slowed it down enough that init doesn't get around to SIGTERMing main-menu before it executes the next menu item
<seb128> 'night
<ogra_live> mdz, Kamion, amd64/live is good to go ... all livecds were fine here
<mdz> Kamion: I've got a full set of CDs locally now; which need testing?
<mdz> ah, will wait for the next build I guess
<xhaker> Kamion, that cdebconf showed up to me but it rebooted right after. heh
<Kamion> xhaker: right, that's the bug - it's harmless if annoying. fixing
<xhaker> and other prompts looked odd/different from breezy
<xhaker> like the Timezone now it displays a tinier prompt..
<Kamion> that's intentional; tzsetup has been significantly revamped and in many cases now will not prompt at all
<Kamion> mdz: live CDs are still worth testing
<Kamion> cdebconf-priority appearance fixed upstream now
<Kamion> xhaker: different isn't a bug but actively odd might be. :-)
<mdz> xhaker: did you sort out your vesafb issue?
<Kamion> mdz: iz usplash bug
<Kamion> oh, no, maybe not, not with 2.6.12
<Kamion> hmm, ignore me
<xhaker> it does work as i can see the boot process in a nice resolution.. but usplash no longer works (tm)
<xhaker> :P
<mdz> xhaker: could be http://bugzilla.ubuntu.com/show_bug.cgi?id=19675
<xhaker> gonna check
<Kamion> but why would a 2.6.15 issue affect current installs?
<xhaker> mdz, the kernel is still 2.6.12 in installs
<xhaker> is that "bug" present in that too?
<Kamion> not AFAIK, we'd have noticed it in breezy
<lifeless> jbailey: fine by me
<mdz> xhaker: if you're talking about a dapper daily install, then your problem is something else
<sivang> mdz: k, thanks. sorry for bugging.
<zyga> night guys
<zyga> night girls
<Kamion> new Ubuntu install CDs up
<mdz> fetching
<Riddell> Kamion: kubuntu ones next?
<Kamion> Riddell: they're building as I type
<Riddell> Kamion: great.  and what's the status of the live CDs?
<sistpoty> infinity: around?
<Kamion> Riddell: they seem OK for Ubuntu, although I haven't checked amd64 yet
<Kamion> Riddell: Kubuntu live CDs are (as before) fine for you to test
<Riddell> Kamion: there's nothing at http://cdimage.ubuntu.com/kubuntu/daily-live/
<Kamion> uh
<Kamion> hmm, maybe that ran afoul of earlier problems, sorry. OK, I'll rebuild shortly
<Riddell> cool
<Kamion> too ... much ... stuff ... to ... coordinate
#ubuntu-devel 2005-11-24
<Kamion> Riddell: Kubuntu install CDs up
<Riddell> Kamion: thanks
<Kamion> http://king.buildd/%7Ebuildd/livecd/kubuntu/current/livecd.kubuntu.cloop:
<Kamion> 23:11:21 ERROR 403: Forbidden.
<Kamion> meh
<Kamion> lamont: please fix? all buildds I think
<Kamion> lamont: ah, the problem is that the cloop didn't build, due to this, which is still your bug :-)
<Kamion> E: Couldn't find package kubuntu-base
<Kamion> lamont: both Kubuntu and Edubuntu should use ubuntu-base
<Kamion> infinity: or you, if you're around?
<lamont> Kamion: hrm...
* lamont goes to fix
<lamont> Kamion: while I'm doing that - do you know how to run javascript crap in a manner that gets me error messages when I have syntax errors?
<mdz> lamont: tools->javascript console in firefox
<lamont> woot
<lamont> Kamion: ISTR kubuntu-base got created in breezy, yes?
<neuralis> lamont, for more serious stuff, download venkman
<neuralis> lamont, full javascript debugger in xul.
<xhaker> anyone holding packages for firefox1.5 rc's somewhere?
<lamont> sadly, that doesn't show me the errors in my proxy.pac file...
<Kamion> lamont: AFAIK there was never a kubuntu-base
<Kamion> lamont: for good reason - it isn't possible to make netboot installs work properly if Kubuntu's or Edubuntu's base system is ever at variance from Ubuntu's
<Kamion> at least not at present
<lamont>             LIST="$LIST ubuntu-base ubuntu-desktop ubuntu-live"
<lamont>             LIST="$LIST ubuntu-base kubuntu-desktop kubuntu-live"
<lamont>             LIST="$LIST ubuntu-base edubuntu-desktop edubuntu-live"
<Kamion> great, that's correct
<lamont> you are go for launching your builds
<Kamion> launched
<Kamion> thanks for the quick fix
<lamont> now tell me how to find proxy.pac syntax errors. :-)
<Kamion> on that, I'm afraid, I am clueless :(
<lamont> well, I still need to go really fix the source, etc.
<lamont> Kamion: ditto
<lamont> neuralis: E: Couldn't find package venkman
<Kamion> mozilla-venkman |   0.9.85-3 | dapper/universe | all
<Kamion> (back to hoary/universe)
<neuralis> lamont, look harder :P
<lamont> danke
<lamont> neuralis: and this lets me examine the .pac file how?
<neuralis> lamont, you didn't specify proxy.pac as part of your problem until later. venkman lets you "run javascript crap in a manner that" gives you full debug control.
<lamont> ok.
<lamont> how does it let me do that?
<lamont> Kamion: fix committed, it'll be in 0.25 for real.
<neuralis> after starting it up, it will show javascript loaded across all firefox windows, and allow you to place breakpoints or enable full-tracing and such. i'm not sure it'll help with proxy.pac.
<Riddell> elmo: please sync smb4k from debian, ok to override ubuntu changes
<elmo> Riddell: queued
<Kamion> mdz: I reckon the Flight 1 announcement should go to ubuntu-devel-announce these days. Should it go to ubuntu-users too?
<lamont> neuralis: how do I print something in javascript?
<neuralis> there's nowhere to print to, generally. alert('message') will do a pop-up.
<mdz> Kamion: sure
<mdz> Kamion: perhaps with a note to subscribe to -devel-announce for the future
<Kamion> good plan
<lamont> grumble.  myIpAddress() returned 127.0.0.1
<Kamion> amd64/server pass
<lamont> The autoconfig file can be output by a CGI script. This is useful e.g. when making the autoconfig file act differently based on the client IP address (the REMOTE_ADDR environment variable in CGI).
<lamont> but I don't _WANT_ to write CGI
* lamont successfully avoids cgi again
<Kamion> Riddell: just a procedural note re http://lists.ubuntu.com/archives/kubuntu-devel/2005-November/000554.html - it's not called flight-1 until it's released
<Kamion> amd64/install pass
<Riddell> Kamion: good point, noted
<Kamion> Riddell: things are looking good on the Ubuntu side; I've written the release announcement, although I probably won't actually do the release until tomorrow morning now. If you've got basic testing done on all the CDs by then, let me know and I'll release Kubuntu Flight 1 along with it; otherwise I can do it shortly afterwards.
<Kamion> you don't have to test quite as thoroughly as for preview/RC/final - just basic validation that the image can perform an install or boot to a live session as appropriate will be fine
<Kamion> I'm afraid my release announcement errs on the duck side of the debate contrary to my personal preference, but only because I found the perfect quote ;)
<Riddell> Kamion: I don't have anyone to test the ppc disk but otherwise they should all be tested by morning
<ogra> Riddell, i can test ppc live 
<Kamion> ok, I'll download ppc install and see if I can give it a go tomorrow morning
<Kamion> thanks ogra
<Riddell> ooh, live CDs are up
<Riddell> ogra: http://cdimage.ubuntu.com/cdimage/kubuntu/daily-live/20051119/  thanks
<ogra> i'll try rsyncing a ubuntu live :)
<Kamion> ah, yes
<Kamion> ogra: that will help a bit, probably, but not a lot
<ogra> a bit is fine ...
<ogra> at least more than nothing ;)
<ogra> meh
<ogra> dapper-live-powerpc.OVERSIZED
<ogra> Riddell, ^^ drop some languages :)
<Kamion> says the man whose project has a special exception in cdimage code to let it be larger ...
<ogra> lol
<Kamion> kubuntu/powerpc/live is only 3MB over; no great concern for now
<ajmitch> ogra: what, drop .de?
<ogra> heh... i'm fine with .en :)
<ajmitch> noone uses it :)
<Kamion> Kubuntu ships a *lot* of languages; dropping a couple would not be a problem, and we wouldn't have to go anywhere near the most popular ones
<Kamion> this sort of optimisation may be best done later though
<Kamion> well, s/optimisation/tweaking/
<Kamion>  * Languages: af am as az be bg br bs ca cs cy da el eo et eu fa fi ga gl gu he hr hu ia id
<Kamion>  ^-- list of languages hipped on kubuntu/powerpc/install outside the most popular dozen
* ajmitch barely recognises half of those
<Kamion> er, "shipped"
* mpt proposes shipping only those that have complete translations
<mpt> that should cut down on plenty of space :-)
<Kamion> sounds like a good way to ship only one language ;)
<ogra> if they are not complete, they might not take much space :)
<Kamion> now is a bad time to try to execute that metric, though
* ajmitch wonders how complete en_NZ is :)
<Kamion> and, as ogra says, incomplete ones are cheap
<mpt> if Microsoft or Apple shipped with incomplete translations, they'd get tomatoes thrown at them, wouldn't they?
<ogra> nope
<ogra> Apple probably ...
<Kamion> it depends how you define "complete". our archive contains a hell of a lot more software than either Microsoft or Apple ship; even if you go by what we ship, we have an awful lot of translation domains
<Kamion> it's hard to compare because Microsoft and Apple don't have the same kind of huge archive of stuff you can grab after the install
<mpt> and we don't measure CD-completeness separately?
<Kamion> we don't measure it at all yet
<mpt> Rosetta measures completeness at all
<Kamion> ok, I didn't know how good its measurements were, but I'm pretty sure it doesn't measure CD-completeness
<Kamion> in any case I can tell you for free that only one language other than English was even at 100% in the breezy installer
<ogra> french ? 
<Kamion> many were very close, but IIRC only French actually made it
<mpt> :-(
<mpt> Will Dapper's earlier feature freeze mean more time for translation?
<Kamion> hahahahahaha
<Kamion> I wish
<ogra> *g*
<Kamion> in any case I don't think more time would have helped; we need better advertisement of what order one should translate things in
<Kamion> I've been discussing installer translations with Carlos
<Kamion> we have a plan which should help
<Kamion> anyway, bed :)
<ajmitch> a lot of random stuff in universe got translated?
<ajmitch> night Kamion 
<mpt> we have a bug reported on that
<ogra> night Kamion 
<mpt> show which stuff is important first
<mpt> g'night Kamion 
<mpt> https://launchpad.net/products/rosetta/+bug/20
<sistpoty> elmo: please sync nvclock from unstable, ok to override ubuntu changes
<sistpoty> elmo: please sync rafkill from unstable, ok to override ubuntu changes
<Kinnison> g/night all
<powerj> Hello fellows!
<powerj> Anyone around.
<powerj> ??
<powerj> Anyone awake?
<crimsun> elmo: please sync vile and tse3 from Sid, overriding Ubuntu changes, thanks
<elmo> is flight1 out yet?
<ogra> elmo, its done, but not out yet
<powerj> I woud like some gentoo devs opinions about some new software i wrote.. Anyone around?
<ogra> Kamion wanted to announce it tomorrow morning
<elmo> powerj: wrong channel
<zul> very wrong channel
<powerj> elmo, is it not here you find the ubuntu devel staff?
<elmo> crimsun: queued
<crimsun> elmo: thank you.
<crimsun> powerj: you mistyped "gentoo"
<powerj> Oh, sorry i was thinking ubuntu..
<powerj> I am writing an replacement for sysvinit, that boots the system in parraler, and heavy reduces boot time.
<powerj> Maby you devs, can tell me a feature list you want to have in a sutch system.
<powerj> Things that i missed.
<powerj> Have a look: http://initng.thinktux.net/
<crimsun> issue has been raised in the channel previously and on the mailing lists
<powerj> Ok?
<crimsun> just letting you know it has been raised. Timeframe is not within Dapper.
<powerj> crimsun, do you have any url to the debate on the mailinglist, or an irc log?
<crimsun> powerj: http://people.ubuntu.com/~fabbione/irclogs/  and lists.ubuntu.com
<crimsun> sorry I don't have them handy
<mpt> powerj, http://lists.ubuntu.com/archives/ubuntu-devel/2005-May/thread.html#7410 is one
<powerj> mpt, thanks, but these mails are back from may, anything fresh?
<mpt> powerj, see http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013072.html w.r.t. Dapper
<powerj> Are there any intrest what you know, to include an alternative init system in ubuntu?
<powerj> People from linspire distro, walked by my #initng and sad that they are working for a complete switch to #initng, actually i would like to see it if even optionally in ubuntu sience its my default distro.
<powerj> That i calually want to say here is that i woud like some feedback, and possibly some directions of what shud be done to my project, towars the integration in ubuntu.
<mpt> powerj, I am in no way an expert on the subject, but from what I have read, the plan is to work on simple improvements to the current system for 6.04 (and there's substantial room for improvement in the current system), then do something less hackish than init-ng for Dapper+n, where n is approximately 1.
<mpt> see for example http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013021.html
<powerj> less hackish than init-ng?
<mpt> and http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013053.html
<mpt> but I have my own work to do now, so excuse me :-)
<powerj> mpt, actually initng is way more advanched than Solaris SMF, and way more extensionable.
<powerj> mpt, okay thank you for your time.
<mpt> If you want to discuss that, the best person to discuss it with would be the Scott James Remnant who wrote that message, aka Keybuk in IRC
<mpt> he's the one doing a lot of the work to reduce startup time for Ubuntu at the moment.
<Riddell> ogra: did you test the ppc CD?
<ogra> Riddell, just finished
<ogra> Riddell, i had only one problem ... there was KDE on my ubuntu ;)
<ogra> Riddell, its fine :)
<spacey> :o
<spacey> whole night messing around with migrating ADS to Samba stuff, i look and feel like a zombie now
<spacey> good night
<ogra> night spacey 
<ajmitch> night spacey :)
<ogra> and night world, i'm off as well ...
<ajmitch> see you later
<powerj> mpt, thank you, i drop him a mail.
<Riddell> ogra: great, thanks
<Riddell> ogra: how come you can't do an install?
<Riddell> Kamion: kubuntu x86 install/live, amd64 install/live and ppc live all work
<Erlang> Can anyone help my with my Ubuntu/Debian dilemma?
<magnon> the answer will always be ubuntu
<Erlang> I can answer the dilemma myself at the end, but I'm looking for a killer p.o.v. somewhere.
<magnon> Erlang: well, you could start by asking a bit more specific
<Erlang> magnon: I could... I will be updating my system to AMD64 from 32 bit soon and I need to decide between
<Erlang> Ubuntu and Debian
<Erlang> I'm a wannabe Debian developer...
<mpt> desrt, ping
<Erlang> well, right now I'd go for Ubuntu.  If I think of a reason I could change my mind, I'll come back here.  It'll be more productive that way.
<mpt> Erlang, no-one can deny the power of the brown
<Erlang> the brown?
<mpt> the brown!
<Erlang> hmmm
<Erlang> whats ... that?
<ajmitch> a nice earthy colour
<Erlang> o_O
<Aegir`> Flaming mother of mercy. My filesystem just exploded... Well, thats one dapper box thats bit the dust. Time to reformat...
<rob1> what is the default music app on a fresh install? rhythmbox/totem?
<sabdfl> rob1: rhythmbox
<rob1> thanks sabdfl 
<zyga> morning
<sivang> morning all
<Kamion> powerpc/install fail due to media problems; my current inclination is to say "sod it", Kubuntu powerpc/install has got further
<zyga> Kamion: is there any working hfs+ repartitioner?
<zyga> (partition/fs resizer)
<Kamion> zyga: parted in dapper should do it; not parted in breezy
<zyga> Kamion: with user interface in the installer?
<zyga> (or the livecd)
<Kamion> try why not try it?
<Kamion> (excuse weirdness, slow link)
<zyga> breezy does not have any user interface for it and I'm not feeling like loosing my data again
<Kamion> also breezy's parted can resize hfs+ provided that you disable journalling
<Kamion> breezy sure does have user interface for it
<zyga> hmm
<Kamion> press enter on the Size: field in the detailed page for the partition
<zyga> is that interface available in the debian installer?
<Kamion> YES
<zyga> hmm
* zyga needs to try again
<Kamion> (er, sorry, caps lock)
<zyga> can the journal be disabled after installation?
<Kamion> of Mac OS? yes, google for instructions
<zyga> right
<Kamion> there are several ways to do it, both command-line and graphical
<zyga> Kamion: if I find such instructions they could be patched as an info node into the installer, do you agree?
<zyga> (mornin pitti)
<pitti> Good morning
<Kamion> no, I do not agree
<Kamion> they could go in the installation manual, but they don't belong in the installer itself
<zyga> at least a note that they are in the manual (and how to find the manual)
<Kamion> no, only in the manual
<zyga> hmm
<zyga> I never knew about the manual really and I think that's something users might struggle with
<Kamion> I'm not going to burden our translators with having to translate a million links to the manual from lots of places
<Kamion> it's sufficient to point to the manual up-front at the very start, in the boot screens (we should add that)
<zyga> I see, but if the user does not know how to sucessfuly resize their hfs+ volume he might decide not to install, just as I did. A single sentence that points in the right direction (Like: To find out how to resize your hfs+ volume, take a look at the manual on the CD) could help a lot
<xxenon> is anyone testing 2.6.15 in dapper ?
<zyga> I agree
<Kamion> zyga: that will no longer be necessary in dapper *anyway*
<zyga> oh, why? :-)
<Kamion> because parted in dapper works even if you leave journalling enabled, as I implied above
<Kamion> or at least so I am told
<zyga> ah, then this is a no-issue :-)
<zyga> thanks for the information
<Kamion> indeed
<Kamion> meh, kubuntu powerpc/install gets further but still dies due to media problems
<Kamion> well, I have no reason to believe it will break and we've tested most of the individual pieces, so I'll just release it
<Kamion> zyga: dapper's parted should also be able to handle HFSX (new variant of HFS+ used in very new versions of Mac OS X)
<Kamion> breezy's couldn't
<zyga> Kamion: hmm, 10.4.3?
<Kamion> http://developer.apple.com/technotes/tn/tn1150.html says it was introduced in 10.3; may not be the default, I don't know
<zyga> checking
<Kamion> 03:44 < powerj> mpt, actually initng is way more advanched than Solaris SMF, and way more extensionable.
<Kamion> 03:44 < powerj> mpt, actually initng is way more advanched than Solaris SMF, and way more extensionable.
<Kamion> (d'oh, sorry)
<zyga> Kamion: hfsx is a minor modification, it allows for (bah) case-sensitive file names
<Kamion> yes (I don't really care about the details), but it still requires explicit support in parted because it's a new filesystem type
<zyga> (welcome to the 1970 ;-)
<Kamion> I also have read the technote I pointed you to ;)
<Keybuk> ooh
<Keybuk> when did lists.uc get prettyfied?
<zyga> Keybuk: hi
<Keybuk> that was a "hi, I was looking for you, and you're in trouble" kind of hi, wasn't it?
<zyga> :>
<zyga> no not really :)
<Keybuk> oh, phew
<zyga> I had a few questions but they are not important anymore I guess
<Keybuk> I'm all ears
<Keybuk> except for the bits of me that aren't
<Keybuk> because I'm not a grasshopper
<Keybuk> ask away
<zyga> It was about non-contiguous malloc, one that doensn't suffer from allocation spikes
<zyga> I had a discussion with seb the other day
<zyga> if you know of any malloc that's better than current one I'm all ears myself :)
<Keybuk> there's about as many malloc implementations as there are nih libcs
<Keybuk> all equally bad at most things :)
<Kamion> a totally new malloc implementation sounds about as inappropriate for dapper (a long-term supported release) as it's possible to get
<zyga> it's not about dapper at all
<zyga> damn I confuse you two
<Keybuk> #define malloc mmap
<Keybuk> easy
<zyga>  hehe
<zyga> almost ;] 
<Keybuk> Kamion's the Lord of the Dance, and I'm the Queen of the Dancefloor
<zyga> oh, where's buffy then?
* zyga hides
<Kamion> that's elmo
<zyga> lol
<zyga> Keybuk: http://www.suxx.pl/~zyga/malloc-test/ if you know of anything that can survive this please let me know :)
<Kamion> malloc is about the common case as well as stress-tests
<zyga> ?
<zyga> ah
<zyga> sorry I omitted one word and it didn't make sense
<Keybuk> you can also tune malloc for your process too
<Keybuk> there's a bunch of random options to let you rely less on sbrk, and more on mmap, etc.
<Kamion> programs that really run into pathological behaviour of malloc often use their own allocators; it's not like there aren't loads around :)
<Kamion> like the apr pools implementation, talloc, etc.
<neuralis> zyga, have you looked at google's TC Malloc?
<zyga> yes there are a multiudue of them
<zyga> neuralis: no :> but it already sounds interesting
<neuralis> zyga, goog-perftools.sf.net
<neuralis> zyga, blazing fast, plays well with stl and threads
<zyga> in-app allocators are basically because standard allocators are more less bad :/
<Kamion> standard allocators are generally trying to be simple, so that they can be a common denominator; once you start being clever you often end up de-optimising for cases you didn't think of
<Keybuk> malloc works sufficiently well for the most part
<Keybuk> the glibc one is a little more intelligent than just "sbrk to get more space"
<zyga> right but the really messy feature of the standard doug lea's malloc is the dependance on sbrk
<zyga> it can use mmap but as far as the source says, it's not that smart
<zyga> (especially when it comes to free)
<Keybuk> free is over-rated :)
<zyga> yeah ;] 
<Keybuk> Linux knows better than to believe an app about how much memory it wants
<Keybuk> and it all gets freed when the app closes anyway
<zyga> ?
<zyga> what about apps that keep runing and running
<Kamion> for example I've worked on programs that really heavily use mmap, right up to the limits of the virtual address space; an mmap-based malloc would de-optimise for that
<zyga> like browsers and damn text editors in most ofices
<Keybuk> the big pages of unused memory won't be mapped
<Keybuk> and they won't page fault because they're not being used
<zyga> ?
<Keybuk> so the app "thinks" it has that memory, when the kernel got rid of it ages ago
<jamesh> Kamion: good reason to switch to 64-bit then :)
<zyga> big pages of previously used memory keep being mapped
<Keybuk> "big pages" ?!
<zyga> s/big pages/lots of pages/
<Keybuk> I of course meant lots of
<Keybuk> yeah I was correcting myself there
<zyga> :-)
<Kamion> jamesh: in some cases that was a win, yes (subject to some other considerations), but it was not always quite so simple, especially five years ago
<jamesh> nod.
<Keybuk> why would they keep being mapped if they weren't used?
<zyga> Keybuck: they were used before, that's why they were mapped
<Kamion> jamesh: frex on the early Opterons it made almost no difference (curiously enough)
<zyga> but after they were freed in the program they are still mapped 
<Kamion> I think that's been sorted out since though
<Keybuk> right, but Linux gets bored quite easily and unmaps them from the real memory if they're not actually used
<zyga> and puts them to swap
<Keybuk> so they appear in the process map, but don't actually take up real memory
<zyga> that's bad IMHO
<zyga> it cannot just discard them, linux doesn't know they are 'free' it just swaps them away, right?
<Keybuk> right
<zyga> exactly :/
<zyga> why would an mmap based allocator be bad then?
<Keybuk> the cost-per-map is reasonably high, you wouldn't want a new map per 16 byte struct
<zyga> you cannot map such small regions anyway
<zyga> but a mmap per 1MB makes more sense
<zyga> when such chunk gets free it can be really returned
<Keybuk> 1MB is rather arbitrary
<zyga> generally a multi-heap design, in the allocator
<zyga> it was an example
<Keybuk> mapping anything other than multiples of 4096 bytes is silly ;)
<zyga> (I was really thinking about mapping 4MB jumbo pages)
<Keybuk> right, 4MB is a reasonably sensible (and common) size
<Keybuk> as is 8MB (default stack, iirc)
<zyga> each jumbo page could be freed (even parts of it could be unmaped if necessary)
<Keybuk> ah, but then you have the fun thing
<Keybuk> allocating space on the page according to where it's likely to be /freed/
<zyga> (BTW: this can go away from #u-d if that's not appropriate here)
<Keybuk> as you'd want to deliberately optimise for clearing pages at once
<zyga> yesh :)
<zyga> run-time data gathering could help
<Keybuk> you wouldn't want to front-fill pages, you'd want to know in advance the memory usage pattern of the program so that data that is commonly freed together is put on the same page
<zyga> or an enchanced malloc api like MALLOC_LONG_LIVED flag
<Keybuk> there are compiler thingies that deal with that
<zyga> oh?
<zyga> I heard about the sun compiler, that it can optimize away some malloc calls
<zyga> (but it was only for loops and trivial cases)
<zyga> a generic approach, one that could calculate the probability of long-livedness of an object would be better
<zyga> it could minimize living objects in mostly empty pages
<zyga> (or simply chunk all long-lived objects together)
<Keybuk> there are many many papers and experiments into it
<Keybuk> see Google
<zyga> believe me I did 
<zyga> I tried citeseer too
<zyga> maybe I spell badly
<zyga> ..
<Keybuk> the "generic" approach is often to use multiple memory pools
<Keybuk> ie. have a "small shit" pool for fixed-sized blocks that you just reuse over and over
<zyga> right :-)
<Keybuk> so whenever you need anything less than 128 bytes, you just grab the first unusued block from that pool
* zyga is writing another paper on this topic
<Keybuk> and everything in that pool is 128 bytes long
<zyga> I was really looking for some exisitng work but all I could find were multi-processor high-end allocators
<Keybuk> you might also have a long-lived pool, for things you know are going to be around for a while
<zyga> interesting but useless stuff for the desktop
<Keybuk> sometimes you have a string pool, where you try some wacky stuff to re-use strings
<zyga> I have a more generic approach
<zyga> I have governors
<zyga> classes and instances
<zyga> and each governor is assigned to a fragment of vm space
<zyga> each can really do what it wants internally
<Keybuk> the trouble with the more complicated approaches is that you sacrifice speed for vsz
<zyga> they have pretty simple outside api
<zyga> yes I know
<zyga> but that's the part of design
<Keybuk> which de-optimises for something that needs to live fast and die young
<zyga> to win speed by doing best not to touch swap as long as that's possible
<zyga> well the governor init is pretty fast
<Kamion> optimise for where it's likely to be freed> this is why application-specific allocators are often superior *anyway*
<zyga> I'm still not sure about how to do startup
<Keybuk> grep for example needs to just to allocate until it dies from either lack of memory, or finishes (and lets the kernel free up the memory it used)
<zyga> app-specific allocators don't span libraries
<Kamion> memory allocation patterns usually don't span libraries well either
<zyga> and multiple allocators fighting one-another is bad for both vm space and swap-likliness
<zyga> true, but an unified system that allows apps to plug their allocators 'higher' would be better
<zyga> if you really need that custom allocator make sure it plays nicely with other parts of the system
<zyga> anyway that's the long-term idea 
<zyga> so far I've got a trivial allocator with one governor that survives that spike test 
<zyga> and lots of ideas for other allocators
<zyga> but I'm still far from tying that into runtime detection of what's best here
<zyga> small object allocator, big object allocator, generic allocator (currently similar to what malloc does)
<zyga> the key to unlocking all of this is to put a working history-based guesser that can allocate in the right governor
<zyga> so long lived allcations go into one place mostly
<zyga> history tracking is based on the call traceback of each malloc call
<zyga> it's not working 'live' yet but it's a start
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 1 released
<Kamion> *phew*
<Kamion> doko: you're good to go with libstdc++ allocator changes
* Kamion releases his soft lock on main
<zyga> allocator changes??
<Keybuk> hmm, I might upload udev and break the world this weekend then <g>
<Kamion> zyga: *sigh*
<siretart> Kamion: grats for flight cd1, man! :)
<seb128_> Kamion: rock ;)
<Kamion> zyga: *libstdc++*, not libc; http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html
<zyga> checking
<siretart> zyga: some ppl refer to that as the 'c2a' transition. it basically means another cxx transition *sigh*
* zyga hugs C
<zyga> ;-)
<zyga> right
<Keybuk> "you need to update for the C++ transition"
<Keybuk> "right, uh, which one?"
<siretart> hrhr
<Keybuk> Kamion: good quote <g>
<Kamion> I liked it
* Keybuk clicks approve
<Keybuk> at least, I think I clicked approve
<Keybuk> I hate mailman
<Kamion> shout if I need to resend it
<Keybuk> it showed up, so I must have :)
<Kamion> ah, yes, there it is
<HiddenWolf> Keybuk, you take pleasure in breaking the world, don't you? ;)
<Keybuk> HiddenWolf: only by breaking the world can we learn what it's made of, and how to put one back together again
<HiddenWolf> dude, it's saturday. Don't make me read twice. :)
<Kamion> Keybuk: *do* sync that with an upload of linux-meta, please :)
<Kamion> hm, we probably want l-r-m first too
<Keybuk> yeah, we'll need to sync, at once:
<Keybuk> 1) 2.6.15 in meta
<Keybuk> 2) lrm
<Keybuk> 3) udev
<Keybuk> 4) hotplug and grepmap removed from meta
<Kamion> l-r-m can come first
<Keybuk> probably hal too
* zyga is amazed by the way foss developmen works
<Keybuk> I'll grab everyone into #ubuntu-boot when it's "ready" and we'll make sure we lock-step everything
<Kamion> and should, given how tricky it is to make it build
<Keybuk> probably 5) installer checks too
<Kamion> yeah; I'm going to be away much of the weekend
* HiddenWolf thinks open heart surgery with a blunt knife sounds like a decent comparison.
<Kamion> we need some installer syncs/merges from upstream before the installer will work right with 2.6.15
<Keybuk> "I'm sorry, was that your aorta?"
<Kamion> couple of things we noticed at the last minute
<Keybuk> what changed with 15 that broke it?
<Kamion> Keybuk: not 15 in particular, just a few things about newish udev we forgot to actually do as opposed to talk about
<Keybuk> oh, such as?
<Keybuk> bearing in mind our new udev isn't the same as Debian's
<HiddenWolf> Keybuk, why not?
<Riddell> Kamion: nice quote :)
<Keybuk> HiddenWolf: because Debian took a long stroll down crack-addled-alley
<HiddenWolf> Keybuk, seriously?
<Keybuk> take for example the elaborate maintainer scripts that mount a new tmpfs, initialise it with the newly upgraded udev, and try to migrate the existing system over to that while killing any process currently reading a device, etc.
<HiddenWolf> ehm, ouch?
<Keybuk> ... we decided just to leave the old /dev in place and pop up a "you might want to reboot at some point" thing
<doko> Kamion: ok, thanks
<HiddenWolf> Keybuk, you're telling me that udev update will kill all processes on any debian rig?
<Keybuk> not all processes, but it'll certainly handicap a few things
<HiddenWolf> pretty much kicking around in a domino setup...
<Keybuk> yeah, upgrading udev is pretty much like purging your current kernel and popping a new one on the disk
<Keybuk> or, tbh, upgrading libc
<Keybuk> it's reboot time
<Keybuk> trying to deal with it any other way is just not going to work
<HiddenWolf> Poor testers, all thinking flight might be a decent time to take the plunge. :)
<Keybuk> it is a good time
<Keybuk> what's the point in having testers who don't want to test things? :p
<Kamion> Keybuk: by newish I mean "post-060"
<Kamion> Keybuk: like dealing with udevstart possibly not being there
<Keybuk> ahh
<HiddenWolf> Keybuk, so if this goes wrong, is the system unbootable?
<Keybuk> HiddenWolf: only if it goes _very_ wrong
<HiddenWolf> Keybuk, so if someone updates halfway through putting the new versions in the archive, they're screwed. :P
<Keybuk> that's what versioned dependencies are for
<Keybuk> though if someone compiles their own older kernel, lots of things will stop working for them
<Keybuk> they'll get the old static /dev and no hotplug at all, etc.
<thierry> seb128 : for https://launchpad.net/distros/ubuntu/+source/ghextris/+bug/4618 , do I send another patch to not force the extension, or do you simply close the bug as NOTABUG ?
<seb128> thierry: if the path is fixed there is no need to drop the .png, there is no variants
<seb128> thierry: variants are usually shipped with themes
<seb128> ie: if you specify just a name "icon_name"
<thierry> seb128 : ok so you'll close it?
<seb128> it can be shipped by different themes, with a svg variant by example
<seb128> I already did
<thierry> ho ok sorry<
<thierry> we should copy your comment in the wiki page
<seb128> I'll comment
<thierry> k thanks
<seb128> np
<thierry> seb128 : while we talk about that I have other bugs that maybe you'd like to check too (for the absolute icon path thing)
<seb128> thierry: which one?
<thierry> seb128 : 4587 , 4608 , 4419 , 3963 AND 3951
<seb128> thierry: I've closed 5-6 bugs this morning
<thierry> seb128 : I know so let's do the whole clean up
<seb128> bittornado doesn't ship a .desktop with dapper
<seb128> so I've not commented on #4587
<thierry> seb128 : but he needs one! no?
<seb128> yeah, but I don't want to start doing such change, I just want to quick comment on stuff I can try without rebuilding a package modified :p
<seb128> that's saturday
<seb128> #4608
<seb128> Icon=/usr/share/httrack/icons/webhttrack.xpm
<thierry> seb128 : yeah ok... but I mean you won't close the bug for that right?
<seb128> same issue, I reject it
<thierry> seb128 : yeah I see
<seb128> thierry: no
<thierry> good
<zakame> is mdnsresponder dropped in dapper?
<zakame> I don't see it in packages.u.c, but asking away just to be sure :)
<seb128> thierry: 4419 path required
<seb128> thierry: #3963 is ok
<pef> hello
<seb128> thierry:utch, patch from #3951 is really broken, you just dropped the translations
<seb128> hi pef
<thierry> seb128 : damn, didn't saw that, but anyway it should be closed since it goes in /usr/share/gnome-system-tools/pixmaps/disks.png
<thierry> seb128 : while looking at the patch, I remember there was some specs problems
<seb128> thierry: there is different desktop file to autogenerate translations, etc
<seb128> you drop the _ on _Name by example
<seb128> which breaks the translations
<zakame> hmmm, netatalk doesn't seem to build, build-deps not met as libdb4.2-dev removes heimdal-dev and kerberos4kth-dev, all of which build-depended on by netatalk :( what should I do?
<seb128> zakame: your sentence is not clear
<seb128> there is some mess with libdb versions
<seb128> pitti started looking on that yesterday, maybe wait a few days
<thierry> seb128 : yeah I see... but icon like @pixmapsdir@/network.png ... does it needs to stay like that?
<seb128> thierry: yeah, they do
<zakame> seb128: I was trying to grab the build-deps for netatalk, but I couldn't do so because upon grabbing libdb4.2-dev it tries to remove heimdal and kerberos :(
<thierry> k
<seb128> zakame: right, pitti was on this yesterday, wait monday
<zakame> seb128: ah, ok, putting this on #4106 as a comment, thanks :)
<seb128> np
<Lathiat> mjg59: hrm, is usplash in dapper supposed to be b0rked?
<tseng> Lathiat: yes.
<Lathiat> ok
<Lathiat> ooh interesting 2.6.15 sound driver for my laptop (i810) no longer has a split master/headphone
<Lathiat> that was both a usefull and annoying feature
<xhaker> shouldn't ubuntu-desktop depend on xchat | xchat-gnome
<xhaker> nvm
<xhaker> it's in universe
<xhaker> any plans to bring it to main?
<slomo> xhaker: when it's completly usable maybe ;)
<xhaker> i ask this because i'd like to try it.. the spell checker sound good for ubuntu
<xhaker> i guess i'll try it later when it gets depends on 2.6.0
<spacey> any ms active directory guru's here by *any* chance?
<Manny> hi
<Manny> I'm re-asking the question here, since asking it ni #ubuntu didn't yield any results: are there any plans to add more -dbg packages? I'm specifically looking for libpoppler-glib-dbg and libpoppler-dbg
<Riddell> Manny: I don't think there's any plans for it, but feel free to do the changes and ask for them to be reviewed and included
<Manny> Riddell, thanks
<Manny> Riddell, -dbg packages are particularly useful for tracking down crashes
<pitti> Manny: eventually we want a more general approach to this
<pitti> Manny: https://wiki.ubuntu.com/AutomatedProblemReports
<Manny> pitti, excellent
<zyga> pitti: hi
<zyga> pitti: a few questions
<zyga> pitti: first langpack update for breezy, when
<zyga> pitti: dapper translations open, when
* pitti points zyga to carlos
<zyga> thanks
<zyga> carlos: ^
<pitti> Rosetta export is currently switched off
<pitti> without data I can't do anything
<zyga> any particular reason? is something broken
<pitti> I hope it is fixed soon now
<pitti> it has been broken all the time
<zyga> hmm :/
<zyga> okay
<zyga> thanks
<zyga> and feel free to ping me if you feel that .desktop files need any coding :-)
<zyga> I'd like to finish that one
<psusi> I changed my sources.list to point to dapper instead of breezy, then did an apt-get update ; apt-get dist-upgrade.. it looked like it upgraded me to dapper, only a number of packages are not using the newer dapper versions
<psusi> anyone got any idea what I did wrong?
<hunger> psusi: This is not a support channel. Please check in #ubuntu.
<psusi> ok... thought they were more user level issues with breezy
<psusi> I changed my sources.list to point to dapper instead of breezy, then did an apt-get update ; apt-get dist-upgrade.. it looked like it upgraded me to dapper, only a number of packages are not using the newer dapper versions
<psusi> damnit... sorry
<hunger> psusi: This channel is for developer talk. Feel free to stay and listen in.
<psusi> I'm trying to get the new version of coreutils with O_DIRECT support and possibly do some hacking on it... thought that since it was being used in dapper, I could just dist-upgrade... heh
<hunger> psusi: I never do dist-upgrades. Always to upgrade (plus remove and install).
<HiddenWolf> hunger, why is that? As soon as the dist-upgrade doesn't conflict, it should be perfectly safe, right?
<hunger> HiddenWolf: Sure. It's just a control-freak kind of thing.
<psusi> well is what I did the correct way to do a dist-upgrade?  It looked like it worked... chugged along for a while doing upgrades
<psusi> but when I look in synaptic, I've still got the old version of coreutils
<hunger> psusi: dist-upgrade is definitly the proper way to do it.
<hunger> psusi: Which one is that?
<psusi> 5.2.1
<hunger> psusi: It is not as if *everything* changes on dist-upgrade.
<psusi> according to packages.ubuntu.com, dapper is using coreutils 5.93
<psusi> that's what I need
* hunger never used synaptic either:-)
<hunger> psusi: I am on dapper and I got 5.93. Have you tried running apt-get directly in a terminal?
<psusi> yea... after the apt-get dist-upgrade I tried update and upgrade again... no dice
<hunger> psusi: apt-get -f install does not find anything to fix either?
<psusi> nope
<hunger> psusi: Dapper is in development, sometimes something does go wrong.
<psusi> yea... I understand... that's why I'm trying to figure out of this is something stupid that I am doing, or something is borked in the repositories
<psusi> apt-get update fetches all the dapper package lists... I just don't get it
<infinity> psui : apt-cache policy coreutils
<mdz> psusi: using the us.archive.ubuntu.com mirror?
<mdz> psusi: (it's broken at the moment)
<psusi> yes...hr... pastebin seems to be down
<psusi> ohh, it is?  how's it broken and is there another mirror I could use?
<infinity> s/us.//
<psusi> hrm... ok
<psusi> bingo
<psusi> upgrading 380 packages... hah
<psusi> thanks...
<Znarl> mdz : us.archive is broken?!?
<psusi> it seems so
<pitti> hmm?
<pitti> dpkg-divert: rename involves overwriting `/usr/lib32/libGL.so.1' with
<pitti>   different file `/usr/lib32/nvidia/libGL.so.1.xlibmesa', not allowed
<pitti> d'oh, I can't purge nvidia-glx any more
<zyga> pitti: I never understood why there cannot be multiple gl systems at the same time (like gl.d) with a select-opengl tool
<hunger> zyga: gentoo has something like that.
<zyga> oh, so it's possible technically :>
<zyga> cool, why don't we get it?
<mdz> Znarl: broken = hasn't been updating for a while, yeah.  we discussed it yesterday
<desrt> mpt; pong
<mjg59> Hmm. Anyone have any idea how many tablet PCs there are on the market?
<Treenaks> mjg59: how many models, or how many sales of those models/
<mjg59> How many models
<HiddenWolf> mjg59, why? they're 90% Win or Palm.
<mjg59> HiddenWolf: Uh. No they aren't. Tablet PCs, not PDAs.
<sivang> mjg59: for starters, there's one per each "big" vendor, Toshiba, Panasonic, Sony, IBM, Compaq etc
<sivang> mjg59: the Panasonic's one are interesting :)
<mjg59> Ah. I hadn't seen any Panasonic or Sony ones.
<mjg59> I've just written some code for the Toshiba one to detect when it's in tablet mode
<mjg59> So I'm wondering how many people I'll need to find in order to make it useful on other pieces of hardware
<sivang> mjg59: wow nice, do you have the hardware at your disposal?
<mjg59> I've got a Toshiba tablet, yeah
<sivang> mjg59: I'd say 5 people :)
<mjg59> The HP one I've got is a slab design - there's no screen rotation, there's just keyboard attach/detatch
<sivang> mjg59: Canonica's sponsering or privately yours?
<mjg59> Various sources
<sivang> mjg59: very cool
<sivang> mjg59: so, what features does Ubuntu already supports on the Tablet PC ?
<mjg59> sivang: Touch screen is supported if you install wacom-tools
<mjg59> And, uh, that's about it
<sivang> mjg59: and then I can use handwriting recognition to input in?
<sivang> m
<mjg59> You can install some handwriting software that doesn't work very well
<mjg59> And then you can have extreme problems when the screensaver comes up
<sivang> mjg59: FOSS , in need of more work ? :)
<sivang> mjg59: well, at least good to hear from you that we're getting there 
<mjg59> Oh, and you currently still need to hack xorg.conf if wacom-tools is installed
<mjg59> But other than that, it's all good
<sivang> mjg59: so at least I can use my finger instead of the mouse?
<sivang> mjg59: well, if you need someone to do testing, I'm always willing to be sent some hardware ;-D
<HiddenWolf> mjg59, is there any chance whatsoever that ubuntu would ever get the handwriting right?
<mjg59> sivang: They're generally wacom devices, so not a touch screen in the traditional sense
<mjg59> You have to use a special pen
<mjg59> HiddenWolf: Ideally
<HiddenWolf> mjg59, not too promising. :(
<mjg59> HiddenWolf: It's not something I've got any time to work on, but with luck somebody will be able to at some point
<HiddenWolf> mjg59, so is it a goal to get ubuntu in the embedeed realm?
<mjg59> HiddenWolf: That's what the ucbuntu project's supposed to be looking at
<sivang> mjg59: Charles is one of the guys working on it right?
<mjg59> sivang: Not sure, I'm afraid
<sivang> mjg59: I met him at UBZ, he told me he was working on some packages for hendhelds. actually, this isn't probably "embedded" per se :)
<mjg59> Hmm. That's interesting.
<mjg59> One of the SATA patches is breaking suspend on this laptop
* ispiked 's ears perk up.
<ispiked> mjg59: suspend to disk or suspend to ram?
<mjg59> ispiked: Suspend to RAM
<mjg59> Grah. Cock.
<mjg59> It's the sata suspend/resume patch (ironically)
<mjg59> mdz: Around by any chance?
<mdz> yep
<suneco> hello guys
<suneco> plz i am semi new to ubuntu
<suneco> and i need to know - how do i follows these instructions
<suneco> 1/ install (using synaptic) the kernel sources for 2.6.10-5386
<mdz> suneco: the best place to ask such questions is #ubuntu
<suneco> yes, but they don't answer
<suneco> its intermediate
<suneco> ok, i will
<mdz> there is a list of other support resources at http://www.ubuntu.com/support/
<suneco> ok thks
<Loevborg> I just discovered that breezy's ruby threading is borked; can't http://bugzilla.ubuntu.com/show_bug.cgi?id=17415 be fixed in a breezy update?
<ispiked> mjg59: 59?
<mjg59> ispiked: ?
<Blejdfizt> i'm having some trouble with launchpad.. my bugreport is falsely reported to be in upstream.. how do i remove that?
<ispiked> mjg59: what's the 59 mean on the end of your name?
<mjg59> ispiked: It's my university username
<ispiked> mjg59: I see. Our scheme is <first initial><middle initial><first six letters of our last name><optional number if you're not unique>.
<mjg59> All usernames here have numbers
<HiddenWolf> heh
<HiddenWolf> still better than my uni.
<HiddenWolf> I'm 279169hb. :)
<mpt> Blejdfizt, what's the URL of the bug report?
* mpt used to be mpt26
<Treenaks> mpt: then you had your birthday?
<mpt> yeah, now I'm 27 :-)
<Treenaks> mpt: wow, mjg59 must be very old then ;)
<mpt> but seriously, I was mpt26 at my first university
<mpt> and thoma994 at my second
* ispiked didn't know princeton had a comp. sci. program.
<ispiked> oh, nevermind. princeton.org != princeton.edu
<mpt> What did you think Brian Kernighan taught, ispiked?
<mpt> (but yes, Princeton was neither of my universities, sad to say)
<Treenaks> mpt: wrong continent?
<mpt> indeed
<mpt> Blejdfizt, if you're going to come back later and try asking again you might get a better response in #launchpad
<zyga> hi
<zyga> is it just me or is ubuntu.com down?
<HiddenWolf> it's up for me
<Blejdfizt> mpt: sorry.. was writing on a report :)
<Blejdfizt> mpt: https://launchpad.net/products/glibc/+bug/4641
<mpt> Blejdfizt, so the bug occurs only in the Ubuntu glibc package, not in glibc upstream?
<mpt> unfortunately you can't alter the upstream request because of https://launchpad.net/products/malone/+bug/1342
<mpt> I'll do it for you since I'm a Launchpad admin
<mpt> if it's true that the bug doesn't happen upstream
<Blejdfizt> i cannot confirm that it does or doesn't occur upstream
<Blejdfizt> i just did the report wrong :)
<Blejdfizt> it works in debian stable (but it's an older version there).
<mpt> ok
<Blejdfizt> the first post (with the patch) could be removed also since the patch is in an attachment
<mpt> Malone doesn't remove comments (including original bug reports), but hopefully they'll eventually be hidden by default if superceded, as described in https://wiki.launchpad.canonical.com/KeepingBugsConcise
<Blejdfizt> ok.. i'll know that until next time then :)
<mpt> yeah, patches are much better as attachments
<Blejdfizt> but.. i attached a patch :)
<zyga> can anyone give me a direct link to 'download breezy' section
<zyga> somehow my isp has broken connection to the majority of outside world
<zyga> and I'm just about to publish a new version of ubuntu.pl
<psusi> jesus I hate octal
* psusi drubs programmers who use octal instead of hex
<zyga> psusi: why?
<psusi> I dunno... I just don't like octal
<psusi> I have to think to figure out how it maps to binary
<psusi> hex I just see it in binary right away
<zyga> octal only makes sense to chmod arguments IMHO :-)
<psusi> I can't stand it there either
#ubuntu-devel 2005-11-25
<HiddenWolf> any server admin here?
<HiddenWolf> GPG error on nl.archive.ubuntu.com
<HiddenWolf> W: GPG error: http://nl.archive.ubuntu.com breezy Release: Unknown error executing gpgv
<HiddenWolf> W: GPG error: http://nl.archive.ubuntu.com breezy-updates Release: Unknown error executing gpgv
<Znarl> HiddenWolf : Only recently?
<HiddenWolf> Znarl, yes
<crimsun> wait 30 minutes and retry
<HiddenWolf> crimsun, what changed?
<crimsun> more than likely, it's syncing
<crimsun> dunno about 'breezy'
<HiddenWolf> Znarl, isn't it still a redirect to archive.u.c?
<Znarl> nl has recently changed to a mirror.
<Brunellus> stupid question.  how do I send a bug report using the bug reporting tool?  it seems to want to use sendmail;  how can I tell it to send the mail through my SMTP server?
<Znarl> HiddenWolf : OK, I've pointed nl back at the master archive site.
<HiddenWolf> Znarl, I didn't ask you to, was just alerting you to that error. :)
<Znarl> HiddenWolf : Ok, I'll change it back.
<HiddenWolf> Znarl, I didn't ask you to do that either. :)
<HiddenWolf> Znarl, do what is right. I have no clue what's causing this.
<Znarl> HiddenWolf : Bug me again if it continues to happen in an hour, ok?
<HiddenWolf> Znarl, nog gonna happen. It's 12:30 at night.
<HiddenWolf> Znarl, I'm tucking in.
<HiddenWolf> g/t
<HiddenWolf> Night all.
<psusi> anyone know why aio_read is creating another thread instead of telling the kernel to do the IO asynchronously like it should?
<crimsun> how do you know that kernel thread isn't doing it?
<psusi> because when I step over the aio_read call in gdb it says a thread was created
<crimsun> oh, you're not doing kdb stuff?
<psusi> nope... I'm trying to patch dd to use aio to keep the pipeline full when doing copies with O_DIRECT
<crimsun> you might want to ask in #kernelnewbies on irc.oftc.net, then.
<psusi> hrm.... that's a channel for newbie kernel hackers?
<crimsun> the channel is misleading.
<crimsun> channel _name_
<psusi> hrm.... thanks
<psusi> hrm.. if I install the debug libc package... how can I direct a program under gdb to use it instead of the stripped one?
<ispiked> psusi: it should automatically be able to load the symbols. at least with my experience that's how it's worked.
<beezly> umm, i think i accidentally uploaded a package to upload.ubuntu.com earlier - that shouldn't upset anything/anyone should it?
<crimsun> no
<crimsun> it'll just be rejected silently unless your key is in the uploader keyring
<beezly> excellent :) - although the world is going to miss out on my crappy remote apt util! (no great loss I assure you!)
<psusi> when I do a tags-search in emacs, it finds things with that text even in comments... is there a way to limit it to things names of functions?
<Burgundavia> how did the osnews thread on Flight 1 devolve to images of Trolltech shafting KDE?
<crimsun> every thread on osnews degenerates </offtopic>
<Burgundavia> sad, just sad
<zakame> huhu
<Lathiat> hahaha
<Burgundavia> ok this one cracks me up the most
<Burgundavia> http://www.osnews.com/permalink.php?news_id=12721&comment_id=62436
<Burgundavia> freedesktop.org is a giant Trolltech conspiracy. I knew it!
<Lathiat> bahahah
* psusi is pissed off at the continued lack of proper aio support in linux
<desrt> man
<desrt> i don't understand why people take screenshots of dapper
<desrt> it's like "wow it looks exactly like the screenshots for breezy awesome!"
<wasabi> wonder if there is a way to make all toolbars use small icons
<wasabi> oops wrong window
<wasabi> woh
<wasabi> my ibook just woke up.
<wasabi> i let it fall asleep on accedent, and it just woke
<wasabi> it's never done that in linux before
<Burgundavia> why does everybody and their dog write a media player? Are there not enough in the world alrady?
<wasabi> So I was just thinking. Samba sucks.
<wasabi> I mean, by default.
<wasabi> WIsh: by default you should be able to install it and it should function just like a WIndows box.
<wasabi> Should auto hook into pam, auto generate smbpasswd, make sure it's in sync with /etc/passwd.
<wasabi> No shares enabled by default, of course, but the basic config should be in place.
<Burgundavia> then produce the patches to do that
<wasabi> Thinking about it. :0
<mpt> Burgundavia, there are no good ones, which motivates many people enough to write another one, but not enough to write a good one :-)
<Burgundavia> mpt, yes
<Burgundavia> the reality with media players is that no perfect one exists to satisfy all people
<jbailey> wasabi: The password synchronisation is a bitch.  I don't think CIFS tosses passwords around in the same format shadow stores them in.
<jbailey> wasabi: The right solution is Keberos on every machine. =)
<wasabi> No, you're right, It doesn't.
<wasabi> It's not possible to fix perfectly.
<wasabi> But a default samba install should at least inform the user to change his Ubuntu password to activate his Windows access, and automatically set up PAM to do so.
<wasabi> Basically it should assure he doesn't have to maintain two passwords.
<jbailey> Synchronisation is teh suck.
<wasabi> No way around it, it doesn't use the same hash format.
<wasabi> and it's one way.
<wasabi> For an office, yeah, Kerberos should be used.
<wasabi> For a home? Probably not.
<jbailey> Right, thus my assertion that Kerberos by default everywhere. =)
<wasabi> You tell MS that.
<jbailey> AD uses Kerberos internally.
<wasabi> AD doesn't run on my mom's computer.
<jbailey> I don't know what MS does for single sign on in home networks, though.
<wasabi> They don't.
<wasabi> They just pass hashes.
<wasabi> And then prompt if it's wrong.
<Burgundavia> or they let you in without a password
<wasabi> Only on 9*. ;)
<wasabi> Or if you enable guest.
<jbailey> But we *could* do it on home Ubuntu networks.  Opportunistically trust other machines on the local network when someone with root privs says "trust that machine"
<jbailey> And use that as an opporutnity to send principals back and forth.
<wasabi> But we "don't need to."
<Burgundavia> wasabi, you cannot disable guest on XP Home machiens
<wasabi> =)
<wasabi> http://www.microsoft.com/windowsxp/using/setup/learnmore/tips/goingsolo.mspx
<jbailey> wasabi: Sure we do.  I find it annoying that I can't trivially just browse the files on the machines in my network without setting up an account, etc.
<wasabi> I agree. We can work on that. ;)
<wasabi> But for the purposes of getting my dad sharing files with Ubuntu in 2 months.
<wasabi> Hehe.
<jbailey> Dude, anything like you're thinking of is unlikely to be dapper material.
<Burgundavia> jbailey, is there a sane fix to the browse problem?
<jbailey> Having samba suddenly twiddle pam is a bit of an invasive change.
<wasabi> I agree. It would need to be thought out better than what I just blurted out on IRC. ;)
<wasabi> Maybe a samba-workgroup-config package or something.
<wasabi> Anyways, I want it to be easy for Mortals.
<jbailey> Burgundavia: I haven't though it through, but I'm imagining something like a directory.  When you install the machine it could zeroconf or whatever and say "look, there's a network here.  Trust it?"  And then ask for a password to attach to the other machines or something like that.
<wasabi> Having some sort of better pluggable PAM infrastructure would be useful though.
<wasabi> I am so tired of hand editing these things.
<jbailey> Similar to registering a windows or netware machine into their respective security setups.
<jbailey> The ideal bit would be somehow making it version changes to the authentication database so you didn't need a single server.
<wasabi> jbailey: I like that idea... but it raises a lot of questions. ;)
<jbailey> Good.  Any idea worth having should. =)
<wasabi> In a home I still see each computer of more of an untrusting island.
<wasabi> Where any trust between them is always initiated with sceptism, etc.
<wasabi> People bringing in comps for a lan party, peopel driving by, people with work PCs
<jbailey> Right.  Have to assume this whole network has real ipv4 addresses and is sitting on the public 'net
<wasabi> Each system having it's own user base, and then, on first auth, attempting to "link" two accounts between systems.
<wasabi> First time you browse to a PC, it asks you for the user name on that PC, which you type in, and then it asks you if you want to "link" these names, or something.
<wasabi> Basically just shares some token.
<wasabi> Would let you bring in a work PC, link it to a home PCs local account, for the purposes of local PC access.
<wasabi> Obviously it would have no meaning on the work network.
<wasabi> But isn't this just like remembering passwords? :)
<jbailey> Right, but that machine should understand that there are multiple contexts.  tie that in with network manager or something.
<wasabi> Or the entire idea could just be snipped in the butt, remember passwords, but offer to update changed passwords on other systems.
<jbailey> The problems I want to solve are: 1) If I have files on my wife's machines, I should be able to get them.  2) If my wife has a file on her machine that she wants me to have, I should be able to get it without emailing it through our mail server 6000 km away
<wasabi> Why can't you just create an account on your wifes PC?
<wasabi> And access that file through that account from yours?
<jbailey> I could, but then I have to remember the password for it.
<wasabi> That's basically all we're talking about.
<jbailey> And that I created it.
<Burgundavia> wasabi, too much overhead
<wasabi> No you don't.
<wasabi> You'd have to remember that password just as much as you'd have to remember some mythical token we just talked about.
<wasabi> For any system to function you have to a) create a security token on each system involved and store with it information that the other system knows.
<jbailey> It's almost like I want a zeroconf AFS. =)
<wasabi> Creating a user with a password fulfils that.
<wasabi> Perhaps it just needs a better interface.
<wasabi> Perhaps, for instance, the first time you try to access a machine with smb:// that doesn't have a remembered password, you are asked to a) auth or b) create a new remote account
<Burgundavia> but that means you need to root account on that box
<wasabi> Yup.
<wasabi> Obviouslyl.
<Burgundavia> because I sure has hell don't want somebody random creating accounts on my box
<wasabi> Exactly.
<Burgundavia> that is way too much overhead
<wasabi> You don't want that in any system.
<wasabi> What?
<wasabi> Who else do you propose a system to allow access?
<wasabi> AI?
<wasabi> At some point a human has to step in and say Bob is allowed to access these files.
<Burgundavia> how does OS X handle filesharing in a windows network?
<wasabi> By default, like we do.
<wasabi> Prompts for password. Password gets saved.
<Burgundavia> can you see shares by default
<Burgundavia> ?
<wasabi> To share, it uses samba, but preconfigures it to allow local users access.
<wasabi> And does track password changes.
<wasabi> Doesn't share any shares by default.
<wasabi> But once you turn it on, you can browse (nothing)
<wasabi> actually maybe Home is shared
<mahangu> im just downloading the first dapper image
<mahangu> how can I get on the testing team?
<Burgundavia> mahangu, the laptop testing team?
<Burgundavia> minghu1, did you mean the laptop testing team?
<wasabi> jbailey: don't suppose you know much about kerberos eh? You talk about it a lot. ;)
<wasabi> I've got a horrid problem I'm trying to debug.
<minghu1> Burgundavia: You probably need to ask whoever you intended to ask again.  Sorry for the nick collision :-)
<Burgundavia> minghu1, ah, ok
<Burgundavia> for some reason I read your two nicks as the same
<Burgundavia> the mind is funny sometimes
* Kinnison finishes a blog posting about new aranha and heads to bed
<Kinnison> night all
<mahangu> hi, did anyone see what I wrote before?
<mahangu> (I don't wanna ask again, sorry got d/c)
<Burgundavia> mahangu, did you want to join the laptop testing team?
<mahangu_> Burgundavia, yeah, i run ubuntu on a thinkpad t42
<Burgundavia> mahangu, ok, https://wiki.ubuntu.com/LaptopTestingTeam should get you started
<Burgundavia> the key thing is that you test EVERY feature of the laptop and file bugs for everything that doesn't work
<Burgundavia> also install all Flight cds so feedback can come during the development cycle
<Burgundavia> there is also a laptop-testing list that you should probably subscribe to
<mahangu_> Burgundavia, ill do that
<mahangu_> :)
<Burgundavia> mahangu, thanks
<mahangu_> Burgundavia, for running the devel images
<mahangu_> i probably shouldn't use my primary work laptop, correct?
<Burgundavia> mahangu_, you can dual boot
<mahangu_> Burgundavia, yeah that's true
<mahangu_> it means ill have to resize the partition im currently running breezy on though
<Burgundavia> not hard, the installer can do it
<mahangu_> Burgundavia, really? without messing my data?
<mahangu_> i was told to boot xp and use partition magic
<Burgundavia> yes
<Burgundavia> no to the second part
* ajmitch will have to try & rejoin the laptop testing team soon ;)
<Burgundavia> ajmitch, you getting another one from canonical
<ajmitch> not that I've heard
<Burgundavia> ok
<ajmitch> I'd be quite surprised if I did
<ajmitch> I've been checking out what to replace it with
<mahangu_> ajmitch, you borked your lappy?
<ajmitch> no, it was stolen
<mahangu_> whoa
<mahangu_> :S
<mahangu_> from where?
<ajmitch> from UBZ, at the hotel
<mahangu_> UBZ>
<mahangu_> ?
<ajmitch> UbuntuBelowZero, the developer summit we just had
<mahangu_> ah
<zakame> hi all! :D
<zakame> just to make sure, but is build-depending on libgamin-dev preferable to build-depending on libfam-dev?
<Burgundavia> bon soir, neuralis 
<neuralis> Burgundavia, g'day, sir
<Burgundavia> have you started in on the server testing framework yet?
<neuralis> Burgundavia, nope, the specs are in mdz's queue
<Burgundavia> ah
<neuralis> Burgundavia, i want to make sure he's happy with them, after which i'll also mail laptop-list re: using the backend for laptops 
<Burgundavia> excellent
<neuralis> Burgundavia, and i've mailed malc re: laptop certification, without response so far
<Burgundavia> have you spoken with mjg59 regarding what specifically he needs from the reports?
<Burgundavia> and if you have, is that recorded somewhere?
<neuralis> no -- i want to address any concerns mdz has *first*, and then fan out and talk to the rest of the people
<Burgundavia> ok
<neuralis> no worries, it's on my list, it'll get done
<mojo85> I suggest the 'Add Application' app and 'Sumit Hardware' app should use icons of the new naming scheme (Tango project)
<pef> hello
<MagnusR> mag runes
<MagnusR> foobar
<MagnusR> Wrong window, sorry!
<neuralis> JaneW, we need to make ubuntu plushies. cute, stuffed animals that i can give to people. anything in the works? :)
<Lathiat> neuralis: we could have little plush dragons ;)
* Lathiat hides from the raging mob
<neuralis> Lathiat, +1. but i'd settle for a duck, if it were dapper enough.
* Lathiat grins
<\sh> infinity / lamont-away: could one of you two check where the last upload of armagetron is hiding? latest uploaded version is 0.2.7.0-1.1ubuntu1 and it didn't appear in the buildlogs
<\sh> elmo: please sync dnprogs from unstable, dropping ubuntu changes ok
<jbailey> wasabi: I've done two smallish kerberos deployments (about a dozen servers in each one.  One with about a hundred users, one with three users and a whole bunch of service principals)
<jbailey> wasabi: I have to Oreilly Kerberos book here if you have specific questions.
<ptlo> neuralis_ hi :)
<neuralis_> ptlo, hey
<slomo_> BenC: the ppc kernel build failure didn't disappear with the new binutils :(
<BenC> slomo_: assuming I can keep kernel-package updated to the latest ppc/powerpc changes, it will build in -4.4
<BenC> I disabled HMT and NUMA for ppc64 to get that building
<slomo_> BenC: ok, thanks... when can we expect -4.4?
<BenC> tomorrow
<BenC> -rc2 was tagged today, so seems like a good time (ppc64->powerpc merge is done now too, so it helps a lot)
<slomo_> hehe, maybe i can finally try the newest bcm43xx driver then ;) seems like they made great progress in the last days
<HiddenWolf> BenC, anything cool in -4.4?
<BenC> hiddenwolf: devmem patch from fedora, enabled ACPI_BLACKLIST=2000, should build on sparc and ia64 now
<BenC> lots of little changes aswell
<HiddenWolf> BenC, sparc and ia64 are on the road to being officially supported?
<BenC> no idea, but I know that fabbione is pushing to get sparc to be a first class citizen
<fabbione> HiddenWolf: not yet no
<HiddenWolf> I'm amazed that interest for IA64 is so consistent.
<fabbione> there is nobody other than lamont giving love to ia64
<fabbione> HiddenWolf: who is asking for it?
<HiddenWolf> fabbione, ah, no. not specifically.
* BenC would like his i2k to be useful, but that's not asking much
<fabbione> BenC: i am getting an ia64 soon
<HiddenWolf> fabbione, but afaik IA64 isn't called itanic for no reason. :)
<fabbione> HiddenWolf: you mean Titanic?
<fabbione> ;)
<BenC> with all the support behind x86-64, I don't think ia64 is viable anymore
<HiddenWolf> BenC, anandtech had an article on why IA64 was the most promising architecture, beating Sparc and PPC and X86. 
<HiddenWolf> BenC, that was on technical merit tho, not viability.
<BenC> hidden: it's a marketing failure though
<HiddenWolf> BenC, Both a marketing and a sales failure, really.
<fabbione> HiddenWolf: well..  sparc is still used a lot more compared to ia64
<BenC> sparc64 would be a lot better if 64-bit code actually ran decent compared to 32-bit code
<BenC> as it is, 64-bit is reserved for when you have to have that much addressing
<BenC> otherwise it's a performance hit
<HiddenWolf> fabbione, anand's point was more: It'll scale better to future performance.
<fabbione> HiddenWolf: sounds like they did send a lot of ia64 to these people writing the review
<BenC> fabbione: uploading new kernel-package now
<fabbione> BenC: cool
<fabbione> BenC: is it going to build on sparc?
<fabbione> ah meh
<fabbione> never mind
<doko> nice, dapper_probs lists the whole archive as uninstallable
<HiddenWolf> doko, why?!
<fabbione> BenC: i read "new kernel source"
<fabbione> HiddenWolf: ia64 is taking over archive.ubuntu.com!
<HiddenWolf> fabbione, cool. :P
<fabbione> impressive
<fabbione> out of 6 arches
<doko> HiddenWolf: tell me
<fabbione> sparc is the one that can still install more than all the others :D
<BenC> fabbione: have you tried compiling -4 on sparc yet?
<fabbione> BenC: no
<BenC> I should hook up my e3k in here just temporarily tonight
<fabbione> i did let the buildd catch up
<HiddenWolf> doko, have you upped OOo2 final to Dapper yet?
<doko> HiddenWolf: go for it if you want ;-P
<HiddenWolf> doko, ehm...
<Kamion> doko: uninstallables> please rebuild python against openssl 0.9.8
<Kamion> python2.4 that is
<doko> ahh, ok ...
<Kamion> we need to get openssl097 into the archive though, so that this isn't so destructive
<Kamion> elmo: should openssl097 still be listed as broken?
<Kamion> elmo: I think probably not - if you could remove it from josie's broken list and do an auto-sync, the uninstallables list would appreciate it :-)
<Kamion> elmo: in fact it probably won't autosync because it's modified - I'll merge
<Kamion> doko: ok, I've uploaded a merged openssl097; the world should look somewhat better once that makes it into the archive
<Kamion> we should still get rid of libssl0.9.7 linkage where possible
<BenC> it's bad when you have to get a dolly to move a computer from one side of the room to the other
<mahangu> BenC, eh?
<ogra> BenC, thats not bad ... bad is if you have to get a team *and* a dolly to move it 
<mahangu> if I have a development idea (which i have half implemented), who can I talk to?
<BenC> worst ever for me was that the dolly wasn't strong enough to hold the computer
<BenC> took six people, and the computer was never actually lift off the ground, we had to lean it into a trailer to transport it
<HiddenWolf> mahangu, just talk here. :)
<mahangu> ok
<mahangu> well, i haven't written a primer or anything
<mahangu> but im working on this live support system for distros
<mahangu> basically, i noticed that many new users dont know how to get on IRC
<BenC> mahangu: you must pass the six tests of Ubuntu, and climb to the highest peak in Africa :)
<mahangu> so I figured, why not write a nice front end for it?
<mahangu> im new to perl and linux, but i did a hack job, and got a working prototype
<doko> Kamion: uploaded python2.4 as well to link against 0.9.8
<mahangu> it's basically a bot that interfaces between a thin GTK client and a support channel
<Kamion> mahangu: the biggest problem with that sort of thing is generally setting up an appropriate support channel; #ubuntu is too busy and basically inappropriate for that sort of thing
<mahangu> GTK client connects to IRC network --> spews data in channel (this is basically username, contact email and help request)
<mahangu> Kamion, I'm aware of that :) just getting there
<Kamion> doko: thanks
<mahangu> so basically, there will have to be a seperate channel for it
<mahangu> like #distroname-support
<mahangu> so far, the folks at Taprobane (www.taprobane.org) , a local GNU / Linux distro seem to like the idea
<mahangu> and im working on it
<mahangu> i havent implemented a client yet
<mahangu> but the bot so far
<mahangu> 1) scans the support channel for activity
<mahangu> if there is activity, channels request there
<mahangu> 2) if no activity sends to support-mailing-list
<mahangu> any thoughts?
<mahangu> i was just thinking while handing out Ubuntu CDs the other day that none of the people I was giving them to would even know what IRC was
<Kamion> I'm wondering if it's complementary to https://launchpad.net/support, or if the two fill basically the same use case
<mahangu> so their support was minimal
<Kamion> well, let's say https://launchpad.net/distros/ubuntu/+tickets, better URL
<mahangu> Kamion, yeah, id say it'l work really well with that
<mahangu> again, i have some pretty sparse code on the Taprobane CVS
<mahangu> anyone think it's worth a shot?
<mahangu> im not really an experienced coder, and have never been to CS school
<mahangu> but im quick to learn and am willing to dedicate a big portion of my time to see this through
<Kamion> my main concern is that IRC is actually kind of a poor medium for real customer support
<Kamion> are you sure you want to use it as the backend?
<mahangu> Kamion, isn't it a stable means of communication? rather than doing all that handshaking on our own?
<Kamion> it's very vulnerable to noise, inappropriate comments, etc.
<mahangu> Kamion, yes
<mahangu> i have a solution (I think)
<Kamion> and you have to sit online for ever to get a response, which is pretty awkward if you have a pay-for line
<mahangu> Kamion, yeah that's why it sends unanswered requests to the mailing list
<mahangu> the client will tell the user
<Kamion> it's better if responses can come back to you asynchronously and you can log in to find if somebody's answered
<mahangu> "Sorry looks like no one is aorund, I've sent your request to the mailing lit"
<mahangu> Kamion, hmm, that would be neat
<Kamion> why not just do everything through a mailing list then? it's confusing to have two means of communication
<mahangu> Kamion, oh right
<mahangu> so a mailing list front end
<mahangu> that's a lot of text manip though
<Kamion> or, as I say, the Launchpad support tracker - you have the asynchronous communication there
<mahangu> stripping mail signatures etc?
<mahangu> Kamion, that is web based, right?
<Kamion> and if you talked to the folks on #launchpad they might be able to expose an XML-RPC interface for you
<Kamion> right
<mahangu> i was thinking of a GTK application
<mahangu> of course
<mahangu> yes, i understand what you are saying
* mahangu ponders
<mahangu> what is the (average) turn around time for a launchpad reply?
<Kamion> I'm not saying you shouldn't pursue an IRC-backed option, just suggesting that you might not want to get too hung up on IRC for this, that's all :)
<Kamion> no idea - it's never actually been advertised anywhere so the people using it are the people who happen to have come across it
<Kamion> (so far)
<mahangu> yeah I understand
<mahangu> Kamion, where can I find one or more devs with a little free time who might like to run through some ideas with me?
<mahangu> Kamion, http://cvs.taprobane.org/viewcvs.py/taprobane/hermes/hermes.pl?rev=1.7&view=log
<Kamion> for launchpad, or in general?
<mahangu> Kamion, well in general
<Kamion> hmm, I guess here's as good as any for IRC, or try the ubuntu-devel@lists.ubuntu.com mailing list; it's always better to find somewhere specific if possible though
<mahangu> Kamion, thanks, ill try
<Kamion> (I'm mostly doing other things at the moment though, I'm afraid)
<mahangu> np
* desrt head-scratches
<mahangu> back
<\sh> elmo: please sync grip from unstable, ubuntu changes can be dropped thx
<desrt> so what's the story on 2.6.15?
<wasabi> Once upon a time, a long time ago, there was a kernel.
<\sh> elmo: please sync k3b-i18n from unstable, overriding ubuntu changes ok
<desrt> no.  seriously
<desrt> there are a few bugs that i'm waiting to see if the new kernel will fry
<HiddenWolf> desrt, it's in, but unstable.
<desrt> so why doesn't it show up on apt-get dist-upgrade?
<\sh> elmo: please sync kdirstat from unstable, overriding ubuntu changes ok
<fabbione> desrt: because PPC is still FTBFS on the buildd
<fabbione> desrt: it should be fixed with tomorrow
<fabbione> 's upload
<desrt> ah.  excellent
<desrt> can you do me a favour, fabio?
<fabbione> possibly
<desrt> view this document :)
<desrt> http://desrt.mcmaster.ca/random/new-key.asc
<desrt> also: explain why there are 2 'b's in your name :)
<fabbione> the second B stands for Big
<fabbione> like Big Fabio -> fabbione in italian
<desrt> ah.  i see.
<tseng> desrt: he has a tshirt that says Ride The Italian Stalion
<fabbione> no
<tseng> there is no modesty to be had here
<fabbione> it says: "Italian Stallion" with Ferrari's font
<desrt> i should count my blessings that i didn't see it :)
<tseng> haha
<jbailey> fabbione: So what should elmo's shirt say?
<jbailey> What's the elmo doll called in Italy? =)
<fabbione> jbailey: "I ride katie?"
<fabbione> dunno..
<fabbione> i never seen that dolls in italy
<desrt> jbailey; i shall be in montreal in january
<jbailey> desrt: Why are you coming here in the coldest month of the year? =)
<desrt> jbailey; it's called CUSEC
<desrt> canadian university software engineering conference
<desrt> at concordia/mcgill
<desrt> a lot of my friends are going and they didn't have a very difficult time convicing me to come along
<fabbione> desrt: dude..
<fabbione> your new key is sick
<desrt> fabbione; i love it :)
<fabbione> 3360R ???
<jbailey> desrt: Ah, nice.  I should poke my head in there.
<fabbione> make it 4096 and get over it
<desrt> jbailey; you certainly should
<desrt> fabbione; 4096 is for posers :)
<fabbione> yeah right
<fabbione> you are jalous that my "key" is bigger than your
<desrt> i wanted more security without doing the cliche thing of choosing the biggest possible key
<desrt> so i put in 3333
<desrt> and it rounded up to 3360
<jbailey> 3333 rounded to 3360?
<jbailey> This isn't on an old style Pentium, is it? =)
<desrt> by gpg logic, yes
<desrt> old-style pentium 4 :)
<desrt> fabbione; so i guess you have a 4096bit rsa key?
<fabbione> desrt: 2 of them
<fabbione> + a standard 1024 DSA
<desrt> fabbione; you deserve the second 'b'
<\sh> elmo: please sync gnome-themes-extras, overriding ubuntu changes ok...thx
<fabbione> desrt: i know i do :)
<desrt> an interesting dos attack would be to create a new strong set
<desrt> just crank out 100s of thousands of keys and have them all sign each other
<desrt> then upload the resulting mess to some poor keyserver
<fabbione> desrt: you would only notice a suddenly increase of keys on the keyservers
<fabbione> it won't affect the strongset
<desrt> fabbione; yes it would
<fabbione> nopr
<fabbione> nope
<fabbione> only if one of the key is crosssigned with the strongset
<desrt> because my new group of keys would be the new strongset
<fabbione> nope
<fabbione> the strong set is not detected
<desrt> "the strongset" is defined as the largest set
<fabbione> the starting point of the strong set is known :)
<fabbione> this is a limitation in basically all the tools that do key stats
<Kamion> desrt: it's only a DoS attack on people who don't hardcode the strong set. :)
<desrt> the only way to fix that would be to say that the strong set is the set with my key in it
<desrt> :)
<Kamion> so more a Denial of Theory attack
<fabbione> Kamion: exactly
<desrt> there exists, i understand, another set of size 98
<desrt> someone needs to cosign those guys in :)
<fabbione> desrt: see.. the point is that prople like you tend to disappear very fast from the net after an attack like that
<fabbione> desrt: there are over 2M keys on the keyserver and afaik the strongset is ~200K
<fabbione> so there is more or less a ratio to 1:10
<desrt> that's weird
<fabbione> no it's not
<fabbione> most of the keys in there are single keys
<desrt> it means that only 1 in 10 keys are effectively signed
<fabbione> that never signed or being signed
<desrt> so weird
<desrt> anyway... have you noticed with rsa keys
<fabbione> i don't find it weird
<desrt> some keyservers think that they have different fingerprints
<fabbione> a lot of people upload keys only becuase they have been told to reading the gpg howto
<fabbione> and gave away the key one minute later
<desrt> some of the web-based interfaces seem to use md5 checksums for rsa keys
<fabbione> desrt: yeah.. old format
<desrt> kinnison bought me a lovely purple book in montreal
<desrt> i've written my key fingerprint inside of the cover in sha1 format
<desrt> i really hope i don't have to erase it :p
<fabbione> eheh
<fabbione> http://keyserver.kjsl.com/~jharris/ka/2005-11-13/top50table.html
<fabbione> desrt: ^^
<fabbione> just about in the middle
<desrt> Fabio M. Di Nitto
<desrt> mako is quite high on the list, hm?
<fabbione> yeah
<Treenaks> whee, I'm 849
<fabbione> but mako also travels N times as much as i used to
<desrt> i wonder how i can determine my rank
<desrt> my msd is a rather pathetic 5.something
<desrt> actually
<desrt> interesting
<desrt> if you sign my key with a key that has MSD x
<desrt> then my key automatically has a MSD of at most x+1
<fabbione> desrt: right
<desrt> cool
<desrt> sign me up!
<fabbione> so in the next calculation you will jump up to death
<desrt> death?
<desrt> you are 3.8199
<desrt> so i will probably be very slightly less than 4.8199
<fabbione> i am 25, 271, 751
<sivang> desrt: what kind of book is it?
<fabbione> and you got signed by all of them
<desrt> sivang; just a notebook
<desrt> er
<desrt> did you just upload to the keyserver?
<fabbione> desrt: look at your email
<sivang> desrt: ah , I thought some interesting technical book :)
<fabbione> + you need to sign me too
<sivang> fabbione: keysining over IRC ? ;-)
<desrt> ah
<desrt> excellent
<fabbione> sivang: no
<fabbione> i had his documents and keys already
<desrt> gpg:         new signatures: 3
<desrt> gpg: sending key AFAA6FF6 to hkp server keyserver.ubuntu.com
<desrt> thanks
<fabbione> desrt: you need to sign my keys
<desrt> just let me verify that the keys that just signed me are the keys that i signed with my old key :)
<desrt> wait
<fabbione> oh btw
<desrt> did you accept my signatures?
<fabbione> your script is broken
<desrt> or ignore them?
<fabbione> no i couldn't
<desrt> it's scott's script :)
<fabbione> gpg was complaning about the mail format being broken
<fabbione> and didn't import
<desrt> odd
<fabbione> i use scott script
<sivang> desrt: use Kinnison's , they are great :)
<fabbione> that was not scott's script output
<desrt> daniel's are so overkill :)
<desrt> weird.
<desrt> i made some very minor modifications to it
<fabbione> well.. fix them
<desrt> like having gpg ask me the passphrase each time instead of the perl script doing it
<desrt> and if i say something other than '2' it asks me "are you sure?"
<desrt> nothing to do with the format of the mail
<fabbione> well the output mail was somehow corrupted
<fabbione> and i couldn't import them
<desrt> and i signed your key before the mods :)
<desrt> hmmmmm
<desrt> this is a problem
<desrt> because i am no longer sure what keys i signed
<desrt> lemme go through my things and see if i can find the piece of paper you gave me
<fabbione> desrt: btw... with my signature, you will be 4 hops from Linus :)
<desrt> linus sucks.  i want rms!
<desrt> :)
<\sh> hmmm...
<desrt> (i'm already 3 hops from rms)
<\sh> is collecting "gpg signatures" something like collecting autographs from VIPs?
<desrt> absolutely :)
<fabbione> \sh: gpg is more fun
<sivang> \sh: judging by the current discussion, seems so :)
<desrt> with gpg you can publish your signature collection to the world to brag
<desrt> without fear of someone stealing the signatures
<sivang> desrt: how come ?
<desrt> fabbione; so why 3 keys?
<fabbione> desrt: 1 (old) debian 2 (new) debian 3) canonical/ubuntu
<\sh> hmmm...then I'm proud to have actually a signature of kinnison and lamot...which gives me a real hard on ... but linus or rms..who wants them? ,)
<fabbione> desrt: but i still use all 3 of them
<\sh> lamont even
<desrt> Kinnison; !
<desrt> kinnison and keybuk said they would sign my keys, accepted my fingerprint and have not yet done so!
<fabbione> kids...
<fabbione> desrt: gpg keysign is not "push me to sign your key"
<fabbione> it happens when it happens
<fabbione> it's not like sex that needs to finish asap ;)
<desrt> you sound very zen :)
<fabbione> i have learned that
<fabbione> it took me a year to get my key signed by Martin Schulze
<desrt> who is that?
<fabbione> just because he kept forgetting
<fabbione> but he did
<\sh> fabbione: "needs to finish asap"? 
* desrt smiles
<fabbione> sex is an obsolete and ancient form of fum
<fabbione> fun
<fabbione> it's much better to play PS2
* desrt blinks
<fabbione> ehehhe
<desrt> your wife agrees?
<fabbione> ok i am off to spend sometime with my wife
<desrt> hah!
<fabbione> desrt: sometimes ;)
<desrt> enjoy the playstation
* \sh has neither sex or a ps2 ... so I'm a real weirdo
<fabbione> thanks
<fabbione> \sh: than you are screwed
<\sh> which reminds me, that this is real OT 
<fabbione> \sh: on a sunday evening?
<fabbione> OT?
<fabbione> ok
<\sh> fabbione: i'm not screwed
<fabbione> is there anybody in here that wants to talk about Ubuntu Devel? ;)
<desrt> i think i've thought about a way to hax0r Kinnison's scripts
<fabbione> desrt: you are welcome to try with one of my keys
<fabbione> but please don't flood me with mails
<fabbione> just use the one with the less amount of UID
<desrt> no... i mean getting daniel to sign a false uid
<fabbione> you can't
<desrt> he puts the fingerprints of keys that he trusts
<desrt> and reruns his script every now and again so that if a new UID got added it sends an email there
<sivang> desrt: I have my key signed by daniel, but still hadn't had chance to sign his ...:-/ It's been SO hectic in work since I returned from UBZ, so much backlog
<fabbione> yeah
<desrt> so just add a new uid with a valid email and a fake name
<fabbione> desrt: nope..
<fabbione> that doesn't work
<desrt> his script checks the name?
<fabbione> becuase the script checks if the UID has been signed by the master key
<desrt> yes
<fabbione> you would need to trick a lot the key to do so
<desrt> i'm saying adding a fake uid to my own key
<desrt> so i have 2 uids
<desrt> Ryan Lortie <desrt@desrt.ca>
<desrt> Jesus H. Christ <jesus@desrt.ca>
<fabbione> even so, the fake uid is still binded to your primary key
<desrt> i bet daniel's script would sign the 2nd uid
<fabbione> even if you kill Ryan Lortie
<fabbione> you can still see it in the key
<desrt> wrong
<fabbione> desrt: yes it will sign
<fabbione> desrt: you are wrong
<desrt> since i know p and q i can remove ryan lortie from the key
<fabbione> you can revoke the uid
<desrt> i can generate a new key without 'ryan lortie' in it that has the same fingerprint
<fabbione> you can't delete it forever
<fabbione> desrt: good luck :)
<fabbione> let me know when you have done ;)
<desrt> i don't want to do it
<fabbione> gotta go
<desrt> i'd totally fuck up my key in the process :)
<fabbione> later
<desrt> ciao!
<\sh> fabbione: hf
<Kamion> fabbione: oh, for the sake of some actual relevant conversation :-), I've implemented most of the stuff you need for whatever that server rescue mode thing was
<sivang> Kamion: is it GUI in any sense?
<Kamion> no
<Kamion> if you want that, use a live CD
<Kamion> rescue mode is not designed for prettiness, it's designed for "oh my god my system is hosed help me"
<loogaroo> hi
<sivang> Kamion: ah I see. Me and Corey discussed that it would be nice to have a GUI rescue mode for a "desktopish" installation, for the sake of "regular users" (tm)
<sivang> can anyone comment if I'm better off using glade-gnome-2 for doing a GUI app in PyGTK or gazpacho?
<slomo_> sivang: whatever appeals more to you... both create valid glade files so...
<sivang> slomo_: ah nice, I was afraid there were some incompatibilities that might have prevented use of one over the other
<\sh> but gazpacho is sometimes segfaulting...when it comes to glade glade files
<sivang> \sh: what's glade glade files?
<\sh> sivang: glade-2 .glade files
<sivang> \sh: aren't we always using glade-2 .glade files? (or is gazpacho producing glade-1 files?)
<\sh> sivang: well..actually we're using xml files (which are .glade files) but gazpacho sometimes doesn't work as expected..it crashed e.g. when I wanted to edit gajims glade file with it..
<sivang> \sh: I see thanks for the tip. I'm already pretty used to working with glade-2 so I'll default to that :)
<Kamion> sivang: that use case is fulfilled by the live CD
<Kamion> we don't have resources to help out with the graphical installer at the moment, unfortunately
<sivang> Kamion: I understand. Not a problem, good the know the use case is taken care of.
<\sh> hmmm....when fabbione is only 4 hops from linus...
<\sh> i'm only 3 hops from linus ,(
<\sh> ,)
<sivang> \sh: then if you sign my key I'm 5 hopes from linux?
<sivang> err, s/linux/linus/
<slomo_> BenC: is -4.4 including the softmac patch? you can get it from here ftp://ftp.berlios.de/pub/bcm43xx/
<BenC> I just synced the latest svn today, saw the softmac log entry
<slomo_> the stuff in svn uses softmac but the patch from that ftp is still needed afaik
<\sh> killall -FIX  buildd 
<Kinnison> desrt: so impatient
<desrt> SIGN MY KEYS, BITCHES!!!
<desrt> <ahem>
<desrt> btw.  did you read my hypothetical attack against your keysign scripts?
<Kinnison> no, where's that?
<desrt> basically, it goes like this:
<desrt> i add a new uid to my key "Jesus H. Christ <jesus@desrt.ca>" and upload it to the keyservers
<desrt> then a few months later you re-run your script
<desrt> (implied: i can receive email at jesus@desrt.ca)
<Kinnison> Nice try
* Kinnison did say, very clearly, "READ THE OUTPUT OF 'make xref' CAREFULLY"
<desrt> hm.  fair enough :)
<\sh> I didn't know that  Jesus had a middle name
<\sh> ,-)
<slomo> daniels: will you update the whole driver stuff to 7.0 for dapper? or will we stay with 6.8?
<Kamion> slomo: it's mostly updated already but FTBFS due to a glibc bug, which is being fixed
<slomo> Kamion: ok, thanks... btw, the new binutils seem to have a bug... or cairo has... debian bts #340073
<Kamion> slomo: thanks, RC bugs from Debian are already automatically imported into bugzilla for us
<Kamion> (I saw that bug in my Ubuntu bugs folder a few minutes ago, so I know it worked ...)
<slomo> ok ;) but it's a bug in binutils imho... only shows up in cairo and they worked around it
<Kamion> ok, I'm not the binutils maintainer so you're talking to the wrong guy ...
<elmo> slomo: no, it's not a bug in binutils
<elmo> it a) doesn't only show up in cario, and b) is a genuine bug in cario and the other places it's shown up (e.g. glibc)
<slomo> elmo: ok... thanks for clarifying... so an INT_ prefix is dropped by binutils? or what was the mistake?
<Kinnison> desrt: Hmm, the xref wants to sign your key
<Kinnison> desrt: I think I'll let it, this time :-)
<Kinnison> desrt: chocks away
<desrt> thanks
<desrt> i do think i've signed your key... but it's not on the servers
<Kinnison> I have a bunch of key stuff to merge
<desrt> gotcha.
<Kinnison> 33 mails
* Kinnison fetches 'em
* desrt wonders if your dob on your key is for extra security or so people will never forget your birthday :)
<Kinnison> mostly it's because I put it there a long time ago thinking it was a good idea, and then didn't want to deal with revoking the uid etc
<desrt> ah.  i see.
<desrt> do you know if there is a program that is better at manipulating ascii-armor than gpg?
<Kinnison> manipulating in what sense?
<desrt> like something that will show you what information a particular sniplet contains and let you add/remove bits to it
* Kinnison merges 32 signatures
* desrt feels his msd drop ever so slightly
* Kinnison gently cradles desrt's msd
<desrt> :)
<desrt> wanna hear something weird?
<desrt> a bunch of the keyservers out there refuse to call my key 'afaa6ff6' and call it some other thing instead
<desrt> they use md5 as the hash, i think?
<Kinnison> seems unlikely
<\sh> Kinnison: somehow evolution don't want to play nice..now i have to copy'n'paste your mail into vi and save the file..
<\sh> Could not parse S/MIME message
<\sh> gpg: armor header: Version: GnuPG v1.4.1 (GNU/Linux)
<desrt> http://wwwkeys.ch.pgp.net:11371/pks/lookup?op=index&search=desrt
<desrt> observe
<Kinnison> \sh: odd, evo on breezy seems fine with them
<desrt> pub  3360/4BC2F68B 2005/11/05 Ryan Lortie <desrt@desrt.ca>
<Kinnison> \sh: then again, I tend to paste them into gpg --import anyway
<\sh> Kinnison: evo on dapper doesn't like it
* Kinnison blames new evo :-)
<Kamion> desrt: bug handling keys of your wacky key length, maybe? (random uninformed guess)
<desrt> Kamion; that's one of my guesses too except that somewhere i saw that it was using an md5 for my key fingerprint
<desrt> (or md5, i assume... it was 128bits)
* desrt has a tendancy to exercise bugs in software :)
<Kinnison> desrt: It may be a hiccough in RSA handling
<Kinnison> I.E. the keyserver may assume an RSA key is not v4
<desrt> nod
<Kinnison> v3 keys had md5-looking fingerprints
<Kamion> desrt: first, get it straight - are you wondering about the keyid, or the fingerprint?
<desrt> Kamion; both
<desrt> Kamion; the keyid, i think, is incorrect by virtue of coming from a fingerprint done with a different hash
<desrt> http://wwwkeys.ch.pgp.net:11371/pks/lookup?op=vindex&search=desrt%40desrt.ca&fingerprint=on&exact=on
<desrt>      Key fingerprint = FA 2C B4 95 EC 16 6F 0C  0E CD AA FB E9 A6 38 A1
<desrt> weird, eh?
<desrt> does the proper sha fingerprint for the DSA key but does (i guess md5?) for the RSA
<Kamion> yes, as Kinnison says, RSA v3 key fingerprints were MD5, RSA v4 fingerprints are SHA-1
<desrt> i wonder, then... if someone got my rsa key with a v3 version of pgp might they try to encrypt to me using my signing key? :)
<Kamion> but you should really ask the keyserver admins - I doubt many people here can do more than guess
#ubuntu-devel 2005-11-26
<doko> elmo: please sync gdb, overwriting ubuntu changes
<paulproteus> Out of curiosity, do you guys plan to stop using an expired SSL certificate, and/or ship the SSL certificate for the Ubuntu Wiki and Bugzilla with Ubuntu?
<paulproteus> 'Cause that'd make life convenient if you would do both. :)
<ispiked> paulproteus: hahah.
<paulproteus> I mean, neither seems very hard, right?  And it makes Ubuntu look so unprofessional the way it is now.
<psusi> it's a self signed certificate anyhow... having it be expired is just silly
<psusi> the site admin needs to just reissue it
<Jimbob_> psusi: Didn't Shuttleworth found Thawte?
<daniels> yes
<Jimbob_> :-)
<ispiked> haha.
<paulproteus> Jimbob_: Hah, you're right. :-)
<paulproteus> psusi: They could ship the server certificate with Ubuntu so at least Ubuntu users wouldn't be annoyed with the certificate message each time.
<psusi> I have no idea who shuttleworth is
<psusi> paulproteus, even if shipped, if it is expired, the browser still complains
<psusi> having the cert already installed as trusted just makes it not complain that it isn't signed by a trusted CA
<paulproteus> psusi: Mark Shuttleworth founded Canonical, the company that funds Ubuntu development.
<psusi> ohhh... that guy ;)
<paulproteus> psusi: Right, I know.  That complaint is a pain.  It being expired makes another complaint, it's true.  I figure they could easily solve this problem by (1) shipping the cert as trusted and (2) renewing the server cert.
* psusi wonders just why the hell increasing the number of overlapped aio requests would LOWER throughput
<psusi> shipping it of course, would only solve the problem for people already using ubunu ;)
<paulproteus> psusi: "Use our distro!  Going to our web site sucks less using our distro!" :)
<psusi> lol
<Keybuk> GOOD MORNING! :D
<jsgotangco> morning
<highvoltage> morning.
<highvoltage> Keybuk: please, not so loud on a monday morning ;)
* desrt moans
<Keybuk> appreciately, I trust?
<desrt> heck no
<desrt> i'm marking.  i've had enough
<desrt> most people are failing
<Keybuk> marking?
<desrt> i need to go to bed
<desrt> exams
<desrt> the class did bad on the last 2 exams
<Keybuk> ahh
<desrt> so we made the test really easy this time
<desrt> and they're still failing :(
<desrt> 45% average so far overall
<Keybuk> I'd've been happy with 45% when I was at school ;)
<highvoltage> ah, so there's hope for me then :)
* highvoltage got 17% for a math test once
<highvoltage> and..
* highvoltage loves maths
<Keybuk> I got 17% for Computer Science
<desrt> the question worst done thus far is the big coding question
<desrt> "Design and implement a function that splits a list into two sub-lists, one containing all the even numbers from the original list, and the other all the odd numbers from the original list (both in ascending order).  Carefully document the function interface."
<desrt> (given datatypes for linked lists of integers)
<desrt> 36% average on this :)
<Keybuk> sorted(num for num in list if not num % 2), sorted(num for num in list if num % 2)
<Keybuk> easy :p
<desrt> you have that your input list will be sorted
<desrt> (the datatype declarations have a comment saying that lists of this type shall -always- be sorted)
<Keybuk> that's even easier then
<desrt> indeed
<Lathiat> desrt: wahh
<Lathiat> how is that hard?
<desrt> haskell: split list = (filter even list, filter odd list)
<desrt> Lathiat; it's not
<jamesh> desrt: Keybuk's routine without the sorted() calls will be equivalent to the haskell
<jamesh> desrt: since it uses generator expressions, it should also work with lists of infinite length :)
<desrt> jamesh; as will the haskell version :)
<jamesh> that's what I mean by it being equivalent
<Keybuk> hell, it's a C one-liner too, depending on the list API;  for (num = FIRST(list); num; num = NEXT(list, num)) ADD(num % 2 ? even_list : odd_list, num);
<desrt> cheap.
<Lathiat> Keybuk: now, carefully document that ;)
<Lathiat> and remember it must have at least 3 classes
<jamesh> Keybuk: that won't work for infinite length lists though ...
<desrt> if someone wrote that i'd have failed them :p
<Keybuk> Lathiat: I said C, not C++
<Keybuk> jamesh: why not?
<Lathiat> Keybuk: then it needs to have at least 3 functions :)
<Lathiat> i hate it when my uni does that
<Lathiat> makes me pointlessly split things up
<Keybuk> Lathiat: this is probably why I failed compsci
<jamesh> Keybuk: because it won't finish
<Lathiat> just so its 'modularized'
<desrt> incidentally, they can do it all in one function
<Keybuk> jamesh: nor will the Python
<desrt> and the best solution i've seen was like that
<desrt> but most of the 'working' solutions have a simple 'split' function and an auxiliary (sorted) 'insert' or 'append' function
<jamesh> Keybuk: the generator expression will return as many elements as you ask for
<desrt> one person (attempted to) use cons and reverse
<ajmitch> hi pitti 
<desrt> hi ajmitch 
<pitti> Good morning everybody
<siretart> good morning, Martin!
<pitti> Hi desrt
<desrt> good night for me :)
<ajmitch> hello desrt :)
<desrt> pitti; you missed my beautiful rant about how the youngin's these days don't know their respect
<desrt> and by respect i mean "c"
<pitti> desrt: meh?
<dholbach> good morning
<desrt> pitti; marking exams.  it's not going well :p
<pitti> Hi dholbach 
<desrt> i want christmas
<desrt> g'morn daniel
<dholbach> hi pitti 
* dholbach hugs derekS 
* dholbach hugs desrt 
<dholbach> :)
* desrt is hugged
* pitti hugs dholbach 
* Keybuk hugs dholbach and desrt
* desrt hugs pitti
<dholbach> woohoo :)
<dholbach> how are you all?
<desrt> woh.  hug party.
* dholbach hugs Keybuk 
<dholbach> this is the HUG day :)
* pitti hugs back desrt
* desrt withholds keybuk's hug until his key is signed :)
<siretart> lol
<siretart> conditional hugs, intersting approach ;)
<desrt> no lapdance either
* desrt goes to bed now.  night guys :)
<Keybuk> desrt: I did sign it :)  you need to recv-key
<slomo_> gn8 desrt ;)
<desrt> oh.  elite.
<highvoltage> why is it hugday?
<Keybuk> because hugging rules?
<desrt> Keybuk; against which keyserver?
<desrt> keyserver.ubuntu.com says key afaa6ff6 is unchanged
<desrt> anyway.  we're short on time here since i really do need to sleep
* desrt hugs scott
<desrt> 'n8' everyone.
<dholbach> night ryan
<Keybuk> ya know how we have days and weeks where we turn off mom and let everyone catch up?
<Keybuk> we should do the same for Bugzilla
<dholbach> yeah
* highvoltage hugs the badger
<dholbach> we'll have a bug day on thursday
* dholbach writes the announce
<Keybuk> let's have a hug day instead
<siretart> woah, new xserver-xorg upload! :)
<siretart> lets check the buildlog..
<siretart> damn. still ftbfs, but this time because of syntax errors, not because of missing includes. (improvement?)
<nomed> hi all
<nomed> where can i find infos about how to report a bug?
<jsgotangco> nomed, bugzilla.ubuntu.com
<nomed> and what's the best way of fill a bug?
<dholbach> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
<nomed> jsgotangco, should i include a patch?
<nomed> mkiniramfs is brocken
<dholbach> nomed: if you can, that's excellent
<jsgotangco> https://wiki.ubuntu.com/BugReports
<Keybuk> nomed: be sure to document what's wrong with it, rather than "is broken" ... sometimes even a patch doesn't make it obvious what was wrong; usually a paragraph saying what mkinitramfs did, and what you expected it to do first, suffices
<nomed> "if [ ! d "${CONFDIR}" ] ; then" ... in /usr/sbin/mkinitramfs
<nomed> is there any "TUT" that explain step by step the best way to fill a bug?
<Keybuk> that's already fixed in dapper is it not?
<Keybuk> yes, that one's already known and fixed
<nomed> ok
<nomed> thanks
<nomed> i would then request a fetaure .. is it possible? or ..
<Keybuk> features are always possible
<nomed> should i contact the maint .. or there is an http place where to ask this?
<Keybuk> bugzilla I guess currently
<nomed> k
<Keybuk> we don't really have "maintainers"
<nomed> thanks
<Keybuk> or you could just ask on here
<Aegir> Quick question, how quickly between when somthing appears on dapper-changes mailing list and when it makes its way to the repository?
<Keybuk> Aegir: $TIME
<Aegir> Keybuk: Fair enough
<Keybuk> Aegir: ie. however long it takes ... usually to build
<nomed> wouldn't it be nice to use "-d confdir" to specify even scrpts/dir to include in initramfs?
<Aegir> Ahh, no worries. Was just curious. Saw the xorg pop up in my mailbox and quickly rushed to update my sources
<nomed> actually i need to copy scripts/* to /etc/mkinitramfs/scripts
<nomed> it just reads iniramfs.conf + modules from -d confdir
<Keybuk> nomeata: that's probably a bug ... I can't see why it does that
<Keybuk> the CONFDIR stuff was just bolted on at the last minute and never tested, I suspect a patch to replace any occurance of /etc/mkinitramfs with ${CONFDIR} would be the right thing
<Keybuk> Aegir: I think xorg FTBS ... so it may never show up
<Aegir> Righto
<Aegir> I think I know what you mean by FTBS, but what specifically does it stand for?
<Keybuk> Failed To Build From Source
<Aegir> Right, seems logical. Anyways, thanks for the answers, I'll go lurk in the corner again ;)
<dholbach> sudo apt-get install bsdgames && wtf ftbfs
<zakame> hi all
<zakame> haha dholbach 
<Mithrandir> pitti: pong
<pitti> Hi Mithrandir 
* pitti ponders what he wanted to ask Tollef
<pitti> Mithrandir: ah - do you know a bit about krb4?
<pitti> Mithrandir: krb4 is the only source package that keeps libdb4.1 in main
<pitti> Mithrandir: 1) we want to eliminate dups, and 2) it breaks some packages I want to update to a newer mysql
<pitti> Mithrandir: it would be great to build krb4 against db4.3
<pitti> Mithrandir: but these are only compatible as long as no transactions are used
<slomo_> elmo: please sync prelink from debian/unstable... ubuntu changes can be dropped
<Mithrandir> pitti: what depends on it?  I'd relaly like to just get rid of it.
<pitti> Mithrandir: cyrus-sasl2, evolution-data-server, heimdal, sasl2-bin
<Mithrandir> problem with migrating it is probably to handle upgrades from the 4.1 stash with all the users etc.
<pitti> Mithrandir: the actual data format is the same, just the log format changed
<pitti> Mithrandir: does krb4 use transactions?
<Mithrandir> pitti: no idea.  Probably not.
<pitti> Mithrandir: Friday I tried to build cyrus-sasl2 against the latest mysql, which breaks because of libdb4.1-dev vs. 4.2-dev
<pitti> (build-dep conflict)
<Mithrandir> does mysql depend on db4.2?
<infinity> pitti : BTW, I'm this --><-- close to declaring MySQL 5.0 "not completely teh suck" and dumping 4.1 altogether.
<pitti> infinity: I thought about the same
<pitti> Mithrandir: indirectly, yes
<Mithrandir> infinity: does it blow (up) in interesting ways?
<Mithrandir> pitti: crack. :-)
<ajmitch> do people still use krb4?
<pitti> Mithrandir: hey, mysql needs a real database backend :) 
<Mithrandir> pitti: anyway, if the data store is the same, we could just transition it.  Any idea what the popcon stats are for krb4?
<pitti> no
<Mithrandir> pitti: hahahha, well, I guess libdb is better than myisam..
* ajmitch is sure he saw something about krb4 removal somewhere
<Mithrandir> ajmitch: I don't know.  People thinking retro is cool, possibly?
<infinity> Mithrandir : Not in any ways I've managed to tickle it.  I need to look into Debian #339740, but since the reporter claims that upstream's binaries are okay, I'm confident it's something we can track down.
<ajmitch> ah, a thread about dropping krb4 support from heimdal
<Mithrandir> pitti: I wonder if we can just nuke it from all of those.. I can't think of any reason to run krb4 five years ago, not to mention today.
<pitti> Mithrandir: re nuke> can apps just be recompiled against krb5? (I don't know anything about krb)
<Mithrandir> pitti: all of the apps above have krb5 bindings in addition to krb4 ones, so we'd just disable krb4.
<pef> hello
<Mithrandir> pitti: heimdal might need a little bit of hammering, but not too bad, I think.
<pitti> Hey seb128, hi mvo
<seb128> hi
<\sh> moins pitti seb128 mvo 
<Keybuk> seb128: you know that totem/mozilla plugin crash?  I was wondering, could it have something to do with the CPU of the machine in question?
<Keybuk> was just reading the bugs, and they're all on a similar class of machine
<Keybuk> and similar to mine, and I get the crash every damned time
<seb128> Keybuk: yeah, maybe. It doesn't crash for me but it seems to do for a lot of people, it's just crappy :/
* mvo waves to pitti, \sh 
<pitti> Hi \sh
<Keybuk> I have another odd one :)  mplayer consistently doesn't work on my laptop, crashes every time
<Keybuk> but exactly the same packages work fine on my desktop
<\sh> hmmm...totem is crashing on all laptops i have...but mplayer, xine etc. are running
<pitti> infinity: just found another worthwile dup: ucd-snmp
<pitti> infinity: I add it to the wiki page
<SteveA> mjg59: hello.  i'm getting a really weird problem with my laptop suspending when i do dhclient eth1.  interested in looking into it?
<\sh> infinity: can it be, that the buildds are in a bad state somehow? i have problems with some kde stuff (amarok, kdiff3 etc.) which are building in a local pbuilder or chroot bot failing on the buildds because of missing kde build deps
<infinity> \sh : I'm out to dinner, can you ping me about it in about 2 or 3 hours?
<\sh> infinity: for sure :) 
<Mithrandir> Keybuk: hmm, I think I need a bootchart udeb.  Could you make me one or would you prefer a patch?
<Keybuk> udeb ?! :)
<Keybuk> you want to profile the installer?
<Kamion> I wouldn't complain ...
<Mithrandir> no, I want to profile the live cd boot.
<Mithrandir> we'd get profiling of the installer as well, but that's not what I'm interested in, really.
<Keybuk> you'd need two things
<Keybuk> 1) a place to hook the start script so that it runs throughout the process (we do this in initramfs for the main system)
<Keybuk> 2) somewhere for the monitoring to live (a jail in /dev for the main system)
<Keybuk> 3) a place to hook the stop script to shut it down again
<Mithrandir> that's three things. :-P
<Keybuk> damn, spotted :p
<Mithrandir> the 2) will be interesting, since we have a pivot_root in the middle.
<Keybuk> indeed
<Mithrandir> it should actually be easy enough, just a casper pre script.
<Keybuk> we have the same in the real system too, (pivot from initramfs to the root-fs)
<Keybuk> but the /dev partition survives that, so we live inside that
<Kamion> pivot_root> not once simplified-live-cd is implemented ...
<Kamion> but yeah, /dev is a tmpfs in d-i so you can use that
<Keybuk> patches welcome anyway, it'd be useful I suspect
<Mithrandir> Keybuk: do you have it in bzr/bazaar or should I just pull what's in the archive?
<teuf> hi
<seb128> hey teuf
<seb128> pitti: that's for you I guess :p
<Keybuk> Mithrandir: no, just grab the source from people.uc/~scott/packages
<pitti> Hi teuf
<Kamion> for startup, I'd include a /lib/debian-installer-startup.d/ script and rebuild debian-installer with bootchart-udeb in build/pkg-lists/base
<teuf> seb128, of course, nobody would come here for you ;)
<Kamion> that way we'd get installer profiling as you say
<teuf> hi pitti 
<Mithrandir> Kamion: yeah, that was my thought too.
<pitti> teuf: somebody already tested the python script, but you are welcome to confirm it :)
<teuf> pitti, yeah, I just did
<Mithrandir> Kamion: it'd be interesting to profile cdebconf, I don't think anybody has looked at its performance at all?
* seb128 slaps teuf
<teuf> pitti, and I'm getting exactly the same results
<Kamion> Mithrandir: not a lot
<nomed> Kamion, will ubuntu livecd use unionfs?
<Mithrandir> nomed: it will be an option.
<Mithrandir> at least when doing development
<Kamion> Mithrandir: I think the biggest win would come from http://bugs.debian.org/329743
<teuf> pitti, maybe a strace from a successful eject call would help ?
<Kamion> nomed: https://launchpad.net/distros/ubuntu/+spec/livecd-unionfs
<nomed> well i'm using it ... there are some issues with some scripts ..
<viviersf> whats the improvement on using unionfs rather than squashfs ?
<nomed> for ex adduser ...
<Mithrandir> viviersf: those are orthogonal.
<Kamion> viviersf: they're complementary, not contradictory. https://launchpad.net/distros/ubuntu/+spec/livecd-squashfs
<pitti> teuf: strace does not help us any more
<nomed> i filled a bug to unionfs list ...i hope they'll fix this ..
<viviersf> kk thx Kamion 
<pitti> teuf: we already isolated the problematic ioctl
<pitti> teuf: I'll do the rest with BenC when he has some time
<Kamion> nomed: what's the adduser issue?
<pitti> teuf: maybe we need to add some printk()s to the code and build a debug kernel
<Mithrandir> Kamion: evil hack suggestion, but quite cool in that bug, yes.  Could be done fairly easily with accessor functions, and we do have that already, don't we?
<teuf> pitti, I mean, eject /dev/sdb2 works properly here, so I was suggesting looking at a strace from that
<nomed> Kamion, "Hard link count is wrong for" etc/skel/dotdirs
<nomed> it fails when trying to cp /etc/skel/ .... to /home/$USERNAME
<nomed> i needed to use useradd -m
<nomed> mainly it seems something related to "find"
<pitti> teuf: I know, but there the CDROMEJECT ioctl will succeed, and it will fail with EIO on the other device
<teuf> pitti, sorry, I don't get what you mean 
<nomed> Kamion, http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2005-November/001427.html
<pitti> teuf: the problem is that the CDROMEJECT ioctl succeeds sometimes, and sometimes not
<pitti> teuf: but we have to debug the actual kernel function for that
<pitti> teuf: strace will only display the ioctl, not the code that is executed in the ioctl function
<pitti> teuf: all I wanted to know from the python script was that the ioctl is indeed the culprit
<pitti> teuf: and not some other commands issued by eject
<pitti> Hi carlos!
<teuf> pitti, ok
<carlos> morning
<Kamion> Mithrandir: it wasn't easy enough for me to do in the afternoon I spent looking at it
* pitti wonders...
<pitti> teuf: does the device where it fails happen to be USB 2.0?
<Kamion> Mithrandir: but not intractable, certainly
<teuf> pitti, the device is an ipod, and it's plugged in an usb2 capable port
<teuf> I'm not 100% sure the ipod is usb2, but it probably is
<seb128> pitti: this eject bug happens with CDs too, no?
<pitti> teuf: hmm, that thought was wrong, it works here with an usb2.0 memory stick
<pitti> seb128: no idea, does it?
<teuf> pitti, the CDROMEJECT ioctl also fails when I call eject, but then there are 3 more successful SG_IO ioctls, dunno if those are used to work around CDROMEJECT not working ?
<seb128> pitti: #5049 starts speaking of CDs
<pitti> teuf: actually yes
<pitti> teuf: the 'invalid argument' is just from the last one (tape?), misleading, but harmless
<teuf> ah ok
<Mithrandir> Kamion: but that'll only make lowmem installs quicker, not general ones, right?
<pitti> teuf: successful? but if they were, the others would not be tried any more
<Mithrandir> Kamion: anyway, using the file backend uses less memory, since it loads them on demand.
<teuf> the last one is BLKRRPART, google seems to indicate it triggers partition table reloading
<pitti> teuf: ah, ok, so that's got nothign to do with ejection
<teuf> pitti, the end of strace eject /dev/sdb2 is http://pastebin.com/435400
<Kamion> Mithrandir: reducing memory consumption and malloc churn should help everyone out a bit, I'd think
<Mithrandir> possibly
<nomed> Kamion, where can i follow the livecd development .. i think i can share some experience i have on this field ... mainly possible issues you could find
<Mithrandir> nomed: most stuff is discussed in here
<nomed> ok thanks
<Keybuk> hmm, I should probably "package" bootchart 0.9, fix the update-initramfs bug and then upload it to the real archive
<Mithrandir> Keybuk: what update-initramfs bug?
<fabbione> shawarma: ping?
<Keybuk> Mithrandir: bootchart's postinst calls update-initramfs, which promptly refuses to update the initramfs because the kernel doesn't use update-initramfs to make them :)
<Mithrandir> ah, ok.
<fabbione> Keybuk: i suggest you talk with BenC or fix kernel-package for that
<Keybuk> well, yes, I think that's the actual plan :)
<fabbione> i know Ben plan to upload the kernel today
<Keybuk> I'm still waiting for BenC to move all the firmware into /lib/firmware too though <g>
<fabbione> so perhaps we can get it in one shot
<fabbione> i tought they were there already
<Keybuk> 15-3 still puts them in /lib/hotplug/firmware
<fabbione> apparently no
<fabbione> yeah i can see that
<fabbione> Keybuk: i think #9394 would be better handled by you
<fabbione> since you are working directly on iyt
<fabbione> it even
<Keybuk> fabbione: ? RESOLVED FIXED
<fabbione> Keybuk: hmmm i just noticed the mail from bugzilla..
<fabbione> it must be old...
<fabbione> sorry
<Keybuk> I have #19200 already assigned to me (same thing)
<fabbione> roger :)
<Keybuk> isn't 9394 well within the WARTY range of bugs? :p
<fabbione> possibly
* fabbione needs to get ready for the next meeting
<Keybuk> have fun
<fabbione> thanks
<Keybuk> Kamion: would you have any objection to trying to slowly shove initrd-tools and modutils into universe?
<BockBilbo> hello
<freeflying> how can download the package from revu  ftp what I've uploaded
<BockBilbo> im about to write a wishlist bug in bugzilla but first i wanted to know if you guys think it is worth
<Keybuk> freeflying: try #ubuntu-motu
<Keybuk> BockBilbo: it may be better off discussing it on the ubuntu-users mailing list first, and then mailing the summary of the discussion to ubuntu-devel if it's broadly favourable
<BockBilbo> i see
<BockBilbo> it is related to WepLab http://weplab.sourceforge.net/
<BockBilbo> a wep key cracking program
<Keybuk> that isn't packaged
<dholbach> BockBilbo: you may want to add it to http://wiki.ubuntu.com/UniverseCandidates
<BockBilbo> i know
<BockBilbo> Keybuk, it isnt on the repositories yet, so i was thinking on suggesting it for drapper
<BockBilbo> thanks dholbach :)
<dholbach> de rien
<dholbach> brb
<Kamion> Keybuk: not at all; to get initrd-tools into universe, fix initramfs-tools to work on hppa and ia64 to lamont's satisfaction
<BockBilbo> *dapper
<Keybuk> remind me, if I _remove_ something from a seed, that shows up in anastacia, right?
<Kamion> yes
<Kamion> provided that you merge it to all the seeds
<Kamion> and that nothing depends on the removed thing
<Keybuk> yeah
<Kamion> (latter for completeness, I know you know this already ...)
<BockBilbo> dholbach, but.. i need a deb package build by myself in ubuntu in order to add it to https://wiki.ubuntu.com/UniverseCandidates
<BockBilbo> right?
<pef> BockBilbo: #ubuntu-motu :)
<BockBilbo> ok
<BockBilbo> :)
<sivang> morning all
<nomed> is it possible to use pivot_root within iniramfs?
<\sh> elmo / kamion: please sync icewm from unstable, dropping ubuntu changes ok, thx
<Kamion> s, / kamion,,
<\sh> whoever has time to do it :) no rush
<Kamion> it's not about time; only elmo does syncs (nowadays), so please don't ask me
<\sh> Kamion: ok :)
<infinity> \sh : So, what were you asking me about earlier?
<viviersf> Kamion, you know if grub has any issues with phoenix bios's 
<viviersf> ?
<Kamion> viviersf: no idea, sorry
<viviersf> kk
<viviersf> BenC, you know by any chance ?
<Mithrandir> Kamion: hmm, any thoughts on bumping the size of /dev?  5MB is a bit too tight, since I need libc and stuff in there as well.
<Keybuk> does the installer still fix the size of it?
<Keybuk> we stopped doing that in the main distro
<Treenaks> libc in /dev?
<Keybuk> you'll need the bootchart output in there too, which is about 30MB I think
<Keybuk> Treenaks: did you not look at the evil things I did to make bootchart work? :p
<HiddenWolf> Keybuk, ew
<ogra> Keybuk, did infinity notify you about dropping the "sleep 3" from initramfs' nfs script ? 
<Treenaks> Keybuk: ...
<Mithrandir> Keybuk: ok, I guess I can just remove the fixed sizee.
<Keybuk> ogra: not yet, though if it's the sleep I think it is, I'll probably drop that myself when I go through
<Mithrandir> Treenaks: it's the New World Order and /dev is the new lib.
<Keybuk> /dev is the handiest place to stash things that need to survive a pivot_root
<ogra> Keybuk, it was for debuigging a klibc timeout, its useless ... would be nice if you could throw it out ..
<Keybuk> oh right, no, wasn't the one I was thinking of then
<Kamion> Mithrandir: will go away with new udev + new rootskel
<pitti> Mithrandir: wow, only 2 packages left that use readline4 - thanks :)
<ogra> Keybuk, line 36 in /usr/share/initramfs-tools/scripts/nfs
<Mithrandir> Kamion: ok, goodie.  I'll just work around it for now.
<Kamion> Mithrandir: new rootskel uses the init script from udev-udeb, so as long as that doesn't hardcode it ...
<Mithrandir> Kamion: \o/ :-)
<Mithrandir> pitti: which are left, again?
<pitti> Mithrandir: lua50 and quagga
<Mithrandir> pitti: ok, I'll see if I can complete those later today. A bit busy with the live cd bootchart stuff now.
<pitti> sure, no problem
<pitti> Mithrandir: that wasn't meant to hurry you, just a thank you
<Mithrandir> pitti: np :-)
<infinity> ogra : Keybuk's not actually the initramfs-tools maintainer, he's just pretending to be for a week or two while he works on the udevHardwareActivation stuff. :)
<ogra> infinity, oh, youre around ...
<infinity> ogra : Lies.
<ogra> infinity, i just saw him doing all these uploads :)
<Keybuk> of course, by the time I give it back, infinity might not want to be the maintainer anymore
<ogra> lol
<Mithrandir> bootchart is DoS-ing my qemu
<infinity> Keybuk : If you do evil things to jbailey's pretty and readable shell, I'll hit you.
<Keybuk> nah, my shell is equally pretty and readable
<Keybuk> Mithrandir: did you forget to put nanosleep somewhere?
<Mithrandir> Keybuk: no, but qemu's I/O sucks.
<Keybuk> . o O { we may want to put that in initramfs-tools, as it's much more useful than the busybox sleep }
<Mithrandir> just fix busybox sleep to nanosleep instead.
<infinity> Keybuk : There's nothing wrong with busybox, I'm assured it's kloibc that's at fault.
<infinity> Oh, wait, maybe I'm confusing two different conversations.
<infinity> But making busybox's sleep take float arguments should be trivial.
<\sh> infinity: ok...I saw some glitches on the buildd for kde stuff...amarok e.g. or kdiff....
<\sh> infinity: http://people.ubuntu.com/~lamont/buildLogs/a/amarok/2:1.3.6-1ubuntu1/amarok_2:1.3.6-1ubuntu1_20051120-1846-i386-failed.gz
<infinity> \sh : I'm failing to see how "the archive is broken" is a buildd problem...
<zakame> hmmm, let me second \sh on that
<\sh> infinity: well...the archive works...because I checked with a complete new pbuilder and removing all packages from the package cache, that's why I thought the buildds are behaving not normal
<Keybuk> there shouldn't be any I/O, it's just tmpfs stuff
<Keybuk> you may be hitting the busybox fork-bomb, of course
<Kamion> \sh: libssl0.9.7 was certainly missing from the archive for a period of time.
<zakame> gnubiff ftbfs on all archs, while I can build so on my own chroot: http://people.ubuntu.com/~lamont/buildLogs/g/gnubiff/2.1.7-1ubuntu1/gnubiff_2.1.7-1ubuntu1_20051120-1014-i386-failed.gz
<Keybuk> infinity: sleep comes from klibc, so yeah, would be trivial -- nanosleep is exactly what you'd replace the klibc sleep with
<Keybuk> (it was written by copying sleep.c and modifying it <g>)
<Kamion> \sh: (I know, because I restored it over the weekend)
<\sh> infinity: but to be sure, I'd ask you :)
<Kamion> zakame: same problem, libssl0.9.7 was missing
* Mithrandir gets bored and increases the sleep period
<Kamion> which rendered python uninstallable, etc.
<zakame> Kamion: should I then adjust to libssl0.9.8 ?
<zakame> or keep it that way?
<Keybuk> busybox is evil, it does "exec /bin/busybox $cmd" for everything that should be a shell built-in
<Kamion> zakame: yes, but that's irrelevant!
<Keybuk> so you get a fork/exec hit for things like echo, test, etc.
<Kamion> zakame: the point is that *python* depended on libssl0.9.7
<zakame> Kamion: ah, ok
<Kamion> Keybuk: no it doesn't, it execs things that *aren't* shell built-ins
<Kamion> (in busybox)
<Kamion> it doesn't exec its own builtins, obviously, or half of them wouldn't work
<infinity> \sh : At any rate, python's happier now, so all that stuff will get given-back.
<Keybuk> Kamion: yes, things that _should_ be
<Keybuk> it does exec itself for echo :(
<Kamion> Keybuk: things that _may_ be, if you read the standard ;)
<Keybuk> I couldn't work out why, if it's the same binary, it doesn't just do it internally
<Kamion> Keybuk: there's progress on that upstream for the embedded guys
<\sh> infinity: k...thx 
<Kamion> but we've had this conversation before ...
<Keybuk> not with me?
<Kamion> yes, with you
<Keybuk> oh, when was that?
<Kamion> a month or so ago I think
<Keybuk> ah, I have little memory of anything before UBZ :)
<\sh> elmo: please sync klibido from unstable, dropping ubuntu changes ok, thx
<Kamion> hmm, might have been in /msg though, can't find it in the irclogs
<infinity> Anyone with a large set of danglies feel like merging PAM?
<Kamion> "personal communication"
<Mithrandir> ah, nanosleep 1.0 instead of 0.2 was _a lot_ better.
<Kamion> infinity: hah, PAM is on my bug list ...
<Kamion> ok, will investigate
<Kamion> today is my "hard merges" day
<infinity> Kamion : Ahh, lucky you.  It's just on my "last thing keeping db3 in chroots" hitlist.
<Keybuk> heh
<Keybuk> there aren't any easy ones left, iirc.
<Keybuk> where easy ~= no dropped
<Mithrandir> hmm, the live cd tells me I have no HD.  Silly thing.
<infinity> It wouldn't lie, you must have removed it.
<infinity> Of course, kernel 2.6.15 thinks I don't have a CD drive, so I feel your pain.
<Mithrandir> well, I'm running it through qemu, so I don't mind.  much.
<Mithrandir> I mind more that it sends a SIGKILL to localedef
* Kamion greps the archive for pam_getenv. sigh
<Keybuk> Kamion: uh, how did bootchart go straight to ACCEPTED ?
<zyga> morning
<Kamion> Keybuk: bootchart_0.8-3_source.changes
<Kamion> NEW to dapper
<Kamion> Changes: bootchart (0.8-3) unstable; urgency=low
<Kamion> (was synced from unstable earlier)
<Keybuk> heh
<Keybuk> how much earlier?  it doesn't show up in my packages lists at all
<Kamion> 25 Oct
<Keybuk> weird, which component?
<Keybuk> ah, it's never built
<Kamion> universe
<Keybuk> rookery scott% madison-lite bootchart
<Keybuk>  bootchart |      0.8-3 | dapper/universe | source
<Keybuk> it's, of course, entirely possible that might won't build either as it depends on evil java crud, but it might
<infinity> i386 / bootchart
<infinity>   Version             : 0.9-0ubuntu1
<infinity>   Builder             : buildd+terranova
<infinity>   State               : Uploaded
<Keybuk> sweet
<nomed> what can be the reason for which usplash picture disappears after run-init cmd in initramfs?
<Kamion> infinity: pam uploaded
<infinity> Kamion : Rock.
<infinity> nomed : timeout, or vc switch are the only things that will kill it.
<infinity> (Well, that and killing it)
<jbailey> infinity: Depend on killing it.
<jbailey> infinity: On a segfault it simply doesn't go away, =)
<infinity> FEATURE.
<nomed> i think it was the 128Mb of ram machine
<nomed> is it possible?
<nomed> ummm ... it seems not
<nomed> well thanks ... i'll check what's killing it
<\sh> doko: when the new gcc is ready to install...we can start with the renaming of the libs? 
* \sh is hot and horny about working on this again ;)
<dholbach> \sh: the new compiler hasn't built yet, but we can prepare packages already
<\sh> dholbach: well...http://people.ubuntu.com/~lamont/buildLogs/g/gcc-4.0/4.0.2-4ubuntu1/gcc-4.0_4.0.2-4ubuntu1_20051121-0317-amd64-successful.gz
<dholbach> \sh: does this include the changes we need?
<Kamion> <cjwatson@cairhien ~/src/ubuntu/base-config>$ dscdiff base-config_2.73.dsc base-config_2.73ubuntu2.dsc | wc -c
<Kamion> 1865092
<Kamion> <cjwatson@cairhien ~/src/ubuntu/base-config>$ dscdiff base-config_2.74.dsc base-config_2.74ubuntu1.dsc | wc -c
<Kamion> 161159
<Kamion> woo
<\sh> dholbach: i could tell you...when my evolution is not fcking around with me
<pitti> Kamion: hopefully most of the diffs are translations?
<Kamion> pitti: right
<doko> \sh: no, it's not ready, FTBFS on ia64 and powerpc
<\sh> doko: yes...but if all archs are build...it's the one compiler we are waiting for, right?
<doko> yes
<Keybuk> \o/ only 2,000 unread bugs now
<Kamion> pitti: could you please review MainInclusionReportPcmciautils? I did the packaging so I'm not qualified to review it
<pitti> Kamion: in 30 minutes?
<Kamion> sure
<dholbach> i'm out for food... see you later
* Keybuk wonders whether his sausages have defrosted yet
<Kinnison> walls!
* Keybuk checks Kinnison's dosage
<Keybuk> a little more today, I think, nurse
* Kinnison pouts
* Kinnison doesn't want more
<Kinnison> You give me so much at one time.
<carstenh> pitti: ping
* Mithrandir wonders if bootchart is going to behave this time around.
<Nafallo> Mithrandir: it didn't before?
<Mithrandir> Nafallo: nah, it dies when init started.
<Keybuk> http://www.thegoth.force9.co.uk/malcsimg/tescomum.JPG
<Mithrandir> s/dies/died/
<Keybuk> *giggle* ... "stoned server"
<Keybuk> that program really shows the age of the author
<Nafallo> Keybuk: grotesque picture! :-P
<Keybuk> "Ping Timeout" would be far more useful
<sivang> Kamion, fabbione : do you know if when resinstalling ubuntu, I  shold be able to remount my LVM managed PV/LVs ?
<\sh> brb
<Kamion> sivang: sure, you just have to go through the LVM configurator in partman once to get it to recognise them
<pef> elmo: can you please sync ktorrent from Debian ? thanks !
<sivang> Kamion: cool, so it's easy as pie to have them recognized again after wiping current isntallation?
<sivang> Kamion: and are we doing that in the Installer, or will it require "manual" intervention after system has been installed?
<Robot101> ktorrent kthanks
<Mithrandir> Kamion: any idea what kills bootchart approximately when casper runs?  That is, it looks like it's killed during casper's postinst, or something like that.
<Kamion> sivang: it's in the installer. please just try it :)
<Kamion> Mithrandir: not offhand, unless bootchart is pid 1
<sivang> Kamion: Will do, terribly sorry for the noise though. thanks!
<Mithrandir> Kamion: it's not.  It's 1998 or thereabouts, iirc
<sivang>  n.
<sivang>    A sullen protrusion of the lips; a fit of sullenness. "Jack's
<sivang>    in the pouts." --J. & H. Smith.
<sivang> hrm
<sivang> EWCHANNEL
* mvo goes to get some lunch
<Keybuk> bugs: 33280 total, 0 unread
<Keybuk> \o/
<pitti> carstenh: pong
<marseillai> hi
<marseillai> does anyone could tell me if gnome-power-management use "pmi action hibernate" command to hibernate a laptop or something else ?
* Nafallo hits the shower
* Mithrandir scratches head.
<Simza> Mithrandir : you can scratch my back instead
<Diziet> Well, it almost certainly doesn't compile on dapper (haven't tried) and it doesn't install on breezy without removing the locale support package.  But I think I shall upload it anyway.
<Diziet> (firefox, finally)
<siretart> hey mark!
<siretart> Diziet: you mean, first blood on firefox 1.5? ;)
<Mithrandir> I have _no idea_ what kills bootchart.  Apparently, lots of stuff is killed when doing pivot_root.
<Diziet> siretart: Yes, I have a package which is only about 2500 lines away from Debian's and seems to work at least a little bit.
<siretart> Diziet: great! :)
<Diziet> Hrm, the debian/rules clean needs a bit of tidying or I'll upload something with lots of junk in the diff.
* Diziet 8> giant buffer cache.
<Diziet> diff of two mozilla trees down from about 1ks to about 5s.
<doko> seb128: iz gtk bug
<seb128> doko: which one? :)
<doko> seb128: gcc-4.0 build failure
<doko> :)
<seb128> ah :p
<seb128> brb
<mvo> Kamion: is #19853 a problem in apt-setup ?
<\sh> elmo: please sync gabber2 from unstable, dropping ubuntu changes ok
<mdz> morning
<\sh> good evening mdz :)
<mvo> good morning mdz 
<seb128> hi mdz
<elmo> sh: done
<elmo> sh: gnome-theme-extras can't be done, orig.tar.gz mismatch
<\sh> elmo: hmmm....same problem as with gajim...
<\sh> elmo: lets see what I can do 
<elmo> Kamion: little is yellow-lining WRT disk space
<elmo> Kamion: still 100G free tho - do you want me to reset the warn/critical paramters to some lower value?
<\sh> ok..going home...cu laters
<Kamion> mvo: yes, but apt-setup is about to die and be replaced by a rewritten version, so ...
<Kamion> I'll take the bug anyway
<mvo> Kamion: ok, thanks
<Keybuk> hey, that's been my response to bugs for the last few weeks
<Keybuk> you can't steal it
<Kamion> Keybuk: heh
<Kamion> elmo: nah, I'll take the opportunity to free up a bit of space. What's the current yellow-line?
<Keybuk> ok, fog at sunset is officially creepy
<Keybuk> it's like there's this alien red mist hanging around
<Kinnison> Keybuk: it *is* alien red mist
<Kinnison> Keybuk: the WoW machines are attacking
* Kinnison expands WoW to 'War of the Worlds' before someone makes a smart-arse comment about 'World of Warcraft'
<Keybuk> I was just thinking "ullah"
<Kamion> elmo: it's sort of tempting to come down to the datacentre one day with a few spindles of CD-Rs and take official archival copies of all the old images lying around on little
<elmo> Kamion: yello is 20%
<Znarl> Kamion : I could help you with that, if you like.
<Kamion> thanks. might be worth it some day when we're all bored.
<Znarl> Kamion : Play escort that is, not changing CDs for you.
<Znarl> ...otherwise Elmo will kick my butt.
<Kamion> heh
<Kamion> I suspect mdz might kick my butt at spending a day changing CDs before ubuntu-express works, though
<Kamion> elmo: I've got it up to 22% used, but, believe it or not, any more is hard without purging old images. Can you reset the yellow line to 10% free?
<Kamion> or, actually, make that 15%
<elmo> Kamion: sure
<Kamion> 5% of little is still lots
<elmo> done
<seb128> Diziet: did you try to run apps using firefox (epiphany-browser, yelp, galeon, ...) with the 1.5 package?
<Diziet> seb128: No.  Are they hideously broken, or just broken ?
<seb128> Diziet: I've no idea, I'm just waiting on firefox build to try :)
<Diziet> I just upgraded my build system to dapper and am checking to see if the 1.5 package I just uploaded builds on it.
<elmo> aspell-ukr (0.51-0-4/0.51-0-4): in main - skipping.
<elmo> bonobo-activation (1:2.4.0-4/1:2.4.0-4): in main - skipping.
<elmo> db4.1 (4.1.25-19/4.1.25-18ubuntu1): in main - skipping.
<elmo> tix8.1 (8.1.4-8/8.1.4-8): in main - skipping.
<elmo> anyone want to vouch for the removal of any of those?
<doko> elmo: tix8.1 can be removed, but tix has to be promoted to main instead
<elmo> doko: can you deal with the seeds then?
<seb128> elmo: remove bonobo-activation please
<elmo> seb128: done, thanks
<doko> elmo: not necessary, it's a dependency of python2.4-tk
<seb128> np
<elmo> ** evolution-exchange has an unsatisfied build-dependency: libdb4.1-dev
<elmo> ** krb4 has an unsatisfied build-dependency: libdb4.1-dev
<seb128> elmo: I'll fix the evolution-exchange one
<elmo> seb128: cool, thanks
<seb128> are the seeds still using baz, or can we get them with bzr?
<elmo> you have to use bzr now, AFAIK
<ogra> seb128, see the SeedsManagement wikipage, colin has updated the content
<seb128> ogra: I've this page open atm, and no, there is no mention of bzr
<ogra> at the bottom
<seb128> no bzr mention on the page
<seb128> according to my browser
<seb128> grumpf
<seb128> EWIKI
<ogra> seb128, see it ? 
<seb128> I was using the canonical wiki
<ogra> heh
<seb128> the page should be removed from here
<desrt> elmo; ping
<seb128> and point to the other wiki if we switched
<ogra> seb128, while youre here ...
<ogra> Gnome-CRITICAL **: gnome_program_get_app_id: assertion `program != NULL' failed
<elmo> desrt: ?
<desrt> elmo; https://launchpad.net/products/launchpad/+bug/3996
<Amaranth> ogra: what app, what did you do to get that, etc
<ogra> seb128, why do i get this message in a pygtk program... indeed i havent set "program" to anything ...
<Amaranth> it doesn't look fatal
<elmo> desrt: *shrug* why are you telling me?
<ogra> but i havent imported gnome either
<Amaranth> ogra: what have you imported?
<seb128> ogra: maybe you have imported something which import gnome
<desrt> elmo; you replied to my RT request asking me to sign the code of conduct.  i am explaining why i can not.
<ogra> gtk and gtk.glade
<Amaranth> o_O
<ogra> nothing more
<ogra> import gtk
<ogra> import gtk.glade
<ogra> import os
<ogra> import sys
<ogra> import string
<ogra> import socket
<ogra> import fcntl
<ogra> import struct
<seb128> stop flooding
<elmo> desrt: that's nice.  but until you do, you don't get an ubuntu.com email.  sucks to be you.
<ogra> i dounbt anything imports gnome ...
<desrt> quite.
<Amaranth> how does that launchpad-integration stuff work, anyway?
<\sh> Amaranth: as a hook 
<seb128> Amaranth: what do you want to know?
<\sh> Amaranth: python example check gajim
<Amaranth> you have to add it to the program manually?
<seb128> you have 2 functions to call
<Amaranth> ok, all i needed to know
<Amaranth> i thought it hooked into gtk or something
<Keybuk> Kamion: does your powerpc have a /proc/device-tree thingy?
<Kamion> Keybuk: yes, all PowerMacs have
<Keybuk> Kamion: ok, can you pick something in there and see what /proc/device-tree/.../device_type contains
<Keybuk> and more particularly, does $(cat PATH) give something useful
<desrt> elmo; thanks for the info.  cheers.
<Kamion> $ cat /proc/device-tree/pci\@f0000000/device_type; echo
<Kamion> pci
<Kamion> Keybuk: ^--
<Keybuk> ok, cool
<\sh> Amaranth: into a gtk menu it's been hooked 
<stub> desrt: Your example doesn't hold anyway. Just because there is a signature that matches a document, it isn't suddenly legally binding or anything. You need to knowingly sign it, and not be under duress.
<Kamion> Keybuk: cat PATH> eparse?
<desrt> stub; but then you can argue that all signatures are meaningless anyway
<desrt> stub; so why even bother?
<Keybuk> Kamion: can you do "find /sys -name devspec | xargs grep pci@f0000000" and check something contains that
<Kamion> /sys/devices/pci0000:00/0000:00:10.0/devspec:/pci@f0000000/ATY,JasperParent@10
<Kamion> /sys/devices/pci0000:00/0000:00:0b.0/devspec:/pci@f0000000/uni-north-agp@b
<stub> desrt: They can be argued that way. Lawyers do it all the time. Depends on what other supportive evidence there is.
<Keybuk> ok, grab http://people.ubuntu.com/~scott/vio_type ... and check that "vio_type /devices/pci0000:00/0000:00:10.0/devspec:/pci@f0000000/ATY,JasperParent@10" returns something like VIO_TYPE=...
<desrt> i didn't expect an argument in the form of "but pgp signatures can be meaningless anyway...." :)
<Keybuk> . o O { must buy myself a cheap mac for xmas }
<desrt> i expected one of the form of "your attack is impossible"
<\sh> Keybuk: cheap mac?
<Keybuk> \sh: figure something off ebay for testing shit on
<Diziet> desrt: Generate a key which exists only for your Ubuntu stuff.
<desrt> Diziet; i'm considering that... but it seems underhanded
<Diziet> Why ?  It just seems sensible to me.
<desrt> Diziet; i also have a key that i plan to revoke soon... considering using that one
<Diziet> Don't do that, that's just silly.
<stub> desrt: Digital signatures suffer exactly the same draw backs as real signatures but on a lesser scale (ie. it is easier to forge a pen-and-paper signature than a digital one). 
<Diziet> Anyway, birthday attacks are not a real possibility with SHA-1, unless you think Ubuntu can carry out an 80-bit search.
<\sh> Keybuk: I thought about buying a pegasos 
<Diziet> The real cryptographic problem is that SHA-1 is broken and you're acting as a signing oracle, which nowadays you ought not to do.
<desrt> sha-1 isn't substantially broken
<Keybuk> Kamion: any luck?
<desrt> but that's a good enough point
<Diziet> Collisions have been found.  That's broken.
<Diziet> But the only risk is that Ubuntu can force you to sign some other file.  This will have no deleterious effect other than on Ubuntu if you use a key you make specifically for Ubuntu.
<desrt> they have full-algorithm sha1 collisions?!
<desrt> crikey!
<Diziet> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
<Diziet> (top hit for google sha1 broken)
<desrt> man
<desrt> is nothing sacred?
<Diziet> But it's only collisions, not second-preimage, so in practice you're still OK if you don't have a blessing oracle.
<desrt> uhm.
<desrt> ok.  so refuse to act as an oracle still
<desrt> but i don't see two files that i can download and hash
<Diziet> FWIW I wouldn't sign the code-of-conduct exactly as provided with a non-Ubuntu-specific key.
<desrt> i just see a reduction of complexity from theoretical birthday attack on sha1 to "still harder to attack than md5 via birthday attack"
<Diziet> So you have a point.  But just generate a different key already :-).
<desrt> well
<desrt> by the same token i'm just as happy to wait
<Diziet> The collision-finding complexity is down to 2^69 which is within reach.
<desrt> it's not like i have a critical need for my ubuntu.com email address to work
<Diziet> To wait for what ?
<desrt> for them to fix launchpad
<Diziet> They're not going to fix it.  Just get a grip and generate a different key.
<desrt> you might be wrong and i have nothing to lose by waiting :)
<Diziet> Sure. 
<desrt> oh.  you're ian
<desrt> hi :)
<Diziet> Hello :-).
<desrt> (we talked at ubz about crypto stuff too)
<desrt> specifically, key revocation policy
* Diziet looks desrt up on launchpad to get a picture.  Ahh.
* mdz scratches his head at the firefox 1.4.99+1.5rc2.dfsg-1ubuntu1 .changes
<Diziet> Lame, isn't it ?
<Diziet> I could have cut-and-pasted the README.Ubuntu but that's even crapper.  I really wanted to get a package out there to give people something to work with.
<mdz> are there reasons other than the freetype breakage why it won't build on dapper?
<Diziet> Not AFAIAA but I hadn't tried it.  I haven't fixed the freetype breakage because I didn't want to interrupt merging by updating my build system to dapper and blowing away my ccache.
<Diziet> It's still building here.
<Kamion> Keybuk: sure those arguments are right?
<Kamion> ah, you cut-and-pasted dodgily :)
<Kamion> $ DEVPATH=/devices/pci0000:00/0000:00:10.0 ./vio_type
<Kamion> VIO_TYPE=ATY,DDParent
<Kamion> $ DEVPATH=/devices/pci0000:00/0000:00:0b.0 ./vio_type
<Kamion> VIO_TYPE=uni-north-agp
<marseillai> does anyone could tell me if gnome-power-management use "pmi action hibernate" command to hibernate a laptop or something else ?
<Keybuk> ok, that looks good
<marseillai> i ask this because it seems that on my laptop hibernation works with ubuntu but not kubuntu!
<mjg59> marseillai: Yes, it uses pmi
<ogra> marseillai, in breezy it does
<marseillai> ogra: do you know what is used in horay ?
<marseillai> because with gnome in hoary it works
<marseillai> but kde and breezy it doesn't
<marseillai> kde and dapper nor
<ogra> mjg59, i'm not sure how we want to go on with this ... seems we'll need to keep the PowerManager backend daemon and patch g-p-m to talk to it
<Diziet> Woah, it built!
<Keybuk> uhhhh, Diziet, what the hell have you broken?
<mjg59> ogra: Either that, or we add a suid helper for hal
<ogra> marseillai, there is no gnome-power-manager in hoary
* Keybuk cries
<Keybuk> I've somehow got a system with a conffile owned by two packages at the same time
<Keybuk> with different md5sums!
<ogra> mjg59, with the likely chance that pitti kills us both ? 
<mjg59> ogra: For which? I've discussed this with pitti
<ogra> oh, ok
<ogra> didnt know that
<Keybuk> can anyone else on dapper do this for me:  grep "/etc/modprobe.d/isapnp" /var/lib/dpkg/status
<ogra> but the current package i have here is completely useless...
<ogra> (i have 0.3.0 locally)
<thierry> seb128 : look at malone bug 3951 , you said it had specs problem with the .desktop file... should I open a new bug to fix that?
<mvo> Keybuk: I have two entries as well
<mjg59> ogra: Because our hal doesn't do anything useful?
<Riddell> marseillai: does it work in ubuntu breezy gnome?
<\sh> Keybuk: 
<\sh> shermann@r200-shermann:~$ grep "/etc/modprobe.d/isapnp" /var/lib/dpkg/status
<\sh>  /etc/modprobe.d/isapnp 33fc47be83e43dd0450748b3e4700332
<\sh>  /etc/modprobe.d/isapnp 33fc47be83e43dd0450748b3e4700332
<ogra> mjg59, even with --retain-privileges
<mjg59> ogra: Oh? Why?
<marseillai> Riddell: it seems yes but it's not me who test but someone with the same laptop!
<Keybuk> mvo: do yours have the same, or different md5sums?
<ogra> mjg59, havent debugged yet ... but i think hal must be taught to talk to pmi ...
<mvo> Keybuk: different ones
<mvo> interessting!
<ogra> Keybuk, gra@honk:~/Desktop/willowgui $ grep "/etc/modprobe.d/isapnp" /var/lib/dpkg/status
<ogra>  /etc/modprobe.d/isapnp 5be3edbb3cd6290636ac3e6d653e5076
<ogra>  /etc/modprobe.d/isapnp 33fc47be83e43dd0450748b3e4700332
<mvo> /etc/modprobe.d/isapnp 5be3edbb3cd6290636ac3e6d653e5076
<mvo>  /etc/modprobe.d/isapnp 33fc47be83e43dd0450748b3e4700332
<marseillai> Riddell: i've thought it was a problem with the swap partition but i've try with resume=swap: /dev/hda5 kernel parameter and it doesn't work anymore
<seb128> thierry: what issue. Don't bother for the "value of key "Categories" is a list of strings and must end with a semicolon" ones
<thierry> seb128 : yeah but there's no encoding and stuff like that...
<Diziet> keybuk: This is probably my fault, indeed.
<seb128> thierry: what file?
<thierry> /usr/share/applications/gksu.desktop
<Keybuk> dholbach: that post probably shouldn't go to devel-announce, but to ordinary announce ... devel-announce is supposed to be "upcoming changes", rather than general announcements.  do you want to resend it?
<thierry> seb128 : my patch was fixing that by the way... maybe I could take a part of it and send it in a new bug?
<dholbach> Keybuk: hrm... none of my mails went through to ubuntu-announce@
<dholbach> Keybuk: they were silently rejected :)
<seb128> thierry: #3951 is about gnome-system-tools, not gksu and is really broken, you dropped the translations
<Keybuk> dholbach: that is to say that it should _also_ go to
<Keybuk> ie. don't "expect" anyone else but the core team to be subscribed
<dholbach> is ok
<Keybuk> rejected?  or jdub just hasn't woken up yet?
<dholbach> no, i didnt send it there this time :)
<thierry> seb128 : sorry about that
<seb128> thierry: np
<mdz> dholbach: ubuntu-announce is moderated
<dholbach> mdz: yeah, i know... i experienced it :)
<mdz> dholbach: that is different from being silently rejected
<plutonium> Hello marseillai 
<plutonium> I'm gonna translate in marseillais langage for certain people in this chan
<plutonium> vazy carlos sort une blague
<plutonium> chuck_, OUAWW !! Chuck Norris is present on this chan !!
<zul> ummm..ok
* Diziet fixes the `next day' date on UbuntuBugDay
<pitti> Hi
<pitti> My main network has been down for some hours (and is still) - anything urgent for me?
<Keybuk> Diziet: I think you can be let off the hook, it doesn't look as though it was broken with your recent conffile changes
<Keybuk> it looks like it's been ALWAYS broken
<Diziet> Really ?  How exciting.
<ajmitch> Diziet: interesting firefox changelog entry
<Diziet> Do explain, if you feel like it ...
<Mithrandir> Keybuk: did marga look at it?
<Diziet> ajmitch: Quite so.
<Diziet> It turns out that it _does_ build.
<ajmitch> that's good
<Diziet> Tomorrow I will upload an rc3-based one with a sensible changelog.
<seb128> bzr: ERROR: unknown command 'push'
<seb128> hum
<Mithrandir> seb128: install bzrtools?
<seb128> Mithrandir: thanks
* seb128 just tries to make a seed change :p
<seb128> bzr: ERROR: Rsync could not use the specified location.
<seb128> grumpf
<pitti> seb128: hmm, recent versions of bzr have push
<\sh> elmo: please sync krusader from unstable, dropping ubuntu changes ok
<Mithrandir> we've switched to bzr for the seeds now?
<pitti> seb128: use jbailey's latest crack
<elmo> Mithrandir: yes
<\sh> elmo: and I don't know if you missed another sync request of "grip" (also from unstable, dropping ubuntu patches ok)
<seb128> pitti: works better, thanks
<seb128> elmo: you can remove smeg it's replaced by alacarte
<pitti> Hi elmo
<elmo> sh: no, I synced grip already
<elmo> sh: krusader done
<pitti> elmo: what is required to get current dapper's pmount into breezy-backports/
<pitti> ?
<pitti> elmo: many folks are crying for it, since it fixes floppy mounting
<elmo> seb128: does alcarte provide smeg?
<Keybuk> Diziet: I don't have an explanation, just bafflement that it can go on-noticed for so long
<\sh> elmo: sorry then I missed it in my inbox...see it now...thx :)
<elmo> pitti: it's already in breezy-backports, it's waiting on buildd enablement
<Keybuk> basically package A provides conffile, package B doesn't ... then B gets upgraded, (partially) replaces A, and also provides that conffile
<seb128> elmo: it does
<Keybuk> now the conffile is owned by both A and B, rather than just B
<seb128> elmo: why?
<elmo> sh: also can you please fix quintuple agent?  it's build-depends line is broken, []  isn't valid
<pitti> elmo: oh, great
<elmo> seb128: the removal program was complaining that a bunch of stuff still depended on smeg
<elmo> seb128: done
<seb128> elmo: that should be the -desktop packages only and I've just updated the seed
<seb128> thanks
<Riddell> dholbach: thanks for sending that to ubuntu-devel-announce, I'd never have seen it otherwise
<\sh> elmo: sure
<ajmitch> elmo: is my gpg key still somewhere in your queue?
<elmo> ajmitch: for ubuntu?  yes
<elmo> ajmitch: I did debian last night
<ajmitch> ok, thanks
<\sh> elmo: u mean this one: libcap-dev [@linux-gnu@]  ?
<elmo> \sh: yes, it ends up as "[] " in the .dsc and Sources.gz
<seb128> type-handling is great :p
<\sh> elmo: yeah...debian/rules tries to do a s/@linux-gnu@/`type-handling any linux-gnu`/
<Keybuk> Diziet: ok, no, it's even stranger than that
<Keybuk> you did partially break it
<Keybuk> which is why it's never been spotted before
<Keybuk> with unpatched dpkg, the conffile appears twice in status, but only once in *.list
<Keybuk> with patched dpkg, the conffile both appears twice in status and twice in *.list
<Keybuk> actually, no, that's wrong too
<Keybuk> with patched dpkg, it appears in the wrong list
<\sh> seb128: well...seeing the output now, it gives me all archs for linux-gnu anyways...so actually it's useless
<seb128> we don't use it for main
<\sh> seb128: I removed the control.in joke now ,)
<\sh> strange that it worked in pbuilder...
<\sh> seb128: while u are here :) can u have a look on this http://people.ubuntu.com/~lamont/buildLogs/g/grip/3.3.1-4/grip_3.3.1-4_20051119-1529-i386-failed.gz ... and tell me what's wrong with it..and if it's actually fixed :) thx :)
<dholbach> Riddell: maybe you can then start gathering kde people, who want to help out :)
<Keybuk> hmm, they both did things in the same order
<Keybuk> Diziet: yup, you broke conffile replaces
<Riddell> dholbach: I'll give it a shot
<dholbach> :)
<seb128> \sh: no idea of what's wrong
<\sh> gnomevfs stuff should work, or?
<seb128> maybe a Depends broken on the way
<seb128> just use a pbuilder and try to install it
<\sh> seb128: i'll do it just now...because it compiled here already...I wouldn't sync a package without testing
<\sh> even armagetron i tested the debian package..and it build and worked ...
<seb128> that's not an issue with the package
<seb128> that's an uninstability somewhere
<seb128> may be a soname change of whatever lib
<\sh> seb128: i'll check
<\sh> bah...I'm now in this "typing with a uk keyboard", that I can't use a german keyboard anymore 
* mvo goes to play hockey
<\sh> mvo: have fun :)
<pitti> Kamion: here?
<\sh> well....
<\sh> it's dapper not breezy *grmpf*
* dilinger eyes mysql++ in universe, still at an ancient version in dapper
<\sh> dilinger: fix it :)
<Nafallo> dieman: http://revu.tauware.de/~sistpoty/MoM/ :-)
<Nafallo> baah
<Nafallo> s:dieman:dilinger:
<dilinger> \sh: will do
<Keybuk> Nafallo: ... you know if you want any "useful" output from mom, you can ask for it, right? :p
<Nafallo> Keybuk: I will always bug you when I need something from her indeed :-).
<Keybuk> you don't have to grep the log files, if you want I can add code to do things when universe merges are made
<Keybuk> ie. poke things with a stick so you can update lists, etc.
<Nafallo> oh, you probably want to talk to sistpoty. I'm just using the system :-).
<Nafallo> yay! firefox built finally :-)
<slomo_> lamont-away, infinity: please remove passepartout and pinball from dep-wait... should be fine now
<pitti> Mithrandir: do you think you can handle #19890?
<Mithrandir> pitti: what was the argument against getting rid of krb4?
<pitti> Mithrandir: none actually
<Keybuk> removing-duplication-in-main?
<pitti> Mithrandir: but removing the package would mean that krb4 needs a fix anyway
<mdz> Kamion: are the daily CD builds intentionally disabled?
<pitti> Keybuk: yep
<pitti> Mithrandir: I'm not sure whether elmo meant 'remove from archive' or 'remove from main'
<pitti> Mithrandir: I can rebuild it against db4.3 myself of course, but I don't have any krb fu
<Mithrandir> pitti: I have no krb4-fu, I just know some krb5 stuff
<pitti> Mithrandir: ah, ok. Nevermind then
<\sh> seb128: hmmm...grip is just building fine
<Mithrandir> pitti: but sure, I can recompile it and upload if you don't want to.  No sane way to really test it though.
<seb128> cool, just need a retry so
<\sh> infinity: ping
<Mithrandir> pitti: and as I said earlier, krb4 is dead.
<pitti> Mithrandir: ok, then we can operate on a similar basis :)
<pitti> Mithrandir: then nobody will notice it anyway
<pitti> :)
<Mithrandir> pitti: heh. :-)
<Keybuk> oh, wow, dpkg corner case
<Keybuk> A depends FOO, B replaces/conficts FOO
<pitti> elmo: speaking about libdb removal, when gnome1 is demoted to universe, there are only about 3 packages left which use libdb3
<pitti> elmo: (in main)
<Mithrandir> Keybuk: doesn't dpkg consist of corner cases?
<Mithrandir> Kamion: what's the eta on initramfs stuff in d-i?
<\sh> seb128: a give back or just a rebuild?
<Keybuk> (where A and B are two versions of the same package)
<seb128> \sh: buildd kick
<\sh> seb128: ok...
<Keybuk> the only way I can describe the result of that is "a sulk"
<\sh> infinity: please kick grip, amarok, kdiff3 again and please have a look on armagetron, it should build, but it's somehow strange that it's in dep-wait...(shouldn't be)..if you are ok with it, please kick it as well :) thx :)
<elmo> pitti: add it/that info the wiki page?
<pitti> elmo: yes (it should already be there in some way, but I check again)
<mdz> neuralis: community-server-hardware-testing needs to be kept absolutely simple; it shouldn't block on having any kind of automated test suite, or a database for recording the results.  What I had in mind was a wiki-based record based on a human-driven test plan, much as we are building for desktop testing
<neuralis> mdz: this is news to me. it was decided, at the bof, to try and do community testing as similarly as possible to certification.
<mdz> neuralis: community testing has different goals and a different timeline
<neuralis> mdz: are you worried about the test suite and catalog being available on time, or do you think a wiki-based record is a good long-term solution?
<mdz> neuralis: there are presently no developer resources allocated for creating such a test suite or catalog
<mdz> neuralis: and it is often a mistake to engineer for a long-term solution without real-world experience about how the application will be used,which is why we prototype with general-purpose tools like the wiki, to learn what our needs are
<neuralis> mdz: how so? the test suite is assigned to BenC, and it's a high-priority spec; as the specs state, i'll develop the catalog.
<mdz> neuralis: it was not intended in the first place (when BenC was assigned) that this spec involve writing a database application, or any software at all for that matter
<neuralis> mdz: i understand what you're saying, but it's radically different than what was discussed at the bof, as far as i can tell.
<mdz> we've learned through past experience that we need to set concrete, simple, achievable initial goals for projects like this, and not to overengineer from the start
<pitti> doko: ping
<mdz> neuralis: yes, that's the problem which I raised during the review process.  The intent of the spec was to create a community testing program for servers, but it was sidetracked to discuss certification instead
<mdz> neuralis: and now you seem to be considering community testing as an offshoot of certification
<BenC> mdz: will it involve a new wiki, or is there some way to apply this to the current wiki without a lot of pollution to the namespace?
<mdz> BenC: see LaptopTesting for an example
<neuralis> mdz: right, but then most of the bof was pretty misguided.
* BenC doesn't remember "community" being part of the "server testing" spec
<BenC> it's been a couple of weeks, and the bofs started running together in my brain, so maybe I'm just not thinking right :)
<neuralis> BenC: because it wasn't -- we mentioned it in three sentences at the end, saying "once we have this test suite developed, we'll just have people run it and post their results unofficially to a central location"
<mdz> right, but that's precisely the reverse of what I had intended
<mdz> BenC: the original summary for server testing said that we should "encourage and coordinate" testing, meaning within the community
<mdz> BenC: rather than carrying out testing ourselves, which is certification
<neuralis> mdz: i'm not at all opposed to bringing this in sync with your intentions, please don't misunderstand me, i'm simply trying to figure out where things got off track.
<Keybuk> mdz: do you know off the top of your head whether apt passes "--auto-deconfigure"/"-B" to dpkg?
<mdz> Keybuk: I don't think so
<neuralis> mdz: the bof discussed writing a test suite, which i've reduced to a rather uncomplicated process in the rewritten spec: essentially, writing a tiny ui.
<BenC> we have an Ubuntu Server Team? :)
<Keybuk> I wonder how the hell this upgrade worked in Debian ...
<Keybuk> udev 060 depends on hotplug, but udev 075 needs to replace/conflict it
<neuralis> mdz: if you don't want to allocate developer resources for that, i'm happy to write a text-only front-end to the chosen tools myself, as long as you want to take care of adding the appropriate "test suite" boot option to the CD, and land me in a shell.
<Keybuk> and dpkg won't do that
<BenC> oh, I'm not even part of that spec
<mdz> BenC: yes, we do
<neuralis> mdz: i'll also be writing the catalog myself, so i'm not sure i understand your concerns.
<mdz> neuralis: the tool described in that spec is for burn-in, which may be somewhat interesting for certification purposes, but isn't relevant to the process of determining whether the hardware is properly supported (which is what the intent was)
<pitti> elmo: can you please sync libgda2?
<mdz> neuralis: if that's something you would like to develop, I have no concerns about it.  however, that won't fulfill the need that I originally laid out for Dapper
<BenC> mdz: can I get one of the Sun Ultra 15k's that is shown for the logo on the Ubuntu Server Team page? :)
<BenC> I don't mind sharing it, just need to reinforce my floor joists to support it
<mdz> Keybuk: that doesn't sound like a problem; hotplug can be removed before the upgrade
<elmo> what would be the right package to file a bug about the 'lock screen' menu entry?
<elmo> pitti: done
<ogra> elmo, eek
<neuralis> mdz: i understand. let's deal with this in chunks. are you satisfied with the certification spec? 
<ogra> elmo, dapper or breezy ? 
<elmo> ogra: breezy
<Keybuk> mdz: would it be though?
<mdz> neuralis: don't misunderstand; I won't argue with your desire to implement whatever you like, but we need to be clear on what the original need was for Ubuntu as a project, and how it differs from that
<elmo> but I can't imagine this bug has been fixed in dapper yet
<ogra> elmo, breezy xscreensaver
<neuralis> mdz: no worries, i see where you're coming from, i'm just trying to get it across that this people at the bof seemingly had little understanding of your intentions.
<elmo> ogra: uh, really?
<neuralis> s/this/the/
<ogra> elmo, it wont, we'll switch to gnome-screensaver (except its a bug in a hack indeed)
<elmo> ogra: it's specifically about the 'lock menu' bit in the gnome menu bar tho
<ogra> elmo, oh, thats rather gnom epanel i guess seb128 ?
<Keybuk> mdz: I guess if apt does premature removal of conflict+provide that's ok ... wasn't sure whether it did or didn't
<mdz> neuralis: yes, unfortunately I am limited to being in one place at a given time, and was not able to attend the sessions
<mdz> neuralis: and other folks had different agendas
<neuralis> mdz: i'm happy to revise the community-testing spec to include a stage1 setup where we simply do a wiki-based record like we do now for LaptopTesting, and then use a centralized catalog as a later stage2. would that be closer to what you're after?
<mdz> neuralis: what I'm after is a formal process which allows the community to provide us with standardized feedback about whether Ubuntu works on their server systems
<doko> pitti: pong
<neuralis> mdz: incidentally, the laptop testing folks got excited about the server testing spec, and are asking me already about using the catalog for laptops as well *instead* of the wiki-based record which they find messy.
<pitti> doko: it looks as if we could sync db4.3, I checked changelogs and diffs
<pitti> doko: however, I'm on modem ATM and can't do a test build
<dholbach> elmo: gnome-session, afaik
<mdz> neuralis: of course they are; the long-term plan has always been to store this information in a database.  It just happens that the design of said database is a lot more complicated than it seems at first, and would have been quite difficult to get right without having actually done any testing yet
<pitti> doko: does anything get into your mind that is still Ubuntu-specific and must not be overwritten?
<mdz> neuralis: which is why we didn't do it that way
<Kamion> mdz: whoops. deliberately disabled for flight 1, but not deliberately left that way. fixed now.
<neuralis> mdz: okay, i'd be happy to outline such a formal process, but with a wiki-based backend, as a stage1 and a primary dapper goal, with anything else being "if we get around to it". would that suit?
<Kamion> Mithrandir: no ETA unless (a) there's a concrete need for it (b) Debian switch by default
<ogra> Kamion, can you enable edubuntu builds as well ? 
<Kamion> ogra: I already have, but they failed due to a bug which bit Kubuntu as well and was fixed just before Flight 1; the next build should work
<mdz> neuralis: sure, but it needs to be specific in terms of defining the test plan for evaluating hardware support (which is the key element).  the certification spec, by contrast, glosses over that part of the process
<ogra> Kamion, thanks ... what do i need to do additionally to have a liveCD build ? 
<mdz> neuralis: the issue which spawned this project was that Ubuntu was unusable on some popular server platforms because of basic issues like support for their RAID controllers, NICs, etc.
<doko> pitti: I'm looking ...
<neuralis> mdz: it glosses over it because the bof glossed over it. what did you have in mind? would a simple checklist, such as that for LaptopTesting suffice, or were you after more complicated solutions?
<mdz> neuralis: something along the lines of LaptopTesting and FormalTestPlans is what I had in mind
<Kamion> ogra: make sure your live seed and edubuntu-live metapackage work, then talk to lamont/infinity about getting live filesystems built
<Kamion> ogra: after that it's relatively straightforward for me to enable
<mdz> neuralis: given a written test plan, we can refine it throughout the testing process, and perhaps later encapsulate some of it in a UI
<Kamion> mdz: FYI I'm adding pcmciautils to the minimal seed
<Kamion> we're going to need it for 2.6.15
<mdz> Kamion: right, thanks
<ogra> Kamion, whats needed to make the -live package work ? its the same as ubuntu-live currently with s/ubuntu-live/edubuntu-live/
<mdz> Kamion: can we drop pcmcia-cs as well?
<Kamion> not yet - it still provides /etc/pcmcia/config.opts
<Kamion> I'm talking to folks in Debian about how to best move that to a common package
<doko> pitti: no, looks fine
<mdz> ogra: in this context, "works" ~= "can be used to successfully create a livefs"
<Kamion> we can get by for the meantime with pcmcia-cs and pcmciautils coexisting (which they do), but yes pcmcia-cs should go away eventually
<pitti> doko: ok, thanks for checking
<ogra> mdz, heh, yes, i got that, but assuming the ubuntu-live package work, my package should work as well in this context ... 
<ogra> s/work/works
<neuralis> mdz: i'm happy to develop such an outline and have you look at it again, but i fear it'll be very minimalistic.
<mdz> ogra: if it's identical, yes, it should
<Kamion> ogra: that should be fine for now; my comment was general. however please upload edubuntu-meta to account for your seed change, since edubuntu-live currently depends on ubuntu-live
<ogra> yup
<ogra> i was waiting unitil the flight 1 dust settled :)
<mdz> neuralis: if your interest is in certification testing, then you are of course free to focus your efforts on that, and leave the community testing side of things to someone else
<neuralis> mdz: that's not what i'm saying -- we can ask a user if they get video, if their drives are detected properly, and if they can use the network. what else can be easily verified by a community server user?
<mdz> neuralis: I see them as mostly orthogonal
<\sh> elmo: please sync kiosktool from unstable overriding ubuntu changes ok
<neuralis> mdz: laptop testing, by contrast (and by virtue of having a full desktop system), has all sorts of bells and whistles we can have people test and put in a checklist. not so for servers.
<mdz> neuralis: there is no limit to how it could be extended (testing functionality of popular server applications, etc.), but as an initial target, our goal is to enable them to answer "does it work?" at a meaningful level of detail
<mdz> neuralis: because currently we don't even have that, and that would be a huge improvement
<elmo> \sh: done, and thanks for fixing quintuple-agent
<zyga> hi
<mdz> neuralis: having the infrastructure in place to enable coordinated community participation is 90% of the problem
<zyga> I need to get all .debs from main in breezy
<zyga> what is the easiest way to do that?
<zyga> !
<zyga> the cd :>
<mdz> neuralis: once that's in place, we can parallelize the rest of the effort throughout the community
<zyga> sorry no issue
<neuralis> mdz: right. i'm pointing out that a meaningful level of detail for servers, and from a hardware point of view, is rather small, but i'd still be happy to put it together and have you comment on it specifically.
<\sh> elmo: thx...and fixing the package was my duty, when I read the changelog  :)
<neuralis> mdz: well, i aimed for the catalog to become exactly that infrastructure.
<mdz> neuralis: it will certainly be smaller than the equivalent test plan for a desktop
<mdz> neuralis: I don't think it will be a strict subset, though
<mdz> neuralis: for example, a server test plan would include things like serial console installation
<mdz> neuralis: for systems with hot-swap capability, that would be included as well
<crimsun> elmo: please sync mpd from Sid
<crimsun> elmo: (ok to override Ubuntu changes)
<neuralis> mdz: right. my point was that, outside of drives/nic/video (and subcategories, such as hot-swap), there isn't too much to ask about.
<mdz> neuralis: apart from the things which are important for servers, there isn't much to talk about.  fortunately, that'll incorporate the things we're interested in :-)
<neuralis> mdz: let's figure out how to proceed. i will revise community-testing and write up a simple process like that in LaptopTesting, which you can then comment on specifically before approving the spec. i'll leave the catalog in as a stage2. alternatively, if there's someone else you'd prefer to take over, i have no problem giving up the spec. 
<mdz> neuralis: sounds fine.  do you feel that you have a clearer idea of what I meant?
<Nafallo> seb128: ping :-)
<seb128> Nafallo: pong
<elmo> crimsun: done
<crimsun> elmo: thanks!
<neuralis> mdz: yes. as long as you're okay with another iteration or two of review, it should be fine.
<mdz> BenC: are you clear as well on the scope of community server testing?
<Nafallo> seb128: http://paste.ubuntulinux.nl/4838 I'll get this when I send mail. seems to stop the mails from getting moved from outbox to sent. anything you recognise from somewhere or know what could cause it?
<elmo> ajmitch: done now, sorry for the delay
<seb128> Nafallo: the sent you have selected from the account properties is a correct one?
<ajmitch> elmo: thanks for that :)
<Nafallo> seb128: yes
<seb128> Nafallo: I think we had some bug about guys setting a folder and removing it
<seb128> so I don't know
<seb128> feel free to open a bug with a backtrace, describe what kind of account do you use and what folder you picked for sent mails
<neuralis> mdz: community-testing aside, do you have any thoughts on the certification spec?
<crimsun> seb128: thanks for the libxklavier fix :)
<Nafallo> oki, I will if I don't narrow it down :-)
<mdz> neuralis: it's in my queue
<seb128> crimsun: np. Does it work for you?
<Nafallo> started doing this after changing ssl-cert.
<mdz> I haven't read the latest draft ye
<mdz> t
<crimsun> seb128: yes
<seb128> crimsun: cool :)
<neuralis> mdz: ah, no problem, i figured you read them together. i'll revise community-testing in the next few days and ping you again with it.
<elmo> HATEFUL BUGZILLA
<elmo> seb128: dude, did you see my annoying user question? (namely: I want to report a bug about the 'lock screen' entry, what should I report it against?)
<\sh> xscreensaver? gnome-screensaver?
<ogra> \sh, gnome-session :)
<elmo> I've had like 4 different answers now
<elmo> 'xscreensaver, gnome-panel, gnome-screensaver, gnome-session, gnome-menus' :-P
<seb128> elmo: the menu item is gnome-panel code
<elmo> seb128: thanks
<seb128> np
<vuntz> what's the bug?
<seb128> and vuntz is upstream for this code :)
<seb128> hey vuntz :p
<seb128> be back in a few min
* ogra guesses screensaver doesnt lock if daemon isnt running
<elmo> vuntz: when you click 'lock screen' and your xscreensaver has died, it just does nothing
<elmo> ogra: good guess
<vuntz> ah
<ogra> :)
<elmo> but this just bit sabdfl, so I get to be bug proxy boy
<vuntz> I think we already have this upstream
* vuntz looks
<vuntz> http://bugzilla.gnome.org/show_bug.cgi?id=130605
<elmo> hum, ok - is it worth reporting in our bugzilla and linking to that, or not?
<ogra> elmo, i think there already is one ... but filed against xscreensaver ...
<Nafallo> seb128: thanx :-). we changed from mail.domain to ogre.domain and didn't specify the sent folder again (thought that didn't depended on what server we used). all this on imap.
<Nafallo> seb128: I just selected the same folder again and it works :-P.
<pitti> elmo: can you please install the following packages into concordia's dapper dchroot: libtool libncurses5-dev libreadline5-dev gcj gobjc cdbs quilt
<ogra> vuntz, wouldnt it solve itself if gnome-screensaver/xscreensaver registered the daemon with respawn in gnome-session ?
<pitti> elmo: (gdb build deps minus type-handling)
<jbailey> gdb depends on type-handling now?  Scary.
<vuntz> ogra: well, this would solve the problem if the screensaver dies
<\sh> elmo: please sync ktrack and kxdocker from unstable, overriding ubuntu changes ok, thx
<vuntz> ogra: but not if the user disabled the screensaver in xscreensaver properties
<ogra> vuntz, thats enough i guess ...
<ogra> hmm
<vuntz> well, for you maybe :-)
<vuntz> not for me, though
<elmo> pitti: RTed?
<vuntz> this is what the upstream bug is about :-)
<pitti> elmo: oh, not yet, but I can do that
<ogra> vuntz, yes, but the patch is odd...
<elmo> pitti: please do - installing now
<pitti> elmo: mail sent, thanks!
<vuntz> ogra: well, it reports an error if the screensaver is not running
<vuntz> :-)
<ogra> vuntz, it should start it instead ... or the icon should be hidden if i disable the screensaver
<ogra> adding popup clutter isnt the solution ;)
<seb128> Nafallo: so you did use a folder not available :)
<jbailey> elmo: Should chroot requests generally go to RT now?
<elmo> jbailey: they should always be in RT, I'm happy to be pestered simultaneously on IRC tho
<Nafallo> seb128: seems like it. must have defaulted to Sent instead of my properly configured Skickat ;-).
<vuntz> ogra: that's why the patch is "needs-work" :-)
<vuntz> and not accepted
<ogra> yup
<seb128> Nafallo: you have edited an account, not created a new one, right?
<jbailey> elmo: 'kay.  When we pester you on IRC, should we give you the ticket number at the same time?
<seb128> Nafallo: but right, it should not crash when it's not set correctly ... either said so or default to Sent
<elmo> jbailey: nah, no need, as long as it's in RT, I'll clean it up later.  the RT thing is mostly about logging
<jbailey> elmo: Otherwise known as "please install devscripts in dapper-i386 on concordia", ticket 894 =)
<jbailey> elmo: 'kay,. cool.
<Nafallo> seb128: yes, changed smtp- and imapserver (only address, it's the same server :-P).
<ogra> vuntz, another option would be to strike out the icon with a red X if the screensaver isnt running and make it non sensitive ...
<vuntz> ogra: I'm not sure about the red X, but insenstive makes sense
<ogra> together with the respawning that should work fine
<vuntz> ogra: iirc, that's what markmc suggests in the bug
<Nafallo> so it should still use the values I've entered for the rest of everything :-)
<seb128> Nafallo: I'm not convinced about that, it should rather say you change other stuff and ask if you want to update this one
<seb128> Nafallo: you may want to keep using your previous Sent folder
<seb128> user choice should not be changed without asking
<vuntz> ogra: ideally, I should be able to lock the screen without having screensaver running in the background, though
<ogra> vuntz, not really, he fights for the popup solution
<vuntz> ogra: eg, if I usually don't want to have the screensaver, but suddenly I want to lock my screen
<elmo> jbailey: done
<ogra> hmm, but isnt gnome-screensaver intended to be shipped in gnome anyway ? why duplicate functionality ? 
<dredg> the best kind of joy is when you have a policy for locking screens, and the user picks a screensaver that manipulates an image of what's on their screen
<Nafallo> seb128: yea, now it changed an option that I didn't change in an existing account and didn't tell me about it. what it should have done is not change ANYTHING I didn't change :-).
<vuntz> ogra: gnome-screensaver might help, indeed :-)
<Nafallo> seb128: shouldn't even have asked me. that's an extra question that I already configured :-).
<seb128> yeah
<Nafallo> anyway, thanx for letting me and my girlfriend stop bashing our heads against the wall and me from sending debian 3 identical bugs again ;-)
<BenC> mdz: community-server-testing: yes, I'm clear on it now, thanks
<neuralis> BenC: i'll write up checking nic detection, drive detection, hot-swap, serial console. what else that comes to mind, hardware-wise?
<BenC> neuralis: storage systems (for installing utils that may be needed)
<\sh> grmpf
<\sh> because of the different cxx transition in debian we will get a lot of unmet deps 
<mdz> neuralis,BenC: note that fabbione has made some efforts through server-candy to collect information about the tools for storage management etc.
<BenC> mdz: excellent
<mdz> neuralis,BenC: so I suggest checking with him and figuring out what we can package, and work with mdy to open a dialog with the vendor in cases where we can't ship it
<BenC> also need something about memory layouts, and cpu systems (numa, etc.)
<seb128> Nafallo: do you use dapper?
<BenC> right now my base server kernel is a generic, need to find out if that's good enough, or do we need seperate numa/bigsmp/whatever kernels
<\sh> elmo: thx
<Nafallo> seb128: yepp, and my girlfriend 5.10 :-).
<seb128> Nafallo: you have this crash with dapper?
<seb128> grumpf
<seb128> it does:
<neuralis> mdz: great, i'll talk to fabio about it.
<seb128> " IMAP command failed: [TRYCREATE]  Must create mailbox before append
<seb128> Appending to local `Sent' folder instead."
<seb128> here
<seb128> and doesn't crash
<Nafallo> hm
<Nafallo> odd
<seb128> Nafallo: http://bugzilla.gnome.org/show_bug.cgi?id=315987
<\sh> yahoo...
<\sh> Setting up debtags (1.5.2) ...
<\sh> /var/lib/dpkg/info/debtags.postinst: line 22: 17024 Segmentation fault      debtags update
<\sh> dpkg: error processing debtags (--configure):
<\sh>  subprocess post-installation script returned error exit status 139
<enrico> \sh: cool! :(
<enrico> \sh: mind keeping me in the loop for what happened?
<\sh> hmmm..debtags update is segfaulting
<enrico> \sh: sure.  any gdb trace?
<enrico> (we can move to /msg if you want)
<\sh> enrico: aehmm....not right now...
<enrico> ok.  Keep me posted if you don't mind: enrico@debian.org
<\sh> enrico: I just made a dist-upgrade...the last autosync is a bit  faulty...
<\sh> enrico: lets see what gdb is saying
<\sh> enrico: for sure...I'll mail u
<\sh> enrico: http://paste.ubuntuusers.de/571
<enrico> \sh: looks nasty.  Repeatable?
<\sh> enrico: yepp
<enrico> and that is debtags update ???
<\sh> jepp
<\sh> enrico: and it's much more nasty because postinst is calling debtags update as last command :)
<enrico> too weird.  Maybe we should move to #ekhis (always on freenode)
<enrico> \sh: could you please /join #ekhis?
<\sh> but it can also be, that the new libstdc++ is somehow causing it?
<\sh> doko: ping
<enrico> \sh: all is possible: that segfault seems to have happened in code that is only called during make check :)
<enrico> (see the tut::test_object part)
<dholbach> have a nice evening... i'm off
<ajmitch> bye dholbach 
<\sh> cu daniel
<dholbach> bye \sh, ajmitch 
<zyga> can anyone suggest a easy-to-use big-mmapped hash-table library?
<zyga> (apart from gettext)
<neuralis> zyga: google makes a couple of different hashtable implementations available for c++, if that helps.
<zyga> neuralis: for big on-disk data?
* zyga needs to check
<neuralis> zyga: yes, look at the sparse hash map.
<zyga> got it
<zyga> neet
* zyga didn't know google shares code like that :)
<jcole> i want to change one simple parameter in a kernel .config asnd recompile... can i just "apt-src build linux-source-2.6.12" with a parameter to a config file??
<jcole> oops, my bad, devel only...
<lamont> gdb needs type-handling hate applied to it...
* lamont fixors
<pitti> lamont: too late, I was faster
<lamont> kewl
<\sh> hey lamont :)
<lamont> \sh: yo
<\sh> elmo: please sync kq from debian unstable, dropping ubuntu changes ok
<\sh> don't update debtags today :) apt needs mvo libstdc++ love...I don't touch apt ,)
<elmo> \sh: done
<\sh> elmo: thx
<jbailey> elmo: Can you pls. install less nito dapper-i386 on concordia (rt896)
<OgMaciel> smurf: hi... are you busy?
<elmo> jbailey: done
<jbailey> elmo: Thanks
<jbailey> !
<OgMaciel> Seveas: sup?
<Seveas> OgMaciel, hi
<OgMaciel> Seveas: how is everything?
<Seveas> busy as usual :)
<OgMaciel> hehe
<OgMaciel> I bet
<OgMaciel> am connected from Brazil
<lucas> is there a way to get the current name of the development branch of ubuntu ?
<OgMaciel> hope the internet will hold for tomorrow] s meeting
<lucas> (same for the "stable" branch)
<lucas> (I mean: in a script)
<OgMaciel> Seveas: I think Rosetta is going nuts... my karma keeps going down no matter what I do
<mdke> OgMaciel, you must be doing bad things
<OgMaciel> mdke: such as?
<mdke> OgMaciel, thinking bad thoughts?
<OgMaciel> mdke: been approving translations and such
<OgMaciel> mdke: hehehe
<mdke> OgMaciel, you can ask in #launchpad, not here though
<Pygi> #join #launchpad
<OgMaciel> mdke: cool... but I didn't really ask anything
<OgMaciel> it was just a comment
<OgMaciel> bt thanx
<OgMaciel> but
<mdke> OgMaciel, ok, i'll rephrase, you can chat about rosetta in #launchpad
<OgMaciel> mdke: understood
<pitti> elmo: please sync db4.3
<elmo> pitti: done
<pitti> danke
<slomo> infinity, lamont: please remove passepartout and pinball from depwait... should be fine now everywhere
<sistpoty> hi slomo
<slomo> hi sistpoty :)
<sistpoty> elmo: thx for adding me to the keyring :)
<sistpoty> lamont, infinity: is nvtv p-a-s? if so could you please clear it (newest version does have Architecture: i386 amd64)?
#ubuntu-devel 2005-11-27
<mdz> anyone gotten qemu -initrd to actually work?  doesn't seem to for me
<mdz> Linux doesn't find the initramfs
<jbailey> mdz: The cpio files are sensitive to cruft on the end whereas cramfs wasn't, so you might be running into a bug on that.  If it's causing you grief, it's possible to include the initramfs into the actual vmlinuz file.
<mdz> jbailey: oh? how?
* jbailey looks it up.
<jbailey> You stuff it into the ELF binary as an extra section.
<mdz> is there a tool to do that?
<mdz> hmm
<mdz> bad gzip magic numbers, says the kernel
<mdz> gzip magic is at the beginning of the file, no?
<jbailey> Yes, first three bytes
<jbailey> (I'm still looking for the instructions)
<jbailey> That's what we get on ia64 from initramfs' too.
<jbailey> Reminds me: lamont *poke* reminder about ia64 access. =)
<mdz> hmm, http://lists.gnu.org/archive/html/qemu-devel/2005-01/msg00255.html
<jbailey> mdz: Ah, interesting.
<jbailey> Hmm,  objcopy -O elf64-powerpc --add-section=.init.ramfs=bar vmlinux seems to create an empty section for me.
* jdong just notices FF 1.5rc2 in Dapper :)
* jdong further notices depressing changelog entry
<jdong> so while it's chugging away, can anyone explain what the "doesn't install cleanly on breezy" part means?
<lamont> jbailey: poking duly noted.
<nomed> just a Q ... what should generate the /dev/input/mice ?
<jdong> the hid drivers seem to do it here
<Chipzz> jdong: you are seeing things I'm not :P
<daniels> http://people.ubuntu.com/~lamont/buildLogs/f/firefox/1.4.99+1.5rc2.dfsg-1ubuntu1/
<jdong> Chipzz: archive.ubuntu.com mirror only
<jdong> yeah, and it failed on Dapper too
<jdong> still going on Breezy
<zul> someone ping me or something
<lamont> zul: huh?
<zul> lamont: my nick was highlighted was highlighte in the tab
<zul> never mind
<lamont> zul: that just seemed like a good way to ping you is all. :-)
<zul> *grumble*
<jdong> zul: DOS
<jdong> zul: DOS
<jdong> zul: DOS
<jdong> zul: DOS
<jdong> just kidding :)
<lamont> jdong: it's DoS, not DOS
<lamont> DOS is some 80's OS.. :-)
<jdong> EXCUUUUUUUSE ME FOR BEING LAZY WITH THE CAPS KEY :)
<lamont> LOL
<jdong> Isn't that the terminal thingie ;)
<jdong> anyone know how long it'll be before ooo 2.0 packages in Dapper?
<jdong> I know doko's hosting his own packages for it
<lamont> jdong: oo.o2 was in breezy, so it should already be in dapper...
<jdong> I meant final
<jdong> breezy still has a late beta
<jdong> which exhibits the later-stage bugs from OOo's bug tracker
<jbailey> lamont: thanks. =)
<lamont> I imagine it has things ahead of it in doko's queue is all
<jdong> mmkay
<jdong> OMFG Firefox built on Breezy!
<zakame> 1.5?
<jdong> yep
<jdong> Dapper's
<zakame> wow
<jbailey> jdong: Are you testing this to torture the poor backports people? =)
<jdong> jbailey: naw, I'm testing it for myself, this is definitely not backports material
<jdong> jbailey: I currently run a hacked/diverted mozilla.org binary of 1.5, so anything's better than that!
<jbailey> Why do you bother?  Does it have anything worthwhile other than svg?
<jdong> much faster
<tseng> jbailey: "the webpage says its faster"
<jdong> it is indeed faster
<jdong> Breezy ships with the slowest firefox ever
<tseng> which is true if you go back and forward 100 times in a row
<jdong> not just that
<jdong> general rendering speeds
<jdong> Even for the Ubuntuforums, I clearly see rendering speed improvements
<jbailey> The only time I want to do that, I usually also find myself wishing it wouldn't wipe out the contents of my forms.
<jbailey> I've learned. =)
<jdong> oh yeah, it's great
<jdong> faster
<jdong> just like official binaries
<jdong> still has a few bugs
<jdong> and still called Deer Park
<jdong> and mozilla.org still thinks it's beta 2
<jdong> but nevertheless it's an improvement
<jdong> like I said before, definitely not backports material
<jbailey> Hmm, looks like it hasn't built for ppc yet.
<jdong> jbailey: fails on Dapper, apparently
<jdong> http://people.ubuntu.com/~lamont/buildLogs/f/firefox/1.4.99+1.5rc2.dfsg-1ubuntu1/
<jdong> pretty brutal
<jbailey> Bad build dep
<jbailey> gtk2xtbin.h:44:27: error: X11/Intrinsic.h: No such file or directory
<jdong> gtk2xtbin.h:44:27: error: X11/Intrinsic.h: No such file or directory
<jdong> you beat me to it
<jdong> and yeah, Dapper is undergoing some X transition stuff
<daniels> it's nothing to do with the X packaging
<daniels> it's all about whatever has gtk2xtbin.h (presumably firefox) not build-depending on libxt-dev
<daniels> this hasn't changed from my side, so presumably something indirectly depended on it in breezy, so it just worked
<jdong> it's indeed in Firefox
<daniels> easy fix if someone with more bandwidth than me wants to try it
<jbailey> As much as that sounds like more fun than doing symbol comparisons... =)
* jdong off to verify even more backports candidates
<crimsun> elmo: please sync tau from Sid (overriding Ubuntu changes), thanks
<elmo> crimsun: done
<crimsun> elmo: thank you
<LaserJock> jdong: is there presently any way to make backports that require changing the source package available?
<jdong> LaserJock: nope
<jdong> LaserJock: a mailing list thread has just been started about that
<LaserJock> jdong: on what list?
<jdong> LaserJock: ubuntu-backports@lists.ubuntu.com
<mgalvin> jdong: trac from dapper works just fine on breezy, just needs to be rebuilt, in case anyone is interested, i "backported" (really just rebuilt) it the other day
<jdong> mgalvin: cool, and I was just about to e-mail elmo about clamav too :)
<LaserJock> jdong: hmm, that would be good. I have one package that would really benefit from a backport but I think  there are some lib name changes from breezy to dapper that would make it unable to get in now
<jdong> LaserJock: exactly
<mojo> is that possible if we breaks up the gnome-games into many components like Debian did before? so when users choose to remove a game using 'Add Applcation', it will makes more sense when that game is removed not whole pack.
<crimsun> daniels: Readding libxt-dev to B-D allows it to compile successfully on amd64 at least.
<crimsun> daniels: ("it" being firefox)
<daniels> sounds about right
<jbailey> crimsun: Are you a main uploader?  It might be worth just fixing.
<crimsun> jbailey: I don't have main privileges, no.
<jdong> aah out of things to backport....
<jdong> feeling... very... restless...
<jdong> (this isn't helping the stereotypical image of Backporters, is it?)
<infinity> Which image is that?  Crack-addled? :)
<jdong> lol
<jdong> it's been a while since I've heard that :)
<jdong> last time was in some mailing list.... in the Warty days
<jdong> reckless, bleeding-edge, representation of Gentoo/Nitro filtration in Ubuntu :)
<jdong> ooh rkhunter
<jdong> elmo: are you around?
<jdong> elmo: just wondering when the backports binary packages would start building... haven't seen any evidence of buildage yet
<jdong> mv,
<jdong> nvm
<jdong> started seeing some
<jdong> there seems to be some gtk 2.0.0 wackyness at work
<jdong> debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process
<jdong> what causes that?
<crimsun> elmo: please sync tapiir from Sid (ok to drop Ubuntu changes), thanks
<jdong> crimsun: that's already been requested earlier today
<jdong> never mind
<jdong> sorry
<jdong> dyslexic moment
* jdong promptly going to bed to  avoid further damage
<highvoltage> sorry for bothering here, is the 2.4 kernel supported in breezy?
<HrdwrBoB> ... no.
<HrdwrBoB> no it is not
<daniels> (nor in hoary, nor in warty)
<HrdwrBoB> err: package crack-smoker depends on linux-2.4
<desrt> W: Unable to locate package crack-smoker
<desrt> man
<desrt> you got me excited there
<HrdwrBoB> haha
<Keybuk> morning peeps
<siggen> Hi ..
<highvoltage> HrdwrBoB, daniels: thanks
<Keybuk> http://article.gmane.org/gmane.linux.kernel/351091
<Keybuk> ^ waaaaaaaaaah
<Keybuk> greg-kh is a very bad man
<lifeless> ...
<Lathiat> Keybuk: are they needed by external drivers?
<Keybuk> Lathiat: they'd only be needed by external non-GPL drivers for PCI devices
<fabbione> Lathiat: mostlikely yes
<Keybuk> (ie. all of them)
<Lathiat> Keybuk: right
<Lathiat> thats what i was thinking
<Lathiat> that sucks
<Keybuk> he's just being scary, and isn't really submitting that patch
<Keybuk> just making a point
<Lathiat> yeh
<Keybuk> greg-kh is very firmly anti-binary-driver
<Lathiat> the whole
<Lathiat> GPL non-GPL linking thing
<Lathiat> is there any actual sensible discussion on it?
<Keybuk> lots
<Lathiat> everyones opinion seems to differ :)
<Keybuk> no consensus
<Keybuk> personally I don't believe the GPL can cover runtime linking because there's no copying involved, and I don't see how it's a derivative work either
<Keybuk> but that's not the opinion of (e.g.) the FSF and Kernel guys
<Lathiat> right
<Lathiat> i assume the argument is
<Lathiat> their 'combined'
<Keybuk> and I tend to agree with the "binary drivers, bad" opinion too
<Lathiat> and so its 'derivative'
<Lathiat> right?
<Lathiat> dynamic linking seems to be a big stretch of that tho
<Keybuk> except I think the right time to pull the rug on them is when we have the market share, and if we dropped support for ATI and nVidia cards (etc.) then they'd lose half their target market so they'll be forced to play the game out way
<Lathiat> and i do wonder what the definition of derivative is
<Lathiat> got any urls?
<jamesh> Keybuk: there are potentially issues when you distribute both halves though (kernel + binary driver)
<Lathiat> Keybuk: right, exactly
<jamesh> (assuming the copyright holders want to go after you)
<Lathiat> atm we need to try hard to get people in
<Lathiat> not try to push them away
<Lathiat> sure it'd be great if the whole world was free and open source etc
<Lathiat> but you can't just expect the world to jump ship, if it'l ever happen
<Keybuk> jamesh: imo. only if you distribute the halves actually linked together
<Keybuk> we distribute them unlinked
<Lathiat> Keybuk: mmm i noticed that
<Lathiat> Keybuk: so is that to get around that part of it?
<Keybuk> and the user links them (well, their computer's dynamic link loader) when they start it
<Keybuk> Lathiat: no, I mean we distribute (e.g.) the libc and dpkg unlinked
<Keybuk> libc is a shared library format with a bunch of entry points
<Keybuk> dpkg is a shared binary format with a bunch of unresolved symbols
<Lathiat> oh, right
<Keybuk> it's the dynamic link loader that actually connects the two together, in the memory of the computer, and throws away the connections again afterwards
<Keybuk> I don't see how that's any different from what we do with non-GPL kernel modules, we link them together at boot time in a tmpfs (memory of the computer) which gets thrown away on shutdown
<Keybuk> and yet one is apparently GPL-illegal, and ther other GPL-legal
<jamesh> Keybuk: depends on what the judge believes.  Of course, this is all hypothetical until a kernel dev starts trying to sue for infringements
<Keybuk> jamesh: they have been sueing for a while
<Lathiat> Keybuk: well, isnt it often a bit different tho?
<Lathiat> like our restricted modules links stuff on boot
<Lathiat> but others distribute the complete kernel module?
<jamesh> Keybuk: I've seen the iptables guys sue for not distributing source to iptables
<Lathiat> does that have extra stuff included?
<jamesh> Keybuk: I haven't seen them sue for distributing kernel + nvidia/ati drivers
<Keybuk> jamesh: you think our lrm-manager thing happened by accident? :)
<jamesh> lrm-manager?
<Keybuk> jamesh: the thing that links the nvidia/ati drivers when you boot your machine
<Keybuk> /lib/modules/$(uname -r)/volatile, a tmpfs containing drivers linked to the kernel on boot
<dholbach> good morning
<rob1> hi dholbach 
<dholbach> hi rob1 
<dholbach> has anybody seen whiprush on irc lately?
<Keybuk> he was last online about a week ago
<dholbach> hm, i see
<dholbach> thanks for the info
<Keybuk> he was last online on the forums ~8 hours ago
<dholbach> and he was kind enough to deal with me messing with the hug-day dates :)
<dholbach> (on the fridge)
<Keybuk> yeah, LWN still have the wrong dates though
<dholbach> hrm, oh never mind - we have enough bugs for a whole hug week
<Kinnison> Morning
<marilize> Kinnison: morning
* Kinnison hugs marilize 
<ajmitch> hi Kinnison, marilize 
<Kinnison> ajm.
<marilize> hi
* marilize misses Kinnison's real hugs :)
<Kinnison> aww
<Kinnison> only a few months to the next conference
<marilize> Kinnison: :) long time
<Treenaks> is it Hug Day again?
<marilize> heh
<fabbione> hey Kinnison 
<\sh> Treenaks: thursday
<fabbione> hey marilize 
<Treenaks> \sh: no, that's Bug Day :)
<\sh> Treenaks: it's dholbach hug day :=
<mvo> hug day!
* dholbach hugs YOU!
<marilize> Fabbione: hey fabio!
<\sh> mvo: can u have a look to apt :) debtags upgrade segfaults because of new libstdc++ love and needs some hands on apt :) or should we wait?
<highvolt1ge> marilize: hi there. in the office today? can I come grab some breezy CD's?
<mvo> \sh: it's just a recompile with a soname change, right?
<\sh> mvo: dokos cxx love :) 
<\sh> mvo: yes
<mvo> \sh: oki, I'll merge other stuff that breaks the abi in this case and upload today, thanks
<\sh> mvo: just ran into it yesterday when the new debtags autosync was done...it breaks (dist-)upgrades 
<ajmitch> yet another apt abi change?
<marilize> hi, yes i'm here :)
<\sh> ajmitch: new libstdc++ read dokos announcement a couple of days ago
<dholbach> ajmitch: don't complain, mvo will surely bring us some shiny new crack with the ABI change :)
<mvo> ajmitch: just the abi, not the api. it's _so_ easy to break the abi in c++
<dholbach> mvo: how about ddtp? :)
<mvo> dholbach: yeah! needs translations on the server though :/
<ajmitch> \sh: yes, I read that
<ajmitch> mvo: I was just kidding, libapt has a complex enough soname anyway :)
<fabbione> Kamion: do we have awk or sed in d-i?
<mvo> haha, that's true :)
<fabbione> (or busybox...)
<\sh> mvo: include a bit torrent client into apt...apt-torrent fetch breezy ; apt-torrent share breezy ,)
<seb128> Diziet: "rmdir: /usr/lib/mozilla-firefox/extensions/*/uninstall: Aucun fichier ou rpertoire de ce type" (No such file or directory)
<seb128> Diziet: when updating to 1.5rc2 this morning
<sivang> hi all
<seb128> Diziet: you around?
<pitti> Good morning
<ajmitch> hi pitti 
<sivang> pitti: Morning!
<sivang> rehi ajmitch 
<pitti> Hi ajmitch, hi sivang 
<dholbach> hey pitti
<pitti> dholbach: Hi Daniel!
<seb128> hi pitti
<pitti> Hey seb128 
* sivang is going to try Flying 1 +LVM detection of current partitions.
<fabbione> dum dum dum dum
<fabbione> check_md5 /mirrors/ubuntu-md5/pool/main/d/debconf/debconf_1.4.59ubuntu1_all.deb.md5
<fabbione> Processing debconf: OK.
* fabbione attempts to corrupt hisown installation
<\sh> elmo: please sync kmymoney2 from unstable, overriding ubuntu changes ok
<Diziet> seb128: Hello.  What can I do for you ?
<seb128> Diziet: hi
<seb128> $ epiphany
<seb128> epiphany: error while loading shared libraries: libgtkembedmoz.so: cannot open shared object file: No such file or directory
<seb128> Diziet: your firefox just broke every single GNOME part using firefox :)
<Kamion> fabbione: busybox has sed, but we don't build its awk applet in the udeb config
<seb128> Diziet: I'm rebuilding it, any chance you forgot to ship some files?
<Diziet> Ah, I knew it was too good to be true.
<Diziet> Do you know whether Debian experimental's firefox comes with the embedding support ?
<fabbione> Kamion: ok, is it doable to build awk?
<seb128> according to a dpkg -c on their deb, no
<seb128> Diziet: but Debian build everything with mozilla, they don't even have a firefox-dev package
<fabbione> Kamion: otherwise i will look into other solutions.. no big deal
<Diziet> seb128: Right.  Well, yes, it's quite likely that I've accidentally dropped something in this area.
<seb128> Diziet: so probably something you want to fix with the next upload, thanks :)
<seb128> Diziet: you can try to run yelp devhelp epiphany-browser gnome-app-install to figure if your package is fixed :)
<Diziet> I'll see what I can do.  Should I look at Debian's mozilla.deb to see what we're missing ?
<Kamion> fabbione: I think awk's probably too big for Debian to build in busybox, and I'd like to sync with them ultimately
<Diziet> Or is there some documentation somewhere ?  (ha ha)
<seb128> Diziet: dh_install --list-missing to your firefox build tree should say what we are missing, no?
<Kamion> fabbione: we can build it into the initramfs config though
<fabbione> Kamion: yup.. that's ok with me
<fabbione> nah
<fabbione> no need to
<Kamion> fabbione: are you talking about udeb or initramfs?
<fabbione> udeb
<Diziet> seb128: That assumes that the filenames and structure haven't changed between 1.0 and 1.5beta.
<fabbione> basically the md5 client checker thingy might need awk
<fabbione> but i can use other commands to achieve the same
<fabbione> that's why it's not a big issue
<fabbione> awk makes it simpler.. that's all
<seb128> Diziet: hum? --list-missing will list what is installed by the make install and not shipped with the package 
<infinity> awk makes everything simpler.
<seb128> Diziet: epiphany-browser works fine with firefox 1.5 for sure, other distro have it. That's just a matter to put the missing files to the deb
<Diziet> seb128: What I need to know is what the files are, though.  I can't just take everything that's in `make install' but not in the .debs into the main .deb because it should perhaps go into one of the others.
<Diziet> So in my ignorance I'm hoping that there will be some way to tell other than guessing.
<dholbach> debdiff-ing old<->new packages might help
<seb128> Diziet: compare with the 1.0.7 deb, that's probably a couple of file with gtkembedmoz in the name
<infinity> debdiff is your friend.
<infinity> Wow, I'm full of pointless one-liners tonight.
<Diziet> dholbash, seb128: Thanks, right.  That's what I meant by `guessing'.
<seb128> Diziet: I don't know firefox neither, so I can just guess ... :)
<seb128> libgtkembedmoz.so should be shipped at least :)
<seb128> for other files I don't know :/
<Diziet> seb128: Well, I haven't taken a look at this issue yet.  If I do and it doesn't look clear I may come back and ask lots of difficult questions :-).
<seb128> Diziet: feel free, epiphany upstream is quite responsive on IRC, I can bounce questions here :)
<seb128> s/here/there/
<Diziet> OK.  Thanks for letting me know, anyway.
<seb128> Diziet: ok, according to epiphany upstream firefox should not built staticly
<Diziet> seb128: You mean they want it without the configure options `--enable-static --disable-shared' ?
<seb128> Diziet: correct
<Diziet> debian/rules only does that on mips.  I have no idea why but it's in Debian's diff too.
<seb128> Debian doesn't build anything with firefox
<seb128> they don't care, they can build it staticly
<seb128> the don't build mozilla this way :)
<Diziet> So `it should not be built statically' _if you want to embed it_.
<seb128> right
<seb128> which we want
<seb128> <crispin> but gtkmozembed depends on things like the xpcom, which in a static build don't exist
<seb128> <chpe> not just xpcom, many other libs too, gklayout etc
<Diziet> mozilla-firefox (1.0+dfsg.1-5) unstable; urgency=low
<Diziet>   * debian/rules: Don't compile statically on mips and mipsel, since it's
<Diziet> ifneq ($(DEB_BUILD_ARCH),mipsel)
<Diziet>         CONFIGURE_OPTIONS += --enable-static --disable-shared
<seb128> yeah, I know
<Diziet> Oh, I was wrong.  We build statically _not_ on mips.
<seb128> right
<Diziet> See what it says in the changelog for
<seb128> sorry I didn't parse correctly what you said before
<Diziet> mozilla-firefox (1.0+dfsg.1-3) experimental; urgency=low
<seb128> we build it staticly atm
<Diziet> Do we know whether that's true ?
<Diziet> And, also, if we build it statically now, how did it work in breezy ?
<seb128> we didn't use --enable-static
<Diziet> Oh, yes, that's commented out.
<seb128> mozilla-firefox (1.0+dfsg.1-3) may be true, but that's not an option for us since we use gtkembedmoz
<Diziet> Sorry about that, that was just a mistake by me then.
<seb128> np
<Diziet> I was definitely intending to keep all of our patches that I didn't deliberately decide to throw away.  I must have dropped that one in the middle of a patch conflict in debian/rules.
<Diziet> I'll reinstate it and also test with epiphany.
<seb128> thanks!
<Diziet> NP, thank you.
<slomo> Diziet: you are the firefox guy? you broke epiphany, galeon and everything else using firefox... you need to build libgtkembedmoz.so
<dholbach> slomo: if you read the backlog... :)
<slomo> oh ok... nm
<sivang> should I expect interesting problems with Flight 1 ?
<Keybuk> yes, and feel free to share them with us :)
<dholbach> didnt the announce answer that already? :)
<Keybuk> ignore the boring problems
<sivang> dholbach: hmm, u-d ml?
<seb128> slomo: we spoke about that on this chan for half an hour
<sivang> Keybuk: ok, I will :)
<dholbach> or u-a, might be u-d-a too
* sivang pokes u-d-a
<Keybuk> you can try out a package for me later if you want a /really/ interesting problem :)
<Keybuk> kernel consistently panics at boot when it runs "udevplug" :-/
<sivang> Keybuk: after I had installed dapper? Cool, I'll let you know when I'm installed.
<sivang> Keybuk: was it you that replied me on sending messages to u-d-a ? :-)
<Keybuk> probably
<sivang> " BUTTON AND SEND MAILS TO THE WRONG
<sivang> LIST!&#163;I_RI"WEFJIAJIDJFUR*U.."
<sivang> Keybuk: sorry again for that, I am watching closely since 
<Keybuk> heh, you sent rather a lot of them
<slomo> Diziet: sorry if i was a bit harsh...
<sivang> Keybuk: yeah, I know. I deserved that :)
<seb128> slomo: usually you can guess than such bug are noticed quickly and beeing worked
<jdong> seb128: would that also count Dapper's panic-on-pcmcia thing?
<seb128> dunno about this one
<jdong> http://ubuntuforums.org/showthread.php?t=93361
<seb128> that probably doesn't happen to everybody
<seb128> better to open a bug
<sivang> weird, https://launchpad.net/distros/ubuntu/+spec/dapper-desktop-plan/+status gives me "orry, you don't have permission to access this page." error, linked from JaneW 's email to u-d about the specs
<seb128> you don't have to edit the status of this spec
<seb128> that's correct that you don't have the permission
<sivang> seb128: how can I just see the status she meant as an example?
<seb128> ?
<seb128> if you have a spec assigned to you, you can change it
<seb128> if you don't, you don't need the example
<sivang> seb128: there must have been a reason why she sent that as an example, no?
<seb128> example of URL
<seb128> just change the name of the spec to match the one you want to change
<sivang> seb128: ah ok, I will do that - thanks!
<seb128> np
<seb128> you have some spec assigned to you?
<sivang> seb128: yes
<TheMuso> c
<seb128> Diziet: is that normal than firefox-dev is empty?
<seb128> $ dpkg -c firefox-dev_1.0.7-0ubuntu20_i386.deb | wc -l
<seb128> 2705
<Diziet> You mean `did you know that ...'.  HTH.  :-)
<seb128> that's rather a "doh, I just noticed it's empty" :)
<seb128> so pointing it :)
<Diziet> Indeed, thank you :-).
<seb128> you're welcome
<seb128> out of the gtkembedmoz files seem to be here when built without the static
<seb128> but epiphany doesn't start due to ABI changes
<seb128> which is fine, I just need to rebuild it (was expecting that), but for that we need a firefox-dev :)
<seb128> Diziet: removing the static and using dh_install -pfirefox-dev is enough to make epiphany (and probably other GNOME stuff) happy after a rebuild
<seb128> just FYI
* seb128 has a correct browser back and can get some work done now :)
<jbailey> Ah, hey.  That's why my browser won't start.
<HiddenWolf> go lynx. :)
<jbailey> I had just figured that it was something to do with it being morning and me being tired and that it would solve itself when I woke up more. =)
<Keybuk> anyone running 2.6.15 who doesn't mind trying something for me after saving any files they have open?
<seb128> jbailey: hey :)
<mvo> Keybuk: depends, but yeah
<Keybuk> "depends" ?
<jbailey> mvo: rm -rf ....
<mvo> Keybuk: I won't run jbailey command :)
<Keybuk> for uevent in $(find /sys -name uevent); do echo "add" > uevent; done
<Keybuk> might be worth doing that from a console/vt
<seb128> $ cat uevent
<seb128> add
<Keybuk> and change that last uevent to $uevent :)
<mvo> oh, let me save my work first
<seb128> with a sudo better :)
<mvo> and bzr push it to a save place :)
<Keybuk> it probably won't trash your disk
<HiddenWolf> *probably*
* HiddenWolf chuckles
<seb128> Keybuk: then?
<Keybuk> seb128: did it do anything scary?
<seb128> no
<mvo> runing, finished
<seb128> my cpu monitor jumped for a few sec
<seb128> and no change out of this
<Keybuk> no kernel panics?
<seb128> no
<Keybuk> running 2.6.15-3 ?
<mvo> loads of "already locaded" messages in syslog
<mvo> yes
<seb128> 2.6.15-3-k7
<mvo>  2.6.15-3-amd64-k8
<seb128> /var/log/messages has a several "...: already loaded"
<jbailey> Sweet!
<Keybuk> hmm
<Keybuk> makes my kernel panic :(
<jbailey> Keybuk: I thought that compat interface had gone away in 2.6.15?
<seb128> disappointed that the boxes didn't crash? :p
<Keybuk> jbailey: which compat interface?
<seb128> Keybuk: Sucks to be you :p
* seb128 runs
<jbailey> Keybuk: /sbin/hotplug
<Keybuk> jbailey: no ... isn't going away for a while (from the kernel side)
<jbailey> Keybuk: I would've thought we'd need the newer udev for the uevent tickling to show up anything at all.
<Keybuk> uevent tickling just causes the uevent to get sent again
<Keybuk> so results in both a netlink event and a /proc/sys/kernel/hotplug fork
<Keybuk> in breezy udevd does listen to the netlink socket
<jbailey> Proof that SVG is worthwhile: http://www.croczilla.com/svg/samples/svgtetris/svgtetris.svg
<\sh> elmo: please sync kwave from debian unstable, ubuntu changes can be dropped
<pitti> jbailey: heh, nice
<Diziet> seb128: Thanks for that.  I'm not sure what happened to dh_install -pfirefox-dev (but the debian/rules was the worst bit).
<seb128> np
<seb128> if you could do an upload which fix that today that would be great :)
<Diziet> Sure, I will definitely do that.
<seb128> nice
<Diziet> It'll be based on rc3.
<pitti> Diziet: 1.5 works pretty well here (amd64)
<pitti> Diziet: ok, it kills all language-support packages, but it works :)
<Diziet> Good.
<Diziet> Yes, the language-support packages have an unfortunate Conflicts.  I'm not sure why that's there.  Maybe just to make the languages be updated :-).
<pitti> right
<seb128> pitti: speaking about language pack, what about rolling new one, evolution is still not translated due to the domain change
<pitti> seb128: hmmmmnngg no Rosetta export
<pitti> seb128: I get a daily cron mail about the missing tarball
<seb128> feel free to kick carlos :)
<seb128> carlos: what about rosetta/translation tarballs?
<pitti> I mean, I can go the old skool way and build them from the buildds
<mvo> seb128: we need a new python-gnome2-extra as well (rebuild against ff1.5), right?
<seb128> mvo: yeah, I'll take care of the transition
<seb128> mvo: we basically need epiphany-browser, yelp, devhelp, galeon, gnome-python-extras
<mvo> thanks!
<seb128> np
<Mithrandir> Kamion: finally got cdebconf keyboard widget working \o/
<Kamion> Mithrandir: hooray
<Mithrandir> Kamion: for some reason, dlsym(RTLD_NEXT, ...) didn't cut it, so I had to explicitly dlopen the newt frontend.
<Znarl> telnet ubuntu.mirrors.tds.net 873
<Znarl> Opps, sorry.
<fabbione> *cough*
* fabbione scratches from the irc logs
<fabbione> no actually
<fabbione> you better tell them to change port ;)
<ogra> :
<ogra> )
<\sh> lol
<Znarl> Yes, they don't want any stranger using their rsync public port on their mirror.
<\sh> cool...I can't debuild anything anymore :)
<\sh> because debhelper is uninstallable ,)
<_pef> \sh: so how upload a new version of debhelper ? :] 
<\sh> _pef: it's  unmet dep of po-dephelper..only a matter of time :)
<\sh> po-debconf i mean
<Keybuk> nothing's uninstallable if you shove it hard enough
<Treenaks> ooh, breaky codes :)
<sivang> nice, so we are going to have OOo able to read MS's docs if they go ahead and nicely release the spces hopefully
<sivang> Znarl: lol
<\sh> Keybuk: well...right now I have to time to do other things..like wan^h^h^hdrinking coffee..so I'm not in a hurry ;)
<\sh> s/have to/have/
<_pef> sivang: there is a restriction against GPL programs, isn't it ?
<Riddell> who killed imlib1?
<seb128> Riddell: Debian
<Riddell> time for a main inclusion report for imlib11 I guess
<pitti> Riddell: don't bother if it is just a package rename
<Riddell> pitti: is it?
<pitti> no idea
<seb128> Riddell: I've a package of libgpod ready to upload, in case of somebody needs it for KDE no need to duplicate the work, I'll upload this week when they roll a correct tarball
<teuf> seb128, s/a correct/an official ;)
<seb128> teuf: whatever :p
<fabbione> Keybuk: ping?
<Keybuk> fabbione: 'sup?
<Riddell> seb128: does KDE use it?
<seb128> Riddell: according to teuf amarok SVN does
<dilinger> interesting
<dilinger> a coworker of mine just pointed out that djb is running ubuntu (according to http://cr.yp.to/)
<dilinger> i've never heard of him running any form of linux before
<fabbione> Keybuk: let's assume somebody hack a box.. and i can mount the disk ro on /target.. i have dpkg available outside.. what can i use, that's 100% safe, to verify that the dpkg database has not been corrupted?
<Keybuk> corrupted how?
<fabbione> any possible way
<fabbione> i would like to know if i can trust the db
<Keybuk> there isn't really anything, other than reading the files one by one
<fabbione> and if not, how can i rebuild it
<Keybuk> you can't
<fabbione> perfect
<Riddell> seb128: cool
<Keybuk> there's not malicious they could do though
<Keybuk> nastily make sure your conffile changes are lost
<Keybuk> they could stick things in postinst or something, but then if they had root, there's far more entertaining things to do
<fabbione> oh yeah i agree
<Keybuk> they could fiddle with the .md5sums files to hide other changes on the filesystem
<Keybuk> which is pretty much the #1 reason why debsums is useless
<fabbione> the major issue for me is: given a package name and an installed release (breezy/dapper...), determine the installed version and do some stuff
<fabbione> Keybuk: that's why i do my checks outside
<fabbione> and not from the running system
<fabbione> note: and i can mount the disk ro on /target.."
<jsgotangco> hello
<Keybuk> yeah, intrusion-detection systems live OFF the box they're protecting
<fabbione> exactly..
<fabbione> Keybuk: it's server-eyecandy stuff
<fabbione> Keybuk: i got the server side almost done (missing a few bits)
<fabbione> and i am writing the preliminary client
<fabbione> so there are some steps for which i need data from the installed system
<fabbione> minimal amount, but still
<fabbione> like installed pkgs
<fabbione> and their versions
<hunger> Keybuk: You could sign the md5sum files with your TPM after the installation is done...
<jbailey> backports.ubuntuforums.org seems to go to some guy's blog.  Anyone know if that's expected?  It's the top hit on google for "ubuntu backports"
<hunger> Keybuk: The infrastructure for TPM is slowly getting to a point where it can get used for somehting like that.
<\sh> jbailey: is it jdong?
<Keybuk> hunger: that only tells you there's been an intrusion, not what they changed
<jbailey> \sh: It doesn't actually say the owners name on it.  There's a long entry about Chuck Norris if that helps. =)
<\sh> jbailey: i mean it could be john dong (backports maintainer)
<hunger> Keybuk: Depends on the granularity of the stuff signed:-)
<jbailey> \sh: I'm saying I haven't a clue. =) There's no identifying marks on the page, and I know very little about the backports stuff.
<hunger> Keybuk: But you are right: If you used the TPM as it is intended, then such a check is obsolete anyway;-)
<\sh> hmmm....
<hunger> Keybuk: Fortunately that won't happen (soon).
<\sh> mez isn't here as well...
<hunger> Where do the debsums come from? Are they generated during installation time?
<Keybuk> sometimes
<Keybuk> they're an unofficial extension, dh_md5sums makes them if you put that in your debian/rules
<hunger> Keybuk: So you could get them from a server if there you think there was an intrusion? Doesen't sound too bad then.
<jsgotangco> dholbach: you busy?
<Keybuk> except if there's an intrusion on the server, you automatically can't trust the md5sums files because they're on the server that was compromised
<Treenaks> so you always need an external source of trust for that
<raingrove> what's wrong with backports now
<raingrove> md5 failed just now
<raingrove> it's ok now
<Treenaks> what's NOT wrong with backports
<pitti> Hi lamont
<pitti> moin carlos 
<carlos> pitti, hi
<lamont> morning pitti
<ogra> lamont :)
<carlos> pitti, about your langpack question...
<carlos> pitti, staging is being used to test gina before moving that into production
<carlos> so I'm not getting an updated mirror of production
<carlos> pitti, anyway, I'm working on the code now
<zyga> carlos, pitti: I was supposed to remind you about something
<zyga> first langpack for dapper was going to be generated with forced utf8 output to test if anything breaks this way
<carlos> I suppose it's related to the .desktop and gettext support?
<zyga> as you remember there are memory savings on all 'native' encoding .mo files
<zyga> carlos: not this time :-)
<carlos> oh, right
<carlos> I will implement the needed changes for that now that I'm back with language packs
<ogra> lamont, if you find some time, could you start a livefs build for edubuntu ? no hurry 
<mvo> Kamion: what is the proper procedur for breezy-updates uploads? just upload because they are hand-approved (and debdiffed) anyway?
<Diziet> Bah!  The files needed for the Flight 1 jigdo template have already vanished from pool !
<Diziet> And where can I find a spec for how to convert a normal hex md5sum into one of those annoying jigdo base64 ones ?  The files are almost certainly in my magicmirror repo but indexed by hex md5sum.
* Diziet resorts to UTSL.
<sivang> Diziet: UTSL ?
<Diziet> Use The Source Luke.
<sivang> Diziet: ah, granted
<mdke> what is the reason behind having a different translation freeze for language-packs and non language packs?
<lamont> ogra: that'd be ubuntu-base+edubuntu-desktop+edubuntu-live, yes?
<ogra> lamont, exactly
<pitti> mdke: because updating langpacks does not impact other packages
<lamont> ogra: I'll get the changes in today or tomorrow, and then it'll happen
<pitti> mdke: but when we upload new application or library debs, it might disturb things
<ogra> lamont, thanks, whenever you find time for it ... no hurry yet as i said :)
<mdke> pitti, hmm. Is there a case for having ubuntu-docs translations at the later deadline? I don't think they affect other packages
<mdke> they use gettext after all
<pitti> mdke: certainly
<siretart> wow! firefox 1.5 is really fast!
<Kamion> mvo: generally just upload, but check with mdz first if it isn't obvious
<Keybuk> yeah, start-to-core in 0.1s
<mdke> pitti, shall I have a word with mdz about it?
<dilinger> siretart: how does its ram usage compare?
<pitti> sure
<mdke> pitti, cool thanks.
<mdke> pitti, that is, unless we can figure out how to get those translations into the langpacks themselves
<mvo> Kamion: it's very obvious to me, I'll upload and let mdz know when he is up
<raingrove> siretart is there an official ubuntu/debian build for firefox 1.5?
<dilinger> raingrove: looks like it's in dapper
<raingrove> rc3
<raingrove> is it ok if i just add dapper repository and pull the deb?
<siretart> dilinger: still too high for my taste
<seb128> raingrove: current dapper version is b0rked you don't want to use it
<raingrove> just firefox
<siretart> raingrove: it breaks with firefox-gnome package, which breaks the translation packages
<raingrove> ah..
<raingrove> i see. but i am not using any i18n or l10n
<seb128> raingrove: current firefox will break anything using firefox if you install it
<seb128> raingrove: ie: gnome-app-install, yelp, devhelp, epiphany-browser, galeon
<sivang> seb128: is there a bug report?
<raingrove> ah. alright thanks
<seb128> sivang: no, do we need one for obvious transitions?
<sivang> seb128: ah, ok
<ogra> seb128, just transition ephy to dillo ... it hasnt that frequent new releases :p
<dholbach> seb128: slap him :)
<ogra> heh
* seb128 kicks ogra
<siretart> hrhr
* ogra : "ouch!"
<ogra> :)
<dholbach> seb128: he seems to like it :)
<seb128> :(
<ogra> :p
<Diziet> Look you stupid jigdo, I don't want you to stat all 200k files in my magicmirror repo over NFS !
<Keybuk> or you burn its car?
<Diziet> Something like that.  I _told_ it the files exist, I don't want it to check !
<pitti> Keybuk: that was another country...
<HiddenWolf> Keybuk, how's the new udev magic coming along?
<Keybuk> HiddenWolf: it's so fast, I have the next release of udev packaged already and the time police are at my door
<Diziet> At this rate it might be quicker for me to download the whole iso.
<tepsipakki> is archive.u.c just busy or why can't I update my mirror?
<tepsipakki> been like this the whole day
<Znarl> archive.u.c or security.archive.u.c?
<fabbione> tepsipakki: probably the kernel release
<tepsipakki> ok, no prob
<HiddenWolf> hm, this is odd
<HiddenWolf> I did an update && upgrade, and only the meta-package is getting updated
* Diziet gives up.  It'll only be about 2 hours to download the damn thing.
<HiddenWolf> doesn't pull in new kernel.
<tepsipakki> znarl: the former
<HiddenWolf> ah, nl.archive isn't synced yet.
<mdz> Znarl any luck with the us.archive mirror admin?
<Znarl> mdz : Yes, I am working on this right now.
<sivang> yay , flight 1 is now installed
<sivang> so, I have a couple of issues I wonder which of them were already reported
<azeem> check the relevant bug tracking systems?
<sivang> azeem: do we have a set of bugs that go by the tag "Flight 1" ?
<Kamion> no
<sivang> Kamion: ok, then I guess it's searching through them the hard way :) (if they all in bugzilla)
<sivang> interesting. loggin to my bugzilla account made the epiphany toolbar disappear. I can't reproduce that now, though.
<Diziet> How hard would it be to arrange for the files mentioned in jigdo templates not to disappear from the archive ?
<Diziet> Actually, come to think of it, distributing the iso but without the sources in pool is probably technically a GPL violation.
<Diziet> Not that any of the copyright holders are likely to mind very much, but it's probably best not to set a bad example.
<Riddell> all ISOs should have equivalent source ISOs available
<Diziet> source isos> Oh yes, there they are, in a subdirectory.
<Diziet> That's a way to solve the licence problem but unfortunately for me not my jigdo problem :-).
<Kamion> Diziet: the correct answer is to build a hardlinked jigdo snapshot archive, but our mirroring arrangements (chiefly, that the machine on which CD images are built doesn't run a web server) make that excruciatingly difficult to arrange in practice
<Kamion> unfortunately
<Diziet> hardlinked jigdo snapshot archive> What, that mirrors have to mirror separately ?
<Diziet> Or do you just mean to let people download the missing bits from.
<Kamion> the latter
<siretart> mvo: around?
<Kamion> it would involve signalling the archive when each CD image build run *starts* (not finishes), and again when a CD image is purged
<siretart> mvo: is it possible that apt does not respect /etc/apt/preferences when fetching source packages?
<sivang> Kamion: there a way to get a log of all packages errors from installatoin time? (Flight 1)
<Diziet> I managed to win against mkimage's stats but I was still missing a file.  I think the files must have been in the archive while my mirror disk was full, so I never had them.
<Kamion> sivang: /var/log/base-config-pkgsel.log
<sivang> Kamion: thank you
<Diziet> (My magicmirror keeps files for 11 days after they are unused, so otherwise I'd still have them.)
<Kamion> Debian have the same problem (although their archive churns less quickly so it's not quite so bad), but they leave a snapshot archive lying around on cdimage.debian.org or somewhere like that that you can get the missing files from
<sivang> Kamion: could it be base-config.log.1 instead? ( I can't find the one you mentioned)
<Kamion> sivang: no
<Diziet> Ideally there would be some fancy program that was both a jigdo reassembler and a BT client.
<Kamion> sounds like they've been logrotated out of existed
<Kamion> existence
<sivang> Kamion: bad, I had a multitude of errors I wanted to report :-(
<Kamion> I mean you can look in base-config.log if you like, it *might* have ended up there somehow
<sivang> Kamion: I just looked, I couldn't find the errors with fontconf and defoma stuff. Should I file bugs anyways?
<Kamion> if you can remember enough details to allow the developer to isolate the problem, sure
<sivang> Kamion: ok, I will try
<sivang> Kamion: actually having non rotating logs would be something very useful for QA purposes, can something like that bearranged for flight cds, or is this something which I can achive through some other means I am not familiar with?
<siretart> hi slomo 
<slomo> hi siretart 
<Kamion> sivang: I'm quite surprised they were rotated actually; I didn't know that happened
<Kamion> sivang: so, er, not unless somebody finds out what happened to them :)
<\sh> hmm
<sivang> Kamion: so in general, they should ot rotate on such installations?
<\sh> Kamion: flight-1 ... before the reboot to stage 2 there was a fast screen questioning me something...i couldn't read what...
<Kamion> sivang: they should not
<Kamion> \sh: see the release announcement
<sivang> \sh: debconf priority
<sivang> \sh: it doesn't let you do anything and it reboots :)
<Kamion> in the announcement, I described this issue and explained that it was harmless
<\sh> yeah...I thought it was something else...
<Kamion> I've also fixed it upstream
<\sh> well..i'll file wishlist bugs later ,)
<Kamion> \sh: for what?
<\sh> Kamion: "Shadow Password On" should be displayed in a popup dialog like the rest of the stage 2 install
<\sh> e.g.
<Kamion> \sh: no, it shouldn't
<Kamion> \sh: at most it should be directed to a log file; but that's being moved into the first stage anyway
<Kamion> it's a slight bug that it appears as a line of text, it's true
<\sh> Kamion: ok..:) 
<sivang> Kamion: also, an interesting thing - I dropped my in console rescue mode at first boot for second stage, with a root shell. I had to type exit for it to continue with second stage...
<gigc1> hi
<sivang> Kamion: *it dropped me
<Kamion> sivang: no idea what that could be
<\sh> Kamion: I wonder, if we can only install langpacks for gnome for the selected language..right now, we're copying all gnome langpacks it seems
<Kamion> \sh: mm, I've known about that for a while; the issue is that they're all in the ship seed
<Kamion> well, the cause, anyway
<Kamion> archive-copier could possibly be a bit more intelligent about those, although it all starts getting unpleasantly hardcoded
<sivang> anyway, heading hime
<sivang> home, even
* sivang -> out
<\sh> Kamion: but this would be a nice improvement to the installer...because you don't have any unused packages on the hd...and the time to a complete install is less then now...(if you have a USB drive and a slow internal HD in your laptop)
<gigc1> i have question add package on cd .
<Kamion> \sh: yes, I agree it would be a useful improvement
<\sh> Kamion: but installation is just fine...no errors until now
<gigc1> who know add package on cd .
<gigc1> heloo
<Kamion> that said, to some extent it's desirable the way it is; it means that you can enable other languages without having to download stuff from the net
<Kamion> which is pretty much the whole point of the ship seed
<Kamion> gigc1: please rephrase your question more clearly
<Kamion> this is a development channel
<\sh> Kamion: but u can always install them from cd
<\sh> if you need them
<gigc1> Kamion: how  add/remove  package  on install cd. 
<Kamion> \sh: the point of the copying step is that you can discard the CD after the first stage; this was a design requirement
<Kamion> gigc1: please ask support questions on #ubuntu; thanks
<Kamion> or see the FAQ on the web site
<\sh> Kamion: sure..but from the logical point of view, it makes more sense to copy the selected language. We don't ask in stage 2 no questions at all. So thinking about that, if the user needs another language he could use the cdrom or the inet. 
<Kamion> I'm just saying that there are arguments both ways, that's all. I'm aware of the arguments you're presenting (and don't necessarily disagree).
<gigc1> Kamion: no , i try ask #ubuntu but i not answer. i test redistribution but i get error apt-step fail . i have recomplie  new package ubuntu-keyring and add replece package ubuntu-keyring  in cd . after i test install .but i get error apt-step fail. i don't understand .
<neuralis> gigc1: this channel is for ubuntu development. for support, please try the forums or ubuntu-users@lists.ubuntu.com.
<Kamion> gigc1: if you mean that the installer fails when you modify a CD image, yes, it's currently annoyingly awkward to modify the signed CDs we distribute
<Kamion> gigc1: you need to rebuild the debian-installer package with your ubuntu-keyring-udeb, and replace the initrd.gz on the CD, so that the installer knows about your key
<Kamion> (put your ubuntu-keyring-udeb in build/localudebs/ in the debian-installer source tree)
<\sh> well...but the network doesn't work
<Kamion> gigc1: hopefully this will get easier in Ubuntu 6.04; we're probably just going to trust CDs by default so that we don't have to do this signing mess
<Kamion> that is, make the installer trust the CD it's installing from, since it clearly has to anyway
<seb128> hum
<seb128> the daily build page is ugly
<\sh> Kamion: sk98lin driver works during install...but not after the first login...driver loaded...leds blinking but no connection....network is ok...I rechecked with this laptop :)
<seb128> is somebody working on making debhelper installable again?
<\sh> libgcj6 broken dep
<seb128> ?
<seb128> doko: are you working to fix that?
<seb128> oh, already did
<\sh> sudo apt-get install debhelper po-debconf gettext intltool-debian libgcj6 gcc-4.0-base
<\sh> thats the whole chain
<seb128> doko: ping?
<gigc1> Kamion:thank you.
<Diziet> seb128: I can't get epiphany installed because of the broken locale dependencies, so I can't test it.
<Diziet> Do you mind if I upload firefox anyway ? :-)
<Diziet> The -dev package is no longer empty ...
<seb128> Diziet: I've tried this morning, if you fix the static and -dev package that's fine
<seb128> not at all
<Diziet> OK.  All of this effort getting Flight 1 installed and it hasn't really let me test it at all.
<Diziet> Oh well.
<seb128> anyway nothing build atm, so no hurry
<Diziet> Oh dear, apt is removing my computer.
<Diziet> That's what test installs are for I suppose.
<HiddenWolf> Diziet, removing your computer?
<seb128> hum, time for dinner, bbl
<HiddenWolf> sudo self-destruct --now? ;)
* \sh wants his debhelper back
<\sh> and something is wrong with my network....at least with the cable
<Diziet> apt-get install -f ...    removing / ... please stand by ...
<mvo> Diziet: you are using apt?!?
<ogra> Diziet, who needs / anyway, all the important stuff is in other dirs ;)
<Diziet> mvo: I use apt on installs I don't care about, and installs where I'm trying to have the (how shall we say it) full end-user experience.
<sivang> mvo: what are you using ?
<mdke> it's all about rpm
<mdke> i'll get my coat
<ogra> sivang, what should the main apt developer use ?
<mvo> sivang: the question should rather be what Diziet normaly uses :P
<\sh> mvo is using yast to install packages...I saw it ;)
* mvo giggles
<ogra> lol
<mdke> mvo uses gdebi
<mdke> :)
<mvo> yep, for testing!
<Diziet> I usually prefer dpkg-ftp.
* mvo installs all updates with gdebi now
<sivang> Diziet: serious? I mean, why not using apt normally, and why do you use it on installation you don't care about?
* dholbach shudders uncomfortably
* sivang wants to be with the elite. He is currently mostly using apt. Hence the question :-)
<Loevborg> mvo, btw thanks for working on gdebi, that really fills a need
<Diziet> Damn, forgot -sa on my -buildpackage.
<\sh> sivang: the elite is using emerge...we're only the windows side of linux ,)
<ogra> lol
<dholbach> Diziet: that makes the uploads faster :)
<sivang> \sh: I'll tell that to my roomate. He's a gentoo fanatic :)
<Diziet> dholbach: Thank you :-P.
<Diziet> sivang: Yes, I'm serious.  But this is a very boring conversation for me now; I've had it so many times :-).  I should write it up.
<mvo> Loevborg: thanks, that's appreciated :)
* ogra has to go away from this channel, his beely muscules wont bear that longer
<\sh> sivang: i'm a gentoo fanatic too..but only when I have holiday and have a slow computer
<ogra> *belly
<\sh> ogra: come on...
<sivang> Diziet: I've asked seriously out of real interest in improving my ways. Should I not be using apt?
<\sh> ogra: u missed the invstors movie today at ISH NOC :)
<ogra> \sh, i surely wouldnt have survived this
<mvo> sivang: Diziet is the original dpkg author (and dselect, right?). he likes it better than apt
<\sh> ogra: I put some ubuntu cds on my desk and went half a day (mostly) out into the cantine and were drinking coffee...I didn't allow them to picture me...but I allowed them to picture the desk :)
<ogra> hehe
<sivang> mvo: but he implied apt trashes your system, if I read him right :)
<Diziet> It can do, yes.
<Diziet> dpkg-ftp doesn't but you have to hold its hand quite a bit.
<Diziet> Excellent, now it is uploading the .orig.tar.gz and will saturate my uplink for a bit.  That's just what I wanted :-).
<sivang> Diziet: do you also do dependency resolution by hand?
<ogra> sivang, by foot ;)
<Diziet> sivang: No, I do that with dselect.
<sivang> Diziet: ok.
<ogra> sivang, as i said, by foot ;)
<Diziet> Anyway, that's enough for me for today.  See you people tomorrow.
<sivang> ogra: what about you? 
<ogra> apt-get save-my world ;)
<sivang> ogra: ok, then with you I'm in a good company :)
<Diziet> Goodnight :-).
<sivang> Diziet: night!
<ogra> night Diziet 
<mvo> night Diziet 
<sivang> interesting, my dapper just froze
<sivang> and I had to "reset" the machine
<mdke> interesting, and also predictable
<sivang> mdke: predictable? Breezy wasn't doing that while it was "unstable" , sure X was down for quite some time - but you could alwasy revert to the text consoles :)
<HiddenWolf> sivang, my Breezy does that quite regularly while "stable"
<mdke> sivang, all unstable distributions are unstable
<sivang> HiddenWolf: never did it to me
<mdke> hence the name
<HiddenWolf> sivang, does here, but I've got no clue why.
<mdz> sivang: are you using irqpoll?
<sivang> mdz: letm me check, that a kernel module?
<mdz> no, it is a kernel parameter
<mdz> if you don't know then you aren't using it
<sivang> mdz: ah, I can see why tht can cause a problem. (devices polling all the time for any waiting data?)
<sivang> mdz: but probably no, I haven't changed anything out of my dist-upgraded dapper
<Kamion> mdke: instability generally refers more to package churn than to how well it runs
<Kamion> there can often be a bit of the latter, but it's not the main point of the term
<mdke> heh
* mdke shuts up
<mdz> woo, firefox builds. go Diziet
<mdz> or infinity
<\sh> now I know what is missing in gnome
<\sh> snap to window borders ... like in kwin
<mdke> does anyone else keep typing cdimages.u.c only to realise it is without the "s"? pointing that at cdimage.u.c would save me loads of time :D
<elmo> mdke: send mail to rt@admin.canonical.com about it
<mdke> elmo, if you think it is a realistic idea, sure I will
* jdong lobbies for inclusion of rt2570 GPL'd wireless driver in Dapper kernel
<jdong> it's fairly stable
<ompaul> mdke, it is reasonable, and not a bad idea because there must be others doing the same thing
<fabbione> jdong: -> bugzilla please
<jdong> fabbione: cool, will do :)
<fabbione> jdong: assuming no bugs have been already filed
<mjg59> jdong: You're too late
<mdke> is there a list of current rt requests? To enable people to see if things have already been filed?
<mjg59> mdke: There's bugzilla
<mdke> mjg59, rt requests are there?
<mdke> oh
<mdke> sorry bit of confusion there
<mdke> i mean the rt@admin.c.c requests
<elmo> mdke: not publicly, no sorry, but you can assume it hasn't
<mdke> elmo, okay thanks
<jdong> mjg59: oh? I don't see any rt2570 bugs
<jdong> did a few searches
<jdong> are you confusing the 2570 with the 2400/2500?
<mjg59> jdong: They're derived from the same core
<mjg59> jdong: But to answer your question - our 2.6.15 contains rt2570 support
<sivang> mdz: what does irqpoll do then? (googling for it brought cryptic kernel develpment threads)
<jdong> ok, I'm about to submit
<jdong> mjg59: yes, so? Breezy and Hoary both had the PCI versions, so I'm assuming the USB isn't gonna come naturally unless someone says something
<fabbione> jdong: hoary and breezy will not get it
<fabbione> i am not sure you aware that they are stable release
<fabbione> hence no new feature
<mjg59> CONFIG_RT2500_USB=m
<jdong> mjg59: really?
<jdong> fabbione: I know that; I just want it for Dapper
* jdong checks out Dapper
<mjg59> jdong: No, I'm lying because it makes me feel better about myself
<jdong> mjg59: mmmkay, me happy :)
<jdong> fabbione: trust me, I deal a lot with the whole no new features thing ;)
<jdong> alright guys, have fun
<jdong> I'm gonna take a break
<jdong> thanks for reading my mind :)
* jdong doesn't feel like ticking off Deziet any more; worrying about FF later
* lamont owes elmo a beer for having stayofexcution=86400
<elmo> Mithrandir: ping?
<jcole> tar jxvf /usr/src/linux-source-2.6.12.tar.bz2; cd linux-source-2.6.12/
<jcole> cp /boot/config-2.6.12-9-386 .config
<jcole> echo 'CONFIG_REGPARM=y' >> .config
<jcole> sudo make-kpkg kernel_image
<jcole> dpkg -i ../kernel-image-2.6.12_10.00.Custom_i386.deb
<jcole> ^^^ i can't boot that kernel because it doesn't include radi support... does "sudo apt-get install linux-source-2.6.12" include the right ubuntu kernel source??
<jcole> s/radi/raid
<fabbione> yes the sources are the same that builds the kernel you get from archive
<jcole> my stock ubuntu kernel breezy kernel has raid support... how do i get the same sources?
<jcole> fabbione: did i do something wrong?
<jcole> (last command is actually "sudo dpkg -i ../kernel-image-2.6.12_10.00.Custom_i386.deb")
<fabbione> jcole: i dunno, but you better ask in #ubuntu
<fabbione> this isn't a support channel
<mdke> i get an error on dapper when doing "xrdb .Xdefaults" as follows: http://pastebin.com/436508 does anyone know if this might be a bug? the command seems to have succeeded...
<YokoZar> Would it be wrong or right of me to turn all of these things: https://wiki.ubuntu.com/UsabilityWishlist into specs at launchpad?
<wasabi_> So how does windows handle monitors so smoothly?
<seb128> mdke: that's due to mcpp and known afaik
<wasabi_> Ya can just unplug one vga and plug in another, never have to touch refresh rates
<fabbione> wasabi: it doesn't always
<wasabi_> I've never experienced a problem with 2k and up.
<fabbione> i do with XP here
<wasabi_> I'd expect at least it to detect at boot, but then screw up on hotswapping.
<wasabi_> But I've just never had that happen.
<fabbione> that's because it reprobes the hw on each boot
<fabbione> something we don't do
<Amaranth> if i have a monitor that can do 100Hz at 1024x768 and i plug in one that can only do 70Hz at 1024x768 it doesn't work
<wasabi_> hmm.
<wasabi_> didn't know that.
<wasabi_> Guess i've just never hit that combo.
<wasabi_> (so lets reprobe on each boot!)
<mdke> seb128, thanks
<YokoZar> Is there a reason really old monitors are detected poorly compared to newish ones?
<seb128> mdke: np
<mjg59> Old monitors don't tend to have useful DDC information
<lifeless> mjg59: any word from dell ?
<wasabi_> So, again, how does windows handle it? It seems to pretty well.
<wasabi_> I mean, you don't have to set it, and it can be made to work with any monitor.
<lifeless> wasabi_: old monitors - windows just takes a really low common denominator
<wasabi_> hmm
<wasabi_> I guess X should be doing this stuff on it's own when it starts, eh?
<mjg59> lifeless: No
<lifeless> mjg59: :[
<lifeless> I don't like us blocking on dell, cause hassling you is the wrong person to hassle.
<j^> is there some way to switch on/off powersaving features on external harddisks?
<lifeless> waaaah
<Amaranth> windows does have a bunch of "drivers" for non-PnP (ddc?) monitors
<j^> my firewire disk just went into some powersave state and locks any access to it now.
<Amaranth> i'm guessing they all use the same driver but have some ini file that lists what resolutions and such they support
<wasabi_> Ahh that's true... now that you mention it.
<wasabi_> I remember seeing Plug N Play monitor in the advanced settings, as if it was a driver.
<Amaranth> it was
<Amaranth> i'm guessing when the PnP driver is selected it does the ddcprobe-at-boot thing
<Amaranth> it probably probes when you first tell it to use the driver too, of course
<mdz> mvo: I seem to recall you were working on importing apt into bzr sometime recently; how did that go?
<mvo> mdz: I have a import ready (with all the cvs history). I'm not sure that it won't conflict with the bzr import from the lanuchpad people though. I need to talk to robert about it I guess
<mdz> lifeless: have you and Ian had a chance to chat about automated testing?
<lifeless> no, but I'm in the thread on debian-devel
<lifeless> Diziet: ping
<mdke> i think he gave up for the night
<lifeless> mdz: anything in particular you want eyeballed ?
<mvo> lifeless: will a bzr baz-import of apt be compatible with the import you do/will do?
<mvo> (a baz import I do myself)
<lifeless> mvo: we'll be doing a conversion of the baz archives to make the logs a lot nicer
<lifeless> which will dovetail to your conversion
<lifeless> the only problem is that your conversion won't do the magic needed at this point.
<ogra> mdz, i renamed my archive to http://people.ubuntu.com/~ogra/bzr-archive/ltsp/dapper/ , is that what you wanted ? or do you plan a dapper branch as well ?
<mdz> lifeless: no, just your input on the overall approach and any ideas you have
<lifeless> mdz: righto.
<mdz> lifeless: would like to have a chat with both of you to run through it, but might be more practical for you and Ian to get together without me given time zones
<lifeless> mdz: what are you running at at the moment ?
<lifeless> GMT-5 ?
<mvo> lifeless: so it won't hurt if I use my own bzr branch right now?
<mdz> lifeless: -8
<lifeless> mvo: go for it, just convert with the bzr on chinstrap
<mvo> ok, thanks
<lifeless> mdz: I'm +11 I think ;0
<lifeless> and ian is 0
<mdz> yep
<mdz> the bizarre time triangle
<lifeless> Frente!
<mdz> New Order
<lifeless> Monday, November 21, 2005 at 20:00:00Mon 8:00 PMMon NoonTue 7:00 AM *
<lifeless> thats london 2000 la 1200 syd 0700
<wasabi_> Odd. Somehow I've got a interface that won't auto up.
<wasabi_> By default, after a breezy install.
<lifeless> or one hour later
<lifeless> I'll mail you guys
<mdz> that's next week, and I'm in San Jose
<lifeless> on.
<lifeless> oh.
<lifeless> silly world clock wouldn't let me put in a tz
<lifeless> bah, same results :)
<lifeless> but I'll remember next time.
<ogra> lifeless, sudo apt-get install gworldclock 
<sivang> lifeless, mdz : are you also discussing this on debian-devel? (I think I read something about it from lifeless)
<lifeless> sivang: yes there is also a thread on d-d abot it
<sivang> lifeless: should I follow the discussion there if interested, or will you be posting / sending meeting minutes somewhere ubuntu community / wiki / lists ?
<lifeless> the meeting mdz and Ian and I have will probably be here or ubuntu-meeting
<lifeless> you're welcome to come along
<lifeless> and yes, if you have input, jump into the threads, thats why they are on the list ;)
<YokoZar> Would it be wrong or right of me to turn all of these things: https://wiki.ubuntu.com/UsabilityWishlist into specs at launchpad?
<mdz> YokoZar: someone was already doing that
<YokoZar> mdz: I just added a few within the past few days, should I go ahead and spec those?
<mdz> during UBZ
<mdz> YokoZar: sure; it might be a good idea to discuss them on ubuntu-devel first
<YokoZar> Isn't that what a braindump spec is for?
<YokoZar> And I assume you mean the ubuntu-devel mailing list, not chatroom ;)
<mdke> if you don't mind spending the time, you can spec anything you like
<mdz> YokoZar: no, the spec tracker is not particularly suited for discussion
<mdz> YokoZar: and yes, I mean the mailing list
<sivang> YokoZar: I am not sure it currently supports mailing back and forth for feedback
<mjg59> ogra: What was that funny wireless chipset you had?
<YokoZar> Thanks.  Will do.
<YokoZar> Hmm, new Wine release today.
<mdz> ogra has a funny one?  mine only tells bad puns
<YokoZar> I couldn't attend my LUG meeting yesterday to get my key signed, unfortunately
<YokoZar> mdz: is there a chance you'll be in the east bay visiting folks Thanksgiving?
<sivang> nice, /etc/lsb-release
<mdz> YokoZar: no, I won't, but I'll be in San Jose on Monday
<ogra> mjg59, mdz, 0000:00:0a.0 Ethernet controller: Linksys, A Division of Cisco Systems [AirConn]  INPROCOMM IPN 2220 Wireless LAN Adapter (rev 01)
<YokoZar> I think it would be uber-cool to have you sign my key, hehe.  Hmm, San Jose is a bit too far out.  Oh well.
<jdong> ogra: whoa.... that's a really weird Linksys...
<ogra> yup :)
<ogra> no way to get it working ... not even ndiswrapper (no windows 64bit drivers fo this amd64 laptop)
<carstenh> mdz: hi, is it possible do implement firewall as a bounty? (pitti told me to ask you)
<jdong> ogra: heh, that's not the typical Linksys Broadcom that I'm used to seeing
<jdong> ogra: then again, Linksys has been really nasty recently (i.e. WRT54G v5)
<mdz> carstenh: a great deal of work was already done as part of the google Summer of Code
<YokoZar> Google needs to have a southern hemisphere summer of code
<carstenh> mdz: sure, but not (successfully) bountied and there is still some work
<mdz> carstenh: oh, was it you who was working on it?
<carstenh> yes :)
<mdz> ah, of course
<carstenh> fine
<mdz> that makes more sense then
<mdz> send me a proposal via email
<carstenh> ok, do you need some screenshots?
<carstenh> (then i would first make them)
<carstenh> + have to
<mjg59> ogra: http://www.planetamd64.com/index.php?showtopic=6559&st=0&p=62758& seems to have an amd64 driver
<mjg59> Still not a good solution
<ogra> mjg59, this one didnt work, its around for quite some time already ... the ndiswrapper guys told me they only concentrate on broadcom for amd64 for now
<YokoZar> mdz: could we talk about Wine for a second?  I read on this ImpiLinux thing http://www.ubuntulinux.org/newsitems/impilinux that there's a goal to have Windows compatibility in that (probably via Codeweavers), but it seems like a more elegant solution would be to have Wine in Ubuntu working smoothly first.
<carstenh> mdz: i guess i can send you screenshots how i will look like on your request after the mail. i'll send the mail in some hours. thanks.
<YokoZar> Anyway, Wine has a somewhat intransigent release schedule at the moment, but I think we could make another stable release ala 0.9 if we knew the date ahead of time.  Do you know the relevant freeze date yet if I wanted a stable Wine to be in Dapper?
<mdke> YokoZar, BreezyReleaseSchedule on the wiki
<mdke> whoops
<mdke> s/Dapper
<ogra> mdke, hehe
<jdong> YokoZar: IIRC MOTU is working on a Wine 0.9 import...
<YokoZar> jdong: that would be me
<jdong> oh, lol
<jdong> I've been having two rough days in here :)
<ogra> YokoZar, so youre going for motu finally ? 
<YokoZar> Just need my key signed, yeah
<dholbach> YokoZar: are you a member already?
<YokoZar> I disappeared off of the internet for a couple months when I moved
* jdong RUNS away before ogra locks onto him
<Amaranth> i've "just needed my key signed" for about 6 months now :P
<ogra> yeah, become a member first ... but this requires a signed gpg key too
<YokoZar> Would the 19th of January (upstream version freeze) be the relevant time to have the final Wine release packaged then?
<jdong> YokoZar: do Sid packages of 0.9 not work at all?
<Amaranth> plus i'm not too interesting in managing a crap load of packages, just my own and a couple python ones i use :)
<Amaranth> err, interested
<YokoZar> jdong: The winehq ones work better.  Much better, actually
<jdong> mmmkay
<YokoZar> And they're built against sid and breezy at the moment
<crimsun> MOTU is an entire team, Amaranth. None of us really maintain any packages.
<jdong> YokoZar: is there really that much work in importing that to Universe?
<ogra> YokoZar, re UVF, yes 
<mdz> YokoZar: we would like to have wine working well in Ubuntu, yes
<Amaranth> crimsun: I know, but I really only wanted to join in the beginning so that smeg and pyxdg would be updated in ubuntu ASAP.
<YokoZar> It's quite possible there will be a better Wine release sometime between upstream version freeze and beta
<ogra> YokoZar, upstream version freeze applies to universe as well this release ....
<mdz> YokoZar: I don't think that is a substitute for what Impi want to do, though
<Amaranth> and now seb128 makes sure that stuff gets in right away anyway so... :)
<ogra> YokoZar, (indeed we can make exceptions, but they are not the general way)
<YokoZar> I just want to plan it out ahead of time so I can pitch the idea of another tested release aside from 1.0 to the Wine team ahead of time
<jdong> mdz: I think buildd is hating me :)
<jdong> http://people.ubuntu.com/~lamont/buildLogs/r/rhythmbox/0.9.1-1ubuntu3~breezy1/rhythmbox_0.9.1-1ubuntu3~breezy1_20051122-0220-i386-failed.gz
<jdong> weird failures
<jdong> debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process
<jdong> during apt-get build-dep
<jdong> several backports packages failed in the same way
<Amaranth> i get that when i'm trying to do two dpkg things at once
<jdong> Amaranth: makes sense, but what would cause buildd to start doing that for Backports builds?
<Amaranth> jdong: It's a conspiracy to close down backports! ;)
<jdong> lol
<ogra> Amaranth, damned, you discovered it ?
<mdz> jdong: interesting.  that's one for lamont or infinity
<jdong> alright
<YokoZar> Here's an open question ~Wine: right now, it doesn't build on AMD64, but that might change with a version between UVF and some other milestone.  Would that be worth upgrading?
<mdz> it depends on the circumstances
<ogra> YokoZar, if you dont sell it as a new upstream version, yes :)
<ogra> and if its not to intrusive indeed
<mdz> Znarl: us.archive seems much better now, thanks
<YokoZar> Well, hopefully and ideally, the Wine release to use would contain no regressions vs all previous releases (ie: stable)
<Kamion> mdz: considering it's == archive ...
<ogra> but even if i am amd64 user, a rocking stable wine for x86 would be more important imho
<mdz> Kamion: ah, so it is
<mdz> still a great improvement
<mdz> a stale mirror is sometimes worse than none at all
<mdz> i expect a bunch of US users are going to have massive dapper upgrades today ;-)
<Amaranth> whoops, gotta go
* tseng has long given up on us.a.u.c
<mdz> it was quite nice for a while there, very fast
<jdong> us.a.u.c was/ (is) also missing breezy-backports
<jdong> I got flooded with complaints about that
<jdong> and recently has lots of md5sum mismatches
<HiddenWolf> couldn't it be that the main archive is used heavily, preventing some mirrors from syncing nicely?
<elmo> us.a.u.c is back at archive.u.c 
<elmo> and will be till it's permanently fixed
<elmo> HiddenWolf: no
<HiddenWolf> I've had it with nl.a.u.c myself.
<YokoZar> elmo: hey, can you remove two packages from the repository for me?
<YokoZar> I sent out an email regarding them a while ago (winesetuptk and xwine)
<elmo> YokoZar: where did you send mail to?
<YokoZar> ubuntu-devel
#ubuntu-devel 2006-11-20
<mako> jdub,jordi: i have a copy of that newspaper.. not scanned
<jdub> mako: cool! someone scanned it tho, but don't remember where the image is
<mako> jdub: if you want me to scan it, i can take it into my lab tomorrow and do it
<jdub> mako: that'd be rad - thanks!
<mako> jdub: cool
<lifeless> BenC: ping re bug 71575
<Ubugtu> Malone bug 71575 in linux-source-2.6.19 "/proc/sys/vm/drop_caches should be able to be configured to allow regular user writes" [Undecided,Rejected]  http://launchpad.net/bugs/71575
<_ion> Hmm, is there a reason for linux-meta/feisty still depending on 2.6.17?
<lifeless> it just hasn't been updated
<infinity> Won't be until the world is in a sane(ish) state.
<lifeless> theres an ABI break in drm anyhow, you need to upgrade to 2.6.19 
<infinity> This week, I suspect.
<lifeless> ... if you have a graphics card which X uses that for
<lifeless> hi infinity 
<infinity> Yo.  Just got home.
<infinity> Considering a very long nap.
<lifeless> infinity: likewise. *yawn*.
<Hobbsee> hey infinity 
<Hobbsee> hey lifeless 
<zul> hey infinity 
<lifeless> ~
<lifeless> infinity: should I subscribe you to these bugs we discussed ?
<infinity> lifeless: Yes, please subscribe me to them.
<infinity> lifeless: I won't promise coherence (or even response) until tomorrow, but s'ok, I don't expect you to survive much longer today either. :)
<lifeless> infinity: exactly :)
<dsas> lifeless: In bug 72501 I'm guessing you've subscribed the wrong infinity
<Ubugtu> Malone bug 72501 in Ubuntu "missing depends entries for X video drivers" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72501
<lifeless> oh foo
<Mez> hmm
<Mez> lib -dev packages should depend on the lib right /
<Mez> nvm
<Lathiat> Mez: generally yeh
<Mez> Lathiat, I pulled a lib-dev package and I thought it wasnt linked to a lib, but it was
<fabbione> _ion: no, i am not maintaing lvm 
<fabbione> _ion: btw.. that's not the only issue we are having with initramfs at the moment
<fabbione> _ion: it looks like udev is not even executed before mdadm that has the correct dependency
<fabbione> _ion: i will need to check with Keybuk once he is alive
<Mithrandir> fabbione: all that will be solved once Scott makes udev call the initramfs scripts, etc.
<_ion> fabbione: Hm, at least that patch made my system boot again.
<_ion> I.e. at least on my system the udev stuff gets started before the lvm stuff.
<fabbione> Mithrandir: yes i know. that's why i am not bothering about it at all
<fabbione> _ion: on my system mdadm is still called before udev and i can't boot. I need to fiddle manually
<fabbione> _ion: for some reasons on mine doesn't.
<_ion> Ok, on this box i'm not using md.
<fabbione> _ion: i am
<fabbione> _ion: and don't bother too much
<fabbione> Keybuk will fix all of this pretty soon
<_ion> Ok. :-)
<sivang> morning
<mzli> afternoon.
<glatzor> hi sivang
<sivang> hey glatzor , how you doing?
<glatzor> my first free day after two weeks :) so I am fine. and yourself?
<sivang> glatzor: pretty good, thanks :)
<zOrK> does anybody has a broadcom wireless card?, I've built a patch and I'd like to see if it works..
<_ion> This is definitely impressive. Beryl actually works with a nvidia 8000-series driver.
<Treenaks> _ion: but does it work with Via Unichrome chips?
<_ion> I have no idea.
<mnepton> dear God. please send me a pony. and deliver me from half-baked compositing. love, mnep.
<niktaris> still looking for a way to add the keyboar indicator sto the gnome panel via the command line. Anyone has some idea ?
<cjwatson> Burgundavia: re your question ages ago, see the installation-guide-$arch package (e.g. installation-guide-i386) for current Kickstart documentation
<niktaris> after recompiling gfxboot with DEFAULT_LANG=el I only get Greek and English language selection with F2. What am I doing wrong ?
<cjwatson> ogra: libasyncns binaries will be in the archive shortly
<ogra> cjwatson, great ... thanks :)
<cjwatson> niktaris: don't recompile it; just put 'el' in /isolinux/lang on the CD
<cjwatson> (or that might have to be in the bootlogo cpio archive, I forget exactly)
<niktaris> hey cjwatson. will that give me the gfxboot menu in Greek too ?
<user__> I ghostimaged my ubuntu image to from a ata to s-ata hard disc, now i modified /etc/fstab and /boot/grub/menu.lst. However when I invoke update-grub it changes back to sda1 instead of hda1 as root= on the appendline in menu.lst in /boot/grub
<Hobbsee> user__: please read the /topic
<cjwatson> niktaris: should do
<cjwatson> at least in edgy
<niktaris> cjwatson, you wouldn't know how I can add  the keyboar indicator sto the gnome panel via the command line? Do you ?
<cjwatson> niktaris: no
* cjwatson <- not a desktop person
<niktaris> cjwatson, :)
<niktaris> cjwatson, did you get my email btw ? (just checking)
<cjwatson> niktaris: I've got about a million e-mails in the last two weeks and I'm hopelessly behind. If it's important, resend
* Hobbsee sends cjwatson 50 billion emails with that quote in it.
<cjwatson> I don't see it in my inbox, but if it was sent in the last few days, my home server has been offline and is still catching up
<niktaris> I'll ask you in a few days again. if not I;ll resend
<cjwatson> consider whether a mailing list might be more appropriate
<niktaris> I generally avoid mailing lists. 
<StevenK> cjwatson: I was pondering bugging you to see if an upload is sitting in the queue. If you're too busy just say so, and I'll deal.
<cjwatson> niktaris: I mention because you seem to be considering me as a person to ask about any possible problem (c.f. the keyboard/GNOME question) and that's not appropriate
<Hobbsee> cjwatson: what, you *dont* know everything?
<cjwatson> StevenK: there are nearly 1300 items in NEW; I'm working on it. I think you should be able to see https://launchpad.net/distros/ubuntu/edgy/+queue
<StevenK> cjwatson: Even for -proposed?
<niktaris> cjwatson, I had the impression that you know everything :)
<cjwatson> StevenK: dunno
<cjwatson> niktaris: well, I don't, and if I get asked about everything I'll just start ignoring the questioner, so ...
<cjwatson> StevenK: that would be /dapper/+queue and select unapproved
<cjwatson> or er /edgy/+queue
<niktaris> cjwatson, I try to keep it to ubuquity and releated
<StevenK> cjwatson: Unapproved doesn't appear in the drop down.
<cjwatson> StevenK: unlucky, then :) ask me later
<fernando> moin
<cjwatson> niktaris: then mail is fine
<StevenK> cjwatson: Sure. To be honest, I'm not even sure if it has been uploaded (since I have no rights for main), so I'll confirm that first. Sorry to bug you.
<niktaris> cjwatson, the mail was about casper and ubuiquity only :)
<cjwatson> "ubiquity"
<niktaris> yes :)
<niktaris> strange name :)
<cjwatson> look it up in the dictionary
<niktaris> there are several issues with casper and ubiquity regarding lang/keyboard support. I' ll try to at least bugreport some of them
<Spads>      2. (Theol.) The doctrine, as formulated by Luther, that
<Spads>         Christ's glorified body is omnipresent.
<Spads>         [1913 Webster] 
<gnomefreak> cjwatson: its not possible to run live cd in terminal is it? like stick disk in boot it up at the menu screen choose to run it in terminal. right?
<cjwatson> gnomefreak: no
<gnomefreak> ty 
<realist> you could always use ctrl+alt+f1
<fabbione> _ion: i tested that lvm fix, it's an interesting thing.. if prereq can't be satisfied, initramfs just goes banana
<fabbione> _ion: anyway working on an upload now
<fabbione> ajmitch: ping?
<StevenK> fabbione: Keep in mind it's 12:22am in ajmitch's $TZ
<fabbione> StevenK: yes i know but he is awake sometime at this time
<ogra> giskard, ping ... if you have a new g-p-m ready, upload it somewhere and point me to it ... i'll push it to the archive then ... ;)
<ogra> s/ping/pong/ (indeed)
<spike> hi there
<spike> I'm using preseeding to install dapper boxes. for most of the answer I've used the debian preseed example file, and it works nicely
* Treenaks feels a 'but..' coming up ;)
<spike> now I've got some problems with a couple Q/A's I'm not sure about, so the question is: how can I dump Q/A's for the whole installation process?
<spike> :)
<spike> obviously I cant run debconf-get-selections post install, because Q/A's about install process wouldnt be there
<spike> and I'm failing to find a complete list of all possible Q/A's anywhere
<spike> I could read the sources but I was hoping for something quickers
<spike> quicker*
<spike> and if I had to read the sources, what package should I look into?
<spike> some udeb I 'spose
<cjwatson> spike: see the installation-guide-i386 package
<cjwatson> spike: use that in preference to the Debian preseed file
<cjwatson> spike: furthermore, your "obviously" isn't
<cjwatson> spike: 'debconf-get-selections --installer' looks at the saved debconf database from the installer
<spike> cjwatson: oh, I'm sorry for that
<spike> thanks
<spike> I assumed questions from the installer werent left into the database after installation
<cjwatson> it's a separate database
<spike> cjwatson: but if I wanted to see the questions as they are asked during the install process which package shuold I look at? I've apt-got source debian-installer, assuming the install process, included Q/A's, were covered there
<spike> because, for example, 2 mins ago there was some network glitch, and it failed to contact the security mirror, which popped a dialog about commenting it out etc, which was expecting me to hit enter
<spike> that is something my preseed file wouldnt ever catched... but I'm still debugging so I had a monitor plugged in
<spike> mmmh, and as far as I can see from the output of debconf-get-selections --installer that question isnt covered in there
<spike> is that because that's never been asked for?
<cjwatson> spike: it's spread through a very large number of packages
<cjwatson> spike: the easiest approach is really to start with checking out the upstream source from svn://svn.debian.org/svn/d-i/trunk/ - there are changes in Ubuntu, of course, but that will get you the general structure and nearly all the packages
<cjwatson> then you can use 'apt-get source' on individual packages of interest to get the Ubuntu source for comparison
<spike> k, whill check it out, thanks
<spike> bah, bizarre, been reinstalling for hours and since 5 mins I keep gettting "bad archive mirror"
<cjwatson> it's not entirely unknown for mirrors to get out of sync for a bit - ISPs' "transparent" proxies often don't help matters either
<cjwatson> Keybuk: FYI I've been churning through NEW all day - 700+ down, about 600 to go
<Keybuk> cjwatson: sweet
<cjwatson> it's a nice mindless task I can do when non-functionally tired
<Keybuk> heh
<Keybuk> I cheated, and booked today and tomorrow off as holiday
<Keybuk> though I'm hestitant to use such words as "today" and "tomorrow", since I still think yesterday was Saturday
<cjwatson> Keybuk: get off work IRC and go and relax, then :)
<Keybuk> cjwatson: I'm bored of relaxing :)
<mjg59> Keybuk: Had a chance to test that patch I sent?
<Keybuk> mjg59: LLU has been down since last week (exchange fault), so the patch is almost certainly still on your SMTP server ;)
<mjg59> Keybuk: Ha.
<mjg59> Keybuk: If I stick it on the web, any chance you can give it a go?
<Keybuk> mjg59: not today
<mjg59> Ok, no problem
<Keybuk> I haven't spoken to mdz yet, but the general plan wrt compiz/beryl is to have them both in universe, or even main, and make the decision as to which shall be the default at Feature Freeze based on how well they've been developed and supported until then, and how well they work
<mjg59> Keybuk: It turned out to be slightly nastier than I thought - I effectively need to translate the keys back and forth
<mjg59> But once I'd built the table, it just worked
<mjg59> Keybuk: But yeah, that sounds sensible
<spike> bah, I've googled for a while now but it doesnt seem I cant find an answer: what can I do to have PXE booting to fail and the box moving on and boot from the HD?
<spike> because even removing the pxelinux.cfg/default|HEX wont make it fail
<spike> it'll just sit there at a boot prompt
<spike> the only ways I've found are either removeing pxelinux.0 or stuff in the dhcp entry
<Treenaks> spike: remove the PXE parts from the DHCP server :)
<spike> none of the two is really feasible for a production environment
<spike> Treenaks: eh, see my last-1 statement :)
<spike> not very nice to restart a dhcp server on a production env, and it's ugly anyway
<mjg59> Can't you just tell pxelinux to boot off hard drive?
<mjg59> Hm. Possibly not.
<spike> eh, apparently I cant, but maybe I missed something
<spike> that's why I was asking :)
<spike> the best approach seems to be having hd -> PXE and wipe out the MBR when you want to PXE boot
<spike> unfortunately that doesnt cope with an half/broken installation
<spike> but it seems to be the best bet
<Treenaks> goatse?
<ogra> there is something in the edubuntu wiki about it ... but dont ask me for the exact name of the page ...
<tkamppeter> How do I get a package removed from Main and either totally removed or moved to Universe?
<cjwatson> tkamppeter: what's the package, and why?
<cjwatson> in general, removing stuff from main requires (a) discussion (b) seed changees
<cjwatson> changes
<cjwatson> (c) archive administrator action (this bit is semi-automatic)
<tkamppeter> It is foomatic-filters-ppds, it got obsolete with CUPS 1.2 being able to auto-generate PPDs. Unfortunately, I did not find a way to find out in which repository it is.
<ogra> ogra@edubuntu:~$ apt-cache madison foomatic-filters-ppds
<ogra> foomatic-filters-ppds | 20061104-1 | http://us.archive.ubuntu.com feisty/main Packages
<ogra> foomatic-filters-ppds | 20061104-1 | http://archive.ubuntu.com feisty/main Sources
<ogra> (oh i need to update my sources.list :) )
<tkamppeter> Thanks, ogra, having foomatic-filters-ppds installed on current Edgy would lead to a mess: every printer/driver pair will be shown twice and the entry comimg from foomatic-filters-ppds can install an old PPD file, as foomatic-filters-ppds is most probably not as frequently updated as foomatic-db.
<Keybuk> lp_archive@drescher:~$ checkrdepends foomatic-filters-ppds feisty
<Keybuk> -- feisty/main hppa deps on foomatic-filters-ppds:
<Keybuk> edubuntu-desktop
<Keybuk> kubuntu-desktop
<Keybuk> ubuntu-desktop
<Keybuk> xubuntu-desktop
<Keybuk> amusingly, the only reason it's in main is because of hppa
<Keybuk> otherwise it would have been demoted
<cjwatson> that's not the only reason; it's in server-ship as well
<ogra> tkamppeter, i hope you mean feisty, not edgy there
<tkamppeter> The dependency can be removed from hppa, as the PPDs are provided by foomatic-db in Edgy.
<cjwatson> let me produce germinate output for feisty and then tkamppeter can learn how to look at that
<cjwatson> tkamppeter: you're not up to speed with the hppa situation
<cjwatson> in any case hppa does not block demotion
<tkamppeter> So if I take the dependency out of hppa foomatic-filters-ppds will disappear automatically?
<cjwatson> tkamppeter: how were you planning to do that? you need the hppa buildds to be operational first :P
<cjwatson> tkamppeter: but hppa *does not block demotion*. It's a red herring. Ignore it.
<cjwatson> tkamppeter: wait until I've got germinate output generated for feisty, and then you will be able to see clearly
<ogra> tkamppeter, it will show up here: http://people.ubuntu.com/~cjwatson/anastacia.txt and then an archive admin needs to edit the override file to actually demote it ...
<tkamppeter> So Keybuk was wrong and so foomatic-filters-ppds can be demoted? I suggest to remove it completely from the distro, to avoid having to keep two Foomatic databases in sync.
<cjwatson> tkamppeter: STOP
<cjwatson> tkamppeter: read all the things people are saying, and wait :-)
<cjwatson> we have heard what you said; I am generating output that will allow you not to have to guess at reasons
<cjwatson> repeating the point doesn't help
<cjwatson> http://people.ubuntu.com/~cjwatson/germinate-output/feisty/rdepends/ALL/foomatic-filters-ppds says:
<ogra> in any case you can only remove packages from feisty upwards ...
<cjwatson> foomatic-filters-ppds
<cjwatson> * Server-Ship seed
<tkamppeter> Sorry, I meant the removal to by done in Feisty and not in Edgy.
<tkamppeter> What does "* Server-Ship seed" mean?
<cjwatson> it means that the only reason foomatic-filters-ppds is in main is that it is listed in the server-ship seed, which is the list of packages to be included on the server edition CD in addition to minimal and standard
<cjwatson> I'll correct that seed now
<cjwatson> the same applies to linuxprinting.org-ppds
<cjwatson> ... actually no, linuxprinting.org-ppds is also explicitly listed in the supported seed. Should it be in main?
<cjwatson> tkamppeter: fix committed to the seeds, so it'll show up in the demotions list soon and we'll deal with it shortly afterwards; thanks
<cjwatson> tkamppeter: if you want a package removed altogether, file a bug on the package with an explanation and subscribe the ubuntu-archive team to the bug
<tkamppeter> linuxprinting.org-ppds should be in main, as it contains all PPDs which are not generated by Foomatic. It should be shipped on both live/desktop CDs and server CDs, so it should be in appropriate seeds.
<tkamppeter> Only foomatic-filters-ppds should go way.
<tkamppeter> Thank you for your help, cjwatson.
<tkamppeter> s/way/away/
<cjwatson> As we extensively discussed during the edgy cycle, linuxprinting.org-ppds doesn't fit on the desktop CD
<cjwatson> if it is to be included, it needs to be reduced in size somehow
<cjwatson> I'll put linuxprinting.org-ppds back on the server CD, as it fits there
<cjwatson> tkamppeter: what about hpijs-ppds on server? it was removed from desktop with the justification that those PPDs could be created on the fly, so I assume it can be removed from server too
<tkamppeter> Yes, it can really be removed. These PPDs are also generated automatically.
<cjwatson> good, my commit was correct then ;-)
<cjwatson> thanks
<tkamppeter> For the linuxprinting.org-ppds I had offered a split version to reduce the size during the Edgy development, but they told me that they have succeeded to get the full version onto the CDs. So the split version did not get uploaded.
<cjwatson> (the seed changes I made also need to be merged to kubuntu, edubuntu, and xubuntu, so won't show up in the demotions list right away)
* Riddell adds to the day's todo list
<cjwatson> tkamppeter: that was not the case for the final edgy images, and I'm certain we had a conversation about that
<cjwatson> we certainly talked about it on 2006-10-24, although it was too late for edgy by that time
<cjwatson> tkamppeter: the conversation on 2006-09-25 ended with me saying that I'd promoted linuxprinting.org-ppds to main; I cannot find any record of anyone saying that we'd found space for it on the CDs
<cjwatson> tkamppeter: it was accidentally reintroduced to desktop for nine days by Scott (misinterpreting what the Recommends in foomatic-db was for), but that wasn't really "finding space for it", because in the end that caused other things we needed to fall off. I'm sorry you were confused by the situation.
<tkamppeter> So then I suggest to introduce the splitting with the next build of linuxprinting.org-ppds which I will do, so that the most important PPDs go onto the Feisty CDs.
<cjwatson> tkamppeter: ok, please bring the seed change up again after that has been uploaded and built
<cjwatson> we can then assess the new size increase
<spike> base-config base-config/package-selection string ~tubuntu-standard
<spike> can anybody tell me what the ~t is for?
<spike> in the debian use it uses ~n, which sounds like regexp match on package name
<cjwatson> spike: ~t => task, ~n => package name; see the aptitude documentation on patterns. Also, base-config/package-selection is obsolete as of dapper.
<cjwatson> (it's pkgsel/install-pattern now)
<cjwatson> you also want ~t^ubuntu-standard$ rather than ~tubuntu-standard; I think the dapper documentation may have been a little bit out of date there
<spike> oh, thanks a lot
<cjwatson> of course in edgy it changed again ;-)
<spike> heh
<Amaranth> crap there was a CC meeting yesterday?
<cjwatson> that seems unlikely
<cjwatson> Amaranth: doesn't appear to have been
<ogra> Amaranth, i was wondering about that blog entry as well ..
<Amaranth> heh
<cjwatson> given that three of us were travelling back from the Canonical allhands meeting, it would have been an extremely odd date to pick
<Amaranth> I dunno if I'm even supposed to go to one of those.
<Amaranth> I was approved as a member a _long_ time ago but I just got my key signed and signed the CoC and such.
<ogra> cjwatson, http://blog.matid.net/articles/tag/ubuntu
<cjwatson> ogra: look at the blog itself: "Posted by Mateusz Drodyski 47 days ago"
<ogra> heh, seems like a planet bug then :)
<cjwatson> ogra: presumably the blog feed was broken in such a way that planet slurped it again
<gnomefreak> fabbione: we just got the updates for madam and lvm-common im gonna look into it a bit more but they are not configuring properly
<gnomefreak> fabbione: error output is at http://paste.ubuntu-nl.org/32942/ whenever you get a chance i have to run out for a bit but will be back in a couple hours
<fabbione> gnomefreak: mdadm edgy -> feisty upgrade. I haven't nailed down that one yet
<bddebian> Howdy
<spike> eer, apparently preseeding doesnt support https to retrieve preseed files from :(
<spike> can anybody confirm that?
<spike> I've changed the url to https and sniffing the traffic I dont even see a request going out
<spike> it fails immediately saying "Failed to retrieve the preconfiguration file"
<spike> but in reality it doesnt even try
<spike> probably 'cause it doesnt understand ssl
<cjwatson> spike: correct; busybox wget only supports http:// and ftp:// URLs - if you look in syslog I expect you'll see an error message including "not an http or ftp url"
<spike> so, what udeb shall I rebuild?
<spike> 'cause I guess that's the only way out
<cjwatson> er - it's not a matter of a simple rebuild. You'd have to write code
<cjwatson> the source package is busybox
<cjwatson> you would then have to rebuild the installer initrd as well (done by the debian-installer source package)
<cjwatson> it might be easier to use initrd preseeding (/preseed.cfg file on the initrd) for anything you don't want going unencrypted over the network
<cjwatson> consider whether you can actually effectively secure PXE in the first place, though ...
<spike> it wasnt really because of sending important info, I'm just bringing up a basic box, the work is done then by cfengine/puppet
<spike> but I had a nice layout with preseeding fetching stuff from an svn repo setup with webdav
<spike> so it played all together
<spike> without extra working copies laying around and the like
<cjwatson> spike: you can use WebDAV over plain HTTP as well, without SSL
<fdoving> is there a website where one can monitor the uploaded-packages-queue for edgy-proposed? 
<cjwatson> fdoving: not a public one, I'm afraid
<fdoving> cjwatson: ok, can you check on kopete for me please? 
<cjwatson> fdoving: I haven't looked at that SRU yet - still tired from travellling
<cjwatson> -l
<cjwatson> it remains in my inbox queue
<fdoving> cjwatson: mdz approved it, imbrandon uploaded yesterday.
<fdoving> so you can remove that from your todo.
<cjwatson> fdoving: ok, thanks. It's in edgy-proposed; I will look at it when I'm actually awake enough to do so safely, i.e. not today.
<fdoving> cjwatson: ok, one more quick question before you go to sleep, should edgy-proposed packages be versioned ubuntuX.X? will edgy-proposed version and the feisty version conflict if they have the same version number? 
<cjwatson> version numbers in different releases must be different
<fdoving> cjwatson: so the updates should be versioned ubuntuX.X ? 
<cjwatson> depends on what the current feisty version is
<cjwatson> or what it's next going to be
<cjwatson> as StableReleaseUpdates says, you should take care to avoid version number clashes. I'm not going to attempt to prescribe anything stricter than that
<fdoving> well.. current feisty version is 4:3.5.5+kopete0.12.3-0ubuntu3, the -proposed version is the exact same. what happens now?
<spike> cjwatson: sure but it's pointless, I'd still need another vhost:80
<cjwatson> fdoving: I'm rejecting the upload in -proposed now.
<spike> well, it would avoid the WC, indeed
<cjwatson> fdoving: you'll have to get it reuploaded with a version number that doesn't clash
<fdoving> cjwatson: will do, thanks :)
<spike> yeah, sorry, it's a bit better as it would save me the hassle of the workingcopy
<cjwatson> fdoving: (yes, -0ubuntu2.1 would be fine in this case)
<fdoving> cjwatson: changing it now. thanks again.
<keescook> fdoving: I've started making lists of the version numbering schemes we use for security updates; it's very similar.  Check out SecurityUpdateProcedures.
<fdoving> keescook: ok, i'll have a look. 
<polytan> hi
<giskard> mjg59, do you know why we have 55-lid-state-tracking.patch
<giskard> in gnome-power-manager
<spike> cjwatson: I've researched a bit about busybox and debian preseeding just to be sure, but isnt the case that debian has got some patches that allow https?
<cjwatson> spike: no, we're up to date with Debian's busybox
<cjwatson> (see http://merges.ubuntu.com/main.html)
<Burgwork> cjwatson: thanks for the info about the installation help
<cjwatson> np
<cjwatson> spread it around - people who have been around since <=breezy generally seem to have trouble finding where the manual moved to
<sbalneav> Hmm, this seems serious:
<sbalneav> root@oin:~# aptitude install xcb
<sbalneav> The following packages are BROKEN:
<sbalneav>   x11-common 
<sbalneav> The following NEW packages will be installed:
<sbalneav>   xcb 
<sbalneav> 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
<sbalneav> Need to get 21.6kB of archives. After unpacking 127kB will be used.
<sbalneav> The following packages have unmet dependencies:
<sbalneav>   x11-common: Conflicts: xcb (<= 2.4-4) but 2.4-4 is to be installed.
<sbalneav> Resolving dependencies...
<sbalneav> Unable to resolve dependencies!  Giving up...
<sbalneav> rodarvus: ping
<rodarvus> sbalneav, pong
<rodarvus> sbalneav, is this feisty already, or edgy?
<sbalneav> Any ideas?
<sbalneav> edgy
<sbalneav> the BROKEN bit was what scared me :)
<rodarvus> there is a library called xcb on X.Org, but this library is not supposed to be referenced on edgy
<sbalneav> xcb's a cut buffer program, seems to be in universe, so I'd expect it'll be MOTU packaging problem, maybe.
<rodarvus> let me confirm
<rodarvus> I don't think its a problem in xcb, actually
<rodarvus> hmm, no
<rodarvus> actually, xorg (which contains x11-common) conflicts with xcb <= 2.4-4
<rodarvus> and this is the version we have on the archives
<rodarvus> xorg is partially inherited from Debian (including this bit)
<bluefoxicy> no matter what I do to /etc/ld.so.conf or LD_LIBRARY_PATH I can't get gaim to load with the debug symbols for gtk+
<alex-weej> can someone suggest a better package than "pkgsel" for this bug, please? https://launchpad.net/distros/ubuntu/+source/pkgsel/+bug/68867
<Ubugtu> Malone bug 68867 in pkgsel "System freeze up during edgy installation" [Undecided,Unconfirmed]  
<alex-weej> my friend is experiencing it, too and it's preventing him from receiving free software goodness
<Treenaks> have you tried the alternate CD?
<alex-weej> it was the first thing i suggested
<alex-weej> awaiting a clear answer
<alex-weej> no he didn't - he bottled it because the installer is confusing
<alex-weej> quote unquote...
<alex-weej> Treenaks: he actually just wants to run the LiveCD after-all.
<ajmitch> morning
<zch> hi
<tormod> alex-weej, I would file it on the kernel in the first place, since it locks up.
<bluefoxicy> Is there a kernel debug package that provides uncompressed vmlinux (not vmlinuz)?
<MacSlow> Greetings everybody!
<MacSlow> How can I check in Malone if a certain kernel bug (actually a sata-driver bug) was fixed or not?
<LaserJock> MacSlow: you can use the advanced search
<LaserJock> MacSlow: or do you know the bug number?
<MacSlow> No I only know what issue I have here (dmesg reports to me)
<MacSlow> I'm trying to install 6.10 on a sata-only system and partitioning/formating the hd fails or rather hangs due to some bug
<LaserJock> MacSlow: you can try https://launchpad.net/distros/ubuntu/+bugs?advanced=1
<LaserJock> MacSlow:  and add "Fix Released" under status and importance
<MacSlow> hm... I've not found the issue I run into here to be filed in Malone (it seems)
<LaserJock> MacSlow: go ahead and file one them
<MacSlow> due to the report from dmesg I'm unsure what to call it... 
<MacSlow> LaserJock, that's the stuff from dmesg -> http://macslow.thepimp.net/sata-bug.txt
<MacSlow> so will it be sufficient to call it a sata-driver bug?
<LaserJock> I guess, I don't know either
<MacSlow> LaserJock, I'll try to be as verbose as possible in the bug-report
<bluefoxicy> PISSING ME OFF
<pygi> bluefoxicy: shhhh
<bluefoxicy> Malone 72630
<Ubugtu> Malone bug 72630 in xserver-xorg-video-via "Xorg Via driver DRI OOPS" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72630
<pygi> can't help ya =)
<bluefoxicy> damnit
<bluefoxicy> the debug packages are so friggin' broken.
<troy_s> who would i speak to regarding freetype2 dev libraries on edgy?
<LaserJock> troy_s: it probably depends on what you want to speak about
<LaserJock> troy_s: find a bug?
<troy_s> freetype/include/internal appears to be missing files
<troy_s> from libfreetype2-dev
<LaserJock> troy_s: I'm guessing https://launchpad.net/distros/ubuntu/+source/freetype/+filebug is what you want then
<troy_s> thank yo
<bluefoxicy> sweet, got it working.  I need cairo symbols
<stewski> is anyone from canonical in?
<stewski> please look this up
<stewski> http://opensourceacademy.gov.uk/solutions/casestudies/birminham-city-council/
<stewski> http://opensourceacademy.gov.uk/solutions/casestudies/birminham-city-council/file
<stewski> there is detail on the recently reported (as failed) FLOSS roll out
<HrdwrBoB> that doesn't sound like failed to me
<stewski> its getting reported as such which is a real shame
<stewski> as the document details some really positive result
<stewski> especially around open office
<stewski> but I thought feed back and comments might be useful for the development team and canonical
<crimsun> how much of it is directly relevant to Ubuntu? It looks like SLES was used.
<bluefoxicy> Any chance of libcairo getting a -dbg package backported to edgy
<StevenK> bluefoxicy: Why not use pitti's ddebs?
<bluefoxicy> StevenK:  link.
<bluefoxicy> actually I must go to class
<stewski> not much crimsun although I've read elsewhere that ubuntu was one of the preferred desktops from early user testing
<stewski> but it was not carried forward
<bluefoxicy> http://rafb.net/paste/results/SktUs157.html for the interested.
<bluefoxicy> Line 20 has my attention.
<stewski> the reason I'm posting it here is there are valuable lessons to be learnt about how the OSA and UK government are looking at linux desktops and maybe a lesson can be learnt for canonical pitches for support etc?
<keescook> bluefoxicy: deb http://people.ubuntu.com/~pitti/ddebs edgy main
<pygi> jdong: how can you doubt my packages? ^_^
<jdong> sorry pygi , I don't know what I was thinking :)
<pygi> jdong: ^_^
<jdong> pygi: hmm...... maybe it was something along the lines of "...There will ofcourse be a lots of bugs, problems and such...."
<jdong> :D
<pygi> jdong: what's wrong with that? :)
<pygi> jdong: you always have me to fix burning stuff
<jdong> :)
<jdong> pygi: ok, problem number one, oh great master, I keep on putting DVD-RAMs in my CD-ROM drive and mkfs.ext3 doesn't work on it
<jdong> fix it :)
<jdong> (my address is 4433 Mark st, ....)
<pygi> jdong: heh :P
<jdong> (fedex preferred)
* pygi shoots jdong down =)
* jdong quietly SIGKILLs ettercap and looks around innocently
<pygi> very nice LOL
<jdong> ooh what's this button do?
#ubuntu-devel 2006-11-21
<mpt> Who works on kickstart?
<pygi> jdong: so everything working fine? :)
<jdong> pygi: well , with one test project yes
<jdong> I'm still testing
<pygi> jdong: bleh, who needs testing ^_^
<jdong> but I'll let it thru backports since you seem so confident :)
<neuralis> mpt: kamion, i imagine
<pygi> jdong: ^_^
<mpt> ta neuralis 
* lamont_ grumbles and tries to remember why gdm would say 'The system administrator has disabled access to the system temporarily"
<HrdwrBoB> probably because the system administrator has disabled access to the system temporarily :)
<HrdwrBoB> /etc/nologin?
<Mithrandir> lamont_: /etc/nologin?
<HrdwrBoB> snap
<lamont_> no such file
<lamont_> HrdwreBoB: I most certainly did not (intentionally) disable access
<lamont_> then again, I was silly enough to upgrade to edgy
<twb> Good day.  I build modified live cds, and I'm migrating from Knoppix to Ubuntu as a base.  Where is the code on the etch livecd that sets up dhcp ethernet?  Somehow I'm losing it when I modify the image.
<lamont_> ah... it's all fallout from ldap going completely belly up
* lamont_ switches screens
<twb> Hmm, never mind.
<twb> Ethernet is working again in my modified CD; perhaps I was just being impatient before.
<Adri2000> Mithrandir: pppoeconf? I also filed a bug for that, #72370
<lamont> Mithrandir: ldap in nsswitch.conf seems to be bustificated in edgy.
<lamont> how very bizare...
<lamont> getent works, but finger doesn't....
<Burgwork> lamont: yes, and that is a bad thing
<Burgwork> means I need to keep a feisty client to test, so this sort of thing doesn't happen again
<lamont> Burgwork: and more to the point, logging in doesn't...
<Burgwork> how something like snuck through, I have no idea
<lamont> Burgwork: I care about that for fiesty.... But for the moment, I just want to fix it so that I can upgrade the rest of the house to edgy...
<Burgwork> you run an ldap server just for your house
<Burgwork> ?
<LaserJock> Burgwork: maybe he has a large house :-)
<_ion> Since when is it wrong to use a ldap server for a small number of computers? :-)
<lifeless> infinity: around ?
<stewski> does the server contain a fridge ou?
<lamont> Burgwork: sure.  why wouldn't I?
<lamont> beats creating logins everywhere
<Burgwork> sure, if it is easy enough to setup
<lamont> Burgwork: trivial
<lamont> once you know how...
<dsas> and probably fun when learning how...for some definitions of fun.
<lamont> dsas: it wasn't too bad...
<keescook> lamont: got a few minutes to write up some docs?  I pulled my hair out this morning just getting a viable test server running to do security update tests.  :P
<lamont> keescook: well, step one is getting edgy to work
<keescook> lamont: heh.
<stewski> anyone seen how samba is getting on with Active Directory import?
<stewski> I was of the impression they were after in place import and replacement of domain controller functionality?
<ajmitch> lamont: yeah, libnss-ldap needs put into edgy-updates
<ajmitch> lamont: assuming it's the timeout issue for boot that you've struck
<lamont> ajmitch: I had timeouts... but the other part was that the login process can't find any users...
<lamont> iz this fixed already somewhere?
<ajmitch> er, I haven't come across that one, nor has it been reported
<ajmitch> gdm has some issues if you don't restart it
<ajmitch> but console logins have been fine in my experience
<Burgwork> gdm is pretty flaky
<lamont> pam_access.so might be the culprit in part
* lamont tries sid's libnss-ldap
<ajmitch> sid's one has fixes for timeouts
<lamont> I can't help but think that maybe it's trying to use SASL where I don't support it...
<ajmitch> you said that getent worked though?
<lamont> Restarting Name Service Cache Daemon: nscd/usr/sbin/nscd: option `--invalidate' requires an argument
<lamont> ajmitch: yep
<ajmitch> edgy living up to its name
<lamont> nscd was changed to require a table (passwd, group, hosts), instead of letting --invalidate do all of them.  or so it would seem
<lamont> so...  libnss-ldap 238-1.1ubuntu1 works (dapper), and 251-5.2 and -7 don't
<ajmitch> -7 doesn't? that's a worry
<lamont> ajmitch: in my configuration
<lamont> now to figure out what's so different
<lamont> sigh.  high touch differences
<_ion> Wow. Feisty was smart enough to inform that "The Wireless mouse device attached to this computer is low in power (14%). This device will soon stop functioning if not charged."
<Burgwork> _ion: that is gnome-power-manager in action
<_ion> I'm not sure whether HAL reported the mouse charge level in Edgy. 
<lamont> Burgwork: I'll try 253 just for giggles
<MacSlow> Gman, hi Glynn
<Gman> hey MacSlow 
<lamont> Burgwork: fixed in 253
<MacSlow> Gman, I might run into you (via email) regarding some hints I got from Paul Byrne when I met  him at the ubuntu developer summit
<lamont> 253     Luke Howard <lukeh@padl.com>
<lamont>         * fix crasher if an empty buffer is passed to
<lamont>           initgroups (glibc NSS only)
<Burgwork> lamont: excellent
<lamont> Burgwork: I bet that's it...
<Gman> MacSlow, ok cool, i know paul well
<ajmitch> afternoon Gman 
<MacSlow> re jdub 
<lamont> morning jdub
<ajmitch> lamont: thanks, hopefully the same behaviour can be seen in debian so it can be forced through there
<MacSlow> Gman, good to know
<Gman> hi ajmitch 
<keescook> mdz told me last week there may be a TB meeting on tuesday, but I can't find any mention of it anywhere.  anyone else heard anything?
<Mez> minghua, ping regarding your gpg key
<minghua> Mez: pong.  what's wrong with my key?
<Mez> I dont know - but I'm getting a "BAD signature"
<minghua> uh-oh.
<minghua> which file did you get the bad sig?
<Mez> your brasero upload - the email
<ajmitch> Mez: that's not unusual
<ajmitch> if launchpad has accepted it, the signature was fine
<Mez> ah, kk
<minghua> yeah, most likely some line break stuff
<lifeless> infinity: so, icheck is not able to be automatically used - it needs to much hooking-in.
<KnowledgEngi> hello
<KnowledgEngi> in this channel there is somebody that work in the ubuntu comunity???
<KnowledgEngi> somebody that is a ubuntu developer
<KnowledgEngi> becouse using synaptic is not possible to install a Low-Latency kernel
<KnowledgEngi> and midi softwares like rosegarden need a Low-Latency kernel
<sladen> KnowledgEngi: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+filebug
<sladen> KnowledgEngi: could you include information about what would need to be done---eg. the URL of patches, configuration options or GIT trees to apply
<sladen> KnowledgEngi: I believe that low latency patches are already in.
<crimsun> KnowledgEngi: it's addressed already in feisty
<KnowledgEngi> but i do not know if low-latency is sufficent 
<KnowledgEngi> is possible that rosegarden need particular kernel configuration
<crimsun> KnowledgEngi: it's much too invasive for breezy, dapper, and edgy
<KnowledgEngi> i have not other chanse
<KnowledgEngi> rosegarden need a particular kernel
<KnowledgEngi> and return me error about kernel
<crimsun> since when has rosegarden required a specific kernel?
<KnowledgEngi> The resolution of the timer of system is too much low Rosegarden has not found one source of the timer to high resolution for reproduction MIDI. This could mean that a Linux with one is being used kernel resolution of the timer too much low. It contacts your Linux distributor for having more information.
<KnowledgEngi> the translation italian-english is not perfect
<KnowledgEngi> becouse i used google translator
<KnowledgEngi> if you try to install rosegarden4 using synaptic and run it
<KnowledgEngi> you can see the error
<KnowledgEngi> in english
<KnowledgEngi> but my ubuntu is setted with italian language
<KnowledgEngi> i asked in the channel #rosegarden but nobody give me an answare
<KnowledgEngi> stupid midi
<KnowledgEngi> ufff
<KnowledgEngi> someone use rosegarden under ubuntu ???
<crimsun> please redirect to #ubuntustudio or #ubuntu
<fabbione> morning
<fabbione> ajmitch: ping?
<ajmitch> fabbione: pong
<fabbione> ajmitch: mdadm is fixed now.
<ajmitch> ok, thanks
<fabbione> ajmitch: if you can distupgrade you should be able to reboot just fine
<fabbione> ajmitch: you want to make sure to upgrade also lvm-common
<fabbione> and please let me know if it's still an issue
<jdong> what is the command to get a list of locally installed packages?
<ajmitch> upgraded them both earlier
<jdong> sort of like what synaptic shows under its locally installed / obsolete list
<fabbione> jdong: dpkg --get-selections *
<fabbione> ah locally?
<fabbione> no
<jdong> fabbione: that wouldn't work :D
<fabbione> that's the full list
<jdong> right
<fabbione> ajmitch: ok
<fabbione> ajmitch: did mdadm upgrade smoothly?
<ajmitch> I believe so
<jdong> any other suggestions? :)
<cjwatson> jdong: sudo apt-get install grep-dctrl moreutils; sudo dselect update; combine <(grep-dctrl -nsPackage -FStatus ' installed' /var/lib/dpkg/status) not <(grep-dctrl -nsPackage '' /var/lib/dpkg/available)
<cjwatson> requires bash; dselect update is required to get /var/lib/dpkg/available up to date
<jdong> cjwatson: thanks, now let me digest that :D
<cjwatson> actually you can get rid of the dselect update if you use this instead:
<cjwatson> combine <(grep-dctrl -nsPackage -FStatus ' installed' /var/lib/dpkg/status) not <(apt-cache dumpavail | grep-dctrl -nsPackage '')
<jdong> ah, so look in dpkg/status for packages not in apt-cache dumpavail
<jdong> makes sense
<cjwatson> correct
<jdong> `dpkg --get-selections | awk '$2 == "install" { print $1 }` would be identical to the first grep-dctrl call, right?
<infinity> No.
<infinity> selections don't mean something's installed.
<cjwatson> selections => desired state not actual state
<jdong> ok
<jdong> good point
<infinity> But "dpkg -l \* | grep ^i | awk '{print $2}'" works.
<jdong> haven't considered that
<jdong> infinity: I think I'll choose the pretty looking grep-dctrl call :D
<cjwatson> that grep-dctrl is technically a layering violation since /var/lib/dpkg/status is an implementation detail of dpkg, but ...
<jdong> meh, it works, I don't complain :)
<cjwatson> dpkg-query -W -f '${Package} ${Status}\n' | grep ' installed$' | cut -d' ' -f1
<cjwatson> ^-- bit neater I suppose
<infinity> I like mine better. :)
<jdong> ooh
<infinity> Less typing.
<jdong> lol
<cjwatson> infinity: I wasn't certain if it would deal correctly with very long package names
<cjwatson> looks like it probably does
<infinity> cjwatson: It does, because when dpkg-query output is sent to stdout, it exapnds the columns.
<cjwatson> ah yes
<infinity> Err, sent to stdin of another process.
<infinity> Whatever.
<infinity> Piped.  Brain.  Explode.
<infinity> I should have booked a week of VAC after the conferences.
<cjwatson> We should put moreutils in main. It's neat.
<keescook> infinity: any brain power available for the security LP uploads?  I've got people wondering why only edgy's update exists.  :)
<infinity> Isn't sponge one of yours?
<infinity> Or was that a joeyism?
<cjwatson> infinity: the concept was originally mine, although I believe it was rewritten, possibly by Tolef
<infinity> keescook: I'm working on it, drescher's dying from I/O contention, so I'm working on it rather slowly.
<cjwatson> er, Tollef
<jdong> wait a sec
<jdong> would that work if a local package is a newer version of a repository package?
<infinity> cjwatson: pee is cute.
<keescook> infinity: okay, cool.  is there anything you need from me, or do you see all the files you need?
<infinity> keescook: I should have everything I need.
<cjwatson> vipe is rather neat too
<cjwatson> though somebody without their brain screwed in made sponge able to output to stdout, which is just SILLY
<zakame> somebody pinged me?
<cjwatson> jdong: synaptic won't display that as obsolete/local either ...
<minghua> yay for moreutils in main.  I use isutf8
<keescook> infinity: okay, great.  I'm off to bed.
<jdong> cjwatson: really? I never noticed that
* jdong compares
<cjwatson> jdong: (at least, dselect never has, and I assume synaptic uses roughly the same algorithm)
* crimsun boggles at the ACCEPTed for flashplugin-nonfree_9.0.21.78~ubuntu1 immediately followed by a REJECTed
<jdong> cjwatson: oh but synaptic does :)
<cjwatson> well, that's much harder then. :)
<jdong> cjwatson: yeah, I got that much :)
<fabbione> cjwatson: when do you think you can merge lsb?
<cjwatson> fabbione: I'll do it later today
<cjwatson> didn't know it was urgent
<fabbione> cjwatson: that'd be great thanks.
<fabbione> no it's not urgent but i am fighting an issue in an init script where something in lsb is returning 1 on ubuntu but 0 on debian
<fabbione> and i can't exactly figure what it is
<fabbione> so i was hoping that a merge would fix that
<cjwatson> tell me what the init script is and I'll check it out when I do the merge
<cjwatson> it could just as easily be our usplash changes or similar
<fabbione> it's mdadm-raid but there is a workaround in place atm
<fabbione> oh might be yeah
<jdong> cjwatson: would it be a fair assumption that packages in main all end in ubuntu<number.number>
<infinity> There was just an LSB upload in Debian that fixed some return codes.
<cjwatson> jdong: no
<infinity> I saw it fly by on my buildd a day or three ago.
<cjwatson> jdong: "ubuntu" in a version number implies that we've locally modified it; no more, no less.
<fabbione> i can't find what provides log_to_console
<fabbione> that seems to be the culprit
<fabbione> infinity: yes i did try lsb from debian but it doesn't really help
<infinity>    * log_use_fancy_output() had unintended behavior under set -e.
<infinity>      (Thanks to Steve Langesek for the heads-up.)
<fabbione> infinity: but ya know.. mixing != not good
<cjwatson> fabbione: I'll check it out later.
<fabbione> infinity: already tested that
<jdong> infinity: speaking of buildd's, can you make it that -backports builds against -updates?
<cjwatson> fabbione: (I know where all the pieces live)
<infinity> fabbione: mdadm has a bunch of its own logging functions, doesn't it?
<fabbione> cjwatson: ok thanks, just bear in mind that our mdadm-raid will work (workaround in place) you will need the one from debian
<fabbione> infinity: only small wrappers. they are ok tho
<cjwatson> I'm capable of spotting workarounds
<fabbione> cjwatson: i am 100% confident in your God alike skillz.. otherwise i wouldn't have asked ;)
<infinity> jdong: Yeah, I can.  Can you mail that request to me?
<infinity> jdong: I can't do it RIGHT NOW, so a reminder would be good. :)
<jdong> infinity: will do :)
<cjwatson> -              log_problem "no $*"
<cjwatson> +              log_dev 0 $1 "no $*"
<cjwatson> I assume that's the workaround
<fabbione> yeps
<fabbione> log_problem is a wrapper in mdadm-raid
<fabbione> so is log_dev
<cjwatson> fabbione: yeah, it's just a bug in our lsb-base-logging.sh; I'll go through it all and make sure it's consistent
<cjwatson> but first, an hour or two more of sleep ...
<bluefoxicy> pitti's repo doesn't seem to have libfreetype dbgsyms
<infinity> bluefoxicy: One would assume that it hasn't been uploaded since we turned on that feature, then.
<bluefoxicy> infinity: it's got one of the most CPU-active pieces of code in it, apparently.
<bluefoxicy> somewhere around fifth on my list (only watching gaim, thunderbird, firefox,rhythmbox though)
<bluefoxicy> 00000000 40442     2.2060  (no location information)   libfreetype.so.6.3.10    gaim                     (no symbols)
<bluefoxicy> ^^^ I'd like to know what symbol that is :P
<infinity> Rebuilding it should do. :)
<bluefoxicy> I'll pass.  I can wait a few weeks.
<bluefoxicy> infinity:  I made strlen() 4 times faster
<bluefoxicy> apparently glibc contains an optimized one that deals in 4 byte words at a time instead of byte by byte
<bluefoxicy> and tries to use some funky analysis to find the null bytes
<bluefoxicy> for a 5 byte string it's 6 seconds for a naive algorithm vs 12 seconds for glibc's to do 10 iterations of 1,000,000,000 strlen() calls
<bluefoxicy> err, not 6 seconds, 1.75 seconds.. hang on.
<bluefoxicy> infinity:  http://rafb.net/paste/results/ojJGja70.html  Like that :>
<bluefoxicy> why am I even talking about this.
<bluefoxicy> http://rafb.net/paste/results/6JMwu456.html  my_strlen() is glibc, n_strlen() is naive, for anyone that actually cares about what I was babbling on about.  sleep.
<Mithrandir> lamont: libnss-ldap?
<fabbione> hey sabdfl 
<sabdfl> hey hey fabio
<Hobbsee> greetings sabdfl
<sabdfl> hi Hobbsee
<Mez> morning mark
<sivang> morning all
<pygi> hey sivang , you sleep too much ^_^
<sivang> hi pygi , nice to see you too 
<pygi> sivang: hehe ^_^
* sivang goes to see why n-d won't play nice with the merged remaining ubuntu changes
<Kagou> hi
<sjoerd> ogra: why does the ubuntu pulseaudio packaging disable jack and asyncns ? their not in main or so ?
<cjwatson> sjoerd: jack is AFAIK deliberately not in main, and asyncns got synced after the initial pulseaudio packaging (so can be turned back on RSN)
<sivang> Lathiat: around?
<sjoerd> cjwatson: ok, so jack will stay the pulseaudio debian <> ubuntu diff then
<Lathiat> sivang: ya
<sivang> Lathiat: I've found something similar to something I Need to patch in n-d, http://avahi.org/ticket/71 , but I can't seem to find DBUS_VERSION_{MAJOR,MINOR} in the source distro anymore, do you know if this has been completely replaced by DBUS_{MAJOR,MINOR}_PROTOCOL_VERSION with the switch to 1.0.1 ?
<cjwatson> sjoerd: that's my understanding, but only as an ftpmaster who wondered verbally what the same diff was for a couple of weeks back :)
<sjoerd> heh, ok :)
<Lathiat> sivang: thats done by avahi customly
<Lathiat> line 413 of configure.ac
<Lathiat>     DBUS_VERSION=`$PKG_CONFIG dbus-1 --modversion`
<Lathiat>     DBUS_VERSION_MAJOR=`echo $DBUS_VERSION | awk -F. '{print $1}'`
<Lathiat> etc
<sivang> Lathiat: I see, I might have to include something like this then, if it's not already included by upstream, thanks
<Lathiat> nps
<sivang> Lathiat: yep, upstream uses the same hack
<tepsipakki> shouldn't tg3 ethernet be supported OOTB on dapper? I can't install a Fujitsu Esprimo with it, edgy works
<tepsipakki> ie. it isn't detected on boot
<tepsipakki> (netboot)
* Fujitsu wonders why he would want to have Edgy installed on him in the first place.
<tepsipakki> heh
<tepsipakki> Fujitsu: you are safe ;)
<Keybuk> tepsipakki: lspci -n
<Fujitsu> Keybuk: Can I convince you to let gcl into dapper-proposed? Pretty please?
<tepsipakki> keybuk: doesn't work on the installation console, but I'll try with a live-cd
<Keybuk> Fujitsu: I don't deal with SRU
<chris77^> Hello. Where can I tell the Ubuntu installer to copy additional files and add new users to /etc/passwd as well as set some permissions?
<cjwatson> chris77^: preseed/late_command; see the installation guide for details
<Fujitsu> Keybuk: It's been approved by motu-sru...
<StevenK> Evidently, that's what he thinks. :-P
<Fujitsu> Apparently.
<StevenK> Fujitsu: I think approving also requires checking the uploaded source versus the debdiff in the bug report.
<Fujitsu> Probably, yes.
<tepsipakki> Keybuk: does it matter which version I use (dapper, edgy..)
<tepsipakki> ?
<tepsipakki> where did /proc/pci go, btw?
<StevenK>  /proc/pci is long dead.
<tepsipakki> ok, well it would be nice to have lspci in busybox, then :)
<Spads> try poking in /proc/bus/pci/
<tepsipakki> too cryptic
<tepsipakki> all it showed in human readable for was the uhci/ehci-stuff
<tepsipakki> forM
<cjwatson> tepsipakki: anna-install pciutils-udeb
<tepsipakki> oh .)
<tepsipakki> :)
<Fujitsu> cjwatson: Do /you/ do SRUs?
<tepsipakki> I'll try that
<cjwatson> Fujitsu: yes, but not *right* now :-)
<StevenK> Aww.
<cjwatson> fabbione: fixed your lsb-base bug
<Fujitsu> cjwatson: If you could do it when you have the time, it would be great.
<cjwatson> I will
<Fujitsu> Thanks!
<fabbione> cjwatson: thanks a lot
<tepsipakki> Keybuk: ok, lspci -n showed this for the network card: "000.... 14e4:167b rev. 02"
<gnomefreak> fabbione: thank you for the mdadm fix looks like it is fixed
<gnomefreak> might have spoke too soon
* hunger gets lots of lines starting with W: when upgrading mdadm.
<gnomefreak> yep
<Fujitsu> gnomefreak: What was the problem with your machine?
<fabbione> they are just warnings. nothing fatal
<gnomefreak> Fujitsu: nothing other than updating mdadm and lvm-common. others couldnt boot
<Fujitsu> Yes, I've noticed my machine now boots :)
<gnomefreak> now just a flash install issue
<fabbione> there is some stuff i need to discuss with madduck 
<fabbione> and wait for Keybuk to move some mdadm/lvm stuff into udev
* hunger is annoyed by python-sip4 not being able to get updated.
* gnomefreak keeps getting python crash popups although no py updates that i remember (annoying not important
<gnomefreak> apt seems to also be crashing
<user__> when using %post --nochroot (using kickstart) and untarring foo, the progressbar is not moving at all. Is this a known issue?
<Hobbsee> user__: please check malone
<gnomefreak> Hobbsee: up-to-date feisty does your apt segfault?
<Hobbsee> gnomefreak: hasnt so far, i just used it
<cjwatson> user__: there's no progress bar for %post unless you implement it yourself
<gnomefreak> ok let me try booting difffernet kernel (shouldnt help though)
<cjwatson> at least, no progress bar updates
<user__> cjwatson, that's odd, because it displays one.
<user__> ah.
<cjwatson> user__: yes, that's just the general finish-install progress bar
<cjwatson> I don't regard this as a bug
<user__> cjwatson, what file is it that would need modifcation?
<cjwatson> user__: well, (a) your %post script to source the debconf confmodule and add suitable db_progress commands, (b) finish-install to allocate a different amount of space for the progress bar
<cjwatson> user__: honestly, I'd just leave it alone - that progress bar is calculated based on the number of finish-install scripts that are available, and it's going to be pretty fiddly to change it
<user__> ok, i'm extracting a huge tarrbal there, is there a way to redirect the output to the install setup easly from %post?
<cjwatson> so one thing you could do is make the info messages change but not actually move the progress bar; that would be less fiddle
<user__> if a user that uses the product doesn't see a progressbar moving while the huge tarrbal is extracing the user could suspect the instalation failed/froze
<cjwatson> fiddly
<cjwatson> however, in order to do that you're going to have to arrange for a shell command to be called after extracting each file (note that this will slow down the extraction a lot if there are many small files)
<user__> I wonder if busybox is supporting this
<user__> feel free to elborate
<cjwatson> busybox? normal tar doesn't even support this easily - you'd have to get a list of all files and extract them each by hand
<cjwatson> you also need a debconf template somewhere that you can subst into in order to pass to db_progress INFO
<cjwatson> I suppose you could abuse one of base-installer's
<cjwatson> given that, it would be '. /usr/share/debconf/confmodule' at the top of your %post script, and 'db_progress SUBST base-installer/debootstrap/info/extracting SUBST0 "$filename"; db_progress INFO base-installer/debootstrap/info/extracting' before extracting each file
<tepsipakki> Keybuk: ping
<cjwatson> user__: I leave the tar integration up to you :-)
<gnomefreak> whats the chances of mdadm messing with apt/aptitude?
<cjwatson> gnomefreak: seems exceedingly unlikely
<gnomefreak> it was a long shot
<Fujitsu> tepsipakki: Note that Keybuk isn't actually in the channel at the moment.
<tepsipakki> duh
<mnepton> "tar integration" is a fantastic euphemism for UDS smoke breaks
<tepsipakki> missed that
<ogra> cjwatson, sjoerd, right i disabled jack on pittis request ... libasyncns will be enabled again if its ok for main (nobody seems to know exactly what its needed for) ...
<tepsipakki> while Keybuk is away does anyone know how I can debug further this tg3 madness.. lspci lists the device as unknown, but the ID is 14e4:167b
<cjwatson> that just means lspci's database is out of date, and is irrelevant
<tepsipakki> www.pcidatabase.com doesn't know about 167b either
<cjwatson> tepsipakki: your symptoms usually just mean that some kernel module needs to have the id added to its MODULE_DEVICE_TABLE
<tepsipakki> yes, tg3 doesn't have that in 2.6.15../modules.pcimap, but in 2.6.17 it is
<cjwatson> there you go then
<cjwatson> unless 2.6.15 has the new_id stuff in /sys, the only thing you can do is rebuild that module
<tepsipakki> and no hope for getting support added for dapper?
<cjwatson> tepsipakki: it's not necessarily impossible; talk to BenC
<tepsipakki> ok, I'll file a bug first
<Enola_Gay> hi all
<Enola_Gay> Is it possible to integrate in Feisty a grub repair function on cd/dvd?
<Enola_Gay> Since it is very hard for beginners to chroot and repair grub.
<realist> Enola_Gay: a GUI tool?
<Hobbsee|Remote> realist: wouldnt really help, if X were broken.
<Ng> unless it's on a live CD type install disc. also having grub and X broken is probably not a good sign ;)
<realist> I presumed they were talking about a live CD
<cjwatson> Enola_Gay: there's already such a function on the alternate install CD; boot in rescue mode
<Hobbsee|Remote> yeah well.  that being said, installing ubuntu first, and mounting the windows partition by default, then reinstalling windows, will stop your ubuntu from booting, and drop you in a rescue shell until you figure how to get out of it.
<Hobbsee|Remote> from edgy up
<cjwatson> on the desktop CD, we assume that desktop facilities will be available; if not, somebody who speaks the desktop's language should write them :-)
<Hobbsee|Remote> (that's after you reinstall grub, to fix the mbr that windows thrashed)
<realist> Hobbsee: ctcp?
<Hobbsee> realist: sorry, wrong button
<Hobbsee> realist: meant to do a whois, and missed.
<realist> oh, gui client?
<Hobbsee> realist: yes.  Hobbsee|Remote is irssi
<lamont> Mithrandir: libnss-ldap
<lamont> 253 (not yet packaged for debian) fixes things for our glibc
<realist> Hobbsee: no ssh/screen? :-(
<Hobbsee> realist: that's what the remote one is.
<Hobbsee> realist: i was dealing with some stuff with feisty here - didnt want to be d/c and reconnecting every time i restarted X and whatever...
<realist> I'll take your word for it ;-)
<BenC> milestone day for feisty...2.6.19 becomes default...fear my eminent bug surge
<Hobbsee> yay!
<rodarvus> BenC, all packages have already been accepted from NEW, built, etc?
<BenC> rodarvus: kernel is, lrm just now uploaded. As soon as it builds, linux-meta will follow
<Enola_Gay> realist: a GUI would be great but an grub entry on boot cd would be enough
<Enola_Gay> cjwatson: How it works? I think most people download the desktop cd so it should be there too.
<rodarvus> BenC, nice, I'll retry it on my fglrx machine in a few hours, then
<cjwatson> Enola_Gay: it's not feasible to add that particular code to the desktop CD, for complicated reasons; it would have to be a GUI facility on the desktop, which isn't really my domain
<Enola_Gay> cjwatson: Ok, but an easy to find function would be great.
<zul> hey
<Spads> hi zul 
<Spads> any luck with my xen problem?
<zul> nope still working on it
<pirast> does anyone have an idea where doko is?
<cjwatson> holiday
<Ng> he's rollerscating around america ;)
<pirast> ah nice :-) i am just wondering because there is a very annoying openoffice bug in edgy :-) but holidays are important, too :-)
<pirast> do you know when he will be back?
<Ng> monday I believe
<pirast> Ng, thanks
<cjwatson> he's aware of a number of openoffice.org bugs and I'm fairly sure there'll be an upload not long after he gets back
<cjwatson> I discussed them with him at allhands
<BenC> cjwatson: is it possible to get ports kicked so the ia64 build of linux-source shows up?
<cjwatson> BenC: that would be a sysadmin problem; surprised it hasn't happened automatically
<BenC> cjwatson: ok, thanks
<user__> <cjwatson> given that, it would be '. /usr/share/debconf/confmodule' at the top of your %post script, and 'db_progress SUBST base-installer/debootstrap/info/extracting SUBST0 "$filename"; db_progress INFO base-installer/debootstrap/info/extracting' before extracting each file 
<user__> cjwatson, it only displays: "extracing foo .... "
<user__>  i put  db)progress INFO ; tar xv... foo.tar.gz ; 
<user__> but still no go
<cjwatson> your report is garbled; please show me the exact code snippet (as short as you can, to avoid flooding this channel), and exactly what message you see
<user__> cjwatson, http://pastebin.ca/254110
<cjwatson> user__: it doesn't look as if you understood what I said. You need those db_progress commands before extracting each file in turn, not before the entire tar command. Like I say, I leave figuring out how to extract each file in turn up to you, but it's certainly not by just running 'tar -xvf /cdrom/stage4.tar.gz -C /target'.
<cjwatson> Running a single big tar command means that you have no opportunity to update the progress bar.
<user__> can I just redirect the output of the stage4 to the install screen?
<cjwatson> No.
<cjwatson> Well, not sanely. I suppose you could try, but I don't really want to offer help with ghastly hacks. :)
<cjwatson> the main install display runs on /dev/tty1
<user__> What options are left, i'm in the last stage, we are about to deliver 500+ ubuntu desktop pc's. Now if I leaf it as it is, the user might think that the restoring process is frozen/not working anymore.
<cjwatson> I've already offered a concrete suggestion; if you want good progress output, you need to use 'tar tf' to get the file list, and extract each in turn
<cjwatson> I'm confused as to why you aren't shipping the machines preinstalled
<cjwatson> the last three lines of your %post script are bogus
<cjwatson> #
<cjwatson> /bin/mknod -m 660 /target/dev/console c 5 1 ;
<cjwatson> #
<cjwatson> /bin/mknod -m 660 /target/dev/null c 1 3 ;
<cjwatson> #
<cjwatson> shutdown -r now 
<cjwatson> the system already handles creating /dev/console and /dev/null on boot (assuming you haven't broken udev), and you shouldn't shutdown at the end of a %post script - the installer will do that itself
<user__> cjwatson, because those are supposed to be recovery cd's.
<cjwatson> ok
<cjwatson> fair enough; you still shouldn't need to mknod stuff by hand though
<cjwatson> user__: you could also create a udeb for all this and include a debconf template in it that says "Restoring system; please wait..."
<cjwatson> and not bother fiddling with tar
<cjwatson> creating a udeb will be slightly more work in that you'll have to regenerate the Packages and Release files, but you may be doing that anyway
<cjwatson> any udeb with Priority: standard in its control file will be used by the installer by default
<user__> i'm using kickstart and preseed so only ubuntu-minmal get's installed.
<user__> hmm, i'll lookinto it.
<cjwatson> you'll need to learn some basic debconf programming, but not a lot, and there are plenty of examples in the archive
<user__> any example suggestions that would make life easier?
<cjwatson> user__: tzsetup, maybe? note the finish-install/progress/tzsetup template there; the end of that template name is derived from finish-install.d/05tzsetup, by stripping off the directory name and the initial digits
<cjwatson> you basically just need a debconf template, the debian/rules, debian/changelog, and debian/copyright build goop, and a debian/control that has Priority: standard and whatever else you want to call it
<cjwatson> drop the XB-Installer-Menu-Item from debian/control and drop debian-installer/tzsetup-udeb/title (or whatever) from the templates file
<cjwatson> and your finish-install.d script can just do the untar bit and whatever else you want
<Spads> ajmitch: ping
<zul> Spads: hes probably asleep 
<Spads> yeah, 'sokay
<cjwatson> mvo: any chance of another synaptic upload for edgy-proposed without the aclocal.m4 and configure changes?
<cjwatson> I'd be happier without trying to work out the possible effects of those
<mvo> cjwatson: certainly
<Mithrandir> lamont: https://launchpad.net/distros/ubuntu/+source/libnss-ldap/+bug/51315 maybe?
<Ubugtu> Malone bug 51315 in libnss-ldap "udevd: nss_ldap: failed to bind to LDAP server" [Unknown,Fix released]  
<cjwatson> mvo: thanks
<lamont> Mithrandir: I think 70146 is more likely
<lamont> otoh, the timeout issue was there too...
<lamont> apt-get -udy dist-upgrade
<lamont> The following packages will be REMOVED:
<lamont>   startup-tasks system-services ubuntu-base ubuntu-minimal upstart
<lamont>   upstart-compat-sysv upstart-logd
<lamont> The following NEW packages will be installed:
<lamont>   sysvinit
<lamont> 0 upgraded, 1 newly installed, 7 to remove and 0 not upgraded.
<lamont> what's wrong with that picture?
<lamont> maybe having dapper and edgy deb lines in /etc/apt/sources.list is a bad idea...
<lamont> yep
<user__> cjwatson, can the udeb be installed after %post ?
<user__> %post --nochroot 
<cjwatson> user__: that's not meaningful
<cjwatson> udebs are all installed considerably earlier, but when they're installed doesn't have much bearing on when code in them is run
<cjwatson> user__: Kickstart %post scripts are run from finish-install.d/01kickseed; anything later than 01 will be run after the %post script
<HarryR> heardly any of my shell scripts are working anymore after the upgrade
<trappist> HarryR: are they using #!/bin/sh or #!/bin/bash
<HarryR> #!/usr/bin/env sh
<Ng> sh on edgy is dash, not bash, so bashisms no longer work. change the sh to bash and you'll most likely be fine
<Ng> sh means you want a POSIX shell
<thom> (and this is entirely the wrong channel for support)
<HarryR> but don't you consider that's a politically bad decision to make the move from the de facto Bash shell to the less common de jure approach (have strict POSIX and like it!)
<Mithrandir> no, it's a good thing.
<Mithrandir> it's like saying that enforcing proper C++ is bad because some code breaks.
<Keybuk> bash isn't de facto anyway
* HarryR gives up the light troller'tainment and settles down
<thom> HarryR: note also that bash is only de facto on certain flavours of linux anyway
<HarryR> In the majority that I've used it certainly is
<sladen> when code is known to be of correct syntax, we can process it faster.  It's taken a few years, but the world has come around to this with CSS/XHTML.  POSIX shell is similar
<Keybuk> indeed, a reasonable number of Linux distributions and every other flavour of UNIX in the world don't use bash as /bin/sh
<thom> Keybuk: OSX does at this point (10.1 was zsh as /bin/sh iirc), but that's about it afaik
<Keybuk> zsh -> sh is just wrong :p
<Keybuk> zsh isn't even vaguely posix
<HarryR> yes but on the other hand it makes developers productivity slower
<Keybuk> HarryR: why does it?
<HarryR> think of how productive people were when they developed for IE alone
<Keybuk> developers develop to standards
<thom> (good ones, anyway)
<HarryR> all those features available, scrolling marques, brilliant effects which are only now being introduced into CSS 3
<HarryR> it's almost as if the standards based approach is keeping the industry back from real innovation
<Keybuk> note that bash is still installed in Ubuntu (it's still the default user shell), so nothing stops you using #!/bin/bash -- which is what you should have been doing before
<sladen> HarryR: yes exactly.  unproductive for the developers and massively unproductive for people trying to view the result with either (a) a different version of MSIE, or (b) something that wasn't MSIE.  Like a linux-based browser for instance
<mjg59> Could we not have this discussion here?
* HarryR suggests #flame-wars
<mjg59> There's -offtopic
* Ng suggests just not bothering because it's a dumb argument ;)
<HarryR> oh im only yanking your chain
<Spads> oh, then you want ##chainyank.  That's down the hall
<jdong> crimsun: Setting up flashplugin-nonfree (9.0.21.78~ubuntu1~6.10prevu1) ...
<jdong> download or license refused
<jdong> crimsun: the new flashplugin upload adamantly refuses to install
<jdong> regardless of my DEBIAN_FRONTEND choice
<jdong> crimsun: it seems to fill in /usr/lib/flashplugin-nonfree-unpackdir for already downloaded location, which in turn fails the download
<thom>  /usr/lib? seems utterly broken
<jdong> config: db_set flashplugin-nonfree/local /usr/lib/flashplugin-nonfree-unpackdir
<jdong> hmm
<jdong> It would seem like somehow the local path was already set
<jdong> crimsun: hmm, unsetting that makes it work again
<jdong> crimsun: I'm gonna assume it's a fluke on my system
<dade`> BenC: have you seen the query?
<BenC> yes
<cjwatson> jdong: try 'dpkg-reconfigure debconf' rather than setting DEBIAN_FRONTEND in the environment
<jdong> cjwatson: got it sorted out.. Somehow my debconf had already a preset nonexistant local flash directory
<jdong> which was coincidentally the same location as one in the debian/config script
<steveire> Hey. Is there some way I can know when my laptop makes a connection to the internet?
<jdong> steveire: I'm gonna get smacked for this, but have you tried using ping?
<cjwatson> steveire: scripts in /etc/ppp/ip-up.d/ are run when a PPP link comes up
<neuralis> steveire: try the #ubuntu channel for support in the future. that said, dhclient has callbacks (shell scripts) that you could use to run logic such as checking for an internet connection (e.g. by connecting to google).
<steveire> jdong: Wouldn't I need to run ping every minute/few minutes for that to be a solution? I'd like a scenario like this: Turn on laptop while not in a wireless zone. Walk into wireless zone. networkmanager connects. Networkmanager executes script.sh (The whole point of the operation)
<steveire> neuralis: Ah, right. Sorry
<cjwatson> ... but if this isn't PPP then neuralis' suggestion is more appropriate.
<steveire> cjwatson: I'll look into that. PPP means broadband, right?
<cjwatson> er, ish
<cjwatson> it's also used for dial-up
<steveire> Cheers. Bye now.
<thom> http://www.joelonsoftware.com/items/2006/11/21.html
<thom> interesting points
<cjwatson> BenC: do you have those Provides in fs-{core,secondary}-modules queued up? e.g. fs-secondary-modules Provides: affs-modules, fat-modules, hfs-modules, hfsplus-modules, nfs-modules, ntfs-modules, ufs-modules, vfat-modules
<Burgwork> thom: I would love to simplify it like that
<cjwatson> infinity: can builddmaster/accepted be cleaned out a bit? drescher is short of disk and there's 112GB in there
<slomo_> infinity: hi... please give-back tomboy and gmime2.2 everywhere where it failed, must build fine now... thanks :)
<cjwatson> BenC: if you could hold off on any further linux-source-2.6.19 uploads for a little bit, that would be good - drescher is running low on disk and another kernel upload would run it dangerously close to full
<ajmitch> Spads: pong?
<Spads> ajmitch: hello
<Spads> ajmitch: got a brief minute to chat about xen?
<ajmitch> yeah
<BenC> cjwatson: Ok
<jdong> pygi: brasero doesn't use libburn for burning iso's, does it...
<pygi> jdong: mhmh, it should AFAIK?
<jdong> pygi: well, on my edgy backport, ps aux still shows cdrecord.mmap's doing the job ;-)
<pygi> ergh, something is bad then :)
<pygi> jdong: will investigate tommorow :P
<jdong> pygi: at least your bugs still leave the program working :)
<jdong> pygi: you've earned my greatest respect for that ;-)
<pygi> jdong: ergh :P
<jdong> pygi: now, why does my FC6 lamp install start gdm?
<pygi> well, Brasero always does a fallback
<pygi> if it encounters any kind of problems
<jdong> I see
<pygi> jdong: tho it might be that some weird thing is happening at your place. I tried burning ISO file without any problems with no cdrecord
<pygi> jdong: might also be some weird bug so I'll just investigate ^_^
<jdong> pygi: would feisty libburn need to be backported to edgy?
<jdong> pygi: I'm testing on edgy here, not feisty...
<pygi> jdong: nah
<pygi> jdong: they are same versions atm
<jdong> mmkay, I'll stop pestering you with my libburn ignorance :)
<pygi> jdong: nah, you aren't, don't worry
<pygi> I'm grateful for any reports ... we need to have something usable in place of cdrtools
<pygi> and the infamous cdrkit
<Kaleo> raphink: bonjour
<pygi> jdong: so you are free to bug me whenever and for whatever at least burning related
<jdong> pygi: ok :)
<highvoltage> pygi: you rock man
<pygi> highvoltage: nah, you all rock ^_^
<highvoltage> pygi: any progress with getting specifications for those writers?
<pygi> highvoltage: nah :(
<pygi> highvoltage: still working blindly :-/
<pygi> and I have some problems with USB attached burning devices, and I have none to test on :-/
<highvoltage> I'm sure there must be a way to get them.
<pygi> (I mean, users are reporting problems)
<pygi> highvoltage: I know, but oh well :-/
<highvoltage> yep
<pygi> I'm helpless ... I don't have the drives or specs of Joerg ...
<pygi> but I have a wish, and that's all I need for now, everything else should be fine ... some day at least
<pygi> highvoltage: cdrkit CANNOT evolve, nobody is willing to mess with code
<highvoltage> well, as far as I understand it's big and ugly.
<pygi> true, but let's not care about them :)
<pygi> we should take care of libburn ;)
<highvoltage> indeed.
<pygi> so my task sometime soon is to try to get some sponsor for drives :P
<pygi> I doubt anybody local would help FOSS project (Croatia is bad in that regard), so will poke some people outside that I know
<pygi> for specs, we'll need a plan ^_^
* jdong kicks FC6 xen for not networking
<highvoltage> drives are cheap here. i'd even be willing to buy at least one drive and ship it over there.
<pygi> highvoltage: nah, don't worry.
<Ng> pygi: are there specific things that need testing? I have a couple of USB burners I could use
<pygi> Ng: there are actually, on different set of kernels...
<pygi> Ng: 2.6.19rc5 for example, and series of 2.6.18
<pygi> several oopses appear, and I have no idea what to suggest for testing since everything we tried didn't help
<Ng> pygi: I'm just upgrading my desktop to feisty now
<pygi> Ng: ok
<pygi> highvoltage: I have time for everything, for spec even. Libburn happened over night .... but I want it to stay here for some time ^_^
<pygi> highvoltage: lets just be patient ^_^
<highvoltage> pygi: I'm willing to be patient
<pygi> I know ^_^
<highvoltage> pygi: I do think that there are big benefits for pygi though
<highvoltage> I mean, libburn :)
<pygi> perhaps, we'll see :)
<highvoltage> and I think there are many who could benefit by funding the development
<pygi> As I already said, I think there are far better devs then me ...
<highvoltage> that's true for just about every developer :)
<pygi> true, but it's interesting why everyone is talking so much about burning sucks this, and that, bla, bla ...
<pygi> but nobody does anything
<highvoltage> yep
<pygi> for example, posted on forum call for opinions about should I include beagle dep in Brasero ...
<pygi> they started flaming me beagle is bad, that I should include tracker (which isnt implemented upstream!!!), and that they'll fork all projects if I don't , bla, bla :P
<highvoltage> well, that's what you get for posting to forums :p
<pygi> yes, I understand that ^_^
<pygi> but some kind of general opinion like that is everywhere ...
<pygi> you suck, we'll fork you altought we don't know a thing about this :)))
<pygi> cdrkit is one of biggest mistakes debian did
<pygi> altought I agree that cdrecord era could not be continued...
<pygi> Ng: I could use your services for testing later then if you are willing ^_^
<highvoltage> I'm not sure Debian had much of a choice.
<pygi> Yes, that's why I said that the cdrecord era couldn't be continued...
<pygi> but they rushed in it without too much thinking...
<Ng> pygi: certainly
<pygi> but anyway, I'm just exactly no one to judge about that
<pygi> Ng: thank you 
<pygi> I'm neither debian, neither I'm a ubuntu dev, or whatever
<pygi> so my opinion is worth 0 :)
<pygi> highvoltage: so feel free to ignore me ;)
<_ion> Re: brasero, i have a faint memory of someone talking about implementing tracker support to brasero. I could remember incorrectly, though.
<_ion> That is, someone planning to implement it.
<highvoltage> pygi: hey! I'm not ignoring you!
<pygi> _ion: yes, and forking ^_^
<pygi> highvoltage: I know, but I'm saying you are free to :)
<highvoltage> pygi: neither do I think your opiniong is worth '0'
<highvoltage> pygi: don't put too much value on what other people think
<pygi> _ion: let them fork whatever they want. Actually, I'd like to see can they change one line of code in libburn without breaking things ^_^
<pygi> highvoltage: don't worry for me :)
<_ion> The discussion i saw was *definitely* not about forking. I wish i'd remember *where* that discussion was. Perhaps the tracker or gnome-something mailing list.
<pygi> _ion: actually, me and Phillip talked about creating indexing abstraction layer. But it'll take some time even if we decide to implement it.
<pygi> _ion: gimme some time for things, I'm busy
<pygi> _ion: but I don't like the attitude that I *MUST* do something or *ELSE* ...
<_ion> pygi: AFAIK the tracker and beagle guys are planning a standard dbus API, which both of them are going to implement in the future.
<pygi> _ion: that's very nice.
<_ion> Who has such attitude? Some random people at the forums?
<pygi> _ion: ofcourse, lol ^_^
<_ion> You're better off ignoring the opinions people have there. ;-)
<pygi> ^_^
<vdepizzol> there is any plan to distribuite gaim in next ubuntu with a different icon theme?
<pygi> vdepizzol: what about apt-get-ing other icon themes? :)
<vdepizzol> pygi: gaim only accepts acctually one theme, because its icons are freely in /usr/share/gaim :\
<pygi> vdepizzol: artistic questions are well, at least debatable ... so default wherever we can, and make users know they have a choice ^_^
<pygi> vdepizzol: feel free to write a python script which'll change that. Make sure to rename all old files from something.something to something.something.backup and recreate new files in there ^_^
<pygi> vdepizzol: actually, should be quite trivial to enable changing theme in gaim.
<Adri2000> mvo: you've just uploaded the merge of pppoeconf... but I had already done it, was waiting on malone bug #72370 :-/
<Ubugtu> Malone bug 72370 in pppoeconf "[Merge]  pppoeconf 1.12ubuntu1" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72370
<vdepizzol> pygi: right
<pygi> vdepizzol: got it at least? :)
<pygi> vdepizzol: and second task is to bug upstream about making theme switchable ;)
<pygi> so we can see several benefits of work ^_^
<fdoving> anyone able to check status of kopete in edgy-proposed for me?
<vdepizzol> pygi: I really need to learn python :P...
<pygi> vdepizzol: well, you are free to start ... there are so much great books
<vdepizzol> pygi: Jackub Steiner created a icon theme for gaim following tango guidelines: http://www.gnome-look.org/content/show.php?content=40047
<pygi> vdepizzol: nice, but as I said ... you cannot get the taste of everyone with one option ... 
<vdepizzol> pygi: uhum
<pygi> vdepizzol: some love, some don't like default theme, but either is fine
<pygi> we provide you with everything you need to change theme ^_^
<pygi> hey BenC 
<BenC> pygi: hello
<mvo> Adri2000: oh, I'm very sorry :(
<mvo> Adri2000: I will fix it
<pygi> BenC: I shall bug one day soon if you allow. I need to know about some of SCSI commands filters in kernel, even the new .19rc5 
<Adri2000> mvo: fix it?
<mvo> Adri2000: look at the diff and see how it differs
<slomo_> BenC: hi... are there any known problems with the feisty kernel and DMA on via ide controllers that make hdparm just output "HDIO_SET_DMA failed: Operation not permitted"?
<Adri2000> mvo: except the changelog, I don't think it differs much :)
<mvo> Adri2000: oh, ok. I will double check. sorry for that again ./ 
<Adri2000> mvo: diff just confirmed what I thought: only the changelog differs. anyway, I forgive you :p
* mvo hugs Adri2000
<Adri2000> ;-)
<lifeless> mdz: so I have a crude email-gathering hwdb-client
<lifeless> mdz: doing some polish to make it acceptable next.
<imbrandon> moins all
<ajmitch> hi imbrandon 
<imbrandon> mdz: is there a way to get intouch with the forums council yet, or has it been formed, i've emailed a few times about the annoying google ad's on the forums but they seem to have not gotten through or have been ignored, i would really like to see those ad's go away
<tormod> slomo, bug #72255
<Ubugtu> Malone bug 72255 in linux-source-2.6.19 "hard disk speed regression (DMA is off)" [High,Confirmed]  http://launchpad.net/bugs/72255
<slomo_> tormod: thanks
<mdz> lifeless: great, thanks
<mdz> imbrandon: I'm not sure, ask the CC
<imbrandon> k
<mc44> any set plan for when the next tech board / CC are going to be?
<ajmitch> mdz: how much longer will we have for spec review & approval?
<mdz> ajmitch: next thursday (I've added it to the schedule)
<ajmitch> alright, thanks
<LaserJock> mdz: what's the proper procedure for getting a review?
<LaserJock> random poking? ;-)
<mdz> LaserJock: launchpad.net/people/ubuntu-reviewers
<LaserJock> mdz: thanks
<LaserJock> it would also have helped if I had remebered to mark it "Review" again :/
<LaserJock> smurf: can I get a review on edubuntu-menus-completion ? I fixed your comments. thanks.
<sivang> LaserJock: what sort of review is this?
<LaserJock> sivang: spec
<sivang> LaserJock: ah
<unfo> hi all, feature-idea: feisty could come with apache2+php5 preconfigured, but apache2 would not start up until the user puts files in ~/public_html
<unfo> then, as soon as you do, FAM triggers a message "Apache2 is starting, please wait".
<unfo> good idea? bad idea?
<unfo> or, it could pop up a paperclip icon in the systray.  When you click it, it could offer to install apache2 + php5 + current mysql for you.
<HrdwrBoB> er
<HrdwrBoB> what desktop user needs a apache2+php5
<lifeless> HrdwrBoB: crackful ones clearly
<unfo> HrdwrBoB: any desktop user who wants to host a phpbb, mediawiki, or such on their box.
<unfo> Dynamic DNS is easy to set up nowadays.
<_ion> Let's install GW-BASIC in dosbox by default! That would rule!
<unfo> _ion: it would be cool.
<HrdwrBoB> unfo: er
<HrdwrBoB> and these users are not capable of doing it themselves?
<unfo> _ion: or at least freedos.
<unfo> HrdwrBoB: many are not capable.
<_ion> hrdwrbob: Well, it's *php* they're using. ;-)
<lifeless> unfo: I think the idea of noting the user tried to use public_html a nd doing something as a result is interesting
<lifeless> unfo: preinstalling apache2 etc etc etc is likely not the right thing to do IMO
<unfo> lifeless: maybe it could even offer to install php and/or mod_perl and/or rails depending on the filetype dropped.
<HrdwrBoB> .. mod_perl!?
<lifeless> unfo: thats getting somewhere. 
<HrdwrBoB> if you are coding mod perl and you don't know how to install apache
<HrdwrBoB> you should be shot
<HrdwrBoB> though I don't disagree with the basic premise
<unfo> HrdwrBoB: i plan to teach my younger brother perl sometime.
<unfo> lifeless: hmm, and it could offer to install a dynamic dns auto-updater client.  If it did so, though, it would automatically set you up for daily dist-upgrades.
<unfo> The auto-updater client would prompt you for a dyndns.org username and password.
<bhale> Microsoft doesnt tell their developers that they "should be shot" if they cant admin IIS and MS SQL server
<bhale> and it is probably against our CoC
<HrdwrBoB> unfo: perl != mod
<HrdwrBoB> mod_perl
<HrdwrBoB> bhale: mod_perl is not perl
<bhale> did I use the word perl?
<HrdwrBoB> ok, remove the 'shooting' language
<bhale> thanks.
<unfo> Then it would tell you "Your new webpage is accessible at 'machinename' from your PC or 'someusername.dyndns.org' from the greater Internet."
<HrdwrBoB> I have to support a very large terrible behemoth of a disaster of a website that's written in mod_perl, so it's a touchy subject :/
<lifeless> unfo: I think what you want is something like - 'you have setup a personal home page but there is no server operating on this machine. Would you like to run our 'homepage server wizard'? '
<lifeless> unfo: that wizard can then ask a bunch of questions as needed
<unfo> HrdwrBoB: :-)
#ubuntu-devel 2006-11-22
<unfo> lifeless: sure, sounds fine.
<unfo> And the personal web server wizard could even be accessible from the Applications menu.
<unfo> It could also install nvu and/or phpbb and/or mediawiki.
<Riddell> cjwatson: yesterday you said you'd made a seed change to ubuntu regarding ppd files, but I don't see any change from you in the ubuntu.feisty seed
<unfo_> Would it be hard for me to write a spec for the above personal web server wizard idea?  Do you think people would like my spec?
<pygi> unfo_: we've got something like that already, but I'm too sleepy to say something usable
<pygi> unfo_: look for Ubuntu Instant Server Manager on ubuntu wiki
<unfo_> cool, didn't know.  But how could I edit the spec to encompass my idea of autodetecting that the user just dropped a file in ~/public_html?
<unfo_> Would the instant server manager have to watch that directory using FAM or Gamin?
<unfo_> And what if it's not installed?
<unfo_> Really we need a clippy (paperclip-like Assistant) in Ubuntu.
<lifeless> unfo_: clippy must die
<lifeless> unfo_: I hope you are joking
<unfo_> lifeless: the problem with clippy in Word was that it popped up far too often.
<lifeless> unfo_: no, the problem was that it existed
<unfo_> lifeless: a better clippy would be an unobtrusive systray icon that only pops up when you do unusual things like saving files in ~/public_html when you have no webserver installed.
<mirak>  isn't ubuntu supposed to have a ubuntu+2 developpement release soon ?
<Burgwork> mirak: +2?
<sladen> mirak: dapper is LTS, edgy is stable, fiesty is development
<mirak> well I believe there should be a intermediate between stable and developpement
<mirak> because I use linux for 5 years, and ubuntu since 2.
<Burgwork> right, a "sid"
<mirak> but the developpement version are too broken to have me want to even report bugs
<sladen> sid is unstable as you'll get
<rodarvus> mirak, as sladen pointed, there is lts (real stable), edgy, which is stable and feisty for pure development
<mirak> edgy is not stable
<mirak> I couldn't even boot LVM
<Burgwork> edgy is stable
<rodarvus> mirak, feel free to report bugs.
<mirak> usb to serial module support is broken
<sladen> mirak: that's a bug;  http://launchpad.net/distro/ubuntu/+filebug
<mirak> rodarvus: problem is that I am sure there is more bug reports from ubuntu+0 than ubuntu+1
<rodarvus> hrm
<rodarvus> there is no ubuntu+0 or ubuntu+1. please use proper names :)
<mirak> by not having a testing release I am sure ubuntu is cutting itself from a big bug reporters base
<sladen> mirak: https://launchpad.net/distro/ubuntu/+source/linux-source-2.6.17/+filebug for the usb module
<mirak> sladen: it's done
<mirak> actually someone else did :)
<sladen> mirak: can you confirm that you've experienced it aswell, 
<mirak> sladen: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/39101
<Ubugtu> Malone bug 39101 in linux-source-2.6.17 "Doesn't recognise USB Serial device" [Medium,Unconfirmed]  
<mirak> this one yes
<sladen> mirak: otherwise there's no way to judge the severity or validity of a bug report
<mirak> well it's detected and reconised but it's broken
<sladen> mirak: regarding 'testing', Ubuntu is in 'testing' for 3months out of every six months.  That is the time to jump in find bugs and get them fixed before release
<mirak> mmm
<mirak> but that puts us often away of using some new apps that use new libs
<mirak> it's still frozen for six month :p
<mirak> sladen: well for me edgy was far from usable 2 month before
<sladen> mirak: sounds like the team could do with more help
<minghua> edgy only has a four-month cycle so it's special
<rodarvus> BenC, the current xorg-driver-fglrx package for amd64 is missing the X.Org driver (basically making the package useless :) )
<rodarvus> are you aware of the problem, or would you prefer me to file a new bug on LP? (there is none on the subject, yet)
<BenC> rodarvus: interesting...I'll check it out
<BenC> what file is missing?
<BenC> fglrx_drv.so?
<rodarvus> yup
<rodarvus> /usr/lib/xorg/modules/drivers/fglrx_drv.so
<rodarvus> BenC, the differences are /usr/lib/xorg/modules/drivers/fglrx_drv.so, /usr/lib/xorg/modules/linux/libfglrxdrm.so and /usr/bin/fireglcontrolpanel (which are present on the old package only)
<BenC> rodarvus: Can you test a rebuilt package?
<rodarvus> BenC, sure
<rodarvus> this particular machine is currently building a package, but should be done in 10 minutes most
<BenC> rodarvus: Uploading to people.ubuntu.com:~bcollins/
<BenC> rodarvus: It's 15461722 bytes, so keep an eye on it for when it's done
<BenC> should be less than 2 minutes
<rodarvus> BenC, nice, I'll report to you when I'm done with the testing
<rodarvus> BenC, thanks!
<BenC> rodarvus: no, thank you :)
<BenC> if it works, I'll do a -2 upload shortly
<crimsun> jdong: I have to presume it is a local fluke on your system; I tested on dapper and edgy systems
<rodarvus> BenC, I can't find the package on p.o.c/~bcollins/
<infinity> rodarvus: In his home dir, not http.
<rodarvus> oh
<rodarvus> infinity, thanks :)
<rodarvus> BenC, fglrx_drv.so is on the wrong place (inside a fglrx_drv.so/ subdirectory), *and* libfglrxdrm.so is still missing
<rodarvus> (essentially meaning X crashes on startup, if I move fglrx_drv.so to the right place)
<BenC> ok
<BenC> give me a minute to try again
<rodarvus> sure
<BenC> rodarvus: on it's way, 15470930 bytes
<rodarvus> BenC, driver is working now, thanks!
<BenC> rodarvus: thanks for testing!
<BenC> uploading now
<rodarvus> BenC, AIGLX is not working though (since the first 2.6.19, actually)
<BenC> rodarvus: no idea why not
<rodarvus> this is minor, and I suspect it might be related to version of Mesa
<rodarvus> (hmm, or not)
<BenC> what does glxinfo say?
<rodarvus> do you plan to update the fglrx driver to 8.31.foo?
<rodarvus> (this is on Xorg.0.log) (EE) AIGLX error: dlsym for __driCreatenewScreen_20050727 failed (/usr/lib/dri/fglrx_dri.so: undefined symbol: __driCreatenewScreen_20050727)
<rodarvus> (EE) AIGLX: reverting to software rendering
<rodarvus> BenC, glxinfo (actually fglrxinfo) just crashes
<rodarvus> the right symbol name is __driCreateNewScreen_20050727, actually (I just pasted it manually from the other machine)
<rodarvus> I'll be back in a minute
<BenC> rodarvus: Do you have a link to a newer ati driver?
<rodarvus> BenC, https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/64bit/ati-driver-installer-8.31.5-x86.x86_64.run and https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-8.31.5-x86.x86_64.run (supposing you create the tarball from this file)
<BenC> thanks
<rodarvus> BenC, thank YOU
<keescook> BenC: woo! 2.6.19-6-generic #2 SMP  *dance*
<BenC> nice
<BenC> rodarvus: Want to test 8.31.5 packages?
<rodarvus> BenC, sure
<rodarvus> brb
<rodarvus> BenC, fglrx 8.31.5 is working fine (including 3D)
<BenC> sweet
<BenC> even AIGLX?
<rodarvus> no
<rodarvus> and btw, disregard that message. it is relevant (for AIGLX, of course)
<rodarvus> but not for 3D
<rodarvus> it is still present
<rodarvus> (the error message)
<BenC> ok, so what is working and what isn't?
<rodarvus> 3D works, Composite doesn't (but this is expected)
<rodarvus> I will *try* to fix Composite for feisty, but there is a good chance it won't happen
<rodarvus> might need collaboration from ATI people
<lifeless> infinity: how can I tell if I have the right gl library ?
<lifeless> I'm wondering if its easy to write a little validator scripts
<lifeless> s/scripts/script/
<BenC> rodarvus: How is this compared to edgy...equal or better?
<rodarvus> BenC, same as edgy, I would say
<BenC> rodarvus: excellent, thanks for testing again
<BenC> cjwatson: ping
<cjwatson> BenC: Please tell me what you want and I'll reply when I'm around.
<rodarvus> version 8.31.5 of this driver is supposed to fix handling of various video boards, but mine used to work just fine on edgy, so I can't tell you it *really* fixes something
<BenC> cjwatson: Is disk space ok for an lrm upload?
<_ion> nvidia-glx | 1.0.9629+2.6.19.2-1 | http://archive.ubuntu.com feisty/restricted Packages
<_ion> 9629 causes all OpenGL programs to segfault on NV2x hardware.
<HrdwrBoB> NV2x is legacy isn't it?
<_ion> Nope.
<_ion> Bug #72805
<Ubugtu> Malone bug 72805 in linux-restricted-modules-2.6.19 "nvidia-glx 1.0.9629 causes OpenGL programs to segfault on NV2x hardware" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72805
<jdong> rodarvus: ping
<jdong> rodarvus: when you get a chance take a look at bug 58721
<Ubugtu> Malone bug 58721 in xserver-xorg-video-mga "Edgy upgrade breaks multiple Matrox cards" [Unknown,Unconfirmed]  http://launchpad.net/bugs/58721
<jdong> rodarvus: the problem is fixed in Debian Sid's version... dunno how you want to handle getting that to Edgy though
<rodarvus> jdong, if I'm not completely mistaken, sid is using a new upstream version (reasonably different from what we have in edgy)
<jdong> rodarvus: that is correct
<jdong> I recompiled the sid version under edgy and gave it to some of those guys to test
<jdong> and they've all reported back success...
<jdong> so whatever they done upstream they fixed that
<rodarvus> its a regression, but I'll likely only do it if I can cherry pick the patch in question into our package, and test it for a good while on edgy-proposed
<jdong> sounds like a lot of work :-/
<rodarvus> jdong, I believe you, but a new upstream release (for edgy) is basically out of question, unfortunately :/
<jdong> what about shoving the new upstream version into edgy-backports as an interim workaround?
<jdong> it'd require a trivial patch against debian/control to tweak a dependency
<rodarvus> this could be an option, indeed
<jdong> but otherwise works
<jdong> first it'd need to be synced to feisty though
<jdong> rodarvus: would you be willing to do it that way?
<rodarvus> jdong, sure, that can be done. its not a *high* priority thing (I want to finish drafting of two specs and update of X.Org for 7.2 on feisty, before I do anything else)
<rodarvus> jdong, but I appreciate if you add this information into the bug report (or create a new one), and subscribe me to it
<jdong> rodarvus: I believe it's already on the bug report
<jdong> rodarvus: at your leisure I need you to ACK a sync of sid's version to Feisty
<jdong> and then we can move forward from there
<rodarvus> jdong, X.Org 7.2 breaks ABI (again :) ), I was planning to hold syncs/merges until we have the xserver ready
<jdong> ah, I see
<rodarvus> but if its really urgent, as you say, we can hurry it, and rebuild later
<jdong> rodarvus: I'd prefer to see this addressed... a lot of users are affected
<rodarvus> but note that a sync from sid will *not* work, btw :)
<jdong> rodarvus: huh?
<rodarvus> it will need to be a manual new upstream release
<jdong> ah, ok
<jdong> pardon my unfamilarity with development policy :)
<rodarvus> jdong, sid added new dependency tracking, after we froze X for edgy
<rodarvus> we'll have to deal with that, before we are able to sync/merge drivers
<jdong> rodarvus: new dependency tracking?
<jdong> the only thing I noticed was that xserver-xorg-{core,dev} deps needed its epoch bumped down to 1
<rodarvus> exactly, and that means we can not sync from sid.
<jdong> ok, I get what you're saying
<viviersf> BenC, ping
<BenC> viviersf: pong
<BenC> viviersf: on the way to bed, just so you know :)
<viviersf> BenC, kay
<viviersf> BenC, was just wondering how would i go about getting the kernel guys to add 3G drivers to the restricted modules
<BenC> viviersf: you file a bug report against linux-restricted-modules-2.6.19 with all the info you have and we'll check it out
<viviersf> BenC, k kewl thx
<TheMuso> c
<cjwatson> Riddell: my branch seems to have unbound on me; I'll sort it out
<cjwatson> BenC: lrm should be fine
<cjwatson> Riddell: fixed now; sorry about that
<mnepton> cjwatson: are you awake early, or insanely late?
<cjwatson> mnepton: early; may go back to bed for a bit
<StevenK> cjwatson: Can I bug you to look at the wlassistant SRU, or should I wait until you get up again?
<cjwatson> StevenK: probably when I get up again would be better. I got through about half the pending SRUs yesterday.
<StevenK> cjwatson: Shall I remind you, or just exercise patience?
<cjwatson> StevenK: it's on https://launchpad.net/people/ubuntu-sru/+subscribedbugs, which is open in my browser, so you probably only need to remind me if it isn't done in say 12 hours' time
<StevenK> cjwatson: Okay, sounds fine.
<dholbach> good morning
<_ion> Good evening.
<mvo> good morning dholbach
<dholbach> hey mvo
<_ion> I took a look at the xorg roadmap; apparently the input hotplug functionality is going to be included in 7.3 (released 2007-05). Will the functionality be patched to the feisty xorg? According to https://bugs.freedesktop.org/show_bug.cgi?id=971, it's already implemented and merged into the 7.3 development repository.
<Ubugtu> Freedesktop bug 971 in Input/Core "Input device hotplug" [Enhancement,Resolved: fixed]  
<Riddell> cjwatson: how do you decide if a programme should be marked as recommends instead of depends in the seeds?
<cjwatson> Riddell: judgement call based on whether you believe it should still be called the "Kubuntu desktop" (or whatever) if people remove it
<Riddell> that makes sense
<dholbach> hey sivang
<dholbach> sivang: did you do the tray transparency patch for ekiga?
<Fujitsu> cjwatson: I've uploaded maxima (the second half of bug #43150's fix) to dapper-proposed, and it's awaiting approval. It's just a rebuild, so can you please let it through?
<Ubugtu> Malone bug 43150 in gcl "[SRU]  maxima frontends fail to connect" [Undecided,In progress]  http://launchpad.net/bugs/43150
<Riddell> mvo: could you look over kubuntu-feisty-language-selector for approval?
<mvo> Riddell: sure
<slomo> cjwatson: hm, are you already finished with the open syncs? in that case you missed some of mine, banshee, banshee-official-plugins, ipod-sharp and libipoddevice :(
<Mithrandir> slomo: the archive team will get to the syncs as soon as possible; please don't nag people about it.  Assuming the archive team is subscribed, they won't be lost.
<cjwatson> slomo: correct.
<cjwatson> slomo: I know I didn't do all of them.
<slomo> cjwatson: ok, sorry...
<TheMuso> c
<Keybuk> as if my body clock and general sense of what day it is wasn't screwed up enough, LWN has come out a day early!
<minghua> I think they announced that in the previous issue (due to Thanksgiving)
<pygi> Keybuk: anything libburn related? :P
<elkbuntu> minghua, that is what they want you to think. It was purely to confuse Keybuk, no other purpose at all ;)
<minghua> :-)
<pygi> elkbuntu: hehe
<mvo> Keybuk: ok for me to do the cdrdao merge (you touched it last)?
<Keybuk> mvo: sure
<mvo> thanks
<pygi> mvo: we've got some merge? new version?
<crimsun> Keybuk: should we be fixing initscripts in feisty to use upstart syntax? If so, are there guidelines?
<mvo> pygi: merge from the debian version, nothing exciting (1.2.1->1.2.2)
<pygi> mvo: ah, oki. 
<pygi> Keybuk: do you perhaps know how cdrkit bits are starting to sync?
<pygi> or rather, have they started to sync ? 
<Keybuk> crimsun: packages in main will be using upstart job definitions instead of initscripts, but there are no guidelines yet
<Keybuk> pygi: cdrkit needs the cdrecord ubuntu patch applied
<crimsun> ok, thanks.
<pygi> Keybuk: aha, oki ... 
<Amaranth> So, uh, is the idea to drop cdrecord and mkisofs in feisty?
<pygi> Amaranth: in favor of cdrkit, for whatever it's worth it 
<cjwatson> mkisofs is needed by our CD build tools
<pygi> cjwatson: mkisofs is still there ...
<cjwatson> yes I know
<Keybuk> is mkisofs even in feisty? :p
<pygi> tho cdrkit won't receive many updates :P
<cjwatson> but I mean that in order for it to be dropped from main in favour of genisofs or whatever from libburn, genisofs needs to be able to replace it
<Amaranth> according to synaptic mkisofs has fallen out of feisty
<Keybuk> Amaranth: right.  it'll appear again when cdrkit is uploaded
<pygi> cjwatson: I know, we are not talking about replacing with anything yet ^_^
<mjg59> Keybuk: Had a chance to test the compiz patch?
<Amaranth> ah
<Keybuk> cdrkit is a GPL version of cdrecord
<Keybuk> mjg59: I don't have a patch from you
<mjg59> Keybuk: Still?
<cjwatson> pygi: won't receive many updates> good, as far as I'm concerned :) HFS+ support is the only thing I want; aside from that I'd rather that it weren't a moving target ...
<Keybuk> mjg59: it could be in the spam bin, or your mail server could be refusing to talk to mine?
<mjg59> Keybuk: I sent it to your canonical address
<pygi> cjwatson: I know ^_^ You'll get hfs+ in libisofs ;)
<Keybuk> ah, so could be just in the spam bin then
<pygi> cjwatson: it's not that they wouldn't like to update cdrkit with new features and things, they just can't :)
<mjg59> Message-ID: <20061117212419.GA5385@srcf.ucam.org>                               
<Keybuk> pygi: why can't they?
<pygi> cjwatson: no one is able to mess with that sort of code ^_^
<pygi> Keybuk: look above :)
<Keybuk> pygi: you give no reasons for why
<pygi> Keybuk: Debian people know that they cannot actually keep the fork...
<Keybuk> why do they know?
<pygi> well, because it makes them look bad :)
<Keybuk> why does it?
<pygi> they are taking bits from Joerg commits which are under gpl, and apply it to cdrkit/wodim source
<Keybuk> right
<Keybuk> entirely reasonable given that Joerg is a Class-A fuckwit
<pygi> no new features or anything, no own work ... nobody can mess with level of such class, low-level scsi, things ...
<pygi> Keybuk: true, but Joerg has some valid concerns
<Keybuk> why can't they mess with it?
<Keybuk> it's easy
<pygi> Keybuk: linux kernel does have it's limitations when it comes to burning
<pygi> Keybuk: it's easy? wow :P
<Keybuk> fortunately the Linux kernel is also open source, so those can be fixed
<mjg59> I don't think this conversation is going anywhere useful
<Keybuk> it doesn't seem to have hampered burning on Linux to date though
<pygi> Keybuk: you really think so? Can I assign you a task of implementing dvd recording in libburn? :)
<pygi> mjg59: as always :P
<Keybuk> use dvd+rw-tools?  WFM
<pygi> Keybuk: that's a fork of cdrecord ^_^
<Keybuk> I'm still entirely missing your point
<cjwatson> ... and thus somebody clearly managed to hack on it
<pygi> no point :P
<Keybuk> burning must be possible under Linux, because there are tools to do it
<Keybuk> also it can't be that hard, given other people have managed to maintain those tools
<pygi> Keybuk: two people have managed to maintain these tools
<cjwatson> honestly you're just coming across as a competitor
<pygi> Joerg and Andy ...
<cjwatson> which is fair enough, since you *are*, but still
<Keybuk> are you saying that you weren't able to figure it out?
<pygi> Keybuk: mkisofs code is such a mess that I even refuse to read that for example
<pygi> cjwatson: I havent mentioned libburn in not even a word in this discussion. And it's not about libburn at all...
<Mithrandir> pygi: that's hardly relevant if you just look at the kernel interfaces.
<cjwatson> 10:11 < pygi> Keybuk: you really think so? Can I assign you a task of implementing dvd recording in libburn? :)
<pygi> cjwatson: well, 'cause he said it's easy :)
<mjg59> Keybuk: Any sign of that mail? If not, I'll just stick the patch on the web
<cjwatson> mkisofs is not pretty, but it's comprehensible. If I had the time I would be entirely able to mess with it for HFS+ support - I just don't have the time
<Keybuk> mjg59: yup, found it in the spam bin
<pygi> and still, only two people in linux history have managed to maintain that kind of tools :)
<mjg59> Keybuk: Ah, good
<Mithrandir> the little hacking I've done on mkisofs wasn't that hard, really.
<mjg59> Keybuk: If you could give that a go and get back to me about whether it seems to work, that would be great
<Keybuk> mjg59: will give it a go in a bit
<Keybuk> mjg59: btw, does this work on nvidia-glx ?
<cjwatson> pygi: I'd honestly prefer if you stopped bashing on the competitors and put the same effort into writing better code. :)
<Keybuk> pygi: so you can't maintain those kinds of tools?
<Keybuk> pygi: this doesn't bode well for libburn
<mjg59> Keybuk: Note that, right now, gnome-keybinding-properties disables the wm shortcuts editing if you're not running metacity
<mjg59> That's something that needs fixing in gnome-keybinding-properties
<mjg59> Keybuk: Yes, that's what I did the packaging on. Needs a 9000-series driver, though
<pygi> Keybuk: you don't get my point ...
<Keybuk> mjg59: we don't have that in edgy
<Keybuk> pygi: clearly
<pygi> cjwatson: I don't see cdrkit as competitors, but whatever
<mjg59> Keybuk: We're not targetting edgy
<mvo> cjwatson: ok for me to merge brltty (you touched it last)?
<Keybuk> pygi: the point I'm hearing from you is "I'm not intelligent enough to do this, so I don't think anyone else is either"
<pygi> Keybuk: you hear it wrong :)
<Keybuk> mjg59: ah, duh :p
<Keybuk> pygi: then what is your point?
<pygi> Keybuk: nothing, lets just forget it :)
<siretart> that cdrecord/cdrkit is nonfree as in probably not redistributable?
<highvoltage> pygi: perhaps you should just type it out from A-Z in an e-mail
<Keybuk> siretart: cdrkit is entirely free
<siretart> Keybuk: you wish
<Keybuk> that's kinda the point
<siretart> from what I hear from zomb/ganneff they still seem to have many problems with the additional restrictions that are on the cdrecord source
<cjwatson> mvo: sure - I was just backporting a change from unstable
<cjwatson> if Ganneff thinks cdrkit is non-free, he's entirely capable of removing it from main himself
<mjg59> siretart: http://svn.debian.org/wsvn/debburn/nonameyet/?rev=405&sc=1
<siretart> well, they are currently still negotiating
<cjwatson> given that he's an ftpmaster
<mjg59> So, situation resolved
<siretart> mjg59: interesting. thanks for that link
* pygi is over and out
<Amaranth> mjg59: Was your patch to add compiz keybindings to gnome-keybinding-properties?
* Amaranth was just looking at that too
<mjg59> No
<mjg59> It was to make compiz use the metacity gconf keys
<Amaranth> ah
* StevenK wonders if he should add to or open a new sync request if a new Debian release is uploaded.
<Amaranth> what about all the others compiz has?
<cjwatson> StevenK: if the previous one has already been dealt with, please open a new one
<Amaranth> for zoom, scale, etc
<StevenK> cjwatson: It hasn't, which is why I'm wondering.
<cjwatson> StevenK: just ignore it; pre-UVF we don't care
<cjwatson> we just sync whatever's current
<StevenK> Sure.
<Keybuk> StevenK: what package?
* StevenK will test it anyway, given it's half way through building anyway.
<StevenK> Keybuk: hat
<mjg59> I'm ignoring the keybinding-properties stuff for now
<Amaranth> mjg59: hehe, that's actually the part i'm most interested in for beryl
<mjg59> Well, it's not difficult to implement at all
<mjg59> Just list the keys that you want to be modifiable
<StevenK> hat just makes me think of the leader of the Guild of Musicians from Soul Music by Pratchett.
<Amaranth> yeah, the code is pretty simple
<mjg59> The sad thing is that the design is somewhat non-scalable
<Amaranth> heh
<Amaranth> don't add lots to it ;)
<Amaranth> mjg59: I'm guessing you've run into the fun bug that happens when you suspend while running compiz?
<mjg59> No
<mjg59> What fun bug?
<Amaranth> With the nvidia driver you resume to a black screen because the driver doesn't restore the gl context or some such thing
<Mithrandir> Amaranth: doesn't restore textures.  Iz nvidia bug, buy a better graphics card.
<Amaranth> actually i think only the intel driver does it right
<mjg59> nvidia binary driver in "shit" shocker
<Amaranth> Mithrandir: it's a laptop :P
<cjwatson> StevenK: I was confused by your comment about the Conflicts in that bug
<Mithrandir> Amaranth: *shrug*; not much we can do about binary-only drivers.
<mjg59> I'm afraid I don't care about whether there are suspend/resume issues with the nvidia binary driver.
<Amaranth> mjg59: Basically you have to kill compiz/beryl and then load it again on resume
<cjwatson> StevenK: you said that the Conflicts change could be dropped because the version in feisty still satisfied the conflicts; but doesn't that mean we need to keep the Conflicts versioning change to avoid breakage?
<Amaranth> mjg59: pretty sure the ati driver has this problem too
<mjg59> No, nvidia have to fix their drivers
<cjwatson> StevenK: (or else sync/merge the other package first)
<mjg59> I'm happy to work on the ATI ones
<Amaranth> it did in edgy anyway
<mjg59> Though I don't actually have any hardware with useful ATI chipses...
<StevenK> Gah. And Launchpad is 503 at the moment.
<Amaranth> I wonder what SLED does to work around the problem
<Mithrandir> Amaranth: probably kills and reloads compiz.
<Amaranth> Mithrandir: Err, I would think XGL would have the same problem
<Mithrandir> yes, of course.
<Keybuk> Amaranth: probably nothing; I'm not aware of resume being in their priorities
<Amaranth> can't really kill it
<Amaranth> Keybuk: oh, i suppose
<Amaranth> workstation and all that
<StevenK> cjwatson: Oh right, because of the Conflicts in 2.05-{5,6} is (<< 2.04-1) which still basically does what the package in edgy did.
<cjwatson> but:
<cjwatson> libghc6-hat-dev | 2.04-0ubuntu4 | feisty/universe | amd64, i386, ia64, powerpc, sparc
* Mithrandir wonders when launchpad will be back
<cjwatson> StevenK: so your proposal means that it'll conflict when it previously didn't, surely?
<cjwatson> oh, except that that package comes from the hat source package
<cjwatson> StevenK: ok, never mind, I guess it'll work once synced
<StevenK> Yup.
<StevenK> cjwatson: I tested the upgrade path of the package from edgy, it worked.
* cjwatson nods, sorry, missed one crucial piece of the puzzle
<StevenK> cjwatson: It's fine.
<cjwatson> I suppose I ought not to try supermirror pushes while LP is down
<StevenK> Heh
<cjwatson> mind you, pulls seem to work just fine
<cybervegan> hello guys. i've got a question about mono in the light of the MS/Nov deal and the fact that java is now GPL...
<mjg59> cybervegan: We've had a functional GPLed implementation of Java for some time
<cybervegan> mjg59, yes, i understand that (tho i've had hassles with getting it working in the past) but i'm more interested in the stance on mono now
<mjg59> What stance? It's in main, we ship software that uses it
<mjg59> The presence or absence of Java doesn't change that
<Keybuk> mono is in fact in our default install
<cybervegan> mjg59, i'm a keen ubuntu user, currently running dapper on quite a few machines
<cybervegan> microsoft is making nasty noises about their "ip" - sort of implicating mono, not being specific enough as usual, so as to create FUD
<Keybuk> we have no fear, we're entirely certain in our steps and move forward without any doubt :)
<mjg59> cybervegan: If we believe that we (or our users) are likely to be sued, we won't ship an item of software.
<cjwatson> cybervegan: we'll deal with it if and when it becomes definite
<cjwatson> cybervegan: but we aren't going to be scared off by FUD
<Keybuk> interestingly, in this case, MS would likely have to sue Novell as the authors of Mono
<Keybuk> their patent licence games can't apply, because they explicitly didn't grand the licence to Novell, just Novell's users
<Keybuk> it's all very silly really
<cybervegan> hmm. in the uk we are of course "immune" from the broken us patent system
<cybervegan> ok, but that's me (notwithstanding the above)
<cybervegan> or rather, i'm not a suse customer, and ballmer has been quoted as effectively saying we should watch our backs...
<Keybuk> I actually did wonder what would happen if Canonical bought a Novell product
<Keybuk> would we become their customers, and thus protected by it
<cybervegan> there's also the notion that by using and distributing mono, you might be considered customers also
<cybervegan> being "downstream" so to  speak
<Fujitsu> cybervegan: I'm sure it is worded such that it doesn't apply to the entirety of their downstream.
<highvoltage> Keybuk: it would be funny if caconical could buy one copy of SUSE and gain immunity :)
<cybervegan> hmm. not sure it would fly tho
<cybervegan> what about the possibility of division within the community - Novl/rest of world, or US/rest?
<cjwatson> I don't think it's useful to speculate until something concrete happens
<cjwatson> that only means the FUDders are winning by distracting us
<cybervegan> i'd say the opposite - it's worth trying to work out what the next move might be... maybe that's an issue for more "user" types like me to ask then?
<Mithrandir> cybervegan: it's not like anybody is going to be dragged off to court without warning.
<cybervegan> true, but i'm wondering about the wider implications, and wanted to get a handle on the views of my favourite distro
<cybervegan> the MS/Novl deal stinks to high heaven in my eyes
<cybervegan> or should that be nose? :-D
<cjwatson> more often than not this sort of thing doesn't come to anything, and by focusing on it people get all het up and worried, often unnecessarily
<mjg59> MS has been able to sue us for patent infringement in the past. The deal didn't change that. There were various things in place in order to discourage that, and they're still in place.
<cjwatson> as Mithrandir says, if it comes to something, we'll have due warning
<mnepton> cybervegan: you're getting panicked about a devil MS painted on your wall. and in doing so, handing them a victory. just move ahead doing what you do, and trust that people that understand the landscape are making correct decisions. IOW, "do not panic."
<Mithrandir> once you _do_ need to panic, you'll have plenty of time.
<mnepton> and plenty of company.
<cybervegan> so you aren't worried right now, that's good... i'm not likely to stop using ubuntu, and no - i'm not panicing
<Keybuk> interesting
<Keybuk> gnome-screensaver activating during upgrade = bad
<cybervegan> guys thanks for your input, i've got to go now
<cybervegan> oh, and thanks for ubuntu too
<cjwatson> cybervegan: I think "watching with interest" is a fair characterisation of our position
<cjwatson> you're welcome :-)
<mnepton> cjwatson: sorta like slowing on a motorway to see an accident's aftermath ;)
<cybervegan> i'll be back when there have been some more developments no doubt! keep it up guys :-D
* mvo just read Keybuks mails about the merge-policy and blushes for not following it for the last ~10 merges
<Keybuk> mvo: consider yourself spanked!
<Hobbsee> mvo: you're not supposed to admit that in a public channel with Keybuk in it.
<mnepton> not to self: to get a free Keybuk spanking ....
<mnepton> +e
<Hobbsee> as to why you'd *want* one though....
<mnepton> Hobbsee: deep-seated personal issues.
<Hobbsee> so it seems.
* mnepton prances like a delicate ox ballerina
<Treenaks> (and a pony)
<Hobbsee> *definetly* some deep-seated personal issues there.
<Mithrandir> http://www.joelonsoftware.com/items/2006/11/21.html is interesting; both from a gnome HIG p-o-v as well as an idea for simplifying the logout dialog further.
<thom> Mithrandir: i posted that about 16 hours ago :-)
<Mithrandir> thom: I didn't see that. :-)
<mjg59> I disagree with it in one major respect
<mnepton> no ponies?
<mjg59> The distinction between "I'm going away now but I want applications to continue running" and "I'm going away now but don't care if my applications carry on running" is important
<mjg59> From a practical level, we can't implement it because suspend/resume isn't sufficiently reliable
<Mithrandir> so "log out" vs "slumber" (which starts with screen lock, then sleep, then hibernate)
<Mithrandir> ?
<mjg59> Yeah
<Ng> perhaps rather than use terms like "suspend" and "hibernate", it should talk in terms like "light sleep"/"deep sleep". they don't tell the user what it going to happen (like now), but they do at least tell you a little more about how involved the process is
<bhale> that would seem easier as 2 menus, or 1 menu with a seperator
<Mithrandir> sorry, slumber vs lock screen.
<bhale> than two dialogs as in upstream gnome
<bhale> if i dont like the menu im in i move the mouse up a few px
<Keybuk> or just have a "Sleep" option
<Keybuk> or even call it "Standby"
<Keybuk> and use "suspend" for things like the lid switch, and not expose it directly
<Riddell> lifeless: I've made https://code.launchpad.net/people/ubuntu-core-dev/+branch/hwdb-client/trunk
<sivang> dholbach: don't recall, could be :)
<dholbach> sivang: because the debian maintainer asked where it was from
<dholbach> sivang: kilian@debian.org - if you want to get in touch with him
<sivang> dholbach: well, he could get the source and just take the patch no? ;)
<dholbach> it'd be good if the patch would go upstream
* dholbach -> dogwalk
<sivang> dholbach: sure
<sivang> dholbach: ttl when you're back
<dholbach> alrighty *wave*
* sivang hugs dholbach 
<pitti> bwah, only 1024x768 with the 2.6.19 l-r-m nvidia???
<gnomefreak> pitti: i have a full range (its a hacked xorg.conf file though because ubuntu doesnt detect my refresh rates properly
<dudanogueira> does texas instrumments card reader 5x1 works on ubuntu or linux in general? i googled, but without sucess :(
<Treenaks> dudanogueira: if it's usb, probably
<Treenaks> dudanogueira: if it's built-in in a laptop, maybe, but don't count on it
<dudanogueira> Treenaks, toshiba built in
<Treenaks> No clue
<dudanogueira> sniiiif :)
<jelkner> sobby appears to be broken in dapper.  does anyone know anything about this?
<Solarion> ello
<bddebian> Heya
<dade`> BenC: will mactelpatches be in -7 ?
<rodarvus> dade`, I'm curious about what are the mactel patches, specifically?
<dade`> patches for intel-based macs
<Mithrandir> that was kinda obvious
<jdong> lol
<rodarvus> :)
<rodarvus> dade`, thanks for the helpful answer!
<dade`> rodarvus: do you want more details ?
<rodarvus> that was the original question, yes. but don't worry.
<jdong> rodarvus: 10 bucks he's gonna tell you mactels are macs with intel chips ;-)
<rodarvus> jdong, he already did so, actually :)
<jdong> oh hah he did!
<jdong> wow I'm awake this morning
<_TomB> are there many problems with Ubiquity and Edgy?
* jdong wonders if he should trust that grsec kernel he just compiled
<jdong> _TomB: it's worked pretty well for me... better than 6.06's initial ubiquity that's for sure
<_TomB> Hmm, well I released nUbuntu, and Ubiquity is failing to install grub for people
<jdong> interesting...
<jdong> well, I'm no ubiquity expert... so I'll let those guys answer your question
<jdong> the only time(s) ubiquity failed to install grub on me were with XFS
<frenkel> does anybody know why there is no build directory in  /lib/modules/2.6.17-6-generic-xen0/?
<Vixus> Is there a reason why I cannot enter the #ubuntu channel?
<dade`> no, a mactel is an intel chip with a macintosh around.
<mjg59> A Mactel is something that's almost, but not quite, PC compatible and has a bunch of extra hardware on the side
<mjg59> Other than its grossly awkward firmware, there's not a great deal of special handling required
<dade`> mjg59: ha, I got you!
<mjg59> Sadly, I now have to go and torture fruitflies
<zul> mmm...torture
<dade`> mjg59: can you tell me if your macbook sleeps with piix module ?
<mjg59> I don't have a macbook
<mjg59> But I know that Macbooks have suspended and resumed fine, and we've never provided ata_piix with pata support enabled (well, until recently), so yes
<dade`> hmm, ok.
<Keybuk> who merged coreutils?
<Keybuk> mvo: congrats
<Keybuk> you're the first person to make feisty not boot <g>
<zul> yay mvo
<mvo> Keybuk: *urg*
<Keybuk> mvo: we had a patch to make coreutils not error with "cp -a -f" and a special file already existing
<Keybuk> note, "had"
<Keybuk> Nov 22 15:50:54 rcS: cp: cannot create special file `/dev/null': File exists
<mvo> Keybuk: I haven't dropped a patch during the merge - let me check what happend
<Keybuk> you say you "Updated" it ?
<Keybuk> 60_ubuntu-force-clobber-specials.patch
<mvo> Keybuk: I updated it so that it applies again
<mvo> Keybuk: I'm checking it now
<Keybuk> I'm just glad it's not me first this time :)
<Keybuk> obviously I'll be making feisty not boot a lot later
<Keybuk> but it's nice not to be the first
* ..[topic/#ubuntu-devel:mvo] : Ubuntu Development (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy is released | coreutils broken, don't update
<jdong> Keybuk: isn't upstart gonna take full effect in feisty? ;-)
<Keybuk> that's the lack-of-a-plan yes
<jdong> sounds like fun :)
<jdong> btw does anyone have any good advice on compiling grsec kernels?
* highvoltage has confidence in ubuntu team to pull it off successfully
<jdong> i.e. like I shouldn't have just selected HIGH without looking?
<Keybuk> jdong: bluefoxicy probably would help
* jdong summons bluefoxicy 
<zul> has anyone merged grub yet?
<smallfoot-> if anyone know a hardware company that done something good or bad such as cooperate with open source or anti-competive, please add it to http://vendors.bluwiki.org/
<cjwatson> _TomB: I need details
<jdong> ok, maybe I did overdo it
<jdong> ps aux shows my own bash and that's about it :D
<iwj> seb128: AYT?  I wanted to talk to you about the g-a-i codec installation stuff.
<fabbione> mvo: how badly broken?!?
<mjg59> Keybuk: Had a chance to test that diff?
<Keybuk> mjg59: my machine doesn't boot atm :)
<Keybuk> fabbione: boot will fail
* fabbione downgrades
<fabbione> Keybuk: thanks
<mjg59> Keybuk: Ah
<fabbione> Keybuk: i reverted the waiting raids at boot in mdadm. we need to sort out the udev stuff...
<fabbione> Keybuk: what about tomorrowi'sh?
<Keybuk> fabbione: dude, I only started back at work today
<Keybuk> I'm nowhere near awake, nor through my e-mail eyt
<fabbione> Keybuk: oh i didn't know
<Keybuk> and then I have merges to do, including udev itself
<Keybuk> next week sometime, eh?
<fabbione> Keybuk: i saw you around and i thought you were working
<fabbione> Keybuk: sure that's fine
<Keybuk> cool :p
<fabbione> Keybuk: i don't care if people can't boot from raid right now.. this is FEISTY...
<Keybuk> yeah
<fabbione> hmm....
<fabbione> actually.. i can't reboot either... but whatever..
<Keybuk> for mdadm, iirc, that just needs the merge from Debian and new udev
<Keybuk> and everything will be fine
<fabbione> i already merged all the new stuff from debian
<fabbione> we have a very small delta now
<fabbione> so we just need new udev crack
<cjwatson> rodarvus: I just noticed a fix for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387043 going by
<Ubugtu> Debian bug 387043 in gdm "gdm: Mojibake if in UTF-8 mode when running XKeepsCrashing script" [Normal,Closed]  
<cjwatson> independent of bullet-proof-x, we should probably make sure we have that fix
<dade`> initrds are cramfs images ?
<cjwatson> initrds are something we don't use any more ...
<cjwatson> we now use an initramfs (although we still call it an initrd in some places for compatibility), which is a gzipped cpio archive
<cjwatson> when we used to use an initrd, it was a cramfs image, yes
<rodarvus> cjwatson, agreed
<rodarvus> I 
<dade`> so I can't mount it
<rodarvus> I guess seb128 and dholbach sync our packages with debian from time to time, but I'll contact them to make sure
<cjwatson> no. you can unpack it by changing to an empty directory and doing zcat file-containing-initramfs | cpio -id
<rodarvus> cjwatson, #387043 hit us pretty badly on the xserver issue a few months ago
<rodarvus> I'm glad to see it fixed
<_TomB> cjwatson, where does ubiquity log to?
<cjwatson> _TomB: dapper or edgy?
<_TomB> edgy
<cjwatson> _TomB: /var/log/syslog; also /var/log/installer/debug if you set UBIQUITY_DEBUG=1 in the environment
<_TomB> ok, thanks
<cjwatson> _TomB: (but the latter will include passwords, etc., so it's not on by default)
<dholbach> rodarvus: sync which packages?
<dholbach> rodarvus: ahhh, gdm
<rodarvus> dholbach, yup :)
<rodarvus> I sent you some information in privmsg window
<spike> hi, I'm looking at puppet package, currently in edgy/universe, version .18.4. Quite a lot of things changed in current version (.20.1) and I'm repackaging (tryint at least) and see if I can get it to run on dapper
<spike> how shall I handle this? shall I email debian maintainer? ubuntu ones?
<dholbach> spike: you could ask in #ubuntu-motu
<spike> dholbach: oh, right. ta
<_TomB> weird
<_TomB> cjwatson, ubiquity didn't fail on grub for me
<cjwatson> _TomB: yes, it's not particularly surprising that it might be hardware-specific
<cjwatson> _TomB: it could easily be a grub problem and nothing to do with ubiquity at all; we have a number of those; I cannot help with them but am happy to take patches :)
<bluefoxicy> jdong:  always use custom; actually read the options; and don't disable textrels (don't log them either; use scanelf to find them!  :D).  Typically the options are pretty straight-forward:  "This will break Xfree86" => don't do that
<cjwatson> _TomB: you need to get /var/log/syslog from the people with problems
<_TomB> I will
<jdong> bluefoxicy: thanks
<_TomB> I'll put a notice on the website
<jdong> bluefoxicy: have any ideas why pax didn't enable even though I told it to?
<bluefoxicy> um.. hm.  No, I'm about to leave though.  I'll look at your config when I Get back and give you better help though k?  :)
<bluefoxicy> (as in, about to leave this second)
<jdong> ok, no hurry :)
<mvo> Keybuk: coreutils should be fixed with the 5.97-5.2ubuntu2 upload, if not, please spank me again (testing appreciated) - works-for-me now
<dade`> ho avuto una idea
<Chipzz> dade`: speak english please
<Chipzz> (unless you're just addressing one person I guess)
<dade`> Chipzz: you 're right, i typed in the wrong tab, sorry
<Chipzz> ;)
<iwj> Anyone fancy reviewing one of my specs ?  (I'm on reviewers but it seems incestuous, particularly now that we're not all together and getting communications clear and correct is more important.)
<iwj> https://launchpad.net/distros/ubuntu/+spec/consistent-login-screen which I've hijacked to point at https://wiki.ubuntu.com/UnifiedLoginUnlock.
<Riddell> mvo: remembering kubntu-feisty-language-selector spec?
<smallfoot-> if anyone know a hardware company that done something good or bad such as cooperate with open source or anti-competive, please add it to http://vendors.bluwiki.org/
<sivang> mvo: what's borken in coreutils btw?
* ..[topic/#ubuntu-devel:mvo] : Ubuntu Development (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy is released | coreutils 5.97-5.2ubuntu1 broken, make sure you got 5.2ubuntu2
<sivang> mvo: I think some of the topic line got cut out ;)
<mvo> sivang: really? looks good here
<mvo> Riddell: I have not forgoten you :)
<sivang> mvo: my bad, sorry
<mvo> Riddell: the spec is approved now, thanks! do you have a eta for python-qt4 in feisty? I would like to test a patch to port langauge-selector to qt4 :)
<Mithrandir> mvo: http://launchpad.net/distros/ubuntu/feisty/+source/python-qt4/4.1-0ubuntu1 you mean?
<mvo> Mithrandir: I guess so - its currently in depwait state
<crimsun> Is doko on vacation?
<Mithrandir> yes
<crimsun> ok, thanks. If a merge is listed for him, should I wait for his e-mail response or proceed?
<crimsun> (wrt alsa-lib, since it's blocking at least two builds)
<Mithrandir> I guess he'll be happy with you taking it, as long as you don't screw up. :-)
<crimsun> hah
<mvo> sfllaw: could you please have a look at https://launchpad.net/distros/ubuntu/+source/xorg/+bug/68430 ? its currently in edgy-proposed and we would like to move it to edgy-updates once it got some QA
<Ubugtu> Malone bug 68430 in xorg "Dependencies allow driver packages to be removed too easily" [Medium,In progress]  
<sfllaw> mvo: Yes.  It didn't get into the archive until recently.
<sfllaw> I'll get to it before I go to bed today, as I understand it's important.
<mvo> sfllaw: yes, unfortunately it was stuck in NEW for quite some time
<mvo> sfllaw: thanks!
<smallfoot-> if anyone know a hardware company that done something good or bad such as cooperate with open source or anti-competive, please add it to http://vendors.bluwiki.org/
<robertj> you know, I think it's rather silly to have specs marked essential that are deferred
<Burgwork> robertj: which one? the ui one?
<Chipzz> smallfoot-: what bullshit!
<Chipzz> smallfoot-: creative is NEGATIVE?
<Chipzz> smallfoot-: for not supporting ONE card? nevermind the fact that 99.99% of their hardware DOES work under linux?
<HrdwrBoB> and works 100% with open source drivers and was one of the first/best cards to support multi open on /dev/dsp
<Chipzz> realtek POSITIVE?
<Chipzz> wtf?
<ajmitch> robertj: if it's the xorg-config-ui, note that it was set as essential just for scheduling purposes at UDS
<Chipzz> realtek chipsets are among the most crappy network-cards in existance
<Chipzz> smallfoot-: you should take a look at the freebsd drivers for realtek, and read the comments of the developers; they are not nice
<mjg59> Chipzz: Off topic
<mjg59> smallfoot-: Also, please stop repeatedly spamming us with your site
<Chipzz> mjg59: yeah but this site looks like a load of crap
<mjg59> Chipzz: I don't care. This isn't the place for it.
<Chipzz> mjg59: apologies
<bluefoxicy> jdong:  do you have a config for grsec you want me to check out?
<jdong> bluefoxicy: well, I answered my own question (partially)
<bluefoxicy> ah ok :)
<jdong> bluefoxicy: but obviously I have the security level jacked to ohigh
* bluefoxicy forgot about it since this morning :)
<jdong> bluefoxicy: because insmod segfaults
<jdong> bluefoxicy: and that's kinda important towards mounting /.....
<jdong> :)
<bluefoxicy> jdong:  now THAT's odd.
<bluefoxicy> PaX will kill stuff
<bluefoxicy> but nothing in grsec should cause SEGV
<jdong> bluefoxicy: I turned on pax softmode
<jdong> bluefoxicy: and it wasn't triggering pax
<jdong> bluefoxicy: so I'm not sure exactly what's causing the SEGV
<bluefoxicy> jdong:  you might want to drop by #grsecurity on OFTC with that one
<jdong> ok
<jdong> first I'll cut my chances of looking stupid...
<jdong> by making mrproper :)
<bluefoxicy> lol
* jdong had been lazy doing his builds
<jdong> but make's supposed to work through that right? :D
#ubuntu-devel 2006-11-23
<jdong> bluefoxicy: heh it's segfaulting on depmod :)
<bluefoxicy> jdong:  wow
<jdong> I'm guessing I'm doing something wrong
<jdong> there wasn't an option that I checked that could cause that to happen , would there be?
<jdong> bluefoxicy: I'm just gonna reset my .config and just use preset HIGH :)
<bluefoxicy> heh
<bluefoxicy> that kind of behavior is distinctly odd
<jdong> bluefoxicy: is the default HIGH high enough that it would prevent at least a basic bootup?
<jdong> bluefoxicy: all I'm looking for is my damn minimal ubuntu install to boot :D
<bluefoxicy> I honestly don't know the defaults
<bluefoxicy> the only thing i can think of it breaking should be X
<bhale> using the grsecurity canned settings is foolish
<bhale> you should know what the little switches do before turning any of them
* StevenK waves to mpt.
<mpt> hi StevenK :-)
<StevenK> mpt: Have you got a sec to talk about AboutWindow?
<mpt> sure
<StevenK> mpt: Have you looked at my most recent changes?
<mpt> I'm looking at them now
<StevenK> mpt: The wiki page also says that it doesn't hook into the session manager, does it need to?
<mpt> Well, it would be nice to not get a busy cursor for 15 seconds after it opens :-)
<mpt> That's the only reason
<StevenK> I don't recall seeing that on my system.
<StevenK> mpt: I was also considering packaging it up in a neat .deb, but I wanted to talk to you about it first.
<mpt> StevenK, sure, but then I'll *never* learn :-P
<mpt> If I haven't done it by this time next week, however, I must be procrastinating, so you'd be welcome to
<StevenK> mpt: Yes, which is why I wanted to talk to you about it. :-)
<jdub> norman silverstone
<Hobbsee> hey jdub 
<jdub> yo Hobbsee 
<ajmitch> morning jdub 
<smallfoot-> if anyone know a hardware company that done something good or bad such as cooperate with open source or anti-competive, please add it to http://vendors.bluwiki.org/
<HrdwrBoB> smallfoot-: please. stop spamming
<Hobbsee> smallfoot-: might be more sensible to put that into #ubuntu-offtopic - that's not development related
<mjg59> smallfoot-: You've been asked to stop before. Please do so, otherwise you'll be banned from the channel.
<smallfoot-> but the developers are those who know what vendors make source code public and who dont
<Hobbsee> ...and are working on other things, such as actual development...
<ajmitch> smallfoot-: you've spammed that a couple of times now
<infinity> At 09:11, 11:19, 15:23, and 17:37 according to my /lastlog
<infinity> smallfoot-: Please stop.  It's not helping your case any.
<mjg59> smallfoot-: You were asked to stop after the third time. You've just done it a fourth time.
<smallfoot-> :(
<smallfoot-> sry i forgot
<smallfoot-> it was long time since last
<infinity> 2 hours.
<infinity> That's not a "long time".
<smallfoot-> i think is long
<bhale> not long enough to forget something you've been told 3 times already
<bhale> don't fight about it, just don't do it again
<mjg59> smallfoot-: The decision isn't up for discussion here. This channel is not for advertising websites - it is for discussing development of Ubuntu.
<smallfoot-> true
<smallfoot-> oh didnt know was discussinog for development only
<smallfoot-> i just figured here are many developers
* mode/#ubuntu-devel [+o infinity]  by ChanServ
<smallfoot-> and developer knows about device drivers
<smallfoot-> and which vendors are good and bad
<infinity> smallfoot-: Please just drop it, don't waste time justifying it.
<infinity> smallfoot-: And promise it won't happen again.
<smallfoot-> okie
* mode/#ubuntu-devel [-o infinity]  by infinity
<sistpoty> infinity: just curious: did you get the mail regarding mit-scheme (from 10/6) I forwarded to you? (https://lists.ubuntu.com/archives/ubuntu-motu/2006-October/000836.html)
<infinity> sistpoty: I'm notorious for poorly filtering spam occasionally (especially when travelling and leaning on the delete key to get through thousands of messages), so it may have disappeared. :/
<infinity> Oh, no.  Wait.  I got that one.
<infinity> Ugh.
<infinity> I refuse to do a manual bootstrap on every single upload of the source.
<sistpoty> infinity: sure... do you see a solution or have any hints?
<infinity> If the only way it can build is with binaries from upstream, the binaries will have to be (ugh) bundled in the source package.
<sistpoty> nice :(
<infinity> Not really a license violation, since the source used to build said binaries is sitting next to them.
<infinity> Just realy, really ugly.
<infinity> And bloaty.
<sistpoty> true... will you send him a quick answer or shall i?
<jdong> infinity: not to distract you, but have you had a chance to happy-ize backports yet?
<crimsun> infinity: if/when you have a suitable moment, please give back alsa-utils and alsa-plugins, thanks
<infinity> sistpoty: Feel free.  He may want to consider a similar bootstrap bloat option for Debian too.  Not having the packages buildable from source is somewhat unacceptable.
<infinity> jdong: Should get done during this wake cycle.
<infinity> crimsun: On it.
<sistpoty> infinity: ok, I'll do. thanks.
<jdong> infinity: thanks, infinitely grateful for your time :)
<infinity> crimsun: Err, nothing to give back...
<crimsun> infinity: are dep-waits automatically retried?
<infinity> crimsun: Looks like we're in dep-wait on libasound2-dev (>= 1.0.12)
<infinity> crimsun: Yes, dep-waits get auto-cleared when available.
<crimsun> infinity: ah, ok, thanks
* lamont grumbles at hal
<keescook> uhm... "apt-get source" ignores Acquire::http::Proxy settings??
<jdong> keescook: is that what it is?
<jdong> and I thought I was doing something wrong :D
<keescook> jdong: eh?  i was just complaining to myself...
<jdong> keescook: I've experienced something like that before
<jdong> keescook: IIRC setting HTTP_PROXY works around it
<jdong> keescook: I was complaining too .... kind of to myself :D
<keescook> jdong: I was also seeing that my sbuilds weren't using the proxy either.
<keescook> seems like the minimal apt in my chroot was ignoring /etc/apt/apt.conf.d ... moving the file to /etc/apt/apt.conf seemed to fix it...
<jdong> keescook: maybe I was being stupid trying to type the setting then :)
<jdong> I've been known to do that
<keescook> wild... yeah, apt-get source ignores /etc/apt/apt.conf.d ??  when I moved my setting into /etc/apt/apt.conf, it works for apt-get source too.
* keescook scratches his head
<lifeless> Riddell: cool
<keescook> I love source packages with test suites.  *happy sigh*
<soulfire45> Hey everyone
<dholbach> good morning
<_ion> Evening.
<dholbach> hey _ion
<_ion> What's up?
<dholbach> damned jetlag - i was up at 5:15 already *yawn*
<Mithrandir> good morning, Daniel
<dholbach> heya Tollef
<dholbach> how are y'all?
<Mithrandir> still not dead
<keescook> always a good sign, breathing.  :)
<dholbach> hey kees
<keescook> hiya dholbach
<_ion> I see the reason for feisty-wallpapers to conflict with edgy-wallpapers, but it would be cool if it was possible to install wallpaper packages from earlier Ubuntu versions.
<fabbione> morning Germans
<BenC> how do I request a sync from Debian for ndiswrapper?
<fabbione> BenC: you need to file a bug in LP.. there is a procedure somewhere for it
<dholbach> BenC: you could use pitti's requestsync script for that
<fabbione> or that
<dholbach> http://people.ubuntu.com/~pitti/scripts/requestsync
<BenC> got it thanks
<mvo> keescook: do you mind if I merge gdb (you touched it last)?
<keescook> mvo: have at it, I was just doing security updates to it.  :)
<dholbach> _ion: I'll think about how to solve it - the filenames need to change, I guess
<infinity> BenC: Alternately, you can just fedex me a smoke and ask nicely.
<infinity> (If it requires overwties and long explanations, filing a long-winded bug is better, though)
<infinity> Paper trail, for the win.
<BenC> there's only two trivial changelog entries, and requestsync seems to be stalling
<BenC> actually only one, and that was a dash fixup, and it's been synced in debian
<BenC> infinity: it's a clean sync, if you could take care of it for me
<infinity> And a cosmetic debian/control change.
<infinity> http://patches.ubuntu.com/n/ndiswrapper/ndiswrapper_1.18-1ubuntu2.patch
<infinity> I assume we made that control change on purpose, dropping it isn't nice. :)
<infinity> +ndiswrapper (1.1-4ubuntu2) breezy; urgency=low
<infinity> +
<infinity> +  * debian/control: Update description to point out that the kernel source
<infinity> +    package is not required with the standard Ubuntu kernel.
<infinity> +
<infinity> + -- Martin Pitt <martin.pitt@ubuntu.com>  Fri, 30 Sep 2005 14:56:14 +0200
<BenC> infinity: What's the best way to handle this then?
<fabbione> BenC: with the new initramfs i will get pata_via directly.. right?
<infinity> BenC: Merge away.
<BenC> I'm not used to the whole syncing process
<BenC> fabbione: correct
<fabbione> BenC: ok. testing now
<infinity> BenC: You get to do a merge if we want t okeep those changes, no syncing required.
<BenC> infinity: Is there anything I need to do special when I'm done?
<infinity> BenC: Upload it? :)
<Hobbsee> run merge-genchanges on it
<BenC> I remember seeing an email from colin about merge policy not being adhered to, just making sure :)
<infinity> BenC: Surely, we've assigned merges to you before... (kernel-package, kernel-wedge?)
<BenC> yeah, but I just uploaded them, and did nothing else :)
<cypher1> fabbione: what is pata_via ?
<infinity> BenC: Oh, the new-fangled merge policy is to, rather than interlacing all the old changelog entries, just have one changelog entry at the top that explains the current delta.
<fabbione> cypher1: a kernel module
<BenC> infinity: Ok
* fabbione reboots
<cypher1> fabbione: what does it do ?
<fabbione> BenC: modulo the OOPS, it's ok. The initramfs is lacking cdrom or you need to blacklist sr_mod from being included otherwise you get a bunch of unresolved symbols
<BenC> lacking cdrom?
<fabbione> cdrom.ko
<infinity> (base)adconrad@cthulhu:~$ modinfo sr_mod | grep ^depends
<infinity> depends:        scsi_mod,cdrom
<BenC> sounds like a bug I introduced
<fabbione> BenC: yeah or blacklist sr_mod
<BenC> cdrom should be in base modules
<infinity> modules_add_dir probably doesn't do dep checking like manual_add_modules does.
<BenC> nope, it doesn't
<BenC> It actually just copies
<infinity> cdrom really doesn't need to be there at all, though, IMO.
<BenC> makes dmesg look ugly though, I suspect
<infinity> However, this may be why we weren't using add_dir. :)
<minghua> speaking of missing kernel modules, we also miss via82cxxx.ko in 2.6.19 kernels
<fabbione> BenC: i suggest you fix that before going to sleep :)
<infinity> With no dep-checking, who knows what other drivers may break.
<fabbione> minghua: that's changed to pata_via
<fabbione> minghua: and it has been fixed as we speak
<BenC> I can make copy_dir do a find -name \*.ko and manual_add_module for each one
<minghua> fabbione: I see.  So I'll just wait?
<fabbione> minghua: yes
<minghua> (I was thinking of filing bugs)
<infinity> BenC: That was what I was about to suggest, yes.
<minghua> fabbione: got it.  thanks.
<BenC> let me finish this ndiswrapper sync and I'll fixup initramfs-tools
<fabbione> minghua: there are already a few dups.. spare your time or check launchpad as you should do before filing
<infinity> BenC: Shame that using add_dir probably gave up a speed boost that you're about to kill again, but hey, easy come, easy go. :)
<BenC> heh, very true
<infinity> s/gave up/gave us/
<Mithrandir> hmm
<Mithrandir> I wonder if we could watershed update-initramfs too
<Hobbsee> hey Mithrandir 
<infinity> Mithrandir: In what respect?
<minghua> fabbione: Now I see the bug.  But honestly, searching via82cxxx.ko in https://launchpad.net/distros/ubuntu/+bugs doesn't give me anything.  I have to go to linux-source-2.6.19's bug page.  No wonder people are filing dups. ;-)
<fabbione> minghua: it's an initramfs bug
<minghua> hmm, so I should mark bug 72888 as a dup of that?
<Ubugtu> Malone bug 72888 in linux-source-2.6.19 "Linux-image-2.6.19-6-generic package should include via82cxxx.ko" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72888
<Mithrandir> infinity: avoid running it half a zillion times on upgrades.
<infinity> Mithrandir: Give me dpkg hooks.
<Mithrandir> infinity: give me 48 hour days and I'll get you dpkg hooks.
<fabbione> minghua: already killed that bug
<infinity> Mithrandir: Pfft.  Just stop sleeping.
<Mithrandir> infinity: our puppy already does that, which is.. tiring.
<minghua> fabbione: thanks.  sorry for the bothering.
* minghua goes back to try to boot 2.6.15 kernel
<minghua> I mean 2.6.17
* mvo is amazed how long the gdb testsuit runs
<_ion> Exactly what are dpkg hooks? Is it the feature that allows packages to say e.g. "run update-initramfs once after the current dpkg actions have finished"?
<Mithrandir> _ion: basically, yes.  
<Lathiat> ooh, thats nifty
<Mithrandir> _ion: a reason why it hasn't been implemented is we haven't decided on the semantics should a hook command fail.  Say, update-initramfs fails because of full disk.  Are packages unconfigured?  If so, which?  Which package is responsible for handling the failure, etc.
<_ion> For that example, my first thought is that packages should remain configured, but the user should be told to fix the problem and dpkg should exit with a non-zero exit value.
<Chipzz> _ion: wouldn't that break behaviour; ie the behaviour as it is now is that all the packages would be unconfigured, right?
<Mithrandir> also, what are the semantics wrt packages depending on the package with a hook?  It might not work correctly until the hook completes.
<Chipzz> not sure if anything actually depends on that behaviour, but it doesn't sound backward compatible
<Mithrandir> Chipzz: you could argue the hooks should be done as a virtual package which is left unconfigured if any of the hooks fail.  That'd at least make sure they would be retried on next upgrade/dpkg --configure -a
<Mithrandir> anyway, as you see, the semantics aren't trivial so it's not a SMOP but rather an IMOS.
<Chipzz> Mithrandir: I was actually thinking of something like a 'Post-Depends', if that makes any sense ;)
<Mithrandir> Chipzz: postream.no-really-I-mean-it?
<Mithrandir> or rather, postinst.no-really-I-mean-it.
<Chipzz> well, we have Pre-Depends semantics now to express the relations between packages
<Chipzz> hooks are the opposite in a way
<Chipzz> Post-Depend would be a (virtual) package which the package needs to be usefull
<Chipzz> bleh, probably not making much sense ;)
<Mithrandir> I'm not quite sure I follow you, no. :-)
<Chipzz> nevermind then :)
<Chipzz> I think the best solution would be to revert the state of all packages needing that hook to unconfigured if the hook fails
<Mithrandir> so if your scrollkeeper hook failed, you'd have the full gnome desktop unconfigured?
<Chipzz> hrrrm
<Mithrandir> that sounds a bit harsh.
<Mithrandir> also, what about recommends?
<Chipzz> I'm thinking of a way which is backwards compatible
<Chipzz> lemme rephrase maybe
<Chipzz> I think the best solution would be to revert the state of all packages _which where upgraded in that particular run_ needing that hook to unconfigured if the hook fails
<Chipzz> you're of course right that if a package isn't installed/upgraded, but does depend on the hook, it shouldn't be unconfigured
<Chipzz> though in some cases it may make sense
<Chipzz> lets say we run ldconfig from a hook
<Chipzz> failing to write out /etc/ld.so* would affect all packages depending on that hook, right?
<Mithrandir> depends on how it failed.
<Mithrandir> if it ended up writing a corrup ld.so.cache, you might be left with a broken system.
<Chipzz> in contrast, in the scrollkeeper case, it would only affect the packages being upgraded
<Chipzz> the corrupt ld.so.cache was what I was referring to indeed
<Chipzz> but that's a problem we don't handle correctly atm anyway, right?
<Chipzz> even without hooks
<Mithrandir> it'll break at the right point right now; with hooks it'd break somewhere else (which wouldn't be deterministic)
<Chipzz> but it's broken either way ;)
<Chipzz> running ldconfig from a hook wouldn't be a good idea anyway I presume, since it's quite fast and low overhead
<Chipzz> in contrast to say running scrollkeeper-update or update-initramfs
<Chipzz> just some random brain-dump: maybe a good rule would be that something can only be a hook if it previously was the last thing being ran in a postinst (or being able to be moved to be the last thing to be run...)
<BenC> new initramfs-tools uploaded
<fabbione> BenC: are you sure initramfs has been accepted? i can't see the mail to -changes
<BenC> fabbione: Subject: Accepted initramfs-tools 0.69ubuntu22 (source)
<fabbione> BenC: ok
<cypher1> how do i control speaker volume from an application ?
<pitti> Good morning
<seb128> hey hey pitti
<seb128> pitti: how do you feel today?
<dholbach> heya pitti
* Mithrandir growls at the not-present hobbsee
<pitti> hey seb128, moin dholbach 
<pitti> seb128: much better already, I finally slept again last night, and cold gets better
<seb128> pitti: good :)
* pitti attacks his giant email backlog
<seb128> good luck
<seb128> I'm fighting with the ~1000 desktop bug mails backlog
<Mithrandir> rodarvus: do you want to tell the people in https://launchpad.net/distros/ubuntu/+source/xkill/+bug/59567 how xkill works or should I?
<Ubugtu> Malone bug 59567 in xkill "Firefox stops responding, and claims to be running even after killing it by xkill" [Undecided,Confirmed]  
<Chipzz> Mithrandir: I was already thinking that was a pretty stupid way of killing firefox ;)
<minghua> pitti: do you have any idea how to fix http://paste.ubuntu-nl.org/33437/ ?
<minghua> pitti: the package has a po/ dir but doesn't seem to be doing any i18n, and therefore an empty po/ygraph.pot
<fabbione> minghua: remove the empty .po
<pitti> minghua: right, as fabbione says
<minghua> fabbione: in debian/rule's clean?
<fabbione> minghua: yes
<minghua> fabbione, pitti: thanks
<pitti> 'find po/ -empty | xargs rm' or so
<Mithrandir> dholbach: could you ask nemiver upstream to update the FSF address in the copyright notices?
<dholbach> Mithrandir: done
<Mithrandir> dholbach: thanks
<Mithrandir> dholbach: you're aware that bits of nemiver is MIT and not GPL?
<Mithrandir> (this is fine, but you should not it in debian/copyright)
<Mithrandir> note, even
<dholbach> Mithrandir: I'll update it, thanks for noticing.
<Mithrandir> dholbach: if you promise to do a new upload today I'll accept rather than reject the package. :-)
<dholbach> promise
<dholbach> :-)
<Mithrandir> Running: "accept nemiver"
<Mithrandir> there, done.
<Keybuk> sweet
<Keybuk> so the automake source package produces the automake1.4 binary
<Keybuk> the automake binary package is produced by the automake1.10 source
<Spads> I remember this game.
<Keybuk> at least the latest version has the right binary name now ;)
<Keybuk> and the right alternatives priority
<Keybuk> so you get 1.10, unless you force otherwise
<pitti> Keybuk: can you please commit your hal upload into the LP bzr tree?
<Keybuk> pitti: err, sure
<Fujitsu> cjwatson: If you're around and have time, can you please look at and let maxima into dapper-proposed?
<pitti> Keybuk: thanks
<MidMark> pitti: if you have time for dvd seen as blank I'm here
<fabbione> Keybuk: thanks for changing redhat-cluster-suite B-D
<mjg59> Keybuk: Any joy with that patch?
<cjwatson> Fujitsu: done
<Fujitsu> Thanks cjwatson!
<pitti> MidMark: ok, great
<pitti> MidMark: let's do this in /msg
<MidMark> pitti wait I've to register to freenod
<MidMark> pitti: in the meantime read the bug -> https://launchpad.net/distros/ubuntu/+source/hal/+bug/14692
<Ubugtu> Malone bug 14692 in hal "hal detects written DVD as empty" [Medium,Confirmed]  
<Keybuk> mjg59: haven't had time to even think about looking
<cjwatson> Keybuk: replacement-initscripts> "set up keyboard" needs to depend on /dev being set up; it needs to get at /dev/tty* for instance
<Keybuk> cjwatson: how does that work today then? :P  you're running it before udev
<cjwatson> that's a very good question
<cjwatson> are static devices there before udev runs?
<Keybuk> no ... but you'll have /dev mounted if initramfs ran :p
<Keybuk> so that probably breaks for elmo
<cjwatson> ok, so that probably wants to be moved to after udev
<Keybuk> *nods*
<cjwatson> mind you, elmo surely has static devices on /
<cjwatson> /dev/tty[1-6]  are pretty reasonable device nodes to have lying around if you aren't using initramfs
<Keybuk> true
<infinity> Any box where elmo doesn't have initramfs is also likely to not have udev. :)
<Keybuk> infinity: you'd be surprised :)  I had to help him fix one the other week
<infinity> (Where "elmo" is "some random sysadmin who compiles monolithic kernels)
<Keybuk> he was dipping his toes into the initramfs waters, but hadn't yet got to udev
<Keybuk> anyway, lunch
<heno> cjwatson: will you be considering specs for approval before the meeting today? (like braille-support)
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy is released | coreutils 5.97-5.2ubuntu1 broken, make sure you got 5.2ubuntu2 | udev 103-0ubuntu1 broken, make sure you got 103-0ubuntu2 ... unless you have an old machine, in which case don'
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy is released | coreutils 5.97-5.2ubuntu1 broken, make sure you got 5.2ubuntu2 | udev 103-0ubuntu1 broken, make sure you got 103-0ubuntu2
<Treenaks> what about old machines :)
<Keybuk> Treenaks: they won't boot
<Keybuk> ha ha ha
<Keybuk> etc.
<infinity> ide-generic disabled.
<Treenaks> ah
<Keybuk> something's broken there, and I'm not sure what
<infinity> Good thing we all use apt-listchanges... Right?
<Keybuk> ISTR that Ben said something about not using it when we had libata anyway
<infinity> I think libata was meant to obsolete ide-generic (finally), yes.
<infinity> But have we fully transitioned?
<Keybuk> no
<Keybuk> but with ide-generic enabled, machines no booty-wooty :p
<infinity> Booting is overrated.
<infinity> I've had to boot with a livecd to fix my feisty about 5 times since upgrading already.
<Keybuk> really?
<dholbach> wow
<Keybuk> I've only had the two breakages, and could fix them both from the system itself
<infinity> Which reminds me, has anyone larted Fabio about that "mdadm makes machines explode" bug yet?
<infinity> Had that about a day ago.  Was too livid to file a bug without cursing.
* pitti sighs about feisty not providing *any* usable video driver for him any more
<Hobbsee> Keybuk: which udev is this?  feisty version seems to be 093-0ubuntu18
<Keybuk> Hobbsee: the one I uploaded a couple of hours ago
<Hobbsee> oh right
<cjwatson> heno: I probably won't get to approvals until after the meeting
<heno> ok, np
<cjwatson> heno: I need to talk with you about braille-support anyway - there's a lot of misunderstanding of the installer in there
<heno> probably better that way round actually
<heno> cjwatson: ok
<cjwatson> heno: do you know what a udeb is at all?
<heno> cjwatson: not really, no
<cjwatson> heno: OK, a udeb is an installer component - in terms of format it's like a deb only smaller, but ONLY udebs can be used to provide facilities within the installer, and udebs can ONLY be used within the installer and not on the installed system
<Keybuk> cjwatson: "Ubuntu Deb" ? :)
<bhale> apt- wants to remove libmeanwhile1 even thought it is an rdepend on gaim, nice
<cjwatson> Keybuk: :P
<gnomefreak> infinity: i thought he fixed mdadm already. (unless you mean something else by explodes) ;)
<cjwatson> heno: braille-support should not be talking about the "server install" - d-i is used in contexts other than server installations
<heno> right, parts are used in ubiquity I guess
<cjwatson> heno: irrelevant here
<heno> and alternate of course
<cjwatson> heno: d-i is also used for OEM installations, LVM/RAID (non-server), etc.
<heno> ok
<cjwatson> and places where the desktop CD just doesn't work
<heno> right
<heno> and that's where the debian braille udeb might e useful
<heno> AFAIU
<cjwatson> it's the only place it can possibly be useful :)
<cjwatson> heno: anyway, my point is that there is no need for the specification to justify the use of brltty-udeb in the alternate installer - it's not possible to use anything else
<cjwatson> at the moment, Debian appears to be including brltty-udeb in its installer images, so it probably works pretty well
<heno> right. On the live CD we would use Orca with it's braille support
<cjwatson> it's done by means of a brltty= boot parameter
<cjwatson> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355851
<Ubugtu> Debian bug 355851 in brltty "Re: a blindunfriendly debian installer problem" [Wishlist,Closed]  
<heno> ok, so inluding it is non-controvertial 
<heno> cjwatson: thanks I'll polish the spec with this feedback in mind
<cjwatson> heno: in fact, apparently the way it's set up in Debian at the moment is that brltty is automatically started if a USB Braille device is detected; you only need to supply brltty= as a boot parameter if you need a serial device
<cjwatson> (or whatever)
<heno> cjwatson: is it installed in debian by default?
<cjwatson> heno: if the script described in the Implementation section is a shell script (preferable) or a C program (possible), then it can be run in d-i
<heno> cjwatson: we installed it during dapper, but then disabled the automatic loading
<cjwatson> heno: in the installed system? I don't know
<cjwatson> heno: it's loaded as an installer component by default, AFAICS
<heno> cjwatson: a default install always makes it more controversial :)
<cjwatson> heno: "language: should this be python or a shell script?" <- if it's in python then you can't use it in d-i
<heno> esp. if it may do odd things
<cjwatson> so I recommend a shell script
<cjwatson> heno: we made sure the daemon doesn't start by default on most systems; I have no problem with automatically starting the daemon if a Braille device is physically present, though
<cjwatson> heno: detecting USB devices is done by udev rules
<heno> I wasn't actually planning to call it from (or before) d-i, but that would also help 
<cjwatson> those exist in brltty-udeb already
<cjwatson> heno: I think we should
<cjwatson> most of the work has already been done
<heno> right, so if F5+6 happens and no USB device is found
<heno> run the script no matter what system it is
<heno> cool!
<heno> cjwatson: does udev need more information about braille devices to do the right thing (start the deamon) or should that all be working already?
<popey> Whats the procedure if someone wants an app to move from universe to main?
<Hobbsee> popey: please see the /topic
<Hobbsee> popey: developer resources page, there is a link to https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<cjwatson> heno: it just goes on vendor/product ids; see debian/brltty-udeb.udev.rules in the brltty source package
<heno> ok, cool
<popey> excellent, thanks Hobbsee 
<cjwatson> heno: the way it works at present in Debian is that if you used it in the installer it gets configured in /etc/brltty.conf in the target system; I don't know if that's quite right, and we should maybe use the udev rules in both places or something
<cjwatson> heno: you might want to get Keybuk to have a look over it
<heno> Ideally it should pick up a USB device whenever it's plugged in
<heno> ie. added to the system later
<heno> I emailed with Keybuk about it before writing the spec
* heno is away
<Hobbsee> heno: http://sackheads.org/~bnaylor/spew/away_msgs.html
<jpatrick> Hobbsee: i have the impression he's not here anymore
<_ion> He'll surely see the message when he returns.
<Hobbsee> jpatrick: true.  i could have removed him with that message, that is my normal practice
<DaSkreech> Hello 
<DaSkreech> Does the Live CD support LVM?
<DaSkreech> Installing to LVM that is?
<hunger> DaSkreech: AFAIK you need the alternate CD for that (and the expert mode there).
<DaSkreech> there are no plans to support it in ubuiiquity
<DaSkreech> ?
<hunger> DaSkreech: Dunno.
<hunger> DaSkreech: I am just a user.
<DaSkreech> OK :-) I wasn't asking you personally. Just kinda in general
<Keybuk> heno: I'd still like to read the finished spec
<heno> Keybuk: sure, I'll ping you after updating it
<frafu> heno: out of curisity: what spec are you talking about? 
<heno> frafu: https://wiki.ubuntu.com/Accessibility/Specs/BrailleSupport
<frafu> thanks
<cjwatson> DaSkreech: it's planned, but only sketchily and some way in the future
<cjwatson> hunger: you do not need expert mode to install to LVM
<DaSkreech> Ok thanks cjwatson
<cjwatson> DaSkreech: (it's dependent on a rewritten partitioner in ubiquity)
<hunger> cjwatson: Are you sure? I am pretty certain that I could not use LVM when installing edgy in non-expert mode.
<cjwatson> hunger: yes, I'm sure
<hunger> cjwatson: Well, maybe I just missed the option... I could set up LVM partitions, but I could not figure out how to set up VGs and LVs on top of those.
<cjwatson> hunger: "Configure the Logical Volume Manager" up at the top
<cjwatson> partman in general is not terribly sensitive to expert mode, which is why I'm sure
<hunger> cjwatson: Must have missed that, sorry for spreading misinformation.
<cjwatson> there is no provision at present for the set of options presented in a given select list to depend on the debconf priority
<cjwatson> (unless you compute it by hand, which partman doesn't)
<hunger> cjwatson: When I ran the last install before that edgy thing the LVM stuff was shown after the partitioning.
<hunger> cjwatson: That is where I was looking for it.
<cjwatson> hunger: I don't recall that ever being the case
<cjwatson> AFAIK you've always had to select "Configure the Logical Volume Manager"
<cjwatson> the exact layout may have changed a bit but I'm pretty sure it's always been an option on that screen
<hunger> cjwatson: Maybe I am wrong, or messing it up with debian or something. I rarely install Linux these days.
<DaSkreech> so is there a roadmap on the partitioner?
<cjwatson> DaSkreech: https://launchpad.net/distros/ubuntu/+spec/ubiquity-advanced-partitioner
<DaSkreech> so possible feisty+1
<DaSkreech> Grumpy Gorrila?
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy is released | coreutils 5.97-5.2ubuntu1 broken, make sure you got 5.2ubuntu2 | udev 103-0ubuntu[12 broken, make sure you got 103-0ubuntu2
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy is released | coreutils 5.97-5.2ubuntu1 broken, make sure you got 5.2ubuntu2 | udev 103-0ubuntu[12]  broken, make sure you got 103-0ubuntu3
<Keybuk> (0ubuntu2 didn't work for anyone with a SCSI, SATA or libata card :p)
<rodarvus> Keybuk, you mentioned you would make feisty unbootable soon, but that was very quick :P
<jsgotangco> Lol
<DaSkreech> cjwatson: Thanks a lot ;_)
<DaSkreech> I'm off now
<zul> when is the dev team meeting?
<zul> er..distro
<seb128> 5utc
<cjwatson> 95 minutes from now
<seb128> 1.5 hour from now
<zul> thanks
<heno> Keybuk: I've tightened the braille spec up a: https://wiki.ubuntu.com/Accessibility/Specs/BrailleSupport Let me know if kit needs more detail WRT to udev or upstart
<cjwatson> development team meeting in 7 minutes in #ubuntu-meeting
<cjwatson> infinity,keescook: ping
<cjwatson> (#ubuntu-meeting)
<Keybuk> Whiteboard changed to:
<Keybuk> Tollef has received training and is now working as an archive team
<Keybuk> member.
<Keybuk> -- 
<Keybuk> see, I would have written that "Tollef is now our bitch"
<fabbione> Keybuk: you wish :)
<bhale> seems a bit like tollef gets thrown anywhere that is too scary for everyone else
<Keybuk> bhale: that's because he's a robot
<kylem> robots can handle hazardous environments...
<Mithrandir> beep!
<cypher1> i get "permission denied" when echo'ing to /proc .. what am i missing ?
<PuMpErNiCkEl> Permission?
<stgraber> maybe you just don't have the permissions ?
<thom> you're missing that you're in a _dev_ channel asking _support_ questions
<pitti> cypher1: if you tried 'sudo echo > /proc/' -> #ubuntu
<cypher1> pitti, just found out using "sudo" wont work
<cypher1> pitti, we have to do "sudo -s" and then echo as root
<bhale> sudo echo > doesnt work
<kylem> echo foo | sudo tee
<bhale>  > is a function of the shell, sudo doesnt work on it.
<spike> I'm suing these 3 lines in my preseed config file:
<spike> d-i mirror/http/hostname string gb.archive.ubuntu.com
<spike> d-i mirror/http/directory string /ubuntu
<spike> d-i mirror/suite string dapper
<spike> but now I'd like to add universe repo and I'm not entirely sure on how to do that
<spike> I dont even see "main" specified in there...
<spike> just took it from the preseeding example
<cjwatson> spike: 'd-i apt-setup/universe boolean true'
<cjwatson> spike: the edgy installation guide documents this
<cjwatson> (in the preseeding appendix)
<spike> cjwatson: oh, I see, thanks
<Keybuk> iwj, pitti: imo, dbus should just do what upstart does ... it can be restarted quite happily
<pitti> Keybuk: as I said, this would need to iterate over all session dbuses as well, and that would be a novum (packages touching user processes)
<pitti> I'm not sure whether an old session dbus and a new sytem dbus would play well
<pitti> (although it should work)
<slomo_> pitti: notification-daemon does this already... "killall notification-daemon" in postinst
<slomo_> and session/system bus have no connection between each other so that's no problem
<pitti> ok
* pitti hugs slomo_, hello :)
<iwj> Keybuk: No, I don't think that's sufficient.  We want to survive dbus crashing too, right ?
<iwj> So it has to be done in the library.
<Keybuk> heh
<Keybuk> I guess upstart crashing is ... less of a problem
<iwj> *snort*
* slomo_ hugs pitti :)
<iwj> And the session bus is started by the session manager and we could just put a wrapper round it to restart it.
<iwj> If the library would cope then it would all be fine.
<iwj> You might have a bit of lossage at the time but bugs => lossage.
<iwj> But I need to understand the protocols and use cases better.
<iwj> wrapper> or some mad session upstart plan of course.
<iwj> Keybuk: BTW, I can't remember where we ended up with the upstart config stuff.
<Keybuk> iwj: I haven't dug out those notes yet
<Keybuk> that's somewhere on my todo for next week
<iwj> Right.  Let me know when you get round to it and what you decide.
<iwj> Feel free to ping me or phone me to talk about it, too.
<spike> cjwatson: another thing: I've got a serial console to this box. if I do a manual install, it works fine. with preseeding it just hangs after booting the pxe kernel
<spike> cjwatson: I've dumped traffic a looked at logs, the request for the preseed file is never issued
<spike> any idea what that could be?
<spike> it's a pain not being able to monitor stuff via sc
<spike> plugged in a monitor for the time being
<cjwatson> spike: you need to preseed locale/keyboard stuff on the command line - d-i doesn't bring up the network straight away
<cjwatson> I'm sure it's sitting there at the locale question
<spike> cjwatson: erg, sorry, missed a detail :). preseed works fine without the serial console
<Burgwork> Keybuk: ping
<spike> cjwatson: so I dont think it's that
<Keybuk> Burgwork: yo
<spike> cjwatson: to summarize: manual + sc = fine, preseed - sc = fine , preseed + sc = breaks
<cjwatson> spike: I'm in a meeting right now and will be leaving right afterwards, but perhaps you could mail me details of your setup and the problem
<Burgwork> Keybuk: your blog is almost the same as https://wiki.ubuntu.com/LookingFowardAtFeisty Mind if I crib off it?
<spike> that'd be great, thanks a lot
<spike> cjwatson: to which address shall I contact you?
<Keybuk> Burgwork: sure
<Burgwork> Keybuk: if you want to edit that page, please feel free
<cjwatson> spike: cjwatson@ubuntu.com
<Keybuk> note that I didn't mention telepathy much, because it's more of a "underneath feature that will be cool in later releases"
<cjwatson> Burgwork: "Forward"
<Burgwork> cjwatson: oops. it was late
<spike> cjwatson: ok, will send it tonight or tomorrow morning at worst. thanks a lot for your time
<cjwatson> np
<iwj> pitti: So the problem is this:
<iwj> If I hibernate my machine, and then boot the desktop cd, and the desktop cd has grown the ability to spot my fs's and mount them, then:
<iwj> The desktop cd will replay the journals of my fs's into the fs's while the hibernated install has them mounted.
<iwj> Then later I resume the hibernated system and it keeps using the filesystems.
<pitti> ah, right
<iwj> Result: hideous filesystem nightmare corruption doom.
<Mithrandir> iwj: so it shouldn't mount dirty fs-es.
<iwj> Right.
<iwj> This actually trashed my Ubuntu install at UBZ.
<Mithrandir> the current livecd doesn't automount partitions, so that would have been through some action of yours though.
<Mithrandir> in which case I'm a little less concerned.
<iwj> Mithrandir: Indeed.  But isn't MountAllLocalFilesystems supposed to change that ?
<pitti> we'll not do automatic mounting of partitions anyway
<iwj> And anyway it happens if you dual boot, too.
<iwj> Err, are you using `partition' to mean `on a hard disk' here ?
<pitti> right, I do; sorry
<iwj> Ie, distinguishing those from usb-storage.
<iwj> Well, the problem exists with usb-storage too.
<iwj> Do we automatically unmount usb-storage before hibernating ?  More to the point, does everyone ?
<pitti> hm, people hibernate on removable partitions which aren't in fstab?
<iwj> No, no, you misunderstand.
<iwj> This trashing doesn't just happen to the disk you hibernate onto.
<iwj> It happens to any disk mounted by the hibernated install, when during the hibernation another setup mounts it.
<pitti> ah, I see
<pitti> (sorry, half of brain is in meeting)
<iwj> :-)
<mjg59> Removable storage vanishes on hibernation right now
<pitti> iwj: is there a way to tell if a partition is dirty?
<mjg59> pitti: Not generically
<pitti> if so, then we should generally refuse to gnome-/automount dirty partitions
<pitti> mjg59: but for a particular fs type, I assume?
<iwj> Note that journaled fs's generally replay the journal to the disk even if you mount readonly.  (!!!)
<mjg59> pitti: Yes. You need to in order to know whether to fsck or not
<iwj> TMBSNMOTW "readonly" OWIWPU etc.
<mjg59> iwj: The fs wouldn't necessarily be consistent otherwise
<iwj> mjg59: Well, duh.
<iwj> Obviously I don't mind getting EIO for some of the contents.
<mjg59> Semantically, "readonly" has two meanings
<mjg59> But there's only one option
<iwj> It used only to have one meaning and nowadays it has silently changed to let the fs write to the disk.
<iwj> Mounting a dirty ext2 also involved mounting a possibly-inconsistent fs and you were supposed to fsck first.
<iwj> But no-one suggested that you should fsck before mounting ro!
<iwj> I can't believe you're defending this crazy behaviour.
<mjg59> That didn't fit my recollection, but on checking the code, you're right
<iwj> Err, I meant "before Linux hard journaled fs's" so I don't understand what you were checking.
<mjg59> ext2 will print a warning about mounting an unchecked fs
<iwj> Yes.
<mjg59> But skips that if you mount it read-only
<iwj> Obviously.  I don't mind it printing warnings.
<iwj> OIC.
<iwj> Yes.  But that's not my point.
<iwj> Supposing ext2 fsck built into the kernel for some reason.  Then no-one would have tolerated it running that and writing to the disk when told to mount ro.
<Keybuk> cjwatson: five second summary; new_id and bind aren't available to udev because the uevents come in too early
<Keybuk> and because they're a function of the *driver*, something udev has no information about, and no mapping from modules to drivers
<Keybuk> this needs fixing in the kernel
<fabbione> <cjwatson> I think the X driver saves the registers
<fabbione> cjwatson: not always.. some drivers almost reinit the card each time you switch stuff around like console <-> X
<mjg59> fabbione: But they try to switch back to whatever mode you switched out of
<fabbione> mjg59: true
<mjg59> So if we want to switch back to text mode, we need to switch out of text mode
<lamont> pitti: got a minute?
<lamont> pitti: why does gvm say this in it's logfile: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.Hal.Device.Volume" member "Mount" error name "(unset)" destination "org.freedesktop.Hal")
<pitti> lamont: in meeting, but I'll answer in a bit
<lamont> pitti: want me to email you all 5 files?
<Mithrandir> mjg59: ok, since it's per-driver, that won't work.  We can't work around that somehow either, I presume.
<pitti> lamont: probably you tried to mount a non-removable file system?
<pitti> lamont: sure, mailing log files is fine
<lamont> pitti: nope.  worked fine under dapper, dist-upgrade to edgy --> borked.
<lamont> pmount /dev/sdg1 works just fine
<mjg59> Mithrandir: Not in any way that springs to mind
<mjg59> Mithrandir: Best we could manage would be to use vesafb, but then we have suspend/resume nightmares
<pitti> lamont: or there is something wrong with libpam-console
<mjg59> Mithrandir: Hm. Actually...
<pitti> lamont: erm, s/pam-console/pam-foreground/
<dade`>  me fa ridere
<pitti> lamont: ok, I'll look at the logs
<mjg59> If we could fix vesafb so it can be unregistered and unloaded...
<mjg59> We might be able to make that fly
<mjg59> Mithrandir: I'll look into that. I can't promise anything, though.
<Mithrandir> mjg59: that'd "just" require vesafb to save the state when it's loaded, wouldn't it?
<Mithrandir> and then restore that on unload.
<mjg59> Mithrandir: No
<mjg59> Mithrandir: vesafb is in-kernel. It can't make vesa calls.
<Mithrandir> point
<Mithrandir> unless we embed x86emu in the kernel
<mjg59> Haha. NO.
<Mithrandir> ok, that was a bad idea. :-)
<tkamppeter> cjwatson, sfllaw, should I put a new SRU request into the bug report, with the successful test by the original poster and Scott's review of the UDEV rules as justification, and with the debdiff of the new 2ubuntu2 version?
<tkamppeter> cjwatson, sfllaw, it is about bug 65618
<Ubugtu> Malone bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix committed]  http://launchpad.net/bugs/65618
<tkamppeter> cjwatson, sfllaw, I cannot upload the fix to edgy-proposed, as I do not have upload access rights.
<sfllaw> cjwatson: Yes, put a new SRU request.  Send an e-mail.  Tag the bug.
<sfllaw> tkamppeter: ^^^
<sfllaw> tkamppeter: You will want to get someone here to upload the package for you.
<cjwatson> BTW, "udev" is not an acronym
<tkamppeter> pitti, can you upload the update from bug 65618 to edgy-proposed as soon as the SRU is approved? Thanks.
<Ubugtu> Malone bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix committed]  http://launchpad.net/bugs/65618
<pitti> tkamppeter: sure, please ping me once it is approved
<cjwatson> I'll look at it tomorrow
<cjwatson> have to run now, I'm afraid
<tkamppeter> sfllaw, how should I tag the bug, with what? I have already subscribed it to the SRU team.
<tkamppeter> And state is "Fix committed".
<cjwatson> tkamppeter: please read the StableReleaseUpdates wiki page; it has all the information
<tkamppeter> sfllaw, what is your e-mail address? Or should I mail to the SRU team?
<Burgwork> cjwatson: GNOME is turning on AT stuff during their dev cycle as well
<cjwatson> no need to mail the SRU team; I am aware
<cjwatson> Burgwork: I'll discuss later
<Burgwork> cjwatson: just wanted to tell you. Nothing to discuss, really
<sfllaw> tkamppeter: In the "Edit Description" field, you can add tags.
<cjwatson> but the one-line summary is that it is generally a mistake to turn things on during development that are difficult to turn off on upgrade to final
<cjwatson> at least for us, since we have many people who install development releases and upgrade
<tkamppeter> cjwatson, I have found what you meam, tagging comes in a later step.
<bhale> cjwatson: it isnt the Ubuntu Device Explosion Five?
<dade`> gaim keeps crashing, grr
<tahorg> hi
<tahorg> who is maintaining mysql-server-5.0 ?
<tahorg> looks like a direct import from debian
<robertj__> ooh the "Ask Mark" hour looks fine..."So Mark, are you...a Goer eh? You know, do you go?"
<tahorg> https://bugs.launchpad.net/distros/ubuntu/+source/mysql-dfsg-5.0/+bug/45694
<Ubugtu> Malone bug 45694 in mysql-dfsg-5.0 "Socket missing with mysqld" [Medium,Unconfirmed]  
* mc44 makes robertj__ put a quarter in the Monty Pytojar
<mc44> *Python jar
<tahorg> the title is bad, it's more precisely "mysqld is TOTALLY BROKEN on amd64"
<Mithrandir> tahorg: no, it's not.  It's just broken on intel em64t.
<Mithrandir> (due to a gcc bug)
<tahorg> Mithrandir: ho, I see.
<tahorg> Mithrandir: is there any way to workaround it with a gcc option ?
<tahorg> (I was removing the PREFETCH macros in the code)
<Mithrandir> tahorg: compiling it with -march=x86_64 should work, I'd think
<tahorg> Mithrandir: ok thanks
<Mithrandir> or -mno-3dnow
* tahorg dpgk-buildpackage
<giskard> Mithrandir, news about NM ?
<Mithrandir> giskard: no, not yet.  ETOOBUSY
<giskard> no problem :)
<Riddell> how oh how do I get emacs to let me edit .diff files?
<Mithrandir> M-x toggle-read-only
<Riddell> perfect, thanks
<mdke_> [OT]  can anyone share a procmail recipe for filtering wiki/spec mail?
<stgraber> mdke_: I think I have one, let me check
<stgraber> mdke_: http://paste.ubuntu-nl.org/33537/
<mdke_> stgraber: why thanks
<shawarma> I have a Edgy system, I installed via debootstrap, so that might the reason why, but having a /dev/root with mode 644 does not seem right... 
<shawarma> Have you all upgraded to Feisty yet, or can any of you confirm the presence and/or the need for that file?
<Adri2000> shawarma: ls: /dev/root: No such file or directory
<jdong> following mdke_'s format....
<jdong> [OT] : What's the best way to get Xen on Dapper?
<shawarma> jdong: I think there'a howto on the wiki somewhere.
<jdong> shawarma: yeah, a few howtos on the wiki
<jdong> all slightly different from each other :)
<jdong> and even more to be found with googling
<shawarma> Adri2000: Ok. Thanks for checking. It must be a leftover from somewhere in my installation process.
<frandavid100> hi guys
<mdke_> jdong: great opportunity to tidy up the howtos!! maybe make one howto to rule them all on help.u.c
<frandavid100> can someone tell me how to create a new screensaver from an existing one?
<jdong> mdke_: hehe, I'll do that if I ever figure out how to set up Xen :)
<mdke_> :)
<ajmitch> there are multiple howtos since xen isn't exactly supportable on pre-edgy
<ajmitch> not without grabbing stuff from edgy, or rolling your own
<jdong> ajmitch: I was considering going with xen sources and rolling my own
<jdong> ajmitch: I guess I'll improvise :)
<jdong> Edgy Xen hypervisor didn't boot on my machine, which puzzled me
<jdong> maybe I'm trying to use xen on a cursed machine
<jdong> oh well, what the heck else am I supposed to do on thanksgiving?
<Spads> thankstaking
<jdong> Spads: get all the camping gear ready for black friday day :)
<ajmitch> hi Spads, you heard that the latest kernel I got off zul booted a bit further?
* ajmitch didn't have the modules in the initramfs to keep booting
<Spads> ajmitch: when?
<Spads> jdong: which black friday is that then?
<ajmitch> Spads: hm, a day or so ago
<jdong> Spads: tomorrow, silly :)
<Spads> ajmitch: yeah, I've been able to boot into the hypervisor, but never been able to get a guest up, in i386 *or* amd64
<Spads> jdong: oh, what does camping gear have to do with it?
<ajmitch> Spads: not even with 2.6.16 & loading the appropriate modules manually?
<Spads> tomorrow is simply the day that americans justify building shopping mall parking lots at 300% capacity
<jdong> Spads: if you want all the good stuff you gotta camp for em :)
<ajmitch> what a country..
<jdong> Spads: at least around my place you do
<jdong> Spads: in fact, at this point there's 200-long lines at a few stores already....
<Spads> jdong: I don't know that they do much of that in London
<jdong> there goes my RAID 
<jdong> Spads: we US guys are crazy I guess :D
<HrdwrBoB> call me crazy
<HrdwrBoB> but I'd much rather sit at home in comfort
<Spads> I've never shopped on the day after thankstaking
<HrdwrBoB> and go the next day and pay full price
<HrdwrBoB> than fight hundreds of people
<jdong> HrdwrBoB: ah, but see, I'm asian :)
<jdong> (j/k)
* jdong decides to go for XenOnEdgy instead
<jdong> that looks a lot more simple to set up :D
<Spads> jdong: let me know how that works for you
<ajmitch> Spads: I've had no problems with xen on i386, at least
<ajmitch> I just haven't tried i386 xen on the amd64
<jdong> ajmitch: I couldn't get the hypervisor to boot on one of my amd64's in 64-bit
<ajmitch> hopefully in a day or two
<jdong> ajmitch: I'm guessing it's PEBKAC though
<ajmitch> jdong: couldn't get the hypervisor to go, or the kernel didn't boot?
<jdong> ajmitch: I think it's the hypervisor
<jdong> ajmitch: I get less than half a screenful of text and then a reset
<ajmitch> ok
<jdong> ajmitch: so I couldn't really determine if it was the hypervisor or trying xen0
<jdong> it was an AMD64 with LVM/device-mapper
<jdong> so it might've been an unusual setup
* ajmitch previously got as far as kernel panic & reboot, now it's up to not having stuff in initramfs
<ajmitch> hardly unusual
<jdong> ah, ok
<jdong> maybe I just gave up too early then
<jdong> ajmitch: though I would expect mkinitramfs to put in all the modules that all my other initramfs'es have?
<ajmitch> sure, but I wasn't using a packaged kernel as such
<jdong> ah, ok
<ajmitch> the only bit I copied in over the existing xen image was vmlinuz
<jdong> mmm I see
<jdong> well, off to reboot into xen
<jdong> hope for the best :)
<ajmitch> Spads: 2.6.16 is known to work with xen on amd64, as long as you load the appropriate modules in order to start guests
<Spads> ajmitch: oh?
<Spads> ajmitch: which modules?
<ajmitch> blkbk, xenblk, and there was one other iirc
<ajmitch> let me just look it up
<Spads> hmmmm
<ajmitch> they were previously loaded by the xend initscript
<Spads> that begs the question...
<ajmitch> why aren't they now? because they were compiled in for 2.6.17
<Spads> Ah, right
<ajmitch> blkbk, netbk, netloop
<Spads> hmmmmmm
<Spads> thanks
<ajmitch> something is working?
<Spads> ajmitch: no, I'll have to try that tomorrow after I reinstall the amd64 version
<ajmitch> alright
<zul> Spads: can you try a kernel im building as well tomorrow
<ajmitch> hey zul 
<zul> hey ajmitch 
<Spads> zul: what sort?
<zul> its another amd64 kernel
<Spads> okay, I'll give both a try
<jdong> ajmitch / Spads : wow, it worked quite nicely
<jdong> the only thing that didn't work stably was fglrx
<jdong> I hacked it to compile cleanly....
<jdong> but on any glx app I get a kernel oops
#ubuntu-devel 2006-11-24
<gnomefreak> is anyone elses feisty crashing when using apt or aptitude?
<jdong> ha! victory!
<jdong> xen+fglrx :)
* jdong attaches his fglrx patch to launchpad
<jdong> happy patching, folks, kthxbye :D
<Hobbsee> infinity: it looks like hal needs a rebuild, due to the new udev.
<Hobbsee> does someone who has power want to process that?
<infinity> Hobbsee: It just built... It needs to build again?
<infinity> https://launchpad.net/+builds/+build/277684
<Hobbsee> infinity: ah right, so it just hasnt been published
* Hobbsee looks
<infinity> Probably publishing as we speak.
<Hobbsee> infinity: way cool
<Hobbsee> infinity: yep, that will fix the problem
<infinity> Spiff.
<Hobbsee> :)
<ajmitch> Spads: latest kernel from zul has me booting a dom0 & domU on amd64, fyi
<fabbione> this channel is strangely too silent today
<mvo> good morning seb128!
<seb128> hey mvo
<seb128> still jetlaged, are you? ;)
<mvo> a bit, but it gets better
<seb128> k
<seb128> I was thinking when I've seen upload from you on -changes at 8am already
<seb128> :)
<mvo> seb128: this time I sleept until 7:30. a bit improvment :)
<seb128> yeah, that's good enough ;)
<fabbione> hey Keybuk 
<fabbione> Keybuk: i was just waiting for you :)
<Keybuk> oh aye?
<Keybuk> morning
<fabbione> eheh
<fabbione> nothing fancy.. i just test udev 103 ubuntu3
<Keybuk> right
<fabbione> and i noticed an extra "Terminated" in the boot
<fabbione> it looks like a process that's killed somehow
<Keybuk> yeah, dunno what that is
<fabbione> ok
<fabbione> it seems harmless
<Keybuk> I replaced the stupid shell that tried to kill udev (and sometimes failed) with just "pkill"
<Keybuk> but dunno what's printing "Terminated"
<Keybuk> could be that it's killing the shell script it's run from, of course
<Keybuk> AHHH
<Keybuk> that explains another bug actually
<Keybuk> let me try something
<fabbione> if you need me to test something just let me know
<fabbione> i have 2 machines where i can reproduce it
<Keybuk> break=top ... sed -i "s/pkill udev/pkill udevd/" scripts/init-bottom/udev  ... ^D
<Keybuk> aha! yes, that fixes my other bug too
<siretart> do we now get mail from the buildds for every FTBFS?
<siretart> or is this mail sent out in error again? 
<fabbione> Keybuk: testing...
<dholbach> good morning
<fabbione> Keybuk: yup
<mvo> Keybuk: it looks like the debian emacs21 has now a emacs package. should we use this or keep emacs-meta around (emacs-meta has more useful packages like emacs-nox, emacs-el)
<Keybuk> we could probably just add emacs-nox and emacs-el to the debian package
<infinity> siretart: It's intentional.
<infinity> siretart: And hopefully now correct.
<siretart> okay, then I must have missed some announcement about that
<siretart> infinity: the FTBFS was btw correct, looks like a bug in the package this time ;)
<siretart> I'm just surprised that the buildd tried to build that package at all
<infinity> siretart: I gave back the world.
<infinity> siretart: So, failure notices for all!
<Keybuk> infinity: my INBOX loves you
<infinity> And I love your IBOX.  Is it free later for dinner?
<Keybuk> ok, this is weird, evolution goes to the bottom of any message that I click on
<infinity> It knows you have a fetish for sigs?
<infinity> Or maybe it's subtly trying to say "use mutt"?
<mvo> Keybuk: sounds good, I can add this now to the emacs21 package. should I file a bug for removing emacs-meta from feisty then?
<seb128> Keybuk: you are using the caret mode (F7)
<Keybuk> mvo: sure
<Keybuk> seb128: ah, yes, turning that off fixes it -- must have hit F7 by accident or something
<Keybuk> what an odd more
<Keybuk> uh, "mode"
<seb128> that's an accessibility feature I think
<Keybuk> infinity: so, err, these build logs
<Keybuk> they go to the uploader?
<seb128> not sure if the "scroll to bottom" is part of the feature or a bug in that mode though
<infinity> Keybuk: That's the general theory, yes.  Well, to the SPR creator.
<Keybuk> infinity: I see
* Keybuk sends them all to /dev/null
<infinity> Keybuk: Let me guess, you did a mess of syncs or some such under your name?
<Keybuk> all syncs end up under my name :-/
<Keybuk> which is why LP thinks I own half the archive] 
<infinity> Keybuk: Well, see, that's just silly.
<infinity> Keybuk: We have we allowed that? :)
<Keybuk> infinity: bad things happened when I used -b lp_archive :)
<Keybuk> LP really needs a real person in that field
<infinity> Keybuk: Could have created a person in launchpad for the express purpose.
<Keybuk> could have, didn't seem worth the effort until now <g>
<mvo> what does the archive do when two source package build a binary package with the same name?
<Keybuk> that person would still need an e-mail address though
<Keybuk> mvo: picks the one with the higher version
<infinity> mvo: If the higher version one is uploaded last, it wins.  If the lower version one is uploaded last, it's rejected.
<mvo> clever archive
<Keybuk> this is the right thing, as it ensures that whatever wins is what would be downloaded onto user's machines
<Keybuk> (assuming both were visible to APT)
<fabbione> Keybuk: did you change something in upstart in feisty?
<Keybuk> fabbione: no, hasn't changed yet -- why?
<Keybuk> I've only got as far as the new udev
<fabbione> Keybuk: a strange behaviour at reboot that i can't see in edgy
<Keybuk> oh?
<fabbione> basically /etc/init.d/rgmanager stop is running and waiting for some stuff to close down and the machine just rebooted
<fabbione> Keybuk: i know for a fact that it takes about 10 secs for that to complete and it was ok in edgy
<Keybuk> what package is rgmanager from?
<cjwatson> Keybuk: what's wrong with the 'katie' LP person?
<Keybuk> cjwatson: I didn't know about that one?
<fabbione> Keybuk: rgmanager
<cjwatson> Keybuk: I told you about it ages ago. :)
<fabbione> Keybuk: but the stuff that's running requires much more to get there
<Keybuk> cjwatson: I never wrote it down then :p
<cjwatson> Keybuk: could you reassign the kickseed product to ubuntu-installer, if I make you a member of that team temporarily?
<Keybuk> cjwatson: not sure what you mean?
<cjwatson> https://launchpad.net/products/kickseed "Registrant: Scott James Remnant"
<Keybuk> oh, I see
<Keybuk> I think I can just do that
<Keybuk> yup, done
<cjwatson> ok, thanks
<pitti> Good morning
<dholbach> hey pitti
<\sh> hmm...what is the difference between libvolume-id0 and libvolumeid0 ? (which is in feisties debootstrap template)
<\sh> moins btw.
<thom> \sh: there's a hyphen in one
<infinity> Package rename?
<infinity> (That was rhetorical)
<\sh> infinity: well, I'm just asking, because of libvolumeid0 feisties debootstrap just breaks apart
<Keybuk> \sh: that's just because it's waiting to be removed from the archiev
<\sh> Keybuk: kk, only a matter of time :)
<Keybuk> let me see whether anything still needs it
<Keybuk> I did the necessary uploads yesterday
<mvo> hey pitti!
<Keybuk> Will remove the following packages from feisty:
<Keybuk> libvolumeid-dev | 093-0ubuntu18 | amd64, i386, ia64, powerpc, sparc
<Keybuk> libvolumeid0 | 093-0ubuntu18 | amd64, i386, ia64, powerpc, sparc
<Keybuk> ------------------- Reason -------------------
<Keybuk> (keybuk) NBS
<Keybuk> ----------------------------------------------
<Keybuk> \sh: fixed
<cjwatson> /home/lp_archive/ubuntu/indices/override.feisty.main:libvolume-id-dev   important       admin
<cjwatson> that's so not right :)
* cjwatson fixes
<Keybuk> odd, who NEW'd that
* Keybuk looks at Mithrandir :)
<Simira> Keybuk: he's sick and in bed.... I'll fetch him his laptop
<Keybuk> Simira: it's not important
<cjwatson> Keybuk: it's wrong in the source - put "Priority: extra" in the libvolume-id-dev stanza
<Keybuk> cjwatson: I never bother putting any section or priority in sources
<Keybuk> as they're meaningless and confuse dpkg
<cjwatson> maybe we should institute priority disparity mails at some point :)
<cjwatson> huh? they don't confuse dpkg
<Keybuk> so they're missing entirely and just inherited from the source
<Keybuk> they confuse something
<cjwatson> rubbish
<cjwatson> this is done all the time in Debian
<Keybuk> right, and I used to get dpkg bugs about it all the time
<cjwatson> since dak sends out override disparity mails
<Keybuk> when the control in a package and the Packages file don't match
<cjwatson> putting the right priority in debian/control cannot possibly make anything worse
<Keybuk> one goes in one database file, the other goes in another
<Keybuk> I tend to put no priority in debian/control :p
<cjwatson> you have one in the Source: stanza in udev, which is inherited by all the binaries
<Keybuk> true
<Mithrandir> Keybuk: no, I didn't new that.  At least, I'm fairly sure I didn
<Mithrandir> 't
<Keybuk> cjwatson: the problem with automatic mails would be that we change things compared to Debian
<Keybuk> and having an Ubuntu patch just for the section and priority would suck
<Keybuk> it should be filtered to only match -*ubuntu*
<cjwatson> mm
<cjwatson> it's probably inappropriate anyway
<cjwatson> we'd have people merging rather than syncing just for priority
<Keybuk> fabbione: in the server installer, don't we add another serial console getty ?
<infinity> It was me that NEWed udev, my bad for not checking the priorities.
* Keybuk spanks infinity
<Mithrandir> hah, so I'm innocent, for once.
* pitti blinks
<pitti> libsword-dev(inst 1.5.9-0ubuntu3 ! << wanted 1.5.8.90-1)
<pitti> Source-dependencies not satisfied; skipping gnomesword
<pitti> 1.5.9 < 1.5.8 ??
<Mithrandir> it wants << 1.5.8.90-1
<Keybuk> << dependencies are so bogus
<pitti> ah, ok, thanks
<crimsun> has rodarvus mentioned any plans for resyncing X.Org packages with Sid?
<fabbione> Keybuk: not automatically.. only if we detect that we are installing on serial console. cjwatson knows where to poke
<crimsun> right now source packages that build against libgl1-mesa-swx11-dev FTBFS because libGLw.a is missing (but the header files are included)
<Keybuk> cjwatson: which package is that?  Could we also detect installing on a ppc hvc0 console?
<cjwatson> Keybuk: rootskel already spots hvc, but finish-install may not
<cjwatson> finish-install is the one that prods init configuration
<cjwatson> Keybuk: do you have such a machine handy?
<cjwatson> crimsun: libGLw was intentionally removed
<crimsun> cjwatson: right, I noted as much in the changelog by Daniel S.
<cjwatson> building it required having lesstif in main
<cjwatson> ergo it's not a matter of resyncing ...?
<crimsun> ok, that's all I had to know. thanks.
<Keybuk> cjwatson: I wish ;)  if only the nice IBM guys would send me a PS3 for testing
<cjwatson> Keybuk: do you know of someone who does? I assume you have a reason for asking :)
<cjwatson> I need to know what 'stty --file /dev/hvc0 speed' says
<Keybuk> bug #72832
<Ubugtu> Malone bug 72832 in finish-install "no console started on cell machine" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72832
<cjwatson> replied
<Keybuk> thanks
<fabbione> Keybuk: i found the reason of the hang
<fabbione> Keybuk: it was really hidden
<Keybuk> oh?
<fabbione> https://www.redhat.com/archives/cluster-devel/2006-November/msg00246.html
<fabbione> it was totally related to the cluster state/consistency
<fabbione> and it's a rare corner case for clusters
<Keybuk> mvo: should emacs21-common depend on emacs21-common-non-dfsg
<Keybuk> mvo: or undo the split for us
<mvo> Keybuk: it seems to me like just adding the dependency is easier from a maintainabliity POV. the emacs21-common-non-dfsg package seems to be not yet in feisty though
<fernando> moin all
<Keybuk> mvo: I just uploaded it
<mvo> Keybuk: cool, thanks!
* mvo hugs Keybuk
<Keybuk> s/uploaded/synced/
<spike> cjwatson: I sent you that email about preseeding and serial console. apologies I forgot the attachments in the first one so I re-sent it
<Riddell> Keybuk: what does fake sync mean on kdesdk?  presumably something to do with me stupidly forgetting to add an ubuntu1 version number?
<Keybuk> Riddell: orig.tar.gz was different
<Keybuk> of course, if you actually had changes in that package, they're now gone :p
<Keybuk> so you may want to upload an ubuntu2 that restores any previous diff
<Riddell> ok, thanks
<Keybuk> feisty had 4:3.5.5-2
<Keybuk> unstable had 4:3.5.5-4
<Keybuk> therefore I assumed there were no ubuntu changes in feisty, so sync'd it
<Riddell> yep, my fault
<Keybuk> but the sync failed because our 3.5.5.orig.tar.gz didn't match Debians
<Keybuk> so the upload I did -4ubuntu1 was the Ubuntu orig.tar.gz with the Debian diff.gz
<Keybuk> so if there was anything in our diff.gz, it's gone now
<Keybuk> you may want to fix that <g>
<cjwatson> spike: thanks, will look later
<imbrandon> mMMm PS3 CELL hotness /me wishes 
<iwj> OK, I give up.  Anyone who knows about i18n madness who can help me ?
<iwj> ../../../man/po4a/start-stop-daemon.8/po/start-stop-daemon.8.pot
<pitti> iwj: ?
<iwj> Oops.
<iwj> Error: 'msgmerge -U ../../../man/po4a/start-stop-daemon.8/po/ja.po ../../../man/po4a/start-stop-daemon.8/po/start-stop-daemon.8.pot --backup=none' exited with value 1.
<iwj> is what I meant.
<iwj> So I ran it separately and it said:
<iwj> ../../../man/po4a/start-stop-daemon.8/po/ja.po:568:52: invalid multibyte sequence
<pitti> iwj: hm, does that line look like Japanese glyphs, or is it really some random gibberish?
<cjwatson> you might need to msgconv -t UTF-8 ja.po
<gnomefreak> what would spit out pci and bios errors on boot with the 2.6.19-6 kernel? is that initscripts,upstart or udev?
<cjwatson> IIRC msgmerge doesn't always do that itself
<pitti> cjwatson: hmm, but judging by the line number the majority of the file should be okay
<cjwatson> true, it may just be misencoded
<Treenaks> gnomefreak: the kernel itself?
<iwj> Just a mo, let me fine a utf-8 capable terminal.
<cjwatson> look up the charset in the .po file header and do iconv -f whatever-the-charset-is -t UCS-4 ja.po >/dev/null and see if it complains
<gnomefreak> k
<cjwatson> iwj: can you stick ja.po somewhere?
<iwj> iconv is happy.
<iwj> http://www.chiark.greenend.org.uk/~ijackson/d/ja.po
<cjwatson> looks like fuzzy garbage to me
<cjwatson> oh, sorry, UCS-2 not UCS-4
<cjwatson> <cjwatson@cairhien ~>$ iconv -f UTF-8 -t UCS-2 ja.po >/dev/null
<cjwatson> iconv: illegal input sequence at position 23049
<iwj> iconv: illegal input sequence at position 23049
<cjwatson> I'd be inclined to replace those four fuzzy msgstrs at the end with msgstr ""
<cjwatson> they're either not Japanese or not encoded in UTF-8
<pitti> In vim I see garbage, too, also in the next stanza
<iwj> Is this something MoM did ?
<pitti> iwj: they are marked as fuzzy anyway
<cjwatson> ah, they're EUC-JP
<cjwatson> well, one of them is
<iwj> Oh!
<iwj> MoM is merging the text but the character set lines will be different.
<iwj> Let me check.
<cjwatson> did ja.po change encoding from base to current Debian?
<pitti> iwj: MoM often jumbles up po files, did you use the merged result?
<pitti> iwj: in general, we don't want a Debian delta in .po files (we have Rosetta and langpacks for that)
<iwj> t
<cjwatson> pitti: dpkg isn't subject to language packs
<pitti> ah, dpkg
<cjwatson> but we should probably just take the Debian .po files verbatim
<cjwatson> IIRC the last time I touched dpkg we had no relevant changes to them
<iwj> I have to admit, when I diffed to generate my `remaining changes' I excluded *.{po,pot}.
<iwj> Was that wrong ?
<cjwatson> sounds reasonable; any changes to those would have been purely automatically generated
<iwj> Can I force them to be regenerated ?
<cjwatson> why not just cp them from the Debian source package?
<iwj> Err, well, I suppose because I thought that if that was generally the right answer MoM would already have done it ...
<cjwatson> .po files contain actual data, so you can't regenerate them from scratch; msgmerge -U is obviously trying to regenerate them, but if it's failing ...
<cjwatson> msgmerge -U => update .po file based on current .pot
<spike> cjwatson: mmmh, in the "Apt Setup" section from https://help.ubuntu.com/6.10/ubuntu/installation-guide/amd64/preseed-contents.html, it mentions the  d-i apt-setup/universe boolean true that you suggested me yesterday. Altho multiverse isnt mentioned. is that just missing or it's not there because it's not possible?
<iwj> cjwatson: Oh, yes, I remember.  Mixture of input and output in the same file.  So EBW.
<iwj> We should give up on this i18n madness and go back to US-ASCII.
<pitti> no, just give up on all non-UTF8 encodings :)
<cjwatson> iwj: the .po files in the current Ubuntu diff have line number references changed and one or two extra strings, so MoM thought it had to merge cleverly
<cjwatson> iwj: but in practice I don't think there were actually any translations of those extra strings, so we can throw them away and regenerate
<iwj> So is the deficiency in MoM that it didn't spot the charset change ?
<cjwatson> If Debian have taken your Breaks change to deb-control.5 then that should be everything
<iwj> No, they haven't.
<cjwatson> iwj: deficiency> yes, I think so
<cjwatson> it probably needs to apply msgconv before and after merging
<cjwatson> Keybuk: ^--
<Keybuk> ?
<cjwatson> iwj: the Ubuntu diff definitely had no new translations, so cping the Debian .po files and doing 'make -C man updatepo' should do the job
<cjwatson> Keybuk: the .po merging stuff in MoM needs to msgconv everything to UTF-8 first and then msgconv back to whatever the encoding is supposed to be (probably the encoding on the Debian side) before writing the output file
<Keybuk> how do you know what the encoding is supposed to be?
<cjwatson> the Debian side will be fine
<cjwatson> whatever the Content-Type line there says
<Keybuk> doesn't msgmerge dtrt anyway?
<Keybuk> I thought it did
<cjwatson> Keybuk: any encoding would be better than the mishmash you get at the moment though
<cjwatson> Keybuk: apparently not, and I've seen it get stuff wrong in the past when the files you're merging aren't in the same encoding
<cjwatson> my own scripts msgconv -t UTF-8 first
<cjwatson> for precisely this reason
<cjwatson> 04:01 Keybuk       mdz has a general "I want some way of forcing a driver bind"
<cjwatson>                    desire which came out of some s3kr3t meeting at UDS
<cjwatson> Keybuk: it wasn't secret, it was ubiquity-driver-updates :)
<Keybuk> cjwatson: heh
<cjwatson> Keybuk: why is modules.pcimap still there if it's obsolete? does something still need it for compatibility?
<Keybuk> because it would be a patch to suppress its generation
<Keybuk> it's still necessary for hotplug or grepmap based systems, after all, so the m-i-t maintainer won't drop it yet
<Keybuk> we use modules.alias these days
<cjwatson> Keybuk: so I could remove it from the d-i initrd?
<Keybuk> yup
<Keybuk> we still use ccwmap and inputmap
<cjwatson> only 80K or so saved, but still
<Keybuk> though in theory we can drop inputmap now
<Keybuk> in fact, we could probably drop *map and grepmap at this point, looking at it
<iwj> Crazy build systems R us.
<Keybuk> iwj: how did you know I was looking at glibc?
<iwj> FFS!  make clean fails because of fucking i18n braindamage!
<iwj> I'm too annoyed.  I shall go and have lunch.
<Keybuk> as the Chinese would say, 
<pitti> iwj: debdiff | filterdiff -x '*.po' ?
<iwj> Yes.  Or some such.
<spike> what's up with preseeding and raid+lvm? the guide states raid is not possible with preseeding, but doesnt mention lvm. does that mean that's possible? and why is raid a problem? is support for it planned?
<cjwatson> spike: LVM preseeding should work; in edgy you preseed partman-auto-lvm/disk to erase an entire disk and use LVM, and then the usual recipe stuff
<cjwatson> spike: RAID is a problem because until recently it hasn't been integrated into partman in such a way as to allow automatic partitioning. This is being actively worked on in Debian
<spike> any ETA are you aware of?
<cjwatson> no
<spike> cjwatson: k, thanks a lot, I'll look into tit
<cjwatson> I generally refuse to give ETAs anyway :)
<spike> ehehe
<sivang> morning
<tepsipakki> cjwatson: would it need more than just to sync partman-auto-raid from unstable?
<spike> eh, was about to mention that (just found it)
<cjwatson> that's still under active development and TBH I haven't yet looked it over
<cjwatson> it's extremely new
<spike> plus, I've found https://launchpad.net/products/partman-md
<tepsipakki> weeks old :)
<spike> isnt that enough?
<cjwatson> partman-md provides partman with RAID support, but not automatic installation
<spike> oh, ok
<cjwatson> it's not usefully preseedable
* spike looks into partman-auto-raid
* spike wonders how would that then glue with lvm
<cjwatson> also, look at https://code.launchpad.net/products/partman-md/ - I knew about partman-md ;-)
<spike> yeah ;)
<spike> quite a lot of the basic servers are raid1 + lvm
<spike> my hands are quite tied wrt preseeding if that's not possible 
<spike> I guess I could work around it with puppet, since everything is gonna be managed by that anyway
<spike> install a base system like it's already to a single small partition
<cjwatson> so I think you can probably use RAID recipes and the normal recipes together
<spike> then puppet will repartition raid/lvm the rest, copy the data over, and covert that partition as swap
<tepsipakki> how does puppet do _that_?-)
<cjwatson> although initial_auto_raid* appear to be after initial_auto in the sequence
<cjwatson> which might hamper that somewhat
<cjwatson> oh, erm, no, it seems to be tied to just putting a filesystem on each md at the moment
<spike> tepsipakki: uhm, what's the problem with that? it would do it the same way you'd do it manually :)
<spike> ok, I'll implement the puppet solution, it's safer anyway
<tepsipakki> spike: so it just runs scripts?
<tepsipakki> "just"
<cjwatson> (btw, partman-auto-raid will need a bit more than just being synced; I need to hack it up to cope with our partman-auto changes to accept autopartitioning automatically)
<spike> tepsipakki: sure, sfdisk, mdadm, lvmcreate/change/blablabla
<tepsipakki> is alioth.d.o down?
<tepsipakki> (if someone knew why it timeouts on me)
<spike> mh
<tepsipakki> um, forget that
<spike> I've added d-i apt-setup/local0/repository string deb http://repo.domain/ dapper main to my preseed file
<spike> the box installed fine, but some pkgs are missed. check sources.list and found this: "# Line commented out by installer because it failed to verify:"
<spike> and the repo commented out
<spike> gpg key for that repo is missing, is that the cause?
<spike> and is there some d-i param to disable the check so my mirror wont get disabled?
<spike> I can only see #d-i apt-setup/local0/key string http://local.server/key to specify one
<spike> but nothing to tell it to not bother checking
<tepsipakki> d-i     apt-setup/local0/key
<tepsipakki> preseed that as well
<tepsipakki> with an url to the key
<tepsipakki> oh
<spike> eheh :)
<cjwatson> key check sounds plausible
<tepsipakki> it needs to have a key
<cjwatson> no way to disable that at the moment short of vile hacks
<cjwatson> (e.g. prodding /target/etc/apt/apt.conf.d/ in a post-base-installer.d hook)
<spike> nm, I'll do the key signing now...
<spike> thing is I'm just testing so I didnt bother
<tepsipakki> be sure not to have strings like "contrib" or "non-free" on your repo string :)
<cjwatson> we could change apt-setup to allow you to disable signature checking temporarily, but the thing is that apt would complain later on unless you permanently disabled checking
<cjwatson> which seems suboptimal
<tepsipakki> it installs everything in one go
<spike> cjwatson: well, complain != refusing to install packages, so that would do for testing anyway
<spike> but again, I'll  just set it up, no worries, thanks
<cjwatson> apt-get update would return non-zero
<tepsipakki> malone 56009
<Ubugtu> Malone bug 56009 in apt-setup "generators/90security is trying to add contrib, non-free" [Undecided,Unconfirmed]  http://launchpad.net/bugs/56009
<cjwatson> which generally makes stuff object violently
<cjwatson> tepsipakki: oh, yeah, must fix that at some point ...
<tepsipakki> heh
<cjwatson> 13:43 < CIA-2> debian-installer: cjwatson * r42868 manual/en/appendix/preseed.xml: note that apt-setup/local* really needs a key
<tepsipakki> I fixed it by changing non-free -> restricted :)
<tepsipakki> on our own repo
<tepsipakki> (and dropped plf)
<tepsipakki> actually, it would be cool if the local* stuff would be added as files in sources.list.d
<tepsipakki> and the sources.list be kept as a vanilla version
<cjwatson> tepsipakki: 56009 fixed in bzr
<tepsipakki> cool :)
<cjwatson> haven't decided how to handle sources.list.d in general yet
<cjwatson> Keybuk: re NoUsplashTimeout, is there any way we can detect something trying to read() from the console?
<cjwatson> Keybuk: sort of like the way synaptic spots packages prompting and pops up the terminal
<Keybuk> cjwatson: how does synaptic do it?  pty for the console?
<cjwatson> Keybuk: my discomfort with NoUsplashTimeout is that it requires us to get all the init scripts right or stuff breaks, and there might be corner cases we won't normally notice
<Keybuk> init scripts are run with stdin=/dev/null, so corner cases will just break
<cjwatson> apache passworded ssl certificate (ugh, but still) are one case
<cjwatson> Keybuk: oh. you should mention that in the spec
<Keybuk> that's broken today in edgy
<cjwatson> pty> yes
<Keybuk> it's in the rationale isn't it?
<cjwatson> no
<Keybuk> oh, it got "simplified"
<cjwatson> unsimplify a bit and I'll approve :)
<Keybuk> done
<mamzers555> latest wpasupplicant-update breaks edgy and network-manager-gnome to connecto to wireless router
<Keybuk> err, ^R, deleted the last bit by accident when I submitted
<mamzers555> the version 0.5.5-3 dont work
<mamzers555> is this known, i couldn't found anything about it on launchpad
<giskard> mamzers555,  did you try to use wpa_supplicant by hand?
<mamzers555> sorry, no i just tried to use it with nm-applet
<cjwatson> Keybuk: thanks, approved
<zul> is it possibile to get someone to approve the xen-fiesty spec now that has been updated to include paravirt-ops?
<iwj> dpkg (1.13.24-ubuntu1) - how EBW is that ?
<infinity> That should be 1.13.24ubuntu1
<iwj> Isn't it better to .orig/.diff even if upstream it's Debian-native ?
<infinity> If you like to cause me confusion, I suppose. :)
<infinity> We tend to keep native packages native, and vice-versa.
<infinity> It's not like a debdiff between A and B is hard to do.
<iwj> Err, well, I don't want to cause any confusion.
<iwj> True.
<infinity> Also, "EBW"?
<iwj> But if you don't have the base version it can be tricky.
<iwj> `Evil, Bad and Wrong'.
<infinity> Ahh.
<infinity> We've been better about snagging base versions cleverly.
<infinity> And, eventually, we'll have all of sid in LP, with rolling updates.
<infinity> Which should solve it once and for all.
<iwj> In the Glorious New Republic.  Right :-).
<pitti> seb128: the avahi switch in network-admin toggles /etc/default/avahi-daemon and calls the init script?
<seb128> pitti: no
<pitti> seb128: ah, it calls enable_avahi?
<seb128> pitti: it runs /usr/share/avahi/enable_avahi
<seb128> correct
<seb128> with 0 or 1
<pitti> splendid, thanks
<seb128> np
<pitti> imbrandon: ping
<imbrandon> pitti: pong
<cjwatson> Keybuk: could I grab you in #ubuntu-installer for a moment, please?
<zul> .win 10
<seb128> grumpf
<seb128> something makes xorg goes back to gdm after 10min or something like that when I don't touch the computer
<giftnudel> seb128: screensaver?
<mjg59> Probably a screensaver triggering a crash
<giftnudel> or dpms
<seb128> I'm wondering if xorg crashes when the screensaver kicks on or something like that
<mjg59> Check the logs for the previous X session?
<seb128> syslog has a "gdm[4155] : Error reinitilizing server"
<giftnudel> seb128: can you test that with the preview feature of the screensaver?
<seb128> yeah, xorg doesn't like some screensavers apparently
<pitti> Keybuk: btw, nss-mdns is on your merge list; can you please ignore this one?
<pitti> Keybuk: I have a merged and fixed package here (since I'm assignee of ZeroConfNetworking), but I don't want to upload it before I did the other necessary fixes
<sbalneav> Under upstart, what's the magic to get it to reload glibc?  Getting ldap integrated into pam's a bit of a bear, as it requires a glibc reload.
<Keybuk> pitti: ok
<Keybuk> sbalneav: in edgy? same as in dappper
<sbalneav> Ah, cool.
<sbalneav> Same for feisty as well?
<pitti> keescook: ah, libnss-mdns works just fine now :) (I couldn't get it to work at all two weeks ago, remember?)
<nox-Hand> Hey
<nox-Hand> Can anyone tell me the kernel image name for 6.10?
<nox-Hand> like, 6.06 was casper
<pitti> nox-Hand: you are mixing three different things here; also, #ubuntu please
<nox-Hand> pitti, Asked there, but noone answered.
<iwj> doko: I think I need to talk to you about AMT fonts and fonts.conf.in ...
<nox-Hand> pitti, Its like the casper image or whatever; I just need the 6.10 name for it.
<bhale> the name 'casper' has never changed
<bhale> its part of the livecd infrastructure
<nox-Hand> Right.
<nox-Hand> Thanks
<mamzers555> latest wpasupplicant-update breaks edgy and network-manager-gnome to connecto to wireless router can somebody confirm this, i didn't found something about it on launchpad
<cjwatson> iwj: he's on holiday
<tonyyarusso> Hey, I just had a thought.  Various people have mentioned / written specs for / etc. the idea of having some sort of "Welcome to Ubuntu" tour/wizard/whatever run on first boot, automatically or being an icon on the desktop, as well as possibly Ubuntu Counter registration being available the same way.
<bhale> sweet! launchpad mails FTBFS
* pitti hugs infinity for those ^
* bhale hugs infinity.
<tonyyarusso> Of course, that runs into the problem of not wanting to clutter the desktop, and an auto-running tour might be annoying for some people.
<nox-Hand> auto-running would annoy me, but mates of mine I have converted from Windows to Linux would much like it. Maybe just an icon, or a pop-up balloon (thoug I dont like them either), that just tells you that you can run it by clicking 
<tonyyarusso> So, my thought that I'd like feedback on whether it would be more sane/acceptable: What if we made a welcome tour (and perhaps an offer to register with the counter) run the first, and only the first time a user clicks the little blue "?" icon in the panel?
<bhale> you mean the yelp launcher?
<tonyyarusso> bhale: Exactly
<bhale> not a fan.
<tonyyarusso> We'd need a way of differentiating the first run from all subsequent ones though
<bhale>  ~/.ubuntu-first-run
<iwj> cjwatson: Damn.
<tonyyarusso> bhale: How come?  What's still bad about it?  (Idea in progress, of course)
<bhale> but please do not dual-purpose launchers
<bhale> or any other ui element
<iwj> I suppose I'll just guess and email him.
<tonyyarusso> bhale: Valid point.
<bhale> if i click someting once, it should do the same thing as the 10th time I click it
<tonyyarusso> bhale: Is the idea of it being associated with a launcher (as opposed to auto-run or desktop icon) good though?
<bhale> I personally don't care for the idea at all, but I would prefer it to have its own launcher and leave me alone
<bhale> NLD has a launcher on the desktop
<nox-Hand> Is there a reason for the Grub bootloader not being decorated? Many of my first-time convertees have complained about it looking too geekish.
<tonyyarusso> bhale: While you may not want it personally (heck, I might not either), do you see the possible advantage in terms of new users, since we're getting more switches from Windows and fewer from other *nixes than originallY/
<bhale> which gives you an ogg video of the charming Ted Haggaer walking you through the desktop
<tonyyarusso> nox-Hand: I think they found that to cause problems for too many people last it was tried
<bhale> do you have any data to back up that last claim? windows vs unix
<tonyyarusso> bhale: Not hard numbers - just anecdotal evidence / watching #ubuntu at this point.  When elkbuntu publishes the survey results maybe we'll see if it's actually true.
<nox-Hand> tonyyarusso, Right. Good point. What about but a colour scheme? I even like the dark blue Debian one better :|
<tonyyarusso> Last time community survey numbers were published something like 85% had used some sort of linux before
<nox-Hand> I know it can be changed manually, but if it was but a bit more pleasing from the off.
<tonyyarusso> nox-Hand: I agree - I think there might be a proposed spec about decorating grub.  You might want to poke around Launchpad and leave a comment if nobody's proposed that.
<nox-Hand> tonyyarusso, Right.
<nox-Hand> Quick question (( I have never used 6.10 installer yet, so bear with me )); Does it ask whether or not it should install grub? I and a few others made a post about it on Launchpad, and it sorta got deleted, as it was called a duplicate; It was a completly different question. Its more that some of us already have bootloaders and dont want to lose the one we got due to Ubuntu deleting it - that should only be
<nox-Hand>  Windows that does that.
<tonyyarusso> bhale: What about the welcome thing's existence being determined by the state of a checkbox in the Live CD installer?  (similar to the "view readme afterwards" boxes on many windows app installers)  That would allow people who don't need it to just uncheck the box and never be bothered, and users of the alternate CD (usually more experienced in general) could just not be bothered at all?
<bhale> don't add pointless UI for some cranky developers
<bhale> if it is going to be there, put it on the desktop
<nox-Hand> bhale, Agreed. On the desktop a simple Shift+Delete will take care of it.
<tonyyarusso> That's what I would think to, but I believe Mark and some others are pretty vehemently against cluttering the desktop.
<TerminX> is feisty moving away from grub or something?  I noticed that dist-upgrade seems to want to remove it (grub) without replacing it with anything
<bhale> the discussion should probably be among the implementers on the spec wiki page
<tonyyarusso> TerminX: I haven't seen that...
<nox-Hand> tonyyarusso, What icons are there already? Isnt it irrelevant stuff such as Examples?
<tonyyarusso> nox-Hand: Examples and Install are only present on the live CD - after install it is completely clean
<TerminX> tonyyarusso: http://rafb.net/paste/results/5xySBQ39.html
<nox-Hand> tonyyarusso, Right. Its been too long since an install. I have just distupgraded always. Though, after a quick poke around Debian, I thought Id get a newer installer.
<tonyyarusso> TerminX: That's with most recent update?
<TerminX> yeah
<tonyyarusso> TerminX: Weird...I don't think I'd press y.
<TerminX> I noticed it when I was checking if dist-upgrade would resolve any of the held packages
<TerminX> oh, I didn't
<_MMA_> Hello guys. If I have a issue using the nVidia 9692 drivers in Edgy should I report it? As it might be an issue for Feisty?
<nox-Hand> Is there a 6.10.1? I saw it on a torrent site and thought what the..?
<TerminX> almost makes me want to play with grub2 though, heh
<tonyyarusso> nox-Hand: no
<nox-Hand> hmn, maybe someone just planted something on it then.. Ah well.
<nox-Hand> Be back later
<spike> uhm, has anybody got any idea what could a preseeding box be doing when it gets stuck on "Select and install software"? Retrieving file 60 of 64
<tonyyarusso> I see Xubuntu has a beta available for a welcome on first boot - https://blueprints.launchpad.net/distros/ubuntu/+spec/xubuntu-welcome-center
<spike> it started doing this as I fixed the problem with my mirror and gpg signed packages
<spike> so the only idea is it's failing retrieving those packages
<cjwatson> TerminX: no, we are not moving away from grub
<TerminX> I'll assume that's a bug, then
<cjwatson> mjg59: could you eyeball https://wiki.ubuntu.com/IntelMacSupport and tell me if there's anything blindingly obvious I've missed?
<spike> grrr
<spike> packages from my own mirror arent fetched during the installation process, yet as I ssh in and run apt-get update install it's all fine
<spike> the gpg key has been correctly added to the trusted keys, and packages install fine
<spike> so I cant see anything wrong itself with the mirror, gpg setttings and whatnot
<keescook> pitti: libnss-mdns> cool!  what changed?
<spike> argh, found it
<pitti> keescook: well, everything :)
<keescook> hehe
<pitti> keescook: back then I used the old edgy version, now I based my merge on Debian's -5 from snapshots and applied the changes from the spec
<keescook> fair enough.  in similar news, I'm having issues with network-manager at home; I need to attempt to connect twice -- first attempt times out.  no clue why.
<keescook> aah, very cool
<seb128> keescook: hey
<keescook> hi seb128!
<seb128> keescook: are you going to ask for the libgtop2 sync or should I do it?
<keescook> seb128: I was waiting for pitti to update the requestsync script :)  but feel free to go ahead without me
<seb128> keescook: he has done so
<keescook> I just wanted a quick example; I'm sure there will be more in the future.  :)
<seb128> feel free to do it then
<pitti> keescook: hey, I did that last week
<seb128> p.u.c/~pitti has the updated version where you can specify a version
<seb128> I've used it today, works fine :)
<keescook> pitti: ah-ha, okay.  I didn't remember if that was a planned or implemented change.  :)  I'll do it now.  :)
<mjg59> cjwatson: Looks good
<cjwatson> mjg59: excellent, thanks
<keescook> seb128: fun. debian changelogs doesn't have 2.14.4-2 yet.  *bang head on desk*
<seb128> keescook: yeah, website seems to be broken, no luck for you :p
<sfllaw> seb128: In bug 54684, is the Edgy version still In Progress?
<Ubugtu> Malone bug 54684 in nautilus "High CPU usage" [Unknown,Fix released]  http://launchpad.net/bugs/54684
<sfllaw> seb128: Same with bug 69566.
<Ubugtu> Malone bug 69566 in gst "time-admin crash with some icon set" [Unknown,Fix released]  http://launchpad.net/bugs/69566
<sfllaw> And bug 65797.
<Ubugtu> Malone bug 65797 in totem "(Edgy) 'Fit window to movie' doesn't work at all" [Unknown,Fix released]  http://launchpad.net/bugs/65797
<sfllaw> If you're happy with edgy-proposed, you will probably want to set them to Fix Committed.
<seb128> sfllaw: what do you call "In Progress", cjwatson did set them "In Porgress", I would have used "Fix Commited"
<seb128> yeah, I'm happy with edgy-proposed
<sfllaw> Fix Committed is "fix available somewhere".
<sfllaw> cjwatson: Please set edgy-proposed packages that are ready to verify as Fix Committed.
<sfllaw> We'll pull them back to In Progress if the fix is no good.
<seb128> sfllaw: changed to "Fix Committed", thank you
<sfllaw> Clarified this on StableReleaseUpdates.
<cjwatson> sfllaw: will do, thanks
<cjwatson> I vacillated between the states and picked one at random
<keescook> seb128: if I request a sync of libgtop2 2.14.4-1, won't the future ones show up again for free during the following autosync cycles?
<dholbach> keescook: yes
<seb128> keescook: yep
<seb128> keescook: they will sync on the current unstable one anyway probably
<pitti> cjwatson: when you updated shadow translations, did you simply download the bunch from Rosetta and replaced the ones in po/? Or did you do some fancy msgmerge'ing?
<dholbach> pitti: is https://wiki.ubuntu.com/MOTU/Teams/Security obsolete?
* pitti looks
<pitti> dholbach: hm, actually not at all
<dholbach> ok
<pitti> dholbach: ATM there is no 'MOTU security team'
<dholbach> recruiting! :-)
<zul> there should be
<zul> imho :)
<pitti> still, there won't be USNs for universe packages
<bhale> UUSN's :)
<pitti> and I don't have time for preparing updates, only for publishing them
<gnomefreak> mvo: you uploaded the gksu version 2.0.3-2ubuntu2 right?  now that i reinstalled due to apt crashing (not related to gksu update) i no longer have the upgraded version 
<mvo> gnomefreak: oh? interessting
<gnomefreak> what package was it that was updated? wasnt it libgksu or something of the like?
<gnomefreak> gksu version is stil 1ubuntu1
<mvo> libgksu2-0
<gnomefreak> ok ty i have it. there wa s abug reported on it and i was looking for the updated version and i couldnt find it
<cjwatson> pitti: I no longer especially care about shadow translations, as it isn't used in the installer any more
<cjwatson> pitti: maybe we should un-blacklist it
<cjwatson> pretty sure I used my rosetta-merge script though, assuming I had it back when I cared
<pitti> cjwatson: ok, I can handle the merging of po/; it's some more work to correctly merge debian/po/, but I'll manage
<dholbach> I think we can drop the note about bugzilla and ubuntu traffic from DeveloperResources
<bhale> dholbach: what about old MIRs?
<bhale> on the wiki
<dholbach> bhale: i think that pitti wants to have them for documentation reasons
<pitti> right, approved MIRs should stay
<bhale> ok
<bhale> there is some old mono docs here
<bhale> i will remove them
<sfllaw> keescook: Bug 65795 is OK.
<Ubugtu> Malone bug 65795 in vino "vino won't accept my password" [High,Fix committed]  http://launchpad.net/bugs/65795
<keescook> sfllaw: cool, thanks.
<sfllaw> keescook: Did you valgrind vino, by any chance?
<keescook> sfllaw: I didn't, no.  is that on the list?
<sfllaw> No no.
<sfllaw> I'm just wondering if you introduced a memory leak there.
<sfllaw> Oh, it's in vino_prefs_init.
<sfllaw> Now that I look harder, it looks basically fine to me.
<sfllaw> That's a stupid place to free the password.
<sfllaw> keescook: Feel free to upload to -updates.
<keescook> sfllaw: I thought I had to wait a week first?
<sfllaw> No no.
<sfllaw> Ah.
<sfllaw> It's only been in -proposed for a few days, right?
<sfllaw> I forgot it sat in NEW for two weeks.
<keescook> correct
<keescook> right.  :(
<sfllaw> Wait until the 28th then.
* dholbach hugs keescook like he hasn't seen him in 10 years
<sfllaw> But at least it works.
* sfllaw hugs dholbach.
* keescook shrieks and hi-fives dholbach
<sfllaw> So, dude, I haven't seen you in 10 years.
<sfllaw> Wanna go out for a beer?
<keescook> hehe
<dholbach> sfllaw: how pumped do you feel today?
<sfllaw> You know, I have to admit that I haven't gone to the gym in a while.
<dholbach> right
* LaserJock wonders what they put in the drinks at the all-hands
<keescook> LaserJock: apparently, iced tea.  always.
<sfllaw> http://www.youtube.com/watch?v=nlRs_WeQmnM
<LaserJock> keescook: sure it wasn't spiked with some go-go juice?
* keescook worries about go-go infection
<LaserJock> dholbach has already flooded my mailbox this morning
<LaserJock> and yes it is infectious
<Mez> I just had a rather random ubuntu dream
<tonyyarusso> Mez: Oh?
<Mez> Ubunu "9,99" with some random f**ked up CDs . ... an old laptop and jdub
<Mez> it was random
<tonyyarusso> Mez: Oh shoot..I had an actual question for you and can't remember what it was
<Mez> lol
<tonyyarusso> Mez: Not sure if this was it, but I just came up with on - not really appropriate here, want to take it in classroom or offtopic?
<Mez> -nun
<tonyyarusso> 'k
<aka_druid_> hi
<aka_druid_> hi again
<yaloki> aka_druid_: hi
<aka_druid_> yaloki: hi
<yaloki> aka_druid_: 'sup
<aka_druid_> super sup
<aka_druid_> how was the week?
<yaloki> none, havin a bud, watching the game
<coyctecm>  /msg NickServ IDENTIFY 1q2w3e
<bhale> good one.
<coyctecm> :D
<coyctecm> LOL
<aka_druid_> yeah, it was his pass...
<aka_druid_> yaloki: true true
<zul> you might want to change that now
<yaloki> ahahah
<yaloki> I guess someone already changed it for him ^^
<coyctecm> :D
<yaloki> ahahahah
<aka_druid_> gee
<yaloki> hmmm... new gkrellm version out, who would have thought
<aka_druid_> yaloki: maybe he needs some incentive to change his passwd
<aka_druid_> yaloki: cool really like this app
<yaloki> aka_druid_: seems so ^^
<yaloki> aka_druid_: package done
<coyctecm> now it's ok. :)
<yaloki> indeed
<yaloki> coyctecm: what did you type to change the password ?
<coyctecm> i dropped my nick and reregistered with new password
<yaloki> I meant the irc command
<zul> so um whats your new password? ;)
<coyctecm> :D
<yaloki> zul: you just blew it
<coyctecm> hah
<coyctecm> :D
#ubuntu-devel 2006-11-25
<anir> #suse-es
<anir> #suse
<Burgwork> anir: hmm?
<_ion> I believe she means we should start talking about Ubuntu development on those channels. I think this channel is more suitable, though.
<Burgwork> right
<LaserJock> I thought this was the opensuse devel channel? doh
<LaserJock> ;-)
<alex-weej> LOL did anyone get that email from "Shark Muddleworth" on ubuntu-devel?
<infinity> No, you're the only one who got it.
<infinity> (It's a mailing list, asking if people got the mail seems silly)
<crimsun> I'm a bit befuddled at this FTBFS:  "Error: Package: and Architecture: do not alternate in debian/control"
<infinity> crimsun: It's either a bug in pkg-create-dbgsyms (bug pitti), or you're actually generating broken control files.
<crimsun> http://librarian.launchpad.net/5157781/buildlog_ubuntu-feisty-i386.realtime-lsm_0.8.7-2ubuntu1_FAILEDTOBUILD.txt.gz
<crimsun> it's appearing right after dh_strip is called
<infinity> Yes, which would be pkg-create-dbgsyms.
<crimsun> ok, thanks.
<alex-weej> *has anyone read it
<infinity> But it doesn't mean your package isn't buggy anyway.
* infinity checks.
<alex-weej> infinity: cock monkey :P
<crimsun> infinity: the original sync (which built in Debian) directly from Debian Sid FTBFS, too, so I don't think it's a buggy package
<infinity> crimsun: Hrm, the package looks okay at a glance.  But pitti about the error.
<crimsun> ok, danke
<infinity> Oh, wait.
<mjg59> infinity: Dude, Saturday.
<infinity> crimsun: The Source stanza has an Arch line.
<infinity> crimsun: That's not allowed.
<infinity> crimsun: Remove it, SVP.
<crimsun> interesting, thanks
<infinity> crimsun: (And file a bug in Debian on it, please)
<crimsun> will do, with patch pushed.
<infinity> mjg59: Saturwhat?
<bluefoxicy> jdub:  still trying to get grsec working?
<luisbg> anybody knows a dbus service made in python?
<Fall2Hell> anyone here?
<Hobbsee>  perhaps
<Fall2Hell> i need help
<Hobbsee> sounds like a #ubuntu type of question
<Hobbsee> see the /topic
<Fall2Hell> sorry
<Fall2Hell> wrong chanel :)
<Fall2Hell> thx
<Hobbsee> if you're not actually saying what it is...we cant really help
<StevenK> sfllaw: Hi. Have you got a sec to talk about wlassistant?
<sfllaw> StevenK: Oh man, it's 1:43.
<sfllaw> And I'm a bit tipsy.
<sfllaw> So technical talk is a bit out.
<sfllaw> But I can try.
<StevenK> sfllaw: I'd suggest leaving it then.
<sfllaw> StevenK: Is this about the SRU?  And my concerns about the usleep()?
* StevenK nods.
<sfllaw> StevenK: I can talk about that.
<StevenK> sfllaw: Ah.
<StevenK> sfllaw: I agree with you, that usleep() may be a bit racy on slower hardware, but what to do instead?
<StevenK> sfllaw: My only thought is looping for a maximum of say 5 seconds, checking that an IP has been assigned.
<sfllaw> By the time dhclient exits, hasn't it finished configuring things?
<StevenK> It forks and daemonizes
<sfllaw> Does it daemonize instantly?
<sfllaw> Doesn't it write stuff?
* StevenK will have to check that.
<StevenK> You're suggesting don't usleep() at all?
<sfllaw> It daemonizes _after_ assigning an IP.
<sfllaw> Lemme look at the source.
<StevenK> I'm happy to upload 3.2 that dumps usleep() or does something else.
<sfllaw> StevenK: Hmm.  Looking at WirelessAssistant::runCommand, it looks like it exits after the command it runs does.
<sfllaw> Is that true?
<StevenK> sfllaw: It also has a timeout.
<sfllaw> StevenK: It will return ::ERR::killed if the timeout hits, right?
<sfllaw> And then you return in that case.
<sfllaw> Due to CONNECTION FAILED.
<sfllaw> So I guess I'm not concerned anymore about that usleep.
<sfllaw> It's just superfluous.
<sfllaw> By the time dhclient exits, it should have set things and run all its exithooks.
* StevenK nods.
<sfllaw> OK.  Well, I can test it on Monday and let you know.
<StevenK> Right. Thanks.
<sfllaw> Did you uncomment that usleep line because it looked like it shouldn't have been commented out?
<StevenK> And also I wasn't certain of dhclient's behaviour.
<sfllaw> StevenK: UTSL!
<StevenK> Yeah, well. :-/
<sfllaw> StevenK: Also, always be weary of arbitrary sleeps.
<StevenK> Good advice.
<infinity> s/weary/wary/, I assume, though "weary of sleep" is cute. :)
<sfllaw> infinity: I love bad puns.
<infinity> Especially when they can be used as a cover for poor spelling? :P
<sfllaw> Indeed.
<sfllaw> The puns go up as the wine goes down.
* StevenK tricks update-manager.
<StevenK> archive.ubuntu.com has address 192.168.7.9
<StevenK> Let's see it download from the internet now.
<dade`> someone using a macbook here ?
<raphink> o_O
<raphink> linda wishes itself a happy birthday today
<raphink> when you launch it
<ajmitch> raphink: look in /usr/share/python-support/linda/linda/eggs.py
<raphink> hi ajmitch
<ajmitch> hello
<raphink> :)
<raphink> ajmitch: lyricue is on REVU. Do you think you could have a look and complete what I already said about it?
* ajmitch can take a brief look
<raphink> thanks http://revu.tauware.de/details.py?upid=3461
<cjwatson> hmm, oops, we broke USB stick installs in Edgy :-(
<cjwatson> bug 66220
<Ubugtu> Malone bug 66220 in busybox "ubuntu edgy hd-media image couldn't mount iso file." [High,Confirmed]  http://launchpad.net/bugs/66220
<Hobbsee> cjwatson: with the hal update?
* cjwatson will look at the feasibility of backporting that on Monday
<cjwatson> Hobbsee: the clue's in "... in busybox"
<Hobbsee> ah, that's different, sorry
<cjwatson> i.e. no, nothing to do with hal. hal doesn't run in the installer
* Hobbsee seems to be seeing reports of the new hal breaking USB sticks in edgy
<Hobbsee> yeah, hadnt actually read the report yet.  didnt even see installs in there
* Hobbsee must need sleep
<Mithrandir> Hobbsee: when you're doing merges, please do actually list the changes still present, not just "All changes preserved"
<Hobbsee> Mithrandir: okay.  usually i do.  which was this for?
<Mithrandir> Hobbsee: a bunch you did two or three days ago
<Hobbsee> hrm
* bhale pokes Hobbsee with a pointy stick of doom
* Hobbsee ignores bhale 
* Hobbsee is skewered
<Mithrandir> https://lists.ubuntu.com/archives/feisty-changes/2006-November/001191.html for instance
<Hobbsee> ah
<Mithrandir> Hobbsee: if you tend to do it, that's fine, I just noticed two or three in a row and thought I should poke you about it.
* Hobbsee doesnt remember
* Hobbsee has a very deaded brain
<Hobbsee> i probably did
<Hobbsee> Mithrandir: when will heno be back here? office hours, presumably
<Mithrandir> Hobbsee: monday, 0800 UTC or thereabout, I'd imagine
<Hobbsee> ok
* bhale writes a somewhat long changelog for Mithrandir 
<bhale> take that :)
<bhale> not BenC long, mind you
<Hobbsee> bhale: i wonder if there's a limit on how long they can be.  guess not
<bhale> hi pitti 
<bhale> someone marked lp #65886 as "security vulnerability", it is a normal segfault
<bhale> can you debunk?
<bhale> "This bug may be a security problem since segfaults in unmanaged native code are often exploitable."
<Mithrandir> bhale: but you can run code as yourself!
<bhale> Mithrandir: oh nose!
<pradeep> bug 65886
<Ubugtu> Malone bug 65886 in beagle "beagle segfaults in libwv native code" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65886
<bhale> ah that is where I can unmark it
* bhale takes it off pitti's whiteboard
<lamont> pitti: any word from those logfiles?
<pitti> hi bhale
<pitti> lamont: I looked at them, but they gave me no clue
<lamont> pitti: figures
<lamont> note that nss has ldap involved, although the user in question resolves completely within 'files'
<pitti> lamont: a hal debug log *might*
<lamont> pitti: ok.  same instructions as edgy?>
<lamont> er, dapper
<pitti> yes
* lamont needs to run off for a couple hours, but will do it after that
* pitti grumbles about feisty udev not working any more on 2.6.17 kernel
<bluefoxicy> <Mithrandir> bhale: but you can run code as yourself!
<bluefoxicy> Mithrandir:  actually a hole in libwv would more likely mean someone could dcc you a word document, your auto-accept would stick it in ~/dcc/, and then beagle would index it and libwv would run code from it
<bluefoxicy> but you have to actually have an exploitable hole; some segfaults are, but some fall short.
<Mithrandir> bluefoxicy: don't take candy from stangers.
<Ng> xchat-gnome in edgy defaults to auto-accepting dcc :/
<bluefoxicy> Mithrandir:  I know I know, people fill my disk up once in a while
<sladen> mpt: you'll love http://www.joelonsoftware.com/items/2006/11/21.html
<Mithrandir> sladen: as somebody in here commented - we can't suspend and hibernate reliably enough yet and it also doesn't give the user the ability to differentiate between "I'm going away" and "I'm going away and would like my programs to keep running".
<sladen> Mithrandir: what I found scary was that all the continion we'd had over the "big logout dialogue" and to find out that MS had come up with the same "show them all"
<cjwatson> bhale,Mithrandir: given that it's while indexing mailboxes, surely "somebody can send you a mail that can run code as you" is closer to the mark than "you can run code as yourself"
<cjwatson> Joel employs the disgraceful debating tactic of pre-emptively discarding any argument that disagrees with him
<bhale> cjwatson: one of the bigger problems with beagle (or anything like it)
<sladen> Mithrandir: while you're around, did you have further ideas to add at the end of https://wiki.ubuntu.com/LiveCDStackedFileSystem
<Mithrandir> cjwatson: it's harder to argue your mail server shouldn't take candy from strangers, I guess.
<Mithrandir> sladen: yes, but not on a Saturday early evening.
<siretart> is nov 30 still targeted for herd1? there seem to be no dailies yet
<cjwatson> siretart: hard to say yet - I haven't finished merging the installer, which is why there are no dailies
<cjwatson> working on that as fast as possible
<cjwatson> ubiquity will need a half-day's work to deal with partman-auto changes
<cjwatson> if the first CDs Just Work then the 30th may be possible, but if not then it may be optimistic ;-)
<siretart> cjwatson: no problem 'bout that. I just looked at FeistyReleaseSchedule and wondered that herd1 is scheduled that early from now
<MatthewG> fsck.ext3 -nv /dev/sda1 reports this ... http://paste.ubuntu-nl.org/33925/ ... this is a second box, and it shows the exact same things. What gives? It's ubuntu server install with LAMP option. Is ubuntu installing a borked filesystem or something? 
<revoltee> hi
<revoltee> how is ubuntu comparatively tyo deian
<revoltee> debian
<revoltee> very different?
<revoltee> i mean kernel wise
<Lathiat> kernels are quite different yes
<Lathiat> notably ubuntu adds drivers and makes some modifitions etc, AIUI debian packages pure stock kernels?
<siretart> Lathiat: the debian kernels are patched quite heavily as well. e.g. they have kernel images with linux vserver and xen and both
<sladen> the debian kernels are not 'stock'---they too have patches, as required
<Lathiat> oh hrm ok, i thougth they didnt at all
<sladen> but not quite the number of driver/latest crack patches that Ubuntu attempts to ship
<Lathiat> apparently i was wrong :)
<revoltee> so in short
<revoltee> debian kernels are way better
<siretart> revoltee: who says this?
<Lathiat> "better" is subjective
<revoltee> siretart: im asking
<siretart> revoltee: the debian kernels support less hardware. what do you mean with 'better'?
<revoltee> better as in performance
<revoltee> optimizatioin
<neuralis> revoltee: how did you infer anything at all about performance from the conversation above?
<neuralis> revoltee: we ship a desktop kernel, a server kenrel, a supercomputer kernel, and a xen kernel. all are tuned to their respective uses.
<siretart> IIRC ubuntu's kernel is compiled with SSP. so it is potentially more 'secure' 
<sladen> ..looking carefully at your userspace is far more likely to create gains than tinkering with the kernel
<ssam> is there anyone around that i could talk to about a possible security bug in ubuntu (i think it might be specific to powerpc)
<Laser_away> ssam: it seems pitti isn't here at the moment
<Laser_away> ssam: you might just want to file the bug and make sure to mark it as a security bug
<ssam> Laser_away, ok, i just thought i should check that i was not being silly first
<revoltee> i test all the live installations of linux .. in vmware before really trying to install or run it live with  a reboot ..
<revoltee> o how does it actually partition the RAM and stuff and run an OS inside an OS
<revoltee> so
<revoltee> just need a basic idea of how vmware does this
<revoltee>  question is how is the bridging done ..?
<siretart> revoltee: this channel is about ubuntu development. please ask in #ubuntu for end user support
<ajmitch> hi siretart 
<ogra> BenC, around by chance ?
<siretart> hey ajmitch 
<JB[away] > Any news about this bug ? -> https://bugs.launchpad.net/distros/ubuntu/+source/apache2/+bug/62820
<Ubugtu> Malone bug 62820 in apache2 "RPC over HTTP" [Medium,Unconfirmed]  
#ubuntu-devel 2006-11-26
<tonyyarusso> Hi..I have a question regarding device drivers and development bounties:
<tonyyarusso> I just bought a digital voice recorder, and while it registers in /var/log/syslog and 'lsusb', it doesn't seem to show up in /dev as anything recognizable or mount itself.  Googling hasn't come up with anything yet (still looking), but I may be stuck unless I can get someone to write a driver for it.
<tonyyarusso> I would be willing in principle to offer a bounty for such a thing, but given my budget I would not be able to make it very much - certainly not market rate for a programmer.  So, with bounties, are most people happy to see any sort of bounty being offered, or would they find a small one (say, ~$15) insulting and actually be less likely to help me?
<LaserJock> I suppose you could find like-minded people and pool resources
<tonyyarusso> Do you think there would be enough people with this particular recorder using Linux for that to make a difference?
<LaserJock> well, you only need to find 1 rich one ;-)
<tonyyarusso> haha
<tonyyarusso> So....college buddies - who's rich?  Darn.
<tonyyarusso> But anyway, the more important point is, even if they wouldn't do it for a low amount, would I at least not be offending anyone by offering it?
* tonyyarusso looks around LP to see what things go for
<LaserJock> I'd think as long as you are upfront in saying you realize that it isn't equal to the amount of time required
<LaserJock> more of a token offering
<tonyyarusso> Okay.
<tonyyarusso> Thank you.
<Hobbsee> hey ogra 
<ogra> yo
* ..[topic/#ubuntu-devel:Hobbsee] : Ubuntu Development (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy is released | coreutils 5.97-5.2ubuntu1 broken, make sure you got 5.2ubuntu2 | udev 103-0ubuntu[12]  broken, make sure you got 103-0ubuntu3
* ogra yawns ...
<Lathiat> 
<dade`> 
* Starting logfile irclogs/ubuntu-devel.log
(ogra/#ubuntu-devel) /usr/lib/pygtk/2.0/demos/colorsel.py
<viller> can I acces the color selector directly in pygtk (i'm a n00b sorry :P)
<viller> ?
<ogra> viller, hit alt+F2 and type in: python /usr/lib/pygtk/2.0/demos/colorsel.py 
<viller> I already tested it
<ogra> if you want to run it from a program you write look at the code of /usr/lib/pygtk/2.0/demos/colorsel.py
<viller> ok
<viller> the gtk color selector should have a value slider IMO
<sivang> jono: ping
<sivang> jono: actually, unping
<sivang> nm
<ogra> BenC, any idea about bug 73336 ? 
<Ubugtu> Malone bug 73336 in linux-source-2.6.19 "linux-libc-dev is missing linux/linkage.h header" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73336
<mhb> hi all, do you know if one can translate the "Unsafe device removal" message that appears when you remove a USB stick without ejecting it first? I tried grepping /usr/share/locale-langpack but I can find it neither there or in Rosetta
<pianoboy3333> Where can I get the latest libnautilus-burn?
<theCore> who should I ask for getting a mailing list for my team?
<corduroy> i have edgy installed and use the courier mail server.  i want to the latest release of courier.  before i start building my own new packagage, is there a repo of "testing" packages for ubuntu.. stuff that hasn't been qa'd yet?
<corduroy> grimboy: you mean /etc/motd?
<mdke> theCore: mailman@lists.ubuntu.com (it says it on the front page, near the top)
<theCore> mdke, I did send an email but I didn't receive any responses 
<theCore> that why I am asking
<ssam> is pitti around? i have a possible security bug (i think restricted to powerpc)
<Mithrandir> pitti: ^^
<ssam> or a developer with a powerpc machine who i can talk to
<mdke> theCore: that's the address
<Chipzz> ssam: if you're referring to the libwv crash, there was a little discussion about that here yesterday, and IIRC the consensus was that it was not a security bug
<theCore> mdke, thanks  
<theCore> mdke, I resent my email a few hours ago
<FliesLikeABrick> has it ever been discussed to have a minimal CD that downloads the packages needed for a ubuntu installation at install time, resulting in a 50MB image or so rather than a 600+MB image?
<FliesLikeABrick> like debian has
<mdke> theCore: fine. It may have just arrived at the wrong time (summit)
<Burgundavia> FliesLikeABrick: that is called netinstall and it already exists
<FliesLikeABrick> I have never seen a CD image for it and I'm not talking about a full CD-less net install
<FliesLikeABrick> I'm talking about something that looks and feels like an alternate install CD, but instead of using packages on the disk it downloads from apt repos
<FliesLikeABrick> hm
<stgraber> http://archive.ubuntu.com/ubuntu/dists/edgy/main/installer-i386/current/images/netboot/mini.iso
<FliesLikeABrick> yeah just found that
<FliesLikeABrick> why isn't that advertised at all?
<FliesLikeABrick> I think that a ton of people would use that if they knew about it
#ubuntu-devel 2007-11-19
 * Hobbsee waves
<ajmitch> hi Hobbsee
<ion_> Howdy
<Hobbsee> ajmitch!
<pitti> Good morning
<StevenK> Morning pitti
<jdong> why hello, pitti :)
<pitti> jdong: 'why'?
<jdong> pitti: nothing, I've got nothing to bug you about today ;-)
<Hobbsee> pitti!
<jdong> actually... *checks his todo list*
<Hobbsee> jdong: i'm sure someone can find something for him to do.
<pitti> jdong: :)
<pitti> hey Hobbsee
 * pitti hugs StevenK and Hobbsee (long-arm Australian hug)
 * Hobbsee hugs pitti back, with her equally long arms :)
 * StevenK grins and hugs pitti back
<Hobbsee> pitti: you should come visit us for proper hugs.  coming to LCA?
<jdong> pitti: can you just do one quick backport (bug #162768), as there's an upcoming mplayer upload that'll tighten b-d's too much to backport, and that might happen before the next time backports is processed?
<ubotu> Launchpad bug 162768 in gutsy-backports "Please backport mplayer 1.0~rc2 from Ubuntu hardy" [Undecided,In progress] https://launchpad.net/bugs/162768
<pitti> Hobbsee: not very likely :(
<Hobbsee> :(
<pitti> jdong: done
<jdong> pitti: thanks :)
<warp10> Hi all!
<superm1> pitti, would you be able to poke the mythtv sru?  It's been waiting for an archive admin to ack it for almost a month now
<superm1> bug 158562
<ubotu> Launchpad bug 158562 in mythtv "PVR-350 Video output fails" [Low,In progress] https://launchpad.net/bugs/158562
<Karnaugh> hello
<Karnaugh> I'd like to steal the skin from the Ubuntu moinmoin :P
<dholbach> good morning
<Hobbsee> oh noes, it's dholbach!
<warp10> dholbach: hi!
<dholbach> hey Hobbsee
<dholbach> heya warp10
<Hobbsee> hi dholbach!  :)
<LaserJock> Karnaugh: you might want to email the Ubuntu webmaster
<LaserJock> dholbach: guten Morgen
<StevenK> LaserJock: Ponies!
<dholbach> heya LaserJock
<pitti> hi warp10, just answered your mail
<pitti> superm1: I did look at it, see https://bugs.edge.launchpad.net/ubuntu/+source/mythtv/+bug/158562/comments/6
<ubotu> Launchpad bug 158562 in mythtv "PVR-350 Video output fails" [Low,In progress]
<warp10> pitti: morgen, martin. Just got it, thanks :)
<pitti> superm1: isn't there an actual *patch* which fixes the problem?
<pitti> hey dholbach
<superm1> pitti, the driver was rewritten to fix the problem
<superm1> pitti, which is what that patch is
<superm1> because it changed upstream ivtv
<dholbach> heya pitti
<pitti> right, but with that we don't know how many new problems it created
<pitti> i. e. we break mythtv for some people to fix it for others
<superm1> well none, because its only used for ivtv video output
<superm1> video input is a completely different subsystem
<superm1> and isn't that the point of the sru, to get further testing?
<pitti> the point of -proposed uploads is *not* to get initial testing of questionable changes
<pitti> i. e. if changes are questionable they are not eligible for SRU in the first place
<superm1> its not initial testing though
<pitti> as I said, if I get confirmation from the (former) MOTU SRU team that this is wanted, I'm ok with it
<pitti> but I am not going to take responsibility for this
<superm1> i would be glad to be responsible for this
<superm1> should there be any problem
<dholbach> doko_, doko__, pitti, server guys (soren, keescook), calc, asac: please check out your bugs on http://people.ubuntu.com/~dholbach/sponsoring/
<pitti> ack (tab is already open, but EOVERLOADED yet)
 * dholbach hugs overloaded pitti
 * Hobbsee runs alt+f4 on pitti's firefox window.
<pitti> Hobbsee: no use, it restores my tabs when I restart it :)
<Hobbsee> darn.
<Hobbsee> rm -rf ~/.mozilla
<Keybuk> well, blow me!  resume from hibernate actually almost works
<jdong> O_O
<jdong> Keybuk: only after you fix it on *my* systems :)
<Keybuk> cool
<pitti> ArneGoetje: are you fine with taking the ttf-arphic-uming merge from me?
<Keybuk> not only did u6y crash on attempted install
<Keybuk> but now apport crashes every time I click the "it crashed" icon
<Keybuk> pitti: do you want the raw .crash files?
<pitti> Keybuk: about the apport crash, yes (please create an apport bug and attach it there)
<\sh> moins
<pitti> Keybuk: some problem with python?
<Keybuk> pitti: is there an easy way to turn a .crash file on a bug report into the usual apportish files
<Keybuk> pitti: shlex.split => module has no attribute split
<pitti> Keybuk: the easy way is to double-click on it
<pitti> Keybuk: but if apport itself isn't able to run, there's little point
<pitti> Keybuk: you can try the CLI: apport-cli -c /var/crash/foo.crash
<pitti> Keybuk: once the .crash attachment is on a bug report, there is no easier way than downloading, unpacking, attaching them one by one
<pitti> (we could write a script for that if it's a common case)
<Keybuk> same error from apport-cli for both
<pitti> (shlex??)
<lifeless> Keybuk: is your python half-configured ?
<Keybuk> lifeless: this is a Live CD
<Keybuk> I would hope not
<lifeless> shlex.split is pretty standard
<lifeless> to get module has no attribute is borked
<lifeless> possibly its not the global shlex but a separate shlex module - local scope
<lifeless> or a variable called shlex that isn't shlex.
<ArneGoetje> pitti: yep
<ArneGoetje> pitti: I'm going to package a new version anyways
<Keybuk> lifeless: I get it from:
<Keybuk> >>> import shlex
<Keybuk> >>> shlex.split("foo")
<\sh> pitti, if there is a version of a package in -proposed, which version I should use to apply sec-fixes?
<lifeless> Keybuk: if that breaks your python is fuxored
<Keybuk> hmm
<Keybuk> attempting to cat that file gives me an I/O error
<pitti> \sh: if the bug looks trivially verifiable, it'd be better to get it verified and do the security changes on top of it
<lifeless> Keybuk: interesting that it doesn't raise ImportError
<pitti> \sh: but the default is to apply them to the -updates version and re-do the SRU
<\sh> pitti, ok...so I add one fix to the -proposed package and one to the -updates or -security package
<pitti> \sh: that works, too (just more work for you)
<\sh> pitti, well, let's get rid of all those nasty openldap cves ,-)
<pitti> yay
<\sh> pitti, which is really a pain in our a*s :( especially dapper fixes
<dholbach> heya Tonio_
<Tonio_> hi dholbach, how are you ?
<DktrKranz> pitti, could you please have a look at bug 78017 to see if versioning is correct?
<ubotu> Launchpad bug 78017 in firehol "[SRU] firehol locks down Feisty & Gusty systems" [Medium,Confirmed] https://launchpad.net/bugs/78017
 * pitti blames dholbach for not having any background image any more
 * Hobbsee blames pitti for the world in general.
<pitti> dholbach: oh, actually that's just because ubuntu-gdm-themes is in NEW, doing
<LaserJock> Hobbsee: ouch
<Hobbsee> LaserJock: PONIES!!!
 * Hobbsee blames LaserJock for the lack of ponies.
<LaserJock> Hobbsee: sorry, rewritting my data analysis program at midnight for a 10am meeting :/
<Hobbsee> LaserJock: ouch.
<LaserJock> somehow when I say I'm doing a 10 point average of 18000 data points I'm guessing I shouldn't end up with 2000
<Keybuk> curious, a detect-cd-for-defects worked just fine
<pitti> DktrKranz: looks fine
<DktrKranz> pitti: thanks. Will upload them later.
<dholbach> pitti: thanks
<dholbach> Tonio_: thanks - I'm doing OK - how are YOU?
<Keybuk> hmm
<Keybuk> ok, that's kinda annoying
<Keybuk> it decided to I/O Error this time after having formatted the disk
<Keybuk> so I now have to do the very strange thing of burning a new CD image from the Live CD
<Tonio_> dholbach: super ! france is on stricke for a week, so I can't go to work :/
 * dholbach hugs Tonio_
<LaserJock> Tonio_: the whole country?
<Tonio_> LaserJock: well the national train company is, and since I need the train to go to work, I'm locked at home
<Tonio_> dholbach: thanks, support is nice today ! :)
<LaserJock> Tonio_: I see
<\sh> Tonio_, just like people in germany last week ;)
<Tonio_> \sh: yeah, I saw that on tv
<Tonio_> \sh: that reminded me of france as it is every 6 month :)
<Tonio_> \sh: the difference is maybe the frenquency, does that happen that often in germany ?
<\sh> Tonio_, well, now you have time to hack on ubuntu more then ever ;) so it's a good thing, too ;)
<\sh> Tonio_, nope...this is the really first big one, but most of the time only in the east of the country because the union has more members in the east of germany...
<Tonio_> \sh: makes sense
<Tonio_> \sh: but yeah, that gives me time for ubuntu, which is a good thing on the other hand ;)
<\sh> hmm...openldap2.3 in feisty and gutsy, openldap2, and openldap2.2 in dapper and edgy...this is evil...and all are vulnerable to the same bugs...
<Keybuk> err
<Keybuk> *blink*
<Keybuk> that's weird
<Keybuk> ubiquity just *vanished*
<Keybuk> no error, no crash, etc.
<Nafallo> Keybuk: it's a ghost.
<cjwatson> Keybuk: syslog etc.?
<cjwatson> (yes, that's weird)
<cjwatson> not that I actually feel like debugging ubiquity at this time in the morning ...
<Hobbsee> but...do you ever feel like it now?
<Hobbsee> ;)
<cjwatson> Hobbsee: not enormously :)
<Keybuk> cjwatson: I'm having a repeated run of dodgy CDs
<Hobbsee> cjwatson: 'xactly.  :D
<Keybuk> cjwatson: I wouldn't mind so much, except the CD seems to magically obtain the defects only *after* it's wiped the drive
<Keybuk> cjwatson: ...
<Keybuk> I'm starting to suspect squashfs problems
<seb128> pitti: can you give a build retry to nautilus-cd-burner?
<TheMuso> If a package's build process generates .la files that have the wrong location for a library dependency listed in the dependency_libs field, whats the best approach? I know of cdbs's clean-la.mk rule, but since the package doesn't use cdbs, should I add that code to the rules file manually, or should I attempt to fix the package's build system somehow?
<TheMuso> This is causing headaches for a package I am working on that depends on the package with the incorrect .la files.
<azeem> I thought .la files were obsolete
<azeem> TheMuso: does that package ship a .pc?
 * Keybuk is totally having a bad install experience :-/
<Keybuk> GRUB now gives me "File not found" on every single option it made
<TheMuso> azeem: Let me look.
<azeem> TheMuso: if so, I'd say don't ship the .la
<Keybuk> it appears the drives have all danced around
<cjwatson> Keybuk: fancy writing the libx86 code to figure out drive numbering from EDD? :-)
<cjwatson> sounds like you have a prime use case right there
<Keybuk> cjwatson: I would have no idea where to start :-/
<mvo> cjwatson: I looked into that long while ago and there is a kernel option that looked like the only sensible option
<mvo> (unless I'm confusing issues here)
<TheMuso> azeem: No .pc file.
<cjwatson> mvo: the kernel option breaks some systems
<cjwatson> mvo: mjg59 told me at UDS that the same thing can be done from userspace with libx86, which would give us the opportunity to blacklist those systems
<azeem> TheMuso: OK, you might have to live with fixing the .la files then, I'm not sure what the current policy on that is
<Keybuk> it's a single SATA controller with three ports
<Keybuk> GRUB sees them as the BIOS does (1,2,3,[4])
<cjwatson> when doing it in the kernel, seems we just don't have room to get it entirely right
<Keybuk> Linux sees them as (3,1,2)
<TheMuso> azeem: Yeah, this is why I asked. This problem has come about since an upload was made for libgcrypt11 which uses the clean-la.mk rule from Ubuntu's cdbs package, and the .la file was also moved from /lib to /usr/lib
<cjwatson> Keybuk: right, the issue is entirely familiar
<mvo> cjwatson: I tried doing userspace magic in a similar fashion as vbetool does it and got nothing useful from the x86 edd interrupt. but then, I digged not too deep into that
<cjwatson> mvo: haven't tried it myself, all I have is mjg59's word that it's possible :)
<cjwatson> pitti: I have a couple of questions about the prefetch spec
 * mvo nods
<cjwatson> pitti: firstly, is the ext3 disk reordering tool required to get the cited speedups? The README in the source says "BEWARE!!! e2remapblocks is in experimental state and can destroy your filesystem. Backup if you value your data!" which sort of puts me off including it in hardy
<Keybuk> cjwatson: required: no
<Keybuk> it gives you a little extra speed-up
<cjwatson> I would suggest not including that in the spec, unless the upstream confidence level increases and we audit it very carefully
<cjwatson> secondly, the spec says "Cannot optimize the live system startup time (no solution provides that so far)." Is this talking about squashfs sorting?
<cjwatson> seems that we ought to be able to generate a squashfs sort list based on a dynamic profile from prefetch
<cjwatson> it wouldn't be perfect (unless we took some extra time in the release process to make it so), but it probably doesn't need to be - even a slightly dated sort list would probably be better than none at all
<mvo> Keybuk: I put some background info into https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/8497/comments/10 (and 11)
<ubotu> Launchpad bug 8497 in grub "grub guessed BIOS disk order incorrectly" [Medium,Confirmed]
<seb128> Lutin: around?
<Lutin> seb128: yep
<seb128> Lutin: did you read my comment on saturday about checkinstall?
<Lutin> seb128: yes. the checkinstall maintainer sent a mail just befor I started mine
<seb128> sent a mail where?
<Lutin> to me
<seb128> I did comment on IRC ;-)
<seb128> ah, to say what?
<Lutin> that he thought the changes were not really needed
<seb128> Lutin: well in any case could you send such changes back to Debian?
<Lutin> seb128: will do
<seb128> thanks
<Lutin> np
<seb128> sending change back means we can sync the packages then which is better for debian and ubuntu
<Lutin> yep. but doesn't MoM mail the changes back to debian ?
<cjwatson> Lutin: it's not the same
<seb128> that's not a replacement for sending back changes
<cjwatson> it's always better to send a proper bug report
<cjwatson> Debian maintainers don't necessarily subscribe to the derivatives keyword in the PTS anyway
<seb128> it makes easier for the Debian maintainer to look at what ubuntu is changing
<Lutin> agreed
<\sh> keescook, jdstrand : bug #163740 and bug #162162 ready for review
<ubotu> Launchpad bug 163740 in openldap2.2 "[CVE-2007-5707] OpenLDAP before 2.3.39 allows remote attackers to cause a denial of service (slapd crash)" [Undecided,In progress] https://launchpad.net/bugs/163740
<ubotu> Launchpad bug 162162 in openldap2.3 "[CVE-2007-5708] openldap 2.3" [Undecided,New] https://launchpad.net/bugs/162162
<pitti> seb128: done
<seb128> pitti: danke
<pitti> cjwatson: sorry, I have to admit that I don't know anything about the prefetch; Scott just asked me to take notes and write the spec; theoretically prefetch's automatically generated profile should apply to the squashfs too, but I don't know whether prefetch supports this with tools
<Keybuk> cjwatson: to be honest, I can't answer any of your questions until I've played with it
<Keybuk> that's the problem with the spec
<Keybuk> it was written with only the docs to refer to
<Keybuk> none of us have actually tried it yet
<cjwatson> Keybuk: makes it hard to approve :)
<cjwatson> mjg59: is there a librarified version of x86emu?
<cjwatson> mjg59: libx86 seems to just have the LRMI stuff
<Keybuk> cjwatson: the spec should be "try this stuff and see what happens" :)
<pitti> also, the squashfs question is not a regression; AFAIK we don't consider the readahead data for building the squashfs ATM either, or do we?
<cjwatson> we don't, although I thought that readahead ran on the live CD too (even though the filesystem isn't sorted)
<Keybuk> no
<Keybuk> squashfs+unionfs data is randomly scattered across the disk from readahead's point of view
<Keybuk> running readahead would be massively sub-optimial
<cjwatson> oh, of course, we do disable it in casper
<cjwatson> sorry, I keep forgetting that
<cjwatson> pitti: it's not a regression, but it's mentioned in the spec so I thought it perhaps worth addressing, since I see this as a gap in our current process
<Keybuk> cjwatson: 1. Crawl.  2. Walk.  3. Jump.  4. Fly.  5. PROFIT.
<cjwatson> Keybuk: of course, but if it's easy to get from walk to jump I see no reason to carry on walking
<cjwatson> which is why I *asked the question* ;-)
<cjwatson> if it's hard, that's fine (although it would still be worth sketching out our current ideas for the benefit of future generations)
<Keybuk> I mean that I can't answer whether it's hard or not
<Keybuk> because we don't know how this stuff works
<Keybuk> we may be able to get a list of files
<Keybuk> we may not
<Keybuk> at the moment, prefetch is just magic pixie dust
<Keybuk> mvo: random question of the day ... in this new apt-tracks-autoremoves world order ... how do I find the list of packages I actually installed myself?
<mvo> Keybuk: synaptic provides a filter to show all the packages that are automatically installed, but the inverse is currently not trivial to get. I can give you a small python-apt script that does it if you want
<Keybuk> hmm
<Keybuk> for PKG in $(dpkg-query -Wf '${Package}\n'); do {sed -n -e "/^Package: $PKG$/,/^$/p" /var/lib/apt/extended_states | grep -q "Auto-Installed: 1"} || echo $PKG; done
<Keybuk> i tried that
<Keybuk> that returns a huge number of packages
<seb128> jdong: could you update backport task titles to mention the version?
<seb128> jdong: bug #144682 is confusing, title mention to backport the gutsy version, one comment mention the hardy one, which one is the correct one?
<ubotu> Launchpad bug 144682 in feisty-backports "Please backport pingus from Gutsy" [Undecided,In progress] https://launchpad.net/bugs/144682
<mvo> Keybuk: http://paste.ubuntu.com/2084/ <- should work. I need to add a status for this into synaptic I guess
<mvo> Keybuk: or something into apt-cache maybe ...
<\sh> keescook, jdstrand: bug #132915 ready for review (don't be surprised, edgy has 14 cves fixed) ,-)
<ubotu> Launchpad bug 132915 in wireshark "WireShark versions prior to 0.99.6 vulnerability" [High,In progress] https://launchpad.net/bugs/132915
<\sh> keescook, jdstrand : and please let's find a solution for dapper...the 0.99.0 version is very vulnerable...but we can only work properly on 0.99.2 (ethereal -> wireshark name merge not only in the name, but as well in many sourcefiles and libs)
<pitti> jdong: ooh, congrats to becoming a MOTU! *hug*
<rgl> hi
<rgl> hi
<rgl> you guys known what package creates /usr/lib/ssl/certs/ssl-cert-snakeoil.pem (or at /etc/ssl/certs/) ? (dpkg -S does now known about that file)  isn't this insecure to have it in the /etc/ssl/ hierarchy? (because when using openssl library, it checks that directory when validation peer certificates)
<cjwatson> rgl: files in /etc/ssl/ aren't world-writable, so why would that be insecure?
<cjwatson> anyway, to answer your question, it's ssl-cert
<rgl> cjwatson, Its somewhat secure iif the snakeoil certificate is generated while installing the package. if that cert if hardcoded in the package its trouble waiting to happen.
<rgl> cjwatson, when you use the openssl library, normally you set it up to verify the peer certificate, actually to verify the peer certificate chain, while doing that verification, it can also grab that snake oil, which is not good, because everyone has that certificate private key.
<fabbione> rgl: the certificate is different on each install
<fabbione> problem solved
<rgl> thats what I wanted to know :-D
<rgl> and its not solved per se... because now there are many pre-made images (eg for amazon-ec2) which is a problem.
<fabbione> it's generated at package install.. and given the nature of snakeoil you shouldn't be using it..
<rgl> fabbione, its not the issue *I* using it, its the issue someone else is using it!
<rgl> fabbione, if that happens, I can be using some site, while its not true.
<rgl> (because I trust the snake oil cert without knowing)
<fabbione> rgl: no you don't trust the snakeoil.. it's not imported anywhere
<fabbione> at least ssl-cert does NOT import it anywhere
<rgl> fabbione, you were not listening :-D
<fabbione> rgl: ok.. whatever..
<rgl> when you use the openssl library, normally you set it up to verify the peer certificate, which picks certificates from where the snake oil is.
<rgl> see the (possible) problem now?
<fabbione> rgl: do you have a PoC for this problem? I don't recall openssl scanning /etc/ssl but behaviour might have changed
<pochu> siretart: when introducing the passphrase for the encrypted hd in usplash, if I hit backspace it enters a new char, instead of removing the last one. Where should I file that, cryptsetup? usplash?
<siretart> pochu: usplash
<rgl> fabbione, I'm using openssl, and I can strace it picking up the certs there.
<pitti> lool: are you going to upload your libgnome merge soon?
<fabbione> rgl: what application?
<rgl> fabbione, I PoC would be "hard" because I don't known how to fool the DNS servers.
<siretart> one could argues if backspace should be a valid character in passwords, though ;)
<fabbione> rgl: you can still test local.. there is no need to go that far
<pochu> siretart: thanks
<lool> pitti: I can't upload...
<lool> pitti: to main
<lool> pitti: It's up for sponsoring at https://wiki.ubuntu.com/DesktopTeam/WeeklyTODO
<pitti> Keybuk: any idea why http://merges.ubuntu.com/d/diffutils is 404?
<fabbione> rgl: anyway best thing to do is to file a bug in LP and mark it as security. somebody from the security team will review it.
<pitti> lool: ah, ok; but there's nothing wrong with it in principle, so I can ignore it on my merges list, right?
<rgl> fabbione, ok.  I can generate a certificate signed by the snake oil that will be trued by my app (well, actually its just a little ruby script that does a http get)
<lool> pitti: Upload it if you agree with the merges and forget about it :)
<seb128> pitti: you are welcome to sponsor the libgnome update, it's on the DesktopTeamTODO
<pitti> seb128: ok
<rgl> fabbione, what is LP?
<pitti> seb128: btw, I took a look at current pulseaudio
<fabbione> rgl: please add everything you do and how you do it, in the bug
<seb128> pitti: ah, does it look good?
<fabbione> rgl: launchpad.net...
<fabbione> rgl: file a bug there for ssl-cert / openssl
<rgl> ah ok.  didn't associate LP with LP :D
<pitti> seb128: it still breaks with multiple users since both instances want to create /tmp/.esd/socket
<fabbione> rgl: make sure you explain everything bit by bit including your test case or PoC on how to fool the system
<seb128> weird, I though the fedora guys said they fixed that
<pitti> seb128: seems we need to teach it about our per-user esd socket patch that we did ages ago in esound
<rgl> fabbione, ok.  thx.
<fabbione> rgl: etc. etc. etc. and mark it as security.
<fabbione> np
<pitti> seb128: and Lennart even asked me about that patch
<tkamppeter> pitti, hi
<pitti> hi tkamppeter, how are you?
<Keybuk> pitti: why shouldn't it be?
<pitti> Keybuk: well, main.html references it, and we do have a delta
<pitti> Keybuk: oh, wait, it's probably just confused; we actually have a newer version than Debian
<pitti> -unstable
<Keybuk> hmm
<pitti> Keybuk: it seems it looked at the available version in experimental
<tkamppeter> fine, I was not here for longer time, as in the last weeks I had an OpenPrinting Meeting in Tokyo and the LSB Meeting mear Salt Lake City.
<Keybuk> that is odd
<Keybuk> DEBUG:root:diffutils: ubuntu is 2.8.1-12ubuntu1
<Keybuk> DEBUG:root:diffutils: debian is 2.8.1-12
<Keybuk> DEBUG:root:diffutils: base is 2.8.1-12 (2.8.1-12 wanted)
<pitti> Keybuk: main.html says that 2.8.7.0-0.2 was current in Debian, but that's experimental
<Keybuk> will look into that shortly
<pitti> Keybuk: I just wondered; I'll just ignore it for nwo
<pitti> now
<pitti> Keybuk: same for refblas3, FYI
<Fujitsu> Keybuk: I saw that on another couple of packages a week or so ago, but forget exactly which.
<cjwatson> rgl: it's not the same private key for every install, so I don't really see the problem here
<tkamppeter> My current problem is the following: I have put an SRU into bug 149511 and it seems that no one has done anything.
<ubotu> Launchpad bug 149511 in ubuntu-meta "[Gutsy] hplip is not installed by default" [Medium,Fix released] https://launchpad.net/bugs/149511
<cjwatson> and the key isn't world-readable, even if you happen to be on the same box
<rgl> cjwatson, you are right.  but its the same if/when you image the server around.
<rgl> cjwatson, I mean, when you use a pre-generated image (for amazon ec2, or services alike it).
<tkamppeter> pitti, have you seen the SRU in bug 149511
<ubotu> Launchpad bug 149511 in ubuntu-meta "[Gutsy] hplip is not installed by default" [Medium,Fix released] https://launchpad.net/bugs/149511
<cjwatson> rgl: I think that's a flaw in the imaging
<cjwatson> rather than in ssl-cert
<cjwatson> (by the same token, ubiquity probably ought to dpkg-reconfigure ssl-cert)
<cjwatson> the same goes for popularity-contest
<rgl> cjwatson, yes, I agree with you.  my initial question was if it was auto-generated :-)
<pitti> tkamppeter: no, I didn't; I approved the gutsy task
<pitti> tkamppeter: I don't think it is grave enough for an SRU, since it has a trivial workaround (just install the package)
<pitti> tkamppeter: and it does not affect the default installation either
<pitti> only people who manually removed hplip
<pitti> it's a safe fix, but it's outside of the purpose of SRUs IMHO
<pitti> tkamppeter: btw, are you aware of your assigned merges on http://merges.ubuntu.com/main.html ? (probably yes, but just checking)
<pitti> tkamppeter: hopefully a lot of them will turn into syncs
<pitti> Keybuk: it looks as if the MoM problem is just that it looks at experimental versions
<tkamppeter> pitti, I see now, you have done some updates of printing-related packages in Debian where the original Debian folks seem to have disappeared.
<pitti> tkamppeter: only for cupsys
<pitti> hm, latest hardy updates seem to have broken gnome-keyring; do others get this as well?
<Keybuk> pitti: err
<Keybuk> it's not 404 now
<pitti> Keybuk: indeed; seems it actually generated the merge now
<pitti> Keybuk: still, I don't think we should pull from experimental, at least not with very big markers
<pitti> s/with/without/
<Keybuk> it'll use experimental packages as base if it can
<Keybuk> it always has
<tkamppeter> pitti, That my new simplified Ubuntu version of HPLIP got synced into Debian Jeff Licquia has shown to me as he met me on the LSB Meeting in Salt Lake City. He is the leader of the LSB project.
<Keybuk> in theory, you'd only ever see it when Ubuntu actually bases off experimental
<tkamppeter> Pitti, and why do you appear as uploader for gutenprint and hplip on http://merges.ubuntu.com/main.html? Is it because you uploaded the last version of the package into the Ubuntu build server (not into Debian)?
<tkamppeter> And the name of the person at the top of the entry is the one who created the last Ubuntu package?
<pitti> tkamppeter: right, because I sponsored the upload
<pitti> tkamppeter: the large name on top is you (the one in teh changelog), and the small name below is the person who gpg-signed the upload
<tkamppeter> pitti, WDYT about Rick Richardson's (foo2zjs author) comment at the end of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413225?
<ubotu> Debian bug 413225 in hplip "new upstream release" [Wishlist,Fixed]
<tkamppeter> pitti, in my opinion HPLIP is still free software, as it does not contain anything non-free. And users get warned before the download of the non-free component starts.
<pitti> tkamppeter: so the 'automatically' is incorrect? how does that download look like?
<zul> mornin
<scaryAardvark> it's afternoon here in the uk.
<tkamppeter> pitti, it is a printer setup wizard. If one of HP's Cheapo lasers is connected (needs firmware files and also a driver component with JBIG compression) a window pops up telling that the printer needs non-free components and when the user agrees the download will happen.
<emgent> heya
<pitti> tkamppeter: hm, that seems reasonable for me
<tkamppeter> Such things will soon happen more often in distros, due to my work on auto-downloadable driver packages at OpenPrinting ...
<pitti> warp10: did you get my reply in /msg?
<warp10> pitti: mmm... no!
<tkamppeter> In Tokyo I met many manufacturers and they want to make driver packages. See https://www.linux-foundation.org/en/OpenPrinting/LFJapanSymposiumTokyo2007
<pitti> dholbach: I'd like to join ubuntu-main-sponsors, so that I can actually unsub the team from bugs which shouldn't appear on the list; can you please ack my subscription?
<dholbach> pitti: done
 * pitti hugs dholbach, thanks
 * dholbach hugs pitti back - no problem
<cjwatson> wow. apparently one of our city councillors has (co-)written a book on learning Python for kids
<zul> sweet
<exodos> I've got "dpkg-shlibdeps: warning: could not find any packages for libfreetype.so.6" while building one package using pbuilder. Is the any easy way to fix it? (specify that this file is in package xxx)
<Keybuk> *sigh*
<ogra> Keybuk, ?
<Keybuk> the basic problem with dog ownership is that you spend time and money choosing delicious tins of food to put in one end ... and then more time picking it up when it comes out the other
<ogra> (nice flight report :) )
<ogra> lol
<ogra> mov to the countryside ;)
<ogra> *move
<Keybuk> ogra: you still have to pick it up!
<ogra> in the woods ? caome on
<\sh> Keybuk, depends on the area...,-)
<ogra> *come
<pitti> Keybuk: please commit your recent usplash changes to the bzr
 * pitti will wait with his upload for that
<Keybuk> pitti: ?
<pitti> Keybuk: you uploaded 0.5.8, but it's not in bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/
<Keybuk> pitti: usplash has no x-vcs-bzr :)
<pitti> but it has
<pitti> and apt-get source whines
<Keybuk> weird
<Keybuk> apt never whined at me
<Keybuk> apt-get source gives me an unpacked copy
<pitti> weird
<pitti> $ apt-cache showsrc usplash|grep Bzr
<pitti> Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu
<ogra> NOTICE: 'usplash' packaging is maintained in the 'Bzr' version control system at:
<ogra> http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu
<ogra> Please use:
<ogra> bzr get http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu
<pitti> Keybuk: that doesn't work for you?
<ogra> thats what i get in gutsy
<Keybuk> pitti: yup, that works
<Keybuk> wing-commander scott% apt-get source usplash
<Keybuk> dpkg-source: extracting usplash in usplash-0.5.8
<Keybuk> dpkg-source: unpacking usplash_0.5.8.tar.gz
<Keybuk> wing-commander scott%
<Keybuk> ogra: that's all I see
<ogra> thats really weird
<cjwatson> maybe it doesn't handle lack of x-?
<ogra> well, mine is the gutsy version (0.5.7)
<ogra> packaging regression ?
<pitti> cjwatson: how do you mean?
<StevenK> pitti: As in X-Vcs-Bzr
<pitti> debian/control has Xs-Vcs-Bzr
<pitti> (in hardy that's not supposed to be necessary any more, but it still works)
<pitti> StevenK: and at least for ogra and me it is in the source package record
<pitti> and apparently for Keybuk, too
<ogra> gutsy has XS-Vcs-Bzr
<seb128> pitti: it's not necessary?
<pitti> so that's more like an apt bug (/me hugs mvo)
<ogra> does it cate about case ?
<StevenK> It whines for me, too.
<ogra> *care
<pitti> seb128: Debian is dropping the XS-Vcs-* stuff
 * mvo awakes and looks around?
<pitti> ogra: right, XS- is correct (no idea about case sensitivity)
<pitti> mvo: apt-get source usplash doesn't warn Keybuk about the bzr, but it does for ogra and me
<ogra> i'm on gutsy though
 * pitti is on hardy
<Keybuk> gutsy
<seb128> works for me on hardy
<pitti> same apt, though
<Keybuk> (with hardy in sources list, but not brave enough to upgrade yet)
<Hobbsee> Keybuk: wuss :P
<pitti> but it works fi#($*#bzzzzzt *poff*
<Keybuk> pitti: usplash committed anyway
<pitti> Keybuk: thanks a lot
<pitti> Keybuk: btw, that change looks really strange at boot
 * pitti prefered the old non-bouncing bar, but that's just me maybe
<Keybuk> blame mdz
<Keybuk> he DEMANDED it
<pitti> I now have a wildly pulsating bar while it waits for my password
<cjwatson> pitti: it's just Vcs-Bzr now in many packages
<pitti> which is very misleading
<mvo> pitti: strange warns me too
<pitti> cjwatson: right, Debian officially blessed them now
<Keybuk> cjwatson: except our dpkg doesn't recognise that
<cjwatson> Keybuk: merging dpkg seems like something we should be doing ;-)
<Keybuk> cjwatson: well volunteered :)
<mwolson> cjwatson: i was wondering if i could have you backport emacs 22.1-0ubuntu7 from hardy to feisty-backports for me
<mdz> Keybuk: that is an exaggeration on your part
<mdz> pitti: perhaps the crypto bits should change it; it is a great improvement for the common case
<Keybuk> mdz: you said "Please see that this gets done" :-)
<Keybuk> I consider that demand-level <g>
<pitti> mdz: agreed
<pitti> mwolson: please file a backport request bug, it'll get done through the regular archive days then
<pitti> (since it needs to be ack'ed by the backports team first)
<mwolson> pitti: OK, i'll file a separate bug for it.  this is related to the security fix that just went into the emacs22 package for gutsy
<mwolson> pitti: do updates to already backported packages count as "backport requests", or should i treat it as a "sync request"?
<pitti> mwolson: no, it remains a backport request
<mwolson> alright
<mwolson> ah good, i see that Launchpad now warns bug submitters when they submit a security-related bug about privacy.  that bit me a few weeks ago.
<mwolson> there.  filed as Bug #163813
<ubotu> Launchpad bug 163813 in feisty-backports "Please backport emacs22 22.1-0ubuntu7 from hardy" [Undecided,New] https://launchpad.net/bugs/163813
<tkamppeter> pitti, it is about bug 152293. Is my "sleep 3" stuff not in the Hardy version of the package?
<ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Confirmed] https://launchpad.net/bugs/152293
<lool> bryce: Around?  It seems on a fresh install of xserver-xorg, it will create a dummy /etc/X11/X symlink pointing to /bin/true, but when installing xserver-xorg-core it doesn't update the link for some reason
<lool> bryce: bug #163806
<ubotu> Launchpad bug 163806 in xorg-server "X doesn't start on Samsung Q1 Ultra" [Undecided,New] https://launchpad.net/bugs/163806
<tjaalton> lool: I think it's fixed in debian
<tjaalton> although I don't understand why it would link to /bin/true
<lool> tjaalton: It's the default
<lool> tjaalton: Do you think it could be the hang in #451439 and dups?
<lool> (Debian 451439)
<ubotu> Debian bug 451439 in xserver-xorg "postinst script hangs when installing on new system" [Normal,Fixed] http://bugs.debian.org/451439
<tjaalton> yes
<tjaalton> I'll merge with 7.3+6
<tjaalton> oh wait
<tjaalton> THIS_SERVER is /usr/bin/Xorg by default
<lool> Only in xserver-xorg, but in x11-common -- which is installed first I think -- it will be set to /bin/true by default
<lool> tjaalton: Hmm seems it's in xserver-xorg.preinst on my laptop: UNCONFIGURED_LINK_TARGET=$(which true)
<lool> "# if performing a fresh install" [...] ln -s "$UNCONFIGURED_LINK_TARGET" "$SERVER_SYMLINK"
<tjaalton> there is no such variable on my system :)
<tjaalton> oh preinst
<lool> Yes
<tjaalton> duh
<lool> No why is my touchscreen completely uncalibrated grmblb
<lool> +w
<soren> cjwatson: You commented on this earlier: https://bugs.edge.launchpad.net/ubuntu/+source/gfxboot/+bug/140713  Do you have any reservations about the patch or would it be ok to apply it in hardy?
<ubotu> Launchpad bug 140713 in gfxboot "Gutsy Tribe 5 (KVM GUEST) needs -no-kvm to install" [Medium,Triaged]
<\sh> grmpf
<\sh> why is that, that some -changes mails are not coming through? e.g. emacs22 22.1-0ubuntu5.1
<cjwatson> soren: no problem for gutsy; go with the upstream patch from Steffen
<cjwatson> err
<cjwatson> no problem for HARDY
<soren> cjwatson: Will do. Thanks.
<pitti> ugh, interweb tube broken
<Keybuk> mvo: hmm, when everyone said "whine" I assumed that apt-get source actually stops if it's in bzr
<Keybuk> usplash is maintained in Bzr repository blah blah blah
<Keybuk> do you really want to get the source package [n/Y]
<Keybuk> or something
<mvo> Keybuk: it used to do that, but it got disabled again because there was too much complain
<pitti> but only because it also complained about debian svn, right?
<mvo> I guess so, we should probably enable it again for launchpad
<Keybuk> for Ubuntu, that seems like the right default
 * mvo nods
<Keybuk> tbh, even if it's Debian SVN, that tells you that you can get an LP import of it
<Keybuk> and thus make it easier to pull from debian
<warp10> pitti: Bug #163822
<ubotu> Launchpad bug 163822 in xtokkaetama "Please sync xtokkaetama 1.0b-10  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/163822
<pitti> warp10: how did you check this?
<pitti> warp10: pbuilder, or building on a system which does not have makedepend installed?
<cjwatson> Keybuk: as a point of interest, there's now a debcheckout script in devscripts, which fetches source from the Vcs-* headers
<warp10> Pitti: I used pbuilder
<pitti> warp10: thanks
<cjwatson> it has a switch to munge the URL in such a way as to give you an authenticated checkout, which is pretty handy
<cjwatson> I sent them a patch to do the same for Launchpad
<Keybuk> remember to use bzr+ssh not sftp ;)
<cjwatson> I did
<Keybuk> \o/
<cjwatson> $url =~ s[^\w+://(?:bazaar|code)(\.launchpad\.net/.*)][bzr+ssh://${user}bazaar$1];
<pitti> warp10: great; I updated the bug :)
<Keybuk> ${user}@, shirley?
<cjwatson> already handled in context you can't see there
<Keybuk> ah
<warp10> pitti: wow! My first sync has gone! :D
<DktrKranz> pitti, bug 103479 only requires Feisty SRU, but Gutsy has the same version and does not require love. Should I apply a similar fix to Gutsy (unneeded, but safe) or preparing a "no-change SRU"?
<ubotu> Launchpad bug 103479 in libfilesys-df-perl "[can-not-install] file overwrite error" [Medium,In progress] https://launchpad.net/bugs/103479
<pitti> DktrKranz: why do you need an SRU for gutsy at all then?
<DktrKranz> pitti: because Feisty would have 0.92-2ubuntu0.1, which is greater than 0.92-2 in Gutsy.
<pitti> DktrKranz: then you just need to make sure that the package will work in gutsy, too
<gaspa> pitti: about usplash. do you have a moment?
<DktrKranz> pitti: I'll check. Thanks for the advice.
<pitti> gaspa: sure
<gaspa> DktrKranz: sorry :)
<seb128> hey gaspa
<gaspa> pitti: i launch it without '&' and i got a strange:
<gaspa> usplash: can't get console font: No space left on device
<gaspa> I guess that's the problem, because I'm not able to use also TEXT command.
<gaspa> seb128: hi! :D
<seb128> gaspa: did you get my mail about bug tagging?
<gaspa> seb128: yes.
<gaspa> seb128: it seems reasonable to me. although the wiki page seem a little bit "polemic;"...
<gaspa> pitti: could you take a look and see if that's your behavior too?
<pitti> geser: well, 'No space left on device'.. is that actually true, or a bogus error code?
<pitti> erm, gaspa^
<pitti> geser: sorry
<gaspa> pitti: bogus one.
<gaspa> it's not true.
<pitti> gaspa: if I start usplash in the foreground, it doesn't return, and if I switch consoles I kill usplash, so starting it in the background is kinda necessary
<pitti> gaspa: I don't get it
<gaspa> so I have another problem... uff.. :(
<pitti> brb
<seb128> gaspa: why polemic? that has been discussed with Debian guys I think
 * pitti hugs his returned internet tube
<pitti> gaspa: ah, you uploaded them to a PPA, I see
<gaspa> yes.
<cjwatson> "No space left on device" can mean "font doesn't fit in provided buffer" in this case - it's not necessarily "disk full"
<cjwatson> look at linux/drivers/char/vt.c:con_font_get(), which has a number of ENOSPC returns
<lool> Hmm unionfs oopsing on me now
<cjwatson> so it's possible that usplash's font save/restore code doesn't handle double-width fonts or something
<lool> It also seems like NM in low disk space situation will happily switch from a working resolv.conf to an empty one; lovely
<gaspa> cjwatson: ok... it sounds reasonable (but I doesn't know yet how do fix it :D :D )
<gaspa> cjwatson: can I specify another font? maybe i can workaround this.
<cjwatson> gaspa: you could certainly try fiddling /etc/default/console-setup
<gaspa> cjwatson: thanks, i try.
<mathiaz> pitti: About bug 129920 - who should do the verification ?
<ubotu> Launchpad bug 129920 in apache2 "/var/lock/apache2 has wrong owner and group for webdav" [Low,Fix committed] https://launchpad.net/bugs/129920
<pitti> mathiaz: preferably sru-verification team (mvo/bdmurray/ogasawara), but feedback from the bug reporter or other users will do, too
<tjaalton> cjwatson: new xorg uploaded, now with complete changelog history :)
<pitti> mathiaz: oh, btw, if you add a "TEST CASE:" to the description, sru-verification will love you :)
<mathiaz> pitti: ok. I was confused your last message.
<mathiaz> pitti: Does this mean that I should poke QA to get the verification done ?
<pitti> mathiaz: that should do; add the test case, and subscribe sru-verification, that's enough
<ScottK> pitti: Were there any MOTUs involved in your discussion with the Tech Board about the MOTU SRU process?
 * jdong hugs pitti back, albeit a bit late :)
<pitti> mathiaz: (or, alternatively, get two other people to confirm the fix)
<pitti> ScottK: I CCed the former members of motu-sru
<ScottK> pitti: OK.  Thanks.
<jdong> seb128: noted, regarding backport versions; from now on I'll include a line of rmadison output clearly stating the origin and version with backport approval messages
<pitti> ScottK: but I still didn't hear anything back
<ScottK> pitti: We should probably make it a discussion topic at the next MOTU meeting.
<pitti> ScottK: that would be great, too
<seb128> jdong: thank you, there is quite some bugs without a version number at the moment which can lead to mistakes since the hardy version can change
<ScottK> pitti: Next meeting is Friday, November 23rd 2007, 12:00 UTC.  Would you be able to come?
<pitti> ScottK: yeah, should be fine; that's even on the fridge calendar
<ScottK> pitti: OK.  I won't be able to be there (this is a holiday week in the US), so if I can find someone to lead the discussion I'll add it to the agenda and let you know.
<pitti> ScottK: splendid; thank you!
<cjwatson> tjaalton: thanks
<pitti> seb128: bwah, the number of pending builds has actually increased by 1000 since Friday
<seb128> pitti: I ran sync-source -a today
<pitti> ah, I see
<jdong> seb128: wrt bug 157903, the problem is that feisty-backports has a backport of a previous gutsy version which is vulnerable to the said bug. The backport is not to take the place of feisty-security.
<ubotu> Launchpad bug 157903 in python-django "security vulnerabiity in django i18n system" [Undecided,In progress] https://launchpad.net/bugs/157903
<seb128> jdong: ok, that was not clear to me while reading the bug, thanks for the explanation
<jdong> seb128: yeah, sorry about that
<seb128> jdong: no problem, the hardy version changed BTW, it's now 0.96.1-1, does the request still stand?
<jdong> seb128: hold on lemme grab a copy of the new version :)
<jdong> seb128: for bug 157903, 0.96.1-1 is fine :) thanks
<ubotu> Launchpad bug 157903 in python-django "security vulnerabiity in django i18n system" [Undecided,In progress] https://launchpad.net/bugs/157903
<tkamppeter> pitti, I have uploaded a new cups-pdf to the usual place, see bug 152293. Can you upload this one? It should fix all problems of not having a PDF queue, also after initial installation.
<ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Confirmed] https://launchpad.net/bugs/152293
<pitti> tkamppeter: can you please add a new comment to that bug with the URL? then I'll get the bug mail (sorry, in meeting now, might need to defer that to tomorrow morning)
<tkamppeter> pitti, I have already added suchg a comment. You will see it if you get back to your e-mail.
<pitti> tkamppeter: ah, usual email lag then; thanks!
<tkamppeter> pitti, I think Launchpad collects changes for something like 10 minutes and joins the notifications then.
<pitti> xactly
<seb128> jdong: ok, thanks
<siretart> mdke: https://help.ubuntu.com/7.10/server/C/preparing-to-install.html talks about 'i386', 'amd64' and 'powerpc'. It seems to me that it should be s/powerpc/sparc/.
<siretart> mdke: can you fix that?
<tkamppeter> pitti, something strange happened: I was syncing HPLIP with Debian and suddenly the hplip subdirectory in http://merges.ubuntu.com/h/ disappeared. Did someone else sync it?
<tkamppeter> And now it reappeared.
<pitti> tkamppeter: no idea; but I didn't see a hplip upload, so I rather suspect MoM just updates itself
<\sh> re
<mjg59> cjwatson: libx86 will be lrmi on ia32, x86emu on amd64
<mjg59> cjwatson: (I'm still GMT-8 until the end of next week)
<cjwatson> mjg59: yeah, it turned out I misread strace - I'd forgotten that strace and vm86 have weird interactions
<cjwatson> asac: firefox-3.0 seems pretty stable, impressively
<mjg59> cjwatson: Ah, ok
<Nafallo> mjg59: you don't happen to have got xserver-xorg-video-intel to work with an external VGA, have you?
<mjg59> Nafallo: Yes
<Nafallo> mjg59: any pointers on where I should look, cause displayconfig-gtk did reset my stuff to the vesa-driver ;-)
<Nafallo> without result.
<mjg59> Don't use displayconfig. Just press the video button.
<Nafallo> aha! :-)
<Nafallo> lol. will test on work tomorrow then. cheers :-)
<LaserJock> where is seb128 proposing these tags be placed?
<LaserJock> in the patches themselves?
 * ScottK was wondering the same thing.
<zul> changelog i think
<LaserJock> oh
<LaserJock> hmm, it'd be nice to know for sure
<persia> Perhaps there'll be a spec or something
<gaspa> persia: a bird tell me that you have a "python fairly easy merge"
<persia> gaspa: Yep.  It's universe though, so come to #ubuntu-motu :)
<zul> interesting http://www.popularmechanics.com/technology/upgrade/4230945.html
<blueyed> Can somebody please approve the Gutsy SRU nomination for bug 141516?
<ubotu> Launchpad bug 141516 in gparted "Gparted crashes when refreshing devices" [Medium,Fix released] https://launchpad.net/bugs/141516
<LaserJock> seb128_: where are these tags to be placed? within the patches or in the changelog?
<seb128_> LaserJock: at the start of the patch, similar to the dpatch comments
<LaserJock> seb128: ahh, we couldn't figure it out, that's what I was thinking
<seb128> "we"?
<LaserJock> zul and ScottK and persia I think
<seb128> k, maybe I should reply on the list to clarify ;-)
<LaserJock> perhaps, some people obviously got it but it wasn't clear to me
<mdke> siretart: it's best if you file a bug on ubuntu-docs
<siretart> oh, I thought it was as simple as to just change the wiki page. ok
<mdke> siretart: it's not a wiki, it comes from the ubuntu-serverguide package. But it's quite simple to fix, just that I can't install Ubuntu on my laptop
<mdke> so I'm stuck on windows and haven't figured out a good workflow yet
<siretart> oh, I see
<mdke> siretart: someone should be able to fix it super quick, it's a small bug
<TiMiDo> hey everyone
<tkooda> could someone please try this on a gutsy box and tell me if it builds for them?:  `wget http://archive.ubuntu.com/ubuntu/pool/universe/r/runit/{runit_1.7.2-1.dsc,runit_1.7.2.orig.tar.gz,runit_1.7.2-1.diff.gz} && dpkg-source -x runit_1.7.2-1.dsc && cd runit-1.7.2 && dpkg-buildpackage`
<tkooda> ..the (unmodified) 'runit' package dosn't seem to build properly on a stock/up-to-date gutsy?
<RAOF> tkooda: Gutsy's dpkg-buildpackage doesn't have the "automatically use fakeroot" setup, does it?
#ubuntu-devel 2007-11-20
<RAOF> tkooda: Does it work if you use dpkg-buildpackage -rfakeroot?
<tkooda> nope.  `dpkg-buildpackage -rfakeroot` fails (both as user and root)
<tkooda> ..also seems kinda* odd that the package version is 1.6.0, but the sources are 1.7.2..
<tkooda> it dosn't appear to use fakeroot by default, either
<StevenK> tkooda: Which means 1.7.2-1 was automatically synced from Debian, but it doesn't build.
<RAOF> Oh, yeah.  Looks like runit's been failing to build since 1.5.1-1 :)
<tkooda> heh
<tkooda> solution?
<RAOF> At least on x86-64.  i386 may vary :)
<tkooda> i386 failing here
<jdong> RAOF: where does it fail?
<tkooda> in the check
 * jdong builds it for fun
<tkooda> Checking runsv...
<tkooda> Segmentation fault
<RAOF> Find out why it FTBFS, fix it, attach a debdiff to a bug?
<jdong> /tmp/tranny/runit-1.7.2/admin/runit-1.7.2/src/runsv.check: line 4: 18062 Segmentation fault      (core dumped) runsv
<jdong> how lovely.
<tkooda> heh
<RAOF> That'd be in make check, right?
<tkooda> google turned up some very old suggestion about omitting "-fomit-frame-pointer"?
<tkooda> raof, yes
<StevenK> So disable make check, and it'll build?
 * StevenK hides
<tkooda> heh
 * RAOF hunts
<StevenK> RAOF: For the segfault, or me? :-)
<RAOF> For *you*.
<RAOF> I'd suggest gdb for the segfault, unless their code is fragile enough that leaving the frame pointer in fixes it.
<StevenK> Which just points the finger at upstream being unable to code.
<RAOF> Actually, if their code's fragile enough that it doesn't work unless the frame pointer doesn't get removed, I'd seriously consider using something else.
<StevenK> Like upstart? :-)
<RAOF> Oh, wow.
 * RAOF actually reads package description.
<RAOF> Something called "runit" *should* be a unit testing framework :P
 * StevenK cackles
<ajmitch> nah
<ajmitch> 'run' 'it' :)
<RAOF> EPARSE
<ajmitch> apart from the fact that there are 20 other testing frameworks all ending in unit
<RAOF> And xUnit is a whole family of them.
<tkooda> any chance of getting a patch for "https://bugs.launchpad.net/ubuntu/+source/runit/+bug/74135" merged at the same time?  (inittab -> upstart)
<ubotu> Launchpad bug 74135 in runit "runsvdir does not use upstart" [Medium,Confirmed]
<ajmitch> perhaps runit should be called runstuff?
<RAOF> So why would one want to use runit?
<tkooda> I don't care if it's called bannanna-ramma, as long as the damned thing builds.  :P
<jdong> ajmitch: and run it is trademarked in the USA too ;-)
<RAOF> tkooda: You're very welcome to fix the FTBFS, apply whatever (sane) patches you like, and attach a debdiff to a bug :)
<StevenK> Why anyone would want to switch to runit from upstart is beyond me
<Keybuk> mmm, djb config files
<tkooda> RAOF, I'll try my hand at a debdiff
<tkooda> StevenK, no.  running runit from* upstart.
<tkooda> (vs inittab)
<StevenK> tkooda: I still fail to see your reason.
<RAOF> Especially since their test program segfaults.  That's not what *I* look for in my init program :)
<StevenK> Muahaha
<tkooda> not runit-as-process-1, but having upstart launch runit to run my numerous daemontools/runit service dirs.
<StevenK> tkooda: But upstart can do that itself
<tkooda> can upstart do seperate logging processes per-service like runit+svlogd?
<tkooda> upstream runit-1.7.2 builds+checks okay..  wtf is going wrong in the build process to cause the check to segfault?
<mathiaz> ScottK: you mentionned at UDS that cyrus sasl should be dropped from main, and dovecot sasl should be used instead. Why ?
<tkooda> StevenK, upstart can let me pipe the output of a service to another process (that it runs+supervises)?
<StevenK> tkooda: upstart can supervise itself, but logging I'm unsure about
<tkooda> I don't think I have the time/skill to fix the 'runit' FTBFS.. so I guess it'll just stay broken until the package maintainer get's around to it (last mod was ~1yr ago?)
<jdong> tonyyarusso: does the hardy version build?
<tonyyarusso> jdong: err, misfire?
<jdong> yes
<jdong> tkooda:
<jdong> WHOA it's the funniest thing ever
<jdong> FTBFS on everything *but* ia64 and lpia
<LaserJock> that's a bit different
<tonyyarusso> weird
<jdong> hardy's ver still segfaults
<RAOF> Reverse FTBFS :)
<ion_> :-)
<jdong> ooh let's just remove the check!
<jdong> (joking, joking)
<jdong> tkooda: you are saying make check does NOT die upstream?
<tkooda> jdong, correct.
<jdong> I don't see how that's even possible
<jdong> we aren't mangling the source at all
<jdong> unless the sources don't match up with upstream's version
<tkooda> jdong, runit_1.7.2.orig.tar.gz from packages.u.o builds+checks even.
<jdong> what??
<tkooda> (manually, not with the dpkg-source && dpkg-buildpackage)
<jdong> so start cutting things out of debian/rules one by one
<jdong> until something solves it
<tkooda> jdong, done:  http://devsec.org/tmp/runit-1.7.2.buildfix-1.diff  <-- "fixes" FTBFS in runit-1.7.2; just cheap trick of using gcc instead of diet
<ScottK> mathiaz: Since we already support dovecot for MDA, we might as well switch to use dovecot for SASL and it's that much less to deal with.
<ScottK> mathiaz: Dovecot is (I've heard) generally easier to get set up and working.
<mathiaz> ScottK: ok. Do you know if dovecot implementation is API-compatible with Cyrus implementation ?
<slangasek> does it support all the SASL methods that cyrus does?
<mathiaz> slangasek: good question. I don't know. Postfix can be built with Dovecot's Sasl implementation.
<mathiaz> slangasek: same for exim. It may prove that the dovecot implementation is robust enough.
<mathiaz> slangasek: and I've just found this page: http://wiki.dovecot.org/Authentication/Mechanisms
<slangasek> ok
<slangasek> seems to cover everything I care about :)
<jdong> tkooda: heh I don't know about the correctness of that as a fix though; probably should poke the Debian maintainer
<tkooda> heh
<tkooda> maintainer is upstream author
<jdong> yeah him too
<mathiaz> slangasek: about bug 163194 - do you plan to fix it in debian also ?
<ubotu> Launchpad bug 163194 in samba "need option to disable creation of lanman hashes" [Undecided,New] https://launchpad.net/bugs/163194
<tkooda> don't got much more time right now to nudge..  perhaps later (read: likely never??)
<lamont> and theoretically, postfix is built with dovecot support.  maybe.
 * lamont hates sasl.
<lamont> or rather, I hate not having figured it out
<jdong> tkooda: it builds correctly on debian and we are using the same sources, so I'd suspect it's a diet bug
<jdong> tkooda: or toolchain differences
<tkooda> k
<tkooda> odd.  it appears to pass the compile successfully, but just not the check.
<tkooda> (I would have expected any diet bug to rear it's head in the compile step)
<jdong> tkooda: segfaults in hardy in the same way, and we use same dietlibc in hardy as Debian where it buidls correctly
<jdong> I'm out of hunches
<tkooda> sounds like a dietlibc issue then? -wonder how that got through?
<tkooda> (or perhaps a compile flag that shouldn't be used anymore??)
<ScottK> mathiaz: I know Postfix is packaged to work for both SASL implementations.  Dunno about other users.
<slangasek> mathiaz: well, I expected that adding an option for it was something to be pushed upstream, but that's already done... as far as making the change to the default in Debian, that's a policy change that needs to be discussed with the rest of the team first
<slangasek> ScottK: in what sense is it packaged to work for both? the postfix binaries are linked against cyrus sasl...
<ScottK> slangasek: It's been a while since I looked.  I thought it supported both.  Let me look into it.
<ScottK> Postifx upstream definitely supports both (at least at compile time).
<lamont> ScottK: if we don't support both, I'd love to.  ISTR checking and finding that it would
<slangasek> so how does it support both dynamically?
<slangasek> (and why would dovecot be supported by dlopen, but cyrus by linking? :)
<lamont> postconf -a
<lamont> cyrus
<lamont> dovecot
<lamont> man postconf
<lamont>  -a     List  the available SASL server plug-in types.
<StevenK> lamont: When did -a hit postconf?
<lamont> uh...
<StevenK> lamont: It's not on my Dapper machine, which is why I ask
 * lamont goes looking
<lamont> 2.3 introduced it.
<lamont> so look at edgy and beyond.
<slangasek> ah, the difference is that dovecot uses an authentication server rather than a plugin, hmm
 * slangasek looks at this design skeptically
<lamont> slangasek: fwiw, uploading util-linux 2.13-11ubuntu1 to hardy, will upload a sync'ed bsdmainutils once panthera uploads to debian
<lamont> and yes, he's expecting it
<slangasek> ok
<lamont> Conflicts: bsdmainutils (<<6.1.9)
<lamont> and yeah, 6.1.9 is actually the current version in sid.
<lamont> so I probably screwed up
<slangasek> hrm, isn't there supposed to be a Replaces: with that too?
<lamont> bsdutils no longer delivers any binaries that it didn't in 2.12r --> nothing that bsdmainutils delivers
<lamont> ergo, no Replaces any more
<slangasek> oh
<slangasek> then why does it need to conflict either?
<lamont> to force the upgrade issue, I suppose
<lamont> should it not conflict either?
<lamont> hrm... time for this one to go home.
<slangasek> I can't see any reason it should conflict, and don't understand how a conflict would help force an upgrade
<lamont> I'll pick up the conversation when I get home... it could be that I'm being a muppet.
<lamont> and then I'll get to upload -12 to debian. :-)
<lamont> will ponder while driving
 * lamont finishes pondering, uploads -12
<Hobbsee> dear update manager, why do you insist on keeping on stealing focus?
<Hobbsee> i dont need to know that you've finished downloading packages, and are now installing them
<jdong> Hobbsee: compiz?
<Hobbsee> yes
 * jdong points your-fault finger at Amaranth ;-)
<jdong> compiz focus stealing protection is umm...... not there.
<StevenK> Compiz focus stealing protection has been stolen
<Amaranth> It breaks in metacity too
<jdong> one could say Compiz has ADD.
<StevenK> jdong: We knew that
<jdong> hmm, does /upgrade kill my connection....
<jdong> whoa I'm still alive!
<jdong> I think
<jdong> why is Samba still broken?
<lamont> ah, one more reason I won't run compiz.
<lamont> neat
<lamont> not that there was much risk of that anyway
 * Hobbsee wonders what the xorg change was
<jdong> *sigh* thanks fglrx for hardlocking on me.
<RAOF> Bwa ha!
 * RAOF points and laughs.
<jdong> :P
<slangasek> jdong: which samba where?
<jdong> slangasek: the one in the topic
<slangasek> er, ok
<jdong> we should probably take that out, right?
* slangasek changed the topic of #ubuntu-devel to: Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
<slangasek> yep
<jdong> better :)
* slangasek changed the topic of #ubuntu-devel to: Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<LaserJock> ok, for translations to be shipped does a .pot have to be included in the source package?
<minghua> LaserJock: To be shipped where?
<LaserJock> in the lang packs
<minghua> I don't quite know how Rosetta works, but I think the answer is yes.
<minghua> #launchpad is the right place to ask, I think.
<LaserJock> perhaps
<LaserJock> I'm trying to figure out the packaging
<LaserJock> my package has .po files and ships .mo files
<LaserJock> but no .pot
 * Hobbsee wnoders if you have to use the kde pot file patch
<LaserJock> Hobbsee: well, it's a Gnomish app so I wouldn't think so
<LaserJock> ;-)
<Hobbsee> i doubt it's kde specific, it's just called that
<LaserJock> hmm, I wonder where I'd find it
<Hobbsee> http://kubuntu.org/~jriddell/kubuntu_01_kdepot.diff
<Hobbsee> oh, hang on, it loosk specific
<LaserJock> yeah
<TiMiDo> wow, the launchpad is sure lacking a lot,
<LaserJock> I'm thinking I just need to something in debian/rules that generates a .pot
<minghua> LaserJock: "cd po; make <package-name>.pot" usually should give you the POT file.
<minghua> LaserJock: But it's really something should be done by upstream.
<mpt> TiMiDo, can you be more specific? :-)
<LaserJock> minghua: I wonder if I need to put that in the .diff.gz or do it at build time
<LucidFox> If a bug is in the stable Ubuntu release but fixed in the development release, can I mark it as fixed?
<Hobbsee> yes
<Hobbsee> mpt: i warn you, incidently, if you *ever* break keescook's autoreply script for launchpad, you (collectively) run the great risk of being imminently killed.
<Hobbsee> just in case you were wondering :)
<minghua> LaserJock: I don't think it makes much difference, unless you do some tricky things to the timestamps.
<mpt> Hobbsee, I have no idea what you're talking about, but I do know that's not a good way to express it
<Hobbsee> mpt: sorry.  just thinking of if there are impending UI changes.
<mpt> There are always impending UI changes. Launchpad is an active project.
<pwnguin> so uh, apparently modprobe wont load nvidia drivers if xorg.conf doesn't have it listed?
 * Hobbsee sighs at impending work
<mjg59> pwnguin: Correct
<mjg59> Otherwise non-free modules get loaded unnecessarily
<pwnguin> interesting
<pwnguin> dont you have to actually go to the trouble of installing nvidia-glx?
<pwnguin> mjg59: how then, do you load the module without modifying xorg.conf?
<mjg59> pwnguin: You don't?
<mjg59> Well, you can use insmod
<mjg59> But there's no reason to load it unless you're using the nvidia driver
<pwnguin> apparently someone wants to see if they can even build / load the driver on their g80
<mjg59> Why?
<pwnguin> because its not fully supported by nvidia-glx-new?
<mjg59> I don't understand the problem
<mjg59> If they're installing a new driver, they need to change xorg.conf to use it
<mjg59> And then the nvidia module will get autoloaded
<pwnguin> < crweb32> i just needed it to load so i can watch detection/other stuff
<pwnguin> 23:31 < crweb32> my card isn't supported fully yet
<mjg59> Then use insmod
<Seq> Is there a way to have
<Seq> Is there a way to have a linux-backports-modules style package replace certain modules (like alsa is with said package) but be included in the initrd?
<corevette> i didn't know hardy was planning ppc https://launchpad.net/ubuntu/hardy/powerpc
<Fujitsu> corevette: It has been unsupported by Canonical for a release or do, but was never entirely dropped, and likely won't be for some time.
<Fujitsu> s/do/so/
<MacSlow> Greetings everybody!
<dholbach> good morning
<tjaalton> good morning!
<tjaalton> general notice; I've changed my nick (formerly "tepsipakki")
<dholbach> hey tjaalton! :-)
<tjaalton> hey dholbach :P
<LaserRock_70s> tjaalton: oh man, just when I started remembering your nick :-)
<tjaalton> LaserRock_70s: yeah, it's been nice and quiet for the past few days :)
<pitti> Good morning
<LaserRock> pitti: heah, you're up
<LaserRock> pitti: I have a translation/lang pack question for you
<pitti> Hey Laser...'R'ock?
<LaserRock> pitti: see Planet
<LaserRock> pitti: it's all jorge's fault
<LaserRock> does the source package need to have a .pot for translations and inclusion in the lang packs to work?
<pitti> LaserRock: after the source package is fully built, there needs to be a .pot file
<pitti> ideally this is dynamically created during build, so that patches which change strings are considered
<pitti> many packages ship a static .pot which must be updated manually; that's not optimal, but works
<LaserRock> ok
<pitti> (we don't change strings too often)
<LaserRock> gcompris ships .po files but no .pot
<LaserRock> and apparently in gutsy the translations got dropped or something
<LaserRock> real mess, upstream's not happy
<pitti> ah; in the past, gcompris was special
<pitti> but I remember having touched it in hoary times to fix translations
<LaserRock> pitti: yeah, I think we (I) must have dropped your changes in a merge/sync accidentally
<LaserRock> I should be able to built the .pot in at build time in debian/rules though right?
<pitti> LaserRock: yes; how in particular, is the question
<pitti> LaserRock: does the package use intltool?
<dholbach> hey mvo
<mvo> hey dholbach!
<StevenK> Hey pitti
<LaserRock> pitti: I'm not exactly sure but I think so. there are lots of .po files in po/
 * dholbach does his daily call for attention to http://people.ubuntu.com/~dholbach/sponsoring
 * pitti hugs StevenK, good morning
<pitti> LaserRock: lemme look
<LaserRock> pitti: there's references to intltool all over the place in the makefiles, etc.
<pitti> ah, great
<pitti> LaserRock: and does the package use cdbs?
<LaserRock> pitti: no, only debhelper
<pitti> LaserRock: try calling 'intltool-update -p --verbose'
<pitti> LaserRock: usually after 'make' in debian/rules build
<LaserRock> pitti: ok, I'll give it a go
<LaserRock> pitti: would there be any possibility of doing an SRU to get translations back for gutsy?
<pitti> LaserRock: I'd prefer building the package locally with pkgbinarymangler installed and enabled and tossing the translations.tar.gz to carlos for manual import
<pitti> carlos: is that possible/reasonable?
<dholbach> seb128, StevenK, doko_, server people (keescook, soren), calc, pitti, asac, mvo: http://people.ubuntu.com/~dholbach/sponsoring/ :)
<Fujitsu> dholbach: How is the responsible person determined?
<pitti> dholbach: I fixed all but one yesterday, and that one requires some action from the bug reporter
<dholbach> pitti: ok - great
<dholbach> Fujitsu: assignee + subscribers - (people not in ~ubuntu-dev or other developer teams)
<dholbach> Fujitsu: maybe responsible is the wrong word for it, I merely want to know easily if it has the attention of an ubuntu developer
<LaserRock> I would think just assignee would be more "responsible person"
<dholbach> it's not always assignee
<seb128> dholbach: do you do stats?
<dholbach> seb128: stats as in how?
<seb128> dholbach: as how many packages are uploaded and reviewed
<pitti> hey seb128, good morning
<dholbach> it'd be nice to have that, I agree
<pitti> seb128: AFAIK, the only remaining bit of 2.20.1 in -proposed is tomboy, right?
<seb128> dholbach: I'll upload the package from bug #118589 soon and I was wondering if that should be listed on your sponsor list
<ubotu> Launchpad bug 118589 in ubuntu "[needs-packaging] Avant Window Navigator" [Wishlist,In progress] https://launchpad.net/bugs/118589
<seb128> pitti: yes
<seb128> good morning pitti ;-)
<dholbach> seb128: not sure a query like "all bugs seb128 is subscribed to and ubuntu-main-sponsors or ubuntu-universe-sponsors too" works in LP
<LaserRock> pitti: if people translate strings for gcompris in Rosetta but there is no .pot I'm guessing the translations aren't included in the lang packs
<LaserRock> pitti: I'm looking at bug #107971
<ubotu> Launchpad bug 107971 in gcompris "Incomplete French translation" [Medium,Triaged] https://launchpad.net/bugs/107971
<pitti> LaserRock: they won't even be imported
<pitti> LaserRock: that'll still use the feisty/edgy pot (whenever it got broken)
<LaserRock> right
<LaserRock> man, that's not good :/
<carlos> pitti: yeah, send me anything you need to be fixed so you don't need a build to get it imported
<pitti> carlos: cool, thanks
<pitti> LaserRock: ^ so, please install pkgbinarymangler, enable /etc/pkgbinarymangler/striptranslations.conf, and build the package
<carlos> pitti: is it for gcompris?
<pitti> carlos: oui
<carlos> I only need the .pot file then
<carlos> no need to generate the tarball
<carlos> just get all patchs applied and generate the .pot file
<carlos> and that's it
<LaserRock> ok, to be clear
<mpt> StevenK, are you going to get the HardyAboutUbuntu spec approved by the 22nd?
<LaserRock> I'll fix up gcompris in Hardy when I merge
<LaserRock> for Gutsy I create a .pot and send it to carlos
<LaserRock> pitti: ^^ is correct?
<pitti> LaserRock: seems like it
<LaserRock> pitti: and would it be a good idea to ask upstream to ship a .pot?
<LaserRock> or is that something we like to do at build time anyway
<pitti> LaserRock: I don't think so; we need to generate during build anyway
<LaserRock> pitti: ok, danke
<carlos> LaserRock: gnome doesn't do it by default and is the right thing to do
<carlos> LaserRock: because it's a generated file. Is just that it must be created as a make rule
<LaserRock> carlos: I see
<Nafallo> mjg59: getting VGA-output just by pressing the Fn+key apparently doesn't work
<seb128> doko: around?
<seb128> doko: you added "Fix build failure with g++-4.3" patches to glibmm2.4 and gtkmm2.4, do you have the build errors somewhere or sent those upstream or to Debian?
<doko> seb128: http://people.debian.org/~lucas/logs/2007/09/10/gcc43/
<seb128> doko: thanks
<seb128> doko: do we need those fixes now? I'm considering sending the patches to Debian and doing a sync
<doko> seb128: yes, or else these failures show up in rebuild tests again
<seb128> doko: is there an easy way for me to do a such test build locally?
<pwnguin> Nafallo: which laptop maker?
<mvo> seb128: I installed gcc-snapshot and set CC=/usr/lib/gcc-snapshot/bin/gcc
<mvo> seb128: and CXX=/u/l/g/b/g++
<doko> seb128: either use gcc-snapshot or install g++ from the ~ubuntu-toolchain ppa
<seb128> doko, mvo: thanks
<Nafallo> pwnguin: Lenovo and Sony
<pwnguin> Nafallo: interesting. my toshiba is apparently outright not supported ever
<Nafallo> pwnguin: same chipsets and works fine on the LVDS?
<pwnguin> LVDS?
<Fujitsu> pwnguin: LCD.
<Fujitsu> The internal one, that is.
<pwnguin> Nafallo: i think im missing part of the conversation, which chipsets would be the same?
<Nafallo> pwnguin: X3100 / GMA965
<pwnguin> ah, no
<Nafallo> pwnguin: and right, I probably only just told Fujitsu :-P
<pwnguin> this is a good old nvidia
<Fujitsu> That would be correct.
<Fujitsu> Ah, well, nvidia is evil, so I'm not surprised.
<pwnguin> it has nothing to do with nvidia
<pwnguin> at least not directly
<pwnguin> they support fn
<Nafallo> Fujitsu: xrandr complains that the screen can't be larger than 1280x1280 and fails :-)
<pwnguin> except on toshiba
<Fujitsu> Nafallo: Ah, if you turn off Composite, that should work.
<Fujitsu> Although I'm sure the 965 allows a larger screen than that...
<Nafallo> Fujitsu: aha!
<Fujitsu> Nafallo: Or set the screen to be on top or below, rather than beside.
<Nafallo> Fujitsu: same thing
<pwnguin> do video drivers get put in universe on occasion?
<Fujitsu> Nafallo: Must be a fairly big external screen, then.
<pwnguin> im thinking it would be neat to have nouveau drivers in hardy, but i can understand the LTS being a scare
<Fujitsu> pwnguin: -amd was for quite some time last cycle.
<Nafallo> Fujitsu: 1280x1024
<Nafallo> Fujitsu: and a bigger one on the way :-P
<Nafallo> Fujitsu: anyway... turn off composite with the new xorg.conf? ;-)
<tjaalton> pwnguin: tracking upstream would be massively painful
<tjaalton> since there are no releases
<Nafallo> Fujitsu: - something, right? :-)
<Nafallo> hi tjaalton :-)
<tjaalton> Nafallo: hey :)
<Nafallo> gaah! DUMB google. not the electrical composite...
<pwnguin> tjaalton: indeed. i know someone who already does it though ;)
<Fujitsu> tjaalton: Are you now employed by Canonical?
<tjaalton> Fujitsu: heh no, I just got bored by the long nick
<Fujitsu> Because that generally induces the nick change.
<Fujitsu> Heh.
<Nafallo> lol
<pwnguin> then.. keescook is his real name?
<Nafallo> pwnguin: yes.
<Nafallo> but jono should really be named jbacon now ;-)
<Nafallo> to fit in with the crowd :-P
<LaserRock> along with mpitt
<dholbach> ...say LaserRock and Nafallo... :)
<tjaalton> pwnguin: there's no-one maintaining it in debian, for that reason :/
<LaserRock> one of the perks of being a lowley volunteer
<Nafallo> dholbach: I'm not employed by Canonical :-P
<dholbach> LaserRock: pfffft
<dholbach> Nafallo: pfffft
<pwnguin> tjaalton: i know. plus it carries a lot of extras, from what i recall. some libdrm or something
<Nafallo> dholbach: and well, my name is Nafallo, and my surname is not pronouncable by non-swedes ;-)
<tjaalton> pwnguin: git HEAD of everything..
<pwnguin> tjaalton: at any rate, RAOF keeps a ppa with nouvuau
<Nafallo> Fujitsu: I got clone with Composite and AIGLX off.
<luisbg_> LaserRock, LaserRock! LOL!!
<LaserRock> Nafallo: yeah, I've tried and I just give up
<Nafallo> Fujitsu: so can't see the bottom menu bar.
<soren> If an upstream tarball does not contain the appropriate license file, but it's otherwise quite clear that it's supposed to be there (every source file says it's GPL and such), the right thing to do is to repack the tarball with the COPYING added?
<dholbach> soren: if upstream promised me to add it, I added it to the diff.gz
<soren> dholbach: I seem to remember someone (Mithrandir, perhaps) rejecting a new package on those grounds.. I belive the reasoning was that it's entirely possible to only download the orig.tar.gz from our archive, and without the COPYING in there, it's not clear if it's redistributable...
<soren> dholbach: It's of course entirely possible that I'm just on crack.
<dholbach> soren: you can repack the tarball too, but I'm not an archive admin, so maybe *I*'m on crack
<soren> :)
<pwnguin> where does the failsafe gdm log errors to?
<Mithrandir> soren: it should be in the orig.tar.gz.  I'd like you to get upstream to release a new version with it fixed, but if waiting for that blocks you, please feel free to upload a repacked orig.tar.gz with a note in the changelog as to what's been done.
<soren> Mithrandir: Exactly the answer I was looking for. Thanks.
<carlos> pitti: hi, what's the status of gutsy's language packs?
<pitti> carlos: you tell me?
<pitti> are there tarballs now?
<carlos> pitti: every Sunday and Wednesday!
<carlos> pitti: as usual :-)
<carlos> we don't stop producing them
<pitti> ah, great
<pitti> I'll set up the PPA builds today then
<pitti> I didn't find time to update the langpacks yet, too much stuff to do
<pitti> ArneGoetje: are you interested in some hands-on training about this? ^
<carlos> pitti: ok, thanks
<pitti> carlos: I guess one of these days can be dropped, we'll only build them weekly
<pitti> so that hardy can get a slot
<carlos> pitti: yeah, next month hardy ones will be generated so I will move Gutsy to be done daily
<pitti> daily?
<seb128> StevenK: do you plan to do that gimp merge? ;-)
<pitti> seb128: does gnome-keyring work for you in current hardy? I only get an error dialog "Couldn't search keyring (code 9)"
<Fujitsu> pitti: Works for me several times a day.
<pitti> hm
<seb128> pitti: I think it does, at least network-manager connect to my network without asking the password
<pitti> I have this since yesterday's dist-upgrade
<seb128> gnome-keyring didn't change recently
<Fujitsu> (several times a day because NM reconnects every time I reboot after -intel locks my machine)
 * RAOF returns to see nouveau highligted...
<pwnguin> heh
<pwnguin> sorry ^_^
<RAOF> Was someone after something else from libdrm git?
<pwnguin> i mentioned nouveau earlier
<RAOF> I could easily build intel & ati drm modules from that source.
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, first, the changelog of the actually uploaded cups-pdf (bug 152293) looks a little bit strange (no name u8nder my sync, my name under Debian upload). Did you edit anything on the changelog or did Launchpad mess up the changelog display?
<ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Fix released] https://launchpad.net/bugs/152293
<pitti> tkamppeter: that's fine, since you correctly used -v
<pitti> tkamppeter: what you see is the .changes file, not the actual changelog
<tkamppeter> pitti, I see, in the _source.changes file all name stamps are stripped off from the new changelog entries and Launchpad adds only one name stamp at the end, the one of the latest change.
<pitti> tkamppeter: s/Launchpad/dpkg/
<pitti> tkamppeter: you did the upload and introduced all those versions into Hardy
<tkamppeter> pitti, second, HPLIP: I tried "man requestsync" and my system did not find the man page. Which package do I need to install?
<pitti> tkamppeter: ah, sorry; that's in ubuntu-dev-tools
<pitti> tkamppeter: ah, is that your first sync request?
<pitti> tkamppeter: you should read https://wiki.ubuntu.com/SyncRequestProcess then
<pitti> tkamppeter: it explains both the process and the usage of requestsync
<tkamppeter> Now I have found it, too, by the great command-not-found tool, I typed symply requestsync without man.
<tkamppeter> Yes, it is my first sync request.
<tkamppeter> Thanks for the link.
<Keybuk> >>>> --=-4+WD5xy/k0klzAYckvq7
<Keybuk> **** Command '--=-4+wd5xy/k0klzayckvq7' not recognized.
<Keybuk> heh
<StevenK> seb128: I do, yes.
<Keybuk> someone needs to drag Majordomo into the 20th century
<tkamppeter> pitti, but I am in doubt whether syncing with Debian is the right thing. This is probably more for the packages where there is active maintainership on the Debian side and Ubuntu simply takes what Debian does.
<pitti> tkamppeter: but what was the reason why the DD uploaded it to experimental?
<pitti> ideally the two of you would cooperate and work on one package
<pitti> which is then uploaded to Debian and synced to Ubuntu
<tkamppeter> pitti, we have it the other way around: I am actively maintaining the package at Ubuntu and Debian takes what Ubuntu does.
<pitti> well, with 'we both work in the same VCS and keep the packages in sync' there is not much of an 'other way round' IMHO
<thom> Keybuk: no, they need to kill it with extreme prejudice
<seb128> pitti: well, it's just a question of where the VCS is then
<tkamppeter> The DD, Marc Purcell, has uploaded it becuase users complained about HPLIP not getting updated (Debian bug 413225).
<ubotu> Debian bug 413225 in hplip "new upstream release" [Wishlist,Fixed] http://bugs.debian.org/413225
<pitti> tkamppeter: did you talk to him about shared maintenance? or did he just upload the current version to experimental without any discussion?
<tkamppeter> Mark has put it into experimental because our Ubuntu package has one additional binary package, hplip-gui which causes it to need to go through the NEW process again.
<Keybuk> thom: I had the fun experience of posting a kernel patch to LKML this week
<soren> Where can I find a list of packages in gutsy-proposed?
<Keybuk> let me paraphrase the response
<Keybuk> "AIIIIEE!! MIME!!! GNARGH!!! MELTTTTTING!"
<pitti> soren: http://people.ubuntu.com/~ubuntu-archive/pending-sru.html might be what you want (packages which are newer in -proposed than in -updates/-security)
<pitti> soren: for a full list: Packages.gz :)
<tkamppeter> pitti, Mark did it by himself, without any discussion with me. For me there was simply no Debian maintainer at all, as Henrique de Maraes Holschu has quit doing Debian packaging work.
<pitti> tkamppeter: ah, I see
<soren> pitti: Ooh! That was exactly what I was looking for. Shiny.
<pitti> soren: :)
<tkamppeter> I did not know that Mark does work on printing packages. Perhaps he simply looks around in Ubuntu for what can help on Debian problems.
<pitti> tkamppeter: so if you want to keep it that way, that would be fine; but I still think that working in a shared VCS together with the Debian guys would avoid unnecessary duplicate work on both sides
<pitti> tkamppeter: what does your upload actually change compared to -ubuntu1 we have in hardy?
<tkamppeter> pitti, I think working together with Debian is really the better solution. Only requirement is that Debian provides a maintainer who quickly reacts if I do something on the package.
<pitti> tkamppeter: oh, we shouldn't block on Debian for doing an Ubuntu upload
<tkamppeter> pitti, it adds only a ChangeLog entry, I have only done it to close the Merge-o-Matic sync request.
<pitti> tkamppeter: ah, I see; so we can just ignore the MoM entry for now
<tkamppeter> pitti, I got an e-mail (I do not find it any more) that I should fix my MoM entries, so I will simply ignore that one and only sync if Debian really contributes something and does not only sync our package.
<pitti> tkamppeter: right; it's fine to ignore those, where Debian doesn't have actual changes
<pitti> tkamppeter: do you get my /msgs?
<tkamppeter> Yes.
 * pitti radiates hot hate towards svn
 * Hobbsee waves
<pitti> hey Hobbsee
 * Hobbsee hugs pitti
<\sh> keescook, I added debdiffs for openldap2.3 for feisty and gutsy
<fabbione> hi Hobbsee
<Hobbsee> hey fabbione!
<\sh> keescook, bug #162162
<ubotu> Launchpad bug 162162 in openldap2.3 "[CVE-2007-5708] openldap 2.3" [Undecided,In progress] https://launchpad.net/bugs/162162
<cprov> elmo: do you know if it's easy to restore rubidium image on ferraz ?
<cprov> oops wrong channel, nevermind me.
<seb128> bigon:
<seb128> "Explanation of the Ubuntu delta and why it can be dropped:
<seb128> Ubuntu changes can be dropped"
<seb128> bigon: that's not really an explanation of the Ubuntu delta and why it can be dropped
<pitti> why? yes!
<soren> :)
<Hobbsee> seb128: dude...we didn't have a MOTU write that, surely?
<Hobbsee> ISTR various of us on motu-uvf going thru this stuff with bigon last time, too.
<seb128> Hobbsee: bigon did
<Hobbsee> seb128: yeah.  wow.
<Hobbsee> seb128: i thought our MOTU's took better care than that :(
<seb128> Hobbsee: most of the time they do, don't worry
<Hobbsee> seb128: i'm glad to hear it. repeatedly giving people the riot act around ubuntu too would not be so much fun.
<Hobbsee> s/giving/reading/
<Hobbsee> work is enough :)
<Hobbsee> pitti:++
<seb128> Hobbsee: ?
<Hobbsee> seb128: ? w.r.t what?
<Hobbsee> oh, pitti++ to his mailing list post (ubuntu-devel)
<pitti> Hobbsee: SRU?
<Hobbsee> pitti: yup
<seb128> Hobbsee: yes
<persia> pitti: Just as an aside, motu-sru has been inactive since feisty (not that I don't agree peer review is good).
<Hobbsee> seb128: i'm agreeing with pitti w.r.t his SRU mail to ubuntu-devel.  alternatively, i'm telling pitti to clone himself.
<Hobbsee> persia: i think they're using motu-uvf instead.
<Hobbsee> makes me wonder what i should do with the bugs and such
<persia> Hobbsee: Not really.  Was true from UVF -> release, but not today.
<Hobbsee> hmm, i wonder why i'm getting bugmail
<Hobbsee> last i checked, azereus is not in main.
<pitti> persia: right, it was decided to abolish it
<persia> pitti: OK.  Just wanted to make sure :)
<bigon> seb128: I've explaned a bit more why ubuntu changes can be dropped for empathy
<seb128> bigon: thanks
<pitti> hm, consolekit does not have a session for my primary user
<seb128> bigon: I'll do the sync because you are looking at the package but "Most of the changes merged in debian, other minor changes can be dropped" is still not a satisfactory explanation of what those changes are why they can be dropped
<StevenK> bigon: You need to list all of the changes, the reason for each of them.
 * Hobbsee would advise checking the sig on the request
<Hobbsee> seeing as we've seen crack before from new motus, which are actually non-motu's uploading people's packages, and resigning them.
<Hobbsee> guess that doesnt apply for launchpad, though
<\sh> keescook, bug #162385 , removed all .orig remains from the dpatches
<ubotu> Launchpad bug 162385 in drupal5 "[Security] Several Security Issues for drupal 5.x before 5.3" [Undecided,In progress] https://launchpad.net/bugs/162385
<Keybuk> http://blog.fubar.dk/?p=94
<Keybuk> nice
<pitti> seb128: btw, I have the feeling that the 'gnome-screensaver does not accept my password' is related to the 'CK does not know about my session' bug
<seb128> pitti: gnome-screensaver doesn't accept your password?!
<pitti> no, it occasionally does htat
<seb128> do you have ck running now?
<pitti> seb128: I restarted the session, and it knows about it now, yes
<seb128> weird
 * pitti greets his very first PK auth dialog
 * seb128 hugs pitti
<seb128> Riddell: do you confirm bug #163383?
<ubotu> Launchpad bug 163383 in k3b-i18n "Please sync k3b-i18n 1.0.4-1  (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/163383
<ScottK> pitti: I asked around after we briefly discussed Universe SRU policy yesterday and was told some other MOTUs are working on a proposal to change the policy to (hopefully) deal with your concerns, so discussing it at the meeting on Friday would be premature.  They're planning on posting to the mailing list thread when they have it worked out.
<pitti> ScottK: that sounds fine
<Riddell> seb128: let me look
<Riddell> seb128: yes, that's fine
<seb128> Riddell: ok, thanks
<cjwatson> seb128: perhaps the contentious bits of desktop-volumes-representation (fully automatic label generation) could be factored out to a separate "Discussion" section? I think the rest of the spec is valuable and can be approved without that
<cjwatson> it seems reasonable to have the desktop autogenerate a reasonable label on the fly if there isn't one there, and if the user wants to change it to something meaningful to them then let them do that; the installer isn't going to be able to guess something any more meaningful than what you could generate on the fly anyway
<cjwatson> (where meaningful => "my old Windows stuff" or "my music" or whatever)
<seb128> cjwatson: works for me, part of the spec is deprecated by partition-âmanagement though
<seb128> cjwatson: I'll update it to list only the naming policy we want to use
<cjwatson> ok, I haven't read that yet
<soren> Should .py files in /usr/share/python/site-packages... usually be executable? They're not meant to executed directly, but lintian makes a fuss about it.
<cjwatson> IIRC, lintian makes a fuss only if they don't start with #!
<cjwatson> if the files are executable, they should actually *be* executable by means of a #!; if that's not desirable or sensible, remove the x bit
<soren> They have #!, and are not executable, so it's the other way around.
<soren> I could change the build system to remove the #! lines, but I'm not sure it's worth the effort.
<pitti> Keybuk: Awooga! my first gnome-mount -> PK -> auth dialog for *my* password (not root's) -> success :)
<cjwatson> soren: for "not worth the effort", the right answer is to leave the lintian warnings there and just not pay attention to them
 * pitti declares this a good enough victory to finally have lunch, bbl
<cjwatson> then perhaps some future developer may see and care
<dholbach> pitti: enjoy it :)
<soren> cjwatson: That's what I meant :)
<soren> cjwatson: Thanks.
<cjwatson> I think Lintian's point in this case is really more that the useless shebang should be removed, rather than that it really wants them to be executable
<soren> cjwatson: Right.
 * lamont uploads a new bsdmainutils to go with the util-linux upload of last night
<Keybuk> pitti: sweet
<Nafallo> anyone have a date for when vmware will be available in gutsy/partner?
<pitti> seb128: in the interest of peer review, do you think https://wiki.ubuntu.com/MainInclusionReportPolicyKit is sane?
<seb128> pitti: looking
<seb128> pitti: s/Gnome/GNOME ;-)
<pitti> argh, I suck :)
<seb128> pitti: looks good
<cjwatson> Keybuk: since I just drafted hardy-bootloader-review, would you take over the job of approver from me, please?
<seb128> yeah for policykit ;-)
<Keybuk> cjwatson: sure
<cjwatson> thanks
<pitti> so let the madness begin! /me promotes
 * ogra sees a lot of traffi on increase-hwdb-participation
<ogra> pitti, cjwatson did any of you talk to cr3 ? he's working on a new client afaik
<ogra> not smolt based
<pitti> he mentioned it briefly
<pitti> on FossCamp, someone showed me http://www.dohickey-project.com/
<pitti> this also looks quite useful
<ogra> the ideas sound just wÂ´awesome
<ogra> talk to him :) it sounded like a nice idea of partial apport integration with the hwdb client
<Ng> pitti: was it Martin Owens? he was at fosscamp (and is a thoroughly pleasant chap)
<pitti> Ng: right, he was
<pitti> it was him, I meant
 * pitti -> off for some hours, bbl
<\sh> keescook, jdstrand bug #164072 ready for review
<ubotu> Launchpad bug 164072 in cacti "[CVE-2007-6035] cacti has a sql injection vulnerability" [Undecided,New] https://launchpad.net/bugs/164072
<jdstrand> \sh: thanks! :)
<cr3> ogra: I will be talking to the fedora folks, introduced to me by George, about extending hwtest (next generation of hwdb) to also post hardware information to smolt
<ogra> right
<cr3> darn, pitti left, but I would also like to mention I have spoken to the author of dohickey and we'll probably work together
<ogra> on the spec there was a question if we'd use smolt
<ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/increase-hwdb-participation
 * persia notes that it might be nice to catch HW changes as well, for those who upgrade without reinstalling, but not important enough to spec or anything
<cr3> ogra: since smolt is such a recurring topic, I will try to implement it as soon as possible
<cr3> persia: I would like to track hardware and software changes. when there is a test corresponding to one of those things which have changed, the user could be prompted to retest
<persia> cr3: That'd be the solution to my ill-formed wish :)
<cr3> persia: glad to hear it sounds useful, this kind of feedback is very valuable
<persia> cr3: I'm mostly thinking in terms of tracking support effectively.  If I attach a new DDC/CI screen, or a new keyboard with a different layout, or put in the latest video card, etc. the system will still work (perhaps with a quick fiddle), but the fact that the system supports that hardware isn't being reported, so the next person doesn't know it's safe to install.
<\sh> jdstrand, I'll push some notes to debian stable security, too
<\sh> jdstrand, btw...I can't add the CVE link to the bug report, because I think LP only checks mitre...but this CVE is not listed on mitre right now
<cjwatson> calc: note that I have assigned ooo-langpacks to you and targetted it for hardy; I believe the specification is fairly clear and we've discussed it before, but please shout if anything is unclear
<jdstrand> \sh: that has been my experience as well
<\sh> jdstrand, worth a bug?
<cr3> persia: right, so you should be prompted once again to run the relevant tests corresponding to your new hardware
<jdstrand> \sh: I don't think so.  I think it is intentional right now as a form of integrity checking.
<jdstrand> \sh: LP isn't well integrated with security updates yet, so it is not a big deal anyway
<\sh> jdstrand, well, the CVE parser on edge is a real improvement :)
<jdstrand> \sh: if it's noted in the bug report and flagged as security, we can get it in our cve tracking syste
<persia> cr3: I'm undecided regarding a direct prompt, or a more subtle restoration of a menu item, as I suspect the collection would be best done after any required local tweaking, rather than before, but it depends on whether the test is an "out of the box" test or a "works for me" test.
<calc> cjwatson: ok
<jdstrand> \sh: there has been some work on it, yes, and hopefully we'll be able to move over relatively soon (I have no timeframe)
<cr3> ogra: by the way, I added a cool feature to hwtest yesterday which relates tests to hardware or software components. the relation is defined in a text file and is really readable: 'net.80211' in info.capabilities and linux.hotplug_type == 2
<ogra> nice !
<cr3> ogra: ideally, I would like to be able to list all hardware devices and see the number of related tests
<lamont> cjwatson: got time to be a chroot-tarball muppet?
<lamont> chinstrap:~lamont/chroot-fresh, *7
<wasabi> Curious question: would it make sense in some way for dhclient to store received dhcp options in HAL for a given network device?
<wasabi> I'm wondering about how to propagate a few of those options to other applications, such as, for instance, Samba's WINS option.
<Keybuk> it makes an amount of sense
<wasabi> Yeah, we're storing similar stuff, such as MD and LVM block devices in there. High level stuff.
<wasabi> options could be translated to dhcp.$optionname or dhcp.$optionnumberid
<wasabi> or some such
<wasabi> Sort of overlaps with network manager.
<wasabi> (which might be a good thing)
<wasabi> Maybe a sub-network device pseudo device for each assigned IP.
<wasabi> With the possibility of seeing how that IP originated, dhcp or otherwise, and if so, pulling otu teh dhcp options.
<Keybuk> network manager is basically just mechanism
<wasabi> Basically then it would come down to making Samba pull it's information from there. And watch for changes.
<Keybuk> for a given interface, it can bring it up or down
<wasabi> Which would be a very nice way to go about it.
<wasabi> Yeah.
<Keybuk> and uses dhclient and/or wpa_supplicant to do that
<wasabi> Applications can query NM to determine up/down state, though.
<Keybuk> right, though arguably that should be in HAL
<wasabi> Yes.
<wasabi> DHCP can be used to push time servers too, syslog servers, cookie servers, lpr stuff.
<wasabi> Tons of stuff in there which has never even been touched on in Unix because there has never been a good way to get it to userspace.
<wasabi> Heh. Can push SMTP servers, POP3 servers, NNTP.
<wasabi> Would be slightly interesting (though maybe an abuse of DHCP) to put that into Evo, so when setting up an account, it defaults to those.
<Chipzz> wasabi: yes, but those settings may be transient, and when the dhcp server on another network does not supply them you're stuck with the old ones
<Keybuk> actually, you'd just have a transient evo account
<Chipzz> *old and incorrect
<Keybuk> so when I login at home, there's an extra private e-mail account for cron mail
<Keybuk> but when I login elsewhere, that account isn't accessible
<Keybuk> (unless I've checked the [X] Available Offline button)
<wasabi> Yeah, combined with Kerberos and friends, that would be pretty slick.
<wasabi> For an office, etc.
<Keybuk> imagine if DNS information was retrieved from HAL by the resolved
<Keybuk> resolver
<Keybuk> instead of some static file on the disk
<wasabi> That would be nice. ;0
<Keybuk> then we wouldn't have a lot of the problems we have today :)
<wasabi> Yeah. You could enumate multiple sources of DNS information: VPNs, DHCP.
<Chipzz> but I don't think even MS uses dhcp for mail
<wasabi> In some sort of described priority level.
<wasabi> (vpn A runs on top of connection B)
<wasabi> No, MS doesn't use DHCP for mail. It's just an ideea.
<wasabi> My bigger point is to simply see about putting that info SOMEWHERE>
<wasabi> And HAL is probably closer to the right place.
<warp10> Hi all!
<keescook> soren: I need to convince you to use subprocess.call([]) instead of os.system.  :)  (submittodebian)
<keescook> soren: also, what do you think of an env variable like "OVERRIDE_DEBEMAIL" or something so that reportbug will use something other than the currently set DEBEMAIL var?
<soren> keescook: No no, you got it all wrong. You need to convince yourself to go fix that. :)
<keescook> soren: no way, security through education.  :)
<jdong> I thought the catchphrase around here is "open a launchpad bug"?
<jdong> :D
<keescook> for my second item, yeah.  But mostly I'm trying to stamp os.system() out of anyone's mind.
<keescook> newly written code should always use an array-based "system" call.
<keescook> (in python's case, that's subprocess.call())
<jdong> keescook: yeah I just read up on subprocess.call(), I will transition my stuff to use that too, it makes a lot more sense
 * jdong watches his todo list grow even more
<keescook> jdong: cool!  yeah, it's a bit weird in some cases, but just not using a shell-backed exec of a string is a win.  :)
<jdong> keescook: wholeheartedly agreed :)
<soren> keescook: hm... So what's the deal with the subprocess.call thing?
<soren> keescook: Just that it doesn't get parsed by a shell or something else?
<soren> keescook: Er..
<keescook> soren: while I don't suspect anyone will pwn you via submittodebian, I just saw the use of os.system and had to soap-box about subprocess.call().  ;)
<jdong> soren: yeah the main point is it precludes accidental shell escaping by not having a shell interpret the arguments
 * soren opens his eyes and notices that kees already answered that.
<keescook> soren: what jdong said.  :)
<soren> Sure, I dig that.
<jdong> also makes sure your own arguments don't need to have annoying quoting, so win-win for laziness
<soren> Yeah, I know. :)
<norsetto> riddel: ping
<norsetto> riddell: ping
<Riddell> hi norsetto
<norsetto> riddell: hi!
<norsetto> riddell: just wondering, I've seen that tagtool was accepted in gutsy-proposed but I can't find the source in the archive?
<Riddell> norsetto: hmm
<Riddell> norsetto: I think the publisher is still doing its thing, it just turned to needs building https://launchpad.net/ubuntu/gutsy/+source/tagtool/0.12.3-2ubuntu0.1
<norsetto> riddell: ok, so the source will not show up until it is built?
<Riddell> norsetto: it should show up before then, best wait an hour and see if it has appeared
<norsetto> riddell: okki, thanks
<cjwatson> lamont: what are the changes?
<lamont> apt-get update; apt-get dist-upgrade
<lamont> --> shorter build logs, and slightly faster build times
<cjwatson> lamont: FWIW, if I'm not mistaken, ebug-http is looping on palmer
<cjwatson> lamont: updated *7, thanks
<\sh> re
<\sh> keescook, you found the patches for feisty+gutsy for openldap2.3?
<lamont> cjwatson: I don't see any runaway procs on palmer
<cjwatson> lamont: https://launchpad.net/+builds/palmer has been spewing "Please enter your CPAN site: []" / "CPAN.pm needs at least one URL where it can fetch CPAN files from." for six hours apparently
<lamont> ah
 * lamont checks again
<lamont> ah, ebug-http build. doh
<lamont> killed with prejudice.
<lamont> and it's arch-all, apparently (just i386 build record)
<cjwatson> oh, sorry, guess I should have made it clear I meant a build
<lamont> so no extra cleanup to do
<cjwatson> have you filed a bug?
<cjwatson> (hang on, why am I telling *lamont* to file a bug?)
<lamont> I have not
<lamont> heh
<lamont> I'll go file one
<cjwatson> ta
<lamont> right after I do a build on i368/debian, so I can file it against debian, where it should be
<cjwatson> heh
<cjwatson> has anyone here encountered bug 162638? If so, we are desperate for an installer log file so we can track it down
<ubotu> Launchpad bug 162638 in user-setup "sudo - first user not in sudoers file" [Undecided,Incomplete] https://launchpad.net/bugs/162638
<lamont> cjwatson: heh.  #450423, 13 days old.
<lamont> I'll import it to launchad
<warp10> hi pitti! bug #164143
<ubotu> Launchpad bug 164143 in gwhois "Please sync gwhois 20071030  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/164143
<cjwatson> lamont: ah yes
<lamont> bug 164166 linked
<ubotu> Launchpad bug 164166 in ebug-http "FTBFS: tries to download from CPAN" [Undecided,New] https://launchpad.net/bugs/164166
 * lamont always feels a little guilty when he confirms his own bug reports
<pitti> warp10: hi!
<DktrKranz> Riddell, ping
<Riddell> hi DktrKranz
<DktrKranz> Riddell, I just redid upload for bug 162843. Mind checking?
<ubotu> Launchpad bug 162843 in docbook2odf "Package dependency missing : perlmagick" [Medium,Confirmed] https://launchpad.net/bugs/162843
<Riddell> DktrKranz: looks good, accepting
<DktrKranz> Riddell, thanks
<warp10> pitti: I used requestsync for that sync. Anyway, the changelog is rather long, and it shows changes much older then the latest ubuntu version. I don'think this is an expected behaviour... should I manually shorten the description?
<mdz_> pitti_: we're discussing your proposal on #-meeting if you're around
<pitti_> mdz_: oh, I am; seems I just broke hardy, so I'm going to fix that, but I'll join
<nixternal> pitti: I was going to let you know that hal didn't devistate hardy, but it added icons to my desktop (kubuntu) and knetworkmangler doesn't show any devices after the update...I know you are in a meeting, so have fun :)
<pitti> nixternal: thanks; but I already found the cause
<pitti> and why I didn't notice it when I tested that stuff
<pitti> policykit ships /var/run/PolicyKit and relies on it
<pitti> wham :)
<nixternal> ahhh
 * pitti will fix tonight
<nixternal> I did see policykit as well
<nixternal> groovy, keep on rockin'!
<pitti> sorry for the breakage
<nixternal> easy work around, so it isn't major
<nixternal> just a bit of a scare until I decided to read /etc/networks/interfaces and seen my old comments from 2006 in there :)
<ajmitch> pitti: I'm interested to hear your SRU plan there :)
<pitti> ajmitch: it was just decided upon, I'll communicate the result to the MOTU council shortly
<ajmitch> right, I was just watching -meeting
<bryce> pitti, I've fleshed out more details about xorg hardware detection (particularly vis-a-vis input hotplug / hal) at https://wiki.ubuntu.com/HardyHardwareDetection - the section entitled X.org configuration refactoring
<bryce> pitti, hope that's okay...  I didn't touch other parts, but I think it doesn't conflict with anything said elsewhere
<pitti> bryce: ah, thanks; I'll have a look
<ivoks> fabbione: have you seen bug 158288?
<ubotu> Launchpad bug 158288 in redhat-cluster-suite "Node hangs at clvm when joining cluster" [Medium,Confirmed] https://launchpad.net/bugs/158288
<fabbione> ivoks: no..
<fabbione> oh yeah hell yes
<fabbione> i know that problem
<fabbione> it's new..
<ivoks> just kicked me in the a... :)
<fabbione> ivoks: i think there is a workaround if you want to test.
<ivoks> sure
<fabbione> basically the problem shows up only when a node has more than one ip address
<fabbione> like a vip or so
<ivoks> that's the case at my node
<ivoks> 4 IPs :/
<fabbione> the cman/dlm do not know which one to use for outgoing connections
<fabbione> before we fixed the security stuff to restrict 2 connections from each node to each node
<ivoks> that makes sense...
<fabbione> cman/dlm were trying to connect * to *
<ivoks> so it tries on all, yeagh..
<fabbione> so at some point the right combination would kick in and work
<fabbione> but
<fabbione> with the restriction you need to make sure that the right 2 will start from the beginning
<fabbione> or bad things happen
<ivoks> hm :/
<fabbione> so the workaround is to make sure that each node can only talk to the other from one IP
<fabbione> for example
<fabbione> node1 resolves to 4 IPs
<fabbione> make node1 (as specified in cluster.conf) to resolve to only 1 IP
<fabbione> do the same for all the nodes
<fabbione> and that should work
<fabbione> without crapping out the services
<fabbione> so basically ccs/cman/etc. will know each node by only one ip that should be forced as source at that point
<ivoks> you mean arp resolve?
<fabbione> -no
<ivoks> cause, it allready resolves to single IP
<fabbione> dns/hosts resolve
<ivoks> node1 resolves always to same IP
<ivoks> so does node2
<ivoks> 3...
<ivoks> etc
<fabbione> ok
<ivoks> if i start them all together, everything is ok
<ivoks> but if i reboot one, that one will not boot
<fabbione> no, it will just take hell of a time to boot
<ivoks> well, i'm waiting for a hour already :)
<fabbione> it can take any random time... really
<fabbione> i am trying to find the upstream patch
<ivoks> this is what i get:
<ivoks> dlm: connecting to 2
<ivoks> then got connection, then extra connection, and then clurgmgrd says that it faild changing RG status
<ivoks> and since then, nothing happens
<fabbione> yeah
<ivoks> i looked for a patch, but couldn't find it :/
<fabbione> i am asking to the guy that did the first patch
<fabbione> i can't find it
<fabbione> it was either Lon or Patrick that did the patch
<fabbione> IIRC Lon
<ivoks> we can move conversation there, if you like
<fabbione> it doesn't matter.. i found it
<ivoks> i will test the patch and if it works, i'll let you know
<fabbione> one second
<fabbione> i need to see which one it is
<fabbione> i found at least 2/3 on cluster-devel
<fabbione> ivoks: the one in the bug is good
<ivoks> ok
<slangasek> lamont: is your disabling of db4.5 java on hppa still relevant if merging the -11 in unstable?  seems to be built fine on hppa in Debian
<ivoks> fabbione: and, this is kernel bug :), so BenC will maintain it :)
<fabbione> ivoks: well no.. i still need to provide a patch
<fabbione> it's his problem to get it uploaded :)
<\sh> ogra1, you use evolution right? do you think we can get another translation for "Benachrichtung bei neuen EMails" plugins? I have two with the same name but with different descriptions
<fabbione> ivoks: if you are building kernel test packages, can you please provide them to the bug reporter too?
<fabbione> and if you have issues to patch the kernel let me know
<ivoks> yes
<fabbione> the patch is based on a code that is slightly newer than the one we have in dapper
<ivoks> um... i'm doing this on gutsy
<fabbione> oh ok
<fabbione> he reported in dapper
<fabbione> no hold on
<fabbione> your patch is different then
<fabbione> i think
<ivoks> joy :)
<fabbione> gimme a sec
<fabbione> ivoks: the patch is the same.. slightly different location. you want to patch kernel/fs/dlm/lowcomms.c
<pitti> yay, I unbroke hardy
<fabbione> ivoks: for dapper that file didn't exist :)
<ivoks> :)
<ivoks> now i just have to figure out how to properly patch kernel :/
<fabbione> ivoks: it's easy.
<fabbione> just apply the patch on top and build
<ivoks> hm?
<ivoks> ok
<ivoks> that was backup solution :)
<fabbione> gutsy didn't use any fancy pants patching system
<fabbione> just apply the patch.. go for it :)
<\sh> keescook, jdstrand : is anyone of you working on net-snmp sec fixes?
<Nafallo> ion_: hehe. saw me joining the group on facebook, did you? ;-)
<ion_> nafallo: Yeah. :-)
<Nafallo> Keybuk: what the heck is smolt? :-)
<pitti> Keybuk: ah, just talking to Lennart; the esd socket problem I mentioned to you this morning has a trivial solution
 * Nafallo reads his e-mail :-)
<pitti> Keybuk: -> go back to upstream's default and remove Debian's (small) change :)
<Keybuk> Nafallo: http://rasher.dk/g/smolt
<\sh> keescook, jdstrand : working on #164007 , gutsy just finished
<Nafallo> Keybuk: cheers
<Nafallo> lol
<Nafallo> Keybuk: you could have just said jfgi ;-)
<alex-weej> seb128: you say the "X system keyboard settings differ from your GNOME keyboard settings" dialog has been removed from GNOME -- what's the behaviour now?
<seb128> alex-weej: dunno, I need to look, likely using the GNOME settings
<alex-weej> ok -- has there not been a GNOME release since then?
<seb128> alex-weej: re, did you get the reply?
<alex-weej> no
<seb128> dunno how they changed it, I would need to read the bug again, likely by always using the GNOME settings
<DaBonBon> am i going wrong somewhere or is there no way to change LOCALE and LANG in ubuntu gutsy ?
<pitti> DaBonBon: System -> Settings -> Language Support
<DaBonBon> pitti: and for kubuntu ?
<pitti> DaBonBon: or set it in /etc/environment
<DaBonBon> thank you, pitti
<pitti> DaBonBon: please ask in #ubuntu, this is not the right forum
<DaBonBon> pitti: actually, i was going to file a bug
<DaBonBon> because there is no localeconf in ubuntu, and unlike debians locale package, there is no dpkg-reconfigure frontend for it
<DaBonBon> and i was wondering, is this a bug or an intentional thing ?
<pitti> intentional, we prefer to use the language selector application
<pitti> (there is a bug already, too)
<DaBonBon> ah ok, thanks pitti
<DaBonBon> sorry, i should have searched then.
<DaBonBon> anyway pitti , thanks for the help.
<\sh> pitti, could you do me a favour before you and I go to bed? ,-)
<pitti> \sh: I guess I shuold ask for details before I say yes :)
<\sh> pitti, just curious if this patch (http://sourceforge.net/tracker/download.php?group_id=12694&atid=112694&file_id=228217&aid=1712988) is not too dangerous for a security update...well actually this is what upstream of net-snmp was doing to fix this issue
<ubotu> Gaim bug 1712988 "GETBULK with large max-repeaters DoS [CVE-2007-5846]" [Pri: 5,Closed fixed]
<\sh> pitti, it's net-snmp not gaim...ubotu is wrong
<pitti> \sh: upgrades will get the upstream defaults (100 responses or so?) without changing any config file, right?
<pitti> \sh: I don't know snmp, but the patch logic seems ok if the point is to stop request flooding
<\sh> pitti, yepp..if nothing is set in snmp.conf it will be set to the default 100/-1
<\sh> pitti, yeah, the patch itself looks very safe..but I was unsure, if introducing new configuration settings is ok
<pitti> seb128: ok for me to seed pulseaudio-esd-compat and perhals p-module-{x11,hal,gconf,zeroconf} to ubuntu-desktop?
<\sh> pitti, so I backport all this stuff downto dapper tomorrow...gutsy is finished
<seb128> pitti: sure, looks like a good idea to start giving those testing early
<pitti> \sh: it's not common, but we did it in the past already, and sometimes it's just necessary
<pitti> seb128: I just uploaded a fix for unbreaking multiuser, so it should be goo dnow
<seb128> pitti: no option about the modules, not sure what they are useful for, but the pulseaudio-esd-compat looks a good thing
<seb128> pitti: you rock
 * seb128 hugs pitti
<\sh> pitti, cool..so I'm on the secure side of life :) thx and good night :)
<pitti> breaking policykit and pulse on one day and then going to holiday -- go me :)
<pitti> \sh: sleep well, and thank you!
<theunixgeek> How do I upgrade to GNOME 2.20?
<pitti> "Ubuntu 7.10"
<ogra> seb128, -x11 is the keyboard bell, -hal is used for device detection, -gconf puts the config into gconf
<pitti> and zeroconf publishes your available audio sinks
<ogra> i'm not sure why we want zeroconf though
<ogra> sounds scary
<pitti> you can route your desktop's sound output to your kitchen computer, and this makes it trivial to find :)
<ion_> In a secure network, itâs awesome.
<pitti> it's just about *finding*, not actually providing the server or service
<pitti> but yeah, we can add that crack later :)
<seb128> pitti: the set looks like some useful
<pitti> I'll defer -x11 and -zeroconf, but gconf and hal are very useful IMHO
<ogra> -x11 is great :)
<ogra> configurable terminal beeps rock :)
<ion_> Yeah
<pitti> well, the standard bell is much nicer, yes
<seb128> visual bell rocks
<seb128> agressive beep on typo is not a good user experience
<pitti> $ grep setterm .bashrc
<pitti>     setterm -blength 15
<pitti> FTW :)
<Keybuk> compiz needs better visual bell animations
<ogra> you can use a very nice and quiet calm beep :)
<ogra> it accepts wav files iirc
<Keybuk> like the bell-generating window should leap into the air, slam down on the desktop, sending ripples out across the screen
<pitti> yeah, the current 'fade the entire screen' is horrible; I thought my driver was broken
<seb128> ogra: you mean one that you don't hear? ;-)
<Keybuk> pitti: you can change that to just fade the window
<pitti> like Darth Vader's dark voice saying "ZOMG"
<seb128> we should have a muted boot option
<ogra> heh
<Keybuk> seb128: heh, because the PowerBook Manoeuvre is so last year?
<seb128> "PowerBook Manoeuvre"?
<seb128> no, because having a laptop doing startup bong and beeps is annoying when you sit in a presentation or a meeting
<Keybuk> that amusing moment when PowerBook owners turn it on, then suddenly cover the speakers with their hands in embarrassment
<seb128> ah ;-)
<Keybuk>  _
<Keybuk> | |__  ___ _ _  __ _
<Keybuk> | '_ \/ _ \ ' \/ _` |
<Keybuk> |_.__/\___/_||_\__, |
<Keybuk>                |___/
<seb128> yeah
 * pitti disabled that about 3 hours after getting his iBook
<Keybuk> laptops should startup silent anyway
<pitti> there's a MacOS app to disable it
<Keybuk> why do we need a startup sound
<Keybuk> what purpose does it actually serve?
<pitti> you know, I hoped to get away with leaving it broken in Gutsy
<pitti> but someone chased me up eventually to fix it :)
<Keybuk> we should silently (heh) disable it, and see if anyone complains
<pitti> "Acoustic OS fingerprinting"
<pitti> Keybuk: we did, and they did
<Keybuk> who was the "they" ?
<ogra> well, that was a bug
<ogra> Keybuk, they community :)
<pitti> meh, lool killed the previous libgnome changelogs and didn't keep the bug numbers in the merge summary
<Keybuk> bah, them :)
<pitti> wasn't Dell involved there as well? in the bug?
<seb128> Keybuk: the gdm sound is an accessibility thing, it tell you want the login screen is ready
<Keybuk> sure, the gdm sound is vaguely useful
<Keybuk> the Dum-di-dum-di-dum-dum-da-ting isn't
<tkamppeter> pitti, msg
<ogra> its branding
<ogra> which makes it useful to some extent
<pitti> bug 129029
<ubotu> Launchpad bug 129029 in libgnome "[Gutsy Tribe-5] No Sound on Login Screen or during Login" [High,Fix released] https://launchpad.net/bugs/129029
<pitti> NB the bug prio *sigh*
<pitti> we should have mentioned it as a feature in the release notes
<seb128> well, look like quite some users expect it
<poningru> rofl
<Keybuk> pitti: that's more likely because people assumed their sound cards were broken
<seb128> dell being one of those (the bug has a dell task listed)
<ogra> it makes you recognize other ubuntu users :)
<Keybuk> it could probably have been commented as "we removed the sound because it embarrasses the hell out of people when their laptop sings to the world"
<soren> pitti: "We've finally tracked down the setting that causes the annoying sound and startup and have disabled it."
<poningru> Keybuk: its the same thing with the whole brown imho
<Keybuk> and it would have gone silent
<Keybuk> though some sounds are hilarious
<Keybuk> like when a Thinkpad owner's battery goes low on a plane
<slangasek> lamont: likewise, is there any reason to diverge from Debian on posix vs. pthreads mutexes?
<Keybuk> the expression on some people's face is beautiful
 * poningru thinks we should have sound like that
<poningru> and it should sound like a ticking time bomb
<Keybuk> NEEE-NAAW-NEEE-NAAW-NEEE-NAAW...ohfuckweregonnadie...Oh wait, Thinkpad user
<ogra> heh
<poningru> it would be hilarious on a plane especially
<ogra> poningru, the brown is gone
<poningru> yeah I was quite sad about that :(
<Keybuk> ogra: it may be making a come back
<ogra> really ?
<Keybuk> the new theme Humans In Corduroy
 * tonyyarusso prefers the current color scheme over the one mockup he's seen so far
<ogra> lol, thats from dholbach, right ?
<evand> bright yellow!
<Keybuk> tonyyarusso: what mock-up is that?
<poningru> link?
<tonyyarusso> Keybuk: not sure - it was on digg a few days ago
<Keybuk> oh
<Keybuk> that amused me
<Keybuk> it was, in no way, official
<pwnguin> why doesnt someone just instrument human to have a color selector, and make the default orange?
<tonyyarusso> 'k :)
<pwnguin> at the moment, orange serves branding well. you can pick an ubuntu screnshot out from a mile away
<Keybuk> pwnguin: there's two camps.  there's the "orange, because it's a colour from the ubuntu logo" and there's the "brown, because it's what we always used to have"
<pwnguin> orange and brown are the same color :P
<Keybuk> http://blog.eax.fr/images/blog/installation-ubuntu/20-ecran-login-gdm-ubuntu.jpg
<Keybuk> ^ brown gdm
<Keybuk> http://people.ubuntu.com/~mmueller/face-browser-2.png
<Keybuk> ^ orange gdm
<Keybuk> brown != orange :p
<ion_> Was that the mockup you talked about?
<pwnguin> brown is just a dark orange
<Keybuk> ion_: no
<poningru> http://blog.slyon.de/?p=154
<poningru> that one?
<evand> that looks fantastic
<Keybuk> it does look rather nice
<Keybuk> a bit too dark though
<Keybuk> I really like the way he put the menu into the title bar
<pwnguin> so is that an actual theme, or just a mockup?
<Keybuk> just a mockup
<Keybuk> I don't think some of the things there are even possible
<pwnguin> like putting the menu bar into the title bar ;)
<Keybuk> nice use of awn, shame it makes us look like apple
<jdong> 17:21 < pwnguin> brown is just a dark orange
 * jdong dies a little inside....
<jdong> you're like my dad (colorblind) defending his assertion that my blue T-shirt is greenish grey.
<pwnguin> except its true
<ogra> Keybuk, awm is cool, i have a classmate image using only awn and compiz, makes it really uasable fast :)
<pwnguin> grab a color picker and throw it into HSV
<pwnguin> they're the same hues, just different brightness and saturation
<Keybuk> ogra: I played with it for a while
<Keybuk> the awn problem isn't the pretty, it's the interaction
<ogra> errwell, my prob on the classmate was that you really need autohide with that screensize .... but thats not really practical imho
<Keybuk> or make it so windows can overlap
<Keybuk> is awn a window?
<Keybuk> or is it above all other windows?
<Keybuk> or below all other windows?
<Keybuk> or is it in a special place no others windows can go until they've eaten the spice
<Keybuk> and that's not even starting on what happens to icons there; if I start empathy, its icon should become interactive
<ogra> for me it was always below all others
<Keybuk> which works for screen size
<ogra> which froced me to use autohide ... (which intrestingly is in fron of all other windows)
<Keybuk> but then you have the application switching problem
<ogra> right
<Keybuk> and the notification problem
<ogra> well, compiz helped here
<Keybuk> I saw a cute demo of the problem
<Keybuk> where the fullscreen window swung back out of the way (as if hinged at the top of the screen) so reveal the waiting dock underneath
<Keybuk> so the notification revealed itself
<ogra> heh
<ogra> well, for its young age its a pretty good app imho :)
<Keybuk> oh, it's totally a good app
<ogra> just needs to mature a bit
<Keybuk> I was playing with kde 4 stuff earlier
<Keybuk> I really like the fact you can drag applets off the panel and onto the desktop
<pwnguin> does the classmate have a touchscreen?
<ogra> no
<Keybuk> ah, my favourite UI problem
<Keybuk> GNOME (and some apps in particular) is terrible for laptops
<Keybuk> because it assumes you have a mouse!
 * pwnguin has his tablet working okay with gnome+tablet
<pwnguin> well, not in hardy right now, but dont blame GNOME for that
<Keybuk> that's not what I mean
 * ogra just upgraded to hardy, but fears the reboot sinc ehe heard pitti say he broke the world
<Keybuk> like right now, I'm in xchat
<pwnguin> alt+2
<Keybuk> if I want to open another application, I have to move the MOUSE POINTER all the way across the screen to the top-right corner
<Keybuk> without a Mouse, this is annnnoyingly hard
<pitti> ogra: you are doomed if you have policykit 0.6-1ubuntu1
<pitti> ogra: ubuntu2 is not built yet
<pwnguin> eh
<pwnguin> i knew it was smart not to install the policykit push
<ogra> pitti, i have whatever was recent at 6pm UTC :)
<pitti> ogra: but if you have and reboot, the workaround is to "dpkg-reconfigure policykit" and "/etc/init.d/hal start"
<ogra> ah, trivial
<pitti> it just stumbles over the fact that /var/run/PolicyKit is missing (with appropriate permissions)
<pwnguin> Keybuk: how about quicksilver / deskbar / that new gnome app i saw
<pitti> drwxrwxr-x 2 polkituser polkituser 60 2007-11-20 22:23 /var/run/PolicyKit/
<ogra> i'm really scared about polkit
<pitti> so was I :)
<ogra> it might break the world in ltsp
<pitti> that's why we break it that early
<pwnguin> Keybuk: so you'd rather have the windows key be bound to the app menu, instead of alt+f1?
<Keybuk> pwnguin: you're missing my point, I think
<ogra> well, i have no ltsp code yet due to the upstream restructuring
<Keybuk> the problem isn't that there aren't keyboard shortcuts
<Keybuk> the problem is that the UI is designed to assume a mouse
<Keybuk> in much the same way that the mobile UI doesn't
<pwnguin> a mouse or a pointer device?
<Keybuk> exactly
<pitti> ogra: I think consolekit shuold be more relevant for LTSP, and we already have that in gutsy
<Keybuk> it's the one thing you don't have an efficient version of on a laptop
<pwnguin> is the problem that itt assumes a mouse or that it assumes a pointer device?
<Keybuk> pointer device
<ogra> pitti, well, they work hand in hand if they are both there
 * pitti hails the .*kit invasion
<Keybuk> at least, an efficient one
<ogra> consolekit wasnt used much yet
<pitti> yesterday I learned what "webkit" is
 * pitti renames apport to crashkit
<Keybuk> pitti: driverkit for restricted manager? :p
<ion_> crapkit
<keescook> \sh: cool, thanks for looking into net-snmp; I hadn't gotten to it yet.
<pitti> Keybuk: well, I do need a proper name, but my current working theory is "Threepio" :)
<keescook> er, \sh_away: ^^
<Keybuk> pwnguin: again, another cute techo demo I've seen
<Keybuk> using the touchpad on a laptop not as a pointer, but as a gesture device
<Keybuk> to close a tab or window, you draw an X with your fingers
<Keybuk> to move to the tab on the left, you draw a <
<ion_> Thatâs a great idea.
<Keybuk> to scroll, you draw a circle and keep drawing
<pwnguin> meh. i just use the keyboard :P
<mjg59> Easy enough to manage
<Keybuk> yeah, probably quite easy
<pitti> lool: hm, wrt. your DistCompilerFlags changes: I think you got the idea wrong, which indicates that the spec should explain it in a better way; let's discuss this in the next days
<mjg59> For devices with a passthrough, you could even do it and keep that active
<pwnguin> my desktop prety much lacks the normal mousy considerations
<Keybuk> it obviously doesn't help with things like gimp and impress on a laptop, but you're pretty much doomed there anyway :)
<pwnguin> Keybuk: if you really want a UI bug in gnome -- it assumes a keyboard!
<Keybuk> pwnguin: again, a valid bug
 * ogra wants sensoric gloves ... it looks good and you can make meaningful gestures in the air to steer your computer :)
<pwnguin> Keybuk: ive chatted a bit with the CellWriter author, apparently metacity only allows gnome-panel to set up struts?
<pitti> ogra: http://www.datahand.com/
<ogra> pitti, well, i thought of somethig that looks a bit more .... like ... bicycle gloves or so :)
<theunixgeek> How do I change the logo in the upper left (on the applications menu) to the GNOME foot?
<ogra> pitti, they dont look like you could easily wave them around :)
<ion_> Who wants to wave their hands around to control the computer?
<ogra> ion_, me :)
<pwnguin> i think the wii's pointed out the problems with that
<pwnguin> its hella tiring
<ogra> in a cape with a pointy hat :)
<pwnguin> i saw a video of a guy who set up a wiimote and an led array to record fingers waved in the air
<ogra> i think thats like bodybuilding ... or gardening ... its always tiring in the beginning ...
<ogra> if you do it all the time its healthier than typing sitting on a desk all the time :)
<pwnguin> ive heard of the marines using "hold your arms out level" as punishment
<ogra> pitti, hmm, no hal issues here
<pitti> ogra: maybe you didn't catch the latest hal yet
<ogra>  0.5.10-2ubuntu1
<pitti> yep, 2ubuntu2 enables PK
<ogra> ogra@laptop:~$ COLUMNS=100 dpkg -l policykit
<ogra> Kein Paket gefunden, das auf policykit passt.
<ogra> ah, yep
<lamont> slangasek: posix vs pthreads mutexes???
<slangasek> lamont: as names of configure options, yes :)
<slangasek> lamont: i.e., --enable-posixmutexes vs. --enable-pthreadsmutexes=yes; the latter is in your patch to db4.5 in Ubuntu, the former is what Debian is now using
<lamont> where is that showing up?
<lamont> package?
<slangasek> db4.5
<lamont> I don't think that was my doing... I'd ask doko.
<slangasek> hmm, you uploaded it :)
<slangasek> 4.5.20-5ubuntu2:   * enable NPTL across the board for linux
<lamont> ok.  NPTL changes --> if I did it, it was because someone told me to (as in doko, jbailey, et al.()
<slangasek> ok
<slangasek> doko: ping
<lamont> I do know that the switch to NPTL in ubuntu (1) is a precursor to debian eventually getting there (2) happened early in ubuntu because (a) we want it and (b) all of ubuntu architectures were ready for NPTL in edgy, and (3) is why hppa dropped out of ubuntu in edgy - it finally had working NPTL late in fiesty.
<lamont> not sure which, if any, architectures are still holding debian back from going there.
<slangasek> yeah, this was a fairly recent ubuntu change, db4.5 wasn't even around in etch
<StevenK> lamont: Could I impose on you on raise the build priority of helix-player 1.0.9-0ubuntu3?
<lamont> StevenK: arch?
<StevenK> lamont: All of them :-)
<lamont> StevenK: done.  you're at 900 now, so you still lose to all of main
<lamont> but beat all of universe
<lamont> have a nice day
<StevenK> lamont: Thanks. It's been waiting for 7 hours already, hopefully it won't be too much longer.
<ogra> woah, firefox 3 in hardy is evil if you have a self signed cert for our https site
<ogra> *younr
<ogra> gah
<ogra> *your
<lamont> i386 has 6 packages ahead of it
<lamont> ogra: what does it do?
<StevenK> lamont: For now :-)
<lamont> StevenK: I have a hard time justifying putting universe packages ahead of main...
<ogra> lamont, it doesnt offer any easy confirmation dialog anymore ... you have to dig into the guts of the config and manually add an exception
<lamont> that requires a more compelling argument.  bumping something to the head of universe just takes asking for it.
<lamont> ogra: neat
<lamont> glad I have my own CA that I use to sign such things... much simpler. :-)
<ogra> well, many people wont ... they will just self build a ssleay cert ... https apache in gutsy ia a pita anyway
<StevenK> lamont: It's fine, I can wait - I just didn't want to be waiting another 7 hours or more
<lamont> right
#ubuntu-devel 2007-11-21
<doko> slangasek, lamont: pong: do we care about db4.5 anymore?
<lamont> doko: it's more about the divergence from debian wrt shifting to NPTL
<lamont> and I expect that at least a little bit of universe will take a while to shift from db4.5
 * slangasek nods
<doko> lamont: I didn't activey change it
<slangasek> does openoffice.org-core have any special upgrade requirements for bdb?
<doko> no, it's just used for the help
<slangasek> that's the only reason I see not to kick db4.5 out of main; but then it should still get a sync or merge or whatnot
<doko> soo tightened deps should work
<slangasek> anyway, if we don't need divergence on the mutex configure option, db4.5 can be a sync
<slangasek> lamont, doko: ok, sorry for the bother; it turns out --enable-pthreadsmutexes isn't supported at all by db4.5 so was a total no-op, and Debian already DTRT with --enable-posixmutexes
<lamont> slangasek: heh
 * StevenK sighs at helix -0ubuntu3 failing on all arches for two different reasons
 * slangasek blahs, botching the subscription to bug #164227.  Can someone take ubuntu-main-sponsors off of there, since it looks like that wasn't required?
<ubotu> Launchpad bug 164227 in db4.5 "Please sync db4.5 4.5.20-11(main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/164227
<elmo> slangasek: you need someone from the team to do that
<StevenK> slangasek: Hold on, I can do it
<slangasek> elmo: sure; I assumed there'd be someone from the team on this channel :)
<StevenK> slangasek: Done.
<bddebian> You know what happens when you assume...
<azeem> ... StevenK executes!
<StevenK> bddebian: In this case, that's crap - u-m-s is a large team and this is the main development channel
<bddebian> It was a joke, sheesh :-)
 * Hobbsee waves
<zul> hey Hobbsee
<bddebian> Heya again Hobbsee :)
<Hobbsee> :)
<slangasek> huh, http://merges.ubuntu.com/main.html looks at experimental?
<Hobbsee> slangasek: for some packages
<Hobbsee> TheMuso: ping, please deal with gnome-speech.
<TheMuso> Hobbsee: I have done, and its in the sponsors queue.
<Hobbsee> TheMuso: ahhh, neat.  bug #?
<slangasek> Hobbsee: how is that determined?
<Hobbsee> slangasek: i think by bugging keybuk.
<slangasek> Hobbsee: e.g., diffutils experimental version is listed on there, but that's not what hardy is currently merged with...
<TheMuso> bug 162127
<ubotu> Launchpad bug 162127 in gnome-speech "Merge gnome-speech 0.4.16-2ubuntu1." [Undecided,New] https://launchpad.net/bugs/162127
<Hobbsee> right, libsvg done.
<dendrobates> Hobbsee: you have to be tired.
<Hobbsee> dendrobates: why in particular?
 * Hobbsee only got up around an hour and a half ago
<dendrobates> Hobbsee: you were up sooo late.
<Hobbsee> i know.
<Hobbsee> work's turned me somewhat of an insomniac, i'm afraid.
<dendrobates> Hobbsee: it must be nice to be young.  That would kill me.
<Hobbsee> heh :)
<bddebian> Young, who's young? :-)
 * Hobbsee was asleep for....7.5 hours or so...
<dendrobates> Hobbsee: not too bad, it seems like you were on irc just a few hours ago.
<Hobbsee> dendrobates: yeah,k i know
 * TheMuso applauds Hobbsee.
<TheMuso> Thats a good sleeping time length. :p
<Hobbsee> hehe
<Hobbsee> dendrobates: i dont deal well on <6.  <4 is particularly bad.
<Hobbsee> pity :)
 * RAOF prefers an number around 10.
<zul> im suspecting that Hobbsee is actually a zombie
<Hobbsee> dendrobates: besides, didn't you know that green aliens don't sleep?
<dendrobates> ha
<Hobbsee> except when they turn purple.
<zul> dendrobates: this is a more acurrate picture of Hobbsee http://www.rightblueeye.com/blog/wp-content/uploads/2007/06/zombie_bunny.jpg
<Hobbsee> *snort*
<dendrobates> arggh
<ajmitch> heh
 * LaserJock locks that away in the "Hobbsee" files
 * Hobbsee beats LaserJock
<Hobbsee> LaserJock: PONIEZ PLZ
<Hobbsee> looks more like mneptok to me, though
<ajmitch> Hobbsee: mneptok looks far healthier than that, I'm sure
<Hobbsee> ajmitch: i wouldn't bet on it...
<ajmitch> true
<ajmitch> the amount of time he spends on irc, can't be good for anyone
<bryce> mhr?
 * ajmitch joins in the request for more ponies
<StevenK> Ponies!
<ion_> Perhaps ShipIt could bundle a pony with each shipment or CDs.
<Hobbsee> ajmitch: the time he spends doing support cant be good for anyone :)
<Hobbsee> customer service for long periods of time == bad.
<ajmitch> he did have the advantage of a warm, fluffy shell of insanity to protect him
<Hobbsee> hehe
<Hobbsee> only works for so long, though.
 * Hobbsee wonders if banana lady as whinged to corporate yet.
<StevenK> Hah
 * StevenK holds you close
<Hobbsee> she probably has
<Hobbsee> i'll probalby hear about it sooner or later
<StevenK> Hum
<Hobbsee> utterly fabricated, of course
<ajmitch> and you won't care at all
<ajmitch> & you can go in there & laugh
<Hobbsee> nah, they won't call me in there.  they'll likely just tell my manager.
<slangasek> banana... lady?
<Hobbsee> bonus points to her if she fabricates it into a 3 page written complaint, though
<Hobbsee> slangasek: i had a nutter of a lady who was unhappy as she refused to read the signage, for the prices of bananas.
<Hobbsee> so called up to complain
<Hobbsee> apparently she couldn't understand the difference between which price referred to the prepack (hint, the one that says "each"), and the loose.
<ajmitch> that's pretty special :)
<Hobbsee> apparently having the branding on the prepack, and also on the sign, was not sufficient documentation.
<Hobbsee> sorry, i'm not giving her a refund because she doesn't like the way the world works :)
<Hobbsee> well, it to her for free.
<pwnguin> what exactly is a prepacked bananna?
<lamont> pwnguin: that's where you pack the bananna beforehand
<Hobbsee> and so the bundle of them is sealed in plastic
<Hobbsee> ajmitch: yes, i thought so.
<ion_> lamont: Yeah, to the yellow material called âbanana peelâ.
<lamont> lol
<lamont> so... how do I get upstart to use a new version of /etc/event.d/ttyS1?
<lamont> on gutsy
<StevenK> lamont: It should just deal, upstart uses inotify
<lamont> haven't seen the -n 3 that I added to the mgetty invocation yet...
<lamont> it's been 2 days, how much longer should it need?? :-)
<StevenK> lamont: Kill mgetty and have upstart respawn it?
<lamont> did that too
<StevenK> Wave your arms and beg Keybuk for help? :-)
<lamont> I expect that he's sleeping
<StevenK> Me too
<Hobbsee> phones are useful.
<lamont> StevenK: I expect that I could use the redmond solution
<lamont> Hobbsee: I'm _not_ going to call keybuk at 3AM
<StevenK> lamont: Yeah, that might fix it. :-)
<Hobbsee> lamont: surely you'd only do it when you were very well hidden, so you didnt' die. :)
<lamont> Hobbsee: I only call people at 2AM/3AM when I can justify it.
<Hobbsee> haha
 * Hobbsee turns her phone off at night, but apart from that, has a "no particular hours are bad to call" policy
<lamont> we knew someone who answered the phone after 10PM with "This better be good."
<Hobbsee> haha
 * Hobbsee gets the odd call at 1am or so
<Hobbsee> or midnight
<lamont> my call at 2AM one night went:  "This better be good."  "This is LaMont, I need to speak with $person." "do you know what time it is???"  "Yes." "Let me get her."
<Hobbsee> haha
<lamont> which is how I know that he really does answer the phone that way after 10PM
<StevenK> I have gotten a call at 3am local, and told the person calling, "This better be a real problem, or I will be eating your heart later today."
<StevenK> (It turns out it was, so they were lucky)
<Hobbsee> yes...i dont give out my home phone number precisely for this reason.
<StevenK> I was a sysadmin at the time, and I told people if $machine or $service call me, I don't care what time it is
<lamont> hrm... cdrom jacked up.  I guess I do get to reboot
<lamont> StevenK: yeah. same here, pretty much
<Hobbsee> StevenK: if you're getting paid, it's different.
<ScottK> My father had the same first and last name as another man in the same city when I was growing up.  This man had a LOT of female friends.  Some of which just had to talk to him in the middle of the night.  His number was unlisted, so my Dad got the calls.  My Mother did not appreciate cute young things calling for Gary in the middle of the night.
<Hobbsee> actually, i had a prank caller for a while.  so i started them calling back while i was interstate, which was aroudn 1am local.  muhahaha :)
<StevenK> ScottK: Maybe your father did. :-P
<ScottK> StevenK: He thought it was kind of funny.  She didn't see the humor.
 * ScottK used to get called in the middle of the night to make decisions about stuff.  I could never remember what I decided, so I always had to be sure to read the logs first thing in the morning to see if I'd been called and what I said.
<lamont> keescook: you still online?
<StevenK> ScottK: I used to tell people if they called me to fix stuff in the middle night, *they* could e-mail the systems team to say what the problem was, and what I did, because I usually wouldn't remember
<ScottK> StevenK: This was way back in ancient history when there was no e-mail at the facility involved.  It was only paper logbooks.
<lamont> ah. paper.
<lamont> and console hardcopy
<lamont> those were the day
<lamont> s
 * lamont reboots to get the CD out of his machine
<lamont> brb
<lamont> StevenK: yep.  redmond solution was a winner for upstart
<StevenK> Heh
<ScottK> When I was in the Navy, turning a system off/on again was often referred to as a "Raytheon reset" - Raytheon being a large, famous Defense contractor here.
<StevenK> I recognize the name Raytheon.
<StevenK> I have no idea why
<pwnguin> they make some pretty good misiles
<pwnguin> (they also sponsored my state Science Olympiad)
<lamont> StevenK: ever use shrink tubing?
<lamont> poly switches?
<StevenK> lamont: I've used heatshrink
<StevenK> That's kind of fun
<lamont> oh wait.  that's RayChem
<lamont>  /dev/md1             679749632 596355428  69586328  90% /home
<lamont> sigh
<lamont> I guess it might be time to do a little house cleaning
<StevenK> Shoulda used LVM
 * StevenK ducks
<lamont> nah - I just need to buy another sata controller and a couple drives, then reshape the array. :-)
<StevenK> Hrm. Is that gluck?
<lamont> that's my workstation
<StevenK> Cool. ~ 650G
<lamont>  /dev/cciss/c0d0p8    625344192 575931328  17647140  98% /home
<lamont> that's gluck
<StevenK> Heh, smaller, and fuller
<lamont> more users, too
<StevenK> And a Compaq hardware RAID controller
<lamont> yeah.  swraid has some advantages, and some disadvantages
<lamont> my machine claims to have 2 raid1 controllers
 * lamont -> bed
<spasticteapot> I downloaded Ubuntu Gutsy Beta, which worked pretty well.
<spasticteapot> However, I'm now in a total bugfest.
<spasticteapot> Are there any known bugs with not reinstalling when the release came out?
<ScottK> spasticteapot: Are you asking if upgrading from the Beta to the Final is known to cause problems?
<spasticteapot> Er, yes.
<ScottK> spasticteapot: I'm not aware of any significant regressions.
<ScottK> It's quite normal to not re-install, but just upgrade.
<ScottK> I've done it on more than one box.
<ScottK> No troubles here.
<spasticteapot> My keyboard brightness adjustment buttons don't work....the laptop regularly refuses to go into sleep mode.... laptop_mode does not engage automatically....and power use is abysmal.
<spasticteapot> I have an X40. This is a small laptop.
<jdong> do all the archive managers handle SRU proposed->updates copying or is that just pitti?
<spasticteapot> How the fnord am I pulling 13 watts running Abiword?
<jdong> spasticteapot: sleep mode, known bug unknown cause on Intel graphics + core*duo
<spasticteapot> Gronk.
<jdong> spasticteapot: laptop_mode does not engage because it sets aggressive options that may wear your hard drive prematurely
<spasticteapot> Er....
<spasticteapot> How, exactly, am I supposed to use my laptop as a laptop?
<spasticteapot> I get two hours of battery life! Maximum!
<jdong> spasticteapot:  power usage.... hmm, good question, I have a macbook myself and am looking answers to that
<pwnguin> spasticteapot: there was a fun internet war over laptop_mode parking the drive too much, i gather
<spasticteapot> I'm debating just selling the stupid thing, repairing my old ULV X40, and throwing in a CompactFlash hard drive.
<jdong> spasticteapot: what wattage were you expecting?
<jdong> out of curiousity
<jdong> 13W sounds typical for non-ULV core 2 duo type hardware
<spasticteapot> I know a fellow who managed to get his T41 down to 10w.
<RAOF> spasticteapot: Tried powertop?
<spasticteapot> Yes.
<jdong> if you spin down the hard drive that should get you 2W
<jdong> if you turn down wireless that should give you 1W
<spasticteapot> With wireless disabled AND laptop_mode enabled, I get 12w.
<ScottK> Removing tracker/strigii for Ubuntu/Kubuntu ought to help with battery life.
<spasticteapot> More like 14w without.
<spasticteapot> Tracker?
<pwnguin> a search indexer
<jdong> spasticteapot: enabling laptop_mode doesn't really save much power
<ScottK> And eater of CPU cycles and disk I/O
<pwnguin> like beagle / updatedb
<jdong> I'd say 11W is an extremely optimistic idle wattage for non-ULV core 2 duos
 * pwnguin pulls around 24 watts
<jdong> I can only reproduce that on my macbook on an idle kernel with no init process and lowest frequency state
<jdong> all modules unloaded except required to bring up an initramfs
<jdong> C3 99.9% 300-500ms residency
<jdong> that's what I'd consider to be an optimistic idle :)
 * RAOF also pulls in ~24W
<jdong> my macbook during normal use is 14.5-15W compiz running GNOME
<jdong> almost stock Ubuntu setup
<spasticteapot> Anyway to undervolt my CPU?
<spasticteapot> I know you can do it through Windows.
<jdong> I think there are kernel patches to do so
<jdong> Gentoo had the best documentation on that, you might wanna look at their wiki
<jdong> they have some really nice info about these kinds of power hacks
<pwnguin> note that gentoo wiki is not regulated by gentoo itself
<pwnguin> so please santiy check what you find there ;)
<jdong> right it's user contributed documentation
<pwnguin> more than that
<jdong> pwnguin: sanity check and undervolting don't go together
<pwnguin> its user contributed and not developer reviewed
<pwnguin> basically, gentoo wiki is its own thing with its own administration
<spasticteapot> I shoulda spent the extra few hundred bucks for an X60s
<spasticteapot> They said I'd get 3 hours for the X40 in the review...3.5 for the X60s.
<StevenK> With what battery?
<spasticteapot> One fellow I talked to was only getting four hours on an X60s with an eight-cell battery.
<spasticteapot> StevenK: Technically, six hours with the eight-cell.
<pwnguin> the x40s are quite old
<StevenK> I get over six with the eight cell on my X40
<pwnguin> hmm
<pwnguin> this graph is wierd
<pwnguin> according to gnome-power-monitor, i use between 21 an 6 watts
<spasticteapot> I had an X40.
<spasticteapot> Someone killed it.
<spasticteapot> Now I have this wretched X60, which I hate.
<spasticteapot> A lot.
<pwnguin> interesting
<pwnguin>   7.7% ( 10.0)             totem : do_nanosleep (hrtimer_wakeup)
<pwnguin> totem is not playing anything
<pwnguin> 10 times a second
<jdong> pwnguin: VLC does similar things on OS X for me, havne't tried in Linux
 * RAOF wishes 10 wakups/sec could be 7% of his total.
<pwnguin> well dont use nvidia ;)
<RAOF> Yeah.  Or x86-64.
<pwnguin> oh yea
<pwnguin> that'll be something to look forward to in the new kernel ;)
<StevenK> So it seems my X40 pulls 10W
<StevenK> (with wireless on)
<spasticteapot> How should I disable Tracker?
<spasticteapot> StevenK: I'm very tempted to trade you.
<pwnguin> apt-gte remove tracker ;)
<pwnguin> err i think its trackerd or soemthing
<StevenK> spasticteapot: It's my precious and not yours. :-)
<spasticteapot> I miss my X40.
<spasticteapot> Admittedly, the ability to run Compiz will be nice.
<pwnguin> tracker is it i think
<spasticteapot> If an when the stupid bums at Intel get off their asses and write me a wifi card driver.
<spasticteapot> Or, at least, one that works.
<RAOF> Tracker shouldn't kill battery life, at least in gutsy.
<RAOF> Or rather, not too hard.  It doesn't (shouldn't) index while on battery.
<spasticteapot> Well...lemme see.
<spasticteapot> Wow. 15.3 watts.
<spasticteapot> I hate this thing.
<spasticteapot> I wonder how much it will sell for on eBay....
<pwnguin> man
<pwnguin> im sitting at 16.0, and its better than ever :P
<spasticteapot> Yes, well...you have a MacBook.
<StevenK> Because selling a laptop because it draws too much power is sensibel
<pwnguin> no i dont
<StevenK> sensible
<pwnguin> i have a toshiba tablet
<spasticteapot> StevenK: Let me rephrase that: Selling a laptop because it won't get you through more than two consecutive classes is sensible.
<jdong> RAOF: tracker has an extremely negligble impact on battery life here
<ScottK> Maybe it's just the initial indexing.
<pwnguin> is the idea to replace updatedb with tracker?
<pwnguin> cuz honestly, i dont search my files that often, and updatedb is a pita
<jdong> I think I'm gonna build a ram distro of Gutsy for when I'm on the road
<jdong> spinning down the hard disk gets me from 15->13.5W
<jdong> the best improvement I've seen
<pwnguin> no, the best improvement is removing nvidia modules ;)
<spasticteapot> ?
<jdong> pwnguin: intel baby :)
<pwnguin> well
<pwnguin> that means nothing to me
<pwnguin>  24.1% ( 11.8)       <interrupt> : iwl3945
<spasticteapot> Hmm.
<pwnguin>  24.1% ( 11.8)       <interrupt> : iwl3945
<pwnguin> doh
<pwnguin> 66.6% (214.8)       <interrupt> : PS/2 keyboard/mouse/touchpad
<spasticteapot>   34.4% (116.8)       firefox-bin : schedule_timeout (process_timeout)
<spasticteapot>   17.6% ( 59.8)       <interrupt> : ohci1394, uhci_hcd:usb6, HDA Intel, iwl4965
<spasticteapot>   14.7% ( 49.8)       <interrupt> : extra timer interrupt
<pwnguin> wow
<pwnguin> what plugin is that?
<jdong> pwnguin: I bet flash video based ad
<pwnguin> hmm. even with adblock off on tomshardware its not that high, but i can see how that happens
<jdong> pwnguin: and firefox is noisy anyway :)
<DaSkreech> Hello
<Hobbsee_> hi DaSkreech
<DaSkreech> I would just like to know if the Live CD installer has any more steps to complete after it installs grub
<jdong> hello
<jdong> I think it just asks to reboot
<DaSkreech> So if that step fails and I reinstall grub from the Live Cd I should be ok?
<jdong> yeah
<jdong> i've had that happen several times
<DaSkreech> thank you :)
<jdong> sure thing :)
<jdong> long time no see, man :) I've drifted far from the Kubuntu world it seems
<DaSkreech> Kome to the Blue side!
<DaSkreech> I am your father
<jdong> :)
<DaSkreech> Well dark Blue
<DaSkreech> Purple sometimes....
<jdong> I'll stay with managing that torrent klient from your side and that's enough KDE for me to take in ;-)
<DaSkreech> :-)
<DaSkreech> I see you have the Hobbsee_ one sampling short trolls as well :)
<DaSkreech> stop stealing our citizens!
<jdong> haha you made her leave :)
<Hobbsee> heh
<jdong> oh the other one is still here
<DaSkreech> Ha ha :)
<ScottK> There is no escaping the longpointystick
<DaSkreech> LongPointyStick: Would you agree?
<jdong> DaSkreech: tell ya what, get your 3D right prism desktop by default and I'll use KDE for LTS :)
<LongPointyStick> indeed.  DOOOOOM!!!!!!!!!!!!!!!!!!
<StevenK> jdong: Isn't that 3D cubiod? :-P
<DaSkreech> jdong: You know we were told not to use KDE4 for LTS :-P
<DaSkreech> but if you wanna You can help us test it for hardy :)
<jdong> StevenK: it's not cuboid if you don't have 4 desktops :)
<StevenK> jdong: Hmph
<jdong> whee geometry!
<DaSkreech> People keep complaining it's not a cube cause you have two desktops by default
<jdong> DaSkreech: it's not even a cube with 4
<DaSkreech> it isn't?
<jdong> DaSkreech: nah length != width
<DaSkreech> silly widescreen laptops
<jdong> DaSkreech: it has 3 unique dimensions, making it a cuboid or rectangular prism
<jdong> DaSkreech: when desktops != 4, it can be generalized as a right prism
<DaSkreech> I got it to balance on the tip as a Pyramid which was fun
<jdong> *cough* triangular prism
<DaSkreech> but KDE4 ships in a Month! :)
<jdong> haha ok I'll stop being the geometry nazi tonight ;-)
<DaSkreech> jdong: I couldn't see through it so it was a pyramid
<DaSkreech> :-P
<jdong> DaSkreech: LOL
<DaSkreech> jdong: interested in running a KDE4 session ? For side testing?
<jdong> not currently, but definitely in the future :)
<DaSkreech> Like in a month? :)
<jdong> while we're talking about KDE, can someone triage the gutsy side of bug #163417, I really strongly think it should be handled as a -security matter
<ubotu> Launchpad bug 163417 in kdesudo "kdesudo+dolphin leads to command execution vulnerability" [Undecided,Fix released] https://launchpad.net/bugs/163417
<DaSkreech> I thought that was fixed earlier?
<DaSkreech> Could be wrong
<jdong> it was uploaded to Hardy
<DaSkreech> Whoot Obama wants ODF :)
<DaSkreech> I have no idea what that means
<saivann> Hi everybody, I would like to show some new specs about the high priority bug 53387 that has great chances to get it fixed, can-I talk to somebody about this?
<ubotu> Launchpad bug 53387 in wpasupplicant "Manual WPA networks doesn't connect at boot" [High,Confirmed] https://launchpad.net/bugs/53387
<saivann> The facts is that removing the file /etc/udev/rules.d/85-ifupdown.rules solve this problem. Since this file starts the network before init.d, this gives great clues
<StevenK> saivann: Then don't mark the device as auto in /etc/network/interfaces ?
<saivann> StevenK : The device is marked as auto in /etc/network/interfaces, if it's not, it will not automatically connect at boot
<StevenK> saivann: If it's not marked as auto then /etc/udev/rules.d/85-ifupdown.rules will leave it alone
<saivann> StevenK : But the final result will be the same, the network won't automatically connect at boot
<saivann> StevenK : Is there a way to add a exception in the /etc/udev/rules.d/85-ifupdown-rules to make it ignore all wireless devices?
<StevenK> I daresay there is, but I don't know it.
<saivann> Hum.. I want to make sure that this bug get fixed quickly since it affects a lot of ubuntu users and since we have pertinent informations on it
<saivann> StevenK : Do you know how and when WPA drivers are started by netbase?
<StevenK> saivann: Nope, I don't, sorry
<saivann> StevenK : Thanks for your help :)
<Hobbsee> asac: could probably help there
<saivann> Hobbsee : Asac knows this kind of problems?
<Hobbsee> he's the network manager guy
<Hobbsee> as for *why* you're setting up wpa manually now, i'm not sure.
<saivann> Hobbsee : It's the only way to get a Static IP adress on a WPA network
<Hobbsee> oh, right, yes.
<Hobbsee> forgot about the static IP
<saivann> Hobbsee : Not often used :) But often enough for a lot of people to report this problem
<saivann> Hobbsee : I think that asac isn't here at this hour right? When can-I talk with him?
<Hobbsee> hm, few hours i guess. not sure where he is.
<saivann> Hobbsee : Thanks, I'll wait.. even if it's 2:42 am here :P
<dholbach> good morning
<saivann> asac : When you're here, can-you ping me?
<dholbach> saivann: he's on holidays
<jdong> uh oh, it's morning for these people I only see at night
<jdong> *looks at clock*
<StevenK> Haha
<saivann> dholbach : Ho.. by holiday you mean that he's going to be absent for weeks?
<saivann> jdong : Same here :)
<dholbach> saivann: I think he's away for 2 weeks or something, but I don't know for sure
<jdong> now all I need to trigger bed is pitti signing on and me poking him about Azureus
<saivann> dholbach : Well thanks a lot for this information, I can now go to bed :)
<dholbach> saivann: sleep tight :)
<saivann> jdong : Thanks for all your great work on azureus!
<jdong> saivann: thank you, and thanks for combing through all the bug reports for me :)
<saivann> dholbach : hehe
<saivann> jdong : I'm a new bug triager, so it's my pleasure :)
<jdong> saivann: haha, the glamor of launchpad will soon wear off ;-)
<saivann> haha
<saivann> Well anyway, good night everyone
<jdong> likewise, this sleep pattern isn't good for me ;-)
<saivann> jdong : :D you can say good morning if it's more appropriate
<jdong> haha don't depress me like that, I've got a long day ahead of me tomorrow ;-)
<saivann> jdong : Own sorry :P Well that's depressing to sleep, I must force myself to sleep, so I must go right now before I stay here another hour
<jdong> ha, if I don't have this silly school thing during the day I think I'd be here 24/7 :D
<saivann> I can understand this :) @++
 * jdong checks e-mail and forums *one last time*
<StevenK> jdong: See you in an hour, then
<jdong> StevenK: haha fortunately all are empty :)
<StevenK> jdong: Heh
<pwnguin> you know, a thought just occurred to me
<pwnguin> surely someone's thought of an aalib compiz plugin
<StevenK> Oh, *TWITCH*
<StevenK> mplayer supports libaa, and libcaca
<pwnguin> yes, but what about fullscreen aalib'ing?
<StevenK> Fullscreen the movie, done
<pwnguin> i dont think you understand the point
<pwnguin> or rather, you're looking to hard for one
<pwnguin> an aalib compiz plugin doesn't fill some need by being used, it mainly works by merely _existing_
<\sh> moins
<MacSlow> v
<Hobbsee> u
<MacSlow> ups
<MacSlow> so much for Ctrl-v
<MacSlow> hi seb128
<lool> Morning seb128
<dholbach> hey lool, hey mvo, hey seb128
<mvo> dholbach!
 * Hobbsee waves to mvo
<seb128> Hi everybody
<Hobbsee> hey seb
 * mvo hugs Hobbsee
<seb128> hey Hobbsee
 * Hobbsee hugs mvo, and attempts not to drown in all the paper
 * Mithrandir throws Hobbsee a paper shredder and a life buoy
<Hobbsee> thanks Mithrandir!
<Hobbsee> Mithrandir: i'll need that for some of it, anyway
<cjwatson> jdong: FWIW, there are a few things ubiquity does after installing grub: installing extra packages (may be a no-op, depending), removing extra packages (definitely not a no-op - removes stuff like ubiquity itself), and copying logs
<seb128> StevenK: did you add some preinst magic for gimp? that's required otherwise dpkg will not replace the documentation symlinks (see hal for one example)
<m3ga> hi all. is heron stable enough to run yet?
<Mithrandir> m3ga: no.
<m3ga> problems?
<persia> m3ga: lots
<Mithrandir> m3ga: if you are asking whether it's stable enough to use yet, it's not stable enough for you.  It's in early development and stuff breaks and is fixed daily so people are expected to be able to recover their system from breakages.
<m3ga> ok, now is too early, but how do i prevent getting too late. I got gutsy about a month before release and there are about a dozen bug that affect me and were never fixed before release.
<m3ga> where is the sweet spot?
<Mithrandir> there's no magic point as to when you'll get your bugs fixed.  We have more bugs than we manage to fix
<persia> m3ga: Id you've a spare (non-production) machine, and want to test early, I'd suggest starting around Alpha 5 (just after feature freeze).  There's still lots of bugs then, but the base system is less likely to be changed on the fly.
<cjwatson> the sweet spot for getting your bugs fixed is a lot sweeter if you help to contribute the fixes :-)
<m3ga> persia: is there an estimated date for that?
<persia> m3ga: mid to late February
<m3ga> cjwatson: I have submitted bugs, with patches, that have been ignored (possibly because they were after release)
<cjwatson> m3ga: see https://wiki.ubuntu.com/HardyReleaseSchedule
<persia> m3ga: But, as cjwatson says, if you can track down bugs and causes in gutsy, and check against what changed in hardy, and submit solutions or pointers to patches (or even patches themselves), that significantly improves the chances that they will be fixed.
<cjwatson> patches submitted after release are certainly extremely unlikely to be applied in that release. The next one is a different story, of course.
<lifeless> cjwatson: what is the best way for those to be raised to the attention of a committer ?
<cjwatson> we do not change stable releases except for a very small number of cases
<cjwatson> lifeless: for stable releases? usually, not
<lifeless> cjwatson: for hardy;
<cjwatson> we are not yet at the stage when I would expect people to be trawling for patches
<cjwatson> developers are still engaged in merging changes from upstream
<lifeless> Sure. I mean, is there a tag that can be put on the bug? Or a status change?
<cjwatson> there's already a search for bugs with patches available, which I think should be sufficient
<persia> lifeless: the "patch" tag helps change patches into debdiffs, and debdiffs can be sent to the sponsor queues.
<cjwatson> (of course not every patch is suitable for immediate application)
<lifeless> Right, I was asking to refresh my mind and get info for m3ga. Thanks.
<cjwatson> I'm not sure I entirely believe the search for bugs with patches in all cases, mind - for instance bug 9006 has no patch attached, nor do its duplicates
<ubotu> Launchpad bug 9006 in grub-installer "system unbootable due to old BIOS" [Medium,Confirmed] https://launchpad.net/bugs/9006
<Keybuk> https://bugs.edge.launchpad.net/ubuntu/+source/grub-installer/+bug/9006/attachments/1133
<ubotu> Launchpad bug 9006 in grub-installer "system unbootable due to old BIOS" [Medium,Confirmed]
<Keybuk> ^ says it's a patch ;-)
<cjwatson> stretching the point a little, I feel
<cjwatson> thanks, at least that shows me how to remove the patch tag
<Keybuk> how so?  That's how the patch query works
<Keybuk> it shows you all the open bugs with things attached that mark themselves as patches
<m3ga> for me, dapper was the last good release, followed by feisty. for me, gutsy is almost as bad as edgy. with ubuntu the fine details of ubuntu-core are good, but I need a lot of other stuff around it and when that stuff breaks, i'm up the creek without a paddle. at least with debian testing, that stuff does get fixed, but with debian, the core stuff lacks the attention to detail i like with ubuntu.
<cjwatson> I mean that it was stretching the point for the submitter of that attachment to tag it as a patch
<Keybuk> oh, right
<Keybuk> yes
<Keybuk> that's very true
<Mirv> m3ga: generally, if your patches aren't being handled it's not that there wouldn't be interested to fix bugs, but that there are not enough people to handle everything. the easier you can do it for the maintainers, the better - ie. you would supply patches, get other users to test the patches and supply comments, check that you can generate packages with those patches, work on getting patches to Debian, too (from where they'll be merged to
<warp10> Hi all!
<Mirv> personally I like to fix things in Debian and then get them merged to Ubuntu, that way it benefits the most and is the least amount of work for Ubuntu developers
<m3ga> Mirv: i do find the debian process better (reportbug vs launchpad is the obvious one), but to fix bugs in debian I should be running debian.
<Mirv> m3ga: ah yes, my point was assuming one also has a Debian installation somewhere
<seb128_> m3ga: you know about apport right?
<m3ga> apport?
<seb128_> m3ga: ubuntu bug tool (what is used to submit crash bugs, etc)
<m3ga> ok found apport. not really for me, i'm much better off with gdb and valgrind
<m3ga> i'm a developer, i can dig into code and fix stuff
 * seb128 kicks xchat-gnome
<seb128> m3ga: just mentioning because of your comment about reportbug against launchpad
<cjwatson> indeed, apport ships a tool called 'ubuntu-bug' ...
<m3ga> cjwatson: is ubuntu-bug anything like debian's reportbug?
<seb128> m3ga: it does send useful informations to launchpad (version of packages installed, architecture, etc)
<cjwatson> it does not share code. it fulfils much of the same function
<mvo> jdong: hello! I want to do some backports with the latest compiz from hardy to gutsy-backports. should I talk to the backports team first or can I just go ahead and ask the archive-amdins for  it myself?
<TheMuso> c
<TheMuso> ugh wrong tab
<m3ga> cjwatson: i just played with ubuntu-bug. it does a small part of what debian's reportbug does, but doesn't allow reporting of bugs like https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/163704 or https://bugs.launchpad.net/ubuntu/+source/usbutils/+bug/159189
<ubotu> Launchpad bug 163704 in cupsys "'cups-config --libs' gives spurious output" [Undecided,New]
<cjwatson> m3ga: -> pitti
<cjwatson> (when he's around)
<m3ga> i've met pitti, but what am i supposed to see him about?
<cjwatson> m3ga: he's the apport developer
<dholbach> and he kicks ass
<m3ga> not mine i hope ;-)
<m3ga> so, does apport run outside gnome/kde? if so how? there's no man page :-(
<seb128_> m3ga: there is an apport-cli
<seb128_> m3ga: and it has a manpage
<seb128_> man apport-cli
<seb128_> m3ga: https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/164249
<ubotu> Launchpad bug 164249 in gnome-utils "Mozilla crashes" [Undecided,Invalid]
<seb128_> that's an example of bug sent using apport
<seb128_> m3ga: what does reportbug do in your opinion that apport doesn't?
<seb128_> hey coNP[uni]
<coNP[uni]> hey seb128
<dholbach> hey coNP[uni]
<coNP[uni]> heya dholbach
<m3ga> ok looking at apport-cli manpage now. that seems to cover most of what reportbug does.
<Hobbsee> mvo: jdong certainly wants to backport compiz
<mvo> Hobbsee: ok, that is all cool then
<m3ga> seb128: 164249 is not a particularly good bug report :-)
<m3ga> and i have a program that crashes, how do I make it generate a .crash file?
<StevenK> seb128_: I didn't remove the preinst magic, since I thought doko added it.
<seb128_> StevenK: ok, it was already there
<seb128_> StevenK: for quite some packages he did symlink the directories from debian/rules
<seb128_> and the symlink are not replaced with the real directories on upgrade
<StevenK> seb128_: Yeah, I think doko learnt that lesson. :-)
<StevenK> m3ga: Hey!
<StevenK> m3ga: I didn't know you ran Ubuntu. :-)
<doko> StevenK: there's nothing to learn; just keep the preinst stuff where you like it.
<seb128_> m3ga: no, but that was the first example in my box with apport informations
<StevenK> doko: Actually, maybe cdbs should do the preinst magic
<m3ga> StevenK: long time no see/hear/chat!
 * Hobbsee wonders when we get a new kernel.
<StevenK> m3ga: Indeed!
<m3ga> been running ubuntu for about 2 years, debian before that
<seb128_> m3ga: you don't do anything, the crash should be written in /var/crash, just double click on it with nautilus to send the bug (or use the apport command line on the crash)
<StevenK> m3ga: I knew you were a Debian bloke, didn't know about Ubuntu
<StevenK> m3ga: I became an Ubuntu member about 2 years ago. :-)
<mpt> StevenK!
<StevenK> mpt!
<mpt> How's HardyAboutUbuntu?
<StevenK> mpt: So, what are we going to do about this spec?
 * StevenK grins
<m3ga> using it at work, basically building an ubuntu derived distro for our embedded boxes
<StevenK> m3ga: I'm using Ubuntu at work. :-) I started working for Canonical about seven weeks ago.
<m3ga> congrats!
<StevenK> m3ga: Thanks. :-)
<mpt> StevenK, I propose simplifying it to something you have time to implement for 7.10
<m3ga> mine is www.bcode.com
<Fujitsu> mpt: That's rather time-efficient.
<Fujitsu> Canonical breaking new ground, as usual :P
<StevenK> mpt: I saw that edit to the wiki page, what do you have in mind?
<StevenK> Fujitsu: Shush you
<mpt> StevenK, the original design, in GTK and Qt versions? :-)
<StevenK> Heh
<StevenK> Keybuk: Ping
 * StevenK checks if he wins at gimp
<StevenK> seb128_: Did you see my report?
<seb128_> StevenK: yes ;-)
 * seb128_ hugs StevenK
 * StevenK grins and hugs seb128_ back
<seb128_> StevenK: you didn't do the preinst thing though, I just looked
<StevenK> Hrm.
<seb128_> StevenK: http://paste.ubuntu.com/2125/
<seb128_> StevenK: you need something similar to that
<StevenK> Yeah, that requires knowing what packages were changed.
<seb128_> StevenK: gimp and gimp-python
<seb128_> those are the ones symlinked in gutsy
 * StevenK sighs, wanting dpkg -I to take multiple .deb arguments
<seb128_> oh, maybe some other ones as well
<seb128_> those are the ones installed on my laptop in fact
<seb128_> likely most of the binaries
<StevenK> Drat, CDBS should do it for me!
<seb128_> there is very few packages b0rked by doko
 * thom guffaws
<StevenK> (Since CDBS is the one that does the symlinking)
<seb128_> but you have a point
<Hobbsee> then fix cdbs at your peril :P
<seb128_> I had to add like 15 preinst to evolution-data-server
<StevenK> seb128_: Okay, so I should I fix CDBS, and then re-upload a rebuild of gimp?
<seb128_> StevenK: cdbs does the symlinking, the preinst is to workaround what doko broke in gutsy
<StevenK> thom: Shush you
<seb128_> StevenK: how do you want to fix that in cdbs?
<StevenK> Actually, it's hard to do it in CDBS, now that I think about it
<seb128_> StevenK: you want to add a similar preinst to every single package in the archive when it's required only for like 10 packages?
<seb128_> I think we should just fix those manually
 * StevenK nods.
<Keybuk> StevenK: gnip
<seb128_> you likely need a preinst by binary
<StevenK> seb128_: Likely, I'm just going to see what doko did
<StevenK> Keybuk: Can you read backscroll - the conversation between me and mpt about HardyAboutUbuntu?
<seb128_> he basically symlinked all the /usr/share/doc/binaries to /usr/share/doc/one-binary
<seb128_> and dpkg preserves the symlink on upgrade now
<Keybuk> StevenK: I have no backscroll
<\sh> keescook, jdstrand : bug #164007 ready for review, thx
<ubotu> Launchpad bug 164007 in net-snmp "[net-snmp] remote Denial of Service vulnerability" [Undecided,In progress] https://launchpad.net/bugs/164007
<StevenK> Keybuk: Oh, hang a sec.
<StevenK> seb128_: Oh, I see! I was too overzealous with my culling of debian/rules. :-(
<seb128_> StevenK: well, you can drop the debian/rules changes
<lool> seb128_: Using "gdm-new" will probably look weird when we have a new new; perhaps "gdm-snapshot"?  I proposed exactly this during the UDS session, but people seemed to prefer uploading the gdm package itself
<seb128_> StevenK: but now cdbs symlink individual files and not the directories so you need to remove the directories symlink in the preinst so the new version can install its real directory and the symlinks there
<seb128_> lool: new new?
<Keybuk> Riddell: shouldn't KDE 4.0 RC1 be "Kalamity" ? ;)
<StevenK> seb128_: ... I can?
<seb128_> StevenK: you need too
<lool> seb128_: using the name "new" looks bad after a while
<seb128_> StevenK: the debian/rules was doing directory symlink, now we have real directories and files symlinking
<StevenK> seb128_: Right. So the preinst hacking needs to stay, but I now I remove the symlink and mkdir
<Riddell> Keybuk: the 4.0 codenames have a deliberate policy of avoiding forced Ks, something to which I entirely approve
<seb128_> lool: the idea was to not keep it a while, but I'm fine with snapshot which is the standard naming for such thing anyway, thanks for the comment
<seb128_> StevenK: yes, cdbs does everything for you but removing the previous symlink
<seb128_> lool: I was not for having a different package because I was under the impression that the new gdm was testable which is not really true at the moment
<seb128_> lool: you can't even select the language and session, there is no gdmflexiserver, no gdmsetup, etc
<StevenK> seb128_: Right. Give me a few seconds, and I'll belt with a debdiff
<lool> seb128_: Right; I can only be happy that you meet my original proposal :)
<StevenK> Keybuk: Relevant bits at http://paste.ubuntu.com/2126/
<seb128_> lool: happy that new gdm sucks?
<seb128_> lool: I would be happy if it was usuable rather
 * StevenK ponders how to fix his webserver
<lool> seb128_: Happy with deciding to package it as a separate package as I really believe it's not ready to replace the regular gdm either
<lool> But then I was mostly alone in this position during the session
<Keybuk> StevenK: err, riiight?
<Keybuk> I don't see why you ping'd me though
<StevenK> Keybuk: Because we spent like an hour discussing this, and now HardyAboutUbuntu looks suspiciously like AboutUbuntuRevisited
<Keybuk> StevenK: except that we changed it to have a summary of your hardware and be "about your computer"
<Keybuk> and not "about ubuntu"
<StevenK> Keybuk: But mpt's point is that seems too complicated for an about dialog.
<Keybuk> why?
<Keybuk> it depends what the purpose of the dialog is, no?
<StevenK> mpt: Come back :-)
<seb128__> re
<Keybuk> it comes back to use cases
<seb128__> my dsl linux sucks today
<seb128__> lool: I was saying
<StevenK> Keybuk: Mmm
<seb128__> <seb128_> lool: happy that new gdm sucks?
<seb128__>  lool: I would be happy if it was usuable rather
<Keybuk> the use case we discussed in the meeting was "answering the most common questions about the computer"
<StevenK> seb128_: Your DSL linux?
<lool> seb128__: I was clarifying that I'm not happy that it sucks...  Just happy that others come to realize it does suck ATM
<seb128> StevenK: s/linux//
<StevenK> Keybuk: Right, which the current specs deals with by showing ...
<seb128> lool: nobody played with it at UDS so we were not discussing the current state
<seb128> lool: can't have an opinion on what you didn't try
<StevenK> seb128: http://people.ubuntu.com/~stevenk/gimp_2.4.1-1ubuntu2.debdiff
<lool> seb128: People seemed to have a strong opinion on basing on it
<seb128> lool: desrt from an upstream point of view had one, yes
<seb128> StevenK: why do you generate the preinsts from debian/rules rather than adding normal .preinsts?
<Keybuk> StevenK: I have a phone call now
<Keybuk> I'm not sure I understand the objection to the spec I'm afraid
<StevenK> Keybuk: Let me reclarify with mpt
<Keybuk> either we have an "About Ubuntu" dialog which just says "Ubuntu 7.10"
<lool> He wasn't alone in pushing for the new gdm; people are seduced by its new architectures which is nicer and more versatile but disregarded its stability
<lool> (or functionality)
<seb128> StevenK: I'm not sure I like have a "rm -rf" in a preinst, especially that's not required to remove a symlink
<Keybuk> or we have "About your Computer" which helps you answer common questions (and one of the incidental details there is Ubuntu 7.10)
<Keybuk> we discussed the latter in the BOF
<seb128> lool: not really, we said that if the new one was usuable we should try pushing for it
 * StevenK nods
<StevenK> seb128: Right, let me rip that apart again
<seb128> lool: we did pronounce opinions on whether it was or not since we didn't try it
<seb128> lool: what came out of the discussion was "package new version quickly, look at it, and revert at feature freeze if that's not satisfactory"
<Keybuk> (my personal opinion is that "About Ubuntu" is entirely useless; if all we do is display the lsb info, we can almost certainly drop it)
<lool> seb128: Yes; and the plan was to replace the package in the archive with a 2.20.x+really-2.21 version; I do recall that
<seb128> lool: right, *if the current version was good enough for hardy testing*, which is the best way to get testing
<seb128> lool: I still plan to do that when it'll allow to select a language and session
<lool> Too bad nobody took notes during the discussions
<seb128> we likely have notes on gooby and wiki no?
<seb128> anyway my understanding was that we want to get as much testing as possible
<lool> The wiki doesn't mention the packaging plans or the security review
<seb128> and the way to get that is to update in new version in hardy as soon as we consider it ready to been pushed to unstable users
<seb128> s/in/to the
<StevenK> seb128: debdiff updated.
 * Hobbsee waves to mdz_
<seb128> StevenK: I like the http://paste.ubuntu.com/2125/ variant better but yours should work too, no need to mkdir though, the packages installed files to this directory so it'll be created automatically
<seb128> s/installed/install
<StevenK> seb128: Oh right, so do it in just gimp.preinst?
<StevenK> Geez I'm slow tonight
<xhaker> StevenK, can I decide to start merging, and subscribe sponsors teams?
<StevenK> xhaker: Start merging what?
<xhaker> i'm looking for instructions on merges procedures
<seb128> StevenK: no, by binary, the hal way or listing several package is wrong because you don't have guarantee on the order I think
<StevenK> seb128: So that snippet is in each preinst?
<seb128> StevenK: I would say remove the mkdir and add a || true to your version and that's alright
<seb128> we don't want to fail the install if the rm doesn't work
<seb128> maybe rm -f symlink too
<StevenK> seb128: Er, read the if link
<StevenK> && [ -L /usr/share/doc/gimp-dbg ]
<seb128> StevenK: right, I did read this one
<seb128> just remove the mkdir then ;-)
<StevenK> seb128: Right
<xhaker> StevenK, universe packages... i don't know.. whatever i can
<StevenK> seb128: Let me just give you the debdiff again so we can be certain.
<seb128> ok
<StevenK> xhaker: You want to ask in #ubuntu-motu
<StevenK> seb128: debdiff updated.
<StevenK> At least I don't need to upload a 25Mb tarball.
<seb128> StevenK: that version looks good now ;-)
<StevenK> seb128: Great! I'll upload it now.
<Mez> how do I get something not to show in the autoremove list ?
<seb128> StevenK: thanks
<seb128> Mez: sudo apt-get install it?
<Mez> seb128, it's installed, but it shows up saying
<Mez> The following packages were automatically installed and are no longer required:
<seb128> Mez: --reinstall maybe then
<Mez> I dont want to accidentally remove it
<Mez> (It's iptables)
<seb128> mvo: ^
<mvo> Mez: apt-get install packagename
<mvo> Mez: that will mark it explicitely installed
<mvo> Mez: what package is it?
<seb128> mvo: even if it's already installed?
 * Mez shrugs - I did a --reinstall and that worked...
<mvo> seb128: yes
<Mez> mvo - iptables
<seb128> mvo: too to know
<seb128> mvo: good to know
<mvo> Mez: interessting, its a rdepends of ubuntu-standard, is that a machine that got upgraded all the way back from edgy?
<Mez> er, I believe it was a fresh feisty install
<Mez> might have been an edgy install - but I doubt it
<mvo> Mez: hm, iptables should be marked as manual install in this case. odd
<Mez> mvo, is there a way I can check if I upgraded it ?
<Mez> this was a pretty fresh server actually.. only a month old..
<mvo> Mez: I can't think of a easy way to check other than checking /var/log/dist-upgrade
<Mez> no such file
<mvo> Mez: ok
<Mez> mvo, checking with my server guy, he'll tell me how it was provisioned
<Mez> I have a feeling it wasnt a default install
<mvo> Mez: thanks, that would explain it :)
<Mez> I think he too a pbuild and played with that ;)
<mvo> heh :)
<Mez> so probably built using essential stuff only
<StevenK> seb128: Uploaded. Bloody gimp's 7Mb .diff.gz :-)
<Amaranth> StevenK: holy crap, what's in there?
<Hobbsee> Amaranth: you shouldn't need to ask.
<Hobbsee> Amaranth: crack, and misspellings.
<StevenK> Amaranth: Uncompressed, it's 38Mb, which is larger than the tarball
<StevenK> Amaranth: ~ 70% is translations
<Amaranth> i thought we stripped those
<emgent> keescook, hi :)
<StevenK> Amaranth: From the binary, yes
<mvo> doko: is pycentral maintained in bzr? I would like to change it so that it does not use /usr/bin/dpkg-querry but the dpkg-querry that is in the PATH. I'm happy to pass a special environment like DPKG_QUERRY too if you prefer that. the reason is that during dapper->hardy we will use a private dpkg that supports triggers and pycentral may be called before /usr/bin/dpkg-querry gets updated with the new dpkg - this would rsult in failures because
<mvo>  dpkg does not understand the new trigger keywords yet
<fabbione> that sounds so scary
<doko> mvo: either that, or just read /var/lib/dpkg/info/*.files directly (using an environment variable)
 * Hobbsee attacks fabbione with a herring
 * fabbione waves his 20T Thor Hammer in front of Hobbsee
<mvo> doko: I don't mind either way, just let me know how you want the change from me. just uploaded as a new package or in a bzr repository?
<Hobbsee> fabbione: you need longer arms.
<fabbione> Hobbsee: buh
 * fabbione heads offline
<doko> mvo: just upload, and maybe change it (make that conditional on an env var):             #lines = [s[:-1] for s in file('/var/lib/dpkg/info/%s.list' % self.name).readlines()]
<doko>             cmd = ['/usr/bin/dpkg-query', '-L', self.name]
<doko> should be faster anyway
<mvo> doko: thanks! that sounds good. I will do that after lunch
<\sh> keescook, jdstrand : bug #149616 ready for review
<ubotu> Launchpad bug 149616 in ruby1.8 "Net::HTTPS Vulnerability" [Undecided,In progress] https://launchpad.net/bugs/149616
<Hobbsee> TheMuso: erm, did i ever upload gnome-speech for yoU?  if i didn't, remind me tomorrow
<cjwatson> oh, WOW, debmany(1) is cool [debian-goodies package]
<cjwatson> why did I not think of doing that?
<thom> cjwatson: read man pages from unextracted debs? cute
<cjwatson> unextracted, or installed, or go and download them from the archive
<cjwatson> in general, "show me a list of the man pages in this package and let me read them conveniently"
<thom> oh wow
<thom> the description doesn't do it justice then
<Le-Chuck_ITA> Hi there, can someone take a look at https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/132583
<ubotu> Launchpad bug 132583 in openoffice.org "python-uno can't be imported" [Low,Confirmed]
<Le-Chuck_ITA> it's milestoned for hardy
<Le-Chuck_ITA> but there's a one-line fix, and gutsy has been released one month ago
<Le-Chuck_ITA> I find it unbearable that we ship buggy software, when we know the fix and that's trivial to upload
<Le-Chuck_ITA> expecially because I am actively pushing ubuntu on an institutional server where I will produce a package which uses python-uno
<seb128> Le-Chuck_ITA: that doesn't look like something high importance on a normal installation
<seb128> Le-Chuck_ITA: you are welcome to work on a SRU
<Le-Chuck_ITA> ok, thanks, that can be my next move but I will have to re-learn lots of burocracy when a developer can just upload the fixed package
<Le-Chuck_ITA> I don't see why I should waste my energy doing that, even though I did it in the past and can do it again
<seb128> Le-Chuck_ITA: there is no such thing as "can just upload" to stable
<persia> Le-Chuck_ITA: The developers follow the same processes as anyone else in order to get a patch applied to a release.  it's not easy on purpose.
<seb128> Le-Chuck_ITA: any maintainer need to follow the SRU process to get things to stable updates
<Le-Chuck_ITA> ok
<Le-Chuck_ITA> I didn't know
<Le-Chuck_ITA> in any case, the package may have little importance, but the fix is vital for the package itself
<Le-Chuck_ITA> it's an ld.so.conf error
<Le-Chuck_ITA> seb128: I am not even a MOTU, do you think I will get the same chances as an ubuntu developer to see my SRU go on? It's not polemic, I just have to decide if it's worth
<seb128> Le-Chuck_ITA: attach a debdiff to the bug and let somebody do the official SRU
<Hobbsee> Le-Chuck_ITA: the sru's get blocked because people dont find testers.
<cjwatson> SRUs for openoffice.org are a rather big deal
<Hobbsee> the rest of it's not so hard
<cjwatson> we prefer to stack up fixes there, since the download is so big
<Le-Chuck_ITA> Come on, it's an added path to ld.so.conf
<Le-Chuck_ITA> ah ok
<Le-Chuck_ITA> I misunderstood you
<cjwatson> I dropped off the network for a moment, so perhaps I missed a bit
<Hobbsee> cjwatson: image change to non-branded form, anyone?
<cjwatson> Hobbsee: ... which won't go into -updates until there's something to stack it with
<Le-Chuck_ITA> ok so i will try to provide a debdiff, I repeat point is that I want to push ubuntu on a server, but I can't do that and then require a patch to the default install, because they would say it doesn't look serious
<Hobbsee> cjwatson: oh, it's not even in -updates? right.
<Hobbsee> cjwatson: i upgraded from gutsy a long time ago :)
<Hobbsee> stable releases are boring, and all that.
<cjwatson> Le-Chuck_ITA: for large packages, it definitely requires signoff from the main responsible developer
<cjwatson> in your case, it's not obvious to me why you can't just set LD_LIBRARY_PATH locally as a workaround
<Le-Chuck_ITA> just a moment, cjwatson: the fix should be done in python-uno
<cjwatson> that doesn't require a patch to the default install
<cjwatson> $ apt-cache showsrc python-uno | grep Package:
<cjwatson> Package: openoffice.org
<Le-Chuck_ITA> ah ok I surrender on this :) However, I don't want to write "if DISTRO==ubuntu then LD_LIBRARY_PATH+=" ecc ecc in my code
<cjwatson> the unit of changes to Ubuntu is source packages; you can't change just python-uno without uploading the whole of openoffice.org
<Le-Chuck_ITA> ok
<Le-Chuck_ITA> I can eventually provide an ubuntu package with the missing ld.so.conf.d
<cjwatson> it seems to me that it would be preferable to set the path to the OOo libraries in the uno module rather than adding an ld.so.conf.d file
<cjwatson> (the latter would affect *all* binaries, and probably slow down all library lookups)
<cjwatson> (just by a little bit of course, but still)
<cjwatson> however, calc should make that decision
<persia> Le-Chuck_ITA: Please submit a change for openoffice.org.  It may take a bit to get in, but in the worst case, it will be in for hardy, and be useful to all clients of python-uno
<cjwatson> (the diff is probably fairly trivial, so I doubt submitting one will make a huge difference)
<Le-Chuck_ITA> persia: now I will have to wait on the decision about using ld.so.conf.d or setting the path in python scripts
<Le-Chuck_ITA> and I agreed with cjwatson in principle
<Le-Chuck_ITA> if the diff is trivial the problem of a developer won't be having a debdiff
<Le-Chuck_ITA> but finding time to take a look at the bug
<Le-Chuck_ITA> In any case I bothered you all a little more than I wanted to :) I just hope to see that fix in gutsy
<cjwatson> not that I want to discourage people from contributing of course; just to point out that the world doesn't revolve around diffs :-)
<persia> cjwatson: True.  My experience has just been that diffs often demonstrate willingness to help fix or test things, but I'm not the person making the oo.o decision :)
<emgent> keescook, ping
<Le-Chuck_ITA> bye all
<mvo> doko: fyi: http://paste.ubuntu.com/2132/ if you are happy with it, I will upload
<doko> mvo: QUERRY? double R ?
<mvo> doko: thanks! fixing this now
 * mvo blushes
<soren> seb128: you doing source new today?
<mvo> or syncs?
<seb128> some
<seb128> I'll not likely do everything
<seb128> anything you would like to get?
<mvo> I have some pending syncs, let me dig out the names
<seb128> mvo: if they are filled I'll do them
<seb128> mvo: I do syncs almost daily ;-)
<Hobbsee> seb128: sync the world plz.
<seb128> source NEW is an another issue
<seb128> Hobbsee: already done this morning
<mvo> seb128: they are filed
<seb128> I do that almost daily too ;-)
<Hobbsee> seb128: there are probably more people there now, though :)
<seb128> mvo: ok, will do them then, no need to bother
<Hobbsee> seb128: sync the universe too, plz.
<mvo> thanks seb128
<soren> seb128: They're not particularly urgent. If I just know that you probably won't get around to it today, I won't be twiddling my thumbs waiting for it. :)
<soren> seb128: It's virtinst and virt-viewer, if you feel like doing them anyway :)
<seb128> soren: will have a look later
<pitti> Hello
<Hobbsee> hiya pitti!
<warp10> Hi pitti!
<pitti> hi warp10
<LaserJock> pitti: quick question about that gcompris .pot, I'm generating it, but it doesn't get installed to any .deb, is that necessary?
<ganeshhegde> in appearance->visual effects  its none...if i click on normal it says composite extension is not available...what it mean?in ubuntu 7.10
<dholbach> LaserJock: it's not necessary to be in the .deb
<dholbach> LaserJock: as long as it's in the built source tree, that's fine
<LaserJock> dholbach: ah, ok
<pitti> LaserJock: what dholbach said (sorry, missed your ping)
<jdong> mvo: if you haven't already, file bug reports in product gutsy-backports, and we shall take a look. I think Compiz is a great Backports candidate :)
<carlos> pitti: ping about language pack update for Gutsy, did you have time to start the process?
<pitti> carlos: I'd like to do that with Arne
<pitti> no time yesterday, but I should be able to start that today
<carlos> ok, thank you
<mvo> jdong: I haven't filed a bug yet, my plan was to just bribe some of the archive-admins to get a backport build going. but I'm fine with filing a bug too (I want to get it done somewhat quick so that we can start pushing compiz into hardy that will be no longer backportable)
<jdong> mvo: the archive admins typically like a backport request ticket they can close when pushing a backport
<ganeshhegde>  I hav ubuntu 7.10 whith desktop effects working on xgl...how to install compiz fusion? graphics card ati radeon x200
<jdong> mvo: but if you can find an admin to shortcut the process I'm all up for it :)
<jdong> ganeshhegde: -> #ubuntu; this is not a support channel
<mvo> jdong: thanks :) I see what I can do
<pitti> mvo: I want a written statement from you that this won't break gutsy, in triplicate, signed with your blood, and a beer as bribe :)
<pitti> mvo: but I also prefer a bug just to have some papertrail
<jdong> :D
 * pitti hugs mvo
<mvo> heh :)
<jdong> pitti: I think bug 57875 is ready to copy from backports to updates. So far I've received no signs that the backports is any regression from the countless positive votes on the prior testing package
<ubotu> Launchpad bug 57875 in azureus "Azureus hangs or crashes showing splash screen at start" [High,Fix released] https://launchpad.net/bugs/57875
<pitti> jdong: I agree
<jdong> pitti: the one regression report towards the end of the bug seems to be more of a problem with that one user's system setup; it's not happened for anyone else
<pitti> carlos: gutsy-updates packages are building
<carlos> pitti: ok, cool
<pitti> I'll wait until the PPA has binaries, then we copy them to -proposed, and send out a call for testing
<carlos> pitti: ok, thank you
<pitti> jdong: *bzzt*, it's in -updates, bug updated
<jdong> pitti: sweet. Thanks so much for you help through this 2-year bug squash! :D
<pitti> you're welcome, thanks to you for enduring it
<jdong> anything for our users, right? :)
 * \sh needs a faster computer for mono :(
<ogra> take two that can get you stereo then :)
<\sh> ogra, good idea...working on two computers at the same time...no..bad idea, I need two more arms for that ,-)
 * Keybuk prepares to reboot into hardy
<Keybuk> cool, nobody screamed "WAIT!" :p
<seb128> Keybuk: way should we do that, no reason to not share the breakage fun with you ;-)
<Keybuk> to paraphrase SteveA ... "because I have changelogs.ubuntu.com, and I can fire people" <g>
<seb128> (s/way/why, I should learn to type correctly or read what I type rather ;-)
<mathiaz> slangasek: are you planning a new samba upload in debian in the next few days ?
<slangasek> mathiaz: 3.0.27a, sure
<mathiaz> slangasek: ok. So there is no point starting working on a merge
 * dholbach hugs soren :)
 * soren hugs dholbach back :)
<\sh> keescook, jdstrand : bug #162826 ready for review
<ubotu> Launchpad bug 162826 in mono "[Mono] Buffer overflow in Mono 1.2.5.1 and earlier" [Undecided,In progress] https://launchpad.net/bugs/162826
<lool> bryce: I subscribed you to bug #163850; it renders the touchscreen on Q1 reference hardware unusable and has no trivial solution; if you know how to write an evdev config from the /proc bits, perhaps we can work on this, or we could check whether input axis scaling could be readded in xorg-server; some hints on the path to follow would be appreciated :)
<ubotu> Launchpad bug 163850 in xf86-input-evtouch "Uncalibrated and can't calibrate with 0.8.7-2 on Samsung Q1 Ultra" [Undecided,New] https://launchpad.net/bugs/163850
<tjaalton> lool: I subscribed ubuntu-x to evtouch bugmail, good catch :)
<lool> tjaalton: TY
<tjaalton> lool: does evdev support those devices?
<\sh> so..time to go home...
<mathiaz> slangasek: BTW where is the samba 3.2 package in Debian ? in experimental ?
<slangasek> yes
<lool> tjaalton: I don't know, but the evdev syntax seemed to be generic enough to allow this
<mathiaz> slangasek: because merges.ubuntu.com lists 3.2 as debian version.
<lool> tjaalton: Can't tell for sure
<slangasek> Keybuk: so Hobbsee was saying that MoM looks at Debian experimental selectively, is that right?
<tjaalton> lool: ok, that would be cool
<Keybuk> slangasek: err....
<Keybuk> slangasek: how about you tell me what you want, and I'll tell you whether it can or can't do that :)
<slangasek> Keybuk: it's in general not obvious to me why we would want mom to list experimental-only merges as outstanding, and e.g. for samba we wouldn't want to merge from there
<Keybuk> it doesn't list experimental-merges as outstanding
<slangasek> oh
<slangasek> it just gets the wrong version for "Debian version"?
<Keybuk> no
<Keybuk> not that I'm aware of
<slangasek> 3.0.26a-1ubuntu2 3.2.0~pre1-1 3.0.26a-1
<slangasek> ^^ samba from http://merges.ubuntu.com/main.html, the middle number is the version in experimental
<slangasek> I had another example which I can dig up if it's helpful, but I've lost track of it in the list at the mo
<Keybuk> that's odd
<Keybuk> debian: 3.2.0~pre1-1
<Keybuk>     samba_3.2.0~pre1-1.dsc
<Keybuk>     samba_3.2.0~pre1.orig.tar.gz
<Keybuk>     samba_3.2.0~pre1-1.diff.gz
<Keybuk> it generated the merge from experimental
<Keybuk> oh, cock
<bryce> lool: ok I'll take a look in a bit
<Keybuk> MoM has gone senile.
<Keybuk> The men in white coats are coming to pick her up and take her to therapy.
<lool> bryce: Thanks; I can hand you the /proc values as reported by the device if that's helpful
<lool> bryce: (Or do you have a Q1?)
<airjump> hello bryce
<bryce> no I don't have one
<bryce> hi airjump
<airjump> orga from the irc chan. edubuntu give me your nick name
<airjump> you have a eee pc from asus?
<bryce> lool, the /proc values may be useful; I haven't written evdev rules before so am not certain what'll be needed exactly
<cjwatson> airjump: I *cough* still need to pack it up and send it to bryce ...
<lool> bryce: My problem is that I couldn't find much information on the format of the /proc entry, but the xorg.conf part seems more clear and documented
<cjwatson> my bad, I've had too much to do
<airjump> ok
<Keybuk> right
<Keybuk> lobotomy applied to MoM
<ogra> poor MoM
<Keybuk> slangasek: check again in a few days when it's rebuilt
<slangasek> Keybuk: ok :)
<cjwatson> hmm. bzr upgrade --dirstate-tags sftp://blah not the fastest thing in the world
<Keybuk> cjwatson: s/sftp/bzr+ssh/
<cjwatson> last time I tried that with bzr upgrade it didn't work
<cjwatson> I'll try it again at some point ...
<cjwatson> bzr log --line | grep 'releasing version .*ubuntu' | sed 's/^\([0-9]*\):.*version \(.*\)$/bzr tag -r\1 \2/' | sh
<cjwatson> mm
<cjwatson> dirty hacks 'r' us
<cjwatson> Keybuk: bzr upgrade bzr+ssh:// just claims it's at the most recent format. bzr upgrade sftp:// actually does the upgrade
<slangasek> mathiaz: do you really think bug #163194 warrants another debconf question?
<ubotu> Launchpad bug 163194 in samba "Disable creation of weak lanman hashes by default in samba" [Undecided,Triaged] https://launchpad.net/bugs/163194
<slangasek> mathiaz: I wanted to take the easy route, and just patch the default behavior in the binary :)
<cjwatson> Keybuk: bug 125166
<ubotu> Launchpad bug 125166 in bzr "Smart server doesn't suppport upgrading" [Low,Confirmed] https://launchpad.net/bugs/125166
<Keybuk> ahh
<Keybuk> you're using LP
<Keybuk> ok
<mathiaz> slangasek: I'm not really sure. I don't know if there is a lot Win95/98/Me clients out there.
<mathiaz> slangasek: I would put the debconf priority to low.
<slangasek> mathiaz: if it's only going to be low priority, I would argue against doing the work on it before there's clear demand for the feature, since it makes work for translators, bloats the package with translated templates, etc.
<mathiaz> slangasek: yes. Makes sense.
<mathiaz> slangasek: on the same subject, IIRC to keep the passwords in sync, we need to install pam-smbpass
<slangasek> yes
<mathiaz> slangasek: would this be part of a default desktop install ?
<slangasek> but I'm still working on the pam framework for that :)
<slangasek> I think it should be
<mathiaz> slangasek: I wouldn't put on the defautl server install tought.
<mathiaz> slangasek: what about the case of a server that installs samba ?
<slangasek> as part of the "filesharing" task, or installing the package direct?
<mathiaz> slangasek: for the fileshareing task, I think pam-smbpass should be installed.
<slangasek> agreed then
<slangasek> well, unless we want the filesharing task to depend on krb5+ldap instead :)
<mathiaz> slangasek: but I don't think that the samba package should depend on pam-smbpass.
<mathiaz> slangasek: we'll wait a little bit for the krb5+ldap integration...
<slangasek> ack
<jdong> Can someone give-back https://edge.launchpad.net/ubuntu/hardy/+source/faad2/2.6-1 on the archs it FTBFS'ed on?
<jdong> the xmms-dev culprit has been resolved
<pochu> Could someone retry anjuta build? It failed in some archs a week ago because of missing dependencies, but it wasn't set to DEPWAIT: https://edge.launchpad.net/ubuntu/+source/anjuta/2:2.2.2-1ubuntu1
<Riddell> pitti: am I likely to need this patch soon?  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450603
<ubotu> Debian bug 450603 in kdm "kdm: Please add support for ConsoleKit" [Normal,Fixed]
<pitti> Riddell: right, I think you do
<pitti> Riddell: ah, that means current Hardy breaks power management and device mounting for Kubuntu?
<Riddell> pitti: not sure, I havn't tried it in a full session
<geser> pitti: have you seen pochu's give-back request for anjuta?
<pitti> geser: hm, seems I missed it
<pitti> ah, right, there
<pitti> pochu: done
<pochu> pitti: ty
<tormod> mjg59: hi I am merging our belowed laptop-mode-tools. Should we ship apm scripts or should we take them out as we do for acpi scripts?
<mjg59> Can you skip merging it until we know what we're doing with it?
<tormod> I can also just merge it, until we know better. Isn't much work.
<pitti> http://merges.ubuntu.com/main.html --- erm...
<pitti> did we just sync the entire hardy to sid? :)
<slangasek> haha
<seb128> pitti: we rock apparently ;-)
<pitti> we said we would push patches to Debian, and WE REALLY MEAN IT
 * ajmitch should still have a couple of outstanding merges there
<Treenaks> pitti: "but.. they kept asking"
<slangasek> I asked Keybuk about the experimental confusion, and he did something, and now everything's gone plaid
<slangasek> 09:06 < Keybuk> lobotomy applied to MoM
<slangasek> 09:07 < Keybuk> slangasek: check again in a few days when it's rebuilt
<tormod> just another reason to use DaD http://dad.dunnewind.net/main.php
<slangasek> I didn't realize he meant we'd be without merge info for two days :/
<pitti> tormod: oh, DaD speaks main now? cool
<seb128> tormod: support efforts duplications? not really required
<slangasek> tormod: no sort by age? :)
<pitti> but DaD doesn't seem to support initial vs. updated merges
<tormod> pitti: it lists main (since a long time)
<tormod> seb128: it has a "comment" field
<tormod> slangasek: it's open-source so you can fix it ;)
<seb128> tormod: I usually don't need to comment on merges I'm doing
<seb128> and if that's useful that should be added to merges.ubuntu.com rather than duplicating
<slangasek> tormod: sure, if I want to run my own copy of a service, pfff
<elmo> yeah, duplicating core infrastructure like that seems entirely sub-optimal
<tormod> is MoM open-source now?
<pochu> seb128, elmo: I think Adri2000 and Lutin volunteered to do that in MoM, but they can't ;)
<elmo> tormod: that's your justification?
<seb128> pochu: did they talk to Scott about it?
<seb128> pochu: are you going to use an another bug tracker than launchpad next because you can't fix bugs? and then something else than soyuz?
<ajmitch> seb128: yeah, it's called 'debian' :)
<tormod> elmo, that's the most important element
<pochu> seb128: nope, but I'm not justificating them, only letting you know :-)
<seb128> ajmitch: use Debian if you prefer, that's your choice
<seb128> ajmitch: that's smarter than creating yet another service
<ajmitch> seb128: pfft, you know that I'm stuck with ubuntu :)
<seb128> ;-)
 * ajmitch is using a sid desktop right now though, at work
<seb128> I doubt many people will work on dak though ;-)
<ajmitch> I'd prefer not to
<seb128> I'm wondering if they will also work on they own google ;-)
<ajmitch> though I like having comments on DaD, they're not much use if people are using 2 separate pages, that won't even give the same merge results
<seb128> I'm wondering if they try to sort the issues with Scott
<ajmitch> they have talked with him
<seb128> or if they just went "that's closed source let's do our own version"
<tormod> as someone said "Weâre committed to reinventing everything we need until the free software stack is a genuinely complete computing universe"
<ajmitch> I can't remember what the outcome was, I think scott suggested just using the MoM output as-is & reskinning it somehow
<seb128> tormod: you are free to reinvent the wheel, that doesn't mean it's really required or useful, especially if the tool you are using is likely to be opensourced one day
<elmo> tormod: obviously, it's your time, but there's ways to be clever about it.  and reinventing services when there's really no need, doesn't seem like an efficent use of time, to me, but whatever
<seb128> ajmitch: well, adding a comment feature on top on merges.ubutnu.com would likely be doable
<ajmitch> yep
 * ajmitch already has some scraping & commenting stuff
<seb128> not sure why comments are useful for merges
<seb128> usually you claim a merge and just do it
<seb128> and if you need sponsoring you use launchpad
<ajmitch> mainly useful for universe, where merges can take a little bit of time, and people like to claim them on the page
<pochu> right, I do that.
<ajmitch> there'd been some duplication of work in the past, and it does still happen a bit
<seb128> for the desktop team we use the wiki to claim those
<seb128> I'm sure MOTU could come with an easy system to claim merges without reimplementing everything
<tormod> I must admit I didn't invent DaD, but I think it would be nice if everybody could use the same tool, and an open-source one by preference.
<ajmitch> the wiki used to be used, and the pages ended up rather large
<elmo> tormod: please don't be so dramatic, everyone can use MoM
<elmo> whether they wish to or not, is another matter
<Adri2000> hmm, another MoM/DaD debate
<Adri2000> btw, I'm still waiting for sabdfl to answer a mail about that issue I sent him back in June
<ajmitch> it probably got lost in a pile of email then
<Adri2000> ajmitch: probably, but I reminded it him many times, and once again yesterday or two days ago, via mail and irc
<Burgundavia> we prefer open source everywhere else, I fail to see why we shouldn't prefer it in our infrastructure as well
<slangasek> tormod: "a genuinely complete computing universe" -- you're familiar with GÃ¶del? :)
<Yoe> hi -- I don't know what phase ubuntu's development is in currently, but could someone please make sure that my (source) package nbd is updated in ubuntu?
<Yoe> AAIU, the current version is held back from Debian since it's got some ubuntu-specific patches, but I incorporated those into my Debian package
<tormod> slangasek: I was quoting sabdfl :)
<Yoe> also, is there a way for me to make this more obvious to whatever Ubuntu tool looks at differences between packages?
<seb128> Burgundavia: when there is an opensource alternative sure, reinventing the wheel when you have working tools is an another question
<Burgundavia> seb128: by that argument, why do we have git when we could all be using perforce or bk?
<slangasek> tormod: ah, heh
<seb128> Burgundavia: I don't care about git and don't use it ;-)
<zul> Burgundavia: because upstream uses git? :)
<Adri2000> Yoe: it's in the merge queue, see dad.dunnewind.net/universe.php, you can add a comment saying it likely needs a sync
<elmo> Burgundavia: you're being disingenuous
<carlos> pitti: ping (about language packs build...)
<Burgundavia> elmo: no. Infrastructure is no different to anything else
<pitti> carlos: yeah?
<Adri2000> Yoe: oh actually it's in main, so main.php
<carlos> pitti: how's that going?
<seb128> Burgundavia: do you also refuse using google?
<pitti> carlos: buildds are grinding for a while
<elmo> Burgundavia: I'm sorry, let me introduce you to this product called Launchpad.  maybe you've heard of it?
<pitti> carlos: sources are all up for some hours already
<Yoe> Adri2000: yes, I was just going to say that :)
<pitti> carlos: (all PPA)
<carlos> pitti: still building packages?
<Burgundavia> elmo: I am well aware of LP. I don't like that it isn't open source either
<elmo> Burgundavia: please don't pretend it doesn't exist then
<carlos> how long does it take to be built?
<Burgundavia> seb128: there is a difference between a tool we use to build a free distribution and a mere tool
<pitti> carlos: yeah; it'll take until tomorrow morning, I suppose; we have three buildds now, but it's quite a large number of updates
<carlos> pitti: I see
<carlos> pitti: ok, thanks
<Burgundavia> elmo: I am not. I am merely saying that in this specific instance, there is no reason for the project to keep using a closed source tool when an open source one exists
<elmo> Burgundavia: sigh
<elmo> Burgundavia: I hate it when you get like this
<elmo> Burgundavia: free archive management tools exist (dak)
<slangasek> Yoe: you're welcome to use the procedure on https://wiki.ubuntu.com/SyncRequestProcess btw, or if you prefer I can go through it for you
<elmo> Burgundavia: free bug tracking tools exist (bugzilla)
<elmo> Burgundavia: ubuntu right now does not use them
<elmo> Burgundavia: please get in sync with that reality, and restate your argument
<Burgundavia> elmo: I know we don't use all those things. I didn't say I agreed with the decision
<Yoe> slangasek: oh, I thought that procedure was "ask on this channel" ;-)
<seb128> Burgundavia: do you think that reimplementing those for the sake for reimplementing will benefit anybody?
<Adri2000> the difference is that DaD was designed and developed for Ubuntu, just like MoM (the difference being freeness), while dak and bugzilla are not
<Burgundavia> seb128: by that argument, LP is a giant reinvention of the wheel that, IMO, add no value and takes away one key one, freedom
<slangasek> Yoe: either way... :)  Just pointing you it out if you'd prefer to have your hands on it directly
<seb128> Burgundavia: don't you think we should better spend the efforts on the distribution rather than reimplementing the tools?
<slangasek> hmm, pointing you it out
 * slangasek rewrites him this sentence
<seb128> Burgundavia: point me to something that does what LP is doing?
<Adri2000> seb128: sure it'd would take time and efforts to now switch to bugzilla or dak, but that's not true for switching from MoM to DaD
<Burgundavia> seb128: I think LP is a giant rathole, tbh
<tormod> seb128: it's for the sake of having open-source tools, not merely reimplementing
<seb128> tormod: we have better things to do that recoding the tools
<Yoe> slangasek: well, if you want to do it, not stopping you.
<seb128> we have tools there working and available, let's use them and focus on users issues
<Yoe> or jcastro (who's /query'ing me) could. Whatever.
<Yoe> as long as it happens :)
<slangasek> jcastro: put your hands where we can see them!
<Burgundavia> seb128: recoding tools because they are non-free is EXACTLY what we have been doing for 2 decades
<tormod> seb128: why not open-source MoM, any compelling reasons those claimed for LP?
<elmo> Burgundavia: you certainly haven't been doing it for 2 decades
<tormod> * like those
<seb128> tormod: dunno, you need to ask Scott
<Adri2000> seb128: Scott told me to ask sabdfl, that's why I sent him a mail back in June
<Adri2000> and still got no answer
<Burgundavia> elmo: no, I have not. It does not change the facts of my argument
<elmo> Adri2000: dude, send the mail
<Adri2000> elmo: ?
<elmo> Burgundavia: no, it's just fun to knock you off the pedestal you like to put you on
<elmo> Adri2000: + again
<elmo> Adri2000: strangely enough, Mark gets a lot of email ,it's not hard to believe it got missed, if you only sent it once
<Burgundavia> elmo: heh. If nobody will point out the elephant in the room, who will?
<slangasek> jcastro: so are you doing the sync request for nbd?
<jcastro> slangasek: I was going to ping sbalneav about it
<slangasek> ok
<Adri2000> elmo: not sure that will help. I already sent him twice, and pinged/queried sabdfl many times. sometimes I got answer "I will look at it" sometimes nothing
<seb128> Burgundavia: nobody really focused on rewriting online webservices until now
<Adri2000> s/him/it/
<slangasek> jcastro: alternatively, I could prepare the sync request and subscribe sbalneav for sign-off?
<Burgundavia> seb128: and that is a problem we have yet to solve
<seb128> Burgundavia: is there any effort to do a free google?
<jcastro> slangasek: I didn't want to interrupt the conversation with things actually relevant to this channel
<jcastro> slangasek: that would be great
<Burgundavia> seb128: I fail to see what the google argument has to do with LP?
<seb128> Burgundavia: that's the same issue, why do you refuse to use LP but are happy to use google?
<elmo> corey doesn't refuse to use it, he just likes to whine about how it's not yet OS
<elmo> (if he even remembers to add the yet)
<Burgundavia> seb128: I use both, because they work. I dislike using both
<tormod> seb128: there is an initiative to make a free "google". You think it's stupid to have a transparent search engine outside corporate control?
<elmo> I mean at least the DaD people did something, I can respect that, even if I think it's a waste of their time
<seb128> tormod: no, but I think we have better thing to do right now that rewritting websites and tools
<Adri2000> elmo: took us only two or three days, + all the bug fixing of course :)
<Burgundavia> elmo: are you saying I am not worth listening to because I cannot code?
<elmo> Burgundavia: nope
<elmo> Adri2000: then i sort of doubt it's feature complete compared to MoM
<elmo> (or you guys are just geniuses and keybuk's a slack jawed hippy, but I guess either of those is possible)
<Adri2000> tell me what's missing then please
<tormod> seb128: for many people, the Operating System is just a tool
<seb128> tormod: we don't argue with those guys, there is just no point
<Adri2000> I know that comments, automatic maintainer update, etc. are missing in MoM, but...
<seb128> automatic maintainer update?
<Adri2000> seb128: yes, for the DebianMaintainerField spec, though it's probably not very useful today
<seb128> as said before, comments ... who cares
<seb128> usually you claim a merge and do it
<Adri2000> that's a bit more complicated in universe usually
<seb128> use launchpad like we do for everything else?
<seb128> it's easy enough to open a "claim the merge" bug
<Adri2000> open a bug to comment on a merge?
<seb128> what sort of comment do you need?
<Adri2000> sync requested, please don't touch, wait for new debian version, X working on it, etc...
<Adri2000> just take a look at http://dad.dunnewind.net/universe.php
<geser> seb128: with comments it's easier to see if someone works on a merge, a sync got filed, any problems preventing the merge, etc.
<seb128> you could get a comment system around merges.ubuntu.com without reimplementing everything
<seb128> that's not a valid reason to reinvent the wheel
<Adri2000> I'd be very happy to help doing that, but I'm still looking for the code
<seb128> no need to get the code, the datas are public
<jcastro> slangasek: I'll send sbalneav a heads up email now
<seb128> it's easy to get a list of merges
<Adri2000> ah yes, but that would mean reinventing all the UI wheel
<geser> Adri2000: afaik the frontend only "parses" the directory structure on merges.u.c
<seb128> Adri2000: better than reinventing the logic and UI wheels
<Adri2000> geser: it should parse that http://merges.ubuntu.com/tomerge-universe
<Adri2000> but now this file is empty...
<Adri2000> it used to look like dad.d.n/tomerge-universe
<seb128> Adri2000: it has been resetted today, it's not like it happens every day
<Adri2000> ok
<Xteven> hi, I'm looking for someone who could give some information on how the gfxboot files onn the ubuntu cd were created
<Xteven> or any pointers to such info would help too...
<calc> mvo: hi
<mvo> hi calc
<calc> mvo: i have an apt patch for you once i verify it actually works
<mvo> calc: sounds good
<mvo> calc: lzma?
<calc> mvo: it adds some missing lzma support for apt-ftparchive, etc
<calc> mvo: yea
<mvo> calc: just mail it to me once you are happy with it. I will go to bed soon
<calc> ok have a great night :)
<Keybuk> hmm, hardy is a mixed bag for me
<Keybuk> bryce: you remember I said my brightness sensor didn't work?
<StevenK> Keybuk: I remember you saying that at least. :-)
<Keybuk> well, it works perfectly in hardy! \o/
<cjwatson> Xteven: it's in the gfxboot-theme-ubuntu source package
<Keybuk> and the brightness keys on the keyboard even pop up a little â OSD
<Keybuk> the fact that the OSD progress bar always remains at zero is ... well, minor
<StevenK> Hahaha
<Xteven> cjwatson: those are the files, but how were they created ? or how do I use them ?
<Xteven> gfxboot has no man-pages
<cjwatson> Xteven: like any other source package, you build it ...
<cjwatson> in the standard way
<Xteven> it has a very shallow "reference manual" that doesn't give much information at all
<cjwatson> the reference manual is INVALUABLE
<cjwatson> I couldn't maintain gfxboot-theme-ubuntu without it!
<Xteven> that xml file ?
<cjwatson> once built properly, yes
<cjwatson> there's a Makefile in there that builds it into HTML
<cjwatson> it is a language manual
<cjwatson> it may not be the information you need, but it's entirely wrong to say it doesn't give much information
<Keybuk> interestingly, I don't have hal-addon-dell-backlight running
<cjwatson> anyway, 'debuild -b' in an unpacked copy of gfxboot-theme-ubuntu with the build-dependencies installed on your system should build the files, just like any other source package in Ubuntu
<Xteven> hmm
<cjwatson> there's a very small amount of code in our deployed debian-cd that extracts /usr/share/gfxboot-theme-ubuntu/bootlogo.tar.gz into the /isolinux/ directory on the CD
<Xteven> is any of this information documented somewhere ? because I couldn't finnd it
<cjwatson> I don't believe it's documented, no
<cjwatson> although, in general, how to build a package from source should certainly be documented
<cjwatson> (I don't know offhand where)
<Xteven> I didn't know it was a source package actually :/
<Xteven> could you tell me how much work it is to create a new theme inn gfxboot ?
<Xteven> the reference doc hints towards a postscript-like language
<Xteven> and the .inc files in gfxboot-theme-ubuntu look complicated enough that I don't want to build anything from scratch :/
<Xteven> thx for the info
<cjwatson> Xteven: unfortunately, lots
<cjwatson> I based the Ubuntu theme on the SuSE theme
<cjwatson> it was several weeks of fairly solid work
<cjwatson> it's not an easy language, I'm afraid
 * mpt wonders if it would make sense for a shell to have a "Chime when anything non-interactive that's taken longer than 2 minutes is finished" option
<cjwatson> I imagine smaller modifications would be less work, of course
<Xteven> cjwatson: I guess I could do with small modificaions :)
<Xteven> cjwatson: I'd like to strip out all the non-english languages, since we won't be using them
<Xteven> and then I'd like to change the menu entries and the image
<Xteven> thats pretty much it
<Xteven> I know how to put a new image and how to change the menu entries
<Burgundavia> mpt: something like that should probably be generalized, ala the geyser project
<cjwatson> (dinnertime, back later)
<Xteven> but the translated files are not easy to understand
<Xteven> ok, enjoy your meal
<cjwatson> stripping out the languages is easy, just remove the translations and take them out of langlist or whatever it is
<Burgundavia> mpt: basically, the terminal would say "something is done, notify the user" and the system would do what it was told to do, which on a server might be SMS or email the admin
<mpt> Yeah, doing it just for the shell would be too easy to implement :-P
<Burgundavia> yep, you need to build a bigger bikeshed and *then* you paint it
<Xteven> cjwatson: ok thx, I'll try it
<mpt> Coincidentally I commented on <https://wiki.ubuntu.com/GeyserSpecification> a few days ago
<Burgundavia> mpt: he should have called it MessageKit
<mpt> We're going to need a KitKit to organize all these Kits
<Burgundavia> oh indeed
<Burgundavia> and HAL+udev is soon to be DeviceKit
<theunixgeek> Hello. I'm following the osdev Bare Bones tutorial for writing a simple kernel. http://www.osdev.org/wiki/Bare_bones I'm a complete noob at this, so please don't assume I know all the terminology you guys do. I'd like to be able to boot the kernel shown in the tutorial in either Bochs or QEMU. How would I go about this?
<mjg59> theunixgeek: This isn't really the right place to ask
<mjg59> This channel is for development of Ubuntu, not development using Ubuntu
<theunixgeek> mjg59: sorry :(
<mjg59> No problem
<mjg59> #ubuntu is a better place to ask
<theunixgeek> mjg59: even for development questions?
<mjg59> Yes
<theunixgeek> ok
<theunixgeek> thanks
<mjg59> If they're not about developing Ubuntu
<Burgundavia> heh
<Burgundavia> mjg59: guess who just popped up on #edubuntu?
<mjg59> ?
<Burgundavia> our little friend, theunixgeek
<mjg59> If he's asking the same question, explain that it's inappropriate
<mjg59> And that it's inappropriate in every Ubuntu channel except #ubuntu
<Keybuk> oh, and other mixed-bag on hardy ... performance is really dire
<Keybuk> is hard to tell whether it's compiz being slow as shit ... or the computer
<Keybuk> since my primary interaction is through compiz
<Burgundavia> Keybuk: tracker seems to fire up right on login, with predictable results
<Keybuk> nope, isn't tracker
<Keybuk> that's the FIRST thing I blamed :p
<Burgundavia> heh
<Keybuk> deskbar-applet is using unreasonable amounts of CPU for something that's not supposed to be doing anything
<Burgundavia> we should probably add a deferred startup bit to tracker
<tjaalton> Keybuk: what driver?
<Keybuk> tjaalton: intel
<tjaalton> Keybuk: ok, try using XAA
<Keybuk> tjaalton: -v
<johanbr> Burgundavia: It's supposed to have a 45 sec startup delay already.
<Burgundavia> johanbr: 45 secs is not enough
<Burgundavia> on a slow harddrive like mine, 45 secs is still in the panel load time
<johanbr> Well, it's adjustable.
<Keybuk> tjaalton: googling for "enable xaa" is surprisingly unhelpful
<johanbr> Burgundavia: And it takes you more than 45 seconds from gdm to gnome?!
<StevenK> Burgundavia: Are you turning the platter by hand, or what?
<Burgundavia> StevenK: tiny japanese hamsters, this is a toshiba
<tjaalton> Keybuk: ok :) 'Option "AccelMethod" "XAA"'
<StevenK> Ugh, Toshiba
<Keybuk> tjaalton: which section?
<tjaalton> Device
<Burgundavia> johanbr: it takes me longer to get from gdm to gnome than it does from bios to gdm
<tjaalton> it's EXA by default now
<Keybuk> if only X supported setting driver params on the fly
<Keybuk> but hey, that'd involve it being dragged kicking and screaming into the 20th century
<StevenK> Keybuk: It needs to be dragged kicking and screaming into the 19th first :-P
<johanbr> Burgundavia: That doesn't sound right.
<Burgundavia> johanbr: login has always been slow for me. Is there a way to instrument it to figure out where the time is being wasted?
<johanbr> Burgundavia: I think bootchart can do that.
<Burgundavia> johanbr: I didn't think bootchart worked after gdm
<Keybuk> tjaalton: highly subjective not-a-metric, but this is a hell of a lot faster
<Keybuk> Burgundavia: sure it can
<Keybuk> tjaalton: oh, it's a hell of a lot faster AND tracker is running
<tjaalton> Keybuk: heh, I couldn't really tell the difference with i945
<Keybuk> this is a 945
<tjaalton> ok.. interesting
<Keybuk> without XAA (with EXA?) simple animations were visibly jerky
<Keybuk> and larger ones like workspace switching only rendered two or three frames
<Keybuk> and the whole desktop felt sick and slow
<Keybuk> with XAA, it's back to normal -- windows slide around, etc.
<mjg59> Login is insanely slow on anything with high seek latency
<tjaalton> actually, workspace swithes were jerky sometimes
<mjg59> From a warm cache, it takes a couple of seconds
<Keybuk> tjaalton: did you try scrolling web pages, or PDF files?
<mjg59> Which tells you where the problem is
<tjaalton> Keybuk: I know there are bugs in that area, but it wasn't too bad
<Burgundavia> mjg59: so basically I have a crap HDD and there isn't much I can do?
<mjg59> Reduce the number of seeks performed during login
<Keybuk> Burgundavia: no, there's plenty you can do, but it all comes down to reducing the number of seeks and reads
<Burgundavia> right
<Keybuk> it's not one specific process you can blame
<mjg59> You can strace gnome-session and all its children
<Keybuk> mjg59: I straced X once, that was funny
<StevenK> mjg59: If I recall, gnome-session seems to react badly when strace'd. If you kill strace(), gnome-session doesn't seem to wake up, even when you kill -CONT it
<mjg59> Michael Meeks' iotrace is probably more worthwhile
 * StevenK kicks openssl for being inconsistent and stupid
<calc> how do i look at a prior revision of a wiki page on w.u.c ?
<calc> ah 'get info' heh
<johanbr> Quoting Dave Jones: "when it isn't busy scanning non-existent pci busses, X likes to reopen files it already read"
<bryce> Keybuk: great to hear about the brightness sensor!
<rexbron> lionel: Has there been any movement on merging gtk-engines-murrine?
<lionel> rexbron: I think your're looking for mr_pouit :)
<rexbron> oh, ok
<rexbron> sorry about that
<lionel> rexbron: no pb :)
<mr_pouit> lionel: ^^'
<lionel> hey mr_pouit
<mr_pouit> rexbron: iirc no, you can merge it of you want (the ubuntu package has a patch to fix a bug with a gimp theme afaik).
<mr_pouit> s/of/if/
<mr_pouit> hey lionel :)
<rexbron> mr_pouit: Cool
<blueyed> Please confirm my nomination of the gparted top crasher for Gutsy (bug 141516).
<ubotu> Launchpad bug 141516 in gparted "[MASTER] Gparted crashes when refreshing devices" [Medium,Fix released] https://launchpad.net/bugs/141516
#ubuntu-devel 2007-11-22
<defishguy> Does anyone have a suggestion for noob reading on creating packages?
<IntuitiveNipple> https://wiki.ubuntu.com/PackagingGuide/Basic
<mardi_soir> hello here
<mardi_soir> i m sorry about this but on ubuntu i have no answer
<mardi_soir> i use livecd lts
<mardi_soir> and i d like to knoqw if
<mardi_soir> the resize can be verry long
<mardi_soir> (many hoaurs )
<mardi_soir> (top say partman is active)
<mardi_soir> syslog that my hard disk is not good
<mardi_soir> and partpman log
<mardi_soir> seams to be well
 * lamont waves from home
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down for maintenance from 02:00 UTC to approx 06:00 UTC - Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
 * lamont debates whether UPS-install-time is now, or in the morning
<fabbione> morning
<fabbione> lamont: UPS?.. the sooner the better
<StevenK> Maybe lamont is talking about installing the UPS guy he kidnapped.
<lamont> fabbione: yeah... sucks when the power bounces
 * fabbione hugs his 2x3KW UPS
<fabbione> fun thing is that i did run out of power cables before power outlets and power on the UPS'es
<fabbione> i still have some machines on their own.. but mainly laptops
<fabbione> and a few monitors i think... that I am _hoping_ they will die soon so i have a good excuse to go and buy 3x30" Flat screens
<lamont> fabbione: 2x2200W
<fabbione> not bad :)
<lamont> that's for the cabinet.  which has stuff of my wife's in front of it atm.
<lamont> my desk area has a 1KW UPS for the WS there.
<fabbione> i share one of the UPs for my workstation
<lamont> and then there are a scattering of 300W UPSs for other computers, TiVo, switches, etc
<fabbione> they are extremely silent
<fabbione> yeah
<fabbione> that too.. but i didn't count them :)
<lamont> my 2200W UPS not silent.
<lamont> nor are the servers --> utility room
<lamont> office area is actually quiet
<fabbione> the servers are noisy but the UPS are very silent
<lamont> and off for family time.  bbl
<fabbione> i heard only once spinning the fans
<fabbione> when i almost loaded them at 80% each
<fabbione> that was about it
<fabbione> plus the general noise with everything powered on makes you feel deaf anyway
<fabbione> later :)
<pitti> Good morning
<LaserJock> hi pitti
* mthaddon changed the topic of #ubuntu-devel to: Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<dholbach> good morning
<IntuitiveNipple> Do we have a recommended package for netfilters/iptables boot-time configuration, possibly for the server install?
<slangasek> no, but we have a spec for it. :-)
<IntuitiveNipple> I wondered why I couldn't find anything! I'm just writing up an article in the forums on how to configure apache2 to do transparent proxying, and was looking for the 'recommended' way to save/load a ruleset
<mjg59> iptables < foo in ifup.d, I suspect
<IntuitiveNipple> Any ideas which package I should recommend to users to do this? minimal thing that loads rules at boot? firestarter et al aren't really what I had in mind but...!
<IntuitiveNipple> mjg59: I thought of that but thought it might be a bit too hackish :)
<mjg59> Doing it on interface up/down is probably the right thing to do
<mjg59> Avoids the interface managing to come up before the rules are in effect
<mjg59> I believe that's why it was removed from the init scripts
<IntuitiveNipple> In my case the rules aren't interface-specific, but I see your point
<slangasek> hrm, I thought the reason for removing it from the init scripts was nothing so sensible as that :)
<mjg59>   * removed README.Debian, too confusing
<mjg59> Promising.
<IntuitiveNipple> I think I'll duck this one for now and just say "you need to add this rule to your preferred firewall manager" :p
<IntuitiveNipple> For reference, if anyone else needs apache2 as a transparent caching proxy: http://ubuntuforums.org/showthread.php?p=3816917
<dholbach> hey seb128!
<dholbach> hey MacSlow
<MacSlow> Greetings everybody!
<MacSlow> hi dholbach
<seb128> hello dholbach MacSlow
<pitti> seb128: will you put the patch tagging guidelines into the wiki somewhere? what would be a good place?
<seb128> pitti: yes, I planned to do that today
<seb128> pitti: not sure w.u.c/PatchTaggingGuidelines? ;-)
<pitti> I thought we would already have some existing documentation about patches, but apparently not much
<pitti> should be linked from UbuntuDevelopent somewhere, I figure
<seb128> pitti: yes, that's the plan
<Keybuk> StevenK: I've renamed hardy-about-ubuntu to about-this-computer to properly match the content
<pitti> Keybuk: eww, killall-gksudo: TBH I wasn't even aware that this was assigned to/drafted by me, and it doesn't even have a wiki page nor notes
<pitti> Keybuk: *sigh*, seems I lied then when I said that I drafted all my specs
 * pitti will ask desrt if he has notes
<Keybuk> pitti: heh, it wasn't :-)
<Keybuk> but it's as good a place as any to dump the result of the ptrace and policykit discussion which is all in your brain
<Keybuk> I don't have any notes from the session that aren't already covered in what we've decided
<cjwatson> mvo: I've written up apt-authentication-reliability; please review
<mvo> thanks cjwatson
<pitti> cjwatson: Keybuk just mentioned to me that you have some remarks about the prefetch spec; they are not in the wiki/whiteboard, are they somewhere else?
<cjwatson> I'll fish them out of IRC backlog and insert them
<cjwatson> pitti: I've added them to the wiki with my name attached; refactor at will
<pitti> thanks
<seb128> pitti: can you build retry libgnomeprintui?
<pitti> seb128: done
<seb128> pitti: danke
<pitti> Keybuk: curious; how does prefetch achieve the speedup if not by reordering disk blocks?
<seb128> pitti: can you also retry gnome-python on lpia and hppa?
<pitti> Keybuk: i. e. without using the remapping tool?
<pitti> seb128: done
<seb128> danke
<Keybuk> pitti: it has a readahead like component, where it tracks the files it needs to read and does so in advance
<Keybuk> in fact, that's the major component
<pitti> ah, I see
<dholbach> 0 outstanding merges, 0 updated merges? YAY!
<pitti> sync-source.py -f -F -a :)
<pitti> or did someone do a major NMU sprint in Debian? :-P (you said "give back patches", and we DID! MUHAHA)
<seb128> pitti: ftp.debian.org dns has been updated to point to ubuntu.archive.com
<seb128> easier this way ;-)
<seb128> archive.ubuntu.com
 * dholbach sees 1500 MOTU applications coming up on the MC list
 * dholbach confiscates a few crack pipes around here
 * seb128 hugs dholbach
 * dholbach hugs seb128 back :)
<Keybuk> seb128: now *that'd* be a great way to leave Debian
<Keybuk> dholbach: MoM is currently undergoing electric shock therapy
<Keybuk> *BZZZT*
<dholbach> just when I announced http://wiki.ubuntu.com/UbuntuDevelopment/Merging
<dholbach> :-)
<Keybuk> yeah
<Keybuk> now's a bad time for that
<pitti> well, the merges are still there, but the index pages are broken
<Keybuk> pitti: I haven't sanity checked them yet
<Keybuk> MoM was merging from experimental instead of unstable
<Keybuk> so I had to wipe it and rebuild the db
<pitti> ah, I see
<TheMuso> Lovely.
<Keybuk> (and then we should probably check hardy to see what we accidentally merged :p)
<pitti> well, let's hope that maintainers would have noticed :)
<dholbach> more! new! crack! :)
<seb128> Keybuk: do you have an idea on how long it'll take to regenerate everything?
<Keybuk> seb128: an hour or so more
<Keybuk> maybe two
<seb128> ok, so today, good
<seb128> thanks
<seb128> StevenK: there is a new gimp version to merge ;-)
<StevenK> seb128: Oh, gah
 * siretart likes the current state of http://merges.ubuntu.com/main.html :)
<tjaalton> duh, apparently debian/foo.install overrides any setting I have on rules (like -Xbar)?
<gaspa> mvo: when do you uploaded ltrace? I lost it :P
<pitti> cjwatson: doko just gave his review and thumbs-up to https://blueprints.edge.launchpad.net/ubuntu/+spec/hardy-reducing-duplication FYI
<cjwatson> ok, thanks
<StevenK> seb128: What new version?
<seb128> StevenK: http://packages.qa.debian.org/g/gimp/news/20071121T194706Z.html
<StevenK> I see that.
<StevenK> I've done most of the hard work in 2.4.1, so 2.4.2 should be simple.
<seb128> pitti: https://wiki.ubuntu.com/PatchTaggingGuidelines
 * pitti hugs seb128
<pitti> seb128: is the 'yes' in UbuntuSpecific really necessary?
<pitti> seb128: isn't the mere presence of the tag implying a 'yes'?
<seb128> pitti: you want to change it by an UbuntuSpecificReason?
<seb128> or UbuntuSpecificRationale
<seb128> right, that's not really required
<seb128> feel free to edit the wiki and change that
<pitti> that's a bit too long; "UbuntuSpecific: we do not want to have this application appear in our menu" or so
<seb128> works for me
<pitti> edited
<seb128> thanks
<mvo> gaspa: ltrace: Fri, 16 Nov 2007
<gaspa> mvo, ok. Then the bug should be closed.
<mvo> gaspa: what bugnumber was that?
<gaspa> mvo: bug #160896
<ubotu> Launchpad bug 160896 in ltrace "Merge with version 0.5.3 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/160896
<mvo> gaspa: doing that now, thanks
<gaspa> ok, thank _you_ :d
<mvo> jdong: https://bugs.edge.launchpad.net/gutsy-backports/+bug/164488 <- compiz backport request
<ubotu> Launchpad bug 164488 in gutsy-backports "Please backport-sync compiz and compiz-fusion-plugins-extra from hardy" [Undecided,New]
<theunixgeek> What do you talk about in here?
<StevenK> Keybuk: I disagree with your first comment in AboutThisComputer
<StevenK> Riddell: Ping
<Riddell> hi StevenK
<StevenK> Riddell: Would you mind running "python -c 'import os; print os.environ'" on a Kubuntu desktop machine and pastebinning the result?
<Riddell> StevenK: http://paste.ubuntu-nl.org/45459/
<Riddell> StevenK: this is me logged into KDE 4 if you're wondering about the funn PATH
 * Hobbsee waves
<ajmitch> hi  Hobbsee :)
<Hobbsee> ajmitch!
 * mvo waves to Hobbsee
<Hobbsee> heya mvo!
 * Hobbsee hugs mvo
<Keybuk> StevenK: ?
<StevenK> Keybuk: "ScottJamesRemnant: summary no longer matches the content of the specification, adjust."
<Keybuk> StevenK: the specification is "About This/Your Computer should show useful information about your computer, its hardware and installed operating system and desktop environment"
<StevenK> Keybuk: I disagree, I think it does match; if you don't agree, could you give me more information.
<Keybuk> the priority of that information is inherent in the order? :)
<Keybuk> and the spec at no point says what derivative name you're running
<StevenK> Because fetching that information is *hard*.
<StevenK> We spoke about that bit alone for >20 minutes :-)
<Keybuk> but the summary says, as the very first thing, Ubuntu derivative name
<Keybuk> so the summary no longer matches the specification ;)
<StevenK> Okay, point.
<StevenK> Keybuk: First spec, be gentle, etc, etc :-)
<StevenK> Well, okay, first spec reviewed
<StevenK> Hum
<StevenK> How I can get a glob that matches libtiny*deb but not if it contains '-dev' ?
<pitti> Keybuk: there: https://wiki.ubuntu.com/PolicyKitIntegration
<Mirv> pitti: have the language packs for gutsy been already generated? where will they appear this time at first? they are quite badly needed as Rosetta had those performance problems preventing translation imports at release time.
<pitti> Mirv: they are in PPA now; testing appreciated!
<ion_> Yay, git-core tries to overwrite /usr/share/perl5/Error.pm from liberror-perl
<Mirv> pitti: ah, it's not ppa.dogfood anymore, otherwise I'd have noted... thanks!
<Hobbsee> pitti: any reason you are dumping thme into ppa?
<Keybuk> StevenK: libtiny*deb~*-dev*
<Keybuk> (in zsh :p)
<pitti> Hobbsee: as opposed to what?
<StevenK> Keybuk: I see your point about the information in About Ubuntu and About Gnome, but I'm not sure what to do, my feeling is a button -- but I'm not sure if that's a good idea.
<pitti> Hobbsee: in ancient tiems I had them on people.u.c., but PPAs are much nicer :)
<Hobbsee> pitti: i thought you used to build them on some of the canonical machines.
<pitti> I don't need to maintain my owhn archive any more
<Hobbsee> like, 6 months ago
<Keybuk> ok, MoM should be happy again
<Keybuk> and sane this time
 * pitti hugs Keybuk, thanks
 * ogra reloads
<Hobbsee> Keybuk: doesn't that require the owner of MoM to be sane too, for it to be sane?
<Mithrandir> sanity is overrated.
<StevenK> We're all perfectly sane!
<Hobbsee> yeah well.  tell me about it.
 * StevenK cackles to himself
<Mirv> pitti: yup, the langpacks (fi) seem to contain correct stuff and fix the most important stuff that I and others have been waiting for.
<Keybuk> doesn't look like we accidentally merged anything from experimental
 * StevenK decides his head is spinning too much to merge gimp right now
<tjaalton> ion_: fixed already, -1.1 should be in hardy soon
<ion_> Nice
<StevenK> Hrm.
<StevenK> Stupid idea - the start-here and Gnome icons become buttons that link to the About Ubuntu/Gnome bits :-)
<mvo> cjwatson: thanks for AptAuthenticationReliability, I'm happy with it
<cjwatson> mvo: cool. it's Scott's to review
<cjwatson> mvo: could I have a release note for networkless-installation-fixes?
<mvo> cjwatson: sure
<mvo> cjwatson: updated
<cjwatson> ta
<ogra> Keybuk, why does my dmesg talk about eth2 and i end up with an actual eth5 device ... can we syncronize the kernel and udev somehow ?
 * ogra just got a USB-ETH adapter that shows this behavior
<broonie> ogra: The kernel printk happens before the device is presented to userspace.
<ogra> well, then userspace should get the device name from the printk or the printk should be supressed and replaced by a udev message that comes with the right interface name
<Keybuk> ?
<Keybuk> does it particularly matter?
<ogra> its confusing that i have to look up the right name in hal device manager since its not exposed anywheer else easily
<broonie> ogra: Userspace does get the device name that's printed, it just immediately replaces it.
<Keybuk> what information in dmesg do you need?
<ogra> broonie, right, so the message should be shown after the replace
<ogra> [81112.456000] usb 3-2: new high speed USB device using ehci_hcd and address 2
<ogra> [81112.588000] usb 3-2: configuration #1 chosen from 1 choice
<ogra> [81113.300000] eth2: register 'MOSCHIP usb-ethernet driver' at usb-0000:00:13.2-2, MOSCHIP 7830 usb-NET adapter, 10:11:00:03:10:98
<ogra> [81113.300000] usbcore: registered new interface driver MOSCHIP usb-ethernet driver
<Keybuk> is any of that information not in lshal?
<ogra> Keybuk, thats what dmesg shows me
<ogra> ogra@laptop:~/devel/hardy/ltsp$ LANG=C ifconfig eth2
<ogra> eth2: error fetching interface information: Device not found
<Keybuk> ogra: so?
<Keybuk> don't look at dmesg
<Keybuk> pretend it doesn't exist
<Keybuk> dmesg is kernel debugging output
<Keybuk> look at HAL and /sys and ifconfig -a
<ogra> tell that to our users :)
 * ogra is expecting complaints 
<cjwatson> this isn't new behaviour
<ogra> but also not very old
<cjwatson> we have been renaming network devices in userspace since warty
<Keybuk> we've had this behaviour for at least the last 4 releases
<Keybuk> certainly since ever in some cases
<cjwatson> at one level or another
<Keybuk> nobody complains that much
<Keybuk> if there's information in dmesg that isn't exposed through HAL in userspace
<Keybuk> then that's a bug
<Keybuk> you shouldn't need to look at dmesg at all
<Keybuk> dmesg is only useful for handing unread to kernel developers when you have a problem
<ogra> my point is that its exposed in dmesg first place ....
<ogra> with different info
<Keybuk> memory addresses are exposed in dmesg
<Keybuk> they don't match /proc/maps
<Keybuk> you haven't complained about that yet
<StevenK> Hah
<ogra> i didnt use them actively yet :P
<StevenK> Keybuk: /proc/version doesn't match my machine name! Oh my god, kittens are dying.
<StevenK> Or something
<gaspa> pitti: about usplash, do you have some deadline for inclusion of my features? I think i won't have so much time this week.
 * Keybuk blinks
<Keybuk> my mortgage advisor just messaged me on Facebook to remind me that it's review time
<Keybuk> W. T. F.
<ogra> on facebook ?
<soren> That's... uh.. wow.
<Keybuk> We so need Web 2.0 Service Park 1
<Keybuk> pack too
<ogra> heh
<Hobbsee> ...impressive.
<zul> Keybuk: what impressive service
<Ng> do you really want your mortgage adviser to see all the pirate/vampire groups you're in on facebook? ;o
<\sh> web 2.0? my former company is working on propietary web 3.0 with world domination services attached
<Hobbsee> \sh: now that sounds fun...
<Keybuk> Ng: I have all of those blocked ;)
<highvoltage> Keybuk: I've got people who messaged me on facebook for business purposes too :-/
<\sh> Hobbsee, tbh this is for real
<\sh> Hobbsee, they tried it already...but a new messenger with some funny comic avatares were not the hype ... so they are discussion now some web 3.0 stuff *crazy*
<\sh> s/discussion/discussing/
<StevenK> \sh: But you can't be discussing world domination, you don't work for the Canonical Evil Empire
<zul> *groan*
<Hobbsee> StevenK: it's the Evil Canonical Empire (tm).
<\sh> StevenK, really, with more then 500 million on their account here, they can discussion world domination ,-)
<\sh> argl
<\sh> disccusing
 * norsetto wonders if the sabdfl has a dark helmet and an heavy breath
<\sh> well, it's 500 mio in total but only 300 mio in cash money :(
<StevenK> Keybuk: I have one concern left to address in AboutThisComputer, but it was one that wasn't discussed in the BOF, and I'm at a loss at how to explain it.
<Keybuk> :)
<StevenK> Keybuk: I'm loathe to include a button labelled "More Information..." since the user would probably assume it was going to give more information about their computer not Ubuntu
<Keybuk> StevenK: I thought a good solution was to stick that stuff under "Help and Support" :-)
<sabdfl> norsetto: some days
<sabdfl> some nights, too
<norsetto> sabdfl: yes, I thought you might eat indian from time to time ...
<StevenK> Keybuk: Oooh. So I mention that the current details will be assimilated into Help and Support, and set it back to Review?
<Keybuk> StevenK: sure
 * highvoltage hear the Imperial March for some reason
<highvoltage> *hears
<Hobbsee> norsetto: that's when he's not eating people.
<zul> mmmm....squishy
<norsetto> Hobbsee: well, indian people ;-)
<Hobbsee> norsetto: oh, he only eats indians now?  how racist1
<StevenK> Keybuk: Spec twiddled.
<Keybuk> StevenK: could you sneak into #ubuntu-meeting
<soren> What does the Uploaders: field do? AFAIUI anyone can actually upload the package, so that happens if you're not listed in Uploaders:? Does the maintainer get a special kind of notification?  (In Debian of course, I know we don't use it)
<seb128> soren: it don't consider the upload as a NMU for uploaders
<seb128> s/don't/doesn't
<lamont> seb128: anything other than lintian for 'it'?
<soren> seb128: So there's nothing technical in place that looks at uploaders at all?
<lamont> soren: maybe some backend web/stats/qa stuff
<seb128> soren: what do you mean? The PTS list the maintainer and the uploaders
<seb128> uploaders is somewhat equal to co-maintainer
<soren> Maybe it's just that I haven't completely grasped the NMU concept.
<lamont> soren: in terms of things getting into the archive, doing a non-NMU version upload and not being in Uploaders will not cause it to be rejected
<soren> What happens if someone does an NMU
<soren> ?
<seb128> NMU is an upload from somebody who doesn't maintain the package
<soren> Yes, that much I understand. :)
<seb128> he gets flamed? ;-)
<lamont> soren: NMU generally means that whatever the SCM that the maintainer uses is now out of date
<soren> lamont: How do you tell an NMU version from a "regular" one?
<seb128> .1 happened to the number usually
<lamont> soren: because it has that NMU version number...
<seb128> s/happened/appened
<soren> lamont: You're being extraordinarily unhelpful here :)
<lamont> for example, all of the kernel uploads happen to have NMU version numbers.
<seb128> soren: the websites etc list the NMUs differently
<soren> seb128: oic
<lamont> backend stuff (like the websites) key off of uploader not maintainer/uploaders, and call it an NMU
<soren> lamont: a) What defines an NMU version number? b) Why do kernels all have such a version number?
<lamont> multiple components (and therefore a dot) in the debian portion of the version
<soren> Ok.
<lamont> kernel -> it was the least evil way to encode all the info we wanted
<seb128> soren: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html
<soren> lamont: Ah, so it's not because kernel upload a actually non-maintainer-uploads, they just look like it.
<lamont> right
<lamont> it's the one case I know of in debian or ubuntu where a maintainer upload always has a NMU version number.
<lamont> doing an NMU without using a NMU version number will get you massively flamed in debian
<lamont> that is, if the package is foo_1.2-3, and you upload foo_1.2-4, you better be the mainainer.  (NMU should be foo_1.2-3.N, with N starting at 1 generally)
<soren> Maintainer or uploader, right?
<lamont> cjwatson: can we make truncated-conversion-of-pointer-to-int a failure on hardy?
<lamont> that'd affect amd64 and ia64 builds, and cause them to FTBFS instead of failing to run
<soren> Otherwise I missed the point of the Uploaders: field again.
<lamont> maintainer/uploader
<soren> Ok, great.
<lamont> Maintainer is the maintainer email address.  uploader is all the other names that could appear in debian/changelog and still mean "maintainer"
<lamont> as in aliases for the maintainer
<lamont> as far as the world is concerned.
<soren> lamont: Maintainer: can't list more than one e-mail?
<lamont> I don't think it can... would welcome an existance-proof to the contrary
<cjwatson> lamont: truncated-conversion> would be OK by me
<lamont> cjwatson: I'll push the change towards the buildd package rather than cowboying it then
<soren> lamont: There are two cases, but I don't think they count :)
<lamont> soren: LOL
<soren> lamont: Ah, only really one: moblin-chat. It lists that I think is the original maintainer + MOTU.
<soren> lamont: The other one was moblin-chat-dbgsym.
<lamont> ok.  existance-proof to the contrary in debian. ;-)
<lamont> doko: how hard would it be to make gcc die in the instances that get caught as conversion of a pointer coincident to an implicit function definition?
<Hobbsee> soren: sounds like a script breakage
<lamont> doko: http://wiki.debian.org/ImplicitPointerConversions
<lamont> Hobbsee: ah, come on, who said they used a script?
 * lamont back in a few
<doko> lamont: I didn't look
<lamont> doko: my options are to (1) have gcc do it (work), or (2) have sbuild check after the build is done, thereby catching all of the instances in one pass (very little work).  I'm inclined to go with option 2, but wanted to give you the chance to claim it.
<lamont> debian/ia64 is doing (2)
<doko> lamont: maybe the easiest way is to make it an error, if a (new) option -fsomething is passed
<lamont> doko: it's always an error.  it's just flagged as two warnings now.
<doko> no, I don't claim it.
<lamont> heh. no worries
<kaaloo> Hi I just patched libxcb1 on hardy to support the LIBXCB_ALLOW_SLOPPY_LOCK env variable which allows java apps like the google web toolkit to run.  I sent a diff to ubuntu-motu but I'm not sure if I sent it to the right place and in the right format.  Any pointers ?  Thanks !
<norsetto> kaaloo: how did you send this debdiff?
<kaaloo> well, I did a diff -u on the sources I got through apt-get source and the source tree I modified (in one directory)
<norsetto> kaaloo: sure, but how did you send it? Note that libxcb1 is in main, so, there is nothing motus can do for you
<pitti> seb128: I just tagged all Ubuntu patches in g-v-m \o/
<pitti> (and forwarded them upstream, too)
<pitti> this looks really good
 * seb128 hugs pitti
 * pitti hugs seb128
<seb128> pitti: you rock ;-)
 * pitti uploads and chalks off another libpam-foreground dependency
<pitti> cjwatson: so adding a new static group is actually hard? and you don't think we can get away with using an existing static group instead of "noptrace"?
<gaspa> pitti: about usplash, do you have some deadline for inclusion of my features? I think i won't have so much time this week.
<pitti> gaspa: FeatureFreeze :)
 * gaspa ransacks into his bookmarks...
<Keybuk> February 14th
<Keybuk> there's going to be some harsh love
<gaspa> oh, so much time
<gaspa> good
<gaspa> :D
<Keybuk> though obviously, the sooner the better
<Keybuk> things landed on feature freeze after coming from nowhere ... not popular
<cjwatson> pitti: adding a new static group is trivial *except* for the way we really ought to debconfiscate base-passwd first otherwise upgrades will suck
<cjwatson> pitti: there haven't been any new users or groups for years so you may have forgotten, but the process involves 'read' in base-passwd.postinst
<cjwatson> it's fixable, just a bit of work we need to (and, TBH, really ought to) swallow
<pitti> ah, for asking whether the postinst may update /etc/passwd?
<cjwatson> pitti: short of 'root' (which is obviously undesirable for other reasons), I'm not sure any other static group is suitable, but please do read through the list and suggest one
<cjwatson> right
<cjwatson> it's not entirely trivial to debconfiscate for various reasons, but it is possible
<pitti> cjwatson: I just did; all existing ones feel a bit like abuse; 'sys' and 'nogroup' still seem like the most obvious ones
<tjaalton> kaaloo: see /usr/share/doc/libx11-6/NEWS.Debian.gz
<pitti> but neither denote the meaning of what we try to do
<cjwatson> nogroup isn't hopelessly bad but we'd have to be careful to avoid anything ever ending up writable by it
<cjwatson> and I think audit tools may flag it as a bug
<cjwatson> and yes, it's not obvious
<cjwatson> nobody knows what sys is for
<cjwatson> AFAIK
<gaspa> Keybuk, sure.. i guess at the end of the month we'll have a shining new usplash
<cjwatson> if anyone does know, please tell me so that I can put it in the users-and-groups documentation
<cjwatson> too many of the other groups probably have users in them already
<pitti> I never saw 'sys' in use, that's why I mentioned it; probably some "hysterical raisins" case
<kaaloo> norsetto: sorry I had to go off to a meeting, I'm catching up on the thread thanks
 * pitti wants a "NOPTRACE/NOLDPRELOAD" file attribute
<kaaloo> tjaalton: thanks I will take a look right now at that
<Keybuk> pitti: like +d ?
<Keybuk> or is that a different !dumpable
<Keybuk> apparently that's different, oh well
<Keybuk> :p
<pitti> 'd'? that's not in chmod(1)
<Keybuk> chattr
<pitti> ah, chattr is ext2 only
<Keybuk> what's wrong with that? :)
<pitti> ah, that dump :)
<pitti> the mother of all backup solutions :)
<pitti> Keybuk: well, we don't prescribe people to use ext3...
<Keybuk> pitti: we should
<Keybuk> there was a wonderful talk at LCA, with a panel of kernel developers
<Keybuk> and someone asked the question "what filesystem do you use?"
<Keybuk> and they went down the list
<Keybuk> everybody put their hands up for ext3
<Keybuk> so if you're not running ext3, you're going to find the bugs first :-)
<Keybuk> AND be expected to fix them
<pitti> well, for this particular case it would even be ok
<pitti> since it's just an additional security measure, not essential functionality
<kaaloo> tjaalton: thanks that is another way to go I suppose.  What I did is merge that from libxcb1.1 where they ended up putting that LIBXCB_ALLOW_SLOPPY_LOCK workaround in the codebase.
<pitti> but anyway, I don't see anything useful in chattr
<pitti> (for ptrace/LD_PRELOAD)
<tjaalton> kaaloo: who's 'they'?-)
<Xteven> hi
<cjwatson> right, +d is dump(1) not dumpable as in core dumps
<Xteven> cjwatson: thx for the info, I got gfxboot working nicely
<cjwatson> Xteven: oh good
<tjaalton> kaaloo: note that newer java (like icedtea) should not have that bug
<cjwatson> I was hoping not to have to support .inc modifications ;-)
<Xteven> cjwatson: just one last question ;) I changed the f1.txt etc files, but they don't change in the graphical version of the bootmenu. Is there an easy way to fix that ? Or possibly just remove the Help button ?
<Keybuk> pitti: what was the problem with g+s ?
<pitti> Keybuk: well, that works; I'm just trying to avoid the pain of introducing a new static group
<pitti> Keybuk: since we want to use that approach in a large number of packages (maybe 10?) I'd like to avoid 10 copies of the postinst code for that
<kaaloo> tjaalton: :) oh I really don't know them, the libxcb1 maintainers at freedesktop.org.  Sorry for being imprecise !
<Keybuk> can't we do it in base-files ?
<Mithrandir> cjwatson: debconfiscation of base-passwd> wouldn't that just be to check if debconf is installed and if so, use that, if not fall back to read?
<cjwatson> Xteven: there's a corresponding help.xml in debian-installer/build/boot/x86/
<Keybuk> we're dropping plugdev, powerdev, netdev, scanner, etc. too? no
<cjwatson> Xteven: the duplication is unfortunate; I haven't finished the code to generate f*.txt from that XML file yet
<Keybuk> (powerdev surprised me, I'd never even *heard* of that one!)
<Mithrandir> Keybuk: it's only for powerful developers.
<kaaloo> tjaalton: If the jvm is easy to patch then it would be nice to have that in the package installation script
<pitti> Keybuk: those aren't static groups
<tjaalton> kaaloo: cannot be done
<gaspa> pitti: what packages won't be ptraced? (and why, just for curiosity?)
<tjaalton> kaaloo: because of the license
<pitti> gaspa: why> https://wiki.ubuntu.com/PolicyKitIntegration
<cjwatson> Mithrandir: (a) it really needs to be done in update-passwd.c so it probably needs a clone of debconfclient.h to do it in C (b) I have a bunch of other bugs asking for more fine-grained control and I'd really like to solve those at the same time
<cjwatson> Mithrandir: trust me, if I thought it were trivial I'd have done it already :-)
<Mithrandir> cjwatson: ah, ugh.
<pitti> gaspa: in short: disabling ptrace will stop the possibility to attach gdb to things like ssh, gksu, gnupg to spy out passwords from their memory
<ember> kaaloo check 161108
<Mithrandir> cjwatson: yes, I was wondering why, not disputing your assesment. :-)
<gaspa> ssh?
<gaspa> uh
<gaspa> pitti: that hurts.
<pitti> gaspa: I think this particular case might already been solved (cjwatson mentioned this recently), let me check
<Keybuk> pitti: plugdev is
<cjwatson> ssh-agent is setgid ssh, but ssh itself isn't
<cjwatson> so if you use an agent you're fine
<kaaloo> ember: thanks, it's exactly that problem, I just patched libxcb1.0.3 with the LIBXCB_ALLOW_SLOPPY_LOCK feature from libxcb1.1
<pitti> gaspa: this is a paranoia measure (not that it would be hard to spy passwords on an average user's box once you got in a trojan)
<tjaalton> kaaloo: err, what version of ubuntu are you using?
<kaaloo> tjaalton: hardy
<tjaalton> oh
<gaspa> pitti, i see, but all of that things won't works under fakeroot, (or umview, but this is not so much interesting )
<tjaalton> right, it's 1.0
<gaspa> right?
<pitti> right
<pitti> gaspa: but why would you want to run ssh or gnupg under fakeroot?
<Xteven> cjwatson: ok, thx I'll have a look
<gaspa> i'm not interested in fakeroot, but in umview :P
<gaspa> it use intensively ptrace for virtualize syscalls.
<mvo> Riddell: in gnome there is something called "gnome-settings-daemon" that sets the theme. is there a equivalent in kde? when I run a kde app in my gnome session it looks unthemed, anything I need to start here?
<cjwatson> gaspa: setgid doesn't stop root from ptracing things
<gaspa> cjwatson: it doesn't work under root
<pitti> gaspa: right, it's meant to stop programs in your user sessions; no way to stop root
<kaaloo> tjaalton: have to go off again, I'll need some help to get this into the distribution
<cjwatson> gaspa: perhaps it needs to for this
<gaspa> pitti, cjwatson: umview don't want to use root to virtualize things, but i understand that's a very few used package
<tjaalton> kaaloo: well, libxcb-1.1 will probably get in hardy, so..
<tjaalton> kaaloo: it was released two weeks ago
<kaaloo> tjaalton:gutsy has libxcb-1.0.3 too
<Riddell> mvo: unthemed as in looks like windows 95 square buttons?
<mvo> Riddell: yes
<tjaalton> kaaloo: yes, I thought that debian already had 1.1 but apparently not
<Riddell> mvo: which app are you running?
<mvo> Riddell: just a random one (kfind in this case). I'm running it in a virtual X environment, there is pretty much nothing else in it
<Riddell> mvo: does it create a file in /home/jr/.qt/qtrc ?
<mvo> Riddell: it looks like I do not have such a file
<Riddell> mvo: do you have permission to create one?
<mvo> Riddell: yes
<mvo> Riddell: ohhhh ... its currently root.root it seems, that might explain it I guess
<Riddell> mvo: fix that and run a kde app, hopefully it'll write a qtrc which uses plastik
<mvo> Riddell: hm, no luck. can you pastebin the content of the .qt/qtrc file? I will try with that one then
<Riddell> mvo: http://kubuntu.org/~jriddell/tmp/qtrc
<mvo> no luck, maybe I miss a theme package or something?
<mvo> this is for a good course, I'm playing with a screenshot generator
<seb128> mvo: a theme package for what?
<mvo> seb128: it looks ugly currently and we do want nice screenshots for kde apps, don't we :)
<mvo> seb128: http://people.ubuntu.com/~mvo/tmp/Kfind.desktop.png
<Mithrandir> mvo: when you have a little bit of time, I'd like to chat about application installation for mobile.
<Mithrandir> mvo: no hurry, though.
<Riddell> mvo: ah, my qtrc will use the kubuntu widget theme not the kde one
<Riddell> mvo: you can always run kcontrol and set it manually
<Riddell> Appearance->Style
<mvo> Riddell: ok, I try this now. what packages does the kbuntu widget theme belongs to?
<mvo> Mithrandir: I would prefer tomorrow, but if it does not take too much time I'm fine with today too
<Riddell> mvo: kde-style-polyester
<Mithrandir> mvo: either works for me
<mvo> Mithrandir: I just need to leave in ~20min
<seb128> mvo: maybe you need the gtk qt engine crappy thing
<Mithrandir> mvo: let's do it tomorrow then.
<mvo> Mithrandir: is it about the mobile-software-updates spec? or something different?
<Mithrandir> mvo: very much related to it, yes.
<Mithrandir> mvo: rather about your note at the bottom about just using apturl
<mvo> Mithrandir: that would be my prefered solution
<mvo> Riddell: thanks for your help, I think its nicer now
<mvo> seb128: god heavens no :)
<Mithrandir> mvo: you seem busy with your screenshot stuff, so let's just discuss it tomorrow, ok?
<mvo> Mithrandir: sure - the screenshot stuff is related to this too, its part of the content for a "install-from-here" website
<Mithrandir> mvo: sounds cool
<pitti> ogra, Riddell: do you have some time to merge the current ubuntu seed changes? there's quite a lot of changes, and I'm not sure about whether you want some of them
 * pitti merges gobuntu and xubuntu in the meantime
<Riddell> pitti: ok
<soren> pitti: Will you have time to do source NEW tomorrow?
<pitti> soren: yes, I think so
<soren> pitti: Excellent.
<pitti> last Friday I spent 3 hours on SRU and didn't feel like it any more
<pitti> but tomorrow I will have time
 * pitti looks at libpam-runtime.postinst and blinks
<ion_> Heh
<pitti> WTH should this md5sum check achieve?
<soren> pitti: It seems to check if common-* has been modified and if not, installs a fresh version?
<pitti> strawpoll: we will drop libpam-foreground from main, since we have ConsoleKit for that now; should we rather leave it in /etc/pam.d/common-session and live with the error message spew about a missing module in auth.log, or remove it from the default common-auth and drop the package entirely?
<soren> pitti: I assume the .md5sums contains the md5sum of all the different versions of the files ever shipped (or at least since 0.76-17)
<pitti> soren: right, but if the file is already identical to the one you check, why bother copying it?
<soren> pitti: There could be multiple md5sums in that file.
<pitti> soren: oh, I seee
<soren> pitti: So it sees if..
<soren> right.
<soren> :)
<soren> It's a bit icky, though.
<soren> If I've upgraded libpam-runtime at some point and found that I liked the old (default) version of e.g. common-auth better and reinstalled that, that postinst will overwrite it.
<soren> The right thing to do was to have the md5sums file have each line read: v1,v2,v3: <the md5sum of the file as shipped in v1, v2, and v3> and then have the grep also look for  $2, or something.
<ganeshhegd1> I installed AWN using http://ubuntuforums.org/showthread.php?t=385981  but how to run?
<soren> ganeshhegd1: Have you looked in your menus?
<soren> ganeshhegd1: I recommend you ask in #ubuntu, by the way. This channel is for development discussion.
<ganeshhegd1> k...
<pitti> soren: it only does it on particular upgrades (ATM if you upgrade from << 0.76-17)
<soren> pitti: Er.. yes?
<pitti> soren: so it won't always overwrite your changes
<pitti> I'll need to bump the version for hardy, though, if we want to get rid of libpam-foreground in common-auth
<soren> pitti: Sure, only if you're unlucky enough to have one of your files match an old md5sum.
<soren> pitti: It's probably an academic discussion, but still :)
<Mithrandir> asac: do you know why mobile-browser is Discussion rather than review or approved?
<pitti> slangasek: is there a particular reason to build pam against db4.5? I'm just about to drop the libpam-foreground patch, and while I'm at it I could drop that delta, too
<pitti> slangasek: AFAICS it was just a quick change before gutsy's release to drop 4.6, but now it's our default AFAICS
<Riddell> seb128: doing syncs?
<seb128> Riddell: yes
<seb128> Riddell: do you need one of those? ;-)
<Riddell> seb128: bug 164520 is all
<ubotu> Launchpad bug 164520 in k3b-i18n "Please sync k3b-i18n 1.0.4-1  (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/164520
<seb128> Riddell: I just did this one ;-)
<Riddell> seb128: perfect
<seb128> bug  #163383
<ubotu> Launchpad bug 163383 in k3b-i18n "Please sync k3b-i18n 1.0.4-1  (main) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/163383
<seb128> Riddell: can you close the duplicate?
<seb128> thanks
<Riddell> seb128: sure
<Propietario_> hola
<Propietario_> alguien puede ayudarme con grub error 17
<Propietario_> ??
<Propietario_> is someone in there that could help me with grub error 17?
<Sp4rKy> i guess it's not he good chan, try #ubuntu
<Propietario_> ok
<Propietario_> thanks anyway
<blueyed> pitti: can you approve the SRU nomination for bug 141516, please?
<ubotu> Launchpad bug 141516 in gparted "[MASTER] Gparted crashes when refreshing devices" [Medium,Fix released] https://launchpad.net/bugs/141516
<blueyed> calc: what about the OOo upload?
<pitti> blueyed: oh, fixing that would be great, thanks! done
<blueyed> pitti: great! thanks! actually it's fixed already. Maybe you want to sponsor the upload then, too? :)
<Mithrandir> cjwatson: what's the reason for ckbcomp running during boot, really?
<cjwatson> Mithrandir: it doesn't if console-setup has been properly configured beforehand
<cjwatson> Mithrandir: err. maybe it does. it isn't meant to
<cjwatson> Mithrandir: ckbcomp won't run if usplash is running
<LaserJock> pitti, cjwatson: are you guys aware of an queue or search that the Ubuntu Drivers can do to get release nominations?
<cjwatson> if usplash isn't running, you might hit an annoying corner case
<cjwatson> LaserJock: https://bugs.launchpad.net/ubuntu/hardy/+nominations - no idea if you can see that
<Mithrandir> cjwatson: mdz claimed it was, by inspection of the code, I haven't looked myself.
<LaserJock> I was just wondering if *you* can see it :-)
<cjwatson> mdz: ^-- details please :)
<cjwatson> LaserJock: yes
<Mithrandir> cjwatson: I can forward you the details, it was in private mails.
<pochu> LaserJock: I can, cant you?
<LaserJock> pochu: I can see it
<cjwatson> LaserJock: but I'm always curious which things I can only see due to extra privileges and which things are generally visible; there's no easy way for me to tell
 * blueyed can see https://bugs.edge.launchpad.net/ubuntu/gutsy/+nominations, too
<blueyed> ..apparently too many..
<Mithrandir> cjwatson: (sent)
<blueyed> But even the top OOo crashed has not been approved.. :/
<LaserJock> cjwatson: yes, I can understand that
<cjwatson> blueyed: we're not using nominations all that much at the moment; that may change
<cjwatson> at present, the nominations are largely set by the people who filed the bugs or have some enthusiasm for them, and have little to do with actual development plans
<cjwatson> obviously this is an unfortunate state of affairs
<pochu> cjwatson: would it make sense if only bug triagers were able to nominate bugs?
<pochu> (bug triagers and developers of course)
<pochu> although not every contributor who submits patches is in the triagers team...
<cjwatson> well, nomination != acceptance
<LaserJock> cjwatson: so does the Ubuntu SRU team check Fixed Released bugs then?
<cjwatson> I'm not sure whether it needs different privileges, or whether it needs better documentation, or both
<cjwatson> however there have been active discussions with the launchpad team about it
<cjwatson> LaserJock: what, all of them? certainly not
<LaserJock> cjwatson: blueyed's problem was that if the Hardy task is "Fix Released" then how will the Ubuntu SRU team know the SRU exists
<cjwatson> err
<cjwatson> somebody would follow the procedure documented on StableReleaseUpdates
<LaserJock> so nominations are the way to bring it up
<cjwatson> "Attach all of the information to the existing bug report, use Nominate for release to mark the bug for backporting, then subscribe the ubuntu-sru team."
<cjwatson> the SRU team uses their subscription page
<LaserJock> cjwatson: right, but that's the problem that blueyed is talking about
<LaserJock> if nominations aren't being accepted well, then Ubuntu SRU won't see the bug
<pochu> Hardy's task is closed, so it doesn't show in bug lists or searches...
<jdong> urgh stupid airport
<jdong> after 20 hours I am finally home for a 2hr flight.
<zul> jdong: thanksgiving isnt it?
<jdong> now excuse me as I collapse
<jdong> zul: yeah, string of canceled flights and extremely discourteous customer support
<cjwatson> LaserJock: pitti is the most active SRU team member, so check with him; I suspect he uses bugmail to track it
<cjwatson> blueyed: if you have a concrete instance of this problem, please bring it up
<LaserJock> there are 353 gutsy nominations, that's pretty difficult to wade through
<blueyed> cjwatson: I've just pinged pitti directly about the relevant bug (see above). I've already set a bug back to "Fix committed" for hardy, only to attract ubuntu-sru. My point is, that it's cumbersome having to "ping the right people", if LP could manage it.
<blueyed> LaserJock: 352 now. Probably pitti is approving them currently.. :)
<cjwatson> I'm declining some that I found also on the dapper list
<LaserJock> cjwatson: just because they are on the dapper list or because you already declined them on the dapper list?
<cjwatson> LaserJock: the latter
<cjwatson> because they're generally not appropriate for stable updates
<LaserJock> geeze, there are like 50 gutsy nominations for bugs just against Ubuntu
<LaserJock> I'm guessing "Support for important hardware components used in notebook computers" is not really gonna be a SRU
<LaserJock> :-)
<somerville32> Is it a regression?
<LaserJock> no
<LaserJock> and it's not filed against any package
<LaserJock> it's just "we should support more wifi cards"
<blueyed> cjwatson: you might want to approve bug 131526
<ubotu> Launchpad bug 131526 in openoffice.org "[gutsy] OpenOffice crashes/hangs with some Gtk themes (e.g. Crux)" [Critical,Confirmed] https://launchpad.net/bugs/131526
<cjwatson> blueyed: approved
<cjwatson> calc: ^-- FYI
<cjwatson> (in case you somehow missed seeing that :-))
<blueyed> Thanks. He knows about it though.. :)
<Kmos> palmer is Building ebug-http 0.31-1 since day 20th.. stopped there
<blueyed> Would it make sense to add the +nomination links to wiki.ubuntu.com/SRU ?
<cjwatson> they aren't quite right
<cjwatson> https://bugs.edge.launchpad.net/ubuntu/dapper/+nominations?field.subscriber=ubuntu-sru et al is better
<cjwatson> I'll add those
<blueyed> cjwatson: great. Thanks!
<cjwatson> done
<zul> whats MID on the employment page?
<ajmitch> mobile?
<zul> oh yeah..
<bmhm> hi
<bmhm> what about providing this as a package: http://linuxwireless.org/en/users/Download
<bmhm> It will allow bcm43xx-users to use more advanced wireless modes
<bmhm> not just bcm43xx as far as i can see
<kaaloo> tjaalton: back ! :)  was going through the log, so what could be the best way to handle the libxcb sloppy lock issue ?  Better to wait for libxcb1.1 for you ?
<bmhm> hi
<bmhm> what about providing this as a package: http://linuxwireless.org/en/users/Download
<bmhm> It will allow allow wireless-users to use more advanced wireless modes
<bmhm> can I get an "ack" please?
<tjaalton> kaaloo: yes
<lifeless> bmhm: ubuntu-motu might be a better channel to talk about new packages
<bmhm> lifeless: they told me to go here
<lifeless> ah, ok
<bmhm> ;)
<bmhm> It's a kernel issue anyway i think
<lifeless> there is also #ubuntu-kernel, but thats only useful if you are liable to actively help out
<bmhm> no it's just a mod
<bmhm> not even
<bmhm> a driver package which gives modules
<bmhm> I won't go anywhere else
<cjwatson> bmhm: I expect we'll be incorporating b43 into hardy; it is very unlikely to be updated in gutsy at this point
<bmhm> okay thanks cjwatson sounds good
<cjwatson> bmhm: our kernel maintainers are well aware of linuxwireless.org and are in contact with its maintainers from time to time
#ubuntu-devel 2007-11-23
<calc> cjwatson: yea know about the issue wrt OOo been working on it along with several other fixes for several days now
<calc> cjwatson: last bit left is to determine what feisty did for broffice splash and fix up gutsy's and then upload
 * calc was off today for national holiday
<calc> cjwatson: did you get my email last night about the openoffice.org-cd-reduction blueprint?
<calc> cjwatson: i was unable to post it since launchpad was down for a prolonged (longer than specified) outage which extended until very late local time
 * Hobbsee curses at hardy's borkenness
<calc> Hobbsee: whats broken for you?
<Hobbsee> calc: my X keeps freezing
<LaserJock> Hobbsee: threaten it with the DOOM stick
 * Hobbsee wonders what this laptop is even running
<calc> Hobbsee: oh :(
<Hobbsee> edgy, it appears
<Hobbsee> and if it doesnt blow up, i'll be in luck
<lifeless> Hobbsee: rofl
<Hobbsee> lifeless: i almost renamed this machine to OnFire for a reason!
<pwnguin> because it plays Frets?
<Hobbsee> no...
<Hobbsee> lifeless: i've had this thing up to 89C before
<lifeless> Hobbsee: miaow!
<calc> nice
<ajmitch> only 89?
<ajmitch> I suppose, it is a laptop
<calc> Hobbsee: that would probably kill a Core 2
<RAOF> Hm.  When does the autosync run again?  I'd like git-core to be installable again :)
<ajmitch> highest I've seen on one of my systems was 93
<ajmitch> that box is now dead, of course :)
<Hobbsee> and update-manager autofreezes.  yay
 * RAOF 's GPU hits 95 under load.
<LaserJock> my laptop keep shutting off a ~ 90C
<LaserJock> *kept
<StevenK> I've not seen how hot this machine gets
<RAOF> LaserJock: Tell it to push through the pain barrier!
<LaserJock> RAOF: I cracked it open and cleaned out the fan an put on fresh thermal paste
<LaserJock> now it's running 40-50C
<ajmitch> it feels like beer o'clock
<LaserJock> that reminds me of our wonder uni Apple support
<LaserJock> my labmate had an iMac that was constantly overheating and shutting down
<LaserJock> and she'd have to leave it of for a couple hours
<LaserJock> she called the help desk people and had the support guy come over
<Hobbsee> i think i'll upgrade X, and see what happens
<LaserJock> and he said "huh, why don't you just put a fan behind it?"
<LaserJock> so she ran it with a fan blowing on the back of it until it got fried in a power outage
<calc> the highest i've seen a cpu was in a desktop and that was in the 80s
<calc> was the regular operating temperature for the chip though
<RAOF> Heh.  That'd be one of the pentium 4s, right?
<LaserJock> geeze
<calc> an athlon 1200 (iirc)
<LaserJock> my desktop procs don't get above 50C
<ajmitch> sounds about right
<calc> somewhere around 185F
<ajmitch> my one that got to 93C was an athlon xp
<LaserJock> calc: did you check the thermal grease/tape?
<calc> it still did that temp even with a lapped heatsink and good thermal compound
<calc> it was on my dad's pc so i checked it out and apparently it was within specs
<LaserJock> my athlon XP 1800+ dropped ~20C avg temp after I redid the thermal compound
<calc> iirc the top temp it was rated for was ~ 95C
<calc> it wasn't an XP it was original athlon (chip based not slot)
<calc> my XP was much lower temps
<calc> iirc the max my XP got to was around 60C
<LaserJock> ah
<LaserJock> that sounds like mine
<calc> but that was many years ago so i am not certain about its exact load temp
 * calc wants a core octo ;)
<calc> build OOo faster!
<LaserJock> my athlon XP is my fastest machine still
<ajmitch> calc: what, in only 18 hours?
<StevenK> calc: Then buy an 8-core Niagra
<calc> i have a core 2 duo 2.8GHz
<calc> isn't niagra a bunch of low end cores?
<calc> in any case sun hardware is way to expensive
<StevenK> calc: Eight 1.4GHz SPARCv9 cores
 * calc wishes wine could run Adobe CS 3 already
<calc> ah, i thought they were crippled in some way to achieve that, maybe i am misremembering
<Hobbsee> sigh.  X broke.
<StevenK> LaserJock: You need an amd64
<LaserJock> StevenK: I do
<LaserJock> I just got a "new" machine
<LaserJock> a 1.7GHz P4
<StevenK> LaserJock: And we need ponies
<LaserJock> yep, working on it
<LaserJock> ah well, at least my computing situation isn't as bad as imbrandon
<calc> i'm going to try to hold out on upgrading until dec 2009
<calc> of course i love new machines so that will be hard, heh
<LaserJock> I should be graduating this spring
<StevenK> Why until then?
<calc> StevenK: 3 years since my last new machine
<LaserJock> and my reward is going to be a new laptop
<calc> hard drives and ram increases are so pathetic for the past 5 years that it probably won't even be worthwhile until then anyway
<calc> cpu are getting faster but not that much either
<calc> i bought a 2gb hard drive in spring 1996 and  100gb drive in oct 2001
<LaserJock> I'm just getting a bit behind with everything
<calc> and the largest available hard drive is still only 1TB now
<Hobbsee> it appears that gnome-control-center needs a rebuild.
<calc> it should be up to like 100TB by now
<TheMuso> calc: I'd say we are starting to hit the upper limits of current technologies.
<Hobbsee> no, a merge
<calc> TheMuso: yea way past the limit, heh
<persia> calc: There's also a price factor: 1TB today isn't very expensive.
<calc> from 5MB ~ 1985 to 100GB in 2001 to 1TB in 2006
<calc> persia: it costs more than 100GB in 2001
<persia> calc: I'll trust you: I haven't purchased a TB storage device since 1997, but it was expensive then.
<calc> 1TB in 1997 would probably have been in the 150K range (i would guess)
<calc> er $150K USD
<LaserJock> hmm, I could by a new laser for that
<persia> calc: We paid about 200k USD, but that included the routing HW, Digital support, etc.
<calc> i helped install a large 2 rack 250GB (max) worm drive system back around 1994
<calc> i bet that cost a large sum of money back then
<persia> 2 racks?  Anything with 2 racks is still expensive :)
<calc> looks like 1TB drive still costs ~ $280 USD now
<calc> persia: yea they were 12" WORM discs iirc
 * persia is amused that 1TB drives are currently cheaper than 10GB drives, which frequently sell for > 100,000 yen
<calc> why would anyone buy a 10GB drive, is anyone even still making them?
<TheMuso> IMO small drives still have their uses. Pitty they aren't as fast as the drives of today however.
<persia> calc: People seem to like them for vast farms of SparcStation 2s.  These are common in factory automation environments, etc.
<calc> well if they were manufactured long ago they are more likely to fail... so just buy the smallest modern drive, 100gb or whatever
<persia> calc: Not supported by ancient Solaris.
<calc> ancient solaris isn't supported either... is it?
<IntuitiveNipple> Interesting issue: xchat2 icon in the notification panel has just zoomed it's icon about 500% so all I can see is the top half of the X, and it is about 3x normal width... what'd cause that?
<persia> calc: Not by Sun, but turnkey vendors support it for the turnkey systems, as it's cheaper than porting to keep up, when one can just release a new turnkey, and migrate customers after the 8-10 year depreciation has finished.
<calc> ah
 * Hobbsee ponders if it's worth attempting to fixthis today
<Hobbsee> aww, crap
<Hobbsee> what am i supposed to do if ia have no more gnome-screensaver, and the machine has gone into powersave?
<Hobbsee> ah, shut it down remotely.  got it.
<pitti> Good morning
<Hobbsee> morning pitti!
<thegodfather> hey Hobbsee
<Hobbsee> hi thegodfather
<Hobbsee> thegodfather: why are you titled as such, today?
<thegodfather> Hobbsee: new nick
<Hobbsee> well, obviously, but why?
<thegodfather> you are gonna have to guess that :)
<Hobbsee> :P
<slangasek> thegodfather: because you're now a godfather?
<thegodfather> slangasek: i was before as well :)
<slangasek> because you've opened a pizza delivery service?
<thegodfather> slangasek: :)
<tjaalton> thegodfather: you are now in the waste management business?-)
<thegodfather> tjaalton: pizza delivery  :)
<tjaalton> thegodfather: so in a sense, yes :)
<DaBonBon> pitti: are you aorund ?
<DaBonBon> pitti: you'd told me that to change locale in kubuntu one needs to edit /etc/environment .. in that file on my machine i've put LANG="en_US.utf8" .. yet in konsole echo $LANG shows en_IN
<pitti> DaBonBon: hm, there might be something in KDE which overrides it, I'm not sure; but KDE certainly has its own language selector? Hobbsee?
<Hobbsee> pitti: pass.
<dholbach> good morning
<dholbach> can somebody please sync traverso from sid?
<dholbach> pitti: can you sync  traverso  from sid?
<DaBonBon> pitti: i don't think kde has it's own
<DaBonBon> wow, i guess i missed something.. brb.
<pitti> dholbach: done
<dholbach> pitti: thanks a lot, now I can close ONE of the 247684276426 needs-packaging bugs
<pitti> :)
<dholbach> http://people.ubuntu.com/~dholbach/sponsoring exploded
<pitti> oh, was it a new package from Debian?
<dholbach> yeah
<pitti> ah; please don't ask me to do that for a particular package in the future
<pitti> I was going to sync all new stuff from Debian today anyway
<dholbach> ok good :)
<pitti> and it's easier that way with source NEW etc.
 * pitti news
 * dholbach hugs pitti
 * pitti hugs dholbach *knuddel*
<dholbach> pitti: sorry for the extra-work - I got desperate, when I looked at the list :)
<pitti> NP
<DaBonBon> pitti: my fault, i didn't notice it .. it's deep somewhere in kcontrol ..
<DaBonBon> ty anyway :)
<DaBonBon> though shouldn't the system follow LANG from /etc/environment ?
<Hobbsee> DaBonBon: i suspect kde localisation is borked.
<DaBonBon> well after selecting US English from Kcontrol -> Regional and language settings -> System language -> Dialog box i could set it :D
<DaBonBon> Hobbsee: borked in what way ?
<Hobbsee> as in, doesn't work
<DaBonBon> oh ok ..
<DaBonBon> actually it's highly irritating that the installer sets the locale automatically .. atleast in the "Expert Settings" mode an option should be given to modify the locale :-/
<DaBonBon> https://bugs.launchpad.net/bugs/164648 -- :)
<ubotu> Launchpad bug 164648 in ubiquity "Allow user to select preferred locale" [Undecided,New]
<MacSlow> Greetings everybody!
<pitti> hey MacSlow
<MacSlow> Tag pitti
<StevenK> Hum.
<StevenK> The new gimp provides is own printing plugin, conflicts with gimp-print, and now gimp-print is gimp-gutenprint
 * StevenK merges gutenprint
<DaBonBon> https://bugs.edge.launchpad.net/ubuntu/+source/sun-java6/+bug/127053 could someone triage this and mark it as New if required ?
<ubotu> Launchpad bug 127053 in sun-java6 "Problem in sun-java6-jdk documentation" [Low,Fix released]
<DaBonBon> (sorry, I meant that for #ubuntu , not here ! )
<mdz> cjwatson: regarding your question from yesterday evening, what I pointed out was that ckbcomp will be run at boot (via setupcon --save) *unless* the init.d script detects itself being run by init.  the mobile folks have observed (via bootchart) ckbcomp running, so I inferred that that logic was not working
<warp10> Hi all!
<milos> hello, i have a bug to report, who do i turn to?
<\sh> milos, http://www.launchpad.net/
<pitti> hi warp10
<milos> thc
<milos> thx
<warp10> pitti: hi martin! I got your mail, thanks. :)
<pitti> whoops
<milos> \sh can you give me a direct link to the official kubuntu section?
<pitti> sorry guys for the source NEW spam on -changes (new sources from Debian, forgot to disable mail)
<milos> there are a lot of ubuntu/kubuntu entries, i don`t know where to post my problem
<\sh> milos, there is no special kubuntu section...you need to know the package name and search for it...and file the bug against the package
<milos> well.. what is the package that runs the bootcd installer? :)
<\sh> pitti, debian removed ircii-pana from their archive....can we remove it from hardy as well now? there is a bug filed already
<\sh> milos, debian-installer?
<milos> not that one
<milos> the graphical one
<\sh> ubiquity
<pitti> \sh: I'll do some mass-removal processing soon
<Fujitsu> pitti: I fail to see a problem in changes going to -changes.
<pitti> \sh: as well as traverse the bug list
<milos> ok
<\sh> pitti, cool thx :)
<pitti> Fujitsu: traditionally we don't mention autosyncs from Debian
<milos> and for kubuntu?
<milos> (the same thing happens in both distros)
<\sh> milos, it's the same...
<milos> thx!
<Fujitsu> pitti: Right, which I think is a bit strange.
<milos> you have been very helpful!
<\sh> milos, ubiquity has a gnome and a kde frontend...it's the same package
<milos> ubiquity does not use Launchpad as its bug tracker.
<milos> :/
<milos> meh, nevermind
<milos> i`m prolly the only one that has that problem :(
<milos> i`ll just use alternative cd and debian-installer
<soren> pitti: I agree with Fujitsu. I realise it would increase the volume significantly, but I subscribe to *-changes to see what changes in Ubuntu, and new stuff (new packages or just new versions of packages) from Debian that gets imported is still a change to Ubuntu.
<soren> pitti: If I really wasn't interested, it would not be that hard to make a procmail rule that discarded any mail to *-changes that didn't have "ubuntu" in the subject.
<pitti> that's a lot of mail for autosyncs, especially for the first one (some 2000 mails!)
<Ng> milos: its "upstream" project page does say it doesn't use lp for bugs, but you can still file bugs at https://bugs.launchpad.net/ubuntu/+source/ubiquity/
<pitti> and if you are interested, you better read debian-changes
<soren> 2000 interesting mails, IMO :)
<pitti> soren: by the same argument we don't get changelogs from other upstreams either
<soren> pitti: Hm?
<pitti> soren: well, that list is meant to describe changes Ubuntu folks did to Ubuntu, not our upstreams
<soren> pitti: Updating package foo from version 1.0-1 to 2.0-1 in Ubuntu is a change to Ubuntu. Regardless of the origin of the update.
<soren> pitti: Ok, rephrasing: I'd really like to have some way of getting notified about *every* upload to Ubuntu, and I really consider *-changes the most suitable place for that sort of thing. Maybe we could add some additional headers to the mails there, so that people could more easily filter out automatic syncs or whatever.
<soren> pitti: I've not completely understood your argument about other upstreams.. Which other upstreams are we talking about? Could you give an example?
<pitti> then I think we should revive https://lists.ubuntu.com/archives/ubuntu-changes-auto/
<pitti> soren: we don't put the changelogs from OO.o, Gnome, etc. to that list either
<pitti> just Debian's changelogs for autosyncs (which we don't do usually)
<soren> pitti: Indeed, but there's a mail on that list when there's a new oo.o upload.. If I'm interested in the details, I can look them up.
<pitti> having a separate ML seems more appropriate to me, and you can sort them into the same folder if you want
<soren> pitti: The difference between OO.o, GNome, etc.  and Debian is that a change in OO.o doesn't change anything in Ubuntu until someone uploads said change, but a change in Debian does.
<pitti> right
<pitti> soren: so WDYT about -changes-auto@?
<soren> pitti: It would indeed solve my problem.
<soren> pitti: I'm just still puzzled why it's a separate list.
<soren> pitti: I don't think automatic changes are any less relevant than UBuntu specific ones are.
<pitti> most people are interested about things Ubuntu devs change in Ubuntu, and getting 2000 mails on one day is not generally considered nice by many people
<pitti> so providing an opt-in with -changes-auto seems better to me than starting to spam people
<pitti> soren: they aren't less releavant
<pitti> for the functioning of Ubuntu
<soren> pitti: I don't know "most people", so I can't say anything about what they're interested in. I can only say that if I subscribe to hardy-changes that early in the release cycle I wouldn't be one bit surprised to get a massive flood of mails about stuff that gets imported. I'd expect it.
<pitti> but they are less interesting to many people to read the details about them
<soren> pitti: I don't think we'll get much further with this discussion. Reviving auto-changes will give me the info I want, so that's fine.
<pitti> ok, great
<soren> I reserve the right to think it's odd, though :)
 * Hobbsee finds it annoying that the merge bugs are just filled with "remaining ubuntu changes" but you rarely tend to see what *debian* has changed
<persia> pitti: While I tend to read changelogs from sources other than the mailing list, finding Debian changelogs with which I disagree is a common prompt for me to make an Ubuntu upload.  I'm only interested in a subset of packages, but for someone with wider scope, the ML may be a strong point.
<persia> Hobbsee: Kick it back if they don't include the Debian changelog.
<Hobbsee> but that may well be because of the options used for merging
<Hobbsee> persia: it's auto-accepting
<Hobbsee> as in, debian changelog is there, but not shown in the mails to -changes
<soren> Hobbsee: If people don't debuild -v<last ubuntu version> someone should politely tell them to do so.
<persia> Hobbsee: If it's not shown in the mail, the uploader made a mistake: one should always generate a changelog containing all changes since the last Ubuntu release.  I use `debuild -S -v(last ubuntu version)` for that.
<Hobbsee> soren: or have keybuk yelling, yes.
<soren> Hobbsee: Well, yes, depending on who did it.
<soren> Hobbsee: If it's one of his minions, sure :)
 * Hobbsee taught this room a whole new expletive that day...
<Hobbsee> soren: he doesn't only blast his minions for it
<Hobbsee> unless i'm suddenly a minion, without realising.
<soren> Hobbsee: oh :)
<Keybuk> When did I yell?
<Hobbsee> Keybuk: a while ago, when i didnt use MoM at all.
<Keybuk> I bet I didn't tell
<Keybuk> yell
<Keybuk> see, I can't even spell yell
<Hobbsee> sure?
<StevenK> I remember cjwatson telling someone about -v
<TheMuso> I have a package I am trying to merge, which is a frontend for another package in the archive. The backend package in question uses libgcrypt11, which recently had its .la file moved from /lib to /usr/lib. The frontend FTBFS on this, as the .la can't be found in /lib. However, attempting to rebuild the backend package results in the package still assuming that the .la file is in /lib, when its in /usr/lib.
<TheMuso> The libgcrypt11 .la file is listed in several .la files in the backend package, in the dependency_libs field.
<TheMuso> I've noticed that libgcrypt11 uses clean-la.mk for use with cdbs. I am wondering whether I should re-upload the backend package with this code in debian/rules, to clean the .la files. I've tested this, and it allows the frontend package (my merge), to build. I am wondering however, whether this is the right approach to take.
<Mithrandir> TheMuso: cleaning .la files is fine, on a general basis
<TheMuso> Mithrandir: Ok. I guess the only other question then, is whether this code will be put into something else that is usable by packages that use staright debhelper, which this backend package does. If not, I'll copy/paste and modify the clean-la.mk cdbs code accordingly for the package.
<TheMuso> straight*
<pitti> TheMuso: I added the sed to gnutls13, which doesn't use cdbs (AFAIR)
<pitti> TheMuso: it took us about 5 uploads until we tamed those *($#$# .la files enough to not break libgpg-error/gnutls13/libgcrypt11 any more
<pitti> TheMuso: unfortunately we had to put it back
<pitti> TheMuso: but putting it into /lib is useless, libtool doesn't find it there
<Mithrandir> pitti: why did we have to pit it back?
<Mithrandir> put, even
<mvo> doko: hello! I'm currently checking my stuff to forward to debian and noticed that python-gamin-dbg is something we may want to forward. is there a spec or anything that explains a bit about the rational for the python-dbg packages? I would like to have something to point people at when sending the diff to debian
<pitti> I forgot, someone else did that; /me checks changelog
<pitti> hm, StevenK, why did you put back the .la to libgpg-error again?
<pitti> libgpg-error (1.4-2ubuntu7) hardy; urgency=low
<pitti>   * Add symlink from /lib/libgpg-error.la to /usr/lib/libgpg-error.la
<pitti>     since /lib is where other .la files expect it to be
<pitti>  -- Jonathan Riddell <jriddell@ubuntu.com>  Thu, 15 Nov 2007 23:19:09 +0000
<pitti> TheMuso: ^ maybe you have to do that as well, but this is REALLY EVIL
<TheMuso> pitti: heh, it does sound rather evil.
<Riddell> if I have been evil, it is because I was standing on the shoulder of evil giants
 * pitti hugs Riddell
<pitti> it seems that three long-experienced developers haven't found a proper way to make .la files work for stuff in /ilb
<pitti> /lib even
<pitti> Riddell: standing on the thin and shaky evil libtool ground? :)
<TheMuso> Sounds wonderful.
<Mithrandir> we could, like, clean out those other .la files.
<Mithrandir> I'd recommend that, especially now that we're in free-fire-mode.
<TheMuso> In the case of the backend package, nothing goes into /lib, but its .la files point to the libgcrypt11 .la which it still thinks is in /lib, which it isn't... If the autotools foo was rebuilt for that package, would that change anything? Or, should I just clean the .la files and be done with it?
<pitti> TheMuso: if it works without a .la at all, then this is preferable IMHO
<pitti> TheMuso: but we need to remove .la files top-to-bottom, and clean their stated dependencies bottom-to-top
<TheMuso> Right.
<TheMuso> But if the .la files were removed from the backend -dev package, what is the likelyhood of something needing to be changed in the frontend package?
<TheMuso> To not rely on the .la files
<pitti> TheMuso: AFAIK, in the worst case, it FTBFSes and you need to remove the .la files from the reverse dependencies, too
<doko> mvo: have to write this p
<doko> mvo: the rationale is to provide an extension to be used with the python-dbg interpreter
<TheMuso> pitti: I'm not that knowledgable with autotools.. What reverse dependencies are you referring to in this context?
<pitti> TheMuso: reverse build dependencies I mean
<TheMuso> pitti: Ah ok.
<mvo> doko: thanks, I found https://wiki.ubuntu.com/PyDbgBuilds
<pitti> TheMuso: e. g. if we would remove the .la files from libgpg-error-dev, then we would likely break the build of everything that build-depends on libgpg-error-dev
<mvo> doko: it would have been cool to get a mail about this to ubuntu-deve-announce, it looks incredible useful
<TheMuso> pitti: Yep, I understand now.
<pitti> TheMuso: which is why we just remove the 'dependencies' line from its .la, so that it does not spread any superfluous dependencies any more and not pull in the lower-level .la files any more
<Mithrandir> .. and then we can get rid of the .la files in the next round.
<pitti> right
<TheMuso> pitti: Ok, so I'll just clean the .la files. Thanks for your explanations and help.
<pitti> TheMuso: you're welcome; for non-cdbs; please look at gnutls13
<TheMuso> pitti: Will do, thanks again.
<pitti> TheMuso: hm, no, it wasn't gnutls13, that's cdbs, too
<pitti> TheMuso: but well, it's just copying the sed -i, so it's no big deal
<doko> mvo: hmm, didn't we do this for feisty?
<StevenK> pitti: But I didn't...
<pitti> libgpg-error (1.4-2ubuntu4) hardy; urgency=low
<pitti>   * Install the .la again. Libtool, I will have my revenge!
<TheMuso> pitti: Yeah, figured as much.
<pitti>  -- Steve Kowalik <stevenk@ubuntu.com>  Mon, 05 Nov 2007 10:13:41 +1100
<pitti> StevenK: I know there was a reason for it, but I forgot
<StevenK> pitti: Oh right, um, because it meant libtool went looking for it and then bitched it couldn't find it
<mvo> doko: I can't find it here, maybe I overlooked it, but it seems to be not in my mailbox
<seb128> doko: right, it's create load of extra work, would be nice to write some announce mail to debian about those and send the patches we have to the bts
<seb128> it should have been made much early, we have lot of packages patches for that an often the debian/rules is changes are not trivial
<rexbron> mr_pouit: Has the patch to stop gimp segfaulting with murrine been sent upstream. (It is in the debian package though)
<dholbach> MOTU Meeting in 8 minutes in #ubuntu-meeting
<dholbach> pitti: MOTU Meeting :)
<pitti> dholbach: joined, thanks
<dholbach> thanks pitti
 * highvoltage also attends for a change
<carlos> pitti: hi
<carlos> pitti: sorry for bother you again... what's the status of language pack generation?
<pitti> carlos: they should all be in PPA, and I got some initial good feedback
<carlos> are they in proposed already?
<rexbron> mr_pouit: There is a major issue with the murrine package
<rexbron> mr_pouit: the debian package does _not_ clean the patches when it builds the package. Afaict, it is in the debian rules, but was not called by the DD when it originally created
<dholbach> thanks pitti
<pitti> my pleasure, not much to do :)
<pitti> carlos: I'll do that now
<Hobbsee> Fujitsu: i see what you mean about this -intel driver being rather tempramental
<Fujitsu> Hobbsee: Yeees.
<Fujitsu> Dieing on me a lot tonight.
<Fujitsu> Hobbsee: Why did you upgrade?
<Hobbsee> Fujitsu: because of something else i upgraded, which gave me random syslocks.
<Fujitsu> Ah.
<Hobbsee> as in, X would entirely freeze, at random, with no way of fixing it, it appears
<Hobbsee> yeah, 20 mins, and it had already crashed.
<Fujitsu> -intel does that too, but with the added bonus of killing everything regularly.
<Hobbsee> heh
<Hobbsee> wonderful
<Fujitsu> Although you can sysrq and suspend out of it, which is good.
<Fujitsu> Hahahah.
<pitti> seb128: new bug-buddy requires libelf-dev, which needs a MIR
<Fujitsu> Hobbsee: Again?
<dholbach> MOTU Q&A Session in #ubuntu-classoom in 20 minutes
<Hobbsee> there we go.
<Hobbsee> twice in 25 mins.  this could get fun.
<ogra> pitti, uuuh, we'll have pulse in desktop now ?
 * ogra just sees the changelog for edubuntu-desktop ... thanke for uploading btw
<pitti> ogra: yes; you don't want it in edubuntu? I thought you were yearning for it
<pitti> ogra: I merged your seeds, BTW (I think I didn't screw them up too badly)
<ogra> pitti, i'm not sure the ltsp alsa emu works if pulse is installed locally
<pitti> ogra: well, feel free to kick it out again
<ogra> i dont care, i still have some months to fix them :)
<Fujitsu> Hobbsee: I've had it within 5 minutes of restarting twice tonight.
<ogra> welll, there wont be an edubuntu desktop like you knew it anymore after we redid the edubuntu CD design
<Fujitsu> And sometimes suspending doesn't work, which is annoying.
<ogra> the point is that i will just depend on ubuntu-desktop and edubuntu-desktop only adds artwork and a basic set of edu apps
<Hobbsee> Fujitsu: bring on the new kernel :)
<Fujitsu> Hobbsee: Why?
<Hobbsee> Fujitsu: because then we get the new -intel
<Fujitsu> Hobbsee: I have the new -intel.
<Fujitsu> It doesn't actually need the new kernel.
<Hobbsee> Fujitsu: doesn't it require something or other from the kernel?
<Hobbsee> that any better?  presumably not.
<Fujitsu> It says it does, but apparently not.
<Fujitsu> No, it's really not.
<ogra> pitti, i actually thoght we were beyond the time where we need sound daemons
<Fujitsu> Though I have had a couple of periods where it has gone for upwards of 12 hours.
<ogra> what for do we add pulse ? only for the system sounds ?
<Fujitsu> But other times just a few minutes or seconds.
<pitti> ogra: apparently not, see the PulseAudio spec (lots of use cases)
 * ogra goes looking ...
<pitti> seb128: FYI, I'm traversing through http://people.ubuntu.com/~ubuntu-archive/testing/hardy_outdate.txt and give back some failed buids on the way
<ogra> hrm ... no hal or consolekit on ltsp clients ... that will get tricky
<pitti> doko: the ocaml merge blocks some packages from getting built; however, do we really need ocaml-native-compilers on lpia? (that's our only change)
<Mithrandir> pitti: I don't think we care about ocaml on lpia
<pitti> Mithrandir: the interpreter still works, and few packages need the native compiler
<pitti> Mithrandir: so ok to sync that?
<pitti> (nothing in main b-deps on -native-compilers)
<Mithrandir> pitti: I don't mind, at least.
<pitti> let's do it then, for the sake of avoiding unnecessary work
<pitti> Mithrandir: thanks
<doko> Mithrandir, pitti: As long as we don't have a simple way to sort out the packages in main not needed for lpia I would prefer to have the package be buildable, or else these show up as build failures
<doko> pitti: please don't, you create extra work for buildd admins
<pitti> doko: how so? it's simply not built for lpia then
<doko> pitti: but other packages do fail?
<pitti> doko: which? as I said, there's exactly one rdepends in the entire universe
<doko> ahh, ok
<pitti> (dag2html)
<pitti> this won't be built on lpia then either
<pitti> but *shrug*
<pitti> doko: your call, though, if you want to do the merge, I don't object :)
<doko> pitti: no, I don't care about universe build failures anymore =) these can be sorted out now with the help of new mail headers
<pitti> ok
<carlos> pitti: ok, thanks
<pitti> seb128: eww, and gnome-games wants guile-1.8 now; MIR or drop that feature?
 * StevenK tries to sort out gutenprint
<doko> drop gnome-games ;p
<pitti> Riddell: are you aware of the kdebase FTBFS?
<ogra> doko, !
<Riddell> mm, don't think so pitti
<pitti> Riddell: and kdebindings is depwaiting on libgtk1.2-dev; I think it'll cost you lots of beer to convince me to promote that again :-P
<Riddell> hrm, hal badness
<Riddell> pitti: that'll be an oversite, I'll remove it
 * pitti gives back kdebluetooth and hopes for the best
<pitti> Riddell: thanks
<seb128> pitti: hum, I think we could build with guile-1.6 again, but might it would make sense to try switching main to the new version?
<seb128> s/might/maybe
<pitti> seb128: ah, indeed, wasn't aware of 1.6; absolutely!
<pitti> -- hardy/main build deps on guile-1.6-dev:
<pitti> autogen
<pitti> graphviz
<pitti> swig1.3
<seb128> I've no idea on how much change between 1.6 and 1.8 and how easy it would be to make those use the new version
<seb128> but that's not too many package, easy to give it a try
<StevenK> pitti: So, cupsys-driver-gimpprint, foomatic-db-gimp-print, and ijgimpprint are all transistional packages in Dapper - do they need to stick around for Hardy as well?
<pitti> StevenK: if they were only used for upgrading *to* dapper, then we can drop them
<pitti> anything used for upgrades *from* dapper needs to stay until after Hardy's release
<doko> ogra: ?
<StevenK> They were dropped since Etch released, I'm not sure
<ogra> doko, dropping gnome-games ...
<StevenK> pitti: Let me check Breezy
<pitti> dh_install: kdepim-doc missing files (/usr/share/doc/kde/HTML/en/kdepim-apidocs/*), aborting
 * StevenK blows the dust off of his Breezy chroot
<pitti> make: *** [binary-install/kdepim-doc] Error 1
<pitti> Riddell: ^ another one for your list (i386 only FTBFS)
<pitti> StevenK: *cough*
<StevenK> Heh, sorry
<StevenK> pitti: It became a transitional package in between Breezy and Dapper.
<StevenK> Er, they did, rather
<pitti> StevenK: ah, it should have been dropped long ago then
 * doko watches more StevenK fallout and hides ;)
<StevenK> doko: Hmph
<StevenK> doko: Next time I see you I'm going to tickle you :-P
<StevenK> pitti: Okay, Debian killed them, they can stay dead.
 * pitti sobs on http://people.ubuntu.com/~ubuntu-archive/NBS/; what an awful amount of review work
<StevenK> Yeah, I suppose I should do some NBS work
<Hobbsee> Fujitsu: *grumble*
<pitti> StevenK: I removed some NBS I cross-checked
<seb128> pitti: you should better not hammer on it that early in the cycle
<pitti> StevenK: problem is that it has a lot of noise from needsbuild packages
<StevenK> After I merge gutenprint and stop being seb128's bitch
<seb128> StevenK: do you plan to do your abiword merge btw? ;-)
<pitti> seb128: well, alpha 1 is in one week, and at least hardy_outdate.txt needs constant attention
<seb128> pitti: NBS is not really revelant for alpha
<pitti> seb128: right; but outdate is
<seb128> indeed
<pitti> I was just whining, not planning to spend my afternoon on it, don't worry
<StevenK> seb128: Why do you care, it's universe? :-)
<seb128> StevenK: it's not
<StevenK> Oh.
<StevenK> Silly me.
<StevenK> seb128: Added to my mental list after gutenprint and gimp.
<seb128> StevenK: thanks
<StevenK> My mental list is like a steel trap, though.
<StevenK> (Rusty and illegal in 6 states)
<seb128> pitti: autogen builds fine with guile-1.8, I'll file a Debian wishlist to use guile-1.8-dev | guile-1.6-dev | libguile-dev
 * pitti hugs seb128, thanks
<seb128> you're welcome
 * seb128 hugs pitti back
<jpatrick> pitti: thanks for the backport
<pitti> jpatrick: you're welcome; welcome in the backporter team!
<seb128> I'll also look to graphviz and swig1.3
<seb128> new backporters?
<doko> new swig version?
<seb128> doko: no, swig1.3 is one of the few packages using guile-1.6 and I'm looking if we could switch those to guile-1.8
<seb128> I'm speaking about main there
<seb128> doko: any opinion on the topic?
<doko> seb128: no, guile-1.8 is still beta, isn't it?
<seb128> doko: not sure, if that's the case we should switch gnome-games back to 1.6
<ogra> sounds messy
<doko> seb128: ahh, no, that was ruby1.8
<StevenK> Oh, *TWITCH*
<StevenK>   C  scripts/config.guess
<StevenK>   C  scripts/config.sub
<seb128> doko: ok
<seb128> pitti: would a Build-Depends on guile-1.8-dev | guile-1.6-dev work? or does it need to be the other way?
<pitti> seb128: no, that works
<seb128> ok, will do that for now then, so it builds
<pitti> cool, thanks
<seb128> you're welcome
<pitti> seb128: any idea why python-gobject-doc is not built any more? dropping -doc packages doesn't seem very obvious to me
<seb128> pitti: it has been merged back to -dev to lower the delta with Debian
<pitti> ah, great
<seb128> pitti: I'll merge pygtk today
 * pitti hugs pygtk
<seb128> pitti: in case you are having a look at what needs fixing, it's on my list already
<pitti> seb128: ah, great, thanks
<seb128> no problem
<pitti> yay, I'm through hardy_outdate.txt
<so1> hi
<so1> looks like gtk or something is broken ...
<so1> get an error about setuid, and something that it's not supported to run gtk as root after logging into gnome
<pitti> so1: that's a feature, not a but
<pitti> so1: which application do you try to run?
<so1> pitti: i can't even run an app
<so1> i just log into gnome via gdm
<ion_> As root?
<so1> gdm works, but after i typed my password and pressed enter nothing happens, and i get that error
<so1> no
<pitti> no, it complains about suidness, not root
<so1> my normal sudo account
<pitti> so1: any third-party applications/drivers/etc.?
<so1> no
 * pitti is afraid of another story like the Samsung printer drivers which made OO.o suid root
<seb128> where does it complain about setgid?
<StevenK> Twitch
<so1> bad thing is, i would try to do a aptitude update, dist-upgrade, but i don't get an internet connection anymore
<pitti> likely because network-manager applet doesn't start
<so1> "this session lastet less than 10 seconds blablabla
<so1> and when i open ~/.xession-errors:
<seb128> those errors are "normal"
<seb128> that's due to some gdmflexiserver calls
<seb128> not likely what creates your issue
<seb128> you said that nothing happens
<seb128> and then that the session exit
<seb128> which one is true there?
<seb128> does it hang or does it exit rather?
<seb128> and what version of ubuntu are you using?
<so1> hardy
<so1> sorry, just tried to get the error message
<so1> don't really know
<so1> mouse doesn't move anymore
<seb128> pitti: can you give a retry to the lpia libgnomekbd build?
<pitti> seb128: done
<seb128> thanks
<so1> wth? i copied the error message to an usb stick and now it isn't there anymore
<so1> http://ubuntuusers.de/paste/18626/
<so1> here it is ...
<so1> most important thing would be an internet connection, it is statically configured, no dhcp
<so1> but even a ping to the router fails!
<seb128> nothing useful there
<so1> ok
<seb128> does starting an another session than GNOME works correctly?
<so1> "xterm could not be found to start a recovery session"
<seb128> your install is in a weird state
<seb128> is gnome-session event installed?
<seb128> dpkg -l gnome-session
<so1> even starting kde4 i get the same gtk setuid error
<seb128> the warning is a gdm known issue and not breaking your login
<so1> is that an "i" or an "l" behind dpkg?
<seb128> L
<so1> ah ok
<seb128> a small one
 * StevenK wonders where Till is hiding
<so1> the output: thousands of "=", then at the end "the gnome 2 session manager"
<seb128> ?
<pitti> StevenK: better mail him, he isn't on IRC very often
<seb128> so1: you have a column describing if the package is installed or not
<so1> first the screens fills with ==============================================
<so1> and after a few seconds the screen is cleared and at the end "the gnome 2 session manager"
<so1> nothing more
<seb128> what did you type there?
<so1> dpkg -l gnome-session
<seb128> you have a line starting with gnome-session then
<pitti> this is such a lot of unspecific breakage that I'd advise a memory and file system check
<seb128> right, something weird is going on there
<seb128> looks like a local computer issue and not a distribution one
<so1> mhhh ok
<so1> the laptop worked!
<so1> it broke after an dist-upgrade a few days ago ...
<so1> how can i get into the internet from the commandline to update my system?
<pitti> so1: what does 'apt-get -f install' say?
<pitti> so1: try 'sudo ifup eth0'
<so1> i thought configuration isn't needed, if i have it statically configured
<pitti> but apt-get -f install works without net
<so1> apt-get has no problems
<pitti> (for the diagnosis anyway)
<so1> "ifup: interface eth0 already configured"
<pitti> so1: so it should be up?
<so1> ping 192.168.1.1 -> destination host unreachable
<pitti> route -n
<so1> i even brought it down and did it again ... :-(
<pitti> this should now be handled -> over there, but not in #devel any more
<so1> http://ubuntuusers.de/paste/18627/
<so1> sigh ...
<pitti> that looks fine
<so1> the router is 192.168.1.1
<so1> and the ip of the laptop 192.168.1.20 ...
<so1> i don't know what i did wrong :-(
<pitti> so1: please pastebin 'dmesg' output
<pitti> (or inspect it first for some obvious error messages)
<theunixgeek> what's the EOF under Ubuntu GNU/Linux?
<theunixgeek> found it - ^d
<mdz> bizarre
<pitti> yeah, that changed last week
<so2> http://ubuntuusers.de/paste/18628/
<StevenK> Hah
<pitti> so2: nothing there; so: 1. close yes, 2. reboot world, 3. wake up from this bad dream
<so2> :-(
<so2> i just don't get it, why can't i even ping my router?! :-(
<so2> i guess i'll get my ubuntu cds and reinstall :'-(
 * so2 starts to cry
<mvo> pitti: do you need a MIR report for cwidget? its just a split out from the old apittude codebase into its own lib
<pitti> mvo: no, that's fine
 * pitti bites into the table
<pitti> so I wated 70 minutes just to find out about a totally counterintuitive Python misbehaviour
<pitti> wasted, even
 * ogra hands pitti some mustard
 * Hobbsee removes the table
<pitti> Python experts, can http://people.ubuntu.com/~pitti/tmp/default_args.py be justified somehow? or is this worth a bug report?
<pitti> (I know why the implementation does that, but it shouldn't IMHO)
<mvo> pitti: IIRC this is documentend
<pitti> it works as intended with scalars, but with complex objects it doesn't instantiate a new one each time you call the function
<mvo> pitti: http://www.network-theory.co.uk/docs/pytut/DefaultArgumentValues.html (under important warning)
<pitti> ah, http://docs.python.org/ref/function.html mentions it
<mvo> yeah, that too
<mvo> just found it there too, I couldn't remember where I read it initially :)
<pitti> "Default parameter values are evaluated when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that that same ``pre-computed'' value is used for each call."
<pitti> that contradicts itself, though, but I see the point
<Keybuk> pitti: right, you define a dictionary as the default argument
<Keybuk> so it's the same dictionary for all instances of that function
<Keybuk> same for objects, etc.
<pitti> so I'll modify the code to use {} when it is None, that's safer
<Keybuk> that's the usual idiom, yes
<Keybuk> Python consistently behaves like that
<Keybuk> so although it's surprising the first time you come across it
<Keybuk> it doesn't surprise you later by behaving differently
<Keybuk> (the same holds true for decorators, parent classes, etc.)
<Keybuk> a justification for why it behaves like that:
<Keybuk>   def foo():
<Keybuk>     pass
<Keybuk>   def bar(func=foo):
<pitti> Keybuk: it just surprised me that it already instantiates formal parameters at function defintion time; that's quite counterintuitive
<Keybuk>     func()
<Keybuk>   def evil():
<Keybuk>     pass
<Keybuk>   foo = evil
<Keybuk>   bar()
<Keybuk> (will call foo not evil)
<pitti> $ devhelp
<pitti> devhelp: error while loading shared libraries: libgtkembedmoz.so: cannot open shared object file: No such file or directory
<pitti> *sniff*
<pitti> file:///usr/share/doc/python2.5-doc/html/lib/module-xml.etree.ElementTree.html
<pitti> whoops, sorry, wrong window
<pitti> mvo: cwidget promoted, and I bumped the build score to actually get builds soon
<so2> hi
<so2> does someone know when network manager will be updated?
<so2> 0.6.5 is a pita
<so2> someone?
<Ng> isn't 0.6.5 the most recent version?
<pitti> I heard stories about 0.7
<gaspa> pitti, but does usplash 0.5.8 works? (i'm not able to make it work, without any changes of mine)
<pitti> gaspa: current hardy usplash works, yes
<gaspa> mmm... i'm in gutsy, could be this the problem?
<pitti> works there, too
 * gaspa crying...
<pitti> usplash only changed a tiny bit since gutsy
<dholbach> so2: there was no new release since 20-Apr-2007 (0.6.5)
<mvo> pitti: cool, thanks
<so2> dholbach: fedore shipped a newer one, don't know if it ws officially released
<so2> this thing is one big mess here, segfaults, forgets configuration, hangs when i try to change something ...
<so2> and it seems the configuartion was so cleverly stuffed away so that i can't find it
<so2> i just wonder where .network-manager is ...
<so2> to do a rm -rf
<pitti> so2: do you use the version from gutsy-updates?
<so2> i use the version shipped from cd
<so2> because i can't get into the internet since a week
<pitti> so2: you should really upgrade
<so2> reinstall didn't help
<pitti> gutsy-updates has a ton of fixes
<so2> nice to hear, but i can't get an internet connection
<pitti> so2: I thought that only happened a few days ago?
<pitti> so2: (I take it you are 'so1' from some hours ago?)
<so2> yes
<dholbach> anyway, best to try to get 0.6.5-0ubuntu16.7.10.0 installed on the machine
<so2> i didn't count the first few days because i thought it would have something to do with hardy
<so2> but i reinstalled
<so2> and it is f***ed up as always
<so2> with a fresh user it works, but with my normal user it doesn't
<so2> i just wonder where network manager stores its configuration
<pitti> huh? you can ping your router with a fresh user, but not with an existing one?
<so2> (or network-admin)
<so2> yes
<so2> exactly
<pitti> so2: network-admin uses /etc/network/interfaces
<so2> understand why i'm quity angry? :-P
<pitti> but that's absolutely independent from users
<so2> obviously not ...
<so2> i had a new user, verything worked, wired, wireless, few seconds, everything ok
<dholbach> might be gnome-keyring-manager keys
<so2> old user, nothing works, dhcp: no, static: no
<dholbach> other configuration in .gconf
<so2> ok
<so2> where in gconf?
<so2> i already looked there but didn't find anything
<dholbach> I don't know, I would have to search too... ok
<dholbach> best to file a bug
<pitti> so2: is your old user in 'admin'?
<pitti> (group)
<so2> yes
<so2> i reinstalled it+
<so2> tried it with the user from the new installed system -> worked
<so2> mounted my home-partition -> old user -> did not work!
<dholbach> you could try strace-ing NetworkManager and nm-applet
<so2> ok
<so2> nm just segfaulted :-)
<dholbach> file a bug report
<so2> i'd just say: pull the latest version ...
<so2> this one is just unbelievable
<so2> it crashes more often than not
<dholbach> please file bug reports on it
<dholbach> we can't change what's in gutsy and the people who maintain network-manager are not around at the moment
<pitti> carlos: FYI, -proposed packages are uploading
<Hobbsee> hum, that reminds me.  why has my network manager not segfaulted at all yet?
<dholbach> so it's no point re-iterating it in here, bug reports are really the best way to go about it
<Ng> Hobbsee: mine's stopped segfaulting since I installed the one in -proposed \o/
<pitti> here too
<pitti> now it just misbehaves after suspend-to-ram
<Hobbsee> Ng: mine didn't seem to segfault even before that
<pitti> (or, rather, it doesn't behave at all; it just sits around until I restart it)
<Ng> Hobbsee: mine only did on resume
<Hobbsee> ahhh, well, i've been running kde, so i've only started even thinking about resume.
<Hobbsee> (recently)
<LaserRock> Hobbsee: you didn't resume with kde?
<Hobbsee> LaserRock: it bunged up each time, so, no.  just took me back to kdm.
<so2> ok, i'll reboot
<so2> brb
<pitti> LaserRock: KDE devs never sleep
<Hobbsee> yeah, well.  about that
 * Hobbsee really hopes she's not supposed to be at work in <5 hours.
<pitti> Hobbsee: there's a night supposed to be in between now and then, right?
<Hobbsee> pitti: yeah, something like that.
<pitti> Hobbsee: I think your suspend/resume is broken, too
<Hobbsee> pitti: on kde?  yeah
<Hobbsee> oh, mine personally
<Hobbsee> hah.  we knew that :)
<pitti> your's
 * Hobbsee recently told the night manager what time she usually gets to sleep.  he was....uh...somewhat surprised.
<zul> i think most people are Hobbsee  :)
<Hobbsee> zul: most people don't do the conversion back into syd time, so don't know how bad it actually is.
<Hobbsee> like, most people dont realise that it's almsot 4am - just that i'ts kinda late.
<geser> Hobbsee: that's because you stay up late, so it can't be that late in Sydney if you're still here :)
<dholbach> geser: 03:48?
<Hobbsee> heh
<geser> dholbach: I don't usually check the time in Sydney but only check if Hobbsee is here or not
<Hobbsee> heh
<mathiaz> soren: I've modified submittodebian to call reportbug with '-T patch' to the patch tag to the bug report.
<soren> mathiaz: I thought the bts did that automagically, but perhaps not. Feel free to upload a new version.
<mathiaz> soren: '-T patch' to add a patch tag to the bug report.
<mathiaz> soren: Just wondering if this is a good practive when forwarding patches to debian.
<mathiaz> soren: As we're already using ubuntu-patch in the user tags.
<soren> mathiaz: I'm not entirely sure.
<pitti> I grab infinity's "lilo" change; complain now or never
<soren> Er... which change is that?
<pitti> erm, s/change/merge/
<pitti> soren: blame it to Friday evening
<pitti> (and wrestling with Soyuz for 6 hours)
<soren> Oh, ok.
<mathiaz> pitti: is it a good practice to add "Tags: patch" when forwarding patches to debian bts ?
<seb128> mathiaz: sure
<pitti> mathiaz: yes, that, and some more
<pitti> https://wiki.ubuntu.com/Bugs/Debian/Usertagging
<mathiaz> seb128, pitti: great ! thanks.
<pitti> so that we can track them
<seb128> mathiaz: that's the purpose of the tag, indicating when there is patch attached
<mathiaz> seb128: I've just added it to submittodebian.
<seb128> cool
 * soren boggles at Debian's kvm packages
 * pitti boggles at how much cruft lilo accumulated
<pitti> several dpatch.orig and dpatch.rej files, patches of dpatches, other rej files, duplicated changelog entries...
<soren> kvm in Debian has got about 1 MB of blobs in it. Most recent changelog entry says "don't bother building a +dfsg orig.tar.gz. It's clean now". Er... no?
 * soren calls it a day
<gaspa> pitti: I did it !
<gaspa> how can I send you the patch? is fine bazar?
<pitti> gaspa: yes, that's fine; just commit it to your branch and make a note in the bug report
<pitti> I'll read the bug mail
<gaspa> ok. ;)
<gaspa> pitti: it just made some mess, while cleaning the code...
<so1> ok
<so1> back!
<so1> deleting /root/.gnome2/netwrok-admin* helped
<so1> connected immediately ...
<so1> now i'm just downloading the 300 mb of updates
<so1> takes ages
<so1> germany is really a development country if you compare internet connection speeds ...
<so1> btw, is there one package which removes the _whole_ mono crap?
<so1> removing libmono0 doesn't seem to uninstall everything
<Keybuk> pitti: you can change the f-spot import folder
<Keybuk> it's in Preferences
<carlos> pitti: cool, thanks
<slangasek> sbalneav: ping
<slangasek> lamont: hmm, ok; db4.5 ftbfs on hppa because java-gcj-compat-dev isn't up to date there, is this in progress? (seems to have no problems in Debian unstable...)
<pitti> Keybuk: ah, great
<geser> pitti: please give-back blktrace, camera.app, timemon.app, zipper.app, terminal.app, textedit.app. Thanks.
<geser> pitti: should I ask for retries for builds which failed because the build-depends weren't build yet or is a massive give-back planned soon?
<rexbron> mr_pouit: Did you get my earlier messages?
<mr_pouit> rexbron: yes: I don't know if this has been reported upstream (let's ask vorlon), and I hadn't gave a look at the patch~clean issue yet.
<rexbron> mr_pouit: What channel/server would that be?
<mr_pouit> s/hadn't gave/haven't given/
<slangasek> mr_pouit: ask me about what?
<slangasek> murrine, I gather
<mr_pouit> slangasek: yes, has the patch been forwarded upstream?
<pitti> geser: no, it's not planned, I don't know how to do that wholesale
<pitti> geser: given back
<_MMA_> mr_pouit: You can often catch Cimi (Murrine author) in #ubuntu-artwork. (not ATM though) He's usually on every day.
<pochu> pitti, geser: let's hope the soyuz crew fixes bug 160439 soon :)
<ubotu> Launchpad bug 160439 in soyuz "Some builds fail when they should depwait" [Undecided,Triaged] https://launchpad.net/bugs/160439
<pitti> yeah
<_MMA_> mr_pouit: Actually he's on Freenode now just not in Ubuntu channels.
<mr_pouit> _MMA_: ah ok, good to know, thanks :)
<_MMA_> np
<geser> pitti: so it's ok when I give you a list of packages which should build now?
<slangasek> mr_pouit: not by me, at least
<mr_pouit> slangasek: ok, I'll check with the upstream author, th//##ModelId=4746BF630236
<mr_pouit> typedef vector<Extremite*> vExtremite;
<mr_pouit> arg ^^"
<mr_pouit> //##ModelId=4746BF630255
<mr_pouit> typedef vector<Chemin*> vChemin;
<mr_pouit> anks
 * mr_pouit hates its touchpad
<mr_pouit> s/its/his/
<slangasek> mr_pouit: thanks for running with it :)
<rexbron> mr_pouit: I always knew you were a turing machine :P
<mr_pouit> ^^
<nxvl_work> hi
<nxvl_work> i need a give back for advi, can someone do it?
<tjaalton> does anyone know why https://wiki.ubuntu.com/HardyHardwareDetection is missing?
<LaserJock> somebody must have eaten it for breakfast
<tjaalton> oh
<nxvl_work> LaserJock: heh
<tjaalton> wrong url
<tjaalton> it was moved :)
<geser> nxvl_work: I guess all buildd-admins are already in the weekend
<geser> oh, nice, Hobbsee can now also do give-backs
<lamont> slangasek: we still have yet to bootstrap a working hppa/java into gutsy.,  er hardy
<slangasek> lamont: on the agenda, though?
<slangasek> lamont: or should I attend to fixing db4.5 to ignore java on hppa again?
<lamont> yeah.  sadly, I'm not a toolchain guy
<lamont> dropping java in ubuntu may be the quicker route
<Mez> argh, how do I creaate proper linda overrides?
<poningru> anyone around?
<poningru> looks like alpha1 will be shipping in a week
<poningru> is there plans for release notes?
<slangasek> poningru: we'll want some web page Ã  la http://www.ubuntu.com/testing/tribe1, but I wouldn't say there are "plans" per se right now
<slangasek> other than the plan that it should be done :)
<poningru> right
<poningru> but I was wondering what the nomer was going to be
<poningru> flight has already been used
<slangasek> from here on, they're just being called "alpha"
<poningru> oh :(
<Amaranth> Which doesn't make sense to me
<Amaranth> Because we've had them after beta/rc releases
<poningru> right what he said
 * poningru wonders where he can appeal that decision
<Fujitsu> /wi/win 5
<Fujitsu> Bah.
<poningru> hedge / sedge / seige
<poningru> so can I call it seige1 in the wiki?
<poningru> slangasek^^
<slangasek> poningru: uh, if you call it a "seige" in the wiki that's just going to be confusing to others because we're not releasing seige1, we're releasing alpha1
<poningru> I know but only for the wiki, the release notes will be on the website
<poningru> whatever
<poningru> alpha1 it is
#ubuntu-devel 2007-11-24
<Burgundavia> slangasek: just to catch up on a previous conversations, we are going with boring Alpha designations for Hardy?
<slangasek> Burgundavia: correct
<Burgundavia> how very boringly corporate
<slangasek> decided before I was involved, I'm just doin' what I'm told
<Burgundavia> I liked the names, thought they added character, but they were confusing
<slangasek> they also guaranteed url uniqueness on the website, but oh well :)
<Burgundavia> yes, they did
<jcastro> Ubuntu Alpha Vorlon 1 released!
<slangasek> ...
<Burgundavia> any idea who made the decision? did it come from sabdfl himself?
<jcastro> I wish there would have been a $something Crow so there could have been Murder 1, 2, etc.
<Burgundavia> given the "boringly corporate" theme for Hardy, I wouldn't be shocked
<slangasek> Burgundavia: dunno, was relayed to me by pitti and cjwatson_
<Burgundavia> ok
<Fujitsu> jcastro: Hahah.
<Burgundavia> jcastro: launch a deriv and have a crazy crow release
<Hobbsee> Burgundavia: mdz
<slangasek> I don't have the impression that LTSness was a significant consideration, since alphas are rather non-user-oriented anyway
<Burgundavia> Hobbsee: hmm, ahh
<Hobbsee> jcastro: *grin*
<Burgundavia> slangasek: but they are tech press oriented, non Linux tech press
<slangasek> I don't know I'd say they're "oriented" toward the tech press, though the tech press certainly covers them and this isn't a bad thing :)
<Burgundavia> right, that is what I meant
<GoldenPony> nxvl: do you still need it?
 * Fujitsu didn't know that ponies were good at eating LongPointySticks.
 * GoldenPony is duplicating LongPointyStick
 * GoldenPony works well, for flattening people
<Fujitsu> Except when it gets shot, like a couple of days back.
 * GoldenPony cannot be shot.
 * persia wonders if GoldenGlue would be useful
<Hobbsee> oy, network manager - stop dying!
<Hobbsee> same to my wifi!
<somerville32> Network manager says I have no network devices
<somerville32> I'd think my computer was pretty awesome to be able to use the internet without one if only I didn't know better
<lamont> Hobbsee: network managler hasn't run on my laptop in a small eterinity
<lamont> eternity, even
<lamont> admittedly, that's mostly because I purged it.
<Hobbsee> hehe
<DoYouKnow> hi
<Hobbsee> well, that tends to have an effect
<lamont> Hobbsee: it makes my network stay up better. :-)
<Hobbsee> what's weird is that this isnt the mangler - it's actually the fact tha tmy card randomly stops flashing / being active at all
<pwnguin> so far i havent found anything terrible with my intel card and network manager
<Hobbsee> what's more weird is that this is only happening today
<pwnguin> Hobbsee: maybe you're just being hax'd
<Hobbsee> pwnguin: maybe it's my machine giving me hell for not running gutsy
<pwnguin> psh
 * Hobbsee glares at mpt_
<pwnguin> hardy's fine if you know where the landmines are ;)
<pwnguin> thy name is policyKit
 * Hobbsee wonders if this is the real mpt.
 * persia recommends chroots
<pwnguin> chroots dont test nvidia
 * somerville32 enjoys multiple machines.
<persia> pwnguin: Exactly :)
<pwnguin> or the rest of my laptop hardware
 * Hobbsee discovered an edgy install on her other machine.
<pwnguin> think i just found a bug in rhythmbox though
 * Hobbsee ponders whether -updates can be abused, for kde4 related stuff.
<LaserJock> Hobbsee: wouldn't -backports be the place for that?
<Hobbsee> LaserJock: normally, yes.  but the current version is useless for building kde4 apps - which is it's only use, iirc
<persia> Hobbsee: The issue is verification: you'd need to show a regression (which requires tricky wording), and demonstrate no impact (which likely means rebuilding all the rdepends and testing them agressively, which would take weeks, if not months).
<LaserJock> Hobbsee: but what's the functional difference between -backports and -updates?
<Hobbsee> LaserJock: backprots is for random crack, to use selectively
<Hobbsee> sarah@LongPointyStick:~% rbuildepend libqca2-dev | wc -l                 3:35PM
<Hobbsee> 12
<persia> Err.  Not "random crack", but stuff from the new dev release that compiles on the old release
<Hobbsee> most of which is already kde4 stuff, or qca2 stuff.
<Hobbsee> oh, and psi
<persia> heh
 * Hobbsee thought psi had to build with theold version
<Hobbsee> that can still go back to libqca-dev.  well, that's what it's shlibdeps have come up with.
<Hobbsee> weird.
<Hobbsee> persia: mmm.
 * Hobbsee just hopes hardy gets sorted soon
<persia> Hobbsee: You could fix all the NBS stuff, and it'd be in better shape :)
<Hobbsee> persia: wouldnt help the intel breakage and such :)
<Hobbsee> besides, its' hard to do such a thing, when your machine hardlocks twice in 25 mins.
<persia> Hobbsee: Ah: video drivers.  No, not as such.  I'd wait for the new kernel
<Hobbsee> just hoping it comes soon :)
<Hobbsee> got caught only upgrading parts of hardy, causing more random freezes
 * persia suspects they weren't random, and suggests aptitude's advanced dependencies resolution algorithm to detect breakage before installation.
<Hobbsee> well, it was update-manager - then other bits would blow up
<Hobbsee> so then i said "screw it, i'll just upgrade the rest, and hope it works better than it did"
<Hobbsee> which it does.  in some ways.
<Hobbsee> it works fine, until it crashes.
<Hobbsee> rather than working slow and crap, until it crashes :)
<Hobbsee> although the crashes are increasing
<persia> Hobbsee: update-manager does a really smart dist-upgrade, but it's less smart about incremental daily uploads: it tends to grab the new stuff, and hope there aren't any library collisions.
<Hobbsee> yeah, true
<persia> Although, if your performance is that bad, I should really upgrade: my system will probably stop crashing :)
<Hobbsee> hehe
<Hobbsee> Fujitsu's got it as well
<Hobbsee> anyway... /me --> vote
 * persia dist-upgrades on the basis of this information
<Hobbsee> right.  have voted.
 * mdomsch is going to like dpkg triggers
<Hobbsee> mdomsch!
<mdomsch> good evening Hobbsee
<Hobbsee> heya mdomsch
<Hobbsee> mdomsch: how do you like ppa?
<mdomsch>  Hobbsee just got it activated for dell-team, haven't uploaded anything yet
<Hobbsee> get to it :P
<mdomsch> been too busy fixing my packages and playing wii with my kids
<mdomsch> :-)
<Hobbsee> hehe
<mdomsch> uploading firmware-tools now
<Hobbsee> hrm.  what's the factoid for customising the ubuntu cds....
<mdomsch> and firmware-addon-dell
<mdomsch> Hobbsee, https://launchpad.net/~dell-team/+archive has them now
<Hobbsee> mdomsch: \o/
<Hobbsee> mdomsch: i thought you were going for all releases
<Hobbsee> not just hardy
<mdomsch> Hobbsee, I need to change and re-upload for gutsy
<mdomsch> and because I need triggers, I can't release for feisty :-(
<Hobbsee> mdomsch: you know that you cant use the same version number for gutsy and hardy?
<mdomsch> eww
<mdomsch> fwiw, fedora uses a "dist tag" appended to the -revision part of the version field
<Hobbsee> (due to archive structure, where all the binaries get put in pool/)
<mdomsch> which solves this cleanly
<persia> Well, actually the same number can be used for both, but it's not ideal for new uploads.
<Hobbsee> mdomsch: you can do the same, or similar.  use 1.4.9-0ubuntu2~<targetrelease>1
<mdomsch> worksforme
<Hobbsee> persia: not in ppa, surely.
<Hobbsee> persia: http://ppa.launchpad.net/dell-team/ubuntu/pool/main/f/ doesn't do releases
<persia> Hobbsee: Right.  Context.  Same binary == same version, but dist copies only happen to the main archive.
 * persia shuts up again
<mdomsch> Hobbsee, must be different, not gutsy < hardy ?
<Hobbsee> mdomsch: it so happens that gutsy < hardy anyway, but yes, they must be different.  and one must be above the other, if you want to stop warnings about "help, you're downgrading"
<Hobbsee> persia: that being said...we cant upload teh same version to gutsy and hardy, can we?
<Hobbsee> in the main archive
<Hobbsee> mdomsch: thanks, that's part of what i needed to stick in the all new and shiny ppa FAQ
<persia> Hobbsee: Err.  From a dpkg perspective it works fine, as long as it's the same binary.  The trick is that the Packages,gz files need to have the right contents, which depends on the archive system being used.
<Hobbsee> persia: true.  it's an archive limitation, not a dpkg one
<persia> Hobbsee: I'm not sure "limitation" is the right word, but yes.
<Hobbsee> well, it's on purpose.  but yes :)
<persia> Note that same binary means same compilation: always copy from older to newer, rather than the other way, or things are likely to break, as forward compatibility is a difficult problem.
<Hobbsee> persia: this is true
<mdomsch> persia, in my case, the package is a python package, so compilation happens at install time
<mdomsch> but if it were C I would agree
<persia> mdomsch: Even python packages have a build process.  If python-central | python-support changed significantly, you'd prefer to build against the old one, to ensure that the install-time compilation worked for both releases.
<persia> Although I admit that "compilation" isn't the right word to use for the python package build process.
<Hobbsee> persia: he left, and it also contains debian/ in the source stuff
<persia> Hobbsee: All true.  I type too slowly :)
<Fujitsu> Hobbsee: Did I see a mention of a non-slow -intel before?
<Hobbsee> Fujitsu: yeah.  the latest non-particularly-slow intel in the archives isnt too slow
<Hobbsee> like, it's not noticibly laggy
<Hobbsee> crashes too often, though
<Hobbsee> it's less laggy than when it first came out, though
<Fujitsu> Hobbsee: Oh, good. I might upgrade, then.
<Fujitsu> Scrolling is just painful.
<warp10> Hi all!
<Hobbsee> oh yeah, scrolling still sucks
<Hobbsee> but the rest of it is fine
<Fujitsu> Ah.
<mpt__> Hobbsee, what did I do?
<Hobbsee> mpt: suspect IP address
<Hobbsee> sorry, hostname
<Hobbsee> mpt: thought people might have turned from impersonating mark to impersonating you.
<mpt> I'm not that popular, surely
<Hobbsee> who knows...
<StevenK> mpt: AboutThisComputer got Approved, but it has the all of the hardware bits back again
<mpt> https://wiki.ubuntu.com/AboutThisComputer
<mpt> whoops
 * mpt forgot to press Ctrl+Space first
<mpt> StevenK, there's no wiki page by that name, and <https://blueprints.edge.launchpad.net/ubuntu?searchtext=about> returns zero results
<StevenK> Hum. Where did it go?
<poningru> mpt: its probably asa ;)
 * persia finds https://blueprints.launchpad.net/ubuntu/+spec/about-this-computer
<Hobbsee> where did what go?
<StevenK> Ah, sneaky
<StevenK> https://wiki.ubuntu.com/DesktopTeam/Specs/AboutThisComputer
<mpt> thanks
<mpt> hum, no mockup?
<mpt> "The icon of the window will be a visually attractive computer icon"
<StevenK> The mockup is in text only.
<mpt> That's going to match what the computer actually looks like about 1% of the time
<Rabbitbunny> is there some sort of 'noob guide' for updating the repository? it only has gtkpod 99.2 and liggpod 0.3.2 when 99.10 and 0.6 are current. if I have to make from source I might as well do it for everybody.
<StevenK>   libgpod |    0.6.0-2 |         hardy | source
<Rabbitbunny> for dapper
<mpt> At least it will be an improvement
<StevenK> We aren't going to update those for Dapper.
<persia> Rabbitbunny: You could request a backport, but Dapper is considered pretty stable: it's better to upgrade to a newer release.
<Rabbitbunny> request a backport? i have source..
<persia> StevenK: Can all of AboutSystem, AboutUbuntu, and AboutUbuntuRevisited go away now?
<Rabbitbunny> StevenK: What do you mean 'we'?
<persia> !backports
<ubotu> If new updated Ubuntu packages are built for an application, then they go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<StevenK> persia: AboutSystem is unrelated. AboutUbuntu and AboutUbuntuRevisited are refered to by AboutThisComputer
<StevenK> Rabbitbunny: We meaning Ubuntu developers
<persia> StevenK: AboutSystem looks earlier than AboutUbuntu, and same topic.  I'll deprecate that, but leave the rest.  Thanks.
<poptones> hello, could i get some assistance regarding a memory leak in nautilus?
<Hobbsee> poptones: better to do so on irc.gnome.org, i expect
<Hobbsee> besides, its' a weekend.
<poptones> thx
<Riddell> ~/win 13
<Riddell> hmm
<Hobbsee> fail :)
<Riddell> ah, Hobbsee, could you give back kdebluetooth and kdesdk
<Hobbsee> Riddell: where?
<Riddell> hardy
<Hobbsee> Riddell: given back
<\sh> moins
<lamont> slangasek: http://conflictchecker.ubuntu.com/possible-conflicts/ lacks hardy...
<sarahl> it would appear that the ubuntu log_sql package hasn't been updated in a while.
<persia> sarahl: Which package?  I don't even see one by that name.
<lamont> sarahl: package names don't have underscores in them...   what package do you mean when you say 'log_sql'?
<\sh> lamont, i think sarahl means libapache2-mod-log-sql-mysql
<tuna> is ther anyone here responsible for http://cdimage.ubuntu.com/custom/ ?
<\sh> tuna, at this time? 21:00 UTC? not likely
<slangasek> lamont: hmm, alright. who runs conflictchecker.ubuntu.com? :)
<lamont> slangasek: nfc.  elmo should know??
<lamont> or any release manager... :-)
<lamont> slangasek: dunno... '
<lamont> 'twas in your announcement. :-)
<slangasek> lamont: only indirectly :)
<slangasek> lifeless: was the conflict checker something you maintained?
<\sh> COMPLAIN: http://archive.ubuntu.com/ubuntu/pool/main/t/tix8.1/ is totally empty but it's needed for python2.2 in dapper, please readd those missing packages, kthxhappysunday ,)
<\sh> I wonder what happend to tix8.1 that it totally disappeared ... hopefully "you know who" was not the one who cursed it
<slangasek> \sh: needed how?
<slangasek> python2.2 itself doesn't appear to depend on it
<\sh> slangasek, tix8.1-dev is a build-dep for python2.2 which needs a sec fix now...
<slangasek> ah
<\sh> well then some other build-dep of py2.2
<\sh> slangasek, Build-Depends: debhelper (>= 3), autoconf2.13, libreadline5-dev, libncurses5-dev (>= 4.2-3.1), tk8.4-dev, libdb4.3-dev, zlib1g-dev (>= 1:1.1.3), libexpat1-dev, libgmp3-dev(>= 4.1.4-8), libgdbm-dev, blt-dev (>= 2.4z), tix8.1-dev (>= 8.1.3.93), libssl-dev
<slangasek> well, drescher only has the warty/hoary/breezy versions available, which were in main; I imagine tix8.1 would need to be reuploaded to dapper?
<\sh> slangasek, looks like...question is what happened?
<slangasek> \sh: it was probably removed prior to dapper release and no one noticed, since python2.2 wasn't touched at all between breezy and dapper and is in universe?
<\sh> slangasek, dunno..hopefully it was in universe...I'll have to setup a dapper chroot to check the reverse dependencies
<slangasek> hmm?
<slangasek> I'm saying that python2.2 is in universe
<\sh> slangasek, oh...sure..pythons2.2. was universe
<slangasek> which by extension implies that tix8.1 was in universe, yes, or else it would've been caught by germinate
<\sh> hopefully
<slangasek> er, n/m
<slangasek> I'm thinking backwards
<\sh> well, we should think about a complete rebuild of the archives, at least a couple of weeks before release
<\sh> when I think about the bash <-> dash change it's really a mess to find out, that when you need to fix some vulnerabilities , you have to fix some crappy bashisms too
<lamont> \sh: we do rebuild the archive (well, main at least), a couple weeks before release.
<lamont> we just don't replace the debs, since that would be, um, bad
<\sh> lamont, hmm...na...I just had a problem with perl last week..I attached a patch to fix a cve...and suddenly, I ran into this Makedepends.sh problem...which was fixed in gutsy but not in feisty, but feisty had the bash dash change so it never rebuild after this change
 * Fujitsu notes we're trying to collect resources for universe rebuilds.
<lamont> \sh: see http://people.ubuntu.com/~lamont/buildLogs/Test/byDate/all.html
<lamont> Fujitsu: we could possibly do a rebuild of gutsy/universe now that gutsy is released...
 * lamont adds it to his ubuntu-datacenter wishlist
<Fujitsu> lamont: So we have resources to do rebuilds of old releases?
<\sh> lamont, man, those infos should be at a central place, where everyone can see it directly ,-)
<lamont> \sh: that was the best we could do for the gutsy-autotest rebuild
<lamont> which only did main
<lamont> Fujitsu: the machines that get used to do the autotest (re)builds are actually the security/livecd/etc machines... and there's only one per architecture... hence they don't like to get lots of strain
<lamont> and the builds are done outside of launchpad
<Fujitsu> lamont: Ah, so it is only that one per arch...
<Fujitsu> I thought there might be some that weren't registered in Soyuz.
<\sh> Fujitsu, if we get a sponsor for around 2x2500 euros...we could get 14TB of raid6 diskspace with 2x (2x amd64 dualcore + 2x16GB ram)
<lamont> Fujitsu: soyuz knows all
<Fujitsu> Do we know when Soyuz is getting the rebuild feature? It has been RSN for a while now. Like, a couple of years.
<lamont> Fujitsu: I think it's further down the list than the current cut-line... dunno when it might clear that line
<lamont> the biggest issue for LP is that it needs to not keep the new debs
<Fujitsu> I guess that we can't expect too much progress from two whole developers.
<lamont> and that's kinda contrary to what the librarian thinks it should do
 * \sh grabs a beer
<Fujitsu> lamont: I guess it would be hard to model the correct behaviour.
<lamont> Fujitsu: the other challenge for autotest is that it requires an import of the archive into DAK, which isn't exactly the fastest operation in the world.
<Fujitsu> lamont: And that hits various DAK constraints that Soyuz doesn't enforce, right?
<lamont> depends on what you mean by constraints
<Fujitsu> Sanity checks and the like.
<lamont> those pass, actually
<Fujitsu> Ah.
<lamont> \sh: only the red files are failures...
<lamont> and I believe I filed bugs against all of the failures
<lamont> some of the "successes" have implicit pointer conversions in them --> failure
 * lamont makes a note to put together the implicit-conversion patch for launchpad's buildds
<\sh> lamont, well, it was just one problem i ran into...and the problem was fixed in gutsy...but I guess, the change inside the chroots from bash to dash came after release of feisty these days
<lamont> could be.  OTOH, feisty-security should be building with the same chroot that feisty release did...
 * Fujitsu likes the large amount of documentation on how everything is set up.
<\sh> lamont, can be...but pbuilder at home builds with feisty chroot whats provided from the archives :)
<\sh> lamont, but you agree with me, that a missing package which is needed by another package to build is a real problem and needs to be fixed and should be avoided all the time, it doesn't matter if it's main or universe
<lamont> Fujitsu: was that maybe sarcasm?
<Fujitsu> lamont: Unless you can point me to some.
<lifeless> slangasek: as wiki.ubuntu.com says; mvo or I are contacts for the conflict checker
<lifeless> slangasek: I wrote it
<lifeless> slangasek: and have handed it over to mvo
<lamont> Fujitsu: yeah... well, it was all temporary when I was setting up the buildds originally, and so that part never got documented so much.
<lamont> and yeah, it'd be nice to have it better documented.
<Fujitsu> lamont: I meant about everything, including the Soyuz bits, but that's a good point.
 * lamont can't claim any responsibility for  the Soyuz bits being documentation-light
 * Fujitsu holds lamont responsible anyway.
<LaserJock> heh
<lamont> Fujitsu: I do admit to being involved in the design
<Fujitsu> There we go!
 * Fujitsu burns.
 * lamont completes level 3430 of kobo deluxe.
<Fujitsu> That's a few levels.
<lamont> somehow, I think that's more sad than wonderful.
<Fujitsu> Probably.
<lamont> there are only templates for 50 levels... then it repeats, only with more crap
<\sh> whatever kobo is
<Fujitsu> \sh: see the kobodeluxe package.
<\sh> hmmm...
<\sh> na...
<\sh> I'*m more in playing anarchy online or eve online
<slangasek> lifeless: why, so the wiki does say, thanks :)
<slangasek> lifeless: can you take care of getting hardy on there then, or should I poke mvo?
<\sh> keescook, bug #163845 ready for review
<ubotu> Launchpad bug 163845 in python2.5 "[python] Multiple integer overflow vulnerabilities possibly resulting in the execution of arbitrary code or DoS" [Undecided,In progress] https://launchpad.net/bugs/163845
<\sh> good night guys
#ubuntu-devel 2007-11-25
<lifeless> slangasek: poke mvo if you would; otherwise remind me during the week
<slangasek> ok
 * calc uploaded openoffice.org 1:2.3.0-1ubuntu5.2 to gutsy-propsed
<calc> er gutsy-proposed
<calc> fixes 11 bugs :)
<somerville32> calc, Did you file an SRU?
<calc> somerville32: i reused the SRU for 5.1 since it was defective
<calc> or am attemping to reuse it, heh
<somerville32> calc, Are you a MOTU?
<calc> somerville32: core-dev
<somerville32> Cool
<calc> to bad pitti isn't awake or he could accept it for me
<calc> slangasek: do you do accept SRUs?
<calc> er remove second do
<calc> hmm looks like just pitti and cjwatson do them according to lp
<calc> https://bugs.launchpad.net/ubuntu/gutsy/+source/openoffice.org/+bug/153132 <- debdiff is there if anyone is interested in what i have fixed for the new upload
<ubotu> Launchpad bug 153132 in openoffice.org "Openoffice splash screen includes Ubuntu logo" [Medium,In progress]
<calc> i fixed the broffice.org not installing bug, the bug where forms/dictionary/etc don't work without openoffice.org-base installed, the python-uno can't be imported bug, the gtk themes crash OOo bug, and proper bitmap depth for splash screen bug
<LucidFox> I tried building a package build-depending on sun-java6-jdk, and got this error: "sun-dlj-v1-1 license could not be presented"
<RAOF> Yup, that's right.  You get an EULA in the postinst.  I forget if people can get around that - you might want to check #ubuntu-motu, too.
<nxvl> is someone here?
<nxvl> i need someone to help me with a give-back
<Mithrandir> nxvl: sure, which package?
<geser> Mithrandir: is uploading possible right now or should I wait till LP is back?
<StevenK> Wait until Launchpad is back.
<nxvl> Mithrandir: advi
<geser> nxvl: I asked Hobbsee yesterday to give it back
<nxvl> geser: oh! thnx :D
<nxvl> geser: but it's still on the FTBFS list
<nxvl> how often it refreshed?
<persia> nxvl: That gets updated about once a day, but it's always best to check in LP, as the build queues might be lengthy.
 * Hobbsee waves
<persia> More verbosely, if you're looking at a FTBFS, you'll want to make sure there's not a pending build prior to hunting too deeply.
<Hobbsee> build queues are lenghty for i386
<Fujitsu> Morning, Hobbsee.
<Fujitsu> Hobbsee: The new -intel seems to be stable.
<Fujitsu> I've been running it all day without issues.
<nxvl> persia: where on LP? at the release information on the package page?
<Kmos> palmer is broken since 20th
<geser> Hi Hobbsee
<geser> nxvl: check the build status for the package (once LP is back)
<persia> nxvl: Errr..  Something like https://launchpad.net/ubuntu/hardy/+builds and then search for "All states" and the package name.  There's a better URL, but I usually find it by trial and error, and LP is being maintained now.
<nxvl> oh! thnx i didn't knew it exist :D
<Hobbsee> Fujitsu: excellent!
<Hobbsee> Fujitsu: downloading it now
<Hobbsee> persia: i dont think there's much of a better URL
<nxvl> sun is now shining and don't want to sleep even a little
<nxvl> :S
<persia> Hobbsee: There is a package specific build URL, which doesn't require a querystring.
<Hobbsee> persia: oh, that's a point
<persia> (mind you, I don't think there are any links to that URL anywhere)
<Hobbsee> no, of course not.
<Hobbsee> if links were there, it'd be easy to find things :)
<Mithrandir> https://launchpad.net/ubuntu/+source/advi/1.6.0-13/ shows you the build and their statuses
<Hobbsee> Fujitsu: wow, it does seem better.  is scrolling better too, or is it just me?
<Fujitsu> Hobbsee: Just you, I think.
<Fujitsu> Other than scrolling, it is working quite admirably.
<Hobbsee> Fujitsu: nice.  oh, and the redraw's still slow, and creates artifacts
<Fujitsu> Hobbsee: You mean creation of new windows not updating textures in time?
<Fujitsu> Or the occasion where bits of the desktop will appear in the middle of the screen?
<Hobbsee> the former
<nxvl> is there any mailling list where i can ask for give-backs or only here?
<TheMuso> nxvl: Usually here is only where its done, and usually only during the week.
<TheMuso> nxvl: As it is, LP is still down I think.
<nxvl> mm
<nxvl> ok
<nxvl> then a geve-back is needed for apcupsd
<Hobbsee> TheMuso: it appears to be back
<TheMuso> Hobbsee: ah ok.
<Hobbsee> TheMuso: oh, and it's when buildd-admins are around
<Hobbsee> which, as you say, is usually during the week.
<Fujitsu> Hobbsee: Are you using -synaptics?
<nxvl> is there any build-admins list out there?
<Hobbsee> nxvl: lp.net/~buildd-admins
<Hobbsee> iirc
<Hobbsee> nxvl: it's ~launchpad-buildd-admins
<Hobbsee> nxvl: given back
<Hobbsee> Fujitsu: yes
<Fujitsu> Hobbsee: Right, just wonderinf if you had a fix for the problem I was seeing. I'd manually added the synaptics stuff to a new xorg.conf, and the USB mouse was going crazy, but copying an extra couple of lines from the old config seems to have fixed that.
<Hobbsee> Fujitsu: i've not modified it at all, WFM.
<Hobbsee> although i dont have a usb mouse connected
<Fujitsu> You've probably got an old config. The new debconf scripts seem to not detect -synaptics.
<Hobbsee> probably.
<TheMuso> Hobbsee: Ah right. Goes to show how rarely I have to do it. :p
<Hobbsee> TheMuso: :P
<tjaalton> Hobbsee: synaptics was dropped from dexconf because input-hotplug should cover that. too bad that it's not actually used yet
<tjaalton> (commit by debian, fwiw)
<Hobbsee> right
<tjaalton> also, you coud try 'Option "AccelMethod" "XAA"' in your Device-section to see if the bugs you are seeing are because of EXA
<Fujitsu> tjaalton: I'll try XAA now that I have synaptics properly working.
<tjaalton> Fujitsu: great
 * TheMuso decides to upgrade to hardy on a non-critical box.
<Fujitsu> tjaalton: It much better, but still not perfect.
<Fujitsu> I can scroll PDFs now!
<Fujitsu> +is
<tjaalton> Fujitsu: did your touchpad work at all before you made your changes?
<Fujitsu> tjaalton: Yes, but without scrolling or double-tapping.
<tjaalton> Fujitsu: ok, in that case synaptics can wait for input-hotplug ;)
<Fujitsu> When I copied the synaptics section verbatim from the previous xorg.conf, events from my USB mouse were all detected twice, but that was fairly easily fixed.
<tjaalton> yep, that was one of the reasons it was dropped
<Fujitsu> Ah.
<Hobbsee> tjaalton: ROCK ON!
<Hobbsee> tjaalton: using XAA goes back to working fine
<ogra> hehe
<ogra> LaserRock :)
<LaserJock> ;-)
<ogra> did jorge show you the pic ?
<ogra> oh, i just notice he blogged it ...
 * ogra should read planet more regulary :)
<LaserJock> ogra: hehe
 * lamont wonders who retried ebug-http
<Raff7> hi
<Jooles> Hi all. Anyone know (roughly) how long it's likely to be until Xorg 7.3 is gonna be in the ubuntu packages?
<tormod> Jooles: it's in Hardy already.
<Jooles> so it's downloadable using the package manager? I haven't played around with ubuntu much you see and I'd rather not compile it from source as I'm setting the machine up for a friend who's not used linux
<Chipzz> it's in the development release
<Chipzz> not in the stable
<Jooles> cool. Thanks guys  = )
<soren> Refresh my memory: Is it ok for source packages to contain blobs that are built from free software, but not built from source in that package?  Example: The kvm package contains a version of bochsbios with a few tiny patches applied and built by kvm upstream and shipped in their tarball.
<soren> I'm guessing: hell no.
<somerville32> soren, Maybe in multiverse?
<soren> Sure, but that's not really interesting at all :)
<LaserJock> soren: it's the bochsbios binary?
<soren> LaserJock: Well, it's built from the bochsbios source with a few tiny patches applied.
<soren> LaserJock: So no, it doesn't match a file from the bochsbios package.
<slangasek> soren: it's a supportability issue, surely?
<soren> slangasek: Indeed.
<soren> slangasek: I've changed the bochs package to build this special version of it, and having qemu depend on that, and I intend to do the same for kvm..
<LaserJock> soren: well, but is there source for it or no?
<lifeless> soren: thats the right thing to do
<LaserJock> yeah, I would think so
<soren> I just want to know if it's kosher as per Debian policy, so I know what to put in my bug report to Debian.
<soren> LaserJock: Not in the kvm package. The kvm package has the patch, the bochs package has the rest of the source.
<lifeless> soren: the key question is 'is it a licence violation'
<soren> LaserJock: Allegedly, if you apply said patch to the bochs source and build it, you get that very blob.
<soren> lifeless: It's not a policy violation?
<lifeless> soren: that is, if the blob is e.g. a derived binary it will trigger GPL protection
<lifeless> soren: .jpg's and other things are built, its still an open freaking sore wound
<soren> lifeless: That's an issue, too. Agreed. however, that's not what I'm interested in right now.
<lifeless> soren: if the blob is derived from bochs but the source for it is not delivered when you apt-get source kvm, then its a violation of the GPL (assuming bochsbios is gpl'd)
<lifeless> soren: and this takes precendence over policy :)
<soren> I'll rephrase my question: Should I just tell the debian maintainer that I disagree with his approach, or should I pound him in the head with some part of Debian Policy or the dfsg or something?
<slangasek> oh, if it's the fault of the Debian maintainer, pound him in the head
<lifeless> soren: FWICT pound him in the head with the GPL.
<soren> lifeless: That too :)
<slangasek> soren: DFSG says that we have to ship source for all programs in Debian main
<soren> slangasek: Right.
<LaserJock> slangasek: even if that source is split into different packages?
<soren> slangasek: But depending on how you interpret that, you could argue that the source is somewhere in Debian main, so all is good. I wouldn't agree to thtat, though.
<soren> slangasek: ...so to do the right thing in terms of supportability and such, you could just change the build system to not use it, but in terms of complying with policy, would it also be necessary to repack the tarball without any blobs at all?
<soren> er... policy and the gpl.. :)
<slangasek> soren: hmm, in the past where I've had binary objects in an upstream tarball, I've stripped them out.  If the code is GPL, this is preventative license compliance, because in the future you may not be able to reproduce that blob from sources available in the archive
<lifeless> soren: no, you can't argue that its somewhere in main
<soren> lifeless: Didn't think so.
<lifeless> soren: because if you follow that argument, 'apt-get source bash' has to download all the source for all of main to match the gpl's distribution at same time requirement
<slangasek> lifeless: well, in effect, "apt-get source bash && apt-get build-dep bash"...
<slangasek> headers and whatnot
<lifeless> slangasek: in this case it's apt-get source kvm && apt-get source bochbios, which is different.
<lifeless> slangasek: reproducible binaries and used-source are different arguments, but I think we're in basic agreement
<soren> lifeless: biochs is lgpl, by the way. That doesn't change anything in this respect, afaict.
<soren> lifeless: bochs, I mean.
<slangasek> lifeless: yes
<lifeless> soren: no, it won't, because we're not linking to it, its the output itself thats being used,
<soren> lifeless slangasek: thanks guys. I'll send an e-mail to the Debian maintainer explaining the errors of his ways :)
#ubuntu-devel 2008-11-17
<rlaager> andrews: You probably want to work on gparted. You should contact them.
<andrews> rlaager:  I saw gparted on Launchpad is that the main project.
<rlaager> andrews: This is most likely off-topic for this chat room. Google gave me this: http://gparted.sourceforge.net/
<andrews> rlaager: thanks
<GodfatherofEire> I know that I'm probably going to be re-directed, but have any of you specifically dealt with the usplash setup for the previous releases, and/or working on it for Jaunty?
<Hobbsee> GodfatherofEire: would suggest checking the changelog of the package 'usplash' to see who's been working on it.
<Hobbsee> that appears to be pitti, who will be asleep at the moment (he's in germany)
<GodfatherofEire> THank you Hobbsee.
<Hobbsee> GodfatherofEire: you're welcome
<Hobbsee> you'll probably have to wait 7+ hours, i expect
<GodfatherofEire> Where would I find this Changelog, however?
<Hobbsee> aptitude changelog usplash
<GodfatherofEire> Ich kann warten Hobbsee (I think that'd be it)
<Hobbsee> or changelogs.ubuntu.com
<Hobbsee> GodfatherofEire: :)
<GodfatherofEire> Well, thanks for the help, looks like I'll be back in a bit.
<Hobbsee> good luck :)
<GodfatherofEire> Thanks.
<jdong> are there any future plans for proper 32-bit library support on x86-64, instead of our ia32-libs hack?
<TheMuso> jdong: WOuldn't that mean apt/dpkg multi-arch support?
<jdong> TheMuso: yeah, I guess
<RAOF> That seems to have died a quiet death.
<jdong> I was hoping we can do away with scripts like getlibs
<RAOF> It'd be nice.
<RAdams> why did they change the default inode size to 256 in a new intrepid install? that borks so many utilities for cross-platform FS access...
<RAdams> what makes 256 blocks so great?
<RAdams> and, how do I install ubuntu in such a way as to prevent that from happening again? I'll have to reformat as it is
<blahbleh> hello, i've been thinking about/working on a little app, that would be similar in purpose to #ubuntu, but would allow each end-user with their own problem to have their own little "room" - ie: it's just for their problem. anyone coming in who wants to help can have a look at all the problems people have listed and want live help for, and go in and out; the advantage being that a person can get help from one or more people without inter
<persia> blahbleh, Something like answers.launchpad.net, except interactive?
<Hobbsee> blahbleh: you got cut off, too
<blahbleh> pretty much, yeah. #ubuntu is good because you don't need an account or anything ad can get right into it; this would be similar
<blahbleh> hobbsee: where did i get cut off?
<persia> Personally, I suspect the main issue is that there's little opportunity for collaboration and cooperation.  One of the great strengths of places like #ubuntu is that as each of us learns more we can help those learning those things whilst seeking help for that which we don't yet understand.
<Hobbsee> more people without inter
<blahbleh> "the advantage being that a person can get help from one or more people without interference from other people who have their own problems. good idea or bad idea? should i keep going? (not even sure if this is the right place; if not, point me :-) )"
<persia> It's probably not the right place, but the location of the right place escapes me.
<persia> That said, I still don't think it's good.  Look at the throughput at answers.launchpad.net as compared to the forums.
<blahbleh> persia: good point with collaboration... i was thinking that anyone using the app can roam between rooms if they want to, preferably as long as they keep on the same subject as the OP. it would be a bit like ubuntuforums in that respect
<persia> It's the same issue: a.l.n expects people to want to solve problems, and look for them (which happens, but to a moderate degree).  the forums encourages people to answer simple questions so that more complex questions get the attention of others, because it's not separate.
<persia> Well, maybe.  With the right design, it might work.  The trick is maintaining the incentive for people to answer simple stuff, and build the sense of working together towards a common goal.
<blahbleh> thanks very much for the insight, persia :-)   i suppose part of the #ubuntu incentive is that it's *fun*, and incredibly easy
<persia> Yep :)
<blahbleh> i think i'll keep at it (it's good coding practice anyway, and i have heaps of free time at the moment)
<dholbach> good morning
<pitti> Good morning
<dholbach> hi pitti
<Hobbsee> hey pitti, dholbach!
<dholbach> hi Hobbsee, hi iulian
<iulian> Morning Daniel.
<iulian> Hey Hobbsee.
<pitti> Riddell: does your "breaks adept" comment in bug 278602 apply to the intrepid SRU or jaunty?
<ubottu> Launchpad bug 278602 in kde4libs "Error loading module Embeddable Image Viewer" [Undecided,Fix committed] https://launchpad.net/bugs/278602
<pitti> asac: is bug 278095
<ubottu> Launchpad bug 278095 in firefox-3.0 "MASTER crash in getenv() ... spi_atk_bridge_exit_func()" [High,Fix committed] https://launchpad.net/bugs/278095
<pitti> asac: ... an issue in firefox at all?
<Riddell> pitti: to the SRU version
<ikonia> wgrant: possibly to pick up here ?
<wgrant> ikonia: Possibly. You might get better results here from people who know what they're talking about.
<ikonia> I think your quite on track
<ikonia> I was just curious to how things like the libc headers are decided if the toolchain components are picked up pretty quick after the current release
<ikonia> the headers are a good/easy example
<cjwatson> how they're "decided"? I don't understand the question
<ikonia> cjwatson: from a previous discussion it was explained the the toolchain for current+1 is finalised quite quick after current release
<ikonia> so would I be right in thinking that they are picked from a "current" libc header availability say based off 2.6.27 , or is there prospective choices such as say 2.6.29 headers
<cjwatson> oh, you mean linux-libc-dev?
<cjwatson> it's built directly from the kernel packaging
<ikonia> thats one example yes
<cjwatson> so it always matches whatever kernel is current in the release
<ikonia> cjwatson: that part I would expect however, the current jaunty kernel is 2.6.27, which measn the headers would be based from the .27 kernel
<soren> ikonia: We don't start from scratch with every release.
<soren> ikonia: When Jaunty came into existence, it was identical to Intrepid.
<ikonia> so if you swap later on to say 2.6.29 will your headers follow that or stay with .27
<cjwatson> ikonia: yes, that'll be changed whenever the kernel team get a new kernel in place
<cjwatson> the headers will follow that
<ikonia> that makes sense
<ikonia> perfect
<cjwatson> it's not ideal that it tends to be a while before the kernel is available so in a sense the toolchain is always going to change quite a bit after the initial bootstrap, but the kernel team are only human and it does take time; I don't think it's all that important in practice
<ikonia> cjwatson this is what I suspected, which makes sense now returning back to a prevsious conversation which made me ask this question
<persia> I think we usually get someone in the range of 3-5 packages that need readjustment for the changes per cycle, which is not unmanageable.
<persia> s/someone/somewhere/
<ikonia> persia really, that few ?
<persia> ikonia, While the kernel changes a lot, the libc headers from the kernel don't tend to change too wildly.  Depends on which package uses the feature that just went from deprecated to obsolete.
<ikonia> persia yes, they have stabiliised a lot since the ed of the LLC project,
<ikonia> persia: I just would have expected more breakage
<persia> Well, there's certainly the possibility of breakage that I don't hear about :)
<ikonia> I just remember how fussy things like libc and binutil where to header changes, even slight ones
<ikonia> so I'm surprised that you don't have more breakages, it is a positive thing that you don't though
<cjwatson> it's not that bad nowadays.
<ikonia> I guess I see more due to the cross-compiling process, rather than the native build, which isn't a good benchmark
<ikonia> interesting info, thansk chaps
<seb128> doko: you really don't want to use requestsync?
<kagou> Hi
<kagou> tkamppeter, what do you think about my comment on #294671 ?
<seb128> do we have a list of packages which have a newer version in debian experimental than ubuntu somewhere?
<mvo> seb128: if we don't have one, I could write you one I think
<seb128> mvo: I can probably hack something too, I was just wondering because for GNOME all the recents versions are in experimental so that's what we want to base updates on
<seb128> and I expect it's not only GNOME since debian is frozen for a while
<joaopinto> is there an easy way to set conditional name resolution, like using different dns server ips based on the hostname domain ?
<soren> Where's the documentation for the format of the files in /usr/share/pam-configs?
<cjwatson> soren: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
<mvo> seb128: whatever you prefer, I was thinking of something very simple based around the apt.Cache(rootdir=debian-experimental); cache.update(); and again for jaunty
<persia> seb128, mdt can generate that fairly easily.  Do you think it's useful to have a persistent list?
<soren> cjwatson: Thanks.
<seb128> persia: what is mdt? that would be useful to have an idea on things we might want to update
<geser> multi-distro-tools
<seb128> persia: usually there is not so many things there but during freezes they upload to experimental a lot of things which would go usually to unstable
<geser> http://qa.ubuntuwire.com/multidistrotools/
<seb128> geser: ok, still doesn't tell me a lot
<seb128> looking
<mvo> geser: interessting, is the source available?
<persia> seb128, It's a tool to compare versions of sortware between debian-format archives.  Very handy.  Originally put together by the Utnubu folk.
<seb128> mvo: I did something around those lines previous cycle to list merges to do for the desktop team I think, let me have a look if I still have the code around
<persia> mvo, There should be a link to the source on that page.  If not, check LP.
<geser> mvo: wgrant should have access to the scripts used on ubuntuwire, I just have a old checkout from somewhere
<cjwatson> could somebody do me the favour of a quick MIR review? bug 299032
<ubottu> Launchpad bug 299032 in isoquery "please promote isoquery to main" [Undecided,New] https://launchpad.net/bugs/299032
<cjwatson> it's on my critical path for getting the installer working for alpha 1
<Haegin> hi, can a preseed file contain commands that are executed before being passed to the client?
<cjwatson> executed on the server?
<Haegin> cjwatson: yeah
<cjwatson> Haegin: no, but there are other approaches that can get you similar effects; what are you actually trying to do?
<Haegin> i want to set a hostname for the client without knowing anything about the client, i really don't care what hostname it gets, it just needs to be unique
<Gast171> dfdds
<Haegin> i am installing ubuntu on about 10PCs in an afternoon each week and netbooting them seems the solution
<cjwatson> Haegin: use preseed/include and point it at a CGI script that generates something unique
<cjwatson> Haegin: or just feed out hostnames using DHCP
<Haegin> cjwatson: i tried the hostnames using dhcp approach and the only thing i could find wanted me to prefill the config files with maps between mac addresses and hostnames
<cjwatson> dhcp assigns IP address, reverse-DNS ...
<cjwatson> you have a finite pool of IP addresses right? :-)
<Haegin> yeah :)
<cjwatson> comment in netcfg says:
<cjwatson>                  * Default to the hostname returned via DHCP, if any,
<cjwatson>                  * otherwise to the requested DHCP hostname
<cjwatson>                  * otherwise to the hostname found in DNS for the IP address
<cjwatson>                  * of the interface
<cjwatson> so just seed your DNS server with the IP address range in question
<Haegin> it is currently giving an error of "" not being a valid hostname which is the problem I am trying to avoid
<Haegin> I think for simplicity i will use the include in the preseed file
<Haegin> thanks cjwatson
<cjwatson> no problem
<pitti> cjwatson: if you are too busy with getting d-i in shape, I can do the installation-report merge; shall I?
<NCommander> dholbach, ping
<dholbach> NCommander: pong
<cjwatson> pitti: it's ok, I'll do it now
<cjwatson> pitti: you can do the isoquery MIR in exchange :-)
<pitti> cjwatson: hehe, deal
<pitti> cjwatson: I didn't get a mail, and it's not on https://bugs.edge.launchpad.net/~ubuntu-mir/+subscribedbugs, hm
<pitti> you mean "write it" then, I take it
<tkamppeter> kagou, pitti, I have also already thought about SRUing bug 294671. Therefore I have nominated it for Intrepid.
<ubottu> Launchpad bug 294671 in gutenprint "Driver reports "ColorSpace is not supported" for Canon iP4500" [Undecided,Fix released] https://launchpad.net/bugs/294671
 * pitti subscribes ubuntu-mir to bug 299032 and does it
<ubottu> Launchpad bug 299032 in isoquery "please promote isoquery to main" [Undecided,New] https://launchpad.net/bugs/299032
<cjwatson> pitti: oh, sorry, I forgot to subscribe ubuntu-mir to the bug
<cjwatson> pitti: I wasn't expecting you to write it, no :)
<kagou> tkamppeter, oh great, thanks !
<cjwatson> installation-report done
<pitti> tkamppeter: nomination accepted; however, we should let this mature a bit more, I feel
<pitti> cjwatson: bzr merge FTW :)
<cjwatson> yeah, not exactly hard work :)
<tkamppeter> kagou, it turned out that the Poppler-based pdftoraster filter has not only problem with SpliX but also with Gutenprint and perhaps also with other drivers. Therefore we will not proceed as we did with the SRU for SpliX (adding the Ghostscript-based pdftoraster to Intrepid's driver package) but we should generally replace the pdftoraster driver by the new one.
<tkamppeter> kagou, with this we will wait for a certain time to see whether the Ghostscript-based pdftoraster driver does not show other problems.
<kagou> ok
<asac> pitti: not really understood if its ffox
<asac> pitti: but its likely that the root cause is somewhere in ffox
<asac> pitti: somehow nspluginwrapper 1.1.2 wasnt built (not attempted) on i386
<asac> while 1.1.0 is properly available
<asac> both were uploaded during intrepid
<persia> asac, I suspect you still have 1.1,0-0ubuntu1 for i386, rather than 1.1.0-0ubuntu2, based on upload dates and P-a-s commit logs.
<asac> persia: do you see a reason in pas commit logs?
<persia> asac, Nope.  The relevant commit is http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.712&root=dak&view=markup
<persia> asac, Sorry.  Didn't scroll to the right enough.  "64-bit wrapper for 32-bit i386 plugins"
<asac> super
<asac> but no bug ;)
<asac> i would like to see what triggers these kind of things
<persia> No.  P-a-s changes aren't managed by bugs.
<asac> how are they?
<persia> email to the P-a-s committers requesting changes.
<persia> Changes get posted to debian-dak@lists.debian.org for review.
<asac> so who to CC ... rmurray, infinity ... anyone else?
<cjwatson> asac: mail addresses at the top of the file
<asac> cjwatson: thanks
<asac> hmm. rmurray is not in there
<asac> ok sent
<zerwas> Is there any work going on in implementing support for intrepid in debootstrap? (scripts/intrepid is missing in http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.10ubuntu1~intrepid1.tar.gz )
<asac> zerwas: you mean jaunty?
<zerwas> asac: no, i meant intrepid. i wonder why the package i linked to does not contain a file called intrepid
<cjwatson> zerwas: it's not missing, it's created as a symlink to gutsy at runtime
<cjwatson> er, build-time
<cjwatson> see Makefile
<zerwas> cjwatson: oh ... i tried to symlink it manually but failed. thanks for the hint, i'll have a look
<cjwatson> zerwas: fear not, intrepid supports debootstrapping intrepid ;-)
<cjwatson> zerwas: get the binary package rather than the source package if you can
<zerwas> d'oh! there it is. thanks.
<asac> TheMuso: do we know anyone from at-spi upstream we could poke to take a look at patch in gnome bug 558028 (lp 278095)
<ubottu> Gnome bug 558028 in atkbridge "atkbridge makes firefox remote client crash during shutdown/atexit" [Major,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=558028
<ubottu> Launchpad bug 278095 in at-spi "MASTER crash in getenv() ... spi_atk_bridge_exit_func()" [High,Fix committed] https://launchpad.net/bugs/278095
<emgent> flashplugin 64bit is out: http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz
<cjwatson> kees,jdstrand_: is it OK if I copy all the packages from intrepid-security that are newer than jaunty into jaunty? the list is: dovecot 1:1.1.4-0ubuntu1.2; enscript 1.6.4-12ubuntu0.8.10.1; linux 2.6.27-7.16; procps 1:3.2.7-9ubuntu2.1
<cjwatson> also pam 1.0.1-4ubuntu5.3 from intrepid-updates
<emgent> DktrKranz: pinghe ponghe
<wasabi> so at some point something started rebuilding /etc/dhcp3/dhclient.conf. Debconf I'm assuming. Except it lost the send "<hostname>" setting.
<wasabi> sup with that?
<wasabi> I thought we'd just fixed that in hardy.
<slangasek> cjwatson: I wouldn't worry about pam, I have an update pending for that (but it also doesn't hurt if you do copy it :)
<wasabi> Hmm. No. Broke in hardy. Well then.
<NCommander> pitti, ping
<slangasek> wasabi: eew?  dhclient.conf is a conffile and shouldn't be rebuilt.
<cjwatson> slangasek: copied for tidiness, then
<wasabi> I just installed a clean hardy, and dhclient.conf is a single line long... and 'looks' generated. And dpkg-dist exists, with the original Debian content
<wasabi> I'm not sure what the thought here is.
<slangasek> wasabi: I'm not seeing this on my hardy install
<wasabi> Hmm.  Well. I just finished the install. Server install.
<NCommander> cjwatson, mind if I ask you an SRU question?
<wasabi> Let me dig through post* stuff and see if I can find it
<cjwatson> NCommander: better to ask than to ask to ask ...
<NCommander> cjwatson, during my efforts to resolve a FTBFS in adept in intrepid-proposed, it seems that the cmake shipped with intrepid has a bug that causes it to hardcode in the paths of some libraries from the build-envrionment, i.e. /build/buildd, etc.
<liw> cjwatson, can I ask slangasek if I can ask Keybuk whether he's OK with me asking sabdfl about presenting him with a question on the general topic of asking me a question?
<cjwatson> kees,jdstrand_: copied dovecot and enscript; linux and procps go together and I might just wait for the kernel team to get an upload together
<cjwatson> liw: :-P
<slangasek> EMETAOVERFLOW
<wasabi> slangasek: https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/221881         Seems to be the same problem.
<ubottu> Launchpad bug 221881 in dhcp3 "dhcp3-client does not send hostname" [Undecided,New]
<NCommander> cjwatson, the version of cmake in jaunty and intrepid-backports has this bug resolved
<wasabi> Oh well. Man. I thought we had this stuff solid now.
<wasabi> Guess not.
<NCommander> cjwatson, it wasn't caught because it seems only the last update to cmake caused it to manifest, and kdelibs wasn't rebuilt until a small patch was added via updates
<slangasek> wasabi: that doesn't seem to be a report of the problem of dhclient.conf being munged to death, though?
<wasabi> It's not clear whether it is or not.
<NCommander> cjwatson, I've been trying to find the commit in cmake's CVS that fixed this, but I don't see any explicate references to a bug that would cause this, it might have been unintentionally fixed. Is it possible we could drop the newer cmake into proposed/updates if I can't isolate the necessary change? (I'm working to see if there is a less invasive solution, but its not looking promising)
<wasabi> He says he also has a dhclient.conf.dpkg-dist, which I do too.
<wasabi> Clean install and I ended up with a .dpkg-dist
<wasabi> I don't know what's doing it either. none of the maintainer scripts seem to be touching it.
<slangasek> so my best guess is that something is creating the dhclient.conf before dhcp3-client is installed; then the installer is using the default "use locally modified version" option non-interactively
<wasabi> Ahh.
<wasabi> d-i must be doing it
<cjwatson> NCommander: the least invasive option would be to fix it just in the packages where it causes a problem; I'm a bit scared of any cmake changes given its reverse-build-dep list
<slangasek> but I've never seen this in practice.  I've also never done a server install.
<slangasek> (not a persistent one, anyway)
<slangasek> wasabi: you said your dhclient.conf was one line long, what's the line?
<wasabi> "request subnet-mask, broadcast-address, time-offset, routers, domain-name,    domain-name-servers, host-name, ntp-servers;"
<wasabi> Funny spacing included.
<slangasek> hmm
<cjwatson> d-i stopped copying dhclient.conf to the target system in intrepid due to conffile problems like this
<wasabi> Okay. So this is just a hardy problem ya'll have fixed
<slangasek> ah, so this is resolved for intrepid but present in hardy
<cjwatson> I believe so
<NCommander> cjwatson, fair enough, although I think my hack meter might self-destruct from the necessary fixes
<cjwatson> this is just from scanning the netcfg changelog though
<cjwatson> NCommander: if it is necessary, I'd like a second opinion from another Kubuntu developer as well; just because I don't know the area at all myself
<wasabi> I've noticed -updates has become a bit more liberal lately. Could this be something for consideration?
<slangasek> wasabi: if a reasonably self-contained fix is possible, we could roll that into 8.04.2, yes
<kirkland> pitti: ping, regarding your comments to https://bugs.launchpad.net/bugs/259631
<ubottu> Launchpad bug 259631 in ecryptfs-utils "Cannot open Private directory after a reboot when "Automatic Login" enabled" [Medium,Fix committed]
<kirkland> pitti: i responded in the bug;  will need some feedback from you either here or there before proceeding.
<kees> cjwatson: cool, thanks.
<kees> cjwatson: I'm fine with copying the kernel/procps stuff too, unless the kernel team actually objects for some reason.
<slangasek> kees: hee, upstream has looked at the per-user env pam_environment patch, and reports that it's full of memory leaks
<kees> slangasek: interesting.  it's been a while since I've looked at that.
<kees> I think tollef wrote it originally.  which processes would see the leak?
<Mithrandir> gdm
<kees> Mithrandir: ah-ha!  I couldn't think of something that was long-running.  (ssh exits, login exits)
<kees> slangasek: looks like it should be easy to fix.
<Mithrandir> maybe gdm-login would be the one.
<kees> Mithrandir: looks like callers of _pam_parse just need to free all the passed variables?
<Mithrandir> kees: yeah, I think so.
<Mithrandir> "full of memory leaks" is probably a slight exaggeration, but fixing this would be good anyway.
<kees> Mithrandir: yeah, agreed.  just a slow build-up of a few strings per login.
<Mithrandir> yup
<Mithrandir> so you'll run out of memory if you log in and out two million times and only have 64MB RAM.
<Mithrandir> (ok, it leaks a bit more, but less than 1k per login, I think, so not exactly a big problem)
<pitti> NCommander: pong
<pitti> kirkland: replied
<kirkland> pitti: yeah, sorry about that ... i should have explained that more clearly in the SRU details
<pitti> kirkland: no need to be, was just a misunderstanding
<kirkland> pitti: i'll add a couple of lines to https://help.ubuntu.com/community/EncryptedPrivateDirectory on how to establish those symlinks
<NCommander> pitti, cjwatson answered my question
<jelmer> Does anybody know whether Ian Jackson hangs out on IRC?
<cjwatson> not routinely on this network
<cjwatson> probably best to e-mail him
<zul> slangasek: ping what do you think of https://bugs.launchpad.net/bugs/282298?
<ubottu> Launchpad bug 282298 in samba "Intrepid: No Access to NAS (samba<=2.2.x) shares any more" [Medium,Confirmed]
<slangasek> zul: the NAS is insecure and they should migrate to something newer; and if they don't like that answer they have to re-enable 'client lanman auth', which is now disabled by default upstream
<zul> slangasek: ok
<slangasek> zul: oh, but there's a patch that fixes a protocol compatibility issue with Samba 2.2?
<slangasek> that would be sensible to apply, then; I assumed this was the known password encryption compat issue
<slangasek> and is appropriate for SRU
<zul> slangasek: yeah theirry did the path I was just going to upload to proposed now
<directhex> hm, usplash looks completely busted when a widescreen console mode is forced
<mohbana_> is anyone using the 64bit flash plugin
<directhex> mohbana_, just trying it out
<mohbana_> directhex: i'd also like to but i'm afraid something will break
<mohbana_> something. flash is always crashing my machine it's absurd
<directhex> mohbana_, thedailyshow.com is no longer a guaranteed browser crash
<joaopinto> mohbana_, you can't break nothing, except that if flashes crashes your browser will crash
<directhex> joaopinto, which nspluginwrapper has been doing for years
<directhex> hm. usplash is very confused. how do debug it.....
<directhex> sigh. bollocks to it. i'll just try a non-widescreen fb mode, and file a bug
<directhex> urgh, 1024x768 is still fail
<directhex> hm. if i can pick between usplash fail or console fail, do i file a bug against usplash or the kernel?
<NCommander> pitti, hola
<wgrant> geser: http://people.ubuntuwire.com/~fujitsu/bzr/multidistrotools/, for future reference. I think there's only one new revision since I last pushed to lp:~ubuntu-qa/multidistrotools/ubuntuwire, however.
<wgrant> There are a few changes in the dead Debian branch that I should probably merge at some point, but nothing too significant.
<pitti> hi NCommander
<NCommander> pitti, in the mood to sponsor and process an SRU for intrepid in main for me :-)?
<pitti> NCommander: can do, but not today any more (about to fall to bed, not feeling well)
<pitti> NCommander: can you please subscribe me to the bug? I'll do it tomororw
<NCommander> pitti, sure. SRU is subscribed, but I'll add you specifically
<pitti> NCommander: SRU is fine, too, I get that
<pitti> ArneGoetje: did you send a CFT to -translators@?
<Ceriand> I'm trying to make some changes to the configure.in file for pango to get it to compile for directfb
<Ceriand> i run autogen.sh and it completes with a warning: configure.in:40: version `pango_version()' doesn't follow Gnits standards
<Ceriand> doing ./configure works fine
<Ceriand> but when i try to run make it gives me the same error as above
<Ceriand> anyone more versed in autoconf-fu care to help me out?
#ubuntu-devel 2008-11-18
<calc> er i'm confused did the desktop team meeting not get changed?
<calc> its still showing up on the fridge as thursday
<beuno> calc, let me know if you need it changed
<calc> beuno: not sure Keybuk_ would know but he is asleep atm
<beuno> calc, ok, poke me and I'll change it or give one of you guys superpowers to do so  :)
<calc> beuno: yea it looks like the meeting should be tuesdays at 16:00 UTC
<calc> https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-11-11
<beuno> calc, so this is the event that needs changing?  http://fridge.ubuntu.com/node/1717
<calc> yes i believe so
<calc> yea the url is it
<calc> though on the wiki it claims the meeting is in #ubuntu-desktopp (?)
<calc> i haven't been at a meeting in 2 weeks so i am not sure if that part is accurate
<calc> i know the day/time is though since i have seen mailing list updates reflecting that part
<beuno> calc, you tell me, I'm just following orders
<beuno> we can change this tomorrow with Keybuk around
<calc> beuno: actually from the looks of it he is on vacation so pitti would be the person to ask i guess
<calc> beuno: i'll find out when i try to go to the meeting where it is for certain :)
<beuno> calc, heh, good luck with that!
<calc> yea :)
 * Hobbsee notes ubuntu doesn't seem to have a 'legal' address.
<Hobbsee> They have a trademarks address, and a PR address...
<mneptok> Hobbsee: whatchya need?
<Hobbsee> mneptok: some waffle words.
<mneptok> Hobbsee: want me to ask the counsel to e-mail you?
<mneptok> Hobbsee: or can you fire something at me that i can then forward?
<Hobbsee> mneptok: fired.
<Hobbsee> mneptok: (thanks
<Hobbsee> )
<mneptok> np np
<mneptok> Hobbsee: sent to our counsel and m.d.z
<Hobbsee> mneptok: cool, thanks :)
<mneptok> for you? da moon, baby.
<mneptok> or ... something.
<Hobbsee> hehe
<Hobbsee> can i have a billion dollars instead please?
 * ajmitch hands Hobbsee 1 billion NZD
<ajmitch> or about 10c australian
<Hobbsee> australian dollars?  Or even euro, or brittish pounds?
<ajmitch> no
<dholbach> good morning
<dholbach> ArneGoetje: I'm just looking at bug 299296 - I'm happy to get it synced, will you take care of getting ttf-sazanami into main and get it seeded?
<ubottu> Launchpad bug 299296 in ttf-kochi "Please sync ttf-kochi 1.0.20030809-8 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/299296
<didrocks> morning
<pitti> Good morning
<pitti> calc, beuno: yes, the meeting is in #ubuntu-desktop, since it clashes with another one in #u-meeting
<amitk_> pitti: how do you feel like uploading a kernel to jaunty to start the day?
<amitk_> :)
<pitti> amitk_: in general I'm fine with that, but ATM we are in alpha-1 soft freeze today, so it's not a particularly good timing
<persia> pitti, With which meeting does it clash?
<pitti> persia: not sure, was just parrotting
<amitk_> pitti: it was cleared with slangasek and cjwatson
<pitti> amitk_: ah, ok, toss me the source.changes then
<persia> Ah.  I ask because I have the two meetings that bracket the old desktop meeting time, so am probably be a good person to shift things.
<cjwatson> pitti: I think alpha-1 soft freeze is *slightly* optimistic given that the installer isn't in yet :-)
<cjwatson> pitti: I'm waiting on the kernel
<amitk_> cjwatson: uploaded
<pitti> cjwatson: was just parrotting the "don't upload anything that brings us closer" thing :)
<pitti> erm, "doesn't bring"
<cjwatson> yeah, this should
<cjwatson> amitk_: how come "Add mouse-modules udeb" shows up as an upstream change?
<cjwatson> I think the kernel team should reconsider this automatically-generated-changelog lark ...
<cjwatson> it's easier to write changelog entries and generate commit messages from them than it is to try to make the other way round work - indeed joeyh explicitly commented that this turned out not to work very well for most folks in practice when he was writing debcommit, http://joey.kitenet.net/blog/entry/devscripts/
<cjwatson> amitk_: although thanks :-)
<StevenK> mvo: Hiyoubrokeupdatenotifierfixitfixitfixit
<amitk_> cjwatson: not completely sure, but maybe because you did not use the git templates that add the UBUNTU: tags for the commits
<cjwatson> amitk_: I didn't commit it at all
<cjwatson> I just sent the patch and figured you guys would take care of that :)
<mvo> StevenK: I did? in what way?
<StevenK> (jaunty)root@liquified:~# /usr/share/update-notifier/notify-reboot-required
<StevenK> .: 8: gettext.sh: not found
<StevenK> mvo: ^
<mvo> StevenK: wehh, sorry, fixing now
<amitk_> cjwatson: ok. I didn't notice the lack of the UBUNTU tag in early morning
<mvo> StevenK: but its still working, no? this message should be harmless, it appears when gettext-base is not installed
<mvo> s/is/should be/ :)
<StevenK> mvo: exit value 2
<StevenK> mvo: So it isn't
<mvo> ok
<mvo> StevenK: thanks, fixed. should be happier now
<StevenK> mvo: You uploaded it, or you'll batch things?
<mvo> StevenK: I uploaded it
<StevenK> mvo: Excellent, thank you
<juliux> hi sodoes somebody know where i can report a broken package at an offical mirror?
<persia> juliux, If it persists, #ubuntu-mirrors tends to be responsive.  If it's not responsive, I think there's an LP project, but I don't find it right now.
<juliux> persia: thxs
<pitti> seb128: do you think we should talk about pidgin->empathy at UDS?
<seb128> pitti: there is not a lot to talk about
<seb128> pitti: I mean we can discuss it but that's not really spec worth, that's rather "try it again and see if it's good enough, if not rollback to what we use now"
<pitti> seb128: there's reviewing of https://wiki.ubuntu.com/EmpathyVsPidginUsability and checking whether it sufficiently replaces ekiga, but of course UDS might not be the best forum to do that
<seb128> pitti: it'll not replace ekiga this cycle
<pitti> seb128: okay; not worth the trouble then, let's ditch bugs then :)
<seb128> that has somewhat been discussed on the lists and they don't aim to replace ekiga for now
<seb128> or rather the softwares are different enough
<seb128> pitti: doing some uds agenda?
<pitti> seb128: yes
<seb128> pitti: do you think we should discuss building upstream language packs there?
<pitti> seb128: I do want to discuss Rosetta and langpacks, yes
<seb128> ok good
<seb128> we should also discuss how to get extra translations back on the CD ;-)
<pitti> 27. CD size war
<seb128> using gettext for gconf would be useful there
<seb128> which is already on your list ;-)
<pitti> right; no need to discuss that, I think, it's a JFDI thing
<seb128> yeah
<pitti> Keybuk: I can't set the priority of https://blueprints.edge.launchpad.net/ubuntu/+spec/smooth-rosetta-imports
<pitti> Keybuk: but you explicitly pointed out that this is important to set
 * mvo reboots to run a hdd diagnose check
<Keybuk> pitti: hmm
<Keybuk> pitti: you don't see "Change priority" at all?
<pitti> Keybuk: I do, but clicking on it gives me "Not allowed here"
<Keybuk> try now
<pitti> Keybuk: anyway, it does appear in the summit.u.c. admin list, despite not having a priority
<pitti> Keybuk: no change
<Keybuk> how about now?
<pitti> Keybuk: \o/ supa-powahs
<Keybuk> freaky
<Keybuk> stupid Launchpad must have a team requirement hardcoded into it somewhere
<cody-somerville> The requirement is probably membership in the distro driver team
<Keybuk> you'd think that, *but* normally it doesn't even show the link if you don't have permission
<Keybuk> so one bit thinks you have permission, since it's letting you click to change priority
<Keybuk> but the bit that lets you actually doing it is clearly looking for something else
<cjwatson> that's not consistent, unfortunately; there are a number of places where you'll see a link but get Forbidden if you try to use it
<wgrant> Mainly in the bits of LP that haven't been touched at all for at least 2 years...
<Keybuk> like Blueprint \o/
<wgrant> Yep.
<wgrant> It hasn't been touched in faaaar too long.
<cody-somerville> It appears that it is also dependent on the view
<sabdfl> liw: maybe
<viviersf> cjwatson, its me again, the kickstart stuff, can it only install packages from main and restricted in the %packages section ?
<cjwatson> viviersf: as of hardy it should allow anything
<viviersf> cjwatson, oh ok, doesnt install gstreamer bad and ugly, lemme read logs
<cody-somerville> Can someone approve https://blueprints.edge.launchpad.net/ubuntu/+spec/jaunty-xfce4.6 for uds?
<cjwatson> mvo: bug 135284: is there a way to feed a list of packages to apt-get such that they'll all end up on the same "command line" even if they overflow the shell's command line length limit?
<ubottu> Launchpad bug 135284 in pkgsel "Unknown maximum list size in kickstart's ks.cfg %packages" [Undecided,Triaged] https://launchpad.net/bugs/135284
<cjwatson> mvo: I think if we could feed them in some other way then that would fix this bug
<mvo> cjwatson: we could use dpkg --set-selection and then apt-get dselect-upgrade
<mvo> cjwatson: not sure if that fits into the requirements
 * mvo looks at the actual bug
<cjwatson> mvo: mm, that might work in this context
 * mvo comments in the bug
<cjwatson> particularly since nobody will have been running dpkg --set-selections by hand yet
<mnabil_work> is there's a ubuntu source for xserver-xorg package in hardy ?
<maxb> I don't understand that question, surely there's an ubuntu source for everything?
<cjwatson> mnabil_work: apt-get source xserver-xorg
<cjwatson> mnabil_work: also, please ask on #ubuntu next time
<cjwatson> seb128: I'm trying to get the GTK d-i frontend working in jaunty, and have run up against the fact that we haven't merged vte packaging from Debian in quite a while so we don't have libvte9-udeb. Any objection to me doing a full packaging merge?
<mnabil_work> cjwatson, thanks
<seb128> cjwatson: no objection, mvo is doing the vte work usually though so maybe worth asking him too before starting
<seb128> mvo: ^
<mvo> cjwatson: sure, go ahead. please just keep our patches :)
<cjwatson> mvo: oh, of course
<beuno> pitti, would you like to get super-powers to add/edit events from the Fridge?
<Keybuk> Libvolume_id now always probes for all known filesystems, and does not
<Keybuk> stop at the first match.
<Keybuk> (!!)
<Keybuk> well, that only took three years
<ogra> and takes 1h to bootup if you have many different blockdevices attached ?
<Keybuk> no more or less than it would now
<mok0> I am doing a "pseudosync", of a package I ported to Debian, I need to set revision back from Debian's -1 to -0ubuntu3. Should I just add a changelog entry at the top where the revision number steps back?
<Keybuk> it just doesn't say "Yup, it's FAT32" anymore when it also has ext3 metadata on it
<Keybuk> it now says "I see FAT32 and ext3"
<ogra> ah, nice
<cjwatson> mok0: why not use -1ubuntu1?
<persia> Keybuk, What do you mean by pseudosync?  Debian diff.gz and Ubuntu tar.gz?
<mok0> cjwatson: Yes why not? Good idea. Thanks
<Keybuk> ok, I can get that tab error when it was Kamion/Keybuk ... but ... *blink*
<ogra> m isnt to far from k on the kbd :)
<persia> Err.  Right.  Not tab error.  Brain error.
<persia> mok0, What do *you* mean by pseudosync?
<mok0> persia: 2 secs
<mok0> persia: bug 296354
<ubottu> Launchpad bug 296354 in mustang "[please-sync] mustang_3.0-1 (universe) from Debian unstable" [Wishlist,Invalid] https://launchpad.net/bugs/296354
<persia> Oh.  Yeah.  You need -1ubuntu1 for that.
<mok0> persia: upstream packaged a new tarball with the same version no.
<mok0> persia: dunno why that didn't occur to me...
<joaopinto> can someone advocate http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
<persia> joaopinto, You'd surely do better in #ubuntu-motu for that sort of request.
<joaopinto> ops, sorry, wrong channel
<pitti> seb128: FYI, I sub'ed you to https://blueprints.edge.launchpad.net/ubuntu/+spec/apport-retracer-maintenance
<seb128> pitti: thanks
<pitti> Riddell: is https://blueprints.edge.launchpad.net/ubuntu/+spec/kubuntu-ipod still an issue in Kubuntu?
<pitti> beuno: I guess it wouldn't hurt; actually I'd just like to add the desktop team meeting there
<Riddell> pitti: no
<Riddell> pitti: libical is needed in main for kdepimlibs, previously kdepimlibs had its own copy of libical, so no MIR needed?
<pitti> Riddell: no, just a MIR bug for tracking, and a quick review of the package by MIR team
<pitti> Riddell: one-liner bug description is enough
<pitti> doko: bug 296466 doesn't look valid to me, but you know better
<ubottu> Launchpad bug 296466 in python-central "[Sync request] Please sync Python-central 0.6.8 from Debian Lenny" [Undecided,New] https://launchpad.net/bugs/296466
<Keybuk> cjwatson: we should have a UDS spec
<Keybuk> oem-config-make-less-yoda-like
<Keybuk> "In which country do you live, hmm?"
<doko> pitti: yes, it is
<pitti> Keybuk: in the dark side of the world you are
<Keybuk> I always wanted to be a Sith
<Keybuk> they looked like they had much more fun
<ion_> Thatâs an anagram.
<Kw4h> i have a question regarding the gspca drivers on ubuntu
<cjwatson> Keybuk: I thought it just said "Select a city in your country and time zone", which doesn't seem too Yoda-like?
<Kw4h> in the sourcecode from both the official gspca driver, and the gspca-source package, my webcam sensor isn't defined right
<Kw4h> after changing it, building the source, and reloading the driver the logs show that it still loads the wrong sensor
<Kw4h> now, I changed the 'gspca' module
<Kw4h> but, the module responsible for the webcam is 'gspca_vc032x' (which is depandant on 'gspca_main')
<Kw4h> does anyone know how those two interact?
<Keybuk> cjwatson: maybe Dell have customised it?
<cjwatson> Keybuk: quite possibly; what did it say?
<Keybuk> "In which country do you live?"
<ion_> en_SW
<cjwatson> Keybuk: perfectly grammatical :-) but not from my oem-config
<Keybuk> the tense is that special "I want to sound posh and use overly stupid forms" style
<Keybuk> "Which country do you live in?"  would be much more ... well
<Keybuk> better
<cjwatson> that's not a tense :-)
<cjwatson> but yes, I agree
<Keybuk> voice
<cjwatson> word order, I think
<cjwatson> "voice" has a special grammatical meaning (active vs. passive)
<Keybuk> sorry, I'm momentarily stunned by the fact that the Mini 9 boots slower with all of the customisations than virgin ubuntu
<cjwatson> some people reorder the preposition in such sentences because either (a) they've been bamboozled by the prescriptivists (b) they want to avoid long tedious arguments with people who've been bamboozled by the prescriptivists
<cjwatson> I often fall into (b) myself
<Keybuk> but course of great english thing about order words matter doesn't
<Keybuk> least at far as the sentence understanding of goes
<johanbr> To paraphrase Dave Barry, "Bamboozled by the prescriptivists" would make an excellent album title.
<calc> beuno: ping
<persia> Keybuk, It's a little more important than that.
<calc> beuno: it is #ubuntu-desktop on Tuesday at 1600UTC after all :)
<Keybuk> oh, latin, it's not; but romantic other languages better than is
<Kw4h> ehm, were my above questions readable? (so I'm not silenced or something :P)
<Keybuk> wow, that's almost, as fun as, impressions, of, William Shatner
<tseliot1> Kw4h: maybe you should ask in #ubuntu-kernel
<Kw4h> heh thanks
<Kw4h> all these channels...
<tseliot1> this channel will soon be renamed #ubuntu-english-syntax
<Kw4h> heh, what's that about then? :P
<Keybuk> cjwatson: the only situation, offhand, that I can think of for beginning a sentence with "In which" is if you're Bob Holness
<cjwatson> Keybuk: as James Bond or in Blockbusters?
<Keybuk> err, maybe I'm thinking of another Quiz Show host?
<cjwatson> Holness' sentences tended to begin "What P is ..."
<cjwatson> or similar :)
<Keybuk> "In which town was Arthur Conan Doyle captain of the local cricket club?"
<Keybuk> type thing
 * persia prefers starting sentences with "in which" when extending other's phrases.
<ogra> "Do you live in a country ? If so, in which ?"
<ogra> :)
<tseliot1> isn't "In which country do you live?" more formal "Which country do you live in?" ?
<directhex> Keybuk, you're thinking of the right one. he was the first bond, on the radio adaptations
<directhex> as well as the presenter of shows like blockbusters
<tseliot1> s/more formal/more formal than/
<Keybuk> tseliot1: not by any rules I'm aware of; English has few formality rules
<Keybuk> unless you're going to go for the full "In which country doest thou live?" :p
<Keybuk> (which is actually informal, but worth a chuckle)
<jdong> Keybuk: I suppose PERHAPS by the rule of not ending a sentence with a preposition...
<jdong> in which country do you live is probably a BIT more formal, but meh.
<Keybuk> http://grammartips.homestead.com/prepositions1.html
<cjwatson> Keybuk: actually, the string you quoted is in UNR
<tseliot1> Keybuk: my Irish tutor told me that word order (of course not always) can make a sentence more formal. And isn't "thou" shakespearean English?
<directhex> tseliot1, thou speakest the truth!
<tseliot1> hehe
<cjwatson> tseliot1: "don't end a sentence with a preposition" is an oft-quoted "rule", but English suffers from the problem that a lot of rules are made up by grammarians and don't correspond to actual language use by the best speakers and writers
<cjwatson> Keybuk: dost :-)
<Keybuk> tseliot1: old English, when it still had a formal you and informal Ã¾ou (thou)
<directhex> good lord, someone using Ã¾ outside the smiley context of :-Ã¾ ?
<tseliot1> cjwatson: my tutor didn't tell me that it was wrong to do so. I guess she learnt it from some grammar book
<cjwatson> tseliot1: cf. languagelog for more rants on the subject :-)
<cjwatson> tseliot1: of course, prescriptivists ultimately influence the language too
<tseliot1> Keybuk: yes, right the "natural" evolution of languages
<cjwatson> anyway, way off-topic :-)
<tseliot1> cjwatson: I didn't know that blog. Thanks for mentioning it
<Keybuk> my English teacher tought me a wonderful rule that I always remember
<Keybuk> "the more boring, pompous and ridiculous the sentence you write--the less likely someone will actually read it"
<tseliot1> ok but, *in which* country did your teacher live? :-P
<Keybuk> England
<tseliot1> Keybuk: jokes aside, what does it take to make a bluprint appear in this page? https://launchpad.net/sprints/uds-jaunty/+specs
<Keybuk> click the "Propose for meeting agenda" and select uds-jaunty
<tseliot1> ok, thanks
<tseliot1> Keybuk: will it have to be approved by someone or am I experiencing some kind of bug? (no hurry, I just want to be sure)
<Keybuk> it will have to be approved by someone
<tseliot1> ah, ok
<Keybuk> it helps if that someone knows what to look for
<tseliot1> Keybuk: https://blueprints.edge.launchpad.net/ubuntu/+spec/wacom-tablets-ui and https://blueprints.launchpad.net/ubuntu/+spec/screen-configuration-ui
<Keybuk> ah yes, I saw those
<Keybuk> who's intending to develop them?
<persia> tseliot1, Is there a reason wacoms should be especially different from other tablet PC touchscreens?
<Keybuk> tseliot1: done
<tseliot1> Keybuk: thanks a lot
<tseliot1> persia: I have yet to receive the actual (wacom) hardware via mail therefore I wouldn't know
<tseliot1> persia: does xsetwacom work for non-wacom devices?
<persia> tseliot1, OK.  I know there's some detail implementation differences in terms of wacom's mouse/pen/etc. support, but as a touchscreen user, I'd certainly like to be able to have something for other tablets or convertibles as well.
<persia> No :)  That's why I'm hoping for something general.
<tseliot1> persia: this is something we can discuss at the UDS
<persia> Indeed.
<tseliot1> maybe ogra can be interested in this ^^ too
<ogra> not really
<Keybuk> scheduled.
<ogra> as i said to persia in a personal chat a min ago, tablets are a lot more painful than touchscreens
<tseliot1> ogra: I suspected that and this is why I might work on it ;)
<ogra> i love touchscreens and will take care fo all of them happily ... but leave tablets (and their ton of different input devices) to someone else as happily :)
<ogra> though it looks like touchscreens will soon be handled by evdev upstream anyway and might not even need any distro love anymore ... i'm in contact with the upstream guy and we'll review the TS stuff in the UDS session
<tseliot1> this would be great
<ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/general-resolution-for-touchscreen-handling
<ogra> tseliot1, will you be at UDS ?
<tseliot1> ogra: yes, I subscribed to that spec. BTW do you use GDK to deal with pointer devices of touchscreens?
<tseliot1> yes, sure
<ogra> cool
<ogra> currently its all done on an xlib level through the driver
<ogra> and i bet the kde people wouldnt be happy if we defaulted to GDK for low level stuff :)
<tseliot1> I guess they have their own way to deal with pointers with QT4
<ogra> they shouldnt
<ogra> its an xorg problem that should be solved on the xorg level
<tseliot1> I was thinking about widgets in which you can test the pointer device
<ogra> but it should provide some kind of API so calibration tools can hok into it
<tseliot1> e.g. the stylus
<ogra> well, thats why i prefer touchsreens :)
<tseliot1> yes, that's what I meant
<tseliot1> heh
<ogra> i dont ant to deal with stylus/eraser and frineds
<ogra> *want
<ogra> or pressure and angle :)
<tseliot1> can you set properties (as in touchpads)?
<ogra> you can set the resolution
<ogra> and a long touch timer (i.e. to emulate a right click on tap+hold)
<tseliot1> but isn't that something that randr should do?
<ogra> it can only do that if it gets the info from the driver
<ogra> and thats where it is configured atm
<tseliot1> yes, of course the driver has to support randr
<ogra> the movelimit parameter defines fi you use a pen or a thumb for your input
<ogra> by adjusting the resolution/sensitivity on a driver level
<tseliot1> and do you use a daemon and/or a configuration file to make these settings permanent?
<ogra> in intrepid i only worked with the evtuch driver ... and made that use hal-input
<tseliot1> ok, so you used an fdi file
<ogra> the driver brings an initscript atm
<ogra> right on combination with a config file
<ogra> *in
<tseliot1> aah
<ogra> the initscript iterates over the config file and calls hal-set-property
<ogra> for all adjustable configuration
<ogra> the fdi file only holds the device identification info
<ogra> but that might change with the upstream switch to evdev ...
<tseliot1> ok, but what happens if X.org is restarted?
<ogra> might not need a separate .fdi
<ogra> xorg asks hal on restart
<tseliot1> ok, so hal properties are still there if xorg is restarted
<ogra> right
<tseliot1> maybe I will use it for tablets when the driver works better with hal
<ogra> that might surely help with the general setup ... but you still need additional stuff for the input devices on tablets
<ogra> since each can have its own handling and config
<tseliot1> I've got X-Kit for that
<tseliot1> but it would require restarting the xserver
<tseliot1> but of course there's xsetwacom
<tseliot1> X-Kit --> to configure the xorg.conf
<ogra> right
<ogra> i dont want xorg.conf to be involved at all
<tseliot1> heh, you can...
<NCommander> Who's archive day is it?
<cjwatson> is the wiki broken? :)
<cjwatson> https://wiki.ubuntu.com/ArchiveAdministration says Riddell
<Riddell> pitti: I've created the bugs https://bugs.edge.launchpad.net/~ubuntu-sru/+bugs?field.bug_reporter=jr
<Riddell> pitti: can I copy to -proposed?
<NCommander> Riddell, so svk ... :-)
<Keybuk> rickspencer3: Welcome! :p
<Riddell> hi rickspencer3
<Riddell> NCommander: onto it
<rickspencer3> Hi Riddell
<NCommander> Keybuk, ping
<jdstrand> lamont: fyi-- I just requested a sync for bind9, since you incorporated all the ubuntu changes
<jdstrand> lamont: hi btw :)
<lamont> jdstrand: kewl
<lamont> which reminds me, I need to finish the util-linux madness
 * calc sees how many new MIRs he needs for OOo 3.0 and lol's
<calc> poor MIR review team :\
<calc> of course poor me for having to write them all as well, heh
<calc> its 21 binary packages, haven't verified how many sources that involves
<TheMuso> calc: Fun.
<cjwatson> you don't need MIRs if it's just replacing something already in main with similar code but a different package name
<cjwatson> so if OOo 2 is dropping out of main at the same time then ...
<calc> cjwatson: oh i mean the new build depends, heh :)
<calc> OOo keeps growing new build depends
<cjwatson> ah
 * cjwatson finally gets around to writing that script to check for override mismatches between architectures that he's been meaning to write for about three years
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/architecture-mismatches.txt
<cjwatson> it should probably group them by source but I don't care that much
 * elmo cries quietly in the corner that that's even possible
<cjwatson> elmo: it does in theory let us get priorities right for all architectures, mind you
<cjwatson> not that we've been taking advantage of it
<cjwatson> some of http://people.ubuntu.com/~ubuntu-archive/priority-mismatches.txt is hard to solve otherwise though
<directhex> i can understand how beagle would disperse from reality for hppa OR ia64, but not both together
<cjwatson> it's a soyuz bug and depends on when they happened to build and when the archive admin processing NEW dealt with them
<cjwatson> I've fixed the overrides in the db now
<cjwatson> (those binaries were supposed to be in main; this sort of thing is why I wrote this script ...)
<NCommander> hey infinity
<NCommander> cjwatson, why is it the binaries require explicate overrides on a per-architectural basis? It seems kinda excessive ...
<cjwatson> soyuz design feature/bug depending on how you look at it
<cjwatson> I brought it up years ago, not particularly planning to do so again though
<calc> if i want echo the value of a variable in debian/rules like KDE_VER in the following
<calc> BUILD_DEPS += , kdelibs$(shell echo "$(KDE_VER)+1" | bc)-dev $(KDELIBS_MINVER)
<calc> shouldn't a line "echo $(KDE_VER)" work?
<wgrant> cjwatson: Is that really all of them, or just those involving main? I expected there to be quite a few differences between universe/multiverse due to some Soyuz races.
<cjwatson> wgrant: that's all
<cjwatson> modulo script bugs of course, but it doesn't hardcode main
<wgrant> cjwatson: Hm. Maybe we detected and got them all fixed already...
<cjwatson> wgrant: it doesn't check "source in universe, binaries in multiverse" type problems
<wgrant> Right.
<cjwatson> which I suspect are more common
<wgrant> I was wondering about that, because that happens a bit.
<wgrant> Because override changes go wrong when something is in UNAPPROVED or NEW.
<cjwatson> might be able to do that, just more complicated logic because that sort of thing is sometimes ok
<calc> gar heisenbug
<wgrant> Checking for source in universe + all binaries in multiverse, should yield fairly usable results.
<cjwatson> yeah, that's true
<wgrant> Well, source in some component and no binaries in that component, in general.
<cjwatson> http://people.ubuntu.com/~cjwatson/architecture-mismatches # warning: not exactly pretty, but patches welcome
 * cjwatson goes out for a bit
<calc> we are in alpha 1 freeze right now, correct?
<directhex> o_o freezes?
<directhex> in november?
<RainCT> directhex: soft freeze in main, for the CD
<RainCT> *alpha CD
<RainCT> directhex: seems like you're missing some ML subscriptions ;)
<directhex> RainCT, more mailing lists? no ta :|
<RainCT> directhex: I think those are send devel-announce or something like that.. low traffic ;P
<NCommander> infinity, pitti, ping
<NCommander> cjwatson, ping
<NCommander> Keybuk, ping?
 * NCommander needs someone who can rescore builds :-/
#ubuntu-devel 2008-11-19
<calc> so i went to the doctor and he prescribed me an immune suppressant... good luck with that (to me) ;-\
 * calc has a feeling he will get much more sick than he currently is before getting better
<ogra> calc, ugh, why is that ?
<calc> ogra: well he gave me that to reduce the inflamation of my eustachian tubes, but i have something else also and my wife has (we think) pneumonia
<calc> so i probably will end up more sick taking this than i am now, but hopefully not, we'll see :\
<ogra> yeah, doesnt sound like fun flying with that
<ogra> ugh, pneumonia ?
<ogra> thats really bad
<calc> ogra: yea she's pretty sick
 * calc going to get something to eat for dinner
<kirkland> slangasek: hey, has your pam-auth-update stuff made it into debian unstable yet?
 * directhex ponders how to fix usplash sickage
<kirkland> slangasek: libpam-runtime, right?
<kirkland> slangasek: looks like it's here: http://packages.debian.org/source/unstable/pam
<kirkland> slangasek: just sanity check me ....
<directhex> bah. too much C, too much low-level. i hate bugs i can't patch
<NCommander> directhex, ?
<directhex> NCommander, trying to patch the suck out of usplash
<NCommander> You are in a maze of twisty little passages, all alike. Exits in all directions.
<directhex> indeed
<directhex> NCommander, i've mostly managed to convince usplash to do what i want on this laptop. mostly. one glitch remains, which i'd like to patch away, but i'm headed into the land of ioctl()
<NCommander> directhex, A sign on the wall says "Abandon All Hope"
<stgraber> directhex: hey, while you are at it, can you fix geode GX2 support too ? :) thanks
<Mithrandir> usplash is love
<stgraber> directhex: X just doesn't start if usplash is started at boot time so basically the customer is either complaining because it doesn't get the usplash or complaining because he only has the usplash but no X :)
<directhex> stgraber, which part of "too much low-level" wasn't clear? o_o
<stgraber> directhex: bah, it's C, could be worse :)
<directhex> oh, hey, look, the random wifi-related lockups i was warned about happened
<NCommander> directhex, x86 assembly code looks at you confused. (it only wants to be your friend)
<directhex> NCommander, this is such a simple desire, too
<directhex> NCommander, i want......... an offset!
<NCommander> x86 assembly language isn't hungry for offsets, its only pinning for fjords
<NCommander> (if anyone gets that reference, you are awesome)
 * directhex nails NCommander to his perch
<NCommander> Not the answer I was looking for
<directhex> as it stands, usplash assumes it has a "full screen" framebuffer to work with. that framebuffer is always 4:3 - but if usplash knows it's really on a widescreen monitor, then it'll use a 4:3 theme which has been compressed horizontally so it looks 16:9 when stretched from 4:3 to 16:9
<directhex> now, if you pass a framebuffer mode via vga=X, then this breaks things a little - usplash still tries to draw assuming the framebuffer is the size it's been informed of (values in usplash.conf, determined god knows when), and if usplash.conf numbers are larger than vga=X, everything goes to hell
<directhex> if usplash.conf is smaller than vga=X, then it displays fine - in the top-left corner
<directhex> so what i would like is the ability to essentially offset usplash, so i can make it use a "4:3" theme, offset from the left margin enoguh to center it on a 16:10 monitor
<Riddell> tjaalton: do you know where /usr/include/X11/extensions/XInput.h has disappeared to?
<Riddell> hmm, should be in x11proto-input-dev according to debian but not yet in our version
<MiladKhajavi> which is better: Intel or AT&T mnemonic for assembly programming?
<savid> Does anyone know much about the nvidia issue as mentioned in the intrepid release notes?  Is there a bug for this?
<RAOF> savid: What particular nvidia issues?
<savid> RAOF apparently certain nvidia drivers are incompatible w/ intrepid...
<RAOF> savid: If you're referring to the lack of 3d drivers for <= geforce4 cards, then that particualar problem has either been fixed or is in the process of being fixed.
<savid> RAOF,  anywhere I can track the status on that?
<RAOF> savid: nvidia released a new driver, which works.  It's either in intrepid-proposed or intrepid-updates, I'm not sure which.
<savid> hmm
<RAOF> There's undobtably a launchpad bug on it, but I don't know the number offhand.
<savid> ok, thanks.  I'll keep looking around for it :)
 * savid needs his compiz!
<savid> Hmm, interesting.   this page says nvidia-glx-177 should work w/ my card (GeForce 8600M GT),  and the release page says that nvidia-glx-177 should work w/ intrepid:   http://packages.ubuntu.com/intrepid/nvidia-glx-177
<aaaantoine> May I ask about gnome-panel applets here?
<RAOF> savid: Absolutely.  It was only cards older than geforce5's that suffered from that problem.
<slangasek> kirkland: it's not in Debian unstable yet, no
<kirkland> slangasek: oh, hrm, okay.  is it intended to land there at some point?
<slangasek> after the lenny release
<kirkland> slangasek: i was trying to get the ubuntu and debian ecryptfs-utils packages back in sync
<persia> kirkland, For pre-release Debian packages, there's a fair precedent for pulling from Debian Vcs with -0ubuntu1 (generally by agreement with Debian maintainers) with a note in the changelog that reminds one to sync when Debian is published.
<kirkland> persia: sorry, it's been a long day, and i've worked on a lot of different packages today ...  which are you referring to?
<persia> kirkland, " i was trying to get the ubuntu and debian ecryptfs-utils packages back in sync" as reference to "after the lenny release"
<persia> It's a suggestion for a workaround to avoid future confusion, rather than a criticism of something you've done.
<kirkland> persia: by "back in sync", i meant that i'm working with the debian maintainer to feed the remaining ubuntu changes back to Debian
<slangasek> persia: ecryptfs-utils diverges in Debian due to local changes for compatibility with pam-auth-update, which is Ubuntu-only until after the lenny release
<persia> Ah, and there's no post-Lenny branch in Vcs yet.  Nevermind: this package is different than many others I've seen recently.
<tjaalton> Riddell: it has moved to libxi-dev
<dholbach> good morning
<TheMuso> Hey dholbach.
<TheMuso> dholbach: When you have some time, could you please do me a favour and add me to ubuntu-main-sponsors please? Thanks.
<dholbach> TheMuso: done
<dholbach> brb
* slangasek changed the topic of #ubuntu-devel to: Archive: frozen for jaunty alpha 1, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pyrosanltd> Hello I have an Tyan k8w system that is experiencing random lockups I cannot find any information in the log files or in my dmesg,  and I am completely stumped as to what action to take next to trouble shoot this, any help or suggestions would be appreciated
<geser> pyrosanltd: have you tried running memtest already?
<pyrosanltd> yes I have
<pyrosanltd> and everything turned out clean
<pyrosanltd> I am able to get the system to hang if I have amarok update my music collection (which is on a NFS mount) while moving a large file over my network say 4gb
<pyrosanltd> also coming from the NFS mount
<RAOF> Well, starting that off and then switching to a VT to catch the kernel output might be instructive.
<pyrosanltd> is there a specific VT that would dump out  kernel output ?
<RAOF> All of them.
<pyrosanltd> ok  one moment let me get an extra irc client up on my laptop
<pyro_> huh
<pyro_> RAOF I was not able to get output in the VT
<pyro_> this is pyrosanltd bthw
<RAOF> pyro_: You got to a VT, and it crashed, but there was no output, or you couldn't get to a VT?
<pyro_> RAOF I did get to a VT but  no output when it crashed
<RAOF> Urgh.
<pyro_> ?
<RAOF> Well, there _should_ have been copious debug spew as the kernel paniced.  I don't know what the lack of output means.
<RAOF> But I can't imagine it's good :)
<pyro_> indeed I have been pluaged with this issue since 6.2.24 was used
<pyro_> I have been living with it for quite some time
<pyro_> I would love to file a bug report But I really do not have enough info to do so
<liw> pyro, how long did you run memtest?
<pyro_> 2 days
<liw> that's long enough
<pyro_> chuckles yeah I wanted to make damn sure it was not my memory
<liw> I typically only get errors from memtest after at least several hours of testing, so the minimum I run it is 12 hours
<liw> anyway, that's my only guess
<pyro_> gotcha
<pyro_> would a rundown  of what hardware I  have in my system be of any help ?
<pyro_> I have a tyan k8W with dual Opteron246he processors an LSI megaraid controller configured with a striped array for my system disk an nvidia Geforece 6600 with 4 gigs of ram
<tkamppeter> doko, are you aware that you are producing a spam bomb bug (bug 299813)?
<ubottu> Launchpad bug 299813 in xine-lib "armel builds failure (package not yet in the archive)" [High,Triaged] https://launchpad.net/bugs/299813
<doko> tkamppeter: well, ok, will continue with separate reports
<seb128> doko: do you really need bugs to list those?
<seb128> doko: isn't the jaunty_outdate listing those?
<doko> seb128: no, these are packages which require fixes, not just buildd admin interaction
<seb128> doko: do you expect the buildd admin todolist to have lot of items?
<seb128> doko: because theorically the outdated list should only be packaged to fix after once the buildds have played catching up on builds
<cjwatson> doko: oh, goodness, yes, don't file a single bug with all build failures as tasks!
<cjwatson> doko: people will rightly get really upset with you. I suggest closing that and opening individual bugs
<cjwatson> you can use tags or whatever for aggregation
<persia> doko, You do know about the tracker at http://qa.ubuntuwire.com/ftbfs right?
<wgrant> persia: I believe the bug is for tracking things which aren't due to Soyuz not detecting depwait properly.
<wgrant> So that list is excessive.
<persia> Fair enough.  Some stuff is known hard as well: http://wiki.debian.org/ArmEabiProblems
<doko> persia: so for which one did I file a bug mentioned in the wiki?
<persia> doko, None.
<doko> persia: yes the tracker is meaningless for now
<doko> cjwatson: yes, will do
<cjwatson> thanks
<Ademan> is there a way to modify the current volume of the system via dbus? (maybe by accessing the volume control applet?)
<tjaalton> Riddell: looks like libxi was autosynced because the old package version was wrong (should've been -1ubuntu6 instead of -2build1), so I'll upload a new version shortly. It'll have XInput.h again
<Riddell> tjaalton: so we deliberatly differ from Debian and want the heard in that package?
<tjaalton> Riddell: yes, upstream moved it while preparing input properties
<Riddell> tjaalton: thanks, I'll look out for your fix and retry the packages that are failing then
<tjaalton> Riddell: yep, it will be uploaded soon
<soren> Err... Can two cores in a Core 2 Duo run at different speeds?
<soren> I'm thinking "no", but:
<persia> soren, Not last time I read the spec, although if they could it might save power.
<soren> $ grep "cpu MHz" /proc/cpuinfo
<soren> cpu MHz		: 1596.000
<soren> cpu MHz		: 2394.000
<persia> Is this a very new chip?
<soren> Not at all.
<soren> model name	: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
<persia> Well, that's special.
 * soren suspects /proc/cpuinfo of lying.
<persia> Is it generated atomically?  Maybe you hit a race condition.
<soren> Oh,  it's consistent.
<soren> /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq tells the same story, even.
<directhex> core 2 can scale each core independently
<directhex> early athlon64 x2 can't. i'm not sure about other chips beyond those two
<cjwatson> doko: could you score up libtool on armel, please?
<cjwatson> doko: the previous version misbuilt amusingly
<doko> cjwatson: done
<cjwatson> thanks
<tjaalton> Riddell: uploaded
<soren> directhex: Really? That's pretty cool. Thanks.
<ogra> hrm, no seb128
 * ogra wonders if its sane to add a libxi-dev dependency to gnome-c-c
<ogra> it FTBFS due to it apparently
<Riddell> ogra: is that the same problem I've had
<Riddell> XInput.h went temporarily missing
<Riddell> but tjaalton just added it back
<ogra> Riddell, ah
 * ogra gives back g-c-c on arm then 
<ogra> Riddell, ta
<directhex> soren, whic is why i have multiple cpufreq applets in my gnome panel
<directhex> soren, perhaps it's a good thing my itanium2 box has no frequencsy scaling though, i don't have a monitor big enough for one applet each
<soren> directhex: Yikes. How many cpus?
<directhex> jms@orac:~> grep -c ^processor /proc/cpuinfo
<directhex> 256
<geser> and you for each an applet in  your panel?
<geser> you have *
<directhex> geser, not on that system
<directhex> geser, one bar per cpu in htop though. needs a tiny font...
<jdong> directhex: ha that's nasty, I remember pulling up Windows Task manager on one of the megacomputers at work.
<jdong> the CPU graph tab was.... interesting....
<directhex> windows runs on megacomputers? :o
<jdong> apparently :-/
<jdong> it was around 64 processors or so
<jdong> dunno any more details about that, I barely had task manager access on the system
<directhex> hm. itanic?
<directhex> don't know of any windows x86 kit with that many cores
<jdong> directhex: yeah I think it was IA64
<jdong> we probably won't see x86 Windows like that until 2008 HPC
<NCommander> infinity, ping?
<directhex> jdong, for the hordes of hpc windows users *snicker*
<jdong> directhex: :D
<NCommander> directhex, mono got uploaded last night
<directhex> NCommander, your armel-patched 1.9.1-4ubuntuwhatever?
<NCommander> yeah
<NCommander> WOrked
<directhex> excellent. please b.d.o it
<NCommander> b.d.o?
<NCommander> oh
<fta2> kees, i tested your native 64b flash, there's a problem with libuuid1, flash expects it in /usr/lib, but it's in /lib so it needs a symlink
<slangasek> Riddell: are you on top of the kubuntu uninstallabilities in jaunty?  livecds obviously won't build right now
<Riddell> slangasek: yeah, things were blocked on that libxi missing header, should be able to get more sorted now
<slangasek> ok, cool
<fta2> kees, hm, nm. this box had nspluginwrapper installed. it worked after purging nspluginwrapper+flashplugin-nonfree.
<seb128> fta2: hi?
<fta2> seb128, hi, yep, i saw for cairo, i've been busy lately
<fta2> and a new cairo is out
<seb128> fta2: ok, are you interest to look into the update or should I do it?
<fta2> i'll try to do it tonight
<seb128> fta2: ok, thanks, debian has the new version in experimental so it would be nice to use that to do the update
<Riddell> slangasek: on the kde 3 side the problem seems to be liblualib50-dev mysteriously moving to universe, ok for me to move back to main?
<fta2> i have a problem with our libjpeg. it's old and insufficient for firefox (and all moz products) so we are using in-source since hardy. now, working on chromium, our lib is also failling some tests (they are using the lib from mozilla).
<directhex> is ubuntu libjpeg using the most recent upstream, i.e. does moz using a svn snapshot?
<fta2> upstream is dead, last version is from 1998 and mozilla continued to improve/fix it since
<fta2> sse/sse2/mmx support, some crashers, etc..
<fta2> it's much faster than ours
<fta2> btw, ours make ff crash during printing
<directhex> API/ABI compat?
<fta2> i think so
<Keybuk> libtool (2.2.4-0ubuntu5) jaunty; urgency=low
<Keybuk> cjwatson: do you have a bug# for that?
<directhex> jms@destiny:~$ apt-cache rdepends libjpeg62 | wc -l
<directhex> 603
<directhex> be sure
<slangasek> Riddell: sure, no objections here if it was in main before
<fta2> directhex, i referenced ~110 patches from mozilla, on top of the last known upstream version. but it's difficult to isolate the old patches, coming from merges during the netscape->free-the-lizard migration
<fta2> I would like firefox and the future chromium to use our system jpeg but it's only possible if we integrate some of those patches
<persia> fta, regarding chromium, have you entered into a naming discussion with the chromium BSU people?
<directhex> fta, if it's ABI-incompat, then you need to make sure all 600-odd packages that dep it rebuild against your new one. if it's api compat, you need to deal with hundreds of devs who want to kill you
<directhex> fta, have you spoken with the debian people? better to minimize divergence in libs
 * persia remembers a number of packages having issues with system libjpeg, and suspects there may be some possibility for coordination.
<cjwatson> Keybuk: no, it was following a build failure
<cjwatson> Keybuk: (dictd)
<cjwatson> Keybuk: it only broke on armel due to the weird way the bootstrap was done
<cjwatson> Keybuk: i.e. it was done initially in a sort of vaguely Debianish chroot that had /bin/sh -> bash, so libtool thought "hey, /bin/sh is good enough" and hardcoded that in /usr/bin/libtool
<cjwatson> Keybuk: when the chroot was fixed/updated to have /bin/sh -> dash, that broke
<Keybuk> cjwatson: hmm, libtool should be ok with dash too though, right?
<cjwatson> apparently not, no
<cjwatson> doesn't support var+=value
<Shanix> hi all, question about a tool called: conga used for control clustering, the only page that I found is https://wiki.ubuntu.com/UbuntuFeistyHAClusters
<cjwatson> Keybuk: http://launchpadlibrarian.net/19676627/buildlog_ubuntu-jaunty-armel.dictd_1.10.11.dfsg-2ubuntu2_FAILEDTOBUILD.txt.gz
<Keybuk> cjwatson: could you file a bug
<Shanix> which says at unresolve
<Shanix> unresolved issue:     * conga packaging complexity and licensing (GPL) since it links with openssl.
<Shanix> any news on that?
<cjwatson> Keybuk: ok, bug 299931
<ubottu> Launchpad bug 299931 in libtool "misbuilds when /bin/sh -> bash" [Undecided,New] https://launchpad.net/bugs/299931
<Keybuk> thx
<cjwatson> Keybuk: (BTW, the practical effect of my change AFAIAA is simply to make armel consistent with the other arches)
<Keybuk> indeed
<Keybuk> it surprised me that you had to force bash and it wasn't ok with dash
<Keybuk> libtool's _supposed_ to be the very model of a portable shell script ;)
<Keybuk> and dash would make it a lot faster
<fta2> directhex, persia, as debian didn't care to do it in >10 years, it's safe to assume that i can experiment on my side and propose to debian later. too bad we don't have a regression test suite for the whole desktop to track eventual regressions.
<persia> fta, For jpeg, yes.  For chromium, I do encourage you to speak with the chromium BSU people.  I suspect that it's easier to get it right the first time.
<cjwatson> Keybuk: well, it's using bash on every other architecture right now :)
<cjwatson> otherwise I wouldn't have made that change
<Keybuk> I'm not arguing that point :p
<cjwatson> defending myself against an imagined charge, perhaps :)
<liw> Keybuk, does MoM remove .git from a source package? looking at lockfile-progs, the Debian .tar.gz seems to have it, the MoM-generated Ubuntu one does not
<Keybuk> not deliberately
<Keybuk> it always favours the ubuntu .tar.gz though
<Keybuk> so if Debian's .orig.tar.gz has a .git and Ubuntu's doesn't, the result won't
<Keybuk> (since there's no point providing a merge that you can't upload due to md5 sum change :p)
<liw> it's a native package so in this instance the tarball is always re-created, as far as I can see
<Keybuk> hmm
<Keybuk> it rarely cares about that ;)
<Keybuk> oh, wait
<Keybuk> isn't lockfile-progs one of the spethial ones
<Keybuk> with extra chest-thumping
<liw> but yeah, the current tarball in ubuntu doesn't have .git
<Keybuk> the Ubuntu one isn't even in the same version series as the debian ones
<liw> I don't see why Debian has .git in there, I'd consider that a bug
<Keybuk> right
<Keybuk> ignore that entierly
<liw> Keybuk, oh?
<Keybuk> that merge is bogus
<Keybuk> the Ubuntu maintainer uploaded 0.1.11 with the version 0.1.11ubuntu1
<Keybuk> which meant that when the next Debian version was 0.1.11-0.1
<Keybuk> the Ubuntu version was *still* higher
<liw> should it be marked somewhere, somehow, so it gets dropped off the MoM list?
<Keybuk> so the maintainer merged with 0.1.11ubuntu2
<Keybuk> I could blacklist it :)  but I felt it was unsporting
<Keybuk> blacklisted
<asac> pitti: i did ppp and network-manager-pptp SRU
<asac> pitti: i uploaded -pptp twice to intrepid-proposed ... so in case it shows up two times, take the last upload
<asac> ok off again
<Keybuk> libtool should so support --without-included-libtool
<Keybuk> to make it use /usr/bin/libtool instead of generating its own
<Keybuk> gettext can do it
<fta2> persia, for chromium, i'm in frequent contact with upstream, and i try to upstream my patches when they are ready.  what are "chromium BSU people" ?
<persia> fta, It's the upstream that handles the package named "chromium" in Ubuntu.
<persia> It's a game called "chromium BSU".  I suspect that working together to determine package names early will lead to the least stress later.
<persia> One of the members of the upstream chromium BSU team is also a member of the Debian Games team, so there's close coordination available at all levels for that package.
<ahasenack> I have mysql installed for test purposes, i.e., I only need it now and then. I ran "update-rc.d -f mysql remove" and
<ahasenack> that prevents it from starting on boot, most of the time
<ahasenack> when there is an update, I get it, but the update marks it again to start at the next boot
<ahasenack> I checked /etc/default and there is no *mysql* file there
<Keybuk> ahasenack: don't use update-rc.d
<persia> ahasenack, That's a bug.  initiscripts should be conffiles, and not autostomped on boot.
<ahasenack> so, what's the proper way to have it installed but not started during boot?
<Keybuk> persia: no, it's not
<persia> Keybuk, No?
<Keybuk> he's using a tool only intended for postinst scripts
<persia> Ah.  Right.
<ahasenack> Keybuk: what's the proper way?
<Keybuk> ahasenack: use a tool like sysv-rc-conf or bum
<ahasenack> Keybuk: that's the "official" ubuntu way?
<ahasenack> Keybuk: just checking, because I don't have them installed (hardy)
<ogra> or just mv S* K*
<ogra> then the distro tools will leave it alone
 * NCommander summons infinity 
<Keybuk> cjwatson, BenC: if it's ok, I'd like to own the module-init-tools and initramfs-tools merges
<BenC> Keybuk: fine by me
<liw> if the only reason to keep a package as a merge is to retain Ubuntu-specific debian/changelog entries, it can be turned into a sync, right?
<Keybuk> liw: right
<cjwatson> Keybuk: fine by me
<liw> hm, I remember having to do something to get requestsync to work with my mail setup
<liw> anyone here understand X events, GTK, or synergy? https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/293589 is need of someone who knows things
<ubottu> Launchpad bug 293589 in gedit "gedit outputs stuff to stdout, prevents background from command line" [Low,New]
<jg> BenC: I gather you also have a Latitude Xt...
<cjwatson> cody-somerville: could you change xubuntu.jaunty/STRUCTURE to say 'include platform.jaunty' rather than 'include platform.intrepid', please?
<cody-somerville> cjwatson, certainly
<cjwatson> superm1: could you change mythbuntu.jaunty/STRUCTURE to say 'include platform.jaunty' rather than 'include platform.intrepid', please?
<superm1> cjwatson, sure
<cjwatson> thanks to you both
<directhex> well they weren't gonna say NO! were they?
<cjwatson> directhex: no reason not to be civil :)
<BenC> jg: yeah
<jg> BenC: turns out that most of the device's functionality is getting most of the way through the usbhid system.  evtest is quite enlightening...
<jg> BenC: You have to move X out of the way to see the results.
<BenC> jg: do you have anything to test with?
<NCommander> anyone around who's in the mood to rescore stuff?
<jg> BenC: first step is to get the events out of the kernel properly.
<jg> The data isn't being entirely correctly decoded.
<jg> and additional stuff needs to be sent up for X to deal with.
 * NCommander turns on the buildd admin like
<NCommander> *light
<jg> A touch is not just x/y, but includes size information.
<BenC> jg: it is definitely all HID stuff though, right/
<jg> BenC: I think so.  I'm under NDA, but I've not received the specs yet.
<jg> evtest makes me think it's a pretty simple extension to where we are.
<Mithrandir> doesn't mpx implement a lot of what you're talking about, with blob events and all?
<jg> Mithrandir: no blob support yet.
<jg> also nothing in the X driver for devices using evdev.
<jg> Peter's demo was on a diamond touch table with spit and bailing wire.
<Mithrandir> oh? http://wearables.unisa.edu.au/mpx/?q=node/88 claims otherwise, but that might just not be merged?
<jg> blobs were a hack, and not merged.
<jg> time to make blobs real....
<jg> The Latitude XT is interesting precisely because it is the first multitouch screen with blob kind of reporting.
<cjwatson> NCommander: would be better to say what you want rescored, so that people know what they're letting themselves in for
<NCommander> Can the buildd admins please rescore x11-utils
 * NCommander tries to find the rest of the to be rescored list
<jg> Diamond Touch tables are a bit hard to come by...
<jg> Mithrandir: we're starting work on an XInput extension v. 2 to do this right.....
<Mithrandir> NCommander: x11-utils/jaunty/armel rescored
<NCommander> Thank you
 * kees scratches his head
<kees> what's responsible for putting utmp in /etc/group ?
<rtg> cjwatson: can you tell me what privileges are conferred by being a member of ubuntu-drivers in Launchpad? I'd really like kernel devs to be able to make their own release nominations. Otherwise myself or ogasawara has to approve/decline all of them.
<savid> So, I've created a patch for a certain app that I've hacked,  and I've used dpkg-buildpackage to re-build it.  How can I install the new deb without having update-manager think that the package needs updating?
<highvoltage> http://no-name-yet.com doesn't go to ubuntu.com anymore :/
<highvoltage> mdz: are you there?
<slangasek> kees: is utmp not a base-passwd group?
<kees> slangasek: ah, base-passwd.  that's what I was looking for.  someone opened a bug saying base-files failed to install due to missing the utmp group (!?)
 * slangasek shrugs? :)
<kees> yeah
<slangasek> base-files does require the utmp group to be present, yes
<slangasek> and it's one of the groups listed in /usr/share/base-passwd/group.master
<slangasek> so "user error"
<slangasek> or "bug in evil non-default tool"
<ogra> tedg, mind if i add a hackish patch to g-p-m to turn off Werror in configure to make the build survive on armel (assuming you will package a new g-p-m anyway soon)
 * ogra wonders what will be left of liboil once doko is done :)
<mvo> savid: please give it a different version number than the one in the archive
<doko> ogra: it fails on the buildd only, so just building without having access to this hardware is ... nice
<ogra> send it over if it doesnt take a day to build
<ogra> i have HW
<nxvl> kirkland: congratulations!
<nxvl> well, almost
<nxvl> :P
<tedg> ogra: Uhm, okay.  If you want you can upgrade to 2.24.2 while you're at it :)
<ogra> tedg, to busy fixing arm FTBFS atm
<tedg> ogra: NP, I'll get to it.  If you just propose your changes as a merge: https://code.launchpad.net/~ted-gould/gnome-power/ubuntu-packaging-2.23
<ogra> tedg, nh, my change should be dropped asap and get a proper fix
<ogra> *nah even
<ogra> something included from gstreamer produces warnings which g-p-m automatically turns into errors ... richard constantly forgets to switch Werror off in releases
<ogra> i had to remind him each release :)
 * ogra has to test-build anyway first ... takes quite a while on ARM
<fta> persia, sorry for the confusion, when i said chromium, i meant the open source version of google chrome, https://edge.launchpad.net/chromium-project; of course, i already knew there's a game named chromium in ubuntu, which is really unfortunate.
<ogra> fta, same prob as epiphany ...
<savid> mvo, by "different version number" do you mean just the version # in the .deb file name?
<tedg> ogra: Yeah, we fixed the first couple FTB errors for Sparc but got stuck on the GStreamer one.
<mvo> savid: just update the debian/changelog file with a new version nubmer before you run debuild
<savid> awesome, thanks
<NCommander> can a buildd admin please rescore kde4libs/armel ?
<Mithrandir> NCommander: given-back
<Mithrandir> (and rescored)
<NCommander> Mithrandir, we just uploaded it, why did it have to be given back?
 * ogra wonders if the armel machines already start glowing :)
<Mithrandir> NCommander: which version did you just upload?
<Mithrandir> 4:4.1.73-0ubuntu5 ?
<NCommander> [ubuntu/jaunty] kde4libs 4:4.1.73-0ubuntu6 (Accepted)
<NCommander> Damn it
<ogra> ouch
<NCommander> can you kill 0ubuntu5?
<NCommander> Or rescore it so it goes last?
<NCommander> We'll loose a buildd for six hours if it builds
<Mithrandir> I don't think it'll be built at all, since the build will be superseded by 0ubuntu6
<Mithrandir> 0ubuntu6 has a higher score
 * ogra wonders if cacao every finishes ...
<ogra> *ever
<ogra> cant take that long to make hot beverage
<shay> hey
<shay> no Xen support on 8.10?
<ion_> /boot/config-2.6.27-7-server:CONFIG_XEN=y
<shay> and compile kernel?
<ion_> No
<shay> $ uname -r - 2.6.27-7-server
<shay> and no /proc/xen/
<ion_> Dunno then.
<shay> and trying to modprobe all the xen-* modules on /lib/modules/`uname -r` give a "No such device" error
<shay> I would like to know if there's anyone involved in the development of Xen on Ubuntu, I would like to help in any way i can
<Daviey> shay: check the kernel mailing list.. it's been spotted :)
<shay> will check, thanks
<ogra> bah ...
 * ogra was wondering why his g-p-m configure mangling didnt work ... running autoconf at buildtime is mean
<Mithrandir> no, it's wonderful.
<ogra> bah
<wasabi> So ... Intrepid has this Samba bug where Winbind crashes every few minutes. It seems to be fixed in 3.2.4 on jaunty. It completely makes winbind useless in Intrepid.
<ogra> only if you think of it while applying evil hacks :P
<wasabi> I'm not sure if it was a specific fix between 3.2.3 and 3.2.4 that solved it.
<wasabi> What would bt eh best way to approach this? Try to pinpoint the exact problem and a quick patch to get in -updates, or advocate that we just port 3.2.4 to -updates?
<Mithrandir> wasabi: how big is the diff from .3 to .4?
<wasabi> eh. dunno.
<wasabi> checking
<wasabi> http://us1.samba.org/samba/history/samba-3.2.4.html
<wasabi> Well, they know they fixed the winbind crash, at least.
<wasabi> And it looks like very few other things are not 'fixes'
<doko> hmm, I forgot to turn off the testsuite run for the cacao-oj6 armel build ... lets look again next week for the results
<ogra> eeek
<ogra> it runs since yesterday already
* spm changed the topic of #ubuntu-devel to: LP down 22:00-23:59 UTC | Archive: frozen for jaunty alpha 1, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<NCommander> lamont, ping, I need your help with xvfb again
<directhex> cjwatson, i think it was you i spoke with before. did you favour including mono-debugger in main, rather than dropping mono-dbg to universe?
<cjwatson> I did say something like that, although I haven't looked at mono-debugger at all
<directhex> cjwatson, well, the package in jaunty currently doesn't serve much purpose. i'm still planning for release, which if all goes according to play means mono-debugger (and mono) 2.2, where jaunty has 0.6 right now
<cjwatson> but all other things being equal it's the approach I'd normally prefer ... stuff in main should come with debugging support as a general principle
<directhex> debian NEW delays are really messing us around
<NCommander> directhex, just do a fast sync (upload with -0, or 1~ubuntu1), and then when it goes through new, it gets clobbered by the package ins id
<directhex> NCommander, huh? explain?
<NCommander> directhex, you can version an upload so that it will get clobbered by the next sync from Debian. A few packages in main do this, and I've done it for the Desktop team
<NCommander> (or just give it a 0ubuntu1, then sync once its in Debian by hand)
<directhex> NCommander, will sync by hand. this is a monumental project. about 100 syncs/merges will be needed (or ubuntu patches applied) after mono 2 syncs in. and we need to rebuild all those things in experimental
<NCommander> so what's stopping you from uploading as 0ubuntu1?
<directhex> NCommander, duplication of work. i don't see why motu and core-devs should alter 100 packages by hand, this far before release, when they can just nab the needed changes from debian
<NCommander> I thought you were waiting on a few individual packages :-P!
<ScottK> NCommander: Even trickier is upload it as -0build1 and autosync will clobber it after it gets out of New.
<NCommander> ScottK, well, I would upload as 0~ubuntu1, or 1~ubuntu1
<NCommander> (0~ubuntu1 if you expect a non-maintainer new upstream release upload)
<ScottK> Well you'd still have to ask for it to be sync'ed over then.
<NCommander> directhex, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506260
<ubottu> Debian bug 506260 in mono "mono FTBFS with recent glibc on ARM" [Important,Open]
<NCommander> ScottK, not if it was 0~ubuntu1
<NCommander> (note the tide)
<directhex> NCommander, i saw. thanks
<cjwatson> NCommander: ScottK is correct - the "ubuntu" substring in a version is what inhibits autosyncing
<cjwatson> in fact that is the entire root of the purpose of putting "ubuntu" in version numbers
<NCommander> cjwatson, oh, I thought only XubuntuX prevented sync, X~ubuntuX would still work
<directhex> okay, i've talked with meebey..... sod debian NEW... i'd like to get people able to work on the packaging transition ASAP, which means uploading a mono stack somewhere people can work with
<cjwatson> NCommander: no, it's just the "ubuntu" substring. that simple.
<NCommander> cjwatson, ah, you learn something new every day :-)
<cjwatson> I don't know where the ~ubuntu idea came from
<NCommander> directhex, I can setup a Debian PPA for you using OBS
<ldiamond> Did anyone here ever build Synergy2 from source? The project seems to be dead and buggy, I was wondering if anyone wanted to start a similar project (from scratch or from synergy).
<directhex> so. NCommander i've got an OBS repo. want mono 2.0 for RHEL5? ^_^
<directhex> NCommander, okay then. let's get this party started. it's gonna be pretty major. i suppose i should mail -devel and -motu about it
<NCommander> directhex, well, I need to setup the infrastructure
<NCommander> I can provide you with x86, and maybe amd64 builders
<directhex> NCommander, i mean uploading a 0ubuntu1 to jaunty.
<NCommander> for Debian etch, lenny, or sid
<NCommander> Oh
<NCommander> So what do you need me for?
<directhex> you specifically? well, nothing. you started offering ME things!
<directhex> NCommander, though if you want to help with the packaging transition, then that'd be sweet ;)
 * directhex preps a 0ubuntu1
<NCommander> sure, I'll help
<NCommander> directhex, LP is down, remember?
<directhex> oh cocks
<ldiamond> Nobody know about any KM/KVM soft switch project around (besides Synergy)
<directhex> back in half an hour though, no?
<cjwatson> at least the bug system is back up already
<cjwatson> well, up-ish
<cjwatson> yeah, it's fine for me
<cjwatson> oh, admittedly I'm using edge
* spm changed the topic of #ubuntu-devel to: Archive: frozen for jaunty alpha 1, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
#ubuntu-devel 2008-11-20
<directhex> and so it begins
 * lamont wonders if bug 300108 belongs to debconf
<ubottu> Launchpad bug 300108 in postfix "during postfix installation i am getting "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process"" [Undecided,New] https://launchpad.net/bugs/300108
<directhex> james_w, thanks
<james_w> directhex: no problem
<directhex> this is kicking my ass, tbh. 1000 word migration guide going to ubuntu-devel and ubuntu-motu in 3...2...1...
<directhex> and i still have 5 or so packages to snapshot from packaging svn
<calc> ugh kino can't do HD :(
 * calc is really not going to be able to convert his wife to linux between no photoshop and no HD video support :\
<directhex> define "HD video support"
<calc> directhex: being able to edit video shot in HD
<calc> directhex: kino squashes into into 4:3 and has no way to keep it as HD afaict
<calc> s/into/it/
<directhex> what kind of editing?
<calc> pitivi seems like it is still in early dev stage from the webpage at least
<calc> need to merge multiple cuts, and resize it to export to DVD, etc
<calc> i can load the file into kino but it messes it up in the process
<directhex> what kind of windows app is comparable? i mean, i'm pretty sure avidemux can do those kinds of things, but it's pretty much virtualdub for linux
<calc> at least dvgrab knows how to dump it off the camera, i may be able to convert to linux while using photoshop and premiere in vmware
<calc> directhex: adobe premiere
<calc> her current machine is too slow to playback hd video so i was going to attempt to edit it on my system, but it can't load it properly without squashing it into 4:3
<cjwatson> lamont: sounds more like user error to me, TBPH - another instance of debconf running somewhere
<cjwatson> lamont: I don't think it's even possible for the lock to hang around after the process has gone away
<cjwatson> lamont: I've commented thus in the bug
<persia> fta, The "unfortunate" nature of the naming is precisely why I suggest early discussion (pre-upload).  Given that Google has more marketing leverage than chromium BSU, I suspect an amicable solution is available.  Not having that conversation soon can lead to the awkwardness that is epiphany.
 * directhex names a web browser "firebird"
<directhex> no, wait
<directhex> more than past my bedtime. monodoc and mono-tools can remain unresolved for one night
<dholbach> good morning
<pitti> Good morning
<NCommander>  morning pitti
<pitti> asac: SRUs> will process, thanks
<NCommander> pitti, care to sponsor some uploads?
<pitti> NCommander: sure, I'm happy to; please subscribe me to the bugs and ask for it
<Hobbsee> morning pitti!
<NCommander> pitti, one of my changes has a huge debdiff because it has a horribly broken clean rule :-/
<NCommander> pitti, https://bugs.edge.launchpad.net/ubuntu/+source/python2.5/+bug/300211
<ubottu> Launchpad bug 300211 in python2.5 "Please sponsor a no changes source upload" [Undecided,New]
<pitti> NCommander: doing ^
<NCommander> pitti, score
<NCommander> pitti, second up is kdelibs. I can post a debdiff, but its somewhat pointless w.r.t. to determining the changes
<NCommander> (yay for broken clean rules)
<pitti> NCommander: python uploaded
<NCommander> Thanks
<NCommander> pitti, https://bugs.edge.launchpad.net/ubuntu/+source/kdelibs/+bug/299909
<ubottu> Launchpad bug 299909 in kdelibs "armel build failure (package not yet in the archive)" [High,Triaged]
<NCommander> pitti, I ran the patch through filterdiff to just pull out the debian folder bits.
<pitti> NCommander: looks good; patch-wise; however, I didn't see any fix to the clean rule?
<NCommander> pitti, I'm not sure how to fix it ATM.
<NCommander> Lintian not giving any warnings about "patch-system-but-direct-changes-in-diff"
<NCommander> So probably the last upload fixed the clean rule, but the package itself was dirty
<pitti> NCommander: indeed, lsdiff -z kdelibs_3.5.10.dfsg.1-1ubuntu1.diff.gz looks horrible
<NCommander> ubuntu2 isn't much better
<NCommander> at least locally
 * NCommander is suprised lintian isn't complaining
<pitti> NCommander: well, it looks alright; it's just autoreconf'ed
<NCommander> ew
<pitti> that's "buildprep" or so
<pitti> uploading
<NCommander> \o/
 * NCommander hates inlining
<persia> inlining?
<NCommander> patch inlining in the diff.gz
<NCommander> maintenance nightmare
<NCommander> (see gcl for an extreme case, and its 70MB diff.gz)
<persia> Oh.  Well, nightmare for many packages.  Saving grace for VCS-managed packages.
<pitti> NCommander: well, for autoreconf'ing I can understand iti
<NCommander> pitti, yeah, that's my exception
<NCommander> If there is no patch system, and a package just needs autoreconf, I'll inline it
<pitti> keeping the actual code changes in debian/patches, and just doing buildprep instead of keeping the autofoo stuff in patches does make things easier
<NCommander> Not worth the headache of adding a patch system, then keeping it work
<persia> pitti, Why not do that at build-time if it is to be done with every upload?  The buildd will do it again anyway, if it's part of clean.
<NCommander> pitti, do you have access to the buildds themselves?
<pitti> persia: I don't like runtime autoreconf much, because I saw it break far too often
<NCommander> +1 pitti
<pitti> persia: but it's common to do that, of course
<pitti> persia: but that doesn't help to get a clean diff either, unless you have some backup/restore magic
<pitti> or use a separate build-tree/
<persia> pitti, Right, but my point is that auto-reconfing in "clean" is runtime autoreconf anyway, at source time, and binary time.
<persia> (unless I'm missing something big).
<persia> So to me it makes sense to either be manual, or to be at build-time.
<pitti> persia: right, it is for source building; buildds don't run clean
<persia> Ah.  I'm missing something big.
 * persia tweaks the local sbuild configuration
<pitti> NCommander: buildd access> not ssh wise or so
<pitti> NCommander: I can rescore builds, stop/start buildds, and so on
<NCommander> pitti, ah, I need someone to kill xvfb on the i386/amd64/lpia builders, and then give-back libgtk2-perl
<NCommander> to a build admin ^
<pitti> NCommander: I can do the give-back, but killing builds isn't possible for buildd admins
<pitti> it needs root on the buildd, and some dirty trick
<NCommander> no
<NCommander> its a process
<pitti> IOW, elmo, lamont, or infinity
<pitti> NCommander: why kill? did it get stuck?
<NCommander> pitti, bug in xvfb on the buildds
<NCommander> It occessionally hangs
<pitti> oh, I see
<pitti> you need one of these three then
<NCommander> So any build that tries to use xvfb where it hangs also ahngs :-)
<NCommander> pitti, since we're on the topic, how about a giveback, all architectures kdebindings
<pitti> NCommander: done
 * NCommander hugs pitti
 * pitti hugs NCommander back
<NCommander> I'm suddenly inspired to fix more FTBFS
<pitti> go, NCommander, go! :-)
 * NCommander notes that desktop should be installable on arm once python lands
<NCommander> python-apt might need a binary rebuild
<NCommander> But other then that ...
 * NCommander sees how to fix gconf-editor
<NCommander> actually
<NCommander> a giveback might fix it
<NCommander> ^ - pitti, mind giving back gconf-editor on i386 only? I want to see if it cleared itself, or if my backup fix is needed
<pitti> done
<NCommander> pitti, I have a possible fix for an armel FTBFS, but I'm not going to be able to actually test build on that architecture (kde4libs is way too big for my 233Mhz board)
<NCommander> The previous upload applied the fix and worked, but I missed a single spot which caused the build to die at the very end
<Hobbsee> directhex: you know, if you want some attention from ubuntu-main-sponsors for https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/300133, you *probably* want to actually subscribe them to the bug ;)
<ubottu> Launchpad bug 300133 in mono "Mono 2.0.1 package (triggers major packaging transition, please read in full)" [Undecided,New]
<directhex> Hobbsee, i've intentionally not done so yet, as I still need to reference monodoc and mono-tools in it, and want to avoid crapflooding main-sponsors by commenting on the bug post-ums-subscribe
<Hobbsee> directhex: ahhh, right, fair enough.
<directhex> and 2am was not the time to work on those, tbh
<directhex> mono-tools is blocked by monodoc, so I haven't actually updated it yet in svn
<directhex> monodoc is... well, short version: monodoc 2.0 as it stands requires mangling of an xml contents page for every doc package. our manglers have been rewritten (but untested) by our main monodoc guy, a dentist who is only online for brief bursts at weekends (making coordination tricky). monodoc 2.2 from svn has dynamic support which we really want, but due to some rearrangements in upstream svn, backporting is a fairly significant p
<directhex> iece of work.
<directhex> there's no "best" solution right now, but ideally i need to see where hanska's got with it on friday, and make a decision on whether to upload 2.0 as-is, wait for his 2.2 backports, or do it myself
<directhex> dholbach, thanks RE libgdiplus
<directhex> james_w, thanks RE gluezilla
<directhex> at least gluezilla builds against xulrunner 1.9 (ff3) now instead of 1.8 (ff2). and, helpfully, the upstream author of that lib now hangs about in #debian-mono
<Hobbsee> ahh
<directhex> i'm half inclined to make a package of the current, lame, mangly 2.0 for my own use, so I have something to work on a mono-tools package with (mono-tools contains a doc browser, hence the dep)
<directhex> but not until this evening. day job first.
<NCommander> pitti, up for another sponsoring?
<pitti> NCommander: a bit later, yes, please sub me to the bug
<NCommander> pitti, you got bug
<pitti> NCommander: uploaded
<tkamppeter> pitti, hi
<seb128> evand: hi, not sure than starting using gnomevfs when it's deprecated is a good idea you should really use gio or gvfs rather
<evand> seb128: noted, will fix
<evand> thanks
<seb128> you're welcome
<danigm> hello, i'm trying to run ubuntu debian-installer in a virtual machine with 32MB of ram, but it hangs at "Early unpacking initramfs...", what pkg-list can I remove to make it runnable with 32MB?
<danigm> with 34MB of ram it runs ok
<cjwatson> danigm: probably some kernel modules or something
<cjwatson> danigm: if you're building it yourself and playing with pkg-lists you are welcome to experiment :)
<tkamppeter> pitti, ping
<pitti> hi tkamppeter
<tkamppeter> It is about CUPS and another SRU.
<tkamppeter> I would like the following bugs SRUed:
<tkamppeter> - The permission problem of the ipp, http, lpd, and serial backends
<tkamppeter> - bug 299707
<ubottu> Launchpad bug 299707 in cups "Impossible to print in reverse order" [Undecided,Fix committed] https://launchpad.net/bugs/299707
<tkamppeter> pitti, note that bug 299707 can have more impact as only making the reverse order not working, like duplicate application of N-up or so.
<ubottu> Launchpad bug 299707 in cups "Impossible to print in reverse order" [Undecided,Fix committed] https://launchpad.net/bugs/299707
<danigm> cjwatson: kernel modules are in pkg-lists also?
<pitti> tkamppeter: backend permissions are scheduled for SRU already
<tkamppeter> pitti, great. Bug 299707 is a 1-byte change which fixes a lot of breakage on CUPS options, like N-up, outputorder, page-set, ...
<ubottu> Launchpad bug 299707 in cups "Impossible to print in reverse order" [Undecided,In progress] https://launchpad.net/bugs/299707
<pitti> tkamppeter: that only affects the PDF workflow, right? thus not debian unstable/lenny
<tkamppeter> It would be nice to SRU this bug together with the backend permissions.
<pitti> tkamppeter: I added intrepid tasks to all three and assigned to me
<pitti> will probably do an SRU today
<tkamppeter> pitti, yes, in Debian it starts only with experimental. Lenny should not contain the cpdftocps filter.
<tkamppeter> pitti, Saivann Carignan has posted a debdiff for SRUing bug 229346, but I think it is not worth the work, as the bug is only a typo in the package description.
<ubottu> Launchpad bug 229346 in ddtp-ubuntu "Typo on string 123" [Undecided,Fix committed] https://launchpad.net/bugs/229346
<cjwatson> danigm: yes, looking like "foo-modules-${kernel:Version}"
<tkamppeter> pitti, ping
<pitti> please don't ping; just ask
<pitti> tkamppeter: 229346> can do as part of the other SRU, but not one by itself, yes
<pitti> tkamppeter: is the Provides: actually depended on by anything?
<tkamppeter> pitti, it is about bug 299542: Mark Purcell from Debian has moved the file /usr/share/pixmaps/HPmenu.xpm from hplip-gui to hplip to satisfy lintian. One release later he has also tried to fix the update conflict, simply adding "Replaces: hplip-gui" to hplip. This still does not work.
<ubottu> Launchpad bug 299542 in hplip "package hplip 2.8.7-0ubuntu6 failed to install/upgrade: trying to overwrite `/usr/share/pixmaps/HPmenu.xpm', which is also in package hplip-gui" [Undecided,Fix released] https://launchpad.net/bugs/299542
<tkamppeter> pitti. ho has it to be done correctly?
<tkamppeter> If this "Replaces: hplip-gui" in hplip I think it would even happenm that hplip-gui gets uninstalled by the update.
<tkamppeter> pitti, one thing I forgot, the "Replaces: hplip-gui" is versioned, it is actually "Replaces: hplip-gui (<< 2.8.6.b-2)"
<pitti> tkamppeter: when was the file moved in Ubuntu? Later than 2.8.6.b-2?
<pitti> tkamppeter: usually packages like that should Conflicts:/Replace: package-moved-from (<< first-version-which-does-not-have-the-file-any-more)
<pitti> tkamppeter: just "replaces" eases apt's upgrade ordering, but is slightly less clean on the dpkg level
<pitti> both are pretty common
<tkamppeter> In Debian the move happened in 2.8.6.b-2, the "fix" happened in 2.8.6.b-3
<pitti> tkamppeter: seems that our 2.8.7-something still had the file in the old location
<tkamppeter> In Ubuntu it must be 2.8.10-0ubuntu1, as this is the first one after 2.8.6.b-2
<tkamppeter> pitti, yes, if you see the debian/changelog our 2.8.7-something is older than Debians 2.8.6.b-2
<tkamppeter> But as both do not appear in the same distribution no epoch is needed.
<tkamppeter> pitti, then I only need to add "Conflicts: hplip-gui (<< 2.8.6.b-2)" to debian/control of hplip?
<pitti> tkamppeter: no, Replaces: hplip-gui (<< 2.8.10-0ubuntu1), AFAICS
<MacSlow> Riddell, hey Jonathan
<tkamppeter> pitti, yes, to cover also the 2.8.7.
<Riddell> hi MacSlow
<MacSlow> Riddell, do you happen to know which classes or parts of Qt allow command-line handling (similar to glib's GOption)?
<MacSlow> Riddell, right now I'm trying poking Qt-reference via that assistant frontend
<Riddell> MacSlow: I tend to write KDE apps which use KCmdLineArgs,
<MacSlow> Riddell, ah ok... that's at least a hint I can start with... thanks
<tkamppeter> pitti, then with "Conflicts: hplip-gui (<< 2.8.10)" and "Replaces: hplip-gui (<< 2.8.10)" all should work for both Debian and Ubuntu?
<Riddell> http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKCmdLineArgs.html
<MacSlow> Riddell, thanks!
<Riddell> MacSlow: pure Qt apps take the command line args as part of the QApplication, but only for the inbuilt Qt arguments (-style -display etc) for your own command line arguments you need to parse them yourself I think http://doc.trolltech.com/4.4/qapplication.html#QApplication
<MacSlow> ok
 * ogra scratches head
<ogra> acpid [i386 amd64]
<ogra> ....
<ogra> why would ltsp-client want to install acpid on armel with that dependency line
<ogra> doko, i dont get it, it shouldnt even try
<cjwatson> ogra: you're not trying to use [] in Depends, are you? it only works in Build-Depends
<ogra> oh
<cjwatson> ogra: if you want architecture-specific dependencies, you have to generate them using substvars
<ogra> it comes from debian ...
<ogra> weird
<cjwatson> the above is true in Debian too
<cjwatson> unless I'm out of date and they implemented it in dpkg
<doko> cjwatson: hmm, wasn't this introduced recently?
<persia> I've seen it a lot in binary Depends though.  Seems a common bug, if a bug.
<ogra> yeah
<cjwatson> doko: it's possible
<ogra> it definately works for packages that are only available for one arch
<cjwatson> if it's implemented, it's at the dpkg-gencontrol level, not at the dpkg level
<cjwatson> so it almost certainly doesn't work for Architecture: all packages
<ogra> i.e. ltsp-client-core has " syslinux [i386 amd64], mkelfimage[i386] | yaboot[powerpc] | aboot[alpha] | sparc-utils[sparc]"
<cjwatson> it probably only works to generate architecture-specific dependencies for architecture-dependent packages
<cjwatson> ltsp-client-core is architecture-dependent, so I can believe that it would work for it
<cjwatson> but it won't work for ltsp-client which is Architecture: all
<ogra> yeah, understood
<cjwatson> I still regard it as a gotcha because of that and avoid it, although y'all may be right that it has been implemented :)
<ogra> well, not in dpkg on ubuntu armel it seems :)
<ogra> else i wouldnt have any prob :)
<ogra> i can pull it in through other ways though and just drop the hard dep for now
<ogra> tjaalton, bryce, can either of you take a look at the xserver-xorg-video-savage FTBFS ? it keeps xserver-xorg-video-all uninstallable on armel (it FTBFS on all arches, so seems a general prob, but the others have an old package available)
<tjaalton> ogra: * Reenable 02_temporary_revert_pciaccess.diff and append all recent pci-rework changes, closes: #483989.
<tjaalton> ogra: that's why it fails
<tjaalton> it was autosynced from unstable
<ogra> ah
<tjaalton> and unstable doesn't have xserver 1.5 which needs pciaccess
<tjaalton> +lib
 * ogra wonders how we will handle that on armel 
<ogra> where you rarely have a PCI bus
<directhex> sigh, hate mail. i should get used to this, i suppose
<Hobbsee> directhex: i was wondering if that was meant in jest.  Apparently not.
<Hobbsee> wow, it's even a known contributor.
<directhex> oh, he did CC the mailing list in the end then? i was just in To:
<Hobbsee> directhex: if it was Morten?  yes.
<directhex> aye
<hyperair> hmm? hate mail about what
<tjaalton> ogra: I can revert that change so it'll build again
<directhex> i mean, i'm pretty sure there are those present who disapprove of the work i do for debian/ubuntu (cough), but both debian-legal and SABDFL have made their decisions on the score ni question
<ogra> tjaalton, that would be great (and unleash a lot of packages for armel)
<cjwatson> Hobbsee: if somebody is sending hate mail to ubuntu-devel and is on the auto-accept whitelist, please take them out of the whitelist ...
<Hobbsee> cjwatson: it was to -motu.  I checked that first :-S
<cjwatson> (I didn't see it in the queue, I assume you processed it)
<cjwatson> oh, ok
<Hobbsee> cjwatson: but, yes, noted for future reference :)
<persia> Also, wasn't hate mail towards a person, but towards a piece of software.  Still questionable, but not in quite the same class.
<tjaalton> isn't it ok to hate software, like certain operating systems and such :)
<directhex> i don't mind hating on apps, i mind "i hate fooapp for spurious reasons, so i want to ban you from contributing free software to ubuntu"
 * Hobbsee sends the good old "this is not on"-style mail.
<tjaalton> directhex: right, didn't read that far :)
<Hobbsee> directhex: yes, I thought it was in *particularly* poor taste, as it was so completely and totally irrelevant, and really mentioned nothing of use in your mail, apart from the fact that it was mono, and it was being upgraded
<persia> Yeah.  Not an ideal mail, and not aligned with that thread.
<directhex> yeah. i DO question the kind of thought process that says "i will help save freedom, truth, and justice, by ensuring this IDE remains at 1.0 instead of 2.0. this will cause microsoft corp to go bankrupt. hail eris!". but i'm stepping into ad hominem here, so i'll quit when i'm ahead
<Hobbsee> persia: maybe do the list a favour, and moderate that thread, and go thru it regularly?  I know you're busy though, but mailman is quite fast :-S
<persia> Hobbsee, Hrm?  I'm not a listadmin for that list.
<Hobbsee> persia: oh, I thought you were, as a member of the MC.
<persia> Hobbsee, Nope.
<persia> The set of listadmins for that list is similar to the set of people who are MC, but there are ex-MC who are still listadmin, and current-MC who are not.
<directhex> on a related note, i've now completed a list of all packages affected by the transition, including versions in sid/exp/jaunty
<Hobbsee> oh, cool
<tjaalton> ogra: uploaded
 * ogra hugs tjaalton 
 * tjaalton hugs ogra for noticing the prob
<tkamppeter> pitti, I have tried with both Replaces: and Conflicts: and get http://pastebin.ubuntu.com/74741/
<pitti> tkamppeter: right, that's the bit about "make apt less confused"; I think it works better with apt
<pitti> tkamppeter: if you drop the conflicts, it should work with dpkg, too
<pitti> tkamppeter: or you build a local archive with apt-ftparchive packages and use apt-get to upgrade
<tkamppeter> pitti, with only Conflicts: it is worse: http://pastebin.ubuntu.com/74745/
<pitti> tkamppeter: yes, you either need both, or only Replaces
<pitti> just conflicts will hold back the pacakge
<tkamppeter> pitti, then I use the version with both and hope that solves the problem. I hope it will not uninstall hplip-gui for all users.
<tkamppeter> pitti, bad thing is also that Mark Purcell has added a 2.8.6b after my 2.8.7 in the SVN trunk to do an after-freeze update for Debian, instead of branching the SVN for the after-freeze update.
<pitti> tkamppeter: no, at most they will not upgrade at all
<pitti> eek, he should have created a lenny branch
<tkamppeter> pitti, and what to do if it does not upgrade? Is this a bug in dpkg and/or apt which prevents from moving files from one package to another?
<pitti> tkamppeter: no, it shoudl work; as I said, you can test it with apt-ftparchive and apt-get, but it's really such a standard situation that I'm sure it'll work
<tkamppeter> pitti, so I will build and upload it with both Replaces: and Conflicts: now.
<fta2> persia, i don't see how we can easily solve the naming conflict with chromium. it seems to me that if we do a transition from chromium to chromium-bsc, at least some people with the game installed will end up with the browser
<tkamppeter> pitti, uploaded.
<persia> fta, Depends on the plan.  Maybe have both chromium-bsc and chromium-browser for a while, and then transition.  I just think it's worth having the discussion as early as possible.
<pitti> tkamppeter: I didn't find any LP bug for debian bug 489045, so I won't SRU it for now
<ubottu> Debian bug 489045 in cups "cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect" [Grave,Closed] http://bugs.debian.org/489045
<tkamppeter> pitti, probably it was never reported to Ubuntu. I got only aware of it through your debian/changelog and I considered it a severe issue which should be fixed in Ubuntu even without a Ubuntu user having hit it.
<pitti> tkamppeter: right, it's an ugly bug, but very hard to reproduce, and it seems to happen very seldomly
<pitti> and it's not obviously regression free
<fta2> persia, so far, i called the package chromium-browser, and upstream is now aware of that name collision. they didn't give me any direction so far, mostly because they think it's too early to work on packaging, with which i only partially agree.
<directhex> tada: http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO
<directhex> your 1-stop reference to the mono packaging migration
<seb128> directhex: good work there ;-)
<directhex> seb128, yeah. perhaps i should do some actual day-job work
<directhex> waiting on some mails, moaning about suse, it's a hard life
<seb128> heh ;-)
<directhex> got a 500-core cluster i can't use, but hey, that's suse for you
<persia> fta, OK.  When you have some time, it's worth chatting with them.  If not, no worries.
<seb128> doko: could you explain the change on bug #299911 and why it worked on debian, and do you plan to change your changes to debian too?
<ubottu> Launchpad bug 299911 in gtksourceview "armel build failure (package not yet in the archive)" [High,Fix released] https://launchpad.net/bugs/299911
<doko> regex.h defines these only for __USE_GNU, likely the newer glibc
<doko> or does debian build with -D_GNU_SOURCE by default?
<seb128> doko: ok, could you change the change to debian? they will likely have the same issue and there is no need to create an ubuntu delta
<seb128> dunno
<seb128> I've no clue about armel
 * ogra wonders why it isnt in debian 
<doko> seb128: it's not armel specific, fails on every arch
<directhex> sniff sniff... glibc 2.8 changes?
<seb128> doko: ok, you will send the patch to debian right?
<doko> seb128: come on, you're our gg ;)
<seb128> doko: it's ok for people to upload desktop packages but it's not ok to create extra delta and work for the desktop team without good reason
<seb128> either you do the work correctly or you let somebody else do the changes
<doko> seb128: no, afaik we don't have such a policy, and again, it's needed for armel installabilty.
<seb128> I appreciate you want to get armel going, it's not a good reason to quickly upload and let the extra maintainship work to other people then though
<seb128> doko: I'm not going to increase my workload you don't want to do things properly, if you don't send that change to debian I'm going to drop it and sync again next time they do a change
<ogra> anyone with buildd admin power to log in to the buildds directly: libgtk2-perl needs some special hand holding (mainly killing off the running xvfb instance from the last upload) in i386, amd64 and lpia buildds before it can be given back
<cjwatson> doko,seb128: guys, please, sort this out. (a) doko should send the change to Debian (b) seb128 shouldn't drop changes that haven't been sent to Debian but are still needed.
<seb128> well right, but I'm not going to merge the package for doko next cycle if changes are not sent to debian
<james_w> could a buildd admin please rescore akode/jaunty/armel, I'd like to know if my patch worked sometime this week :-)
<Hobbsee> james_w: done
<james_w> thanks Hobbsee
<Hobbsee> james_w: you're welcome
<ogra> Hobbsee, do you have ssh access to kill procs on the buildds ?
<Hobbsee> ogra: uh, no?
<ogra> sad, ok, seems i need lamont or so
<Hobbsee> ogra: the only people who have ssh into chinstrap and beyond are canonical employees, and last i checked, i don't work there.
<cody-somerville> Actually, it isn't even canonical employees :P
<cody-somerville> Its only the elite IS sysadmins
<ogra> heh
<Hobbsee> cody-somerville: well, i did'nt say *where* beyond ;)
<dholbach> can somebody please tell me which value you get for   cat /proc/acpi/*/fan  | grep speed   ?
<soren> cat: /proc/acpi/*/fan: No such file or directory
<dholbach> I have   /proc/acpi/ibm/fan    it might be different for others
<soren> On all my systems..
<dholbach> I'm sorry - I don't know where the fan speed is on other systems - I just wonder if 3867 is not a bit much when the machine is not actually doing much
<dholbach> I turned up the music already to hear less of the fan, but I'm not sure that's the best solution ;-)
<tedg> Hmm, my fan only goes on when the screensaver kicks in -- should turn off the fancy GL screensaver :)
<dholbach> so no numbers from anybody? :)
<johanbr> The only thing I have named fan anywhere in /proc/acpi is an empty /proc/acpi/fan directory (but my fan works fine).
<dholbach> looking at the bugs in LP, I guess I can happy that my machine does not overheat :)
<directhex> what johanbr said.
<directhex> let me try my laptop
<dholbach> in the thinkwiki it says you can just put "level 2" into some file and it will throttle down, but I think I prefer "auto"
<seb128> dholbach: there is no fan information on my laptop apparently
<persia> dholbach, I've previously had speeds from 300 to 8000, depending on fan size and heat.
<directhex> nothing on the laptop
<dholbach> alright, maybe I'll just ask in #ubuntu-kernel :)
<doko> james_w: I don't know why it fails on armel, but not on the other architectures
<james_w> doko: akode?
<doko> yes
<james_w> yeah, me neither
<james_w> it failed again due to a missing header in another file
<Keybuk> kirkland: any word from Ted?
<james_w> I don't really want to keep trying to fix it like this, It'd be much more efficient with access to hardware
<kirkland> Keybuk: nothing in my inbox yet
<torkel> dholbach: speed:3312
<tedg> kirkland: Keybuk: Not me, right?
<kirkland> tedg: ;-)  nope
<kirkland> tedg: ted tso
<tedg> kirkland: Okay, just checking I didn't miss a mail.
<kirkland> Keybuk: i have his cell #, i'll call in a bit, when the west coast is on a reasonable hour
<kirkland> tedg: well i can't guarantee that :-)
<dholbach> thanks torkel, so it's probably not too bad
<lamont> ogra: what process where and did you get it killed already?
<Mithrandir> james_w: you know qemu can simulate arm, right?
<ogra> lamont, no i didnt yet, its the old xvfb keeps running for libgtk2-perl builds thingie
<persia> Mithrandir, The patch for EABI is widely considered somewhat unstable.  Do you know of a version that works well for armel?
<Mithrandir> persia: hm, ok.  I didn't play with it
 * persia has only looked at qemu upstream and qemu-arm-eabi upstream
<persia> Mithrandir, For old-ABI, it works just peachy
<Mithrandir> yeah, but that's not helpful here
<persia> So Debian "arm" architecture works, but "armel" for either Debian or Ubuntu is less stable.
<Mithrandir> I guess you could use a chroot on an n810 or something.  Slow, though.
<ogra> lamont, must be on zirconium, palmer and crested if i didnt get that wrong
<persia> Mithrandir, That's what most of the porters with hardware have been doing.  n810, NSLU2, etc.
<persia> BeagleBoard or GumStix is probably a better choice for speed, but nobody with those has been making much noise.
<lamont> ogra: nothing looks amiss on zirconium
<ogra> lamont, well, i'll just try a give-back, lets see
<lamont> ditto on the other two
<lamont> the only one I've seen this week is xvfb-run, which needs a bit of identification (next time we hit it, for sure...)
<ogra> lamont, i just know you had to kill xvfb-run on ppc yesterday, so i wanted to make sure its out of the way before giving back
<ogra> lpia given back now, lets see
 * lamont checks all the buildds for xvfb-run
<ogra> lamont, looks like libgtk2-perl is just failing on molybdeium
<ogra> *molybdenum
<lamont> ogra: if it helps, it's running: /usr/bin/perl -w t/GtkRecentChooser.t
<lamont> and xvfb-run is in the process tree
<ogra> well, i only saw the log on LP
<lamont> so I rather expect that after it finishes failing, there might be some pain left over
<ogra> and the messages looked similar
<doko> NCommander: back to zero with kdelibs and kde4libs
<crweb> what package owns the default ubuntu background and how does it set it to default?
<_MMA_> crweb: Its a gconf key I believe.
<ogra> ../libtool: line 818: X--tag=CC: command not found
<ogra> ../libtool: line 851: libtool: ignoring unknown tag : command not found
<ogra> ../libtool: line 818: X--mode=compile: command not found
<ogra> ../libtool: line 985: *** Warning: inferring the mode of operation is deprecated.: command not found
 * ogra scratches head
<_MMA_> crweb: Looking at Synaptic should show you what package the background comes from. Either ubuntu-wallpapers or ubuntu-artwork. I forget.
<doko> persia: please wait with killing sun-java5 in jaunty. there will be one more upload, which I need for -updates in earlier releases. it's easier to do this work in the development version first
<doko> ogra: wrongly regenerated?
<ogra> doko, well, i didnt do anything but dpkg-buildpackage -b for gnome-power-manager on armel
<ogra> it seems to work on x86
 * ogra tries again on the faster arch
<seb128> ogra: try running autoreconf to fix the error
<persia> doko, No rush planned.  slytherin will put together a spec, and we'll do a spec review process to make sure all interested parties concur before dropping it.
<ogra> seb128, hmm, i thought cdbs does that automatically
<persia> doko, The general goal is just to try to drop it before Jaunty releases, if it's not blocked by something, so as to give fair warning to uses that they have to start migration plans for the next LTS.
<seb128> ogra: the cdbs logic is buggy apparently
<ogra> DEB_AUTO_UPDATE_AUTOCONF = "yes"
<ogra> ah, k
<doko> yes, agreed
<ogra> hrm
<soren> Keybuk: Do you have an opinion on bug 44194, in particular the fix applied to the udev rules file for ifupdown?
<ubottu> Launchpad bug 44194 in netbase "wpasupplicant doesn't start when the network start" [Undecided,Fix released] https://launchpad.net/bugs/44194
<Keybuk> can you provide me a link to the diff you'd like me to look at?
<soren> Keybuk: The first check in a current (intrepid and jaunty) /etc/udev/rules.d/85-ifupdown.rules.
<Keybuk> oh, that
<Keybuk> I saw that, and wondered who'd been taking drugs
<soren> I'm glad we agree.
<soren> IMO, what we should do is:
<soren> Remove it, and make sure that any if-up.d script bails out if it needs rw access to various things.
<Keybuk> indeed
<Keybuk> it's perfectly valid to have no rw access at all, ever
<soren> That way, if stuff just needs basic ifconfig, it works, and everything else gets to get configured later (S40networking)
<soren> Keybuk: That's also a very good point.
<soren> Keybuk: So: Remove the patch, thus  attempting configuration at interface discovery, and filing bugs against packages with if-*.d scripts that can't deal with this... Sounds like a plan?
<Keybuk> right
<Keybuk> but you'd have to fix the underlying wpa_supplicant bug anyway
<soren> s/you'd/someone would/ :)
 * soren glances at siretart :)
<soren> Keybuk: But great, thanks for your input.
<kirkland> Keybuk: how do i suspend/hibernate a system from the command line?
<siretart> soren: sorry?
<Keybuk> kirkland: pm-suspend ?
<kirkland> Keybuk: is there a tool, or is it an echo of something to /proc/yada/yada
<kirkland> Keybuk: thx!
<soren> siretart: bug 44194
<ubottu> Launchpad bug 44194 in netbase "wpasupplicant doesn't start when the network start" [Undecided,Fix released] https://launchpad.net/bugs/44194
<siretart> oh that one
<soren> siretart: Read the last 15 minutes of scrollback here for more context.
<siretart> so you argue that my fix was wrong. correct?
<soren> Yes.
<siretart> okay. what's the problem with the fix?
<soren> It stops interfaces from being configured at discovery time.
<soren> and that makes me cry.
<soren> and kittens die.
<soren> Please. Think of the kittens.
<siretart> why does that happen? (sorry, I just arrived at my desk and context switching is expensive)
<Spads> siretart: soren weeps acid tears in the pet shop
<Spads> siretart: HTH, HAND
<soren> siretart: Why kittens die?
<soren> siretart: I stab them. And it's your fault.
<siretart> soren: why interfaces are no longer configured at discovery time
<soren> siretart: ah.
<siretart> soren: without the fix, the interface are not configured at boot time. which I consider worse
<soren> siretart: Because discovery time is waaay before S40networking.
<soren> siretart: Why wouldn't they be?
<siretart> read the bug?
<siretart> espc. https://bugs.edge.launchpad.net/ubuntu/+source/wpasupplicant/+bug/44194/comments/10
<ubottu> Launchpad bug 44194 in netbase "wpasupplicant doesn't start when the network start" [Undecided,Fix released]
 * soren goes to read it again
<soren> I don't see why wpasupplicant's failure to function properly at that time should make everyone else suffer?
<ogra> and especally the kittens
 * ogra ha a totally new view of soren now 
<ogra> *has
<soren> Hey, it's not that I want to stab them. They just make excellent hostages.
<robbiew> james_w: do you have a spec/blueprint that I can point to for UDS scheduling purposes?
<robbiew> james_w: only need a stub
 * soren goes to dinner
<james_w> robbiew: I'll write a stub for you now, sorry.
<robbiew> james_w: great...thnx :)
<siretart> soren: damn, university just went offline, I'm now on my mobile via umts
<siretart> soren: you still did not explain why the patch would break configuration at discovery time
<siretart> soren: would you please summarize your concerns in a new bug and give me the chance to comment on that?
<siretart> I need to hurry home now anyways
<siretart> soren: in short, wpasupplicant won't work before S40networking. I cannot give you the exact details why that doesn't work, but before reverting my change, please investigate that use case first
<siretart> if you want to fix that, please do so after reverting the change that unbreaks wpasupplicant at boot time. btw, that is the most common way of using wpasupplicant on debian,and I do consider it a very important use case
<ogra> oh, ekiga magically fixed itself on armel
<doko> well, not that magically
<ogra> did you give it back ?
<ogra> i dont see any upload
<ogra> ah, the autoreconf on g-p-m seems to have helped
<ogra> which leaves me with an even more awkward patch ... but it will build on armel
<kees> pitti: still around?
<pitti> kees: *wave*
<james_w> robbiew: https://blueprints.launchpad.net/ubuntu/+spec/distributed-development-debian-import
<robbiew> james_w: thnx!
<lore20> hello
<lore20> i'm trying to compile brasero 0.8.3
<kees> pitti: cool.  say, I've been pondering something slightly crazy, and I wanted to see what you thought of a possible (ab)use of jockey.
<lore20> i did "./configure" and "make", without any error
<kees> pitti: I want to do this: https://blueprints.launchpad.net/ubuntu/+spec/use-pae-when-possible
<pitti> kees: oh :) shoot
<lore20> but when I type "checkinstall --install=no"
<kees> pitti: basically, we can only fit 1 kernel on the install CD, and as such it needs to be the -generic
<Riddell> enrico: any idea what causes this in jaunty?  debtags.cc:232: error: 'struct ept::core::PackageState' has no member named 'isUpgradable'
<kees> pitti: however, I want hardware that is PAE-capable to run the -server kernel to get PAE, and therefore "nx" protections.
<lore20> I get this error: "/bin/mkdir: cannot create directory `/usr/local/etc/gconf': No such file or directory "
<ogra> ++for rneaming -server
<kees> pitti: (jaunty's -server kernel may get renamed to be a more sane name)
<ogra> *renaming
<kees> ogra: totally
<ogra> all my ltsp users switch to -server and are always concerned that its not a deskto kernel
<lore20> why?
<kees> pitti: it's not clear to me yet if this will be possible entirely from the installer, so I was trying to think of a way to have jockey prompt for it
<ogra> ltsp usually uses >4G
<kees> ogra: yeah, lots of people have desktops that they run 32bit and wonder where their memory went too.  :P
<ogra> yep
<lore20> It can't make a dir cause it doesn't exists?
<kees> pitti: does jockey already prompt for system reboots when installing restricted drivers?
<pitti> kees: in principle this is fairly easy to do (write handler which checsk the PAE bit and installs -server if enabled)
<ogra> lore20, please see /topic
<pitti> kees: the problem is how to describe and communicate this thing to the user in words they can understand
<kees> pitti: sure, but that's just a bit of word-smithing.
<pitti> kees: reboots are not tied to restrictedness, but to the particular handler
<kees> pitti: I think "use all your memory" and "protect against crackers" would be motivational.
<pitti> kees: if a handler gets enabled, but detects that it isn't active yet, it is shown as "needs reboot", yes
<kees> pitti: perfect.
<enrico> Riddell: that's mornfall's stuff
<enrico> Riddell: he's probably changed something
<kees> pitti: another handler I'd like to add then, is one that detects that both -generic and -server are installed, and that -server is booted.  to prompt for the removal of -generic.
<pitti> kees: installer> entirely possible for netboot and DVD, but not CD, yes
<enrico> Riddell: do you have a link to mornfall?
<kees> pitti: right.  and it's the CD I'm most concerned about.
<Riddell> enrico: a link to mornfall?  he's in #kubuntu-devel dunno if he's at computer
<kees> pitti: that's the bulk of installs, as well as the fact that jockey will prompt for people that do upgrades.
<tkamppeter> pitti, for a possible SRU on bug 294671, bug 292257, and bug 298982 I got a patch for the Poppler-based pdftoraster from Koji Otani. I did not ask these people for testing the patch yet, but we could apply it to the -proposed CUPS package and see whether it helps. WDYT?
<ubottu> Launchpad bug 294671 in gutenprint "Driver reports "ColorSpace is not supported" for Canon iP4500" [Undecided,Fix released] https://launchpad.net/bugs/294671
<pitti> kees: why would you want to remove -generic? that rather sounds like system-cleaner
<ubottu> Launchpad bug 292257 in cups "epson printer d88 (dup-of: 294671)" [Undecided,New] https://launchpad.net/bugs/292257
<ubottu> Launchpad bug 298982 in ubuntu "Canon IP 4500 and printing Color (dup-of: 294671)" [Undecided,New] https://launchpad.net/bugs/298982
<ogra> wouldnt "last good boot" take care of that ?
<kees> pitti: to avoid grub-positioning problems, reduce update bandwidth, reduce redundancy, reduce size of install.
<kees> ogra: I'm nervous about removing -generic while it's running.
<kees> pitti: what is "system-cleaner"?  (and how does it run?)
<ogra> well, last good boot only removes after the first successfull boot of a new kernel as i understood it
<liw> kees, system-cleaner is the tool I wrote to remove "cruft" (it's now called Cruft Remover, although the package name is still system-cleaner)
<pitti> kees: cruft-remover now
<pitti> ogra: last-good-boot was pulled from intrepid
<ogra> pitti, and ? arent we taking jaunty here  ?
<kees> liw: ah, very cool -- does it get run automatically?
<ogra> i would expect it to come back
<liw> kees, nope, user has to invoke it
<ogra> but BenC can surely comment better on that
<pitti> ogra: yes, certainly
<pitti> we want it, it just had implementation problems
<ogra> right
<ogra> so jaunty should be its release :)
<ogra> which then should solve the system cleaner prob
<enrico> Riddell: ping him there then
<pitti> tkamppeter: that sounds like a good followup SRU together with the "spin on backchannel EOF" bug, so that one coudl sit in -proposed longer
<pitti> tkamppeter: the current three bugs in -proposed are easy to verify, so I'd like to finish that one first
<enrico> Riddell: he'll see your messages if you address him
<tkamppeter> pitti, OK.
<pitti> kees: so yes, technically it is no problem to do that
<kees> pitti: okay, great.  this gives me much more to work with as far as fleshing out that spec; thank you!
<pitti> kees: it's mostly an usability challenge, I think
<BenC> ogra: yeah, that's the plan
<kees> pitti: oh, how so?
<pitti> kees: getting description right, and so on
<tkamppeter> pitti, should I send you the patch to put together this next -proposed package of CUPS? I cannot put the patch into the BZR as there the Poppler-based pdftoraster is already removed.
<pitti> tkamppeter: feel free to commit it to the intrepid branch
<pitti> tkamppeter: lp:~ubuntu-core-dev/cups/intrepid
<kees> pitti: right, sure.
<tkamppeter> pitti, do I have write access there? And if not, can you activate write access for me?
<liw> kees, hmm, I think it might be a cool plugin for system-cleaner/Cruft Remover to have it suggest the optimal kernel, assuming that's possible
<pitti> tkamppeter: oh, you aren't core-dev any more, right
<tkamppeter> yes, they have made me only MOTU-and-a-half
<pitti> tkamppeter: just send me the patch then, probably easiest
<pitti> tkamppeter: I can change the owner, but only with breaking the existing Vcs-Bzr: headers in packages
<kees> liw: you mean to suggest removing -generic when -server was installed and running?
<kees> liw: I think that would be great.
<tkamppeter> pitti, you have mail
<liw> kees, yes, exactly that
 * liw makes a note
<kees> liw: I'll add it to the spec details too
 * ogra takes rss-glx from the armel list
<kees> pitti, liw: do you mind if I subscribe you to the PAE-kernel-selection spec?
<liw> kees, sure
<pitti> kees: please do
<kees> ogra: you interested too?  I've added "rename kernels" to the list of things the spec may include
<ogra> kees, interested sure, not sure i have so much time left for non mobile and non arm specs though
<ogra> but feeel free to subscribe me
<kees> ogra, liw, pitti: I've sub'd you all, but didn't mark you "required". please adjust however you want.  :)
<kirkland> pitti: Keybuk: hey, can i ask for a slot on the desktop UDS agenda, to discuss a couple of encrypted home directory graphical management utilities that we'd need?
<kirkland> pitti: Keybuk: i've got working prototypes of the entire underlying framework
<kirkland> pitti: Keybuk: but there's a lot of griping from people about wanting a pointy/clicky utility to manage their setup
<Keybuk> pitti: no, put them on the server track
<Keybuk> and ask for desktop people to attend
<Keybuk> err
<Keybuk> not pitti
<Keybuk> kirkland:
 * liw gets a mental image of a crossbow
<directhex> Ubuntu Sponsors for main team has been subscribed to this bug.
<directhex> okay then, the big mono 2.0 transition is ready to be kicked off. more or less.
<alex-weej> what package should i file bugs about guest session to?
<cody-somerville> guest-gdm-session or something like that
<alex-weej> asac: know anything about PPTP VPN connections failing? hasn't worked since at least intrepid released (it did work with pre-release NM 0.7 though)
<alex-weej> cody-somerville: thanks
 * ogra wonders where his yesterday given back rpm went 
<ogra> anyway
 * ogra goes out for dinner
<pitti> alex-weej: there's a current SRU for it
<tkamppeter> pitti, I have a problem with pstopdf: See bug 282186
<ubottu> Launchpad bug 282186 in cups "HP Photosmart 2610 top first cm not printed" [Undecided,Fix released] https://launchpad.net/bugs/282186
<alex-weej> pitti: which issue exactly?
<pitti> alex-weej: network-manager-pptp
<tkamppeter> pitti, the pstopdf filter converts PostScript to PDF using Ghostscript. On the Ghostscript command line paper size, resolution, and unprintable margins (all taken from the PPD) are supplied on the command line.
<alex-weej> pitti: there are at least 4 outstanding, independent issues i am having to workaround in order to connect
<tkamppeter> This is done to get the best of the file conversion, and also so that a CUPS test page contains the correct data.
<directhex> so. who feels like doing said kicking off. it's only 80 packages or so :)
 * directhex prods pitti 
<directhex> sooner the better with transitions, that's what i say
<tkamppeter> pitti, the problem is that  the PDF generated by Ghostscript has the margins clipped exactly at the borders defined in the PPD file. In general, one would think this is OK, as the PPD tells what are the unprintable margins of the printer, but in reality it is not the case.
<pitti> alex-weej: look at the topmost bit of https://edge.launchpad.net/ubuntu/+source/network-manager-pptp
<pitti> directhex: 80 packages what? syncs? can do; uploads? spread to several people please; "develop fixes"? no way :)
<pitti> tkamppeter: I saw the reply, but how was it handled in the past? some mystic implicit extra margin?
<directhex> pitti, https://bugs.launchpad.net/ubuntu/+source/mono/+bug/300133 plus recent messages to ubuntu-devel@
<ubottu> Launchpad bug 300133 in mono "Mono 2.0.1 package (triggers major packaging transition, please read in full)" [Undecided,New]
<tkamppeter> pitti, the current HP inkjets for example have unprintable margins of 9 points (around 3 mm) alll around if not in full-bleed mode. The PPDs suggest all an unprintable margine of 36 points (12.7 mm) at the bottom. This makes pstopdf clipping a lot.
<tkamppeter> pitti, formerly there was no filter which clipped borders. And the CUPS test page was rendered by the Ghostscript instance which ran the printer driver.
<tkamppeter> The two possibilities which I can do are:
<tkamppeter> 1. I do not feed the border info but only page size and resolution into Ghostscript. Then all normal jobs work correctly and I can also print full-bleed photos with flphoto.
<tkamppeter> But the CUPS test page does not show margin info (all zero) and not the black border.
<tkamppeter> 2. No change, which gives me a perfect CUPS test page but unwished margin widths on many normal jobs, especially no full-bleed with many photo managers.
<tkamppeter> pitti, my suggestion is 1. both for Jaunty and as SRU for Intrepid.
<kees> anyone know how to pin a command to a specific CPU?
<directhex> kees, tastset?
<directhex> task
<tkamppeter> In Jaunty the CUPS test page will go away with CUPS 1.4, there is a new test page concept.
<directhex> let's try that again: taskset
<tkamppeter> pitti, in Intrepid users happen to print the CUPS test page rarely, as with s-c-p on A4 and Letter Ubuntu tesy pages are used.
<directhex> unless that's in some sgi rpm... nope, util-linux
<pitti> tkamppeter: (phone, bbl)
<kees> directhex: perfect! thanks
<tedg> pitti: Have you packaged devkit?
<tkamppeter> pitti, simply answer after the call. I leave the window open, so it catches your answer also if I am not here.
<pitti> tkamppeter: hm, so is the issue that the margin info in the PPDs are plainly wrong, or that they only apply to some modes (and not in full-bleed)?
<pitti> tkamppeter: if they are wrong, fixing the PPD files seems most adequate?
<pitti> tkamppeter: other than that, I'm all for breaking the test page to fix real printouts :) (your solution 1.)
<pitti> tkamppeter: I mean, after all the printer will figure out the clipping on its own :)
<pitti> tkamppeter: the only other useful thing would be to make applications aware of the clipping borders, so that you avoid putting contents to these areas in gimp, OO.o, or whereever; do PPDs provide that?
<pitti> tkamppeter: if it's just some intermediate filters in the chain, then clipping there is fairly useless IMHO
<devinheitmueller> I'm a developer for the Kaffeine project, and was wondering if there is a documented process for getting an upstream Pull into Ubuntu?  We did a new release in July (0.8.7) and there was a launchpad ticket opened which never got responded to.  What is the best way to ensure that that the newest release gets into Jaunty?
<directhex> devinheitmueller, is kaffeine in ubuntu based on a debian package?
<devinheitmueller> hmmm... that's a reasonable question.  Let me look.
<tkamppeter> pitti, it is an intermediate filter, pstopdf. So I think I will let the filter not clip, also if then the CUPS test page is wrong. I will do the change in Debian CUPS BZR trunk. Please put it into the current CUPS SRU then. The fix is obvious and does not need a long testing preiod. I have tested it also with flphoto by myself.
<directhex> yes, it seems so
<devinheitmueller> Yes, I believe so:
<devinheitmueller> https://launchpad.net/ubuntu/+source/kaffeine
<devinheitmueller> It would be really useful to get this in, since digital television scanning doesn't work in North America without the new release.
<directhex> devinheitmueller, so: talk to the debian packager (who is likely to need to use Experimental, as debian is frozen) then request a sync/merge
<directhex> devinheitmueller, debian kde extras team. pkg-kde-extras@lists.alioth.debian.org
<cjwatson> (we can do it directly, but prefer to work via Debian if possible)
<devinheitmueller> Is there a definitive way to determine who the debian packager is (admittedly I'm not familiar with Ubuntu/debian's packaging processes)
<directhex> yes, we do! had a peek at my mono transition bug, cjwatson? someone's gonna have to take the plunge & start it off
<devinheitmueller> Ah, ok.
<cjwatson> directhex: I'm already literally doing something like five or six different things ...
<directhex> devinheitmueller, generally: http://packages.qa.debian.org/sourcepkgname
<directhex> poot.
<cjwatson> directhex: most of which are critpath for jaunty alpha 1 :(
<devinheitmueller> Hmm.... Looks like they're already at 0.8.7-1.
<directhex> cjwatson, well, alpha 1 is basic toolchain isn't it/ that takes priority
<devinheitmueller> http://packages.qa.debian.org/k/kaffeine.html
<directhex> devinheitmueller, really? in that case, request a sync with a sync bug. details of how are on the ubuntu wiki someplace
<devinheitmueller> Ok.
<cjwatson> directhex: shouldn't this go after alpha 1 anyway?
<devinheitmueller> In fact, it's been marked at "testing" since August 1st.
<cjwatson> don't request a sync with a sync bug
<directhex> devinheitmueller, it may need a merge (i.e. actual developer intervention) instead of syncing
<cjwatson> it's modified in Ubuntu - somebody needs to merge it, but we already have a queue for that
<cjwatson> i.e. it's on the list already
<cjwatson> (http://merges.ubuntu.com/universe.html)
<devinheitmueller> Pardon, are you saying Kaffeine is on the list already?
<cjwatson> yes, I am
<devinheitmueller> ok
<cjwatson> at the start of each cycle we merge everything from Debian
<cjwatson> we're partway through that process, but haven't finished yet
<cjwatson> kaffeine is still on the to-do list
<devinheitmueller> Now that I see how this is working, I'll see about merging whatever patches you have upstream for 0.8.8.
<devinheitmueller> directhex, cjwatson: thanks for your help!
<ScottK> devinheitmueller: apachelogger did the last uploader for it, so he's generally the one that would look at it.
<Riddell> devinheitmueller: hi
<devinheitmueller> Ah, I saw that name and thought perhaps it was an automated process.
<Riddell> devinheitmueller: I actually was doing the kaffine update today but there's a problem in kdelibs that stopped it compiling
<devinheitmueller> oh?
<directhex> devinheitmueller, that's good - it's always ideal to have some connection between up & downstream, WRT patches
<devinheitmueller> Yes, I definitely want to reduce the work required by the maintainers in terms of merging.  It's bad for everybody.
<Riddell> devinheitmueller: #kubuntu-devel is generally the place to ask about KDE related packages
<devinheitmueller> Riddell:  ah.  Thank you for pointing that out.  I'll switch over to the more appropriate channel.
<cjwatson> could somebody score up gnome-control-center on armel, please?
<directhex> NCommander, did i thank you for your armel mono fix?
<NCommander> YOu don't have to thank me.
 * NCommander kicks distcc
<RainCT> isn't "fix mono" something like introducing a bug?
 * RainCT hides behind a big stone :P
<directhex> NCommander, contributors need recognition!
<directhex> RainCT, rule 1 of irc: nobody can see your finger quotes or hear your sarcastic tone of voice. adjust smileys as appropriate ;)
<Treenaks> directhex: "finger quotes"
<directhex> Treenaks, if i used finger quotes when telling them shell commands to run, they'd give me a very funny look
<directhex> s/them/people/
<RainCT> directhex: add a  *sad look*  to my previouse sentence then ;P
<Treenaks> directhex: good point
<directhex> bah. i need more sleep. up until all hours last night writing some mails about some packages
<pitti> tkamppeter: current SRU is already uploaded
<pitti> tkamppeter: I agree, clipping makes no sense at all in an intermediate filter
<tkamppeter> pitti, as you have seen in the mail I have put the new pstopdf onto the BZR. It fixes for sure bug 282186 and perhaps also bug 293832.
<ubottu> Launchpad bug 282186 in cups "HP Photosmart 2610 top first cm not printed" [Undecided,Fix released] https://launchpad.net/bugs/282186
<ubottu> Launchpad bug 293832 in foomatic-db "printer prints page at wrong position, page cut" [High,Incomplete] https://launchpad.net/bugs/293832
<soren> siretart: As I said: 17:00:54 < soren> I don't see why wpasupplicant's failure to function properly at that time should make everyone else suffer?
<soren> siretart: The kernel discovers ethernet devices very early. It tells udev about this. Until you applied that patch, my interfaces were configured right then and there.
<soren> And all my kittens were still alive.
<soren> Now, nothing gets configured until S40networking is run.
<ogra> can a buildd admin please priorize apmd (its holing up gnome-applets)
<ogra> *holding
<NCommander> I just had a brilliant idea on how to accelerate boot times
<ogra> put the buildd boards on 380V ?
<ogra> oh
<ion_> -O999 -funroll-loops -fgentoo
 * ogra read s/boot/build/
<NCommander> ion_, not quite
<NCommander> OS designed have been playing around wit the idea of caching OS startup for years
<NCommander> (OS X has BootCache, and I think Windows has something similar)
<ScottK> NCommander: Since hibernate works so reliably we can just do that all the time?
<NCommander> Not quite
 * NCommander did have an idea about that but for another time
<NCommander> Well, w.r.t. to hibrenation, it might be worth investigating the point of having kernel execution cache its member state just before/after it executed init
<soren> siretart: Either ping me here if you want to discuss it, or I'll file a bug tomorrow at some point.
<persia> ScottK, Actually, yes.  The issue is getting hibernate to work that reliably.  Booting is usually not so helpful.
 * persia has a linux box that gets about 1000 power cycles per reboot
<soren> Resuming from hibernation often takes longer than booting for me.
<joaopinto> where there any recent updates (as in today) related to sound play ?
<ogra> soren, dont hibernate your servers :P
<jdong> soren: likewise, I only hibernate when I need to save my state
<jdong> the problem is the swap-thrashing right after resuming
<jdong> I find it actually better to hackishly swapoff -a; swapon -a after suspend in a suspend.d script
<soren> persia: I see the potential for using something *like* hibernation to boot faster, though.
<persia> soren, Well, depends on hardware, etc.  On that device, resume-from-hibernate is about 1.5 seconds, but it's a custom kernel to support "instant-on" type behaviour.  Boot takes about 4 minutes.
<persia> It's also ARM, which boards tend to have shorter resume-from-hibernate cycles anyway.
<ogra> yeah
<ogra> we just need to switch the world to arm
<ogra> that solves all power probs
<jdong> it probably would :)
<TheMuso_> ogra: heh it also solves x86 domination probs. :p
<persia> Well, no.  Nobody builds ARM supercomputers.
<ogra> TheMuso_, yeah, thats a sideeffect ... :)
<ogra> persia, but why ?
<ogra> you can get way more beagleboards in a 19" cabinet than blade servers :)
<persia> ogra, Power-consumption-optimisation rather than instruction-throughput-optimisation, I'd say.
<ogra> ah, well, mass compensates here ...
<lamont> what's it mean when seahorse(?) blats out: Warning: Tried to connect to session manager, Could not open network socket
<ogra> probably it didnt get a dbus connection ?
<ogra> is the session dbus running ?
<lamont> well, X died when kvm and xchat did battle
<lamont> ogra: how do I see if the session dbus is running?
<ogra> ah
<ogra>  ps ax|grep dbus|grep "session$"
<ogra> but it usually gets started via dbus-launch with the --exit-with-session option
<ogra> which means it dies with x-session-manager
<ogra> lamont, while you are here, could you bump gnome-control-center and ampd on armel ? building them will make ubuntu-desktop installable
<ogra> and they seem to sit with with a score of 0 in the queue ....
<Hobbsee> I'm starting to hate email.
<Hobbsee> or the MOTU community.  Either way.
 * Mithrandir ruffles Hobbsee 
 * NCommander gives Hobbsee a shotgun
<NCommander> lamont, is it hypothetically possible for a build admin to be able to do a binary upload into a PPA?
<NCommander> or, actually, to the buildd admins ^
<cprov> NCommander: not even in theory. What's the case ?
<NCommander> cprov, cross-compiler bootstrapping
<NCommander> cprov, I'm investiaging the possibility of packaging cross-compilers in the archive (with doko's blessing), or in a PPA (to stage)
<NCommander> But to build a cross-compiler, you need a glibc compiled to that architecture
<calc> i'm getting weird build errors (maybe hardware related) so i'm going to run memtest and other hardware tests, bbl
<NCommander> Essentially, you need cross-binutils, cross-gcc min, cross-glibc built, cross-gcc built again full, full glibc
<NCommander> Steps 2-4 would require a binary upload. Once all the packages are uploaded, its possible to rebuild itself
<calc> system can't even unpack a previously known good tarball (from ~ 1hr ago)
<TheMuso_> calscary.
<TheMuso_> gah missed him.
<NCommander> cprov, this would also allow us to work around cases where arch all packages require building on non-i386 platforms
<cprov> NCommander: it's very tricky, I can see.
<NCommander> i.e., QEMU BIOS
<doko> NCommander: better to just build-depend on the corresponding -source packages and build it; you can even reuse most of the packaging
<NCommander> YOu still have the issue problem of the first toolchain, I've never been able to get GCC to build properly without headers from glibc
<NCommander> doko, does glibc even support cross-compilation?
<NCommander> (the source package I mean)
<NCommander> I know binutils and gcc do
<doko> NCommander: have a look, but you can always build-depend on glibc-source. and better to apply all the patches we do in the native package
<NCommander> Hrm
<NCommander> It would probably be tricky to tweak the rules to get the toolchain to come out properly in a PPA without glibc binaries installed ...
<NCommander> But not impossible
<doko> hmm, I don't understand ...
<NCommander> GCC requires glibc's headers for the target platform to be compilable
<NCommander> (it cross-compiles libgcc to match the target)
 * NCommander looks up his cross-compiler notes to make sure I'm not talking smack
<NCommander> d'oh
<NCommander> I forgot you also need kernel headers
<NCommander> I knew something was missing
<NCommander> Oh
<NCommander> They fixed the gcc needs glibc in the 4.x series
 * NCommander is giving a hint the last time he built cross-compilers without cross-tool or equivelent
<NCommander> so in that case, it simply becomes cross-binutils, cross-gcc-core, cross-linux-headers, cross-glibc, cross-gcc-full
<lamont> NCommander: no
<lamont> one can upload source, buildds build, and launchpad uploads binaries to itself
<NCommander> I know that.
<lamont> (for the delayed response)
<NCommander> BUt I mean in the case of bootstrapping in a PPA, would it be possible for a build admin to do a binary upload
<doko> ogra: gcompris build failure on armel
<ogra> doko, yeah
<lamont> NCommander: that would be problematic, and not something I'd willingly touch
<ogra> doko, the tird time or so
<ogra> *third
<lamont> *turd
<ogra> waiting for gnome-games
<lamont> :-)
<NCommander> :-)
<ogra> oh, wait gnome-games should be there
<doko> ogra: no, please look first
 * ogra looks
<lamont> NCommander: and I'd certainly defer to cprov on the answer to that
<sebas> Hi
<sebas> Is anybody aware of an issue where i as a user can't connect to networkmanager and HAL
<sebas> Or at least, i'm getting permission problems when trying to use nm-applet or powermanagement stuff in HAL
<sebas> Happens since a few days, maybe a week or so
<sebas> I'm not quite grasping how this dbus / session / permission stuff works
<cprov> NCommander: the model doesn't allow that, maybe you could upload a source with the binary blod inside it.
<sebas> Or maybe someone has pointers to where I need to look if things are set up OK
<NCommander> cprov, yeah, that was plan B, which was evil, but doable
<cprov> NCommander: in LP binary needs a build the needs a source, we can't break this chain.
<NCommander> cprov, we could upload the source package, no issue
<cprov> s/cannot/don't want to
<NCommander> But someone would have to manually upload the first binary build of it
<cprov> NCommander: no, I meant a source that already contain the built binary
<NCommander> cprov, no, that I got too
 * NCommander was answering on breaking the chain
<doko> NCommander: please don't package the source again; use the available -source packages
 * NCommander nods
<NCommander> doko, what about for binutils/gcc, do we want the cross-compilers building out of a single source package, or two, one for the main toolchain, and one for the cross-compilers?
<directhex> what exaclty does the alpha 1 freeze freeze?
<doko> NCommander: no, no more cross compilers out of the same package. we do that for spu and hppa64 because we do need it for those platforms. but for nothing else.
<NCommander> doko, would you objection to say a gcc-cross source package to build cross-compilers (which would live in universe)?
<NCommander> (assuming we put them in the archive ...)
<doko> NCommander: yes, I do object, because a monster source building n cross compilers is just ugly
<ogra> urgh, grcompris grew by 20 MB since i touched it last two releaes ago
<ogra> *releases
<NCommander> doko, what if we create a binutils-source which is the source w/ all binutils attached, then individual cross-toolchain packages which depend on that, gcc-source, and glibc source, and then works to build the cross-compiler? No duplication of source, no super-massive package to self-destruct
<doko> NCommander: there is already a binutils-source package for this reason
<NCommander> Oh
<NCommander> I missed that it existed
<NCommander> Well
<NCommander> THat solves that :-)
<ogra> doko, is tehre a bug open about gcompris (for my changelog)
 * ogra doesnt get why that didt fail on any other arch
<ogra> *didnt
<doko> ogra: no
<ogra> good
<doko> NCommander: and you could just copy the packaging, and set the target in debian/rules. but don't apply the patches again
<NCommander> So then we need a binutils-*arch* package for each architecture we want a cross-compiler for ...
<NCommander> when you update binutils, then we need to do no-changes binary uploads to update the cross-compilers. That works out to 3*architectures we want to support (binutils/gcc/glibc)
<ogra> lamont, thanks for gnome-control-center
<ogra> can any buildd admin rescore apmd on armel ?
<Mithrandir> ogra: done
<ogra> gracias :)
<doko> done; why does lamont the thanks?
<ogra> Mithrandir, you win a flowerpot for making ubuntu-desktop installable on armel :)
<lamont> ogra: what did I do?
<ogra> doko, oh, you rescored g-c-c ?
<ogra> thanks to you then
<Mithrandir> ogra: hurrah
<ogra> :D
<directhex> who feels like kick-starting the mono 2.0 transition then? it's got a steaming hot armel-ftbfs-fixing patch in it!
<ogra> doko, did the cpp error checking change in any way since intreipd ? gcompris would never have built with the string handling code it has on jaunty
<ogra> i really wonder how it did on the other arches
<calc> still working on my system but found at least 1 bad memory stick :-\
<calc> so i probably won't get the replacement until after i leave for UDS :\
<calc> stuck with only 4GB of ram, heh
<directhex> "only"
<Mithrandir> you can't just walk to the closest shop and pick up a replacement?
<calc> directhex: well OOo uses all it can get :)
<Mithrandir> it's not like memory costs anything those days.
<calc> Mithrandir: well it is under warranty so i'd like to avoid buying more, heh
<directhex> i could be facetious and run "free" on my big box at work. can we take it as read that mine's bigger than yours? ;)
<calc> especially since my record on buying new memory isn't any better
#ubuntu-devel 2008-11-21
<calc> about 70% of the time i get memory its bad out of the box
<calc> directhex: most likely my system can only take up to 8GB iirc
<directhex> hm, UDS is at google? that's awesome
<calc> directhex: yea
<Mithrandir> calc: sounds like you are mishandling it.
<Mithrandir> or buying really crappy memory
<calc> Mithrandir: its from Fry's (US store notiorous for bad hardware)
<calc> Mithrandir: unfortunately they are the only real hardware store around the area
<directhex> i used to work at a pc retailer
<Mithrandir> I've heard of this thing called the internet where you can order stuff from other places than nearby stores.
<Mithrandir> you ever heard of that?
<directhex> boxed hard disks have a similar weight to a soccer ball
<Mithrandir> ;-P
<calc> generally if someone returns something they just stick it back on the shelf to sell again
<directhex> calc, yea, we did that
<calc> Mithrandir: yes but then "you can't just walk to the closest shop and pick up a replacement?
<directhex> with said football hard disks
<calc> that part doesn't work (bad copy/paste caused early return)
<ogra> you kicked them before putting them back ?
<Mithrandir> calc: internet is even closer than the closest shop
<calc> but yes i have fairly good results from buying from newegg in the US
<Mithrandir> *shrug*
<calc> Mithrandir: but takes several days for shipping unless you pay large amount of money for next day (in the US)
<calc> in the end not much faster than just RMAing the memory which is what i am going to do
 * calc thinks he'll go get food while waiting on the rest of his system to pass testing
<Caesar> Hi, it looks like there's a dependency issue between the mozilla and seamonkey packages in hardy-{updates,security}
<Caesar> Should I file a bug against both packages?
<kees> Caesar: yes, please.
<kees> Caesar: please mark it a security issue, and then flag it as public.
<Caesar> kees: okay
<Caesar> kees: https://bugs.launchpad.net/bugs/300519
<ubottu> Error: This bug is private
<Caesar> Drat
<Caesar> Now it's public
<kees> Caesar: cool, thanks!
<Caesar> np
<mneptok> Salve Caesar! Morituri te salutamus!
 * Caesar blinks
<mneptok> Caesar non Latine dictus?
<serge> am hitting https://bugs.launchpad.net/ubuntu/+bug/300162
<ubottu> Launchpad bug 300162 in ubuntu "bad security update (dup-of: 300247)" [Undecided,New]
<ubottu> Launchpad bug 300247 in hplip "apt-get upgrade (hplip...) fails on gutsy" [Undecided,Triaged]
<serge> sounds like a bad push
<serge> ok second bug answers my question
<Caesar> mneptok: no
<NCommander> kees, poke
<NCommander> kees, you can't have NX without PAE
<mneptok> NCommander: and if you want PIE you have to compile with --finished_dinner=YES
<NCommander> lol
 * mneptok is in the Clean Plate Club!
<Hobbsee> hahaa
* spm changed the topic of #ubuntu-devel to: LP down at ~0315UTC for ~ 30-60mins| Archive: frozen for jaunty alpha 1, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* spm changed the topic of #ubuntu-devel to: Archive: frozen for jaunty alpha 1, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<jsmidt> I have been looking at harvest and found a package called moodbar has a patch from fedora for it.
<jsmidt> How do I figure out what the patch does?
<jsmidt> Here: http://cvs.fedoraproject.org/viewvc/devel/moodbar/moodbar-0.1.2-glib.patch?view=markup
<jsmidt> I would like to learn to patch packages but am sure in the changelog you want to state why the package is being patched.
<jsmidt> Or do I just say something like: "patched with fedora patch"?
<hyperair> does anybody have time for a sru? Bug 263779
<ubottu> Launchpad bug 263779 in gnome-settings-daemon "Evince takes over global shortcut keys" [Undecided,In progress] https://launchpad.net/bugs/263779
<kees> NCommander: right, I know about NX needing PAE, but I encountered non-NX _with_ PAE.  finally tracked it to a bios setting. !!
<NCommander> o_O;
<NCommander> yay for crapply written bios
<kees> NCommander: yeah.  I'm deeply unpleased that a) it is even _controllable_ by the BIOS since the CPU feature downgrades gracefully for OSes that don't use it, and b) Dell ships with the feature disabled.  grrr
<NCommander> kees, VTx is the same way
<kees> NCommander: yeah.  I can _almost_ understand why that's in the BIOS, but not really.
<NCommander> Well, its because of PAE
<NCommander> PAE can screw up some old operating systems, but it should be disabled out of the box :-/
<NCommander> (i.e., the kernel must write the necessary control information for PAE to activate)
<dholbach> good morning
<RAOF> Any X heads here?  Why is the default RenderAccel method for radeon still XAA on all cards, but the driver will spit a warning to Xorg.0.log saying that they shouldn't be using XAA?
<wgrant> RAOF: Because it was causing instability, IIRC. It will probably be changed in Jaunty.
<superm1> slangasek, if you would like to reclaim some space on cdimages.ubuntu.com, you can remove the old mythbuntu/{daily,hardy,releases} directories.  we've got those images on mirrors now, so the only relevant one is daily-live/
<pitti> Good morning
<pitti> tkamppeter: the patch which you mailed me for bug 294671 isn't for cups; is it for gutenprint? where does the patch come from?
<ubottu> Launchpad bug 294671 in gutenprint "Driver reports "ColorSpace is not supported" for Canon iP4500" [Undecided,Fix released] https://launchpad.net/bugs/294671
<directhex> it's friday morning. a weekend of exciting possibilities awaits for developers new and old. so... who feels like kick-starting the mono packaging transition, and uploading my 2.0.1-0ubuntu1 package? pitti?
<NCommander> directhex, once mono is uploaded, I'll do the universe sponsorings
<superm1> directhex, i think 9.04 alpha 1 will probably need to get out the door first...
<directhex> NCommander, excellent. $DEITY-willing, coordinating efforts with pkg-mono will mean things can go into experimental and be synced as per usual, in many cases
<directhex> superm1, what exactly does alpha 1 aim to freeze?
<NCommander> directhex, you still need people to ack the sync
<NCommander> superm1, alpha freeze 1 is main only ATM
<directhex> NCommander, aye. just sayin' syncs are best. did you see my handy dandy transition tracking page?
<NCommander> xxNope
<directhex> http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO
<NCommander> Youch
<NCommander> Why didn't you use an LP bug to track the status as one big group?
<superm1> NCommander, yeah and last i checked mono itself was in main
<NCommander> directhex, get a mono freeze exception
<NCommander> (or wait for alpha 1 to pass)
<NCommander> hey mvo
<mvo> hey NCommander
<directhex> NCommander, how much of a wait? the idea of going with a 0ubuntu1 rather than waiting for -1 to finish debian NEW was to let people start on the transition ASAP
 * NCommander is checking the release schedule
<NCommander> ...
 * NCommander thinks it would help if I checked on wiki.ubuntu.com vs. wiki.debian.org
<NCommander> mvo, when do we leave alpha 1 freeze specifically?
<NCommander> directhex, we might be out of freeze now that I take a closer look, the schedule said November 20th
<NCommander> Its the 21st now
<directhex> it's not clear to me what the purpose of alpha 1 freeze is - given the lenny freeze in debian, it's not as if there's any value in the automatic sid importing, this time around. and last i checked the wiki didn' explain that freeze
<seb128> NCommander: don't use one bug listing lot of tasks to track transitions, that mailspam the subscribers to all the task including the ones which have been closed
<NCommander> fair enough
<NCommander> seb128, I see jaunty CD images
<NCommander> Does that mean we're out of freeze?
<seb128> the topic doesn't indicate so and I just woke up so dunno what happened during the night
<seb128> better to ask to slangasek
<NCommander> and the amd64 image is oversized
<NCommander> by less than a megabyte
<NCommander> \o/
<directhex> NCommander, well, the amd64 image shrinks by several meg once this transition is done!
<mvo> NCommander: normally when its released, I don't except it will be much later (but #ubuntu-release will know for sure)
<NCommander> mvo, would you do me a favor, and once we leave freeze sponsor directhex? (and my kde4libs upload (yes, its a recurring cycle of breakage, but I testbuilt on armel with the help of distcc :-))
<mvo> NCommander: sure
<NCommander> directhex, there you go, mono sponsor :-P
<directhex> hah. thanks to you both!
<pitti> directhex: sure, where is it?
<directhex> https://bugs.launchpad.net/ubuntu/+source/mono/+bug/300133
<ubottu> Ubuntu bug 300133 in mono "Mono 2.0.1 package (triggers major packaging transition, please read in full)" [Undecided,New]
<pitti> directhex: erm, hang on, has alpha-1 been released? if not, uploading it now would be bad
<NCommander> pitti, are we still frozen?
<NCommander> pitti, I see CD images
<pitti> see /topic
<seb128> pitti: see scrollback ;-)
 * NCommander is just wondering if the topic is lagging
<pitti> seb128: I didn't see anything which would indicate that the topic is wrong and a1 is released
<seb128> pitti: ok, we were just wondering if it was any likely that new images will be rolled
<seb128> freeze going over friday are no fun
 * NCommander can't figure out why we're freezing for alpha 1
<pitti> seb128: don't know, I wasn't tracking a1 at all this time
<seb128> ok, me neither
<directhex> what does alpha 1 achieve?
<pitti> NCommander: it's a soft freeze
<seb128> I guess we need to ping slangasek to know
<pitti> NCommander: we can upload stuff that doesn't break consistency
<NCommander> oh
<seb128> pitti: the mono transition is a transition
<NCommander> while kde4libs is simply lets unbreak armel :-)
<seb128> pitti: so it will break installability
<pitti> seb128: exactly
<NCommander> pitti, after the last armel FTBFS, I actually wired up a cross-compiler this time. 12 hours later, I have confirmed my fix works
<seb128> pitti: btw I didn't do syncs due to the freeze but I can do those after the freeze if you want
<pitti> seb128: I'll have a look at them, no problem to do universe ones, and trivial main ones
<pitti> but yes, an autosync run is too dangerous right now
<seb128> pitti: ok, just letting you know that I can do that if you are busy, I've nothing special to do today
<directhex> it would probably be really valuable to add a marker for main/universe to that transition page, wouldn' it
<NCommander> directhex, yes
<NCommander> doko, I have the debdiff uploaded to #299906 if you care to sponsor
<NCommander> er, Bug #299906
<ubottu> Launchpad bug 299906 in kde4libs "armel build failure (package not yet in the archive)" [High,Triaged] https://launchpad.net/bugs/299906
<NCommander> THere we go
<NCommander> directhex, for these transitions, what specifically needs to be done?
<NCommander> directhex, new upstreams, or just a rebuild bump?
<directhex> NCommander, best case: reduce build-deps a little, and add a configure flag/env var
<NCommander> This sounds this transition is going to suck
<NCommander> Speaking of sucky transitions, someone needs to look at ghc6
<directhex> haskelltastic!
<NCommander> s/ask//g
<NCommander> :-)
<directhex> http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition#head-67c13a005dab7f510b0fd1ee8db7a30689e89669 is a brief guide i wrote on how to transition a package. i should probably put the simple option before the complicated option
<directhex> truth be told, i did the complicated one due to lack of CDBS knowledge (i happened to pick a CDBS package for my example)
<NCommander> speaking of breakage, can one of the archive admins handle #298785
<seb128> bug  #298785
<ubottu> Launchpad bug 298785 in intrepid-backports "please backport lirc and mythbuntu-lirc-generator to Ubuntu intrepid" [Wishlist,In progress] https://launchpad.net/bugs/298785
<seb128> NCommander: any hurry that you need to ping on irc about it?
<stefanlsd> What should i do re: http://launchpadlibrarian.net/19829294/buildlog_ubuntu-jaunty-armel.wordnet_1%3A3.0-13_FAILEDTOBUILD.txt.gz
<seb128> NCommander: usually when people lag a bit on archive admin work that's because they are busy so there is no need to ping on irc, just wait a few days rather ;-)
<NCommander> seb128, can't I just call fork() and get my own archive admin :-)?
 * NCommander hears a gunshot
<seb128> NCommander: nice try ;-)
<NCommander> stefanlsd, is this package in main?
<seb128> NCommander: you don't have enough on your plates yet? ;-)
<NCommander> seb128, I'm determined for beta 1 that main is FTBFS free on powerpc and armel, with close to zero on the non-installability accounts
<NCommander> I just need to know where to place this in the queue
 * NCommander notes that KDE is currently the priority since GNOME built
<stefanlsd> NCommander: universe
<directhex> okay. i've still got to do libs, but:
<NCommander> stefanlsd, its sorta a case of patches welcome :-/. We're focusing on main ATM (KDE is a load of unhappiness). Is there a pressing reason to handle it now?
<directhex> mono stack, 4/9 packages in main
<stefanlsd> NCommander: nope, other than i would just like to learn about ftbfs and how to fix it. not pressing in terms of release at all
<directhex> cli apps, 5/42 packages in main
<NCommander> stefanlsd, for that build failure, you likely need to relibtoolize or autoreconf of the package (it likely will also FTBFS on amd64/i386 if you tried to build it there)
<stefanlsd> NCommander: do u know if there is any documenentation on doing that, or how we approach FTBFS in general?
<doko> NCommander: done
<NCommander> stefanlsd, In case of FTBFS, poke NCommander ;-)
 * NCommander runs
<stefanlsd> hehe. NCommander poke!  mm. but i think its great that your a FTBFS expert, but if you can get something up so we can get some more ncommander expert clones, that would be great (i wanna volunteer to learn about ftbfs)
<directhex> cli libs, 13/41 packages in main
 * hyperair wonders if anybody has time for a sru for gnome-settings-daemon
<hyperair> specifically Bug 263779
<directhex> so a total of 22 packages in main are affected by the mono transition, including mono itself
<ubottu> Launchpad bug 263779 in gnome-settings-daemon "Evince takes over global shortcut keys" [Undecided,In progress] https://launchpad.net/bugs/263779
<NCommander> stefanlsd, I'm one of the few people from Debian who is a porter more than a packager. I'm used to handling FTBFS :_)
<cjwatson> directhex: I'd really appreciate you waiting with mono; it won't take much longer
<cjwatson> could somebody please score up hw-detect and udev on the architectures where it has not yet been built?
<seb128> hyperair: not sure if that's really worth a sru, that seems a corner case, usually people use multimedia keys for such actions, anyway subscribe the sponsor team so it's on the sponsoring list
<cjwatson> NCommander: you don't see CD images in cdimage.u.c/releases/jaunty/. Dailies aren't releases
<NCommander> oh
<hyperair> seb128: usually people use multimedia player keys to control their media players, not a pdf reader =p
<cjwatson> I suppose it's just hppa/ia64/sparc, I'll upload debian-installer without waiting for those
<seb128> hyperair: right, which means you don't have a conflict between applications
<seb128> hyperair: or the bug description is not clear
<hyperair> seb128: no the issue is that evince is hijacking the multimedia keys from media players
<seb128> hyperair: so the description is not clear and I suggest you update it
<hyperair> what should i change it to?
<directhex> cjwatson, on the bright side, with the new build-deps, we don't anticipate needing another packaging transition any time in the next few years (i.e. not until MS release a new version of the CLR spec which isn't built on top of a previous version, which last happened in 2006, AND mono becomes compatible enough with that new release to warrant making it the default CLR version to use). so at least 5 years away
<seb128> hyperair: right now it says to use ctrl-alt-letter to get the issue, which I doubt many users do
<seb128> hyperair: change to a common usecase, ie: use a multimedia key, start evince, verify the multimedia key stop working
<cjwatson> directhex: that'll be great
<cjwatson> directhex: though not something I'm worried about right now, I'm focused on getting CDs working
<pitti> zul: ping question in bug 228693
<ubottu> Launchpad bug 228693 in bacula "[SRU] bacula-director-pgsql postinstall broken" [Medium,Fix released] https://launchpad.net/bugs/228693
<cjwatson> ok, cancel my hw-detect/udev request, but could somebody please score up debian-installer?
<tkamppeter> pitti, the patch is for the pdftoraster filter which is in debian/local/filters/pdf-filters/filter/ (Intrepid only).
<pitti> cjwatson: you mean retry?
<hyperair> seb128: i've just modified it. is the new description okay?
<pitti> cjwatson: oh, nevermind, buildd.py used the previous version for some reason
<pitti> indeed, the version shown on https://edge.launchpad.net/ubuntu/+source/debian-installer is out of date
<NCommander> doko, are you working on kdelibs?
<doko> NCommander: no
 * NCommander is starting to at the moment, but since the last upload is still broken on armel
<NCommander> ok
<wgrant> pitti: Because it's not published.
<pitti> cjwatson: done (don't count on ports, though, they are horribly clogged)
<pitti> building qt4 and OO.o
<NCommander> and kde4libs
<NCommander> wooo
<pitti> and sparc is down to one buildd, which is OO.o'ed
<pitti> cjwatson: i386 shoudl be ok, if amd64 is urgent, we need to prod the buildd gurus to forcefully kill kde4libs or openjdk
<NCommander> pitti, kde4libs will only take one hour, 17 minutes to build give or take five
<NCommander> since it started 26 minutes ago ...
<seb128> hyperair: the description is better indeed, does it mean that the keys will not work in evince if rhythmbox is running though?
<pitti> tkamppeter: but rasterdsp.cc doesn't even exist in cups
<hyperair> seb128: yes that's right, but that's intended behaviour.
<hyperair> seb128: when rhythmbox is closed, the keys wll work in evince
<seb128> hyperair: I would expect the intended behaviour to be that whatever application having the focus should respond
<seb128> and not evince working or not depending of whether some other software is running somewhere
<hyperair> seb128: well, these are global shortcuts. you don't see shortcuts defined in sys/pref/keyboard shortcuts reacting to focused apps
<cjwatson> pitti: I guess I'll just wait for kde4libs
<cjwatson> NCommander: see, this is how porting can end up blocking alpha releases
<hyperair> seb128: let's say i define ctrl+alt+c to start the calculator, and some other application has some menu item which reacts to ctrl+alt+c. if i focus that application and press ctrl+alt+c would you expect a calculator to pop up, or the menu item to trigger?
<seb128> hyperair: not sure that the behaviour is ideal but the patch makes sense over what is happening now, just subscribe the sponsor team, I'll try to have a look to sponsoring today
<seb128> hyperair: the menu item to be selected
<seb128> but that's a different question than the sru change one
<hyperair> alright
<tkamppeter> pitti, remove the rasterdsp.cc part, only take the part acting on pdftoraster.cc and apply it to pdftoraster.cxx (edit the patch appropriately).
<seb128> let's get the obvious issue fixed first and then that can be discussed upstream later if required
<pitti> tkamppeter: okay; where does this patch come from?
<hyperair> seb128: alright. i've subscribed ubuntu-sru and ubuntu-main-sponsors
<seb128> hyperair: thank you
<hyperair> np
<tkamppeter> pitti, the patch is based on the upstream distribution of the pdftoraster filter. For the use with CUPS I did not put the full upstream distribution into the CUPS package but only the source file of the filter itself and I patched the build system of CUPS to get the filter compiled.
<pitti> tkamppeter: right, I'm interested in getting a websvn link or something, for putting into the patch as an upstream reference
<MacSlow> what's the name of xfce's window-manager?
<MacSlow> found it, never mind
<pitti> tkamppeter: oh, ignore me, I didn't upload the cups SRU yet, so I can include this one
<tkamppeter> pitti, here is the patch on the upstream web SVN: http://svn.sourceforge.jp/view/pdftoraster/trunk/src/pdftoraster.cc?root=opfc&rev=850&r1=848&r2=850
<rlj> hi all, i experienced LP#291878 and wrote a trivial patch to the kernel to add a keyboard quirk for the affected laptop model. the patch works the way it's supposed to on my laptop and solves the issue, but so far no one else affected by the bug has responded to my patch. what's the proper way to get it included into the ubuntu kernel and also getting it upstream?
<dholbach> rlj: try taslking to the folks in #ubuntu-kernel
<rlj> thanks
<tkamppeter> pitti, then you can SRU the following now: cpdftocps (bug 299707), pstopdf (bug 282186, and perhaps also bug 293832), pdftoraster (bug 294671 and duplicates).
<ubottu> Launchpad bug 299707 in cups "Impossible to print in reverse order" [Undecided,In progress] https://launchpad.net/bugs/299707
<ubottu> Launchpad bug 282186 in hplip "HP Photosmart 2610 top first cm not printed" [High,Confirmed] https://launchpad.net/bugs/282186
<ubottu> Launchpad bug 293832 in foomatic-db "printer prints page at wrong position, page cut" [High,Incomplete] https://launchpad.net/bugs/293832
<ubottu> Launchpad bug 294671 in cups "Driver reports "ColorSpace is not supported" for Canon iP4500" [Undecided,Fix released] https://launchpad.net/bugs/294671
<tkamppeter> pitti, note that it is not confirmed whether the current pstopdf fixes bug 293832, we must ask the poster to try the -proposed package once you have uploaded it).
<ubottu> Launchpad bug 293832 in foomatic-db "printer prints page at wrong position, page cut" [High,Incomplete] https://launchpad.net/bugs/293832
<pitti> tkamppeter: okay
<pitti> tkamppeter: so your latest trunk commit fixes bug 282186?
<ubottu> Launchpad bug 282186 in hplip "HP Photosmart 2610 top first cm not printed" [High,Confirmed] https://launchpad.net/bugs/282186
<pitti> tkamppeter: if so, please set the jaunty task to "fix committed" and commit the LP # to the changelog
<tkamppeter> pitti, yes.
<pitti> tkamppeter: please tell me when you committed/pushed, then I can merge this into the intrepid branch
<doko> pitti: please could you process liblink-grammar4 binaries in NEW? makes abiword installable on armel
<pitti> seb128: ^ can you please?
<seb128> pitti: looking
<seb128> doko: could you start using requestsync to file sync requests?
<seb128> doko: your bugs are the only one we need to open to know if the package is in main or universe, that's extra work for no good reason
<tkamppeter> pitti, bug number committed/pushed, bug set to "Fix Committed".
<seb128> doko: requestsync set nice title which have those informations and make the work easier for everybody
<pitti> tkamppeter: thanks
<seb128> doko: does liblink-grammar4-java need to go to main or universe?
<doko> seb128: "makes abiword installable on armel", so I assume that should be main
<seb128> doko: liblink-grammar4 is also new on armel so I was wondering if that's only that one or also the java binary
<seb128> doko: I don't think abiword uses java
<doko> seb128: well, usually we add language bindings into main if they are built from the same source and the language is in main
<doko> so yes, it should go to main
<seb128> doko: not really, they are listed on component-mismatch if you do that, they either need to have a depends or be seeded
 * directhex hands seb128 cake, udpates his transition wiki
<seb128> directhex: ;-)
<cjwatson> well, you're both right, (a) they're usually added (b) they need to be seeded
<seb128> doko: newed
<doko> seb128: we seed after we have the mismatch, not if the package is in NEW
<cjwatson> *-gcj is included automatically but *-java isn't
<seb128> doko: right, just pointing that you need to have a depends or seed it
<cjwatson> doko: there's nothing wrong with seeding when it's in NEW, actually
<cjwatson> and it's often handy
<pitti> tkamppeter: fix-the-world-cups uploaded to intrepid-proposed
<tkamppeter> pitti, great, thanks. Now the PDF filter chain should really work perfectly.
<tkamppeter> pitt, at least on Intel, on PowerPC there is bug 271350 (already reported to upstream).
<ubottu> Launchpad bug 271350 in cups "pdftopdf filter on PowerPC corrupts data" [Medium,Triaged] https://launchpad.net/bugs/271350
<tkamppeter> pitti, have you put a comment into all bugs which I mentioned so that the posters know how to activate -proposed to get the new package and to try it?
<pitti> tkamppeter: yes, including #293832 (the needinfo one)
<pitti> tkamppeter: argh http://launchpadlibrarian.net/19831839/buildlog_ubuntu-intrepid-i386.cups_1.3.9-2ubuntu2_FAILEDTOBUILD.txt.gz
<pitti> tkamppeter: a local build worked fine, because I had libcupsimage-dev installed; this probably needs an -I option to the local cups/image.h
<pitti> tkamppeter: ok, fixed
<zul> pitti: yeah that got slipped with things ill do that today
<speakman> hi! avahi seems to be disfunctional in Intrepid
<speakman> can't see any other services in the local network after reinstalling Intrepid.
<zul> pitti: bacula fixed and uploaded
<doko> cjwatson: http://launchpadlibrarian.net/19834786/buildlog_ubuntu-jaunty-armel.debian-installer_20081029ubuntu2_FAILEDTOBUILD.txt.gz
<doko> beep is in the archive, so why not beep.udeb?
<cjwatson> doko: NCommander already prepared a MIR for this
<cjwatson> https://wiki.ubuntu.com/MainInclusionReportBeep
<doko> ahh, ok
<cjwatson> doko: there are a couple of others, you should join #ubuntu-arm :)
<cjwatson> devio-udeb and oldsys-preseed
<doko> cjwatson: I thought we wanted to have this in #ubuntu-devel ... at least I did write this in my email
<cjwatson> I don't think there are MIRs for devio-udeb and oldsys-preseed yet
<cjwatson> I don't think we need a separate mailing list; IRC channel meh *shrug*
<persia> Mind you, over time, the IRC channel probably ends up being less dev and more support, and so people will want to retreat here, but for now it's mostly dev stuff.
<slangasek> superm1: well, we wouldn't remove images that are still part of an official release from cdimages.u.c, so mythbuntu/releases is staying :)
<doko> cjwatson, pitti, please promote https://bugs.edge.launchpad.net/ubuntu/+source/beep/+bug/300442
<ubottu> Ubuntu bug 300442 in beep "Main Inclusion for Beep" [High,In progress]
<slangasek> superm1: but I've nuked mythbuntu/daily at least, yes - thanks for the nudge
<cjwatson> doko: done, as I say will need the other two before it's worth giving back d-i though
<doko> ok
<doko> cjwatson: see #300676 and #300678
<soren> kirkland: Sorry, I think I missed it... Why were we putting it into /var ? Something about configuration data?
<kirkland> soren: here's the key ....
<kirkland> soren: $HOME/.ecryptfs/wrapped-passphrase contains your mount passphrase, symmetrically encrypted with your login passphrase
<kirkland> soren: it is unencrypted in userspace by pam on login
<kirkland> soren: and then the mount passphrase is used to mount all of $HOME
<kirkland> soren: okay ....  now ....
<soren> Oh, ecryptfs is not the data directory?
<soren> Sorry, I mean .ecryptfs.
<kirkland> soren: right the mount is this:
<soren> Ok, sorry :) Go on.
<kirkland> soren: mount -t ecryptfs -o lots_of_foo $HOME/.Private $HOME
<soren> Oooh..
<kirkland> soren: persia: okay, this is where the unionfs or bind mount might work ....
<soren> Ok.
<kirkland> soren: because i need .ecryptfs to (again) be available in $HOME, for password changing, unmounting, etc.
<soren> Got it.
<soren> I thought .ecryptfs was the data directory..
<kirkland> soren: but, i need to *absolutely* make sure that anything edited within there doesn't get written to the disk through the kernel ecryptfs crypto
<soren> here's a thought:
<kirkland> soren: no, just config
<persia> kirkland, I think a bind mount would be better.  aufs does layering in a way that's causing me enough confusion I'm not getting you a mount line.
<kirkland> the data dir is /home/$USER/.Private
<soren> Before doing the ecryptfs mount, how about bind mounting the ecryptfs directory to somewhere else.
<soren> ?
<cjwatson> you'd end up with a *lot* of mounts with multiple users logged in, is the only thing
<kirkland> soren: please suggest a mountpoint you find suitable?
<soren> cjwatson: Good point.
<cjwatson> one per user is reasonable, more than that I start to find uncomfortable
<soren> kirkland: I'm not sure.
<persia> I'm getting more and more excited about the idea of a setuid binary in ecryptfs-tools to manage /var/lib/ecryptfs/$USER
<persia> Only problem there is namespace: limits to one encrypted mount per user.
<soren> kirkland: Let me just say: My primary reservation against /var/lib/ecryptfs/$USER was that I thought you were dumping lots and lots of data there... Since it's just configuration, I'm less opposed (but still a bit) to it :)
<Mithrandir> make it /var/lib/ecryptfs/$USER/$mountname, then?
<soren> Do ecryptfs's have uuid's?
 * soren takes a quick break
<persia> Mithrandir, That sounds sensible.
<kirkland> soren: purely configuration
<kirkland> soren: purely $USER configuration, and i though /var/lib was less evil than /etc
<speakman> hi again folks!
<speakman> I've just resolved my avahi issue!
<speakman> The latest ubuntu kernel seems to have problems with the ATL1E driver
<speakman> after applying this patch it all works great: http://kerneltrap.org/mailarchive/linux-netdev/2008/11/11/4060524
<kirkland> persia: a setuid binary to create that dir -- i like that
<speakman> When can I report this to kernel maintainer?
<speakman> where
 * persia credits cjwatson for the suggestion : what you see here is an IRC echo
<kirkland> persia: i don't think it necessarily limits the mounts, as we could teach ecryptfs to deal with the data in the user's /var/lib/ecryptfs/$USER dir directly
<persia> kirkland, As pointed out above, /var/lib/ecryptfs/$USER/$mountname makes it moot.
<kirkland> persia: thx, i hadn't bounce back to the other channel
<james_w> speakman: try #ubuntu-kernel
<kirkland> soren: cjwatson: persia: there is one other option, but it involves kernel changes ....
<kirkland> ecryptfs supports a mount option, ecryptfs_passthrough, which allows for an unencrypted file in the lower filesystem
<kirkland> you can read and write the file in the ecryptfs mount, and it remains unencrypted
<persia> That sounds nice and clean to me.  No fussing about with stuff.
<kirkland> however, that feature doesn't yet work recursively on a directory
<persia> oh :(
<kirkland> ie, new files created in a passthrough dir are encrypted
<kirkland> that could be changed
<kirkland> and the kernel maintainer agreed that it would be doable, and a good feature
<kirkland> but i'm not sure how long that would take
<persia> kirkland, Now, how would this work for bind-mounting /home out of a chroot (e.g. a default schroot setup)?
<persia> Would I have to enter my password 8 times for an sbuild run like I do for pam_mount?
<kirkland> persia: no
<kirkland> persia: see keyctl
<kirkland> persia: keyctl show
<kirkland> persia: the key will be loaded into your kernel keyring
<kirkland> persia: if i'm understanding your question correctly
<persia> Cool.
<kirkland> persia: fwiw, i can debuild in an ecryptfs home no problem
<kirkland> which uses something similar, i think
<persia> No.  Not at all.
<kirkland> sbuild, then
<persia> debuild uses the host system binaries.  Very dangerous way to test-build if there's any chance you have stray development libraries around and an agressive ./configure.
<persia> Yeah, by default sbuild uses schroot.
<Mithrandir> I want to have a pam_time which would work somewhat like pam_stack and skip modules if not too long had passed, so I can do stuff like "the screensaver should be able to unlock using my finger if it has been locked for less than 15 minutes".
<persia> Mithrandir, That's a nifty idea.  Interesting applications with pam_blue as well.
<Mithrandir> persia: yup.
<directhex> UTSL!
<directhex> (note: pam modules are icky black magic)
<Keybuk> err
<Keybuk> wtf
<Keybuk> why does the default apt sources list include the banshee and bzr PPAs ?
<pitti> o_O
<cjwatson> it doesn't ...
<cjwatson> if I added random PPAs, I wouldn't have added banshee :)
<Keybuk> cjwatson: mine has
<Keybuk> I reinstalled today
<cjwatson> with what installation image?
<pitti> jaunty daily?
<Keybuk> an intrepid desktop CD
<Keybuk> for some reason, they point at hardy though ?!?!
<cjwatson> <cjwatson@riva /mirror/ubuntu/pool/main/u/ubiquity/ubiquity-1.10.10>$ grep -r banshee .
<cjwatson> <cjwatson@riva /mirror/ubuntu/pool/main/u/ubiquity/ubiquity-1.10.10>$
<cjwatson> are you sure you booted into the new installation, and not a previous one?
<Keybuk> totally
<Keybuk> I wiped the entire disk
<seb128> that's very weird
<pitti> Keybuk: APRI... wait, wrong month
<pitti> Keybuk: I did probably a dozen intrepid test installs and I always check sources.list
<ScottK> doko: Are you planning on including Python 2.6 in Jaunty?
<doko> ScottK: sure, but unlikely before uds
<Keybuk> cjwatson: is there *any* code that touches source.list?
<Keybuk> uhhhh
<Keybuk> never mind
 * Keybuk is an idiot
<seb128> Keybuk: what did you do to get that? ;-)
<seb128> you were sshing to an another box? ;-)
 * Keybuk hides with embarassment
 * cjwatson points and laughs
<cjwatson> admittedly in some relief :)
<Keybuk> clearly I need a holiday
<ScottK> doko: No rush (actually if you have some python time I think it'd be worthwhile to update the Python 3.0 package in Intrepid), but I was starting to think about 2.6 transition.
<directhex> transitions? nah, only crazy people do those
<ScottK> directhex: Python actually has a pretty well thought out scheme for the process.
<directhex> oh?
<ScottK> The Python packaging policy makes it so we can support multiple Python versions at the same time.  That way you don't have to try and do an instant transition.
<ScottK> So we can get 2.6 into Jaunty and work on making stuff work with it and then when ~stuff works, make it the default.
<directhex> so this is a version transition, not a packaging transition, really. other than changing #! in apps as & when they don't die horribly
<ScottK> directhex: It's more complex than that in that Python packages should point to #!/usr/bin/python and work with Python versions they claim to work with.
<ScottK> It's probably more like a library transition.
<Mithrandir> persia: oh, and it should be configurable by the user, which is harder.
<Haegin> hi, where can i find a list of the options for preseed files along with the values they take?
<cjwatson> Haegin: the installation-guide is the best source; it's linked from help.ubuntu.com
<Haegin> cjwatson: thanks
<cjwatson> Haegin: it doesn't document absolutely everything, but the things it doesn't document are generally not very interesting, and if there are relevant omissions from it then we'd appreciate a bug to get them fixed
<Haegin> cjwatson: i have ddns working now but it is still asking for mirror information, do you know where i can find the valid list of countries?
<cjwatson> Haegin: install the iso-codes package; first column of /usr/share/iso-codes/iso_3166.tab
<Haegin> danke
<directhex> syntax may or may not change in subtle ways between d-i versionm
<Haegin> well selecting the country is working but the mirror hostname is still prompting me now
<cjwatson> mirror/http/hostname?
<Haegin> yup, d-i mirror/http/hostname string ie.archive.ubuntu.com
<cjwatson> Haegin: can investigate if you give me your full preseed file (with passwords stripped), and also the failing /var/log/syslog from the installer; I'm on the phone for the next few hours though
<Haegin> cjwatson: thanks, it is also giving me kernel not found errors when i get past the mirror selection so i will go try fixing that first
<hwilde> hey everybody.   I love ubuntu  :)
<hwilde> thought you could use some kudos
<directhex> hwilde, payment is: show people how cool it is and get THEM to use it.
<directhex> s' very expensive
<dholbach> Keybuk: what do you think about the patch in bug 256429?
<ubottu> Launchpad bug 256429 in hal "Intrepid regression: carriage-return required after finger scan" [Unknown,Confirmed] https://launchpad.net/bugs/256429
<Haegin> is it possible to preseed and automate a oem install?
<ogra> dholbach, the reporter himself says its a hack
<ogra> well, s/reporter/patch writer/
<NCommander> ogra, kde4libs built!
<ogra> yay !
<ogra> NCommander, erm, only on i386 yet
<ogra> (and lpia)
<NCommander> ogra, its simply stripping debs on arm, it finished :-P
<ogra> ah, cool
<murdok> Hello kees , are you available? :)
<kees> hiya murdok, what's up?
<murdok> it's about bug 216398 . do you remember it?
<ubottu> Launchpad bug 216398 in dosemu "default mmap_min_addr breaks dosemu" [Undecided,Confirmed] https://launchpad.net/bugs/216398
<murdok> Malte has said it's better name the file in sysctl.d 30-* than 90-*
<murdok> In jaunty you commited the 90-* version
<murdok> I don't know what to do. It's becoming an oddysee with something so little, xP
<murdok> 30-* also sounds logical
<NCommander> doko, is it a bad sign that kde4libs is still running dpkg-shlibdeps o_O?
<hwilde> directhex, oh we are forcing people to use it.  no windows support here anymore
<pitti> bryce: would you be up for the inkscape merge?
<jcole> whats the correct way to associate an application to a particular mime type?
<jcole> for example
<jcole> echo "audio/midi=timidity-interfaces-extra.desktop" >> /etc/gnome/defaults.list
<jcole> from the command line
<jcole> and to make it "system wide"
<jcole> isnt there a debian way to do it?
 * jcole notices the /usr/lib/mime/packages directory
<jcole> should i be putting a file in there?
<directhex> hm. still alpha1 frozen?
<cjwatson> not for too much longer
<cjwatson> I was on the phone for 4.5 hours there, sorry about the delay
<cjwatson> just doing a quick LVM install test
<calc> cjwatson: that sounds painful for your ear :)
<cjwatson> yes
<superm1> cjwatson, the ubiquity that's currently in the archive doesn't indicate it's an alpha for live disks..
<cjwatson> superm1: ubiquity is broken anyway
<superm1> cjwatson, in what sense?
<cjwatson> superm1: a1 will be alternate/server only
<cjwatson> superm1: in the sense that it has not been updated to the current underlying installer code which makes an alpha release with it a little bit pointless
<cjwatson> superm1: and if it were, evand says that the partitioner breaks
<cjwatson> so -> a2
<superm1> cjwatson, ah okay
 * calc will be uploading new OOo 3 for jaunty (in the ppa) in a couple hours for anyone who wants to play with it
<calc> it was delayed a bit due to bad hardware
 * ScottK pictures calc shaking his finger and saying, "Bad hardware, Bad hardware! Don't you EVER do that again."
<calc> ScottK: single bit error in 48Gbit :\
<ScottK> Lovely.
<directhex> calc, is what you work on what ends up in the archive fo' realz?
<calc> directhex: well it is rebuilt on the buildds, but yea more or less
<calc> directhex: its preferrable that bit errors don't corrupt my sources in any case
<directhex> calc, you've noticed my warning about the mono 2.0 transition, yes? it applies to you
<calc> directhex: i saw something about it yes, need to read it again :)
<bryce> pitti, I'd like to do that, yes.  This week I've been swamped with OEM team stuff.
<bryce> looking forward to getting back to distro work, I've got a bit of a backlog
<doko> cjwatson, Riddell: kde4bindings binaries in NEW. please accept
<doko> and now afk ...
<NCommander> Could a buildd admin please rescore kdebase-workspace on armel
<directhex> KDE on ARM... how does that even run? I can't imagine the smoothest user experience
<cody-somerville> NCommander, be king, provide a link to the build
<cody-somerville> *kind
<NCommander> actually, kdebase-workspace is still dep-wait
<NCommander> https://edge.launchpad.net/ubuntu/+source/kdepimlibs/4:4.1.73-0ubuntu1/+build/787507 - kdepimlibs however still needs build
<NCommander> (which is the new dep-wait)
<hyperair> bug 263779 - sru anyone?
<ubottu> Launchpad bug 263779 in gnome-settings-daemon "Evince hijacks global multimedia keys" [Undecided,In progress] https://launchpad.net/bugs/263779
<cjwatson> jaunty alpha 1 needs a respin, please hold off on uploads for a little longer
<directhex> how could you tell i just checked /topic ?
<NCommander> mrooney, ping
<mrooney> NCommander: hello
<NCommander> mrooney, its amazing to know there is another Ubuntu dev from RIT :-)
<mrooney> NCommander: oh, you are from RIT, no way!
<mrooney> what major/class?
<NCommander> Criminal Justice/3rd year
<directhex> RIT? republic of intoxicated turbots?
 * NCommander beats directhex with a brick
<NCommander> mrooney, actually, one of the members of the Ubuntu Technical Board was an RIT student, and a CSH allumi
<ScottK> NCommander: Just beat him with some Microsoft submarine patents.
<sebner> lol
<NCommander> ScottK, but RIT has so many bricks
 * NCommander should build a brick cannon
<sebner> ScottK: I'm curious. Were your questions for the MC or for you?
<ScottK> Bricks are so 20th century.
<ScottK> sebner: For the entire MOTU community.
<NCommander> mrooney, you still in Rochester, or have you fled the winter wastelands :-)
<directhex> submarine patents? you mean... they helped the nazis with u-boats? boycottnovell was right!
<ScottK> sebner: If I'd concluded from your answers you weren't qualified, I'd have said so.
<sebner> ScottK: I thought so because I was wondering why you didn't add a +1 or -1 in th end  ^  ^
<sebner> ScottK: ah, thx for the honour then
<ScottK> sebner: Because I didn't sponsor you, I don't feel I have the breadth of information to say plus one.
<mrooney> NCommander: Well this quarter as my last academic, though I still need two more co-ops
<mrooney> but I am in Rochester for awhile unless I find a job elsewhere
<NCommander> ah, major?
 * mrooney is crossing his fingers for a Canonical position :)
<mrooney> CS
<sebner> ScottK: I've seen many +1 in other applications for "Community integration" :P
<NCommander> mrooney, heh, I washed out of the CS major
<sebner> mrooney: counterstrike?
<NCommander> I perfer criminal justice actually
<directhex> according to some unnamed websites, i'm apparently crossing my fingers for a novell position. that's what ubuntu packaging earns you these days o_o
<NCommander> directhex, the Novell guys heard I know about ARM. Appartantly thats what being a porter does for me
<cjwatson> directhex: meh, you aren't a proper free software developer until you've had a whole slashdot story dedicated to flaming you personally ;-)
<NCommander> cjwatson, so if I go back into the /. archives, I can find your roast?
<cjwatson> if you look really hard, probably
<directhex> cjwatson, two boycottnovell stories, TYVM
<cjwatson> heh
<directhex> in one i'm ignorant and/or stupid. in the other i'm... a graphics api, i think
<mrooney> sebner: haha nope
<sebner> mrooney: cybers*x?
 * NCommander just found the bug on slashdot with 5.10 and readable root passwords
<cjwatson> not that one
<cjwatson> though, hey, two stories. bonus.
<NCommander> I just realized Mark's initals are MS
<directhex> cjwatson, i reckon i know someone who can beat your record into dust
<NCommander> O_o;
<cjwatson> directhex: oh, I'm sure you do :)
<directhex> cjwatson, calls himself "miguel_" on irc...
<cjwatson> yes :)
<NCommander> roflk
<NCommander> directhex, I think the worst beating miguel ever took is when he defined Microsoft's OoXML
<directhex> NCommander, ooxml is a ~99% complete spec. it's not a very good one (really, it's completely braindead for word processing), but it's well defined, other than some remnants for exact formatting of converted 13-year-old documents
 * NCommander watches the flamewar about to descend on directhex 
<ScottK> directhex: Any spec that includes in it's definition "do what program X does in this situation" isn't a spec.
<NCommander> ScottK, thank you.
<ScottK> That said, I certainly don't object is some FOSS project wants to try and implement it.
<ScottK> is/if
<directhex> ScottK, oh, agreed. but, frankly, i don't think MS could even tell you what that tag does in real terms
<directhex> there are no specs available for word 95. 97->, you can download something resembling a spec, but 95- i think they've actually lost it
<NCommander> directhex, 95 was a hell of a lot of binary structs
<directhex> because, let's be frank, it's such an idiptic thing to have in the ooxml spec, there's no way they'd put it there if they could, well, not
<ScottK> Sure.  So let's not call it what it isn't.
<NCommander> (same with 97)
<NCommander> There really isn't much of a spec behind it
<NCommander> That's why even Mobile Office and Office for Macintosh choke on word documents
<NCommander> And there was never a native version of Office for Alpha
<directhex> intrepid has ooxml support
<directhex> certainly reading
<NCommander> WTF can WRITE ooxml files?
<NCommander> (DocX != OOXML)
<NCommander> Even Microsoft finally gave up and is implementing ODF
<directhex> i thought docx WAS ooxml - it's office 2003's "xml document" that isn't
<NCommander> No, its not
<directhex> but that was stillborn
<NCommander> DocX is based off a draft of OOXML
<directhex> hah, the xmlns url is dead
<directhex> nice one, MS
<directhex> ContentType="application/vnd.openxmlformats-package.core-properties+xml"
<directhex> that mimetype fills me with disgust
<cjwatson> I'm not sure xmlns urls are necessarily expected to return data
<cjwatson> they just have to be in a namespace you own
<Treenaks> cjwatson: it's considered good form to return data though
<cjwatson> I'm pretty sure I've seen W3 xmlns urls that claimed not to exist when queried with an HTTP client
<directhex> i'm sure i've seen discussion on the topic
<directhex> it seems many apps validate it
<directhex> so netscape.com still gets hammered
<directhex> as many html-esque xmlns lines live there
<cjwatson> maybe not W3 (they do seem to exist), but it's not just MS anyway
<directhex> but it's a reason to point and laugh... it's ms! special rules apply!
<directhex> hm. shall i get an early night, or is there a compelling reason for a late night? i think cjwatson is the one who decides that
<cjwatson> sassenfrassenslowbuilds
<directhex> moar mhz.
<cjwatson> building ubuntu kubuntu xubuntu ubuntu-server ubuntustudio now
<cjwatson> moar i/o I suspect
<cjwatson> usually about 15 minutes apiece
<directhex> d-i?
<cjwatson> hmm, I'm out of date. 8 minutes apiece
<cjwatson> alternate/server, yes
<cjwatson> desktop isn't ready for jaunty yet
<directhex> i ask because d-i is the only one i have any experience modifying
<directhex> we have fiddled etch CDs for rebuilding our infrastructure servers at work
<directhex> was gonna be dapper, but, well, kernel update policy fail. 5 months after release, and uninstallable on dell kit
<cjwatson> (that got fixed in 6.06.2, didn't it? but yes)
<directhex> 6.06.2 took a long time from my perspective
<directhex> with a million quid of kit to deploy, and no infrastructure servers to run it
<cjwatson> understood
<directhex> god, that sounds absolutely mad doesn't it. "a million quid of kit". i have root on that.
<directhex> and it's closer to 2m these days
<NCommander> hey infinity
#ubuntu-devel 2008-11-22
<emgent> heya
<NCommander> hey emgent
<emgent> hey NCommander
<NCommander> emgent, what be up?
<emgent> i saw your private message about utu
<emgent> one moment :)
<emgent> fixed
<NCommander> Cool
 * NCommander eyes #4 on the list
<kirkland> anyone familiar with inoticoming?
<kirkland> is it possible to watch an nfs-mounted directory?
<james_w> if you get "warning: format not a string literal and no format arguments" for a printf(foo); call then the fix is printf("%s", foo); isn't it?
<james_w> I mean, the two printfs are equivalent, correct?
<Byrnison> I think so.
<Byrnison> The latter will not do formatting if foo has %'s.
<Byrnison> But that's the point.
<james_w> but formatting would require subsequent arguments wouldn't it?
<Byrnison> Yes.
<james_w> ok, thanks
<Byrnison> The warning is there because printf(foo); is dangerous if foo is a user-inputted string. It would probably crash the program if there were %'s in the string. There are worse things that could happen, though.
<phirestalker>  I am trying to compile a program but it is giving a version mismatch error on libtool. I have libtool 2.2.4 but the program may be expecting the old 1.5, what can I do?
<ScottK> relibtoolize.
<phirestalker> that didn't work I have tried libtoolize and libtoolize --force, I have also tried aclocal to rebuild aclocal.m4 as the error suggests but nothing works
<phirestalker> they developers say they have got it to compile on the same version of linux I have Ubuntu 8.10, so I guess it is something about my system
<NCommander> ScottK, feel like sponsoring an upload?
<phirestalker> what files besides ltmain.sh have commands or directives that pertain to libtool that I may need to update to match ltmain.sh?
<NCommander> phirestalker, what package is it?
<phirestalker> it is oreka from oreka.sourceforge.com
<NCommander> (usually you can get away with libtoolize --force --install --verbose in the source code folder)
<phirestalker> the only complaint seems to be about install-sh: libtoolize: `/usr/share/libtool/config/install-sh' is serial 2006.12.25.00, greater than 0 in `./install-sh'
<stefanlsd> Anyone with a WP installation that gets the WP update announcement that can test something for me?
<thinkgnu> how can i make a changelog ? is there any tool to create a standard changeLog ?
<thinkgnu> it seems i should ask my question in #ubuntu-motu !
<thinkgnu> or not !?
<legreffier> just write yours in the standard
<legreffier> way
<legreffier> it's pretty trivial...
<thinkgnu> i do that already :)
<legreffier> there's an emacs helper dpkg-dev-el
<legreffier> it has a changelog mode
<legreffier> might help
<Hobbsee> legreffier: thinkgnu dch (dch -i is also useful)
<legreffier> it's not in my ubuntu :/
<legreffier> (using hardy currently)
<thinkgnu_> me too ! :P
<thinkgnu_> legreffier: it seems you need ubuntu-dev-tools
<legreffier> apt-cache search dch didn't show the way, thanks
<thinkgnu_> np ;)
<thinkgnu> Hobbsee:  it seems what i want , thanks.
<directhex> man, still with the a1? o_o
<deufrai> hi there, is it the right place to ask for advice about packaging for ubuntu ?
<cjwatson> deufrai: #ubuntu-motu is more used to doing mentoring work
<deufrai> cjwatson: thank you
* cjwatson changed the topic of #ubuntu-devel to: Archive: open, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> directhex: ^-
<ogra> urgh
<ogra> so how am i supposed to handle a patch in a quilt package that needs an autoreconf run ?
<ogra> afaik quilt requires me to add all touched files to the patch, how would i know which these were ?
 * ogra curses quilt once again
<soren> ogra: What I've done on a few occasions is to do all the patching I wanted, dpkg-buildpackage -S, run debdiff between the previous version and this one, filterdiff -x '*debian/*'.. That's usually the stuff that ought to be in the quilt patch... So I pipe it to a file and quilt import that, and "patch -R -p1" it on the dev tree. Presto.
<ogra> phew
<ogra> lots of work induced by a silly patch system :)
<soren> It sounds bad, yes.
<ogra> but right, that would indeed work
<soren> You get used to it, though :)
<soren> Have fun! :)
<ogra> well, i ry to stay away from quilt, but wanted to see whats up with rpm (keeps alien from armel)
<ogra> rpm itself is weirdly packages though
<ogra> *packaged
<ogra> soren, thanks for the hint
<ogra> :)
<soren> Quilt is growing on me, actually. It's very good when patches need to be refreshed.
<soren> ogra: sure thing.
 * soren wanders off again
<ogra> right, but in cases like the above i would just liked dpatch or even cdbs-edit-patch
<directhex> cjwatson, yay! of course, now someone needs to ack the mono upload. where's pitti hiding...
<persia> directhex, NEW or upload?
<persia> directhex, Reason being that most of the archive admins won't NEW stuff they upload, so if it needs both, you might do better to find a non-archive-admin uploader.
<directhex> persia, name names. the longer this takes, the more painful it is for everybody
<persia> directhex, See, it's not about names.  It's about teams.
<persia> I think you already subscribed ubuntu-main-sponsors.  From there, someone ought get it.
<persia> Mentioning the bug and asking generally for an upload is one way to escalate, but doing that too much tends to bother people.
<persia> Asking each of the main sponsors individually is very likely to bother people.
<persia> My main recommendation is that if you are going to poke specific individuals, it might be fastest to not poke the archive-admins until the new package split is waiting in NEW, just because of the multistep process involved.
<persia> (and launchpad does have a list of main sponsors, if you're *really* curious)
<directhex> persia, it's not my intention to be more obnoxious than my natural baseline level, i'm just a bit fed up with queues at the moment - especially on a package which experience says a lot of people don't want to be associated with. the last thing i want to see is a release turn up halfway through a package transition, gnat-style
<Silicium> hi there
<Silicium> iam searching for the gnome-volume-control maintainer
<directhex> in my defence, pitti IS in u-m-s, and has been helpful in the past when i've needed merges and updates to get pushed through
<directhex> Silicium, Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com>
<Silicium> ok i will try
<Silicium> so maybe anoyne know that bug
<persia> directhex, Sorry if I came off wrong: I don't mean to attack you: it's just that because I know you're doing a source split, and because the set of archive-admins is smaller than the set of main sponsors, I thought you'd be faster with another.
<Silicium> gnome setting "detachable menubars" was set, and the menubar of gnome-volume-control has been detached, and now it coulnt be attached again, the app faults with the following msg:
<Silicium> Bonobo:ERROR:(bonobo-dock-item.c:1342):bonobo_dock_item_get_child: code should not be reached
<Silicium> i think i should directly contact the gnome-dev ml
<directhex> persia, s'okay. what with ubuntu-motu@lists and boycottnovell.com, i assume a baseline level of attack at all times :p
<persia> directhex, I can see that.
<azeem> Silicium: file a bug, rather
<maxb_> I've just had usb-creator hang, and I think it's because I was using a USB stick that turns out to be preformatted *without* an MBR: i.e. /dev/sdb is a vfat FS, *not* /dev/sdb1 !
<directhex> maxb_, i've lost track of whether you're meant to do that or not, in general. i know i've had devices which looked at me funny for not doing what they expected
<persia> maxb_, If you can recreate with it formatted that way, and the same key works with partitions, please file a bug.  usb-creator is expecting partitions, but it's not supposed to hang.
<doko> cjwatson, Riddell: is there a reason not to enable mono in P-a-s? just seen that kde4bindings does ftbfs on lpia (NCommander mentioned that)
<NCommander> Scratch that
<NCommander> SOmeone added lpia support a few commits back
 * NCommander hasn't recently checked the file
<NCommander> Someone needs to change the build-dependences on kde4bindings then
<directhex> NCommander, they do anyway.
<NCommander> ??
<directhex> NCommander, kde4bindings is affected by the 2.0 transition
<NCommander> oh yay
<directhex> NCommander, it has no rdepends though AFAIK, so it ought to be possible to make those changes pretty much immediately, ignoring the "wait for apps to transition first" rule. once mono 2.0 lands
<NCommander> directhex, kde4bindings are libraries :-P
<NCommander> Its depressing though if nothing uses them
<directhex> NCommander, the cli bindings are pretty new
<directhex> NCommander, meebey, who as well as being the main mono packager is upstream on an irc client called smuxi, was considering playing with them to make a kde frontend as well as gtk
<NCommander> ah cool
<NCommander> Just keep me apprised, if you need a sponsor, ping me
<directhex> NCommander, really though, i don't know what more i can do to keep people informed about this, other than mass-filing 90 odd bugs on packages :/
<NCommander> The changes are non-trivial (more than changing a build-dep, and bumping the changelog)
<NCommander> It will be slow going
<directhex> NCommander, some packages are worse tha others. let me take a peek at kdebindings for you. not like i have much else to do at this moment in time
<NCommander> kde4bindings :-)
<NCommander> (kdebindings is another package ;-))
<directhex> yes yes i know. it's kdebindings on debian
<directhex> directhex@mortos:~$ monodis --assemblyref /usr/lib/cli/qyoto-4.3/qt-dotnet.dll | grep -B1 corlib
<directhex> 1: Version=2.0.0.0
<directhex> 	Name=mscorlib
<directhex> NCommander, good news, that means there's no additional testing needed, nor any reason to delay the transition, as it's already building against clr 2.0
<NCommander> someone just needs to attempt the merge
<directhex> i.e. the only changes are the build-dep, and making sure it uses 'csc' instead of 'gmcs' when building
<directhex> of course, it's blocked on mono 2.0 itself, but it means it should be a *relatively* stress-free one
<doko> directhex: does it make sense to start with mono before we have a base kde4 built?
<NCommander> doko, w.r.t. to KDE, a new version going up on monday, so aside from the base libraries, I'm going to wait for that to land before running around fixing stuff
<directhex> doko, other than kde4bindings (and i don't know how important that package is), it should be pretty unrelated. all mono apps in ubuntu are gtk-based
<directhex> doko, as long as the appropriate parties understand that kde4bindings will FTBFS until it's been transitioned, once mono 2.0 lands, then i don't want to tell people how to do their jobs nor insist they alter their workflow
<doko> directhex: ahh, ok I'll stay out of the loop then.
<doko> directhex: does openoffice build with mono-2.0?
<directhex> doko, i;ll check that for you
<doko> that would be nice
 * NCommander wonders if OOo will explode
<directhex> o_o
<NCommander> :-)
<directhex> doko, OOo looks like it'll be rather less simple than kde4bindings
<doko> directhex: because I would like to get OOo on armel first built ... if it doesn't work with mono-2.0
<directhex> doko, okay, looking at it, you're only attempting to build the mono bindings on [i386 amd64 ia64 lpia sparc]
<doko> I know ...
<directhex> doko, i can let you in on how to make it not ftbfs on other platforms, but please, it still needs to be transitioned
<doko> but it doesn't help if the binary-indep packages cannot be built on the i386 buildd
<directhex> doko, 's/mono-2.0-devel/mono-devel/' will fix FTBFS, but please, those libs really need to be built against the 2.0 runtime (currently it seems OOo builds three 1.0 libs, and a 2.0 lib - all four should be 2.0)
<doko> directhex: a bug report including a patch would be fine, hint, hint ;)
<doko> calc: ^^^
<directhex> doko, i'll start on an apt-get source. it might be done by tomorrow
<directhex> what build system does OOo use?
<directhex> hm, i need a faster archive
<directhex> oh bugger, forgot to change my mirror on this install
<Xsss4hell> howto unbind the "Menu" key on the right side near the STRG key from gnome-terminal
<directhex> a 100 meg diff.gz is officially insane
<hyperair> directhex: where did you get that?
<directhex> hyperair, OOo
<hyperair> good grief
<RainCT> o_O
<madduck> so i have this 8.04 system here that can't be upgraded to 8.10
<madduck> update-manager tells me 8.10 is available, so i click on it, see the README, click on upgrade, and then it just exits
<madduck> it prints to the console:
<madduck> extracting 'intrepid.tar.gz'
<madduck> authenticate 'intrepid.tar.gz' against 'intrepid.tar.gz.gpg'
<madduck> and then just exits
<kirkland> madduck: possibly related to https://bugs.edge.launchpad.net/ubuntu/+bug/245219 ?
<ubottu> Ubuntu bug 245219 in ubuntu "Ubuntu archive server returning incorrect content-encoding" [Undecided,New]
<kirkland> madduck: ie, are you behind some sort of a proxy?
<madduck> no, it works when I run do-release-upgrade by hand
<madduck> i just didn't know about that.
<madduck> yes, a transparent http proxy
<madduck> actually, do-release upgrade does an apt-get update with hardy, not intrepid
<madduck> aha, now it's coming int...
<madduck> anyway, works for me now, sorry for the noise.
<kirkland> madduck: not that this conversation has to take place now, but I'm working on merging mdadm again for ubuntu, and i'm curious if you're interested in getting this package somewhat closer to being 'in sync'
<kirkland> madduck: i did some work to improve booting on degraded devices for intrepid, which may or may not be of interest to you
<madduck> kirkland: absolutely. I am talking to doug kirkland @redhat too about merging
<madduck> kirkland: i saw your work. I would love to make use of most of it, but I have not found the time to wade through the entire huge patch
<madduck> I do want to convert mdadm to quilt soon
<kirkland> madduck: that would be nice ;-)
<kirkland> (quilt)
<madduck> based on a topgit repo
<kirkland> madduck: or git would be even better
<madduck> don't you have to use launchpad?
<kirkland> madduck: i'm happy to help work through the diff with you at some point
<madduck> kirkland: if i added quilt to mdadm post-lenny, would you be prepared to split the changes into quilt patches?
<kirkland> madduck: when's "post-lenny"?
<madduck> kirkland: when it's ready. ;)
<kirkland> madduck: (trick question)  :-)
<madduck> kirkland: I am happy to do so earlier if I find the time, targetting experimental
<kirkland> madduck: sure, i think quilt would be a big improvement
<madduck> It shouldn't even be a lot of work, but it is still time that's needed
<madduck> and i am about 160% loaded these days
<kirkland> madduck: i'm certainly most familiar with the boot-degraded changes;  i'd have to do some research about the rest of the changes ubuntu carries on mdadm
<kirkland> madduck: understood.
<kirkland> madduck: i got a little burnt out with users complaining about RAID 24x7, so i was happy to step away from RAID for a little while :-)
<madduck> kirkland: would you send me an email to madduck@d.o so I get your details?
<kirkland> madduck: you bet.
<kirkland> madduck: i'm happy to work through Debian BTS, but looking at the size of the mdadm debian/ubuntu diff, it might take a few irc conversations to peel through everything
<madduck> sweet. maybe i can find the time to give you an update on the cooperation with doug and maybe some time, ubuntu, fedora, redhat, and debian will all build their mdadm packages from the same repo.
<kirkland> madduck: remarkable ... Red Hat has a "Doug Kirkland" working on RAID?
<madduck> kirkland: yeah, and as I said, I am very pressed for time up until around May.
<kirkland> madduck: and Canonical has a "Dustin Kirkland"  :-)
<madduck> no,
<madduck> Ledford
<kirkland> madduck: fair enough
<madduck> Doug Ledford
<kirkland> ah
<kirkland> <madduck> kirkland: absolutely. I am talking to doug kirkland @redhat too about merging
<madduck> freudian slip i know
<kirkland> ;-)
<madduck> do you read pkg-mdadm-devel?
<kirkland> madduck: i haven't, to date.  i certainly can subscribe.
<madduck> well, might be useful if you track mdadm for Ubuntu...
<madduck> there's also pkg-mdadm-commits
<kirkland> madduck: well, i haven't been really "tracking mdadm for Ubuntu" ...  but I did decide to fix booting degraded RAID for Ubuntu, which put me deep into mdadm, initramfstools, and grub
<madduck> lovely world, ey?
<madduck> in a sentence or less, what is booting degraded RAID?
<kirkland> madduck: and i have a priority of trying to simplify the mdadm diff betwix debian/ubuntu, per request by jcastro
<madduck> i mean, mdadm on Debian can boot degraded raids, no?
<madduck> kirkland: awesome. hug jcastro from me. now it seems like i owe him another beer. :)
<kirkland> madduck: i'm not sure ... this might be a result of Debian/Ubuntu forkage
<kirkland> madduck: he's been on us about syncing back up, in a good way ;-)
<madduck> that's great news.
<madduck> you do know about http://vcs-pkg.org, yes?
<kirkland> madduck: so when a RAID becomes degraded (loses a disk) in Ubuntu, on the next boot, the mdadm --assemble with be tried a number of times (3 minutes in Hardy, 30 seconds in Intrepid), waiting for all the disks to spin up
<kirkland> madduck: in Hardy, when that timer expires, if disks are missing, the user gets dropped to an initramfs shell
<kirkland> madduck: the work i've done in Intrepid (and backported to hardy) includes:
<kirkland> madduck: a debconf question "Do you want to boot if your RAID becomes degraded?"  (more or less the question)
<madduck> damnit, i have to help my mother. i'll be back later to read this, ok? sorry about that. keep writing.
<kirkland> madduck: (sorry, not less than 1 sentence --  not possible :-)
<kirkland> madduck: the answer to that question is written to a file in /etc/initramfs-tools/conf.d/mdadm, which get's added to the initramfs
<kirkland> madduck: and in the initramfs, if the wait for all disks to spin up expires, the BOOT_DEGRADED value is read from file
<kirkland> madduck: if it's "true" or "yes" or whatever, the system RAID is assembled in degraded mode, and the system boots
<kirkland> madduck: if it's "false" or "no" or undefined, a message will be displayed, informing the user that a new RAID degrade event has been detected; do you want to boot on a degraded RAID [y/N]:
<kirkland> madduck: after 15s, "N" is assumed, and the system drops to an initramfs (busybox) shell, which is the legacy ubuntu behavior
<kirkland> madduck: dpkg-reconfigure mdadm can be used to change the value of your BOOT_DEGRADED selection
<kirkland> madduck: and we've added that debconf question to the debian-installer/partman if you're installing onto a RAID
<kirkland> madduck: beyond that, i also made some changes to grub (and grub-installer), to write the bootloader to each disk in an array
<kirkland> madduck: perhaps the most "compressed" patches for this functionality are the ones attached to https://bugs.edge.launchpad.net/ubuntu/+source/mdadm/+bug/290885
<ubottu> Ubuntu bug 290885 in initramfs-tools "SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy" [Wishlist,Fix committed]
<kirkland> madduck: that was the "backport" of the functionality, as contained as possible, to Hardy
<kirkland> madduck: the mdadm portion is http://launchpadlibrarian.net/19438493/mdadm.290885.debdiff
<kirkland> madduck: most of which is PO/translation noise
<kirkland> madduck: pruning out the i18n distractions, the functional patch looks more like this: http://pastebin.ubuntu.com/75724/
<kirkland> madduck: that patch is dependent on an initramfs-tools patch, http://launchpadlibrarian.net/19438280/initramfs-tools.290885.debdiff , which provides a "mount root failure" framework whereby hooks can be defined and executed
<kirkland> madduck: all in all, udev will likely be the biggest hurdle
<directhex> calc, ping
<calc> directhex: hi
<calc> directhex: whats up?
<directhex> calc, i wanted to ask when debian/control is rebuild on OOo
<directhex> seems it's when i hoped, so only debian/rules needs patching
<directhex> which means.....
<directhex> directhex@mortos:/tmp$ diffstat openoffice.org-2.4.1_mono2.0transition.diff
<directhex>  rules |    7 +++----
<directhex>  1 file changed, 3 insertions(+), 4 deletions(-)
<directhex> in THEORY that's correct & valid
<calc> debian/control gets rebuilt when you run debian/rules control
<calc> ok
<calc> yea i uploaded a new version of OOo 3.0 to the ppa last night waiting on doko to do some testing
<calc> i'm on vacation/holiday all next week
<directhex> calc, well, i hope this section of debian/rules hasn't changed in 3.0 :/
<calc> but i could do a new upload if needed
<calc> directhex: if it has it should be simple enough for me to port
<calc> directhex: you can email it to me at ccheney@u.c
<directhex> calc, yeah, i reckon you can handle things like
<directhex> -MONO_MINVER= (>= 1.2.3)
<directhex> +MONO_MINVER= (>= 2.0)
<calc> yea :)
<directhex> calc, OOo appears to have the build system from hell, but underneath it all, it smells like autofoo. and the transition with autofoo is pretty simple as long as you know the AC_PATH_PROGs to override
<calc> oh
<calc> yea OOo is very confusing in that it has two different configures
<directhex> no, OOo is confusing as it seems to have three different patches for adding mono to the build
<directhex> mono-build.diff, mono-build-m14.diff, mono-build-m15.diff
<calc> oh heh, yea it has many different confusing bits :\
<calc> there are no apparent mono patches for 3.0 not sure if they were integrated or not
<calc> at least none named *mono* under ooo-build/patches/dev300/
<directhex> calc, anyway, i'll mail you this patch, but please be aware that i've neither tested it (partly because i don't like mucking with 'pristine' pbuilders, partly because i only just wrote it and don't have the 600ghz needed to have been able to test it by now), and it can't be applied until mono 2 is in jaunty
<calc> directhex: ok no problem
<directhex> calc, i want to keep my transition wiki page updated. shall i assign OOo to you or me on it, to show that work is being done?
<calc> leave it as yourself but i will look into as i get time, i will be on vacation most of the rest of the year though (other than during UDS)
<directhex> calc, who else should i speak to r.e. OOo/mono issues (or who should be speaking to me?)
<calc> i think there is a week after UDS that i will be around, so i could look at it then if i am not too slammed with other work
<calc> directhex: maybe doko, but he will probably be away a lot as well
<NCommander> Can a core developer give-back k3b on armel
<directhex> evenin' NCommander!
<NCommander> evening
 * NCommander preparing for his company's turkey party
<directhex> yay, turkey
<NCommander> Free boozie
 * NCommander is going to discover if balmer's peak exists
<geser> do I resolve this correctly to http://xkcd.com/323/?
<RainCT> awalton__: oh, hi :)
<RainCT> awalton__: wouldn't it be better if your patch (nautilus scripts) also looked for deleted and modified files?
<directhex> geser, yes, you do
<ianm_> ï»¿anyone know of software for head tracking using a laptop camera?
<RainCT> ianm_: me not, but tell me if you find out ;P
<ianm_> RainCT: oh you'll hear about it... you already package my screenruler app ;)
<ianm_> opencv!
<RainCT> :)
 * directhex wonders who's about this evening
 * RainCT is to stupid to parse directhex's sentence :P
<Mithrandir> yo, directhex
<directhex> Mithrandir! long time, no see. man, how long is it since i loitered in #debian-amd64?
<Mithrandir> long enough I have to look at another machine's irc logs. :-P
<Mithrandir> how's life?
<directhex> good, good! looking after a LOT of kit these days
<directhex> working on mono packaging in my spare time, it seems
<Mithrandir> yeah, I've noticed you asking about bits and pieces
<Mithrandir> kit> any fun, or just much of it?
<directhex> Mithrandir, ehm... a 128-box xeon cluster, a 128-box opteron cluster, a new 66-blade SGI cluster, and a 256-core itanium SGI box
<cjwatson> NCommander: k3b given back
<cjwatson> directhex: ok, so what needs to go first?
<cjwatson> directhex: mono itself?
<Mithrandir> directhex: wow.
<directhex> cjwatson, yes, that's the important one
<cjwatson> directhex: is http://launchpadlibrarian.net/19799395/mono_2.0.1.orig.tar.gz definitely bitwise-identical to what will end up in Debian?
<directhex> ah. hm. let me triple-check that
<NCommander> hey cjwatson
<NCommander> cjwatson, I dunno if you caught the conversation between me and doko, but I'm going to hold off any more KDE-core FTBFS fixes until Monday when Beta 1 gets uploaded
<NCommander> *KDE4
 * RainCT feels ignored by directhex *g*
<directhex> RainCT, sorry
<cjwatson> NCommander: yeah, I saw, thanks
<RainCT> directhex: heh just joking ;)
<directhex> cjwatson, it seems not. shite. hold on...
<ianm_> RainCT or others, is it hard to make a PPA .deb of a C app that uses a version of the liblo library that isn't in the repos yet? (0.25)
<Mithrandir> ianm_: it requires the liblo package to be uploaded to the PPA too
<ianm_> Mithrandir: would that interfere with enduser systems at all?
<Mithrandir> ianm_: the newer version would obviously be installed on the user's system.
<Mithrandir> assuming it works fine, that's not a problem
<ianm_> two versions of the same library installed is ok?
<Mithrandir> if the soname is different, yes.
<cjwatson> directhex: there's at least one Ubuntu change missing here
<cjwatson> +     + libmono-mozilla0.2-cil: Drop libgluezilla to Suggests, it is in universe
<cjwatson> +       and pulls in the old xulrunner.
<ianm_> RainCT: there's also this http://code.google.com/p/ehci/
<directhex> cjwatson, gluezilla no longer needs xul 1.8. i'll file a MIR
<cjwatson> ah yes, so it doesn't
<cjwatson> directhex: what about the doc directory symlinking?
<directhex> cjwatson, the patch for it is badly written and will never be accepted in debian. given the multi-meg savings elsewhere, i don't see it as a good reason to merge instead of syncing, for the sake of tens of k
<cjwatson> I think it was more like 1.8MB, as it happens, though less compressed
<cjwatson> but I'm OK with that rationale given that the number of binary packages is shrinking (isn't it?)
<directhex> the number produced is *increasing*. the number needed for tomboy/f-spot is decreasing by about 50%
<cjwatson> oh, hmm
<cjwatson> I suppose it's more the latter we care about
<cjwatson> as written the patch goes to more work than it needs to, certainly (I think it came from an implementation in cdbs); I would suggest that you should consider the idea (not necessarily the specific implementation) in Debian anyway, since symlinking documentation directories to a common base package is a perfectly reasonable thing to do there too
<directhex> yes, i'll add it to the TODO
<RainCT> ianm_: thanks :)
<cjwatson> directhex: ta
<RainCT> ianm_: btw, have you tried out touchlib/tbeta?
<directhex> cjwatson, i don't think me or meebey realised the little issue w/ gzip reproducibility. i'm asking him to upload a copy of what will be uploaded to debian.
<cjwatson> oh, upstream only releases bz2, I see
<cjwatson> ok
<directhex> i wonder if the debian archive will properly handle bz2 any time soon
<cjwatson> should do with dpkg-source v3
<cjwatson> iirc, anyway
<NCommander> directhex, Debian has handled bzr2 for ages
<NCommander> I think they even handle lzma
<directhex> NCommander, *all* of it? iirc some of the toolchain has gaps
<cjwatson> NCommander: not as orig.tar compression methods
<cjwatson> which is the matter at hand
<NCommander> I was fairly sure this feature was properly implemented
<NCommander> If not, well, I have a dak installation + source
 * NCommander queues the evil laugh
<cjwatson> it's rather easy to verify that it is not supported by Debian; you could for example search for files ending with .orig.tar.bz2 in a Debian mirror ...
<NCommander> my mistake
<NCommander> I was sure it was supported though :-/
<cjwatson> http://liorkaplan.wordpress.com/2008/01/31/origtarbz2-packages-in-debian/
<ianm_> RainCT: not yet
<NCommander> cjwatson, I thought I already admitted they are not supported ;-)
<cjwatson> just some verification
<directhex> cjwatson, shall i upload the new orig to the LP bug? wait, i need to re-do the dsc too don't i
<cjwatson> directhex: don't worry about the dsc
<cjwatson> directhex: either upload it there or give me a URL
<directhex> http://www.meebey.net/temp/debian/mono_2.0.1.orig.tar.gz
<cjwatson> grabbing
<RainCT> ianm_: do you know if there's some .deb with OpenCV 1.1?
<ianm_> RainCT: nope.  I got the same "Requested 'opencv >= 1.1.0' but version of OpenCV is 1.0.0"
 * RainCT sighs and installs CVS
<cjwatson> directhex: hmm, does this have stuff stripped out of the tarball as well as simply changing the compression type?
<directhex> cjwatson, no, not anymore. the +dfsg was previously due to some non-dfsg-free licenses on some code (a CC license, i forget which). it was relicensed to expat at meebey's request
<cjwatson> directhex: meebey seems to have repacked the tar as well, though
<cjwatson> which seems a bit gratuitous?
<directhex> yes, i've told him off about that. he'll be using bunzip2 | gzip in future
<cjwatson> ok
<directhex> apparently it never used to be an issue, which is technically true...
<cjwatson> it's not an issue as such, it just makes it more effort to independently verify the status of divergence from upstream
<directhex> if there's no +dfsg on it, assume it's just a workflow glitch by meebey
<cjwatson> "independently verify" ;-)
<cjwatson> (I've already checked myself
<cjwatson> )
<madduck> kirkland: why would a user not want to assemble a degraded array?
<madduck> anyway i need to sleep. we'll talk again, thanks for the explanation! :)
<cjwatson> directhex: mono uploaded
<cjwatson> directhex: what else can/should be done in the first stage before that builds?
<cjwatson> directhex: libgdiplus?
<directhex> cjwatson, yes, please sync it
<directhex> cjwatson, i know it's possible to use mismatched versions of some packages like libgdiplus, but i don't know if there are side-effects
<cjwatson> directhex: do you want to keep bug 300133 open to track this, or shall I close it?
<ubottu> Launchpad bug 300133 in mono "Mono 2.0.1 package (triggers major packaging transition, please read in full)" [Undecided,New] https://launchpad.net/bugs/300133
<directhex> cjwatson, close it - i'm tracking it on wiki.debian.org, and i don't want to crapflood people who aren't me by tracking 90 packages from one bug
<cjwatson> ok
<directhex> cjwatson, thanks very much for your help
<cjwatson> directhex: done
<cjwatson> directhex: xsp/mod-mono/mono-debugger now or later?
<directhex> cjwatson, is dep-wait a problem in the real archive?
<cjwatson> in what sense?
<directhex> xsp can't build until 2.0 is there, i was under the impression uploading unbuildable source was frowned upon in debianland
<cjwatson> I'm not aware of that being a problem for either Debian or Ubuntu
<directhex> really? perhaps i'm just paranoid then
<cjwatson> not a problem in Debian at any rate
<cjwatson> err
<cjwatson> not a problem in UBUNTU at any rate
<cjwatson> brains
<cjwatson> directhex: same question for the .orig.tar.gz files in those three bugs, then
<directhex> cjwatson, i've asked meebey to grab them and use them as his own
<cjwatson> directhex: has he said yes? just want to avoid sync problems in the future
<directhex> i'm double-checking
<cjwatson> directhex: I think I need to go to bed though, maybe I should stop here and resume tomorrow
<directhex> cjwatson, understood. i'll try and get monodoc ready by then - didn't get a chance tonight
#ubuntu-devel 2008-11-23
<cjwatson> directhex: let me know when you've had .orig.tar.gz confirmation from meebey
<directhex> confirmed
<cjwatson> directhex: hmm, xsp won't dep-wait; all its build-dependencies are already available
<cjwatson> directhex: I think I'll indeed leave this until tomorrow morning after it's all built and I've done binary NEW
<cjwatson> seems safer
<directhex> yeah, indeed. let me check my build-deps
<cjwatson> I don't have a major problem with the build-deps not being 100% accurate for Ubuntu since we're going to operate in strict order anyway, but you might want to get them right for Debian
<directhex> hm, no, i think it's a bug in the archive. build-depends-indep: mono-devel
<directhex> mono-devel doesn't currently exist in jaunty
<directhex> i should version that as (>=2.0) though
<cjwatson> oh, yeah, you're right
<cjwatson> no bug in the archive, bug in my brain
<directhex> same difference!
<cjwatson> thankfully, the archive has more work to do :)
<directhex> heh!
<cjwatson> I've uploaded xsp, then
<Mithrandir> mmm, braaains
<directhex> yay, thanks cjwatson
<cjwatson> Mithrandir: could you score up https://launchpad.net/ubuntu/+source/mono/2.0.1-0ubuntu1/+build/794238, please? sparc is down to one buildd so it'll take forever otherwise
<cjwatson> maybe also https://launchpad.net/ubuntu/+source/mono/2.0.1-0ubuntu1/+build/794235, though that's less bad
<Mithrandir> cjwatson: sure, doing so
<Mithrandir> done, 5k
<cjwatson> thanks
<Mithrandir> 50k for sparc, so it builds now
 * Hobbsee waves to Mithrandir, directhex, and cjwatson
<directhex> hello Hobbsee
<cjwatson> perfect, all builds due to start within an hour now
<Mithrandir> hiya little green Australian
<cjwatson> Hobbsee: hiya
<Hobbsee> Mithrandir: i'm not a green alien today.  i'm a blue, crystalised alien.
<Mithrandir> oh, is it cold?
<Hobbsee> very.  14C here
<directhex> 14C is cold?
<directhex> they had snow oop norf today!
<Hobbsee> directhex: it is for here
<Hobbsee> we're probably getting snow on the mountains today
<Hobbsee> directhex: oh, and i freeze extremely quickly.
<Mithrandir> it's only like 20Â°C here now.
<Hobbsee> send us a bit of warmth, then!  :P
<Mithrandir> I'm here for another week, come visit
<Hobbsee> someone else can do my dratted exams?
<Hobbsee> oh *damn*.  This is the max temp for san fransisco in december, too.  I thought it'd be a bit warmer, at least.
<stgraber> Hobbsee: California will be warm, at least compared to what I've here (-7C) :)
<Hobbsee> stgraber: ewww!
<Hobbsee> stgraber: you're..canadian now, right?
<directhex> http://www.bbc.co.uk/weather/5day.shtml?id=2941 - toasty!
<stgraber> yeah but I'd have get something similar in switzerland too
<stgraber> but yeah, if you plan to relocate and like warm winters, don't choose canada :)
<directhex> go south for the winter?
<stgraber> yeah, I should ask to work at the Brazilian office during the winter :) (well, office == 1 employee at the moment)
<directhex> so ask to work in a brazilian employee's closet?
<directhex> and now, time for bed. tonight i sleep the sleep of the just
<Hobbsee> night!
<kirkland> madduck: because the user might boot into a system where they are no longer protected by redundancy, and loss of a second disk would spell permanent data loss
<kirkland> madduck: seemed wise, to us, to provide the option to the system administrator
<persia> directhex, Some people have found that using gzip -9fn is a handy for bzip -> gzip changes to maintain md5sum reproduction (for future reference)
<madduck> kirkland: sure, knowing that there is no redundancy and the data are in immediate danger is helpful, but choosing not to assemble the degraded array doesn't increase the lifetime of the other component disks.
<doko_> directhex, cjwatson: mono did fail to build on arm. maybe wait until accepting it from NEW?
<directhex> doko_, doko_ balls. build log?
<directhex> wait, got it
<doko_> directhex: see bug 301232
<ubottu> Launchpad bug 301232 in mono "armel build failure" [High,Confirmed] https://launchpad.net/bugs/301232
<directhex> NCommander, i need your healing touch i think
<directhex> doko_, i don't have much knowledge of arm porting. can you answer a couple of questions, or should i wait for NCommander to appear?
<doko_> directhex: not that much time today, I may be unresponsive
<directhex> doko, i think the problem comes from incomplete changes to the code relating to the new arm-darwin target (i.e. iphone). the darwin target explicitly defines -DARM_FPU_NONE=1, the linux target does not. what kind of FPU should be checked for slash built for?
<directhex> hm, config.log would probably be helpful :/
<doko> directhex: defining -DARM_FPU_NONE=1 should be ok for now
<directhex> for now?
<cjwatson> doko: rather too late, I already accepted it
<cjwatson> directhex: we might want a variant built with VFP later, but ARM_FPU_NONE will be a baseline
<doko> directhex: yes
<directhex> morning cjwatson
<directhex> i'll prep a 0ubuntu2 then, it's a 1-line change
<cjwatson> throw me a patch and I'll sponsor it
<cjwatson> directhex: did you get round to writing that gluezilla MIR?
<directhex> cjwatson, no, it was late last night, and i got up late today
<directhex> cjwatson, i'll do that now
<cjwatson> mono-debugger uploaded
<cjwatson> directhex: was there a reason to repack the mod-mono tar?
<cjwatson> (i.e. do you want to take the opportunity to just bunzip2 | gzip?)
<directhex> no explicit reason (i was probably glancing over the code), but at this stage, it would do more harm than good to regenerate the orig (as meebey has already got the one from LP to be used for debian)
<cjwatson> ok
<directhex> rules r.e. repacking are being added to cli policy
<directhex> or at least to team policy
<cjwatson> directhex: mono-debugger failed to build: http://launchpadlibrarian.net/19878271/buildlog_ubuntu-jaunty-i386.mono-debugger_2.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<cjwatson> mod-mono uploaded
<directhex> okay, thanks for mod-mono
<directhex> mono-debugger..... it seems that whilst it was marked as "done", it's anything but. sigh.
<directhex> sorry
<cjwatson> looks like mono-debugger needs to look for gmcs2 rather than gmcs?
<cjwatson> or is that a bug in mono-gmcs?
<cjwatson> hmm, or csc?
<directhex> control and rules need patching
<directhex> for all my bluster, it hasn't actually been transitioned to the new build-deps
<directhex> cjwatson, it should look for csc, but that change isn't in svn. i'll do it now
<cjwatson> ok
<directhex> gah, parents have turned up. back in a couple
<maxb_> Would anyone happen to know of an alternate implementation of sha256 besides the coreutils one?
<maxb_> it and reprepro are disagreeing about what the sha256 of a file is, and I want to determine which package has the bug by getting a third opinion
<directhex> cjwatson, ping: https://bugs.launchpad.net/ubuntu/+source/mono/+bug/301232
<ubottu> Ubuntu bug 301232 in mono "armel build failure" [High,Confirmed]
<geser> maxb_: openssl dgst -sha256 $file
<cjwatson> directhex: I think it would be better to decide on a particular one in debian/rules, rather than having it depend on the build machine
<cjwatson> directhex: we don't necessarily want runtime requirements to be identical to what the buildd has available
<cjwatson> directhex: ... i.e. add --with-fpu=NONE on armel please?
<directhex> cjwatson, eh, it's added:
<directhex> else ifeq ($(DEB_BUILD_ARCH), armel)
<directhex>         CONF_FLAGS += --with-tls=pthread --with-fpu=NONE
<cjwatson> directhex: not in the debdiff attached to that bug
<cjwatson> directhex: oh, I see, it was there already
<directhex> cjwatson, upstream promised the --with-fpu= thing had gone upstream a while ago. it's a regression that means it's gone, so we've updated a dpatch which adds it back
<directhex> so passing --with-fpu wasn't doing anything
<cjwatson> directhex: ok, edited the changelog entry to close that LP bug, otherwise uploading as given
<cjwatson> thanks
<directhex> cjwatson, well, meebey fixed it, i was out with visiting parents today
<cjwatson> directhex: oh, I'm also putting the Ubuntu Maintainer field back
<directhex> oh, cocks, sorry. i keep forgetting about those
<cjwatson> directhex: sorry to keep going back and forward, but is it just me or will the automatic detection override anything you set via AC_TRY_WITH anyway?
<cjwatson> directhex: it doesn't seem to check whether fpu is already set before doing AC_TRY_COMPILE
<cjwatson> directhex: ... except that I'm blind and can't read diffs. Ignore me!
<directhex> /ignore
<cjwatson> really uploaded this time
<directhex> heh. better *right* than rushed
<directhex> sparc build of mono 2.0.1-0ubuntu2 in ubuntu jaunty RELEASE
<directhex> Estimated build start:  	2008-11-26
<directhex> someone needs to beat more sunfires out of sun
<directhex> (nah, scoring it up isn't worth it, it has 0ubuntu1 and 0ubuntu2 is arm fixes only)
<directhex> jaunty armel   Successfully built  (ACCEPTED)
<directhex> cjwatson, can i hear a "w00t"? :)
<cjwatson> directhex: w00t
<directhex> :)
<directhex> cjwatson, hanska has finalized his monodoc 2.0 package, which includes some *great* backports from 2.2 (in <2.2, the monodoc.xml index file needs mangling every time a manual package is added or removed, we've backported dynamic index generation from an improvement upstream wrote for our benefit). once meebey signs off on it, i'll file a bug on that. ditto a *fixed* mono-debugger
<cjwatson> ok, cool
<NCommander> hola
<directhex> HELO!
<directhex> NCommander, needed you this morning, had to fix armel ftbfs all alone ;)
<NCommander> I was recovering from beer
<NCommander> directhex, and the ARM one is still broken
<directhex> NCommander, hm?
<NCommander> directhex, nm, the build log I saw was old
<NCommander> directhex, how did you fix it?
<NCommander> (what did you define?)
<directhex> NCommander, we had an old patch to make configure understand a --with-fpu= setting, which we turned back on after refreshing
<directhex> NCommander, basically defining ARM_FPU_NONE explicitly
<NCommander> I thought were compiling FPU support in ...
<NCommander> directhex, er, nm
<directhex> NCommander, important thing is, mono 2.0.1 ACCEPTED on armel
<persia> NCommander, The idea is to start with a base system that should work everywhere, and build optimised versions of libraries where required.  It might make sense to have a vfp version of mono, but not in the default build.
<NCommander> persia, an VFP version will work fine
<NCommander> The kernel will catch the exception when a FPU instruction is executed, and then emulate it
<NCommander> (its slow, but the binaries themselves would worK :-))
<persia> slow isn't better :)
<directhex> i'm open to long-term solutions, but i think letting mono use its own ARM_FPU_NONE code for now is a sensible enough solution to having it at least be functional
<sebner> persia: only some hours left until you leave :)
<persia> directhex, Short-term, I'd agree.  Longer-term, if there's a signficant performance difference, it might be worth having a double-build with different versions of the library available.
<directhex> persia, yes, i think that would be interesting
<directhex> persia, an alternate mono-jit package i think
<persia> directhex, I'll trust you on which bit might benefit from optimisation :)
<directhex> persia, it might require some re-sculpting of debian/rules unless armel-fpu got its own $ARCH, lpia-style
<cjwatson> I don't expect it to be a separate dpkg architecture
<cjwatson> we have enough to do bringing one architecture up
<persia> directhex, It would require sculpting of debian/rules, but I suspect the adjustment would have benefit for both Debian and Ubuntu.
<persia> directhex, Given where you tend to concentrate your work, if you get something that seems to work, it's probably worth chatting with the Debian armel team about the possible optimisations.
<directhex> persia, without access to an armel machine for testing, i'm pretty much unable to help
<directhex> persia, i.e. a buildd or developer machine
 * NCommander just found his next project
<directhex> NCommander, mono-jit-supermegaarmfpu?
<NCommander> directhex, orig.tar.bz2/orig.tar.lzma
<NCommander> in dak
<directhex> NCommander, even better!
 * directhex is slightly aroused at the thought
<NCommander> I figure it I can get Debian to accept them
<NCommander> THe LP devs must add support
 * NCommander laughs evilly
<Byrnison> I haven't been paying attention... LZMA compressed packages?
<ajmitch> directhex: funny, I thought that NCommander would be porting mono to nvidia/ati cards
<NCommander> mono works fine on both
<ajmitch> I mean using the GPU to accelerate certain things
<directhex> ajmitch, O RLY?
<directhex> [jms@durandal ~]$ mono deviceQuery.exe
<directhex> There are 2 devices supporting CUDA
<directhex> Device 0: "Tesla C870"
<ajmitch> interesting
<ajmitch> and mildly scary
<cjwatson> NCommander: I thought it was something planned for dak after lenny anyway, TBH
<cjwatson> NCommander: I'd take it as a favour if you'd ensure that LP gets fair warning if you do it, though; it would be very annoying to be unable to sync lots of packages for a month
<directhex> ajmitch, hell to code, and CUDA.NET.dll is non-free
<NCommander> cjwatson, of course, I'll make sure the devs get fair warning before any code lands on ftp-master-production
<directhex> ajmitch, it's a direct language binding, e.g. only supports native CUDA data types like "float4", not normal CLI ones like Double
<directhex> and once you start using array pointers to point to c# arrays, you've already lost
<doko> directhex, NCommander: if you rebuild packages for the mono transition, please don't upload openoffice.org. still building on armel, and there's at least on other change to make with the next upload
<directhex> doko, i don't intend to molest any non-pkg-cli-* apps directly - other than offer patches
<directhex> doko, did calc CC you the OOo patch i sent him?
<doko> directhex: no, calc is currently preparing 3.0, please could you send it to me as well?
<directhex> doko@debian ?
<doko> directhex: doko@ubuntu.com
<directhex> senyt
<kees> hrm, what's this Pulse Null Output junk?
<persia> kees, Maybe you want to use pulse, but you don't want to make any noise.
<slangasek> yes, a frequent goal of mine is to consume CPU cycles without generating output
<kees> slangasek: I always run "cat /dev/urandom > /dev/null" for each CPU I have.
<persia> slangasek, Maybe you have an app that won't shut up, and you want to redirect it's output?  Maybe you're testing something, and want to avoid interactions of a given output plugin?
<NCommander> Question, IF I'm converting a friend to Ubuntu for the first time, should I give him Hardy or Intrepid?
<directhex> intrepid imho
<slangasek> persia: I am immune to your logic
<persia> slangasek, We've known that for a while :)
<cody-somerville> lol
 * NCommander packs up
<mok0> Anyone with a bit of time on their hands, please take a look at Bug #299489 , there is a patch to fix an annoying bug in libupsclient1-dev
<ubottu> Launchpad bug 299489 in nut "[jaunty] /usr/lib/libupsclient1.so is a dangling link" [Medium,Confirmed] https://launchpad.net/bugs/299489
<NCommander> mok0, let me see
<NCommander> oh, needs a core dev
<mok0> yes
 * NCommander pokes LP
<NCommander> I think I broke it
<directhex> NCommander, consider it just punishment for no debian PPAs
 * NCommander also learned his laptop knows what a DVD-RAM is O_O;
<directhex> NCommander, panasonic drive?
<NCommander> Nope
<directhex> hm, odd then. i thought it was mostly panasonic drives w/ dvd-ram support
<ScottK> mok0: It looks like the Debian maintainer is trying to be responsive.  Could you work with him to try and get a complete fix in Debian and then we sync the pacakge?
<ScottK> doko: Are you going to update python 3.0 in Intrepid too (please)?
<mok0> ScottK: that was fast
<ScottK> mok0: Is that a yes then?
<mok0> ScottK: of course
<mok0> ScottK: trying to find his reply
<ScottK> mok0: I don't think he replied to your last comment, just the one from two days ago.
<mok0> Ah, ok
<ScottK> If the Debian maintainer is active in the bug, then I think it's good to try and work with them.
<mok0> Absolutely
<ScottK> Generally I think it's good, but particularly in such a case.
<doko> ScottK: not before the final
<ScottK> doko: OK.  I can understand that.  Is that expected soon?
<mok0> ScottK: Actually, I don't think I got all the Ubuntu changes merged in. I don't know what happened, I took the grab-merge output
<doko> Dec 3
<ScottK> Not long at all.
<ScottK> mok0: Sounds like a good time to sort it all out with Debian and see how much they'll take.
<mok0> ScottK: will you remove the bug from the sponsor queue, then?
<ScottK> Sure thing
<ScottK> mok0: Done.
<james_w> when a package needs specific permissions on a owner/permissions on a package it will chown/chmod it in postinst. If that directory is in /var/run then Ubuntu will move that code to the init script.
<james_w> the correct way to change the owner/permissions is to guard the call with a call to dpkg-statoverride
<james_w> however, I haven't seen many packages do that in code in the init script.
<james_w> Is this a bug that we are introducing to these packages, or is it not a problem as dpkg-statoverride doesn't work on a tmpfs?
<mok0> james_w: good question
<soren> james_w: One could easily make the argument that we should be respecting statoverrides in init scripts.
<soren> james_w: Regardless of whether the created files/directories are on tmpfs.
<Philip5> hi! is there a dh-command for bumping the changelog with a new timestamp etc in a existing debian/files tree like the autogenerated one you get in the changelog the first time you run dh_make?
<TheMuso> Philip5: dch -e
<TheMuso> Philip5: which is in devscripts
<TheMuso> Philip5: or dch -i depending on whether you want a new changelog entry, or update the timestamp for the top most entry.
<TheMuso> Philip5: man dch for more info.
<Philip5> nice... thanks
<Philip5> it was the -i parameter and the command it self i was looking for
<Philip5> thanks a bunch
<TheMuso> Philip5: You're welcome.
<savvas> Now that Philip5 mentioned it, do you happen to know a script that creates just the timestamp line similar to the changelog one, e.g.  -- Name Surname <email> date/time
<TheMuso> savvas: Creates, or edits?
<savvas> creates
<TheMuso> Dch may have something, but if it does, I don't know about it yet.
<savvas> I just wanted to add a timestamp in debian/README.Debian file :)
<TheMuso> savvas: devscripts may have something, the package devscripts that is.
<savvas> I'll take a look
<james_w> savvas: dch can create other files
<james_w> savvas: but I'm not sure it does README.Debian, as that is normally considered to be for all versions, as opposed to NEWS.Debian
<savvas> wait I think I'm on to something, debchange --news
<james_w> dch -c README.Debian as well
<savvas> by the way, is it recommended to use debian/README.Debian in Ubuntu packages or debian/README.Source ?
<RAOF> savvas: Those two files serve different purposes.
<RAOF> savvas: README.Debian is things that (advanced) end-users may want to know about the package; README.Source is things that packagers should know when messing with the package.
#ubuntu-devel 2009-11-16
<craigbass1976> I've been reading this: https://lists.ubuntu.com/archives/ubuntu-devel/2009-June/028297.html  What was the verdict for someone still on Jaunty?
<craigbass1976> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/289852   I tried that stuff too, and still no love
<ubottu> Launchpad bug 289852 in cups "intrepid: printing very slow (dup-of: 382379)" [Undecided,Incomplete]
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released]
<craigbass1976> Anyone know how to get the fix for bug#382379, or have I already got it and it still isn't working?
<ccheney`> has anyone been able to get googletalk to work from the hotel?
<ccheney`> finally just magically started working
<diwic> In what timezone is the schedule on http://summit.ubuntu.com/uds-l/2009-11-16/ ?
<diwic> According to http://summit.ubuntu.com/uds-l/ it says EST, but timeanddate.com says dallas is in CST.
<Flannel> Dallas is CST
<diwic> So http://summit.ubuntu.com/uds-l/ is wrong then?
<diwic> And https://launchpad.net/sprints/uds-l says UTC, to add to the confusion
<foobarmus> Can anyone tell me if a bunch of video drivers have been removed from recent kernels? I'm beginning to suspect this has happened...
<RAOF> foobarmus: Such as?
<lifeless> foobarmus: I'm not aware of anything like that.
<foobarmus> RAOF: um, I dunno... I have 2 boxes each with a different card... Having trouble getting both Karmic and a recent download of Hardy to spit out anything more than 800x600 on either of them
<foobarmus> RAOF: never had this kind of trouble b4... have been using ubuntu for years, on all kinds of hardware
<RAOF> What video cards?  The kernel doesn't tend to drop support for anything, but you may well be running into Proprietary Driver Annoyanceâ¢
<\sh> moins
<\sh> guys, the times on summit.u.c are in UTC, right?
<foobarmus> RAOF: they are pretty bog standard cards, nvidia maybe... one is about 6 yrs old, the other 3 yrs old
<lifeless> nvidia, mmm proprietary hardware
<RAOF> foobarmus: Well, nvidia is likely proprietary hell.  Particularly since they'll have dropped support for your card in recent drivers.
<foobarmus> have had multiple installs of ubu running on both boxes b4, everything from dapper to Jaunty... now I can't seem to install anything
<RAOF> (We now have 4 different versions of the nvidia driver in the repositories)
<foobarmus> RAOF: hmmm... so I should go back to an older kernel?
<foobarmus> RAOF: or older release?
<lifeless> RAOF: is nouveau nvidia or ati?
<RAOF> foobarmus: #ubuntu is probably a better place for troubleshooting.  You should be able to get Karmic working on both your systems, but I can't tell you how :)
<RAOF> lifeless: nouveau is nvidia.  The radeon is ati.
<lifeless> foobarmus: so, #ubuntu, but also try the nouveau driver (or if you are, try the proprietary one)
<foobarmus> RAOF: Thanks for the info
<foobarmus> lifeless: cheers
<RAOF> lifeless: (Fun fact: nouveau is called nouveau because the first (French) developer had a text-substitution alias for 'nv->nouveau')
<hyperair> how does one debug an upstart job?
<\sh> hyperair: vi /boot/grub/menu.lst add --verbose or --debug to the kernel command line
<hyperair> \sh: is there any way i can debug an upstart job without rebooting?
<hyperair> $ sudo start apport
<hyperair> start: Job failed to start
<hyperair> that's all i see
<hyperair> running the pre-start script manually in dash or bash works
<hyperair> and there's no exec
<hyperair> i can't figure out why it's not working
<\sh> hyperair, http://upstart.ubuntu.com/wiki/Debugging
<\sh> hyperair, eventually because it's not enabled in /etc/default/apport
<hyperair> hmmm
<hyperair> ah
<hyperair> thanks
<hyperair> i feel stupid now
<hyperair> heh
<forscher> hi - could someone tell me how udev does handle keyboards and joysticks to create eventN on hiddevN ?
<Tm_T> dendro-afk: hrr, awaynick ):
<lool> Do we have a script to "import" a Debian bug into a LP one?
<lool> (create a LP bug from a Debian bug)
<hdon> i think i just made gnome-terminal crash!
<hdon> all my tabs!
<hdon> gone!
<hdon> :C
<cjwatson> yes, well that's a design flaw (robustness) in g-t, isn't it ...
 * cjwatson uses pterm O:-)
<hdon> gtk 1.2 :O
<highvoltage> but does pterm have tabs? ;)
<cjwatson> hdon: not in karmic
<cjwatson> highvoltage: no, and I like it that way :)
<hdon> oh
<hdon> i suppose i should upgrade eventually
<cjwatson> separate processes => one crash doesn't take out everything
<cjwatson> (obviously xterm etc. are the same)
 * hdon can't imagine an acceptable circumstance for terminal emulator crash
<cjwatson> hdon: sure, but there's this principle called "defence in depth" ...
<highvoltage> cjwatson: I guess all the cool people us screen anyway
<hdon> cjwatson: xterm instances are in one process?
<cjwatson> hdon: each xterm instance is a single process
<directhex> perhaps g-t should be a transparent frontend to screen!
<hdon> ah, ok. i thought i had entered a parallel universe or something
<hdon> holy shit
<hdon> lmao
<hdon> i ran gnome-terminal --disable-factory so that i could recreate the crash and see what it says
<hdon> but when i did it, both of my terminals crashed. *should have seen that coming*
<hdon> wow, now i cannot recreate the crash at all
 * hdon scratches his head
<hdon> hmm, there we go, that did it
<hdon> i think i know how to recreate it now
<hdon> of course maybe it isn't even in karmic
<hdon> oh well i can't mess with this right now
<hdon> if someone else wants to investigate, try menu/Terminal/Set Character Encoding/Add\Remove
<hdon> and then try adding one
<hdon> that caused a crash for me. maybe only if there is more than one gnome-terminal running. i can't be sure
<hdon> running with --disable-factory may protect from crash
<hdon> cjwatson: i think --disable-factory will get you a new process for each gnome-terminal, but that did not mean the crash didn't take down all my gnome-terminal processes anyway
<hdon> i suspect it's some kind of race condition somewhere
<hdon> for some shared resource concerning available character encodings
<YokoZar> what's the summit IRC channel?
<StevenK> #ubuntu-devel-summit
<forscher> Could someone tell me how udev detect and handle keyboards and joysticks? Through all changes in Karmic I have lost the path....
<forscher> a link to some documentations are pretty welcome!
<snnw> Amaranth: ping
<Amaranth> snnw: pong
<snnw> hi, I noticed in Alacarta's git repository that you started a rewrite in Vala a couple months back. Can you tell me if there are any plans on replacing the python implementation with yours?
<snnw> I was writing a few patches for the python one, but if that's a dead end I'd rather work on the newer code base
<snnw> If this is not a good time, I can ping you later.
<snnw> Amaranth: still there?
<Amaranth> snnw: I'd like to see the vala one finished but it's somewhat stalled on libgarcon
<Amaranth> snnw: So I doubt the vala one will replace the python one before gnome-shell replaces alacarte completely
<snnw> Amaranth: Thanks, I think I'll stick with the python one for now, then. It's kind of nice, working on a small project like this :)
<Kartinka> Hey guys, i was hiding some unmounted partitions with DevKit / udev Rules, but i search for a way to hide these partitions completely from the system not only from gnome / nautilus. Can anyone help me?!
<craigbass1976> https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/382379   The fix has been released.  How do I go about implementing it?
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released]
<ebroder> Kartinka: We've told you before - this is not the right channel for this discussion
<Kartinka> i search only for sb i won't talk in the chan...
<forscher> to which channel did Kartinka go?
<Kartinka> here
<Kartinka> i'am
<Kartinka> ^^
<Kartinka> can you help me?
<Kartinka> forscher?
<jdong> does upstart do a sync anywhere at reboot?
<jdong> I'm seeing somewhat reproducible FS data loss when rebooting right after heavy IO
<jdong>         if (! no_sync)
<jdong>                 sync ();
<jdong> hmm. Seems like it should :-/
 * jdong blames btrfs
<StevenK> Sounds like a good thing to blame :-P
<jdong> lol hey hey!
<jdong> at least I don't have to iteratively download and md5sum my >500MB files :P
<StevenK> Does btrfs actually support sync? :-)
<jdong> StevenK: as far as I know, yes :)
<ajmitch> you just enjoy the bleeding edge
 * soren hugs his XFS filesystems
 * jdong switched from XFS to btrfs on this server :)
<soren> No sympathy, then.
<soren> :)
<jdong> partly to help the cause, partly because I was tired of XFS taking 2 minutes to clean pbuilders
<jdong> lol nothing actually was lost though :)
<soren> jdong: 2 minutes to clean pbuilder? You got that bad unlink performance?
<jdong> yeah, on XFS
<jdong> any nontrivial pbuilder takes minutes to clean
<jdong> unlink performance on XFS for me has been pretty horrible with a collection of small files
<soren> Wow.
<jdong> I mean, I love XFS -- my media storage partition is still XFS
<jdong> but... there's certainly some things that XFS simply wasn't designed to excel at.
<soren> I know it has less than stellar unlink performance, but I've never seen anything as bad as what you're describing.
<slangasek> any nontrivial pbuilder should use sbuild + schroot w/ LVM snapshots ;)
<ebroder> Yeah, I used to think that. My stance now is "any nontrivial build should use PPAs" :-P
 * soren uses tarballs for his sbuild
<ajmitch> ebroder: depending on your upstream bandwidth :)
<ebroder> Oh, also, you don't want LVM snapshots, because their performance sucks, too. You actually want the aufs support added in schroot 1.3
<jdong> aufs sounds like a good idea for this
<jdong> or.... btfsctl -S....
<jdong> *ducks*
<soren> It performs better (no overhead of dm_snapshot), it doesn't waste space, it allows bigger builds.. It's pretty awesome.
<ebroder> aufs with a tmpfs for the overlay is going to be faster than ~anything that writes to disk, so long as you have the RAM for it
<ajmitch> anything that avoids hitting the disk overly much is great on a laptop
<soren> Even counting the time it takes to unpack tarballs, it still beats lvm snapshot based sbuilds even for relatively small builds.
<sebner> jdong: I'm wondering why btrfs takes that long to mature. Started 2006 afaik, big company behind it and it has the attention of the community. Will be stable in 2010 earliest imho
<ajmitch> sebner: given that 2010 is a few weeks away...
<jdong> sebner: eh they're playing the game responsibly.
<sebner> ajmitch: and lasts 365 days :P
<sebner> jdong: isn't game responsibility to push out stuff to early?
<jdong> Yes
<jdong> It is though
<jdong> It's in mainline, easy to build git checkouts...
<jdong> Dunno what else one expects
<sebner> jdong: with whom do we need to stay in bed in order to get btrfs installable with lucid like fedora offers now :P
<yofel> hi, would bug 402188 qualify for a SRU? The patch has been tested in a ppa and works fine.
<ubottu> Launchpad bug 402188 in vim "gvim complains about "gtk_form_set_static_gravity: assertion `static_gravity_supported' failed" in the shell it's started from" [Undecided,Confirmed] https://launchpad.net/bugs/402188
<ebroder> Hmm...when I run 'manage-credentials create -c ubuntu-dev-tools -l 2' on my Karmic machine, then fill out the web form, then hit enter in manage-creds, I get a 401 error
<ebroder> Oh wait - classtime. I'll try again later
<jdong> sebner: seems like you need to sleep with a debian-installer/ubiquity developer ;-)
<jdong> sebner: and possibly a GRUB2 dev too
<sebner> jdong: heh, grub2 ubuntu-dev as fedora and suse already support that stuff. We could pull the patch from there
<jdong> sebner: wait where'd this patch come from??
<jdong> I've been keeping my eye on the associated debian bug and no patch AFAIK
<sebner> jdong: fedora/suse?
<jdong> well I don't think fedora/suse use grub-probe for this purpose
<jdong> namely due to the multi-rooted nature of btrfs, grub-probe cannot identify the device node associated with a btrfs volume
<jdong> which causes update-grub to bork out
<jdong> a Debianism...
<sebner> jdong: it seems they are always ahead of us :P
<jdong> often true
<sebner> jdong: we are not bleeding/cutting edge enough :P
<jdong> nor is OpenSUSE.
<sebner> jdong: well, it's suse. I just mentioned it because of btrfs. No one wants suse :P
<EtienneG> does someone know if the MIT kerberos are attending UDS-L? They where at UDS Jaunty.  If they are, I would love to have a quick chat with them, got a thorny problem
<Pici> 0/64
<Fenix|work> Greetings and salutations
<Fenix|work> Any rsyslog implementers present?  I'm confused about what/where the template RSYSLOG_TraditionalFileFormat is or points to.
<Fenix|work> ok, nm found it.  Is there any reason why high-precision timestamps are turned off?
<Riddell> asac, pitti: VPN?
<cjwatson> sebner: there's a blueprint for that already, later this week
<cjwatson> sebner: there's a grub patch from fedora, but grub2 != grub and it's not trivial to forward-port. In this case the problem is that they are too far behind us :P
<cjwatson> sebner: they kind of tossed it over the wall to grub-devel, but haven't volunteered to do the forward-port
<cjwatson> jdong: http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00381.html and thread
<sebner> cjwatson: heh, nice you catched up as I thought of being punched to death because lucid will be LTS :)
<ajmitch> sebner: why did you anticipate a violent death?
<cjwatson> no, I'd like to support btrfs. I certainly don't think it should be the default though
<ajmitch> I don't think lucid will quite be 'no new features', just sane defaults
<sebner> cjwatson: oh well, not even myself considers btrfs "defaultable" ;)
<ajmitch> jdong might :)
<sebner> cjwatson: I was speaking about fedora12 btw, still wondering if they have grub2 now
<cjwatson> sebner: if they have a btrfs patch for grub2, they have not seen fit to contribute it upstream, and upstream is to the best of my knowledge unaware of it
<sebner> cjwatson: ah right and so opensuse sticks to grub too. HAHA ubuntu ftw!
<jdong> lol never said I want to default to btrfs
<jdong> it'd just be nice to make it an available option in the installer
<ebroder> Blargh. Did bug #483813 get filed correctly? requestsync errored out in the middle - I didn't realize it had even filed the bug
<sebner> jdong: to me it's the same :P
<ubottu> Launchpad bug 483813 in schroot "Sync schroot 1.3.1-1 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/483813
<jdong> aren't there supposed to be diffstats and such attached to requestsyncs?
<cjwatson> jdong: as an archive admin I wouldn't look at them ... :)
<ajmitch> I don't think I've ever seen or attached diffstats
 * sebner too
<ajmitch> it's more relevant for SRUs & fixes close to release
<jdong> it might be freeze exceptions then :)
<sebner> anyways
<ebroder> I've certainly never seen requestsync attach debdiffs
 * sebner wishes a good night everybody! :)
<ajmitch> night sebner
<jdong> lol at this stage in Lucid I'd expect it to be big-rubber-stamp protocol anyway ;-)
<ebroder> Anyway, just wanted to make sure the bug was in place right (not that I'd object to somebody looking at it :-P)
 * jdong hands ebroder the subtle bugprod award of the day.
<ebroder> *shrug* Or I could wait a week and a half, at which point hopefully I'd be able to ACK it myself
<directhex> when was the last autosync run? i'm still not seeing things that have been in squeeze since pre-karmic-release
<StevenK> directhex: It's run by hand. I'll run one soonish
<ajmitch> StevenK: does the autosync pick up packages from contrib/non-free?
<StevenK> ajmitch: It can, not in the same run
<slangasek> TheMuso: when you have a chance, I would like to talk with you about the brltty package's init script
<forscher> which channel could I ask for udev and eventX ?
<bdrung_> does ubuntu accepts 3.0 (quilt) source package uploads?
<RAOF> bdrung_: No(t yet)
<bdrung_> RAOF: how long do we need to wait? will it be ready for lucid?
<ajmitch> probably until the next LP rollout, ask wgrant about it
<RAOF> Launchpad hasn't quite grown support for the new source package formats, but wgrant (IIRC) is working on it.  My remembarance is that it should be ready soonish, before Lucid certainly.
<bdrung_> thanks.
<wgrant> bdrung_, ajmitch, RAOF: It should be supported on 2009-12-05 (LP 3.1.11)
<bdrung_> wgrant: thx
<rgreening> NCommander: ping
<NCommander> rgreening, pong?
<rgreening> you available to come to vinoy
<rgreening> we have an armel
<rgreening> need som advice/help :)
<rgreening> me and Riddell
<NCommander> rgreening, I saw it earlier, didn't I?
<rgreening> dunno
<rgreening> but can you pop over
<rgreening> NCommander: nope, its a different one
<NCommander> rgreening, neat, I'll be there as son as I'm done here
<rgreening> k
<pitti> Riddell: sorry, had a session right now which I draft
<elopss>  why/where/how is the kernel inserting mount options that mount(2) isnt sending it?   (according to both behaviour, and /proc/mounts)
<elopss> well /proc/mounts shows mount options that were not provided by mount().  what is the cause of this?
<elopss> relatime is the option that's showing up on all my mounts that i want to get rid of
<elopss>  and, it didnt do this until i upgraded to 9.10
<elopss> but i'm also using kernel .32rc  which might have something to do with it
<elopss> anyone?
<elopss> the he strictatime  works for some mount commands, but mount.nfs doesnt pass it to mount()   ..  i could write a call to do it, but why the relatime is in there in the first place boggles me.
<elopss> hmm?
#ubuntu-devel 2009-11-17
<elopss> i really NEED help here
<elopss> :(
<NCommander> rgreening, where is that room?
<rgreening> 3rd floor
<rgreening> vinoy
<elopss> can anyone advise?
<elopss> norelatime doesnt get passed to the kernel, it just cancels out any relatime in the mount command
<micahg> pitti: what's the best way to talk to you about a blueprint you updated today?
<nixternal> micahg: the way you just did :)
<nixternal> right about now pitti is prolly in the pub
<micahg> ah
<nixternal> if he is in dallas of course
 * micahg tried to shout in the URS IRC channel, but no one saw me :)
<nixternal> micahg: when you do that, there is a person in the channel named after the room everyone is in..... make sure you highlight that person when sending something to the channel you want them to see, so it highlights up on the projectors
<nixternal> ie.  if the room is vinoy, then do:      vinoy: foo is bar, and 2+2=5
<micahg> ah, thanks, that's good to know
<micahg> that should come in handy tomorrow when I join another chat
<elopss> i just wrote my own mounter to pass strictatime, that works.. (mount.nfs wont pass it to the kernel)
<directhex> where is dependency info for upstart jobs specified?
<dtchen_> per-job, if I understand your question correctly.
<dtchen_> (i.e., /etc/init/foo.conf)
<directhex> dtchen_, i think there's a race condition between mythtv-backend, and disks being mounted. hence wanting to check into it
<jdong> lol they're not really "dependencies" </nitpick>
<directhex> mmmmmm, yes, if i understand this shonkiness correctly... mountall.conf emits the "local-filesystems"... um... trigger? (dunno the terminology). except mountall.conf daemonises the mountall command, so i see no way to guarantee that local filesystems are actually mounted by the time the next upstart script is used
<dtchen_> directhex: missing /var/run/mythtv or something?
<dtchen_> directhex: at least it looks like mythtv-backend.upstart is missing a pre-start script stanza
<directhex> dtchen_, by the looks of it, if your recordings dir is on an unmounted disk, then it'll all go fubar. in this case, prevent mounting of my lvm volume
<dtchen_> directhex: ok, so /var/lib/mythtv, I presume?
<dtchen_> I'm not familiar with the program(s); I'm just looking at 9.10's source package
<directhex> dtchen_, i have a custom dir on a distinct partition. that's certainly the default, though
<dtchen_> might need to make mythtv-backend wait for all-filesystems
<directhex> having spent an hour and a half fighting to get my home server booting again, i feel i should go to bed
<\sh> moins
<Laney> hiya
<edeca> Does anybody know what file the GUI updater is looking for on a mirror in order to show the "a new version is available"?  I debmirror the entire repository but my uers never get that message.
<edeca> (Manual updating by editing sources.list works fine)
<tsimpson> edeca: looks like it uses http://changelogs.ubuntu.com/meta-release and http://changelogs.ubuntu.com/meta-release-lts
<tsimpson> from /etc/update-manager/meta-release
<edeca> Thank you.  That's not allowed through the proxy, which will obviously make a difference.
<edeca> I shall fix that and see.
<edeca> Does update-manager use the proxy settings that Gnome does?  Because that shouldn't have failed if so.
<edeca> But anyhow.
<maxb> Hi, I need some advice. I'd like to request sponsorship for a merge of Subversion, but I have noticed that the Debian armel build has failed with a testsuite error. Does that mean I shouldn't ask for the merge?
<emgent> \sh: moin moin!
<\sh> hey ema
<\sh> aeh emgent
<emgent> how goes? :)
<\sh> emgent, good <-----> bad somewhere in between ;)
<emgent> hehe ;)
<\sh> emgent, just working on fai 3.3.x for karmic and lucid
<ashiswin> umm
<ashiswin> hello
<ashiswin> does anyone here know how to do OS development?
<yofel> ashiswin: define OS -> operating system / open source / ... ?
<ashiswin> operating system
<ashiswin> so does anyone know how to do operating system development?
<directhex> ashiswin, plenty of people, but you need to better define your scope. an operating system combines many components, and depending on whom you talk to, could cover any number of products and projects
<ashiswin> umm
<ashiswin> ok
<ashiswin> what about
<ashiswin> who knows how to make an OS Kernel that can print stuff to the screen
<siretart`> try looking at lecture notes from universities that offer courses for operating systems
<directhex> yeah, a simple kernel is a first-year course now on the degree i did
<directhex> (it wasn't when i did it, mind you, we had to write our own malloc instead)
<siretart`> that's fun as well :-)
<ashiswin> so does anyone know?
<onaogh> hi, can someone tell me which book is good if someone wants to start programming in linux environment
<onaogh> and where i can find linux api reference
<jussi01> onaogh: you are a programmer already?
<pitti> Good morning
<pitti> nixternal: Dallas> I am :) I just suck at being on IRC this week
<nixternal> I don't blame ya, better things to do than sit on IRC :)
<nixternal> dholbach: is there a techboard round table going on?
<dholbach> nixternal: I have no idea
<dholbach> nixternal: I'm in the community track roundtable
<nixternal> ok, I heard ScottK say something in the waverly room about it, and the kubuntu devs have a bullet point in the round table if I understood him correctly
<nixternal> if you aren't in it, then I am guessing it isn't going on now
<Daviey> nixternal: i believe it is on right now
<nixternal> nice of them to put it on the schedule
 * nixternal looks for a gobby document
<Riddelll> nixternal: techboard is http://icecast.ubuntu.com:8000/alamo2.ogg.m3u
<Riddelll> do listen in and let us know if they start discussing us
<nixternal> lovely!
<nixternal> Riddelll: ok
<nixternal> dholbach, soren ^^ there is one going on
<soren> nixternal: WEll, yeah, there's a /session/.
<Daviey> vlc alamo2.ogg.m3u ; sphinx /dev/snd/* | grep kubuntu
<nixternal> shush
<soren> nixternal: I asked about a /track/ :)
<nixternal> hehe
<soren> Err... /You/ asked about a track.
<soren> :)
<ebroder> pitti: Did bug #330766 regress in Lucid?
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Undecided,Fix released] https://launchpad.net/bugs/330766
<Fenix|work> Greetings and salutations.
<Fenix|work> I would like to ask a question about a config before filing a 'bug' on launchpad.
<edeca> So ask.
<Fenix|work> Apart from bug 459730 with rsyslog and the package not creating /dev/xconsole, would it be considered a bug that Ubuntu server's default rsyslog config tries to log to /dev/xconsole considering X isn't installed as base?
<ubottu> Launchpad bug 459730 in rsyslog "rsyslog doesn't create /dev/xconsole " [Undecided,Confirmed] https://launchpad.net/bugs/459730
<ebroder> xconsole isn't for X
<ebroder> It's just poorly named
<Fenix|work> ebroder, when I try to run xconsole, I'm hinted to install x11-apps
<Fenix|work> man xconsole (1) :: xconsole - monitor system console messages with X
<Fenix|work> unless you're talking about the block file...
<ebroder> Right
<ebroder> My recollection is that /dev/xconsole predates xconsole(1)
<Fenix|work> perhaps, but the comments in the config file state that /dev/xconsole is for use with the xconsole utility.  That's why I asked if by default on server it should be turned on.
<Fenix|work> is there any need to use this FIFO file, or any downside?
<cRUDE> fingerprint?
<cRUDE> hi room: when do we see fingerprint id working?
<davidboy> I'm wanting to run the software center from source.  I downloaded the source code from launchpad using bazzar, now which file should I run?  software-center, app.py, or something else?
<beuno> davidboy, my guess would be software-center
<davidboy> beuno: Thanks!  That works!
<MacSlow> pitti, I did save the gobby notes for this session
<StevenK> MacSlow: \o/
<MacSlow> pitti, want then as email?
<TheMuso> za/c
<Fenix|work> A quick question.  Is it safe to modify /etc/rsyslog.d/50-default.conf, or does it change with updates?
<Laney> you can modify anything in /etc
<jdong> Fenix|work: when dpkg attempts to update a file in /etc that you've modified, you'll be prompted about the conflict.
<jdong> so yes, it's generally safe to edit things in /etc
<Fenix|work> jdong, k, thx
<snnw> Amaranth: ping
<slangasek> Keybuk: bug #484386 has an untested patch to dkms that you may want to give a try for boot performance
<ubottu> Launchpad bug 484386 in dkms "optimize the dkms init script to be less greedy at boot time" [Undecided,New] https://launchpad.net/bugs/484386
<Keybuk> sweet
<Keybuk> stgraber: could you stop the Ubuntu QA Website tagging every single bug in Launchpad
<Keybuk> please?
 * Keybuk watches the mail storm
<jdong> lol that's 30% of my lp bugmail today
<jpds> Keybuk: http://paste.ubuntu.com/321056/
<Keybuk> jpds: SHIT KEEPS GETTING TAGGED!
<jpds> Keybuk: Falling, getting tagged, make up your mind!
<stgraber> Keybuk: sorry for the flood, I just "fixed" the script that should have done that as bugs were added to the QA website since the last release, so pretty much all bugs reported on the ISO tracker for karmic just got tagged
<jdong> do we get flooded with untagging too?
<jdong> (haha half-kidding)
 * ajmitch searches for all bugs with jdong subscribed to go on a tagging spree
<jdong> oh I could just ignore LP bugmail then ;-)
<jdong> since it seems like I get IRC notifications of important bug reports anyway ;-)
<Amaranth> snnw: pong
<snnw> Amaranth: Hi again:) Can I PM you about Alacarte?
<Amaranth> If you've been looking in the code recently you probably know more about it than me but sure
<Keybuk> slangasek: I have a bootchart without the hdparm now
<Keybuk> that's 1s better
<Keybuk> one down, 14 to go!
<StevenK> Keybuk: Seconds, or calls to hdparm?
<Keybuk> seconds
<ion> Nice
#ubuntu-devel 2009-11-18
<jdong> kees / pitti: Now this is an interesting one....
<jdong> btrfs snapshots can bypass AppArmor restrictions
<jdong> i.e. log into a GDM guest account
<jdong> cd /tmp
<jdong> btrfs -s test /
<jdong> btrfsctl, rather
<jdong> now, /tmp/test provides a apparmor-unrestricted look into /
 * Laibsch would like to ask for input on how to progress with bug 420918
<ubottu> Launchpad bug 420918 in isdnutils "please update libcapi" [Wishlist,New] https://launchpad.net/bugs/420918
<bluefoxicy> so, for the past month or so Ubuntu has been running without cutting over 50% of my ram
<bluefoxicy> usually I'm 4 gigs deep and about a gig into swap.
<bluefoxicy> What did you guys do?
<highvoltage> bluefoxicy: heh, I keep running into users who say things like "I'm running Ubuntu 5.10 because my hardware is old so I'm running an older system that should be faster"
<bluefoxicy> highvoltage:  lol... well the newer versions were eating like 50 times more ram
<highvoltage> bluefoxicy: I don't know, I think they're getting more efficient
<bluefoxicy> I remember always having gimp, firefox, thunderbird, gaim, xchat, a terminal, and rhythmbox running, and needing 512M because I'd be 400MB into RAM all the time
<highvoltage> bluefoxicy: gnome-terminal uses much less memory per tab than it used to, and so does firefox and openoffice
<bluefoxicy> now I don't have gimp open like ever, yet I was always burried 4 gigs deep
<bluefoxicy> and now, about 2 gigs, with very little used as system cache
<highvoltage> bluefoxicy: my main desktop has 5GB RAM and for normal use I don't ever go above 1.5GB
<bluefoxicy> I mean, it would make sense if half my ram was ate by cache and buffers; unfortunately it was more like 20 megs went to disk cache
<highvoltage> ever/much :)
<bluefoxicy> and the rest was all resident program memory
<bluefoxicy> highvoltage:  yeah, mine's doing that now, I'm trying to figure why.
<bluefoxicy> gnome-terminal isn't being crazy huh.  Firefox seems to have huge RAM usage and it gets laggy (if I type I have to wait 1 second between each letter appearing,and the whole program freezes until it's caught up to me)
<bluefoxicy> restarting firefox fixes that for a couple hours though.
<highvoltage> bluefoxicy: yeah I had that too :(
<highvoltage> bluefoxicy: I've switched to chromium now and it's way faster than firefox and it doesn't do that laggy thing
<bluefoxicy> it's a bug in xulrunner
<bluefoxicy> thunderbird does it  too.
<pitti> jdong: ugh, interesting; this sounds very much related to apparmor's inability to work with aufs, too; it only seems to work on "real iron" file systems
<pitti> jdong: could you please file this as an apparmor bug?
<jdong> sure thing
<jdong> seeing that btrfs seems close to being around the corner... it'd be good to get this on the radar screen
<jdong> it is somewhat "surprising" behavior that the snapshotting ioctl is accessible by unprivileged users
<pitti> that, too; I guess it expects file system permissions to be respected
<jdong> *nods* indeed
<jdong> given that it's not a terribly expensive operation and UNIX DAC wise doesn't elevate any access... I suppose in that way it's "safe"
<pitti> which is not really unreasonable, of course
<jdong> indeed
<jdong> pitti: ok, filed as bug 484786
<ubottu> Launchpad bug 484786 in apparmor "Too easy to circumvent AppArmor using btrfs snapshots" [Undecided,New] https://launchpad.net/bugs/484786
<robbiew> slangasek: the dkms issue was related to VirtualBox.... vboxdrv (3.0.8) failing to build...forgot I had VirtualBox installed :/
<robbiew> so not THAT big of a deal right now
<robbiew> Keybuk: shouldn't a dkms build failure be reported to the users during boot?
<Keybuk> robbiew: no, but apport could popup after login
<robbiew> right...sorry...that's what I meant
<davidboy> Is it possible to download Lucid before Alpha 1?
<smoser> soren, is there a general "vmbuilder improvements" session? or one that i missed.
<maco> soren: wouln't it make sense to add lucid to karmic's ubuntu-vm-builder "suite" option so that karmic users can test it in a vm without having to do it as a karmic vm then do-release-upgrade?
<maco> is that SRUable or would it require backports or...?
<ebroder> Isn't there usually an SRU for debootstrap?
<ebroder> Hmm...I guess it's always done as a backport
<Riddell> asac: will you do the spec for desktop-lucid-firefox-kde-integration or shall I?
<kirkland> Keybuk: okay, you're not the only one http://ubuntuforums.org/showthread.php?t=1267224
<jdong> heh in general, how do you in Linux tell ACPI to keep a PCI device on during suspend?
<jdong> Windows device manager has a per-device checkbox for doing that
<jdong> I'm assuming that translates to some sort of ACPI voodoo
<a6> hello
<a6> help me thanks
<a6> http://paste.ubuntu-fr-secours.org/plain-44908
<a6> many people have concernerd
<mneptok> a6: have you filed a bug regarding this issue on Launchpad?
<a6> NO
<mneptok> svp
<a6> ok
<mneptok> merci bien
<superm1_> pitti, are you available right now, or hiding busy in a session?
<Keybuk> mpt: my favourite thing
<Keybuk> "[icon] There are wireless networks available.  Click this icon to see them"
<mpt> I like you too, Keybuk
<Keybuk> floating in the middle of the screen
<mpt> oh
<Keybuk> if I try and click the icon, it hides on me
<Keybuk> and there's no other copy of that icon anywhere else on my computer
<mpt> hm, missing patch in nm-applet
<Keybuk> surely it should just popup the window with the wireless networks
<Keybuk> update-manager style?
<mpt> that would make sense
<mpt> there doesn't seem to be a bug report on this
<Keybuk> I was going to tweet about it instead
<mpt> On the grounds that if people whine long enough about us using a proprietary bug tracker, Twitter will eventually be open-sourced?
<mpt> Keybuk, did you happen to grab a screenshot? I haven't seen that myself so I'm uncomfortable reporting it
<Keybuk> mpt: make it forget ibahn and ubuntu
<Keybuk> then toggle your wireless off and on again
<jdong> why was it decided that notify bubbles act like the ghost characters in nintendo video games??
<ebroder> Haha
<jdong> lol
<jdong> that's the best metaphor I can come up with for them!
<jdong> and just like those things, it's frustrating figuring out how to get rid of them.
<jdong> I haven't figured out how to bounce eggs off the sides of the display yet :(
<mpt> Keybuk, ok, I'll try that in a bit, thanks
 * mpt is momentarily distracted by reporting bugs about Launchpad itself
<TheMuso> c
<Laney> defghijklmnopqrstuvwxyz
<chrisccoulson> hello Laney!
<Laney> greetings sir!
<Laney> any sign of $baby yet?
<chrisccoulson> she arrived yesterday :)
<Laney> oh wow, congratulations
<TheMuso> chrisccoulson: Congratulations.
<chrisccoulson> thanks:)
<chrisccoulson> i had a very short day at work yesterday!
<Laney> now the real fun begins
<chrisccoulson> yeah! although, they're still both in hospital at the moment
<chrisccoulson> so i have another night of peace ;)
<lfuser-741> hello anyone there ?
<Laney> hah, you better savour it :)
<Laney> Good job you didn't go to Texas then eh?
<lfuser-741> hey - can anyone help me ? I am newbie
<chrisccoulson> yeah, it's a good job i'm not there
<ajmitch> chrisccoulson: congratulations
<chrisccoulson> ajmitch - thanks:)
<chrisccoulson> and thanks TheMuso too
<lfuser-741> looks like everyine is busy in there own world - no chance of any help here
<chrisccoulson> lfuser-741 - you want #ubuntu for support
<lfuser-741> thanks chris for your reply - yes - need a little bit help
<Laney> bed time anyway
<Laney> goodnight all
<chrisccoulson> 'night Laney
<ebroder> lfuser-741: It's generally considered bad etiquette in IRC to ask permission to ask your question, But this is still the wrong channel
<maxb> james_w: Hi, do you have a moment to talk about a tricky UDD merge?
<james_w> maxb: I'm almost out of battery, so have just a few minutes
<lfuser-741> ok = chris - my first time in this forum - can your please guide me to the write forum where some one may be able to help me ?
<maxb> james_w: ok, I'll keep it short: are there known problems when uploads to experimental are involved
<maxb> ?
<james_w> no known issues
<james_w> doesn't mean there aren't any, what are you seeing?
<lfuser-741> ebroder - which channel should I go for any help ?
<ebroder> lfuser-741: #ubuntu. This is #ubuntu-devel. Go to #ubuntu
<lfuser-741> ok - thanks ebroder - will head that way. your guidance much appreciated
<Lindows> hope this is he right channel finally =)
<maxb> james_w: After a merge from experimental->karmic, the subsequent upload to karmic which was a merge from unstable didn't have ancestry recorded as such.
<Lindows> I just ran a md5sum comparing a backup of a windowsXP virtual image (30GB+, ext3) against what it wrote to my local drive (ext4) and the md5sums don't match...
<maxb> This resulted in hilarity like "bzr merge-package" attempting to re-merge already-included changes, and all the file-id mess in the world
<Lindows> is there a patch coming?
<maxb> james_w: Ok, since there are no outstanding issues for you to point me to, I shall chronicle the mess to ubuntu-distributed-devel@
<jdong> Lindows: I think that's a known bug.
<Lindows> is there a patch coming?
<jdong> bug 453579 I believe is the right one
<ubottu> Launchpad bug 453579 in ubuntu-release-notes "in-place corruption of large files *without fsck or reboot* reported with linux 2.6.31-14.46 on ext4" [Undecided,Fix released] https://launchpad.net/bugs/453579
<maxb> james_w: Oh, one last question - if an import has wrong history, is the preferred approach to do some fixup commits, or is binning the existing branch an re-importing an option?
<jdong> Lindows: to be honest I don't think anyone actually knows what the real cause of it is.
<Lindows> okay, a better question, is it coming soon enough that I can wait it out or should I reinstall the OS using ext3 because it'll be a month or more?
<jdong> the Karmic release notes did mention this bug...
<Lindows> okay...hrm
<jdong> it appears to be rare and only dealing with large files
<jdong> so yeah, for the time being if you do a lot of work with large files, good idea to not use ext4 :-/
<james_w> maxb: Thanks, mail is the best way, thanks for investigating. As for wrong history, I'd have to think about it
<jdong> my personal opinion is that XFS is one of the best behaving filesystems to put VM images on
<james_w> pointers to such branches on the mailing list appreciated
<Lindows> well, I mean, definate "a lot", any video game file is > 512MB
<jdong> but others will certainly disagree :)
<jdong> Lindows: yeah that's one of the problems.
<Lindows> define*
<maxb> james_w: Actually I guess, to make this work, you'd have to replace history in sid branch too, so I guess a history rewrite would be ... complex and unwelcome.
<jdong> nobody really knows what "big" actually means :)
<jdong> it's one of those magical mystery voodoo bugs.
<Lindows> well, crap
<Lindows> guess I'm reinstalling
<jdong> yeah sorry about your luck...
<slangasek> Lindows: the original bug reporter says there's a patch which fixes it; I'm going to try to escalate that to the next kernel SRU
<Lindows> awesome, thank you
<jdong> and I hope the said patch will fix it :)
<slangasek> (so that I can stop getting lots of useless and irrelevant bug mail from people who have *none of the relevant symptoms*)
<jdong> slangasek: yeah I think I hit the reset button yesterday and..
<jdong> *HIDES*
<slangasek> jdong: Keybuk has already reported that it *does* fix it on his system; and almost no one else has actually reproduced it reliably
<jdong> cool
<slangasek> jdong: so are you here?
<jdong> the most amusing part about that bug was the comment someone made about iterative md5summing "converging" on some value :)
<jdong> slangasek: sadly I am not :(
<jdong> as much as I'd love to be there right now, schoolwork requires me to stay planted.
<Lindows> I guess I'll wait it out then, whenever the patch hits I can easily test it
<Lindows> the update
<Lindows> thank you for all your help
<slangasek> jdong: doh
<ebroder> Yeah, it turns out that the UDS scheduling is really crappy for students
<ebroder> Because November and April are always OH CRAP CRUNCH TIME months
<ebroder> Err, I guess it's November and May. May being worse, of course
<jdong> heh indeed
<jdong> hell even the one that was on MIT, I literally could not find the time to go to
<slangasek> jdong: solution: stop studying, join the Free Software career track
<slangasek> ;)
<jdong> hahaha :)
<chrisccoulson> jdong - what are you studying?
<jdong> chrisccoulson: Electrical Engineering and Computer Science :)
<chrisccoulson> jdong - i did straight electronics engineering
<ebroder> slangasek: Where were you with that advice 3 years ago when I started? Now it just doesn't seem worth the trouble :-P
<chrisccoulson> but i wish i did more of the computer science bit ;)
<jdong> chrisccoulson: cool; I personally have a slightly bitter relationship with the EE side of myself ;-)
<jdong> but it exists enough that I don't want to ignore it completely.
<chrisccoulson> jdong - me too. i really enjoyed studying it, but i absolutely hate working in electronics
<jdong> the electric machines (i.e. motors / electromagnetics) and control systems side of me does manifest itself from time to time....
<jdong> but yeah by far I prefer to be on the CS and software engineering sides of things
<jdong> maybe because there's less ways to set the room on fire ;-)
<chrisccoulson> oh, i enjoy setting the room on fire, but there's not much chance of doing that in my job
<chrisccoulson> i definately wish i'd done software instead!
 * ajmitch thought that setting the room on fire was one of the perks
<chrisccoulson> ajmitch - i thought that too ;)
<donpdonp> what .h file declares DBUS_BUS_ACTIVATION ? i have various dbus -dev packages installed but "grep -r DBUS_BUS_ACTIVATION /usr/include/dbus-1.0/" turns up nothing.
<jdong> ajmitch: if it's a "don't ask don't tell" fire, I'm all for that!
<chrisccoulson> perhaps if i worked on something which wasn't safety critical, then there'd be more chance of fire :)
#ubuntu-devel 2009-11-19
<dtchen_> are the irc channels for UDS logged?
<dtchen_> err, the room-specific irc channels
<ScottK> dtchen_: I have a complete backscroll for all of them if there's something you want.
<tsimpson> dtchen_: http://ubottu.com/uds-logs
<dtchen_> tsimpson: / ScottK: thanks
<dtchen_> bah, 20091116 seems missing for alamo2
<tsimpson> times are UTC+2, and UDS is UTC-6 I think
<tsimpson> hmm, actually some of it does seem to be missing
<tsimpson> oh well, someone has logs I'm sure
<dtchen_> ok, gobby it is, then
<tsimpson> I remember now, we just didn't start logging until half-way through the first day
<tsimpson> no one had thought to get some logging before then
<tsimpson> so it was a bit of a scramble to get it up
<dtchen_> l
<ScottK> Let me look if I have it.
<ScottK> dtchen_: I have that day.  What time do you want?
<dtchen_> ScottK: 1200-1300
<maxb> james_w: Is there any reason why the udd task on https://bugs.edge.launchpad.net/udd/+bug/248447 should remain open?
<ubottu> Launchpad bug 248447 in bzr-builddeb "Doesn't handle invalid version numbers" [High,Fix released]
<maxb> or https://bugs.edge.launchpad.net/udd/+bug/91579 for that matter
<ubottu> Launchpad bug 91579 in udd "associate branch with source package" [High,Confirmed]
<dtchen_> pitti: hi, do you know of any changes in karmic-proposed's udev that might cause bug #424655?
<ubottu> Launchpad bug 424655 in pulseaudio "Pulse audio memory leak" [Undecided,Confirmed] https://launchpad.net/bugs/424655
<dtchen_> s/proposed/updates/
<pitti> dtchen_: well, obviously I cannot rule out weird toolchain changes, but the actual code changes just fix an fd leak and an eternal loop in inotify handling (which doesn't actually affect the .deb by sheer luck, just when you build with -O0)
<pitti> dtchen_: IOW, it added a missing closedir() and fixed a variable type; no memory allocation changes at all
<pitti> ah, in comment 43?
<pitti> dtchen_: so, one potential explanation would be that said fd leak made udev completely stop recognizing new hardware on a lot of systems
<pitti> so the fix might uncover another leak by adding/probing sound hw which previously didn't appear in udev (since it simply stopped working because of exceeding the 1024 fd limit)
<dtchen_> pitti: hmm, right.
 * pitti asks on bug report
<micahg> pitti: can I talk to you about a blueprint?
<dtchen_> pitti: thanks!
<pitti> dtchen_: done
<pitti> micahg: just ask :)
<pitti> micahg: are you here @ UDS?
<micahg> no
<pitti> ok
 * pitti in need of food and beer :)
<micahg1> but I subscribed to some blueprints to keep up to date
<micahg> I was wondering about https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-bug-management
<micahg> it mentioned subscribing uploaders to bugs for a few days
<micahg> I wanted to suggest only subscribing them if apport caught their version as the one being reported on
<pitti> right; it's something that we already discussed last cycle, but didn't get to implementing
<pitti> micahg: right, it'd certainly check the package version if the bug report has it
<micahg> ok, great, didn't see that in there, so I thought I'd mention it
<ScottK> dtchen_: OK.  I should have that for you in a moment.
<ScottK> dtchen_: http://paste.ubuntu.com/322064/
<ScottK> There isn't a lot
<krisives> Hey how can I add screenshots?
<Hobbsee> to?
<krisives> Like in the Software Center when it says "No Screenshot"
<krisives> http://img5.imageshack.us/img5/6360/screenshot003fw.png
<Hobbsee> good question
 * Hobbsee only just discovered that
<krisives> It's in Synaptic too
<krisives> http://img8.imageshack.us/img8/3626/screenshot004kl.png
<krisives> http://img691.imageshack.us/img691/8924/screenshot005z.png
<Hobbsee> i have no idea
<krisives> I just don't know where the repository for that would be
<Hobbsee> mvo should know, it appears, but it's very late where they all are
<Hobbsee> mpt: should also know, it seems
<mpt> Hobbsee, http://screenshots.ubuntu.com/
<Hobbsee> ah!
<Hobbsee> i was looking for something like that
<Hobbsee> that's very cool :)
<krisives> mpt: THANK YOU! :D::D:D:D:D:D:
<mpt> O_o
<mpt> You're welcome
<dtchen_> ScottK: thanks!
<dtchen_> maco: not all quirk lookups are via PCI SSIDs; some broken hardware requires the codec SSID
<dtchen_> (I have a blog post half-written explaining all this mess)
<ScottK> Hobbsee: The screenshots are from screenshots.debian.org (or net, I'm not sure)
<ScottK> Ah, read the whole backlog first.
<Hobbsee> ScottK: cheers :)
 * ScottK waves back to Hobbsee.
* spm changed the topic of #ubuntu-devel to: LP Codehosting off for H/W update 0800-1200 UTC | Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM up to date as of Monday 4am, but now stalled | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.
<Lindows> so, okay, I need a sanity check...
<Lindows> I first installed kubuntu 9.10 x64 with ext4
<Lindows> I ran md5sum of a windowsXP virtual image, one stored on a samba share in ext3
<Lindows> against the local copy in ext4, the checksums didn't match
<Lindows> repeated the experiment after reinstalling kubuntu using ext3 instead.....the checksums also don't match
<Lindows> maybe I don't understand md5sum?
<Lindows> I thought it was deterministic
<engla> DktrKranz: ciao; don't package kupfer c18 yet, there will be a small release for bugfixes
<engla> DktrKranz: otherwise, upstream gap closing going well, c18 will install into $DATADIR
<DktrKranz> engla: sure thing
<DktrKranz> and thanks for addressing my boring attitudes :)
<engla> everything makes so much sense now. $DATADIR is fantastic :-)
<engla> the idea to use it, that is
* mthaddon changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM up to date as of Monday 4am, but now stalled | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.
<Hiram> Hi all. I'm trying to roll a .deb package for Snort 2.8.5.1. It all goes well, but it's not including the snort config files. could anyone help me out with this?
<LucidFox> Short config files?
<Hiram> they can be.
<Hiram> they're pretty well commented, but i could cut them down.
<Chipzz> Hiram: #ubuntu-motu pls
<Chipzz> Hiram: also, debian has a package for snort - why are you creating your own?
<Hiram> Chipzz: because i need a package for 2.8.5.1, the one that's out now is only 2.8.4.1
<philsf> In Jaunty I used to set my keyboard settings in /etc/default/console-setup, but it's being ignored now in Karmic, both for console and X. I need to use setxkbmap everytime I login and also everytime I switch to the console. How can I set my keyboard variant permanently now?
<philsf> sorry for asking here, but I already tried in #ubuntu, and #ubuntu-x
<maco> dtchen_: i only know how much youve explained so far. pleeeeeeeeeease finish that blog post so i can learn more ;-)
<soren> maco: Definitely.
<maco> soren: re vmbuilder?
<soren> maco: Oui, oui.
<_follower_> hi, if a tty has a pending newline and then fills the input buffer it no longer responds to ^C etc or bells.   this seems to be a pervasive "issue" across multiple OS, but I'm not sure if it's considered "correct behaviour" or not. possibly relevant code is 'n_tty_receive_room' in 'n_tty.c' and http://lwn.net/Articles/123724/ suggests that at least some of the code is considered suspect. is there a better place than here to mention this? :) if i
<_follower_> considered a bug then I can file something, but i wasn't sure if it was just considered expected behaviour--even though it ends up leaving a terminal which you can't do anything with unless you kill the program. to test you can do e.g. perl -e "sleep 1000".
<_follower_> hmmm, apparently the relevant code might now be around " n_tty_set_room"
<vadi2> Will there ever be a  public response from Ubuntu Developers to the PulseAudio failfest and people dumping Ubuntu because of it failing so much?
<vadi2> http://tycheent.wordpress.com/2009/11/18/pulseaudio-revisited#comments is just sad to read.
<soreau> Hello folks
<soreau> I am having trouble assisting a user in #compiz because he is trying to get the fire effect working but /usr/lib/compiz/libanimationaddon.so does not exist. So I had him do 'sudo aptitude remove --purge compiz-fusion-plugins-extra && sudo aptitude install compiz-fusion-plugins-extra' but the file still does not exist. It is a 64bit jaunty install. Why is this file not being installed?
<couannette> hi
<soreau> I can not come up with any conceivable scenario where this could happen and I am out of ideas. Might anyone know how this could be possible?
<couannette> is it possible to use 'germinate' to merge two archives or two configurations ?
<micahg> soreau: according to packages.ubuntu.com, it's in there
<soreau> micahg: I know that, that's is why I am completely baffled
<soreau> Here is the output of his 'dpkg -l | grep compiz' http://pastebin.ca/1677983
<soreau> and the output of the re-installation command I gave him: http://pastebin.ca/1677973
<soreau> Other than having him install the file manually, I don't know what else to do
<soreau> more than anything, I want to know how this can possibly happen. Because when I tell a user to reinstall a package, I expect it to restore/replace/populate all files contained in the package
<cragdor> Hi all, who is the best person to talk to about the development of UbuntuOneMusic store
<StevenK> soreau: He is using another source in his sources.list that has a greater version than in Jaunty, and it doesn't provide that library?
<soreau> StevenK: Even on Karmic, the package and file name situation is the same but I will investigate this possibility
<StevenK> soreau: apt-cache policy will help determine that
<soreau> StevenK: I had him output this
<soreau> StevenK: http://pastebin.ca/1677938
<soreau> I have to run, but I will bbi~45
<soreau> I will remain logged in here
<soreau> any other suggestions appreciated
<StevenK> That's -main, not -extra
<micahg> soreau: according to your first pastebin, the version is not from the archive
<micahg> http://pastebin.ca/1677973
<jdong> dammit...
<jdong> I lost my build system
 * jdong waits for 60 minute dyndns timeout
<jdong> it is generally bad (intra)netiquette to try your SSH pubkey against a /16 subnet, right? ;-)
<ebroder> jdong: Did you upload bug #463429, or should I subscribe sponsors?
<ubottu> Launchpad bug 463429 in openafs "[Jaunty, Karmic SRU] openafs-modules-dkms' postinst fails repeatedly when headers missing" [Undecided,Fix released] https://launchpad.net/bugs/463429
<pecisk> GIMP will be gone in Lucid default, true?
<StevenK> What gives you that idea?
<pecisk> StevenK, Slashdot as always http://linux.slashdot.org/article.pl?sid=09/11/19/1342230
<StevenK> But that requires reading Slashdot
<tgpraveen1> it is true
<soreau> micahg: Thanks for pointing that out, I didn't notice it said ppa
<tgpraveen1> pittivi is going to be included
<pecisk> rocks
<tgpraveen1> probably
<pecisk> it is not said that dropping GIMP from default isn't smart - true, most of people won't use it
<pecisk> I just hope it stays in main :)
<ebroder> jdong: Oh, also, could you accept the jaunty/karmic milestones for bug #463429?
<ubottu> Launchpad bug 463429 in openafs "[Jaunty, Karmic SRU] openafs-modules-dkms' postinst fails repeatedly when headers missing" [Undecided,Fix released] https://launchpad.net/bugs/463429
<soreau> Thanks for the help too StevenK
<soreau> So if it says http://ppa.launchpad.net jaunty/main Packages and not http://ppa.launchpad.net jaunty/main Packages this means it's a ppa repo and not official packages
<soreau> err...
<soreau> paste fail
<soreau> So if it says http://ppa.launchpad.net jaunty/main Packages and not http://us.archive.ubuntu.com jaunty/main Packages Packages this means it's a ppa repo and not official packages
<StevenK> soreau: That's correct -- it's from a PPA, not the archive
<pkern> Riddell: Seriously?  https://bugs.launchpad.net/ubuntu/+source/gobby/+bug/485408 breaking all translations?
<ubottu> Launchpad bug 485408 in gobby "en_US users see en_UK spellings" [Undecided,Fix released]
<pkern> Riddell: IMHO you cannot assume that C is en_US albeit it might be common.  And I even NACKed this change with a reason to the bug log.  I don't see the point in opening a bug if one uploads anyway.
<tjaalton> is the devel subscription of lwn still available?
<ajmitch> I believe so, there's an ubuntu members group for it
<ajmitch> https://wiki.ubuntu.com/Membership/LWN has the details
<tjaalton> ah, so the contact person has changed.. thanks
<Keybuk> what is the .ssh/known_hosts file hashed by?
<wamty> Ubuntu will drop GIMP?
<wamty> why?
<ebroder> Don't trust what you read on /. It's being removed from the /CDs/, not Ubuntu altogether
<ion> If itâs on Slashdot â especially Slashdot comments â it must be true.
<ebroder> Of course. What was I thinking
<wamty> ebroder: any idea why?
<wamty> the /. headings have gotten increasingly more misleading in the last few years
<ebroder> I wasn't involved in the decision, but I can only guess it's because GIMP is a crappy excuse for a UI
<wamty> ebroder: compared to what?
<wamty> btw f-spot is what the article mentioned
<ebroder> Yes, I believe that's what's being used as thh replacement
<wamty> ah
<wamty> fspot is a gimp replacement now??
<ion> For most basic users, sure. Advanced users are free to install the advanced software of their choice.
<wamty> f-spot looks like an iPhoto app, not photoshop
<ebroder> WHich is what basic users need for photo editing
<wamty> I imagine gimp must be massive otherwise it shouldn't be an issue
<wamty> especially when you include the dependancies.
<ebroder> The Live CD is tight enough on space that it doesn't have to be massive to be an issue
<wamty> whats the issue then?
#ubuntu-devel 2009-11-20
<micahg> when someone blogs about a rant, does anyone ever poke them to file bugs?
<ajmitch> yes
<micahg> or am I better off filing the bug if I think it's worth it?
<ajmitch> see dtchen's recent response there for how to fix audio bugs
<micahg> yeah, I saw that
<ajmitch> often people who want to rant don't want to put the effort in to file a useful bug
<micahg> ok
<pwnguin> micahg: although, usually it's a good idea to search yourself to see if they've already filed it before suggesting they eat their vegstables, exercise 30 minutes daily or file bug reports
<morfic> dropping gimp? seriously? (yes i joined, just to ask that, seriously ;P)
<ion> Why not? F-spot is enough for the typical userâs needs and the advanced user is free to install the advanced software of her choice.
<ebroder> Also, for crying out loud, gimp is being removed from the LIVE CD, not the distribution
<morfic> thanks for clearing that up then
<Lindows> not sure if this is the correct channel, but I mount a network drive (samba share, cifs, auto in fstab) and it appears kubuntu is attempting to mount the network drive before the network is up (or I'm even logged in).  Anyway to tell it to wait?
<Lindows> generates the error: 2009-11-19 20:07:27	anubis	kernel	[    9.323175]  CIFS VFS: Error connecting to socket. Aborting operation
<llama_> If I wanted to disassemble execv(), what library would have that with debug tags?
<pkern> glibc, but it's just a wrapper around the execve syscall I think.
<llama_> I kinda just want to see the source
<pkern> glibc then.
<llama_> and where is that, ive never dealth with libraries before.  Theres lib, lib32 and lib64 and im on a amd64 system
<llama_> dealt
<pkern> llama_: I think it's off topic in here and you might want to ask in #ubuntu.  (Hint: apt-get source libc6)
<llama_> thanks, can I ask how you learned about the libraries, they confuse me.
<ashiswin> umm
<ashiswin> hello
<ashiswin> anyone who knows OS dev please pm me
<ashiswin> urgently
<blackxored> what's the appropiate package to file a bug against the Appearance preferences, which has to do where you're using CCSM, there are no options marked in the visual effects tab, I recall that sometime ago (or maybe I'm wrong and that was in fedora), when you have customized your effects through ccsm, there is a marked option for ccsm or custom, or something like that?
<blackxored> also the indicator applet doesn't shows pidgin on my system
<blackxored> anyone?
<blackxored>  what's the appropiate package to file a bug against the Appearance preferences, which has to do where you're using CCSM, there are no options marked in the visual effects tab, I recall that sometime ago (or maybe I'm wrong and that was in fedora), when you have customized your effects through ccsm, there is a marked option for ccsm or custom, or something like that?
<blackxored> <blackxored> also the indicator applet doesn't shows pidgin on my system
<Chipzz> blackxored: not the appropriate channel. I thnk you want #ubuntu-bugs
<blackxored> Chipzz, thanks
<Chipzz> blackxored: also, if you're not getting an answer (on any channel really), may I suggest you check the topic (which you REALLY should have done before asking the question in the first place) to see if your question is on-topic instead of repeating your question?
<blackxored> Chipzz, I was unsure about the proper package, I was going to file against ubuntu-desktop but that was too generic
<zul> james_w: ping when you get a chance can you import samba please? thanks
<dalfz> after i compiled wine from apt-get source, what do i do to install it?
<unimatrix> how do i request a package to be included in the repository?
<akshaysulakhe> so many people at this time...
<NCommander> bryce, ping eric_miao is looking for you
<dariocaruso> salve ho un problema con un netbook Hp 700EL
<dariocaruso> installo i driver
<dariocaruso> ma non funziona
<dariocaruso> qualcuno puÃ² aiutarmi!?
<ebroder> !es | dariocaruso
<ubottu> dariocaruso: En la mayorÃ­a de canales Ubuntu se comunica en inglÃ©s. Para ayuda en EspaÃ±ol, por favor entre en los canales #ubuntu-es o #kubuntu-es.
<hsn> !cs
<ubottu> chanserv.py is a ChanServ helper script for !XChat | http://kaarsemaker.net/software/chanserv/
<hsn> !cz
<ubottu> ÄeskÃ© uÅ¾ivatele Å¾Ã¡dÃ¡me, aby mluvili v kanÃ¡le #ubuntu anglicky. Äesky je moÅ¾no se domluvit v #ubuntu-cz. DÄkujeme.
<ebroder> dariocaruso: Oh, I'm so sorry - I'm not sure why I thought that was Spanish. In any case, there's also an #ubuntu-it
<corp186> I'm trying to start development on the installer, but I'm having a hard time starting out
<corp186> I've asked on #ubuntu-installer, but no one's home
<corp186> has anyone here had any experience in that part?
<corp186> I'd like to know how I can build up an iso image myself
<micahg> people are probably at UDS sessions
<corp186> micahg: ahhh
<craigbass1976> Anyone know the status of this ?  https://bugs.launchpad.net/ubuntu/jaunty/+source/poppler/+bug/382379    It says there is a fix, but I can't figure out what needs to be implemented on a jaunty box to get pdf's printing properly over a network
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released]
<craigbass1976> Anyone know the status of this ?  https://bugs.launchpad.net/ubuntu/jaunty/+source/poppler/+bug/382379    It says there is a fix, but I can't figure out what needs to be implemented on a jaunty box to get pdf's printing properly over a network
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released]
<micahg> craigbass1976: just updating the package should fix it in jaunty
<craigbass1976> micahg, hrmmm... I've done all the updates.  No love.
<craigbass1976> I don't remember checking to see if I had poppler installed, but wouldn't it have been anyway?
<micahg> oops
<craigbass1976> oops what?
<micahg> I saw cups and said it was released :) checking the other task
<micahg> yeah, that was released too
<craigbass1976> so jsut because I have cups installed doesn't mean I have popplar as well?
<micahg> craigbass1976: idk, sorry
<micahg> craigbass1976: maybe try #ubuntu
<jcole> so, i created a chroot and bind mounted dev/proc/tmp ... how do i kill only the procs started in the chroot?
<jcole> i created a hardy chroot to backport
<maxb> jcole: /proc/PID/root tells you what the (ch)root dir of a process is. You can use this, from outside the chroot, to locate still-running chrooted processes
<jcole> maxb: thank you, i figured out that lsof was also my friend :)
<maxb> that too :-)
<nixjunki3> Is there a channel specifically for packaging or is this it
<StevenK> nixjunki3: I'd suggest #ubuntu-motu
<nixjunki3> thanks
<hyperair> dtchen: is it possible to patch pactl/pacmd to be more friendly to scripts?
<hyperair> e.g. list-sinks with a format parameter or something
<hyperair> if the output can be parsed by a script then it should be simple enough to save the muted status of each sink/source prior to suspend/hibernate and restore upon resume
<hyperair> in fact, i think pm-utils has some helper functions for this kind of thing
<hyperair> hmm no wait i think i can script this..
<hyperair> $ echo list-sinks | pacmd | grep -e index -e mute | sed -e 's/^[[:space:]*]*//' | (sink=; while read line value; do [ ${line%:} = index ] && sink=$value || echo $sink=$value; done)
<hyperair> voila. readable $sink=$muted status
<hyperair> now to save it..
<Infin1ty> I'm trying to build openoffice.org with some extension integrated into it, what is the easy way to pack it? i thought about just putting the oxt file in the OOBUILDDIR/extras/source/extensions, is it the right thing to do?
<judy> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/289852  I've got everyhing update on my jaunty box, but still can't print
<ubottu> Launchpad bug 289852 in cups "intrepid: printing very slow (dup-of: 382379)" [Undecided,Incomplete]
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released]
<qense> judy: For discussing bugs I would suggest you to use #ubuntu-bugs in the future. It seems your bug is a duplicate of bug 382379, which should be fixed in later versions of Ubuntu.
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released] https://launchpad.net/bugs/382379
<qense> and even in Jaunty
<judy> qense, but nothing now?  The bug says it's fixed.  I'll ask in bugs though
<fale> hi
<fale> Will Lucid use xsplash or will it use plymouth?
<Keybuk> james_w: "You cannot upload to this branch. Members of Ubuntu branches can upload to this branch." ? :-(
<hyperair> fale: xsplash.
<fale> hyperair: oh... I have seen a couple minutes ago the opposite info :S
<hyperair> what?
<hyperair> from who?
<hyperair> where?
<hyperair> when?
<hyperair> er nevermind about the when
<fale> hyperair: http://ubuntuforums.org/showpost.php?p=8341620&postcount=8
<hyperair> ...either i'm missing out on something, or somebody's bullshitting.
<fale> hyperair: yeah.. is not very clear what's going on :S
<Keybuk> how is that not clear? :p
<ScottK> fale: ^^^ guy in charge of the Ubuntu boot work, so I think it's now clear.
<fale> ScottK: hem... who is?
 * Keybuk  
<fale> Keybuk: oh, cool... than it will plymouth or what for ubuntu? and for the other flavours?
<Keybuk> fale: yes, plymouth; as it says
<Keybuk> replacing usplash
<fale> Keybuk: than even for kubuntu, I guess, is it right?
<Keybuk> fale: yes
<fale> cool :)
<Keybuk> the xsplash bit is a bit more complicated; we *may* merge the xsplash code into plymouth, so that we can use the plymouth splash plugins rendering to (effectively) xsplash
<Keybuk> recent changes in plymouth's code make that possible
<fale> Keybuk: I see
<fale> but it will use the actual plymouth system in any case (I mean that it never shows a black screen, code or stuff like that)
<fale> *?
<Keybuk> that's not really plymouth doing that
<fale> :o... what is?
<Keybuk> but it helps
<Keybuk> patches to the X server and kernel/X driver support
<fale> I see
<Keybuk> the main reason for the usplash->plymouth switch is that plymouth is a much cleaner codebase for future developments
<Keybuk> with better support for things like multi-head built in
<Keybuk> (being based on the kernel DRM/DRI/FB devices, not SVGAlib)
<fale> and ubuntu will aim to that? (like fedora does)
<Keybuk> yes
<fale> I can see the point ;)
<fale> cool :)
<fale> Keybuk: since when, probably, the plymouth will be the default one on the daily?
<Keybuk> probably early next week
<fale> that's really cool :)
<Keybuk> tseliot and I have been working on it for a couple of weeks
<fale> I see :)
<fale> another question completly unreleated: fedora uses kickstart to create the official and the unofficial ISOs. Which program is used by ubuntu for the official ISOs?
<Keybuk> proved it worked, so came to UDS saying "yup, let's just do this"
<fale> Keybuk: I think that's a good way ;)
<Keybuk> we use Debian-based tools
<fale> what's the name?
<Keybuk> something boring like "live cd tools"
<fale> I see
<fale> and is there the 'official configuration' that is used to create the official ubuntu iso?
<Keybuk> not sure
<fale> I see
<Keybuk> basically they just make a chroot, debootstrap, install ubuntu-desktop, turn it into a squashfs, and onto an iso
<fale> Keybuk: it sounds dirty :S
<fale> I mean, compared to kickstart
<ScottK> fale: debian-cd is used for all ISOs and there's some additional bits for the live CDs.
<Keybuk> fale: no, not at all
<Keybuk> very clean
<fale> I see
<Keybuk> making CD images is fundamentally Not That Hard :)
<fale> Keybuk: if I use uck to modify an ubuntu iso... do you think it will still be clean?
 * Keybuk modifies them all the time
<fale> ok :)
<fale> another thing: I have created a package that only have some dependences (no files). But after the installation apt tells me that my package is unused and that I can freely delete it. How can I fix this?
#ubuntu-devel 2009-11-21
<dtchen> hyperair: pactl could use love; pacmd really isn't the way to go for scripts.
<hyperair> dtchen: i agree with that.
<consumeEarth> O prokleta kosovska veÄero,
<consumeEarth> kud ta sreÄa da grdne glavare
<consumeEarth> sve potrova i trag im utrije;
<consumeEarth> sam da MiloÅ¡ osta na srijedi
<consumeEarth> sa njegova oba pobratima,
<consumeEarth> te bi Srbin danas Srbom bio!
<consumeEarth> BrankoviÄu, pogano koljeno,
<consumeEarth> tako li se sluÅ¾i otaÄastvu,
<Tm_T> !op
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<pecisk> hi people, there was gui for configuring policykit rules once, it is gone in karmic. Is it still available trough repos?
<mac_v> pecisk: there is no gui atm
<pecisk> mac_v, well, but is there plans to do so? Can be old tool ported to new pk api?
<mac_v> pecisk: you need to ask the upstream devs... there isnt any at the moment and the old tool doesnt work
<pecisk> allright
<pecisk> thanks for info
<mac_v> np
<maxb> Does Ubuntu have any means of providing armel test-builds for people other than the rare people with non-virtual PPAs?
<maxb> I want to merge subversion from Debian but the latest version is FTBFS on armel only in Debian
<fale> I can compile a package in lucid correctly, while in karmic I must add as dependences quilt. Why is that?
<JanC> fale: I think the new dpkg source package format uses/supports quilt, or something like that?
<JanC> not sure if that's supported in Lucid already though
<souffledev> dear oh dear asking ubottu about udev and it doesn't understand it
<Tm_T> !udev
<ubottu> Sorry, I don't know anything about udev
<fale> why is tor not included as package?
<fale> how can I purpose it? (I already have the package working)
<Laney> search ubuntu-devel(-discuss?) for why tor was removed
<fale> Laney: ok, thankyou
<fale> Laney: unmanteined
<fale> I have been really close to compile the last boost.. but got in some syntax errors :S I'll try again...
<fale> http://launchpadlibrarian.net/33823851/buildlog_ubuntu-karmic-i386.boost1.40_1.40.0-2ubuntu1_FAILEDTOBUILD.txt.gz <-- anyidea?
<geser> fale: see Debian bug #550300
<ubottu> Debian bug 550300 in boost1.40 "FTBFS with GCC 4.4: expected primary-expression before 'enum'" [Normal,Open] http://bugs.debian.org/550300
<fale> geser: awesome, thank you :)
<geser> and btw: why are you trying to build boost1.40 1.40.0-2ubuntu1 as karmic already has 1.40.0-2ubuntu2?
<fale> geser: mmm it was some month ago... but are you sure about the version in karmic?
<fale> that's true :S
<fale> geser: It was when karmic was still under development (more than 2 month ago ;))
<sebp> hi
<sebp> what's the process of importing packages from debian into ubuntu?
<jpds> sebp: It's automatic if there are no Ubuntu changes. Otherwise it needs a merge: https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<ari-tczew> sebp, come on #ubuntu-motu
<dmb> why is there no lib32 sdl devel package?
<siretart> dmb: https://wiki.ubuntu.com/MultiarchSpec
<dmb> siretart, i don't see how this is implemented in 9.10
<dmb> unless there are more details somewhere
<siretart> dmb: it isn't
<dmb> siretart, it says Ubuntu 9.10 introduces support for installing packages from multiple architectures on a single system. This makes a wider array of 32-bit applications available to users of 64-bit Ubuntu.
<dmb> is there something that describes that more?
<siretart> not that I knew, but other might be more knowledable
<ion> http://www.ubuntu-trading.com/media/site/images/titles/we_love_ubuntu.png
<ion> http://www.ubuntu-trading.com/our-fairtrade-cola
<ion> I wonder if itâs a random occurence they use a font very similar to the one used with the Ubuntu logo? :-)
#ubuntu-devel 2009-11-22
<wgrant> dmb: Multiarch was not implemented for 9.10.
<wgrant> dmb: That release note is just what would have been used if it had been.
<dmb> wgrant, so when it does get implemented, it will be possible to install any package as a 32bit or 64bit binary?
<dmb> because that would help the transition :)
<dmb> probably is rpath
<dmb> and that it looks for a lot of things in /usr/lib
<wgrant> dmb: That's the point.
<Ryan52> which package does the "the program 'foo' is currently not installed. you can install it by typing:" come from?
<Ryan52> does anybody happen to know?
<wgrant> Ryan52: command-not-found
<Ryan52> ah, thanks!
<m4t> anyone here familiar with how liblockfile/bsd-mailx and g+s /var/mail setgid(mail)/lockfile() work together?
<smwn> hi
<smwn> there is a bug in 9.10
<smwn> http://ubuntuforums.org/showthread.php?t=1300590
<Tm_T> !bugs
<ubottu> If you find a bug in Ubuntu or any of its derivatives, please file a bug using the command Â« ubuntu-bug <package> Â» - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs - Bugs in/wishes for the IRC bots (not Ubuntu) can be filed at http://bugs.launchpad.net/ubuntu-bots
<Tm_T> smwn: ^
<Tm_T> smwn: not exactly what I wanted to say, so I'll elaborate: bugs should be filed in launchpad so developers can follow the issue and answer to it
<smwn> ok
<smwn> its already reported
<smwn> thanks
<smwn> just alotta people out there going out to buy new harddrives when they don't need to lol
<ebroder> So tell them to keep the old drive - then they'll have backup for when the drive inevitably actually fails :-P
<fale_> fedora is using an open version of the bcm-fwcutter... ubuntu is planning to use it?
<trudell> hi all
<trudell> driver nvidia for kubuntu on karmic distro have being a lot of problems
<trudell> someone developer have any solution
<trudell> and a lot of programs need libgtk-1.2, can developers left this libraries as legacy in repositories?
<dtchen> trudell: problems should be reported using bugs.launchpad.net and will be investigated in due time. gtk+1.2 is no longer maintained in Debian; in fact, it was removed in April 2009.
<trudell> why not left as legacy?
<trudell> to other porograms that needs it
<dtchen> it has been "left as legacy" since 8.04
<dtchen> anyhow, the normal process is that if it's removed from Debian proper, there needs to be a really compelling reason to leave it in Ubuntu
<trudell> well,,,but in karmic isnt present as legacy
<ion> Programs depending on ancient versions of libraries should be fixed. If nobody is interested of fixing such a program, the program itself shouldnât be left âas legacyâ in the archive forever. :-P
<trudell> sure, but libgtk-1.2 is requered by a lot of progrmans yet
<trudell> epsxe for example
<dtchen> well, none in Debian testing or Ubuntu 9.10+, at least
<dtchen> but as ion said, it is unmaintained, and carrying it in Ubuntu presents a maintenance nightmare.
<dtchen> actually that's what I said, but his point that fixing a program is quite apropos
<trudell> i disagree this opinion
<dtchen> You're welcome to work with various developers to help maintain it
<trudell> i think that solution to space problem is dont build bad distribution like intrepid for example
<trudell> intrepid is a bad distribution only with problems and bugs
<trudell> intrepid had been a inutil distro
<trudell> since your launch
<ion> Ah, a troll. Letâs not feed it anymore. :-)
<trudell> my machine was only problems with intrepid
<trudell> Microsoft bribes Ubuntu development team to make bullshit kernel to not run 3d cards or commercial games on Linux.
<trudell> Microsoft bribes Ubuntu development team to make bullshit kernel to not run 3d cards or commercial games on Linux.
<beuno> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<trudell> Microsoft bribes Ubuntu development team to make bullshit kernel to not run 3d cards or commercial games on Linux.
<beuno> thanks Pici
<Pici> np
<slangasek> should the !ops token be updated to include more people who are actually current and active ops?
<slangasek> (and drop thom, fooishbar, jdub, perhaps)
<Tm_T> slangasek: well, I think we need more ops here anyway
<siretart> slangasek: if libbar links against libfoo, and libfoo's soname is bumped, does libbar's soname need to be bumped as well? in any case or might there be some special cases?
<ebroder> siretart: Shouldn't the soname number only need to be bumped if the API that library is exporting changes?
<nhandler> slangasek: You might want to bring that up at either an IRC Team meeting or in #ubuntu-ops
<Tm_T> preferaply in meeting and in ML before the meeting perhaps
<EzraR> anyautomake gurus in here?
<olmari> hello.. I'd have instant problem with Karmic mini-installation
<olmari> Warning: http://us.archive.ubuntu.com/ubuntu/pool/main/d/db/libdb4.7_4.7.25-7ubuntu2_amd64.deb was corrupt
<olmari> at middle of downloading
<olmari> same with using, say, finnish mirror
<dtchen> that points to a proxy error, really
<olmari> no proxy here
<dtchen> you don't need to be running one; your ISP could be
<olmari> well I know they aren't, they offer proxy but I don't use
<olmari> there is no forced proxy
<Tm_T> hmm, I'm not aware of any finnish ISP which would force proxy
<dtchen> 1928ab137f45edfe8e8fb690e56af26aeb44266219e9a8e35d2ccfb1eba12696  /var/cache/apt-cacher-ng/uburep/pool/main/d/db/libdb4.7_4.7.25-7ubuntu2_amd64.deb
 * Tm_T is assuming olmari is using finnish ISP anyway
<dtchen> (SHA256SUM)
<olmari> Tm_T: I am
<dtchen> what happens if you curl/wget it directly (even from another mirror)?
<olmari> dtchen: well I can try with this computer, but what to do with that computer in middle of installation?
<dtchen> have you ruled out medium error?
<olmari> dtchen: hmm.. well not actually now you ask... yet it's same file each time even when done HD formatting etc... Sorry to ask stupid Q, but how can I check the HD for defects? I do have livecd at my disposal too
<dtchen> olmari: I was referring to network medium -- cables, etc. Sorry for not being precise.
<olmari> dtchen: mm.. well.. cable should work... haven't got a spare unfortunately ATM
<EzraR> anyone in here familiar with the problem with automake and python.m4 setting wrong dirs?
<ebroder> If I'm requesting a backport to, say, Hardy, is it better to ask that the version in Intrepid be backported, or the version in Karmic be backported to Hardy/Intrepid/Jaunty?
<micahg> ebroder: no difference, it's all a matter of dependencies and time
<maxb> I need some advice: I want to request sponsorship for a merge of subversion from Debian, but I can see that the Debian armel build of the package failed. Should I still request sponsorship? If not, what can I do without an armel box of my own?
<ebroder> maxb: Generally Ubuntu doesn't care too much about architectures other than amd64, i386, and lpia
<ebroder> (And lpia is kind of tenuous at best)
<ebroder> You can use PPAs to test those three architectures
<maxb> Indeed. But this is an armel-specific failure, it seems
<ebroder> maxb: Then I wouldn't worry about it
<ebroder> The architectures other than the 3 I listed are absolutely 2nd class citizens in the Ubuntu ecosystem
<maxb> ok, I guess I'll just subscribe ubuntu-main-sponsors, point out the issue, and hope for the best
<stgraber> ebroder: armel is far from second class citizen
<stgraber> ebroder: it's the main architecture for the ubuntu mobile team
<stgraber> ebroder: and part of the main supported architecture just next to amd64 and i386
<ebroder> stgraber: Oh really? Last time one of my uploads FTBFS'd on a port architecture, I was told not to worry about it
<ebroder> Granted, I suppose, it was hppa, not armel
<lifeless> james_w: any chance you can look at why glib2.0 failed to import ?
<james_w> lifeless: it was blocked while codehosting was low on space
<james_w> I need to confirm that I can restart
<lifeless> james_w: codehosting has 2TB free now
<lifeless> the upgrade was completed
<james_w> yes, but I want to confirm
<james_w> and return to work so that I can restart the imports
<lifeless> well, I can get the confirmation for you; I realise its your weekend.
<james_w> and I am on vacation next week
<lifeless> can losas control the system?
<spm> james_w: you can restart when ready; space is available.
<james_w> spm: thanks
#ubuntu-devel 2010-11-22
<StevenK> RAOF: O hai! Do you tim to throw some debugging options at me for a DPMS issue I'm having?
<StevenK> s/\(tim\)/\1e/
<RAOF> I have any number of Tims to throw.  And maybe even a little time :)
<RAOF> What's the problem?
<StevenK> RAOF: I have "Put display to sleep when inactive for: 0:10" in Power Management, it just ... doesn't
<RAOF> Heh.
<RAOF> Is something inhibiting the display sleep?
<StevenK> I'll come back to the machine after a few hours, and the monitor is still helpfully showing the screensaver
<RAOF> Does âxset dpms force off ; sleep 5; xset dpms force onâ turn off the monitor for 5 seconds?
<StevenK> Nope, it blanks, and then comes right back
<StevenK> Although, it seemed to work the second time ...
<RAOF> Heh.
<RAOF> I'd suspect something higher in the stack than X, generally.
<RAOF> Particularly if xset works :)
<dholbach> good morning!
<didrocks> good morning
<pitti> Good morning
<pitti> buxy: as ebroder says, we primarily need to install less; compressing .debs more won't help much
<pitti> jibel: do you think you can play with the test case in bug 672964, so that someone else than just me tests this? I know that it doesn't help to fix an already broken system, but I'm fairly sure the patch will prevent breaking it in the first place
<ubottu> Launchpad bug 672964 in udev (Ubuntu Lucid) "2.6.32-26 unbootable: does not find root file system" [Critical,Fix committed] https://launchpad.net/bugs/672964
<jibel> pitti, I'm looking at it.
<pitti> jibel: merci; not that urgent, though
<mvo> jussi: could you please add to the channel topic that I'm "patch-pilot" of the day ? (ref is https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch%20Pilots)
<jussi> mvo: this channel is not +t - you are able to do so yourself :=)
<jussi> mvo: though I think we will have the bot to help out soon
<pitti> mvo: happy piloting!
<pitti> "launch clearance granted"
<seb128> mvo, oh nice, that's starting today ;-)
 * mvo puts his pilot hat on and starts the engine
<mvo> jussi: aha, thanks
<dholbach> can somebody approve my mail to u-d-a - it's also about the patch pilot programme
<dholbach> please :)
<pitti> dholbach: will do
 * dholbach hugs pitti
<pitti> flushed
 * pitti hugs dholback
 * dholbach will blog it too
* mvo changed the topic of #ubuntu-devel to: Archive: Open | maverick-proposed is now unfrozen | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs; Friendly Patch Pilot of the day: mvo
<dholbach> haha
 * dholbach hugs mvo
* cjwatson changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Friendly Patch Pilot of the day: mvo
<cjwatson> (I think we can drop the maverick-proposed unfrozen item now)
 * mvo nods
<bryceh> dholbach, is patch pilot only looking at debdiffs?
<dholbach> bryceh, see the mail I just sent to u-d-a
<dholbach> I'll give you the link to my blog post in a sec :)
<dholbach> hang on
<bryceh> dholbach,  I just did
<bryceh> dholbach, but I'm unclear
<dholbach> http://daniel.holba.ch/blog/?p=820
<dholbach> bryceh, http://reports.qa.ubuntu.com/reports/sponsoring/ is a good start
<om26er> mvo,  can you sponser this fix https://code.launchpad.net/~om26er/ubuntu/maverick/gwibber/gwibber-fix-674894/+merge/40899
<dholbach> bryceh, is your question about "what you're supposed to do" or "which queue to look at"?
<bryceh> dholbach, no, my question is, if a bug report has a patch that is not in debdiff form, is it acceptable or unacceptable to subscribe ubuntu-sponsors?
<om26er> the fix is taken from gwibber trunk
<ogra_ac> didrocks, hrm, you messed up ubuntu-netbook-default-settings
<dholbach> bryceh, if you reviewed the patch and it's sound and you want to upload it and it's only a matter of adding a changelog entry, it's great if you just go ahead and do it
<didrocks> ogra_ac: well, on armelâ¦ that's why I asked you to test it before on an armel build :)
<dholbach> what I usually do is say "this is what I did to get it in an uploadable state"
<ogra_ac> didrocks, you should also never use DEB_HOST_ARCH, that breaks cross building and makes lool unhappy ;)
<jibel> pitti, re 672964, I cant reproduce the original issue with udev 151-12.2 in lucid-updates and the steps described in the test cases , is there any other prerequisite ?
<didrocks> ogra_ac: oh really? what should be used?
<didrocks> (saw that in other packages too)
<ogra_ac> didrocks, not armel related, seems that dh7 cant handle the code in rules the way you used it
<pitti> jibel: hm, I only tried on maverick, and there it reproduced well
<didrocks> ogra_ac: but you know I like make lool unhappy :)
<ogra_ac> didrocks, ifeq ($(DEB_BUILD_ARCH),armel) would be better for cross builds
<ogra_ac> that takes the target arch instead of the build machine arch
<pitti> jibel: there shouldn't; if the initramfs gets built correctly while udev is unpacked, but not configured yet (i. e. /sbin/udevadm is diverted), the bug wouldn't happen
<pitti> jibel: but I don't see what would stop that from happening in lucid
<jibel> pitti, I'm trying in maverick.
<didrocks> ogra_ac: ok, updating to that then (same for ubuntu-netbook)
<ogra_ac> k
<didrocks> ogra_ac: then, those two packages are yours :)
<mvo> om26er: sure, I have a look now
<ogra_ac> i_m still trying to figure out what makes it fail with "missing separator"
<didrocks> ogra_ac: maybe you want to do the change and test with your hw rather?
<ogra_ac> its not HW related
<ogra_ac> but i cant see a typo either
<didrocks> ogra_ac: it's building locallyâ¦
<didrocks> and it built everywhere !armel
<geser> ogra_ac: whitespace issue: space vs tab before the dh_install
<ogra_ac> well, it doesnt go the script path you created if DEB_HOST_ARCH isnt set to armel
<jussi> ts2: you going t explain for all the lovely folks here how this works?
<lool> didrocks, ogra_ac: It's hte other way around; you want to use DEB_HOST_ARCH, not _BUILD_ARCH
<lool> the arch on which you build it on shouldn't affect the results; only the target arch on which you expect to run it (host)
<ts2> jussi: one sec, yeah :)
<lool> geser found the real problem it seems
<ogra_ac> didrocks, http://paste.ubuntu.com/535147/ that way it shoudl work
<didrocks> yeah, I should sometimes have an automatic rules to not strip tabs when opening debian/rules in vim
<ogra_ac> geser, oh
<didrocks> replacing by a tab and uploading then
<didrocks> thanks geser, lool, ogra_ac
<didrocks> and so nothing to change for the ubuntu-netbook metapackage
<mvo> om26er: thanks a lot for this branch. it looks fine, the only missing bit is a "TEST CASE" in the bug #674894 so that the SRU verification can be done, it should be pretty trivial in this case :) one more question - did you talk to kenvandine about the upload? I just want to ensure that he does not plan to upload this as part of some bigger patchset to maverick-proposed
<ubottu> Launchpad bug 674894 in gwibber (Ubuntu Maverick) "gwibber prepends "is" to messages sent to facebook" [Undecided,New] https://launchpad.net/bugs/674894
<lool> ogra_ac: No it wont; this will not define override_dh_install on != armel, so it will run dh_install by default
<ogra_ac> lool, yeah, right
<ogra_ac> lool, thanks for both
<lool> didrocks: It would be nicer to ifneq ($(DEB_HOST_ARCH),armel) override_dh_install: endif and not have any dh_install
<didrocks> lool: oh, directly wrapping the target? ok, can do that :)
<om26er> mvo, there is nothing coming in maverick-proposed from ken since the last -proposed (big bug fix release) was just gone into -updates
<seb128> mvo, om26er: you should let kenvandine's do the gwibber sponsoring
<lool> Alternatively, you could use -X or -N; e.g. override_dh_install: dh_install $(if ...), but I find that harder to read
<seb128> mvo, om26er: he's active on it and might have a reason for not having uploaded yet, at least check with him before upload
<didrocks> lool: yeah, that was my first idea but I didn't like it when reading
<didrocks> # Skipping dh_install - empty override <- nice dh7 warned about it :)
<om26er> seb128, ok sure will do that today
<mvo> seb128, om26er: ok, thanks. I will comment in the branch but wait for kenvandine for his final word then
<mvo> if he is busy I'm still happy to sponsor it
<om26er> mvo, ok this https://code.launchpad.net/~om26er/ubuntu/maverick/gexiv2/gexiv2-fix-636161/+merge/41398 ;)
<om26er> its recommended from shotwell developer
 * mvo looks
* jussi changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<jussi> mvo: others, herses how the bot works
<jussi> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Patch Pilots: jussi
<jussi> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Patch Pilots:
<mvo> nice jussi!
<mvo> @pilot in
<nigelb> neat :)
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Patch Pilots: mvo
<jussi> mvo: thank ts2
 * mvo hugs ts2
<ts2> :)
 * didrocks is kind of disappointed that the Patch Pilot isn't "Friendly" anymore ;)
<jussi> ts2: can we have friendly patch pilots?
<didrocks> :)
<ts2> any other requests while I'm at it? ;)
<jibel> pitti, I can't reproduce in maverick either. I only get a broken initramfs if I stop at step 2.
<nigelb> didrocks: you want to bot you hug you at the end of your rotation? ;)
<nigelb> *want the
<jibel> pitti, if I run the postinst step, the diversion is removed before running update-initramfs and the correct udevadm is copied to initramfs.
<didrocks> nigelb: oh neat idea! :)
<jibel> pitti, or ma I missing something ?
<jibel> s/ma/am/
<pitti> jibel: oh, you mean udev.postinst configure rebuilds the initramfs?
<jibel> pitti, right.
<pitti> jibel: then it indeed seems that this test case isn't reproducing the problem, sorry
* ts2 changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mvo
<ts2> @pilot in
<udevbot> An error has occurred and has been logged. Please contact this bot's administrator for more information.
<ts2> yippy...
<dholbach> thanks ts2
<geser> it would be nice if the bot would tell who the bot admin is
<ts2> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ts2, mvo
<jibel> pitti, np. I think that we can only reproduce the issue if the postinst script is not run at all or if it stops before calling enable_udevadm
<ts2> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mvo
<jibel> pitti, let me know if you want to test something else.
<pitti> jibel: will think about it; thanks so far!
<mvo> om26er: you have just written history, the first upload from the new patch-pilot program
<om26er> mvo, thanks alot :)
<om26er> i am legend :p
<didrocks> ts2: nice :)
<bryceh> mvo, om26er, congrats :-)
<didrocks> heh, congrats mvo, om26er :)
<mvo> \o/
 * pitti ^5s om26er and mvo
<om26er> bryceh, didrocks thanks ;)
<om26er> bug 655241
<ubottu> Launchpad bug 655241 in AppMenu GTK+ "some applications show duplicated menus" [High,In progress] https://launchpad.net/bugs/655241
<om26er> https://code.launchpad.net/~om26er/ubuntu/maverick/appmenu-gtk/appmenu-gtk-fix-655241/+merge/41397
<om26er> the fix is merged upstream mvo
<om26er> there are quite a few duplicates too.
<om26er> thats the last one
<mvo> om26er: thanks! I look in detail after my lunch break, from fist sigh it looks fine, it would be nice to have a TEST CASE in the bugreport to the SRU process
<mvo> from the first look
 * mvo can't type today
 * om26er writes a TEST CASE
<pitti> ev: FYI, I'll port usb-creator from pygtk2 to gtk3.0 and gi, if that's alright with you?
<ev> that's fantastic, thanks pitti!
<cjwatson> pitti: my understanding had been that gtk3/pygi only worked properly with python3; is that true in your expereience?
<cjwatson> *experience
<pitti> cjwatson: I have run into one bug where python3 works better
<pitti> cjwatson: but by and large it's fine
<cjwatson> ok, that's a relief
<pitti> cjwatson: https://bugzilla.gnome.org/show_bug.cgi?id=620579 is the one FYI
<pitti> it's being fixed
<pitti> but it's easy enough to avoid/work around for now
<seb128> pitti, no, it works fine with python2, though they recommends going for python3 while you are at porting if you can
<seb128> ups
<seb128> cjwatson, ^
<pitti> that's right
<pitti> but we don't currently ship py3 on the CDs
<pitti> and I don't want to be the one who introduces it :)
<mvo> didrocks: are you ok with me uploading #655241 ? it looks like you did most of the recent uploads?
<seb128> right, I don't think we should go for python3 yet
<cjwatson> seb128: I just don't want to have to do both ports simultaneously
<mvo> didrocks: diff looks fine and is taken from the upstream branch
<cjwatson> in general
<seb128> right, my idea was to do python2 gi ports this cycle
<didrocks> mvo: sure, cherry-pick it :)
<didrocks> thanks :)
<mvo> thanks didrocks, uploaded
<seb128> mvo, yeah, feel free to do appmenu-gtk uploads
<mvo> thanks om26er!
<seb128> mvo, oh, you are the new maintainer then
<seb128> ;-)
<didrocks> you gave me compiz, you have appmenu :p
<seb128> joke aside appmenu-gtk has a collection of issues if anybody feels like working on it...
<mvo> seb128: geh, I'm pilot, not superman
 * seb128 hugs mvo
<dholbach> seb128, I just noticed in Harvest that there's a number of patches and branches for it :)
<seb128> dholbach, I will kick dx-ers to get reviews
<dholbach> sweet
<geser> anyone available to review and sponsor a gparted SRU? the debdiff is in comment #53 of bug #617885
<ubottu> Launchpad bug 617885 in gparted (Ubuntu Maverick) "gparted crash at start: glibmm-ERROR **" [High,Triaged] https://launchpad.net/bugs/617885
<seb128> or nicely nudge rather
<seb128> geser, I though cjwatson said he had it on his list
<mvo> geser: I guess that is me
<mvo> seb128, geser, cjwatson: I'm the pilot today, I can do the sponsoring (after lunch)
<geser> seb128: wasn't that the vim merge? I asked cjwatson about gparted too but as he's busy I try to find someone else (the vim merge is still waiting on review)
<mvo> but I'm equally happy to let someone else do it
<seb128> geser, yeah, searching in my log I think I confused it with another patch
<seb128> let mvo rock it ;-)
<cjwatson> sorry, I really haven't had time to deal with gparted - if the patch pilot could deal with it I'd be enormously grateful
<cjwatson> (otherwise my patch pilot morning is coming up next week, but you might not want to wait for that ...)
 * mvo will take it
<cjwatson> thanks!
<mvo> ev: if you could have a look at some point at #545445, that would be nice. its  support for lxde in ubiquity, afaics its fine, I commented in the bug
<mvo> (I had two question for the diff, but maybe they are non-issues)
<seb128> bug #546445
<ubottu> Launchpad bug 546445 in ubiquity (Ubuntu) "Support for lxdm in ubiquity (autologin, only-ubiquity support)" [Wishlist,Confirmed] https://launchpad.net/bugs/546445
<seb128> mvo, rather?
<mvo> seb128: rather?
<seb128> mvo, the number, see line before
<seb128> mvo, #545445 has nothing to do with ubiquity?
<mvo> seb128: oh, sorry
<mvo> seb128: indeed, typo
 * mvo is away for lunch now
<seb128> hum, lunch!
<smoser> anyone else seeing bug 676790 ? I'm almost certain that its not just me (I've seen it happen every time during debootstrap on host system of maverick or lucid).
<ubottu> Launchpad bug 676790 in apt (Ubuntu) "huge performance regression" [Undecided,New] https://launchpad.net/bugs/676790
<seb128> mvo, great idea ;-) I will do that as well
<smoser> it seems fairly important to me, that it would affect cd install, and turn that into a multi hour affair
<ev> mvo: when you get back, any idea what the details of "[ev] support "keep package selection" on install that preserves /home: TODO" in packageselection-foundations-n-update-manager-improvements are?  I thought OneConf was the approach for maintaining packages between installs.
<smoser> has anyone attempted a natty ISO install ?
<ogra_ac> there were plenty probs reported in the release meeting
<ogra_ac> iirc X restarts continiously
<dholbach> ogra_ac, I think that was a kernel bug and is fixed
<ogra_ac> already uploaded and on the isos ?
<dholbach> uploaded yes, isos I don't know
<ogra_ac> k
<ogra_ac> i just remember it was reported on friday
 * ogra_ac doesnt touch x86 much anymore ;)
<mvo> ev: well, oneconf requires a ubuntu one account. it seems like its pretty straightforward to preserve the selection via a chroot dpkg --get-selection like mechanism from the to-be-overwriten system. I don't have strong opinions here, but it sounds like the amount of work for this is about the same, the chroot dpkg --get-selections would just be one of two possilbe backend methods to retrieve the data needed
<mvo> (as straightforrward as dealing with potentially multiple /usr, /var, /boot mount points can be I suppose ;)
<ev> unless of course they have third party repositories
<ev> in which case, as mpt pointed out, we risk removing all of their paid applications
<sladen> where are the IRC logs from UDS?
<mvo> ev: well, oneconf only partly helps here
<mvo> ev: for payed apps we need to do "update repo to nre-release, check if software-is-still-there, if-not, fail or warn"
<mvo> ev: we could extend the "preserve-packages" to preserves sources.list
<mvo> not sure if that still fits in the spec, it gets complicated quickly
<cjwatson> geser: DMB meeting?  we have some timezone confusion apparently
<ev> mvo: speaking of the specification, are you working on that or are you keen to keep it as just a list of work items?
<mvo> ev: the oneconf one?
<ev> foundations-n-update-manager-improvements
<mvo> ev: so far I was happy with the workitems as more a loose selection of todos, but I'm happy to write a proper spec if you prefer that
<ev> I'm just concerned about handling the reinstallation of third-party applications.  dpkg --get-selections is easy enough if we assume a vanilla maverick to natty, but if we also copy over sources.list and try to reinstall packages, we may have broken dependencies.
<mvo> geser: I'm happy to upload your gparted patch, could you please add a TEST CASE to the bugreport for the SRU verification - if that is not straightforward, just add something like "no known test method, regression test plus getting feedback fro mthe original reports required"
<mvo> ev: yeah, I think it will need a python-apt app, I can work on something like that if it helps
<mvo> ev: a more intelligent version of dpkg --get-selection that looks for stuff that is not downloadable, stuff that comes from third party repos and then checks if the third party stuff has upgrades etc
<mvo> ev: similar to what u-m is doing when it performs its checks. we need to figure out a UI for this
<mvo> I think that is the hardest part :)
<ev> exactly
<ev> answering the question of what we do when it cannot resolve something
<ev> because we've told the user we were going to preserve applications or whatever
<ev> but yes, a python-apt application would be most helpful
<mvo> ev: thanks, I add a workitem for myself. I guess the exact message/Ui is on mpt, but I imagine something like a warning that the exact package selection can not be restored and a (optional) list of detailed packagename/descriptoins
<mvo> ev: I add a workitem for myself
<Chipzz> ev: wouldn't patching dpkg so the --get-selections option is aware of manually and automagically installed packages be more usefull?
<Chipzz> (but the manually vs automatically installed information is sth on the apt and not dpkg level I suppose)
<mvo> seb128: bug #486154 looks like something that really should be done upstream, no?
<ubottu> Launchpad bug 486154 in metacity (Ubuntu) "System beep broken in Karmic despite heroic efforts to fix it" [Medium,Triaged] https://launchpad.net/bugs/486154
<mvo> seb128: or do you think its appropriate as a distro patch?
<seb128> no strong opinion about it, we use compiz by default
<seb128> would be nicer done upstream though
<seb128> but if you want to upload go for it
<mvo> I don't feel confident in the diff enough for that, I would prefer upstreams comment
<seb128> right
<geser> mvo: I'll update the bug and add the TEST CASE when I'm back home
<geser> cjwatson: the DMB meetings at 12 UTC don't suit me at all as I'm in the middle of a lecture at that time
<soren> geser: It's still going on, if you're interested.
<mvo> thanks geser
<persia> bdrung, So, yeah, I tend to agree with you about core-dev being about work primarily in "core", but I'm uncertain to some degree, in part because of the issues one has in bringing new stuff in, and in part because all the packagesets depend on core, which often means one has to work in core in order not to just upload workarounds for various issues.
<cjwatson> bdrung: if you disagree with the design of the package set split, that's one thing, but kenvandine has been working on things that *are* core packages and that are core because they're used by products other than desktop
<cjwatson> bdrung: in some cases we've made specific exceptions, but the volume is high
<cjwatson> and it's not always obvious that it *is* correct for these packages to be in desktop
<cjwatson> although netbook being merged back into desktop reduces the question marks a bit
<pavolzetor> hi, please look at this fix https://code.launchpad.net/~pavolzetor/ubuntu/natty/liferea/liferea-test
<kenvandine> a big chunk of what lands on the ubuntu-desktop CD isn't in the desktop package set
<cjwatson> bdrung: for example libindicator is in both Ubuntu and Kubuntu desktops, and therefore is in core
<seb128> cjwatson, bdrung, persia: we also could use extra people being able to do sponsoring
<cjwatson> (actually desktop-core I think)
<seb128> out of set specific discussions
<seb128> even if 99% of kenvandine's work is in desktop
<cjwatson> bdrung: I made an exception because it seemed most sensible at the time, but this means that people entirely focused on ubuntu-desktop can make changes to kubuntu, which is really the sort of thing core-dev is meant for
<persia> seb128, I'm not confortable with that rationale: I'm not convinced the sponsoring issue is a lack of people, so much as a lack of people willing to touch a small subset of critical packages.
<seb128> if we have people who know enough about what they are doing to help on sponsoring that would be nice to have them set with upload rights
<cjwatson> bdrung: so simply saying "oh that should be in desktop" simplifies the situation IMO too much
<persia> seb128, And I'd rather grant access to folk because of my confidence in them uploading stuff, than because of my confidence in their ability to sponsor stuff.
<pavolzetor> coukd someone help me
<seb128> persia, sponsoring is uploading, I fail to see the difference
<pavolzetor> I would like help make ubuntu better
<seb128> pavolzetor, try #ubuntu
<pavolzetor> so :-D
<pavolzetor> ubuntu-mote => ubuntu-devel => ubuntu
<pavolzetor> trhanks
<persia> seb128, Yes, I agree.  There is no difference.  Hence I don't care about a willingness to sponsor (other than that everyone should have one)
<seb128> pavolzetor, well maybe if you state your question in a better way
<cjwatson> 14:58 <pavolzetor> hi, please look at this fix https://code.launchpad.net/~pavolzetor/ubuntu/natty/liferea/liferea-test
<seb128> pavolzetor, but "can somebody help" usually go to #ubuntu
<kenvandine> pavolzetor, oh... hang on
<cjwatson> seb128: ^- did you see that?
<kenvandine> pavolzetor, that isn't #ubuntu :)
<seb128> cjwatson, no, just "<pavolzetor> coukd someone help me"
<seb128> cjwatson, thanks
<seb128> pavolzetor, sorry, I didn't read the first line you wrote
<pavolzetor> I have done patch
<BlackZ> pavolzetor: I will test your patch
<kenvandine> pavolzetor, are you looking for sponsoring?
<pavolzetor> and branch
<pavolzetor> I am bit new in ubuntu dev
<seb128> pavolzetor, you can try to ask mvo, he's patch pilot today
<seb128> see the topic
<seb128> pavolzetor, you might want to subscribe ubuntu-sponsors as well
<pavolzetor> okey, I just must go out
<persia> pavolzetor, Don't run away, just because we're confused :)
<kenvandine> pavolzetor, sorry we were in the middle of a debate :)
<pavolzetor> I am student and I fixed liferea indicator in free time
<pavolzetor> I am sorry
<kenvandine> pavolzetor, awesome... no worries
<seb128> persia, well, I don't say we should care about willingness to sponsor, I'm just saying that kenvandine understand enough of what he's doing to do uploads out of the desktop set if he needs to
<kenvandine> i should look at that then
<persia> pavolzetor, Don't be sorry.  That's wonderful.  Thank you.
<pavolzetor> I don't wanna make big changes in source, because of diffs between ubuntu and others
<ivoks> guys, how does one make upstart not to kill child processes?
<seb128> pavolzetor, we will get your patch reviewed and comment, you can maybe do a merge request from it?
<pavolzetor> I have done it
<seb128> pavolzetor, ok, so wait a bit and somebody is going to review the work you did and comment on it
<pavolzetor> and I fixed gpm twcie steps, a "big bug"
<pavolzetor> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/257827
 * persia finishes playing with "comm"
<pavolzetor> I am trying get it to gnome also
<pavolzetor> I have tested it at two comps and it works properly
<pavolzetor> brb
<seb128> persia, is your issue with kenvandine's application that you think that he doesn't have the skills to work out of the desktop set?
<seb128> persia, I'm not sure to understand the issue
<persia> seb128, No, my issue is that from what I have seen, he's never had anything in "core" even as a sponsored upload.
<persia> I'm more than confident in his skills, but like to see some examples of work in the target packagesets before granting upload access.
<seb128> why?
<persia> That said, I might be using edit_acl or comm incorrectly.
<seb128> it's a chicken egg issue
<persia> Why?  Most folk find sponsors for stuff before applying.
<seb128> he could be sponsoring things he doesn't work on if he had upload rights
<seb128> he doesn't work out of desktop
<bdrung> seb128: yes, we need more people doing sponsoring. there are 12 sponsor request open for ubuntu-desktop that kenvandine can work on.
<seb128> it doesn't mean he couldn't make use of upload rights for sponsoring
<kenvandine> persia, seb128 has sponsored lots of stuff for me
<pitti> mvo: when you moved to apt-get changelog, did you keep the configuration support? (i. e. setting the mirror)
<seb128> kenvandine, in the desktop set though
<persia> kenvandine, I believe you.  I'm just not sure why I don't see it.
<seb128> kenvandine, or things that ought to be in there
<kenvandine> seb128, sort of... the fact that you needed to sponsor them though
<persia> Might just be race conditions then: stuff being sponsored just before it hits.
<seb128> bdrung, we know that we need more people doing sponsoring
<pitti> mvo: ah, it's in apt-get(8) now, nevermind
<seb128> persia, it's not even a race, if kenvandine has upload rights he could take on reviewing and sponsoring things out of the set he works usually on
<persia> seb128, There's a sufficiency of patches not currently embedded in sponsor requests that would benefit from wrapping that I don't find that convincing.  There's plenty of stuff that can be uploaded that isn't sponsor requests.
<seb128> persia, I don't see the point of stopping people to get upload rights if they have the skills for
<seb128> they might not use them now
<persia> What I'm less convinced about is whether the potential race condition between the state of the packageset at the time an upload was made and the state when I am reviewing the upload gives me an accurate picture of the historical work done.
<seb128> but they would be set if there is any need showing up
<superm1> ev, mvo: in terms of UI, it is sounding to me like once the person selects the option to reuse a partition you'll need to present them with another ubiquity page that gives them some details on what is about to happen with some checkboxes. Eg 1) Any  files in /home will be saved 2) The following applications that come from Ubuntu will be re-installed 3) The following applications that you paid for will be re-installed 4) The following third-
<superm1> party sources will be re-activated.  You will need to manually reinstall applications from them; etc
<bdrung> seb128: you should show that you can work in that area you want upload rights to.
<seb128> persia, how can it hurt to have people skilled to be able to upload? even if they don't use that right often
<superm1> and using the python-apt black box to build the lists for those checkboxes
<seb128> bdrung, right, but persia said the issue was not on showing that you can
<seb128> that's why I was asking if the issue is that he didn't show enough packaging skills
<bdrung> seb128: i didn't saw enough outside the ubuntu-desktop set. there is no link to a launchpad bug or upload.
<seb128> is outside of desktop harder?
<persia> seb128, No, I said that I'm comfortable with kenvandine's skills.  That said, I'm not core-dev, so I wonder if I'm best qualified to review his work on packages in "core".  A lack of apparent uploads (either from an LP bug or coincidence) dissuades me from approving it.  On the other hand, there are a number of other things that kenvandine does need to do which would be facilitated by being core-dev, hence my indecision.  If it was just a matte
<persia> r of access to the "core" packageset, I'd vote to defer until I could see some work history.
<persia> (actually, might not be an LP bug, so much as some limits in data collection)
<seb128> let's be honest, his focus is desktop
<seb128> that will not be different because he got upload rights out of the set
<seb128> but that doesn't mean he couldn't make use of uploads right of the set
<mvo> pitti: yeah, I took your documentation and adapted it, the option is almost named the same (apt::changelog*s* iirc)
<seb128> to do sponsoring
<seb128> to be able to workaround set definition bugs
<mvo> pitti: thanks for writing the docs btw \o/
<cjwatson> my focus is installer/bootloader, that doesn't mean I do nothing else
<seb128> to be able to help on something when we need people
<mvo> @pilot out
<kenvandine> and not to end up blocked by or distracting others when needing sponsoring myself
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<seb128> I fail to see why you have an issue with him having upload rights
<seb128> if you trust him to upload to main out of desktop you should let him have those right, even if he doesn't use them every day
<cjwatson> NCommander: are you being a patch pilot today (per the schedule)?
<ogra_ac> cjwatson, he should be, but doesnt seem to be up yet
<seb128> that show we have qualified people in the team and people able to take on tasks that require those rights
<persia> cjwatson, It's 7:21am there :)
<ogra_ac> (we discussed it last week)
<SpamapS> anybody have ideas what might cause the error about tar here:  http://launchpadlibrarian.net/58855548/buildlog_ubuntu-lucid-i386.mongodb_1:1.2.2-1ubuntu1.1~ppa1_FAILEDTOBUILD.txt.gz ?
<SpamapS> dpkg-deb: building package `mongodb' in `../mongodb_1.2.2-1ubuntu1.1~ppa1_i386.deb'.
<SpamapS> tar: ./usr/bin/mongo: file changed as we read it
<cjwatson> persia: hm, I forgot he'd moved
<SpamapS> it works in sbuild and pbuilder .. but the PPA build fails
<bdrung> seb128: i like to see a list of sponsored uploads to the core package set
<cjwatson> he's still London-0500 in my head
<persia> Thought that might be it :)
<persia> SpamapS, Ask in #launchpad: my random guess would be overeager cleanup of some sort.
<seb128> bdrung, he doesn't work out of desktop
<seb128> bdrung, but he could be helping sponsoring out of desktop or be assigned task that require upload out of desktop he had right to work there
<seb128> bdrung, which is not the case
<seb128> there is no point for him to pick a sponsoring bug if he can't upload
<bdrung> seb128: there are 12 sponsor request he can work on
<seb128> I'm not saying he lack sponsoring tasks to work on
<seb128> I'm saying he could do things
<seb128> like if libindicate soname change tomorrow
<seb128> he could upload all the no change rebuilds himself
<seb128> those being in the desktop set or not
<seb128> rather than having to deal with pinging people or opening sponsoring requests
<seb128> you are arguing that he might not use his upload right
<seb128> so what if he doesn't
<seb128> it still doesn't cost anything
<SpamapS> persia: ack
<seb128> it can only be useful
<seb128> if it doesn't it still doesn't hurt
<seb128> it would be a no change compared to now
<seb128> you block a potential win situation just because it might not win a lot?
<seb128> I fail to see the point... let people be able to help, what they do then is their issue
<bdrung> seb128: it's not about what he will do, but about what he has done.
<seb128> why does it matter?
<pavolzetor> I am back
<pavolzetor> please reply if there are some issues with my patches
<pavolzetor> I think, gpm patch would have higher priority
<persia> seb128, It's how it's always been done: we expect work to be done through sponsors before we grant direct upload permissions.
<seb128> bdrung, it's about having confidence people are ready for uploading or not
<bdrung> seb128: is it enough to show that you have packaging skills or should you show that you can work in specific area?
<seb128> well nobody has worked on everything
<persia> pavolzetor, Be aware that it sometimes takes a while for folk to give feedback.  If you've subscribed the sponsors and/or made a merge proposal, someone should review it before too long.
<seb128> even debian doesn't ask you to work on everybody before being a DD
<persia> Debian and Ubuntu have very different models.
<seb128> they just ask you to show you have the technical skills and social understanding to do what you want to do
<seb128> persia, did you read what I wrote a few minutes back?
<seb128> like being able to handle a soname change transition
<pavolzetor> I think moths are too long
<kenvandine> i think what seb128 is saying, it isn't likely that anyone will assign a bug with a patch on it to review if i can't upload it
<pavolzetor> I am mainly interested in android, but this is my part-hobby
 * ogra_ac doesnt get this discussion, 128 sponsored uploads on maverick-changes dont qualify for upload rights ?
<persia> ogra, Where are the 128 sponsored uploads?  remember that kenvandine has upload access to a number of packages.
<bdrung> i want to see the list where kenvandine gets an upload to the core-set sponsored
<ogra_ac> persia, on maverick-changes in my evolution if i search for his name
<seb128> bdrung, he doesn't, he's working on desktop
<ogra_ac> why does he need to ?
<seb128> bdrung, sure we don't ask to help with transitions out of the desktop set because he can't upload
<persia> ogra, I'm having trouble finding anything sponsored.  128 seems about right based on what I see.
<seb128> persia, I've sponsored at least 25 uploads for him last cycle
<seb128> random number but he pings me at least once or twice a week every week
<ogra_ac> so he is obviously able to do proper packaging
<seb128> it does cost me non null time
<persia> seb128, Do you happen to remember what one of them was?
<bdrung> seb128: can you give us the list of these uploads?
<seb128> persia, bdrung: gtk3 today
<seb128> nov. 02 22:19:09 <kenvandine>	seb128, can you sponsor lp:~ken-vandine/ubuntu/maverick/x264/maverick-proposed
<seb128> nov. 09 20:41:23 <kenvandine>	seb128, btw i am just running ubuntu-geoip through pbuilder for natty, then it will be ready to sponsor :)
<seb128> nov. 09 21:37:51 <kenvandine>	seb128, lp:~ubuntu-desktop/ubuntu-geoip/ubuntu is ready to sponsor
<seb128> I might have forgotten about x264 in fact
<seb128> nice example of thing that would have been uploaded if it was not blocked on me
<kenvandine> seb128, i think you did, and pitti saved the day :)
<seb128> ok, great, I though I might just have zapped it ;-)
<bdrung> seb128: gimme the list (pointing to the uploads like https://launchpad.net/ubuntu/+source/gtk+3.0/2.91.4-0ubuntu1 ) would convince me
<bdrung> seb128: this list is missing on his application
<seb128> bdrung, I changed laptop recently and don't have IRC logs over this month now
<seb128> bdrung, I don't even see why you need it
<seb128> ken clearly has showed he can be trusted with uploads
<seb128> which does it matter if he use that right often or not?
<seb128> it's wasting us hours every cycle to not have him having upload rights, that's not like we could use with extra hands
<geser> for me having a list of sponsored uploads (direct or indirect (e.g. requested rebuilds)) would be a proof that someone has a "need" for core-dev uploads right and not just the skill but no current use for them
<persia> seb128, It's not just about kenvandine: it's about every applicant.
 * ogra_ac really doesnt get that discussion, we have someone who *obviously* is good at packageing, he offers to help in other areas and we refuse ?!?
<bdrung> seb128: that's the Chicken or the egg dilemma
<seb128> persia, well same applies to everybody
<ogra_ac> we havent been that picky in the past
<seb128> why should somebody with technical and social skills to be part of the team not be in?
<geser> ogra_ac: we haven't had packagesets in the past
<seb128> just because it doesn't help every day?
<persia> seb128, Sure.  Historically, we've expected people to demonstrate their work by getting sponsored.  I'm not sure that's broken.  I'm having difficulty finding recent examples of that happening for kenvandine.
<ogra_ac> geser, no, but do we need to add extra bureaucracy ?
<kklimonda> for some reason the discussion reminds of the medieval age and apprenticeship from back then...
<seb128> persia, it doesn't work lot out of desktop, does it mean it shouldn't be welcome?
<persia> There are *other* reasons kenvandine would benefit from being core-dev, but I'm not yet convinced they are sufficient (uploading new packages, working on stuff in universe).
<seb128> persia, I would be assigning him desktop tasks I can't assign him now if he could upload
<Riddell> mvo: I don't suppose you know what's wrong with this upgrade bug 680088 ?
<ubottu> Launchpad bug 680088 in update-manager (Ubuntu) "Upgrade fails "Can not mark 'kubuntu-desktop' for upgrade "" [Undecided,New] https://launchpad.net/bugs/680088
<ogra_ac> if someone has obviously the tech skills it should really be a non-issue
<seb128> persia, he would spare me sponsoring work as well
<geser> seb128: so everyone with the needed skills should become core-dev because he *might* need them in future?
<ogra_ac> if he/she asks for them, why not
<seb128> everybody who has contributed to ubuntu in a significant way yes
<ogra_ac> he/she can be a patch pilot
<seb128> that's what debian does and what we used to do
<ogra_ac> etc
<seb128> uploads right doesn't hurt
<seb128> they can only be useful
<ogra_ac> ++
<seb128> he might sponsor once a month
<bdrung> i think geser and i share the same concern. i have to leave now.
<seb128> it's still a win
<bdrung> ogra_ac: you don't be a core-dev to be patch pilot
<seb128> kenvandine, has uploaded hundred of packages to main
<persia> You don't even have to be a developer
<seb128> it's not like he was not contributing
<persia> It's not about "main".  It's about "core"
<seb128> same differenc
<persia> Except it's not: it's also about new packages and universe, which complicates the picture.
<seb128> being able to help where help is needed
<ogra_ac> bdrung, you need to be core-dev for being a patch pilot for all core-dev packages
<persia> No, not at all.  There's *lots* of stuff in main that isn't in core.
<ogra_ac> its only a win
<seb128> we need people who have skills to help out of their usual set
<persia> ogra, No you don't: a huge number of patches are better addressed upstream.
<ogra_ac> the criteria should really be tech based
<ogra_ac> rarther than artificial political issues imho
<ogra_ac> if he is technically capable and wants to help, let him do
<persia> ogra, Which artificial political issue?
<cjwatson> for the record, the patch pilot programme is intended to include things like poking people to follow up on patches, making sure people get a good first response and are directed to the right place to discuss their work, etc.  there's no need to drag that programme into this.
<ogra_ac> persia, dunno, obviously there is no tech issue blocking here
<geser> it's not political for me; I just prefer to give a person the rights that he really needs (just like access in security)
<seb128> geser, well it means you are blocking all people working on specific sets to help
<seb128> you should remove my rights to upload out of desktop going this way
<mvo> Riddell: I commented in the bugreport, it complains about libkephal4/plasma-netbook
<seb128> I'm doing 95% of my work in desktop as well
<seb128> I'm just not sure what you would win by doing that
 * ogra_ac doesnt want to have such a discussion for every member of the arm team in the future 
<ogra_ac> and we dont have a single package set
<seb128> I think I will just recommend desktop people to not try to work out of desktop
<seb128> seems that's not welcome
<ogra_ac> i.e. every team member would have to be core dev
<ogra_ac> yeah
<seb128> way to drive contributors away
<ogra_ac> its a weird setup imho
<persia> seb128, Rather, if there is history of work outside desktop, upload rights outside desktop are easily granted.  Without any prior history, it's uncertain.
<seb128> "sorry but they don't like people who focus on a set"
<persia> That's not at all the case.
<seb128> it is
<geser> seb128: I'm not strict on how many uploads one does outside his package set, but at least show that ones does them
 * persia is having trouble finding *one* for maverick or natty
<ogra_ac> persia, but why has there to be any history ? tech skills should be enough
<seb128> persia, I just gave you 3
<seb128> persia, for kenvandine
<kenvandine> gtk3 today
<seb128> gtk3 today got rejected
<seb128> x264 in maverick-proposed
<ogra_ac> and the expressed will to help out with more
<persia> Ah, rejected.  Excellent.
<persia> Why was it rejected?
<kenvandine> perms
<kenvandine> gtk3 isn't in the desktop set yet... so now i need seb128 to sponsor it for me
<kenvandine> even though i applied almost the same patch to gtk2 and uploaded that
<chrisccoulson> gtk2 isn't either is it? seb128 had to do a gtk2 upload for me last week
<kenvandine> so until gtk3 gets added to the package set, i need to interupt someone with changes
<kenvandine> chrisccoulson, i uploaded that fine on friday
<chrisccoulson> oh
<geser> that would be proof enough for me (as I expect that this won't be the only upload to the core set)
<seb128> Signed-By: Didier Roche <didrocks@ubuntu.com>
<seb128> https://launchpad.net/ubuntu/maverick/+source/compiz/1:0.8.6-0ubuntu8
<seb128> ^ another one
<chrisccoulson> i've got no idea what i can upload really, it seems a bit hit-and-miss
<kenvandine> edit_acl.py is your friend
<kenvandine> :)
<geser> desktop might be a little bit special in this regard thanks to the intermix with core
<chrisccoulson> kenvandine, oh, you're right
<kenvandine> geser, right... ultimately the stuff i work on could be anything that ends up on the desktop CD
<chrisccoulson> so, i could have uploaded it myself then
<persia> chrisccoulson, `./edit_acl.py -P ubuntu-desktop -S natty query` would show you the list of desktop packages.  Dunno if you have other packagesets offhand.
<cjwatson> this bites desktop a lot because there's a lot of overlap between Ubuntu and Kubuntu desktop that one or the other side maintains
<seb128> Signed-By: Martin Pitt <martin.pitt@ubuntu.com>
<seb128> https://launchpad.net/ubuntu/maverick/+source/x264/2:0.98.1653+git88b90d9-3ubuntu1
<persia> geser, What intermix?  The exceptions lists?
<geser> yes, that several packages that "belong" to the gnome desktop are in core
<geser> I guess this is less a problem for e.g. mythbuntu
<seb128> well still, we could assign him sponsoring bugs to review for example if he was able to upload
<seb128> or helping on transitions for soname changes
<geser> I'm happy with any proof that one will use that uploads right and just doesn't apply because it's "nice to have"
<ogra_ac> or any other transitions
<seb128> those cases don't show upload in uploads before because they are tasks that don't make sense when you need a sponsor
<geser> that's part of how I understand the whole ArchiveReorg
<seb128> you create a chicken egg issue there
<seb128> we can't get people to help on those because to be able to help they need upload rights
<ev> superm1: I'd like to keep things consistent with the existing interface, if possible and avoid superfluous checkboxes.  We should pick a singular outcome and structure the documentation around that.  This is automatic partitioning, after all.
<ev> oh, when you said checkboxes did you mean bullet points?
<superm1> well i was thinking checkboxes, but bullet points might make more sense if it is automatic
<geser> seb128: that mustn't be necessarily sponsored uploads, I would trust a word from you that you sponsored uploads for him (without any visible LP record9
<seb128> I sponsor at least an upload for him a week
<superm1> but the important bit was relaying what the outcome would be before doing it since it could have different results depending on web access and for different people
<seb128> that every week in the cycle
<geser> for me that would be sufficient
<geser> (the word from you)
<seb128> we add comments from pitti and me at least on kenvandine's wiki
<seb128> add -> had
<kenvandine> and didrocks
<kenvandine> all wrote endorsements :)
<seb128> not sure what else is needed there
<kenvandine> thx guys
<seb128> kenvandine, np ;-)
<persia> Examples of work would have been nice, and saved the confusion.  Turns out my issue was not querying on the "desktop-core" set.
<ogra_ac> to me this process looks really scary and broken to be honest
<geser> I didn't read the application page yet and didn't attend the DMB meeting, will follow-up with my vote to the DMB later
<seb128> geser, thanks
<seb128> still seems artificially hard
<ogra_ac> ++
<seb128> kenvandine does over an hundred upload a cycle and had endorsement from 3 active ubuntu members
<persia> ogra, The process is basically: do something, get sponsored, ask for upload rights, get upload rights to the stuff you had sponsored work on (typically by packageset)
<ogra_ac> persia, yeah, thats broken
<seb128> well it doesn't solve the need to have people being able to work on things out of specific sets
<seb128> or to help there
<persia> This oughtn't be overly hard or complicated.  Sometimes the tools are confusing, or we make mistakes.
<ogra_ac> if i have the skills and am willing to help out, even if i didnt yet, i should be granted access
<persia> ogra, Which part is broken?
<seb128> especially that set are buggy
<ogra_ac> the tech skills should be all that rules here
<seb128> we have chrisccoulson and kenvandine hitting set issues every week
<seb128> it's costing us a lot of energy
<cjwatson> I'm not being asked about this every week
<cjwatson> and I wonder why not
<seb128> those might not been "issues" than "technlogogies used in kubuntu, xubuntu, etc as well"
<persia> seb128, If the set is buggy, we should fix that.  If we're having consistent set issues, we should describe the class, and fix that.  Fixing on a per-person basis doesn't scale.
<kenvandine> cjwatson, just us needing sponsoring
<seb128> cjwatson, because often those are cross desktop techs
<seb128> dbus, libnotify, etc
<cjwatson> seb128: ok ... but you're saying the set is buggy.  which is it?
<cjwatson> either it is buggy, in which case the bugs should be reported, or it is not
<seb128> "buggy" might be wrong
<kenvandine> buggy might not be the word
<seb128> it's just that we touch techs which impact on other sets
<ogra_ac> the policy is buggy imho
<cjwatson> ogra_ac: conflicting requirements
<cjwatson> makes it hard to keep everyone happy
<seb128> cjwatson, ideally chrisccoulson and kenvandine would have access to cross desktop techs
<persia> ogra, How do you recommend we judge other than on prior work?
<pitti> seb128: (which would make them eligible for core-dev IMHO)
<cjwatson> one suggestion would be to have both Ubuntu and Kubuntu desktop folks have upload access to the desktop-core set
<ogra_ac> persia, do a techincal only judgement of the skills
<cjwatson> that might ease the pressures without being one-sided
<kenvandine> the set probably is good for most people, but some of us touch a wide array of pieces
<persia> seb128, That's being core-dev, which is fine.
<persia> ogra, Based on what?
<seb128> pitti, well, the issue there is that persia, geser and bdrung think kenvandine doesn't work enough out of desktop to warrant that
<ogra_ac> persia, exposing the proper skills of former work and expressing the will to help should be enough
<cjwatson> wait, geser doesn't seem to have expressed a definitive opinion yet
<persia> seb128, I said I couldn't *find* the work.  I've found it now (I was looking in "core", and it's in "desktop-core")
<seb128> persia, not it's not, we are arguing over an hour now because you said kenvandine's doesn't need it
<cjwatson> and persia explicitly abstained
<chrisccoulson> having access to desktop-core would help me quite a bit. most of the stuff i find i can't upload is in desktop-core
<cjwatson> (actually, bdrung also abstained)
<seb128> ok, so maybe what we need is desktop members to have access to desktop-core
<seb128> would that be doable?
<geser> seb128: that's not what I been trying so say, all I want is some proof that someone is working outside a package set
<persia> seb128, I never said that.  I said that from what I could find, he hadn't done *any* work in the area to which he wished to be granted upload access.  This turns out to have been a problem with my tools.
<cjwatson> I think the DMB would have to agree on it, but it's certainly technically possible.  As I say I think that it should be both Ubuntu and Kubuntu though (the desktops in main)
<seb128> persia, ok
<cjwatson> (meeting)
<kenvandine> doesn't solve new packages and such
<kenvandine> but would cover more for sure
<persia> I'd rather keep that to core-dev, personally (and I don't mind granting core dev to people working on that set, with some demonstrated work)
<seb128> right, it's still annoying in quite some case
<seb128> like the GNOME3 new sources landing regularly in natty
 * ogra_ac totally agrees
<Laney> they can easily be added to the sets
<kenvandine> not before they are uploaded
<chrisccoulson> kenvandine, yeah, that probably helps me more than you, because i can already upload to universe :(
<persia> kenvandine, Indeed: it's the new packages problem and the not-yet-in-the-packageset problem that made me almost vote for you to be core-dev *even though* I couldn't find the examples.  I'm glad I found them.
<seb128> speaking of which what is the official way to have things added to a set?
<seb128> out of pinging cjwatson on IRC ;-)
<persia> seb128, It's supposed to be ask an archive-admin, but in practice it's ask cjwatson.
<Laney> not archive-admin, member of owning team
<chrisccoulson> and it doesn't help the fact that i still can't target bugs in packages that i can upload (or maintain) to a particular release
<seb128> I was asking to try to avoid pinging cjwatson directly
<persia> And ideally, the archive-admin request is in a bug.
<seb128> chrisccoulson, you should apply for core rights
<persia> chrisccoulson, That7s a different issue.  Isn't it targeted to get sorted soon?  I thought I heard things at UDS about it being on the short-term list.
<geser> any TB member can add packages to TB owned packagesets (the are only DMB owned packagesets)
<Laney> You can email the owner of the set (I think they are all TB or DMB owned)
<seb128> Laney, where do I find the owner of a set?
<chrisccoulson> seb128 - i was thinking about it until i saw this discussion today ;)
<persia> Did the bug in LP that limits changing stuff to the TB get fixed?
<seb128> persia, see what you did :p
<chrisccoulson> i think that the DMB members will have all the same objections with my application (i do 95% of my work in desktop or mozilla)
<seb128> you made chrisccoulson not to apply! ;-)
<geser> seb128: through the LP API (owner attribute of the package set)
<Laney> seb128: set.owner attribute
<Laney> actually I patched edit_acl to display that locally
<Laney> can push a branch if you want to merge it
<seb128> hum
<seb128> I will let other people deal with that
<seb128> but seems the reply is "there is no easy way out of writting code to query launchpad"
<persia> chrisccoulson, We don't care about the 95%: we care about the 5%: if you have work that you did in core or desktop-core, and you list it on your application page, there will be little confusion, and you'll just get approved or rejected for something other than the areas of your work.
<Laney> the LP web UI is lacking when it comes to package sets, indeed
<seb128> chrisccoulson, joke aside you should apply
<Laney> I would love the +source page to display them for example
<seb128> I think the confusion was mostly that they didn't consider desktop-core
<seb128> chrisccoulson, should be easier for you now that this one is sorted
<persia> Laney, That7s been requested, for the Soyuz ArchiveReorg spec from this last UDS.
<Laney> persia: yeah, I know (or I'd be filing a bug)
<geser> some web-UI for package sets would be nice (a little overview and the like)
<persia> seb128, My confusion was that I didn't consider desktop-core.  I can't speak for anyone else (and some DMB members voted in favour, just not enough to confirm during the meeting)
 * ogra_ac still would like to rather see the policy fixed
<persia> ogra, Would you prefer to grant upload access to people with no demonstrated experience?
<ogra_ac> persia, no
<persia> Then why do you suggest that we shouldn't use demonstrated experience as a criterion?
<seb128> "not uploading out of a set" != "not showing experience"
<ogra_ac> persia, but if i have rights for packageset A and have proven that i'm technically capable, requesting sponsoder proof for packageset B if i express interest in that packagset is nonsense
<seb128> you can do all your work in a set and demonstrate enough experience to be trusted with uploads
<geser> ogra_ac: I don't believe that the policy has changed much, only that the packagesets made it more hard to show the expierence in the area where one wanted to have upload rights
<ogra_ac> the *technical* skills should be all that matters here
<persia> I don't think it's more hard.  It's the same.
<persia> ogra, So everyone should be core-dev, with no distinctions?
<seb128> geser, well we should be able to say that someone showed enough skills to be able to work out of one specific set
<ogra_ac> its not, since you refused to grant rights without sponsored proof right above
<seb128> persia, those who showed enough experience yes
<seb128> if they ask for it
<persia> seb128, How do we judge that except by them showing they did work outside the set?
<seb128> if people are happy in their set no
<ogra_ac> persia, everyone who has the skills sould be *easily able to* become core-dev, yes
<seb128> persia, how is the work out of the set different from the work in the set?
<ogra_ac> you are making the process overly complex
<ogra_ac> while only the tech knowledge should matter
<seb128> persia, the packaging doesn't change because you are out of a set
<persia> seb128, Shows integration with wider communities of developers.  Shows consideration for other packages that depend on the packages being worked upon.
<ogra_ac> and the tech knowledge was judgeable by existing work
<ogra_ac> sponsored or not
<seb128> you still use the same infrastructure, debian packaging, launchpad, etc
<persia> No?  Compare Java packaging to GNOME packaging some day :)
<seb128> persia, java-gnome bindings?
<seb128> you have java in desktop as well
<persia> That's packaged GNOMEy, but sure.
<ogra_ac> persia, know what ? i'm core-dev and wouldnt touch java packaging with a ten foot pole
<ogra_ac> do you want me to withdraw from core-dev now ?
<ogra_ac> into some package set ...
<seb128> I was asking the same before
<geser> no
<cjwatson> this is getting a bit emotive
<persia> ogra, No.  You've demonstrated that you won't touch Java with a 10 foot pole, so I feel safe about you and java
<ogra_ac> cjwatson, i'm cool sorry if i dont sond like
<ogra_ac> persia, right, so why should that matter for someone becoming core-dev then
<ogra_ac> ask him/her in the DMB meeting if he/she would touch java
<seb128> persia, well you can show that you are reasonable and would not touch things you don't understand while working in a set
<ogra_ac> but judge his/her tech skills based on existing work
<ogra_ac> without the requirement to having sponsored packages to the future set he/she is intrested in
<ogra_ac> the existing work should be enough for that
<dholbach> I think trust is important - if I trust somebody to know where to stop and where to ask that's one of the most important things (plus statements from others who worked with them, etc.)
<ogra_ac> right
<ogra_ac> more important than sponsored uploads
<ogra_ac> and trus is something you have to build up *without* the tech skills
<persia> Trust is indeed important, but I have to wonder how much trust someone has if they can't find any work to do or anyone to sponsor their work in their target area.
<ogra_ac> and whichch should be based on testimonials
<persia> And while I try to know everyone, I know that I fail, and I am certain I'm not alone in that failure.
<ogra_ac> sure, and you dont have to
<ogra_ac> thats why we got wiki pages
<geser> should everyone from the the "kernel" set get upload rights for "core" because we trust them with kernels?
<seb128> persia, taking kenvandine's case you got pitti didrocks and me saying he does nice work
<ogra_ac> geser, if he knows packaging good enough, yes
<seb128> geser, no, but when you get 3 people from the set giving you recommendation you would consider that enough
<pitti> geser: do you trust me with kernels? (you certainly shouldn't)
<persia> I'd much rather focus on making it easy for folks to demonstrate their work in other areas than make granting of upload rights a popularity contest.
<ogra_ac> indeed for the kernel thats hard to judge, there wont be many different packages to review
<pitti> geser: just as a point that there can't ever be the perfect core-dev
<apw> heh, you want to make sure this conversation is stricken from the logs, else noone will ever bother applying for core-dev again
<pitti> in practice, everyone knows just a subset of everything
<ogra_ac> pitti, nontheless you can upload one if you want ;)
<geser> ogra_ac: then why do we the whole package set business at all? just having motu and core-dev like in the old days would be much easier
<pitti> well, unless you are cjwatson, of course
<persia> ogra, So what kernel folk do is peer-review for the first few uploads, and then bring the demonstration to the DMB, and get a new kernel uploader.  It's just collaboration.
<seb128> geser, because some people are desktop contributors only
<seb128> they don't want or need anything else
<seb128> we have people who want to be able to do GNOME updates
<seb128> it's an easier way to start
<ogra_ac> geser, i dont say package sets are wrong
<seb128> desktop being once example
<ogra_ac> but the artificial threshold you put in place is
<seb128> some people might be just interested in xubuntu
<persia> seb128, So, if you have folk in the desktop team who need wider access, just make sure they get some stuff sponsored (you say you do this already), make sure that the examples show on their applications, and they are likely to easily be approved as core-dev.
<seb128> then you get people over time that might feel like doing work out of the set
<persia> With no examples, and difficulty finding any work, it's a more complicated discussion.
<seb128> persia, well I still fail to say why we need those if you have several trusted people who worked with them and said they would be useful contributors out of the set
<ogra_ac> geser, if there is enough work to judge on, why do i need sponsored uploads to the target set i want to enter ? i have already proven my skills enough before
<seb128> persia, gotcha on how to get people approved easily
<persia> And the example that raised this is not a good one, as it came from a misunderstanding on one person's part as part of an *incomplete* DMB vote.  No application was deferred.
<seb128> I still think you are putting some requirements which are not needed
<ogra_ac> persia, no, its a good one
<kenvandine> the tough thing for me is there are lots of examples of my work that didn't need sponsoring, because of the the package set
<seb128> persia, you might have people who could help with transitions or sponsoring
<ogra_ac> since you guys asked for sponsored uploads to the future target set
<ogra_ac> which is a big flaw imho
<seb128> they will just not do as long as they can't upload
<seb128> because they then need to find themself a sponsor
<persia> ogra, Why?  it7s an *incomplete* vote.  Even without this discussion, kenvandne may have become core-dev.
<seb128> which is costing as much work they spared
<geser> ogra_ac: so everyone who can package gnome ("desktop") should get access to "kubuntu" just by asking? because he knows how to package?
<ogra_ac> geser, if he can prove he knows how to package, why shouldnt he ?
<seb128> geser, if we trust him to not upload without asking there, etc why not?
<persia> seb128, I actively don't want folk working on sponsoring if they have no experience in the target area.  I7d rather they chase the random patches not ready for sponsoring and get them tested and in shape.  There's *lots* of non-sponsoring work to be done, and I don't think the primary activity of developers ought be sponsoring (although sponsoring is a welcome part of it).
<ogra_ac> if i'm able to fix a bug in gtkmm, why shouldnt i be able to fix a bug in QT ?
<cjwatson> pitti: (I steer *well* clear of desktop, FWIW ...)
<seb128> persia, well then ignore sponsoring and take transitions as an example
<ogra_ac> cjwatson, it was about abilities ;)
<pitti> cjwatson: nevermind, it was just a compliment :)
<persia> transitions and packagesets interact very badly, unfortunately.
<\sh> persia: +1
<geser> ogra_ac: I believe that only knowing how to package is not enough; I'd expect that he also knows how "kubuntu" works (how the packages interact each other)
<seb128> persia, see you hit limitation which block people in doing work and helping
<ogra_ac> geser, how does that matter to fix an ftbfs in a single package ?
<seb128> would it be launchpad issues, new sources, set definitions bugs, transitons
<ogra_ac> geser, i touched enough kubuntu packages in my ubuntu life and have no clue at all how kubuntu works
<mvo> smoser: re #676790 - this is the natty apt?
<ogra_ac> nontheless i bet people in kubuntu were happy when their packages built
<smoser> mvo, yes.
<\sh> ogra_ac: we all touched a lot of packages where we didn't know how that all works...but that's long time ago...
<cjwatson> Keybuk: (from #ubuntu-meeting) I don't pretend that this would be anything other than a nasty hack, but given how the kernel presently behaves it seems to me that the only thing init can do is try a few times in the hope of winning the race eventually.  Obviously you don't want to block starting other events on that
<geser> ogra_ac: it's also about trust; I don't know how to properly explain it and I'm myself not fully sure where I draw the borders
<cjwatson> s/other events/other jobs/
<ogra_ac> geser, so make it a requirement that someone from the desired package set expresses trust in the wikipage
<mvo> smoser, pitti: it sounds like bug #676790 is releated to the compressed indexes
<ubottu> Launchpad bug 676790 in apt (Ubuntu) "huge performance regression" [High,Confirmed] https://launchpad.net/bugs/676790
<smoser> based on nothing but changelogs, i suspect it has to do with the compression
<pitti> right
<smoser> yeah, that was my suspicion too
<Keybuk> cjwatson: yeah, but in theory init is going to proxy everything anyway
<pitti> I just don't know yet what these image builds do with apt indexes
<ogra_ac> but dont make sponsored uploads a requirement to people who can prove their knowledge already
<cjwatson> Keybuk: remind me: would anything go wrong if pid 1 kept its own master fd on /dev/console (with O_NOCTTY of course) and duped it, rather than reopening for each job?
<\sh> mvo: good that I see you...I don't know if you are responsible, but /etc/cron.daily/apt does some strange apt-key net-update thingy...and it starts wget to get a keyring..without a sane timeout...can we change something there?
<Keybuk> so the fd won't be console anyway
<Keybuk> it'll be a pty
<cjwatson> Keybuk: this is lucid
<Keybuk> and then it'll output that to console later
<smoser> pitti, its nothing strange, i would suspect that a CD install would hit this
<Keybuk> lucid we fixed already
<cjwatson> no we didn't, per bugs
<Keybuk> at least fixed well enough
<smoser> its basically an 'apt-get install some package list'
<Keybuk> what are the bugs now?
<cjwatson> this is why I brought up bug 642555
<ubottu> Launchpad bug 642555 in Ubuntu Lucid "Services not starting on boot in 10.04.1 LTS" [Medium,Confirmed] https://launchpad.net/bugs/642555
<Keybuk> cjwatson: yes, if you SysRq-K you get a kernel panic
<cjwatson> in the meeting where you responded
<Keybuk> if Upstart keeps its own console fd
<cjwatson> I assumed you'd seen it
<cjwatson> ok
<Keybuk> no, I'm not reading bugs anymore
<mvo> \sh: sure, is there a bugreport?
<geser> ogra_ac: for me sponsored uploads are only one way to proof that, a comment from the set "leader(s)" is for me also sufficient
<cjwatson> I assumed you'd seen it *in the meeting log* since you responded there
<cjwatson> I know you aren't reading bug mail
<\sh> mvo: not right now, I wanted to talk to you before :) because some of my servers do have no direct internet connection....and I always see this process hanging and timeouting after several hours whysoever
<ogra_ac> geser, why leaders ?
<mvo> \sh: heh :)
<Keybuk> oh, no, I just have certain highlights ;)
<Keybuk> I was coding
<mvo> \sh: sure, let me quickly check the code
<ogra_ac> and why cant you judge by existing work ?
<\sh> mvo: especially when the firewall drops those packages
<\sh> mvo: I think there needs to be just a --timeout option to wget (60 secs should be enough imho)
<seb128> is grep-dctrl working for other people in natty
<seb128> ?
<cjwatson> there is a lot of plymouth-hatery in that bug, which makes it difficult to pick out the real issue
<Keybuk> well, yeah
<Keybuk> or if there is actually an issue
<geser> ogra_ac: perhaps leaders is the wrong word, more "key persons"; persons who I'd trust from that team and not somebody who just entered into the team in the last meeting or so
<cjwatson> but making sure that there's a console fd would dismiss that part of the question for good
<ogra_ac> geser, agreed, still though, technical knowledge should be judgeable by former work already, i agree on the trust thing
<chrisccoulson> seb128 - it doesn't work here, but i guess that's because the package lists in /var/lib/apt/lists are stored compressed now
<seb128> chrisccoulson, I was wondering about that yes
<seb128> iz pitti bog? ;-)
<chrisccoulson> heh:)
<pitti> chrisccoulson: "it" ==?
<pitti> oh, grep-dctrl
<chrisccoulson> pitti - did you break grep-dctrl? l;)
<geser> ogra_ac: for extending permissions, the technical knowledge often isn't the hard part, for those applications I watch more on comments from "key persons" from the team where one applies
<chrisccoulson> :)
<pitti> chrisccoulson: presumably; can you please file a bug about it and assign to me?
<pitti> (sorry, I'm in meeting, and then off)
<chrisccoulson> pitti - yeah, sure
<ogra_ac> geser, right, what seemed wrong to me above was just the requirement that ken had sponsored uploads to the core-dev set
<seb128> chrisccoulson, I can do it if you want
<seb128> chrisccoulson, I was the one who asked about it ;-)
<chrisccoulson> seb128 - yeah, feel free to do that :)
<seb128> chrisccoulson, ok
<cjwatson> Keybuk: I posted to that bug to try to narrow things down a bit
<pitti> ev: FTR, the UI works, but I have spent an hour trying to track down why the communication with the backend locks up; presumably a threading deadlock, so I pushed the stuff to a branch for now; will get back to that tomorrow
<ev> thanks
<ev> indeed, I should've never gone down the path of threads with that application.
<pitti> it's a pain to debug indeed, but let's see
<pitti> could be that gi/pygobject just isn't thread safe yet, I'll investigate
<pitti> good night everyone
<ev> g'night pitti
<cjwatson> pitti: OK if I just accept this d-i upload?
<bdrung> geser: you said that you found sponsored work from kenvandine - how?
<ari-tczew> bdrung: tumbleweed has a script to looking sponsored bugs
<mvo> \sh: commited the timeout fix to bzr now, thanks for the report!
<\sh> mvo: thx to you...(and I didn't file any report ;))
<mvo> \sh: no worries
<geser> bdrung: did I? persia found it in "desktop-core"
<Sarvatt> is there a way to mark a bug fix in a sync request without doing it in debian's changelog?
<Laney> you can make that bug into the sync request bug
<persia> bdrung, I screen-scraped LP to get kenvandine's uploads, and then compared with the output of edit_acl querying the desktop-core set, and found matches.
<seb128> zul, hi
<zul> seb128: hey
<seb128> zul, do you think you could sru the fix from https://bugzilla.samba.org/show_bug.cgi?id=7791?
<seb128> it's bug #393012
<persia> RAOF, pitti Welcome to the sponsors team :)
<ubottu> Launchpad bug 393012 in autofs "smb: Error while copying file, "Invalid argument"" [Undecided,Confirmed] https://launchpad.net/bugs/393012
<seb128> zul, https://bugzilla.samba.org/attachment.cgi?id=6062&action=view
<zul> seb128: sure
<seb128> zul, thanks
<\sh> oh wow...attachmate wants to take over Novell, and Microsoft wants to get hold on some IPs of Novell...oh wow...this will be fun and I can already read all the FUD news
<seb128> zul, we got quite some users unhappy because smb copies from nautilus are broken in maverick, that should fix it ;-)
<cjwatson> pitti: ... accepting, figuring it's OK
 * smb does not like his copies to be broken
<zul> seb128: gotcha...but they shouldnt be running windows in the first place ;)
<seb128> ;-)
<seb128> zul, thanks!
<ogra_ac> gah, damned, no way back, i'm in the ubuntu-sponsors team
<\sh> ogra_ac: lol...you were in the past, too..well not sponsors, but MOTU
<ogra_ac> (thats like the patch pilot flight license, right ?)
<ogra_ac> \sh, indeed
<persia> ogra, The main power of the sponsors team is the ability to unsubscribe the sponsors team from things no longer of interest.
<ogra_ac> persia, patch pilot license, as i said ;)
<\sh> ogra_ac: I hope the patch pilots don't have problems like the A380 pilots ;)
<ogra_ac> we dont use rolls royce ;)
<ogra_ac> we are launchpad powered instead ;)
<slangasek> SpamapS: bug #582963> so what does the apache2 ask-for-passphrase do if plymouth shuts down in the middle of prompting?
<ubottu> Launchpad bug 582963 in apache2 (Ubuntu Maverick) "SSL pass phrase dialog can't read input" [Medium,In progress] https://launchpad.net/bugs/582963
<geser> ogra_ac: and no eject button :)
<ogra_ac> heh
<Kmos> date
<geser> mvo: added TEST CASE to bug 617885
<ubottu> Launchpad bug 617885 in gparted (Ubuntu Maverick) "gparted crash at start: glibmm-ERROR **" [High,In progress] https://launchpad.net/bugs/617885
<geser> mterry: can you please do a vala-dep-scanner upload soon? so we are one rdepends nearer to kill libvala-0.10{,-dev}
<mterry> geser, ah ok!  a new version is coming out shortly, so yeah
<geser> thanks
<ogra_ac> stgraber, so i managed to get lightspark to build up to the point where it starts linking against the intel SSE assembler code (where it indeed fails). from a packaging POV its easy to add armel support, but the assembler is a huge lot
<stgraber> ogra_ac: ok, cool. And I guess there's no C equivalent for that assembler code (that'd likely make it "unoptimized" but at least work) ?
<ogra_ac> i dont think so
<ogra_ac> the assembler really hooks deeply into SSE, rewriting that is beyond me
<stgraber> is that something anyone at Linaro might be interested to work on ?
<stgraber> I guess it depends on how much you really want a flash implementation and of ongoing discussions with Adobe by the manufacturers (I'm guess there's some as unfortunately flash is usually kind-of a must have :()
<ogra_ac> well, i guess the manufacturers get access to flash internally
<ScottK> cjwatson: re  bug 635273, I don't have a strong opinion.  Depending on what the fix it, it might be ~OK.  I'd make barry figure it out.
<ubottu> Launchpad bug 635273 in python-support (Ubuntu Lucid) "Building debs with SWIG libraries do not work" [High,Confirmed] https://launchpad.net/bugs/635273
<SpamapS> slangasek: you mean the race condition between ping and ask? yeah.. I thought about that when I copied it from some other package. :-/
<ScottK> skaet: Sorry I missed the meeting, an appointment ran over.  One item of note for 10.04.2 is that the Tech Board approved putting KDE point releases in -updates so you can expect Kubuntu to update to KDE 4.4.5 (and 4.4.7 for kdepim) for 10.04.2.
<SpamapS> slangasek: I believe apache2 will fail to start at that point.
<SpamapS> slangasek: its kind of an interesting problem..  we kind of have to have this happen before getty's/X ..
<bdrung> geser: sorry. i meant persia.
<bdrung> persia: can you give me your findings?
<bdrung> Sarvatt: i think the no-source change syncs are useless
<Sarvatt> bdrung: ack, wasn't sure on those because pitti is doing no change reuploads of X packages in main to shrink the livecd size
<bdrung> Sarvatt: when will be the next cd spin?
<Sarvatt> I just requested the ones in xserver-xorg-video-all
<Sarvatt> dunno, I agree they are kind of useless but was trying to help out since I saw him doing that
<jmelis> Hello, is this channel the right place to ask about packaging?
<bdrung> Sarvatt: if pitti wants the rebuilds, then give him the rebuilds. ;)
<bdrung> jmelis: yes
<bdrung> jmelis: maybe #ubuntu-motu is appropriate too
<jmelis> my question is: I have a package, and I have created a system-V init script in the debian folder named <package>.init. I'm working with 10.04. The problem is that after installing the package the init script is not installed in /etc/init.d... How can I debug this? System-V init scripts are still working, or do I have to switch to upstart?
<persia> jmelis, Are you calling dh_installinit?
<skaet> ScottK,  Riddell,   will add that Kubuntu will update to KDE 4.4.5 (and 4.4.7 for kdepim) into the minutes.   Thanks for letting me know.
<jmelis> persia: no. where should I do that?
<jmelis> persia: in the rules file, correct?
<Sarvatt> ok I'll invalidate all the sync requests that aren't new upstream versions then. sorry for all of the sync requests but its a heck of a lot easier to do everything in debian and request a sync since I'm not a core-dev :)
<persia> jmelis, Yes, in the rules file.  If you're using dh(1), it's probably automated.  If not, it's usually done in the install: rule, somewhree around dh_installmenu
<bdrung> Sarvatt: no, you misunderstood me
<jmelis> persia: can you point me to a guide that explains this? I haven't had much luck finding one...
<Sarvatt> how so? from what I understood you think it'd be better to do a no change rebuild instead of syncing something like this? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-tdfx/+bug/680110
<persia> jmelis, Erm, I don't tend to do it manually, but ask in #ubuntu-packaging, and I'm sure someone can take you through it step-by-step
<jmelis> persia: thanks a lot!
<persia> Sarvatt, If that upload was needed in Debian, doesn't make any difference which way you do it.  Note that things in sync will autosync, so sometimes no request is required.
<jmelis> i'll give it a shot myself, if it doesn't work I'll go to #ubuntu-packaging
<persia> Heh, OK :)
<SpamapS> slangasek: In looking at this, I don't know if we'll have other services like this, but in this case we have to make sure that apache starts before plymouth is stopped. Can we somehow wait in plymouth-stop for apache?
 * persia isn't as sure of being active in #ubuntu-packaging later
<SpamapS> it would appear to me that plymouth quit could be called from several locations.. :-P
 * highvoltage somehow didn't know about #ubuntu-packaging before now
<SpamapS> highvoltage: me too :p
<bdrung> Sarvatt: i thought that syncing a no-change version from debian has no benefit, but if a rebuild is really desired, it's ok
<bdrung> Sarvatt: if pitti wants the rebuilds, then give him the rebuilds by syncing from debian.
<Sarvatt> bdrung: either way works, it's just easier for me to request syncs than find sponsors for all of the no change rebuilds so I did it that way for packages in xserver-xorg-video-all and I completely understand if a no change rebuild would be preferred, no problems doing it that way instead here outside of it being a lot harder to find sponsors :)
<bdrung> Sarvatt: but i prefer a sync over a no change rebuild :)
<bdrung> Sarvatt: we have ack-sync for sync requests and sponsor-patch for everything else. so there is no big difference from the sponsoring side of view
<bdrung> Sarvatt: processed all sync requests - all were fine
<Sarvatt> bdrung: thanks a ton for that!
<bdrung> Sarvatt: np
<Sarvatt> sorry to dump so many sync requests in there, unstable is being reserved for squeeze on the driver side and everything's being done in experimental
<bdrung> Sarvatt: no problem. we can live with that. in the lucid cycle, we had to requests syncs from unstable. ;)
<bdrung> all sync requests processed
<SpamapS> hmm... is there a way to lock plymouth so it won't exit after 'plymouth quit' until you've unlocked it?
<SpamapS> that would work to make sure plymouth is around to enter the SSL pass phrase...
<SpamapS> hmm.. I actually need it to also not deactivate
<SpamapS> I wonder if pause-pogress would work
<slangasek> SpamapS: I don't see any sane way to wait in plymouth-stop for apache to start.  For now, perhaps open a new bug report against the package to document this know issue?
<slangasek> +n
<bdrung> BlackZ: libgphoto2-2.4.10.1 fails to build: Unmet build dependencies: libgpmg1-dev - but libgpmg1-dev is there
<BlackZ> bdrung: it's related to build-dependencies with [linux-any], if you want, patch your pbuilder ( see http://bugs.debian.org/363193 )
<BlackZ> bdrung: it's fixed in the launchpad buildd AFAIK
<bdrung> BlackZ: the merge will took more time (this bug and big diff). ask the patch pilot instead or ask me tomorrow again.
<bdrung> BlackZ: i sponsored enough today.
<BlackZ> bdrung: heh, will do :)
<bdrung> BlackZ: look at that spice in the first graph: http://reports.qa.ubuntu.com/reports/sponsoring-stats/
<BlackZ> bdrung: uh, cool!
<micahg> very cool :)
<bdrung> crimsun: can you reassign bug #678183 to the correct package?
<ubottu> Launchpad bug 678183 in vlc (Ubuntu) "audio-only playback always stops after 1.5 minutes on any file types" [Undecided,Invalid] https://launchpad.net/bugs/678183
<Awsoonn> hi all, what package is the network proxy config tool in?
<hallyn> upstart question.  Is it actually the case that if package X installs an /etc/init/X, that its removal should not remove /etc/init/X?  (I wouldn't have thought so)
<cjwatson> not particularly upstart-specific
<soren> hallyn: It's got nothing to do with upstart. It's all dpkg.
<cjwatson> in general, files in /etc are conffiles and are only removed on purge
<hallyn> oh, ok.  so --purge should remove the conffile at least?
<cjwatson> yes
<soren> hallyn: this is also why most init scripts (sysv style ones, that is) almost always have a check for the presence of the daemon they're supposed to start.
<hallyn> ok, thanks guys.
<soren> hallyn: Sure.
<hallyn> oh, so does dpkg do it automatically for debian/*.upstart files?
<soren> hallyn: Not that I know of.
<ebroder> hallyn: debhelper does it automatically for files installed into /etc
<soren> ?
<soren> Sorry, then I don't understand the questoin.
<cjwatson> indeed, at debian/compat level 3 and above
<soren> hallyn: What is "it" in your question?
<ebroder> soren: dpkg determines what should be removed at purge vs. uninstall based on a "conffiles" file in the control information (i.e. DEBIAN/conffiles or /var/lib/dpkg/info/foo.conffiles)
<soren> ebroder: I know.
<hallyn> soren: sorry, i meant removing the init scripts
<hallyn> but dh_installinit manpage i *think* answers that
<soren> hallyn: That's what I thought. Then no. It doesn't.
<hallyn> hm, dh_installinit says it sets up postrm commands...
<ebroder> hallyn, soren: Err, sorry - I think I inverted the question when I answered it
<soren> hallyn: It removes the rc?.d/ links.
<hallyn> soren: yeah that was my first interpretation, but that doesn't help :)
<hallyn> ebroder: meaning it does not?
<hallyn> all right - thanks guys, at any rate it's not quite what i expected, sadly, and i know what i need to do :)  thanks
<ebroder> hallyn: debhelper will mark /etc/init/* as a conffile. dpkg will only remove conffiles when the package is purged
<soren> hallyn: debian/*.upstart are installed as upstart jobs. They land in /etc and are handled like any other conffile.
<hallyn> ok, so still --purge removes them
<soren> hallyn: "conffile" is a very specific term here.
<soren> hallyn: Different from "config file".
<soren> hallyn: That may not be completely obvious.
<hallyn> it's not
<soren> hallyn: Right. So when people talk about this stuff, "conffiles" is a term used to describe a set of files that dpkg handles in a very specific way.
<soren> hallyn: For almost all packages that use debhelper (which is almost all of them), this set includes all files shipped in /etc.
<soren> hallyn: Others can be added to the set. It's reasonably rare, though.
<soren> hallyn: "shipped in /etc" is also a pretty specific phrasing. Some packages end up having files in /etc that aren't conffiles.
<soren> hallyn: They do this by shipping the file in /usr/share somehwere and then copying it into /etc at postinst (or preinst, I suppose) time.
<hallyn> soren: ok, thanks.  and i presume the idea is that those should be preserved as much as possible?
<cody-somerville> ugh
<cody-somerville> why am I getting ubuntu-desktop team bugs now? :(
<cody-somerville> oh wait, thats the mailing list
<soren> hallyn: Sorry, i don't understand the question.
<hallyn> soren: well, between package upgrades, and temporary removals, etc, the conffiles are treated specially so that local customizations are preserved
<hallyn> (i was just blabbing, ignore me)
<ScottK> hallyn: It's described in debian-policy.
<Gulfstream> What language is Ubuntu written in? I am thinking about simply changing the name... WHat language skills are needed?
<cjwatson> Ubuntu is made up of lots of different pieces of software written in quite a few different languages
<cjwatson> the primary ones, depending on how you count it, are probably C, Python, POSIX shell, C++, Perl, a few others
 * ogra_ac thinks shell comes before python :)
<hallyn> ScottK: thanks, bookmarked.  will be reading that
<ogra_ac> if the order is based on most freqently used langs
<Gulfstream> which language is best for fixing Ubuntu?
<ogra_ac> you need to really look at the piece of ubuntu you want to fix
<ogra_ac> (i.e. the package that has the issue)
<ogra_ac> and find out which language this uses
<Gulfstream> okay
<Gulfstream> Which language would you recommend someone learn?
<ogra_ac> shell and C would likely be a good start ....
<ogra_ac> but thats personal preference
<sladen> Gulfstream: pick a goal, and then work backwards to see how to achieve it
<ogra_ac> some pepole would probably recomment to start with python
<ogra_ac> yeah, what sladen says makes sense
<sladen> Gulfstream: perhaps investigate some of the "papercuts" bugs.. some of those are as simple as changing a string (eg. menu item) to be more accurate
<Gulfstream> Okay
<Gulfstream> is C# used much?
<cjwatson> there's some, not lots in the core
<cjwatson> we ship a couple of applications by default that are written in C#
<Gulfstream> Thanks for the info... I will see what I can learn
<hunger> Gulfstream: "Our" C# is using different libs than would normally be used on windows... so do not spend too much time on the ui stuff when wieding a windows book:-)
<SpamapS> slangasek: The bigger issue is that when we write an apache upstart job, we are going to have to revisit the non-plymouth passphrase dialog... :-P
<slangasek> oh, this isn't even an upstart job yet?
<ebroder> SpamapS, slangasek: Isn't the bug that plymouth will willingly exit when a client is in the middle of an ask-{for-password,question} command?
<SpamapS> actually I don't think it will
<SpamapS> its that gdm may start before apache has asked for a password
<SpamapS> ebroder: I'm trying to grok plymouth's code/docs to verify that.. or to figure out how to play with it without having to constantly restart a vm
<ebroder> SpamapS: At least with plymouth-x11, "plymouth quit" will cause plymouthd to exit, and the plymouth clients get an error
<ebroder> SpamapS: Install plymouth-x11, then do sudo plymouthd and sudo plymouth show-plash
<ebroder> *show-splash
<NCommander> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: NCommander
<geser> cjwatson: (/me reading the meeting logs) I've no problems to access packagesets information over LP API with anon login. Or is a specific method failing?
<jono> NCommander, did you just sign in for your patch pilot work?
<SpamapS> ebroder: ahh, you're my hero. ;)
<NCommander> jono: yeah.
<jono> NCommander, cool, thanks!
<NCommander> jono: I can't upload though
<NCommander> jono: at least not today
<jono> NCommander, no worries, if you can review patches that is fine
 * NCommander does not have a working card reader so no GPG keys, I can put stuff in my queue however to upload when I can
<jono> and help people get in touch with the right folks
<jono> cool
<jono> thanks NCommander :-)
<ajmitch> NCommander: you're the lucky person first up for it? :)
<ebroder> ajmitch: mvo went earlier
<jono> ajmitch, mvo was
<jono> :-)
<ajmitch> aha
 * NCommander generates a temporary GPG key for thsi laptop so I can upload
<NCommander> BAH :-P
<cjwatson> geser: I tried making edit_acl.py use anonymous login for query and it fell over in some way I forget
<cjwatson> geser: if you can make it work, send me a patch :)
<cjwatson> --- ChangeLog   2010-08-04 03:43:05 +0000
<cjwatson> +++ ChangeLog   2010-11-22 13:33:13 +0000
<cjwatson> @@ -1,3 +1,4041 @@
<udevbot> Error: "@" is not a valid command.
<cjwatson> yow, grub is not a particularly quiet project
<geser> cjwatson: will give it a try, the FTBFS page is also using anon LP API login and can access packagesets data. I'll look what breaks.
<cjwatson> I may just have been being stupid
<SpamapS> ebroder: does plymouth-x11 allow typing in answers to ask-question btw?
<SpamapS> ebroder: mine seems not to
<ebroder> SpamapS: I can get ask-for-password to work, but not ask-question
<SpamapS> ebroder: hmm.. so.. plymouth quit doesn't seem to kill it ... just blocks actually
#ubuntu-devel 2010-11-23
<ebroder> Spamaps: ...weird. It definitely killed it for me
<ebroder> NCommander: Did you manage to summon uploading capabilities? I was hoping to harrass the patch pilot into sponsoring bug #601732 :)
<ubottu> Launchpad bug 601732 in update-inetd (Ubuntu Maverick) "postinst using both update-inetd and debconf hangs on first install" [Undecided,New] https://launchpad.net/bugs/601732
<NCommander> ebroder: I'm not a core dev.
<NCommander> ebroder: MOTU and some Kubuntu
<ebroder> NCommander: Oh, didn't realize. No worries then
<Riddell> NCommander: if something needs uploading I'm sure there are people who would help the friendly patch pilot to do that
<NCommander> Riddell: if I review the patch, would you be willing to upload?
<Riddell> NCommander: yes
<NCommander> ebroder: this looks sane (and important) and my netbook is running maverick, so I'll test and review there
<NCommander> Don't have a lucid system thats currently functional so I can't easily test there
<abuDawud> New dev here, I found a bug and patched it but the original package reported differs from where I found the actual issue and patched it
<abuDawud> does someone have a minute to go over this with me?
<abuDawud> and when I say patched it, I mean I just found the code and corrected the issue. I haven't actually created a patch, cause well... derp
<NCommander> abuDawud: sounds like the bug was reported against a previous release (or pre-release version) and you fixed it in a later one
<abuDawud> NCommander, the package it was reported against was Apport, but I found the issue in apport-symptoms.
<bdrung> kirkland: how to progress with bug #427612? should i wait for a review by upstream or should i add the patch to the ubuntu package?
<ubottu> Launchpad bug 427612 in qemu-kvm (Ubuntu) "kvm sends caps lock key up event twice" [Low,New] https://launchpad.net/bugs/427612
<NCommander> abuDawud: sounds like pitti (apport's upstream) split the package in maverick or natty.
<bdrung> kirkland: will it reviewed by upstream or is there something to do for me?
<Ian_Corne> 7-
<NCommander> abuDawud: so what you need to do is when you make a patch is properly file it against both the old and new packages (there's a button in LP to do this)
<NCommander> abuDawud: alternatively, the original subbitter could have filed it against the wrong package (fairly common if it came from a non-dev)
<abuDawud> NCommander, can you go over this with me if you have a minute or is there a wiki article on this?
<abuDawud> there is no package in launchpad for apport-symptoms.
<NCommander> abuDawud: sure, I'm patch pilot for today, so I can look at it. I don't know if there is a wiki page for this
<ebroder> NCommander: Feel free to push my stuff to a lower priority
<NCommander> abuDawud: Launchpad only sees source packages for bug reportting purposes
<abuDawud> I'll try and create a diff or a patch and put it up for you to look at and maybe go over what needs to happen with me
<NCommander> ebroder: your next on deck after I finish with MAME
<NCommander> I'm waiting for pbuilder to finish building, I haven't used this netbook for dev work before and ports.u.c. is very slow tonight
<NCommander> abuDawud: it looks like the bug is against the wrong package in this case, if you can link me, I can look to be sure
<abuDawud> NCommander, give me a minute, gonna eat with the family then I'll get a patch up
<abuDawud> thanks for your help thusfar
<NCommander> abuDawud: I meant the launchpad bug you were workng against ;-)
<NCommander> but dinner++
<NCommander> pbuilder on armel === SLOW
<NCommander> ugh
<micahg> NCommander: you're working on mame?
<ari-tczew> regards to main sponsors - you have a lot of work to sponsor
<NCommander> micahg: yeah, commentted on the bug.
<micahg> NCommander: I thought the patch pilots were supposed to be focusing on the core packageset
<NCommander> micahg: wiki says anything I can choose. I can actually touch universe/multiverse packages (and some kubuntu).
<NCommander> micahg: so those get priority for me unless something looks urgent. At most, on a core packageset I can say a patch is sane but can't upload it
<micahg> NCommander: well, the main backlog is the stuff that MOTU can't upload
<abuDawud> NCommander, heres the bug https://bugs.launchpad.net/ubuntu/+source/apport/+bug/678371
<NCommander> micahg: argh
<micahg> NCommander: not your issue I guess
 * NCommander had a kernel oops break a filesystem
<NCommander> ARGH
<NCommander> [ 4247.950000] EXT4-fs error (device sda1) in ext4_dirty_inode: Journal has aborted
<NCommander> I can't win today
<micahg> NCommander: BTW, I had a build issue with mame in pbuilder for natty, it was trying to use an arch specific gcc
<NCommander> micahg: I'm on an armel netbook ATM, if it FTBFS's, I'll throw it in a PPA and try there.
<NCommander> ah
<NCommander> Architecture: i386 amd64
<NCommander> blast
<NCommander> Oh well, will check it later
<abuDawud> So the issue I am working on a package that does not have a /debian/patches folder so edit-patch is kicking me out.
<abuDawud> I ended up just making a diff file but I'm unsure what to do now
<NCommander> Adri2000: apport-symptons is maintained in bzr, you should pull the branch down and apply it to the source directly since apport-symptons is a native package and only exists in Ubuntu
<abuDawud> wrong person, but I got it. I pulled the bazaar package and the apt-get source down so after I have the patch I should just apply it and request a merge?
<NCommander> ebroder: I managed to confirm the bug
<NCommander> eek
<NCommander> abuDawud: sorry about that, I multitask-failed :-). If a package is maintained in bzr, you shouldn't use apt-get source, you should grab the source branch (apt-get source will tell you what it is), apply it there, upload it, then request merge, and I'll review it and make comments
<abuDawud> stupid question, how do I request a merge?
<NCommander> abuDawud: upload the branch to LP under your own namespace, then click it, and then click request merge, and then put the branch its going against. Also make sure when you make the commit on your own branchdo bzr ci --fixes lp:bugno
<NCommander> that will tell LP that branch is for the bugm and magically connect it to the bug
<abuDawud> awesome, I'll give it a go
<abuDawud> thanks
<NCommander> abuDawud: NP
<micahg> debcommit does bzr ci --fixes magic with the changelog entry as the commit message
<NCommander> ^- abuDawud
 * NCommander may be a luddite with some of the tools we use due to  old habits
<abuDawud> so the recommendation is package it myself then upload it?
<abuDawud> I'm not familiar with debcommit, but I'm about to read the man page so expert incoming
<NCommander> abuDawud: grab the branch, download it, edit it, push it, request a merge, and then poke the sponsors queue or patchpilot
<NCommander> abuDawud: debcommit is fairly straightforward
<NCommander> Riddell: you still around?
<Riddell> NCommander: yo
<NCommander> abuDawud: there's a good guide somewhere on the wiki on the specifics of VCS packaging
<micahg> abuDawud: here the beginning of the docs on Ubuntu bzr dev stuff (UDD) https://wiki.ubuntu.com/DistributedDevelopment/Documentation
<NCommander> ah
<NCommander> :-)
 * NCommander is saved from using the wiki's search 
<abuDawud> micahg, thanks. I'll give it a go
<NCommander> Riddell: I think I have a patch I'm ready for you to look at, ebroder's patch for maverick looks sane
<NCommander> ebroder: silly questionm, why did all the po files get regenerated?
<ebroder> NCommander: Hmm. Good question
<NCommander> ebroder: the po's looks like they got regenerated inproperly
<NCommander> ebroder: can you respin your branch without them there, since I'm seeing blank Language fields which seems to be wrong.
<NCommander> Riddell: disregard, currently not recommending merger
 * NCommander comments on the bug
<ebroder> NCommander: I don't see those changes in my branch. I wonder if it's just something that happens when you debuild -S
<abuDawud> Anyone, since the version number is already at 0.9 what should I move it up to?
<NCommander> ebroder: hrm
<NCommander> ebroder: modified: debian/po/cs.po
<micahg> abuDawud: is this for Natty?
<NCommander> abuDawud: 0.10
<NCommander> (if its for natty, if its a backport/SRU, it changes)
<NCommander> ebroder: er, indeed. modified: debian/po/cs.po
<abuDawud> I was doing just the Natty side right now
<abuDawud> working off the current bazaar branch
<NCommander> ebroder: *coughs*
<NCommander> disregard the noise
<ebroder> NCommander: Looking
<micahg> abuDawud: dch -i usually does the right thing for new version
<abuDawud> it put in 0ubuntu1 at that end
<micahg> abuDawud: ah, hmm...
<abuDawud> and marked it as Maverick
<abuDawud> argh
<NCommander> Riddell: https://bugs.launchpad.net/ubuntu/+source/cernlib/+bug/601732 - can you look at the mvercik branch and merge/upload please if it also looks sane to you?
<micahg> abuDawud: you can set the series with -D
<NCommander> abuDawud: just change it by hand, although its recommended if your doing Ubuntu dev work, you be on the latest version.
<NCommander> or what micahg said
<NCommander> :-)
<abuDawud> coolbeans, I'll set to 0.10 and natty
<abuDawud> thanks gents
<NCommander> ebroder: Thank you for your contribution to Ubuntu.
<ebroder> NCommander: Haha, thank you for piloting :)
 * micahg will file a bug about Ubuntu native package versioning being incorrect
<micahg> bug 680334 in case anyone wants to subscribe
<ubottu> Launchpad bug 680334 in devscripts (Ubuntu) "dch -i should just DTRT with native packages" [Undecided,New] https://launchpad.net/bugs/680334
<abuDawud> I have a nasty feeling I am going to screw this up. I don't have a ppa set up or anything and I think this is ready to go up
<NCommander> abuDawud: from every failure comes a lesson learned
<abuDawud> can either micahg or NCommander walk me through how to do this without destroying everything?
<NCommander> (or something like that)
<NCommander> abuDawud: 1. Don't Panic
<NCommander> abuDawud: pbuilder is your friend (or pbuilder-dist)
<NCommander> which you can use to test build packages
<abuDawud> NCommander, in the process of moving pbuilder to natty
<NCommander> Riddell: ping?
<Riddell> NCommander: hi
<Riddell> I'm looking at it
<NCommander> Riddell: thanks, just wanted to make sure the earlier ping didn't drop into the void
<Riddell> NCommander: uploading
<NCommander> ebroder: ^
<ebroder> Riddell: Thanks :)
<NCommander> Riddell: also: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/642071 - no-changes rebuild required. If you have amd64, can you quickly check and confirm for me?
<NCommander> ebroder: or do you have an amd64 install?
<ebroder> NCommander: Yeah, I can test
<NCommander> ebroder: thanks, if you can test, Riddell can sponsor :-)
<abuDawud> NCommander, I think I broke it
<NCommander> abuDawud: well, what's your patch? (stuff it in a pastebin or on paste.ubuntu.com)
<abuDawud> NCommander, I tried to upload it to a personal branch and.... it gave some upsetting info
<abuDawud> see: http://pastebin.com/XMZkUKbc
<abuDawud> ah I see, bzr status shows uncommitted changes, hrm
<NCommander> abuDawud: got your SSH keys in LP properly and told bzr of your launchpad-login?
<abuDawud> yep
<mwhudson> is there a good place to ask about python-apt?
<NCommander> did you do bzr unbind to make the branch local and stop trying to commit to the trunk?
<ebroder> NCommander: I can reproduce the kexec bug. Doing a rebuild now
<NCommander> mwhudson: just ask
<NCommander> ebroder: on natty or maverick?
<ebroder> NCommander: maverick
<ebroder> Do you want a natty repro?
<mwhudson> is there a way to get the version of a apt.debfile.DebPackage ?
<ebroder> (I've got one of those lying around, too)
<NCommander> ebroder: that would be nice
<NCommander> mwhudson: no idea :-/, you might want to poke mvo, or ask in one of the Debian channels
<NCommander> mwhudson: (or someone else here might nice, pitti possibly)
<NCommander> might KNOW
<NCommander> ARGH
<mwhudson> :-)
<mwhudson> ok thanks
<abuDawud> NCommander, I was able to commit my changes and tried pushing to the same location and it said it pushed up to Revision 10
<abuDawud> buha! Worked.
 * ebroder thinks this quid pro quo thing could be a real win
<abuDawud> https://code.launchpad.net/~abudawud0/apport/apport-symptoms
<NCommander> ebroder: ?
<ebroder> NCommander: I just think you're doing a good job of getting other people involved
<NCommander> ebroder: that's the idea of the patch pilot
<Riddell> NCommander: I need to sleep, anything you need me for?
<ajmitch> mwhudson: I can see an ugly way to do it, but it doesn't seem like a nice solution at all (looking at _sections)
<NCommander> Riddell: looks like a double no-changes rebuild? Up for the task, or do I need another victi^H core dev?
<Riddell> NCommander: can do if it needs doing now
<mwhudson> ajmitch: is python-apt the sort of wrapper where things get added as needed?
<ebroder> NCommander: no-change rebuild is good on maverik
<ajmitch> it's the sort of wrapper that seems to have multiple confusing layers
<ebroder> *maverick
<ebroder> Same for natty
<NCommander> Riddell: just got confirmation
<NCommander> Riddell: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/642071
<ajmitch> mwhudson: I've only used it a bit, I just found _sections['Version'] by a bit of trial & error
<mwhudson> ajmitch: that works for now, i guess, and i'll bug mvo tomorrow
<mwhudson> ajmitch: thanks :-)
 * ajmitch was hoping for something that would return a Version object (iirc)
<lifeless> mwhudson: what are you looking for ?
<NCommander> Riddell: thanks for the sponsorships
<Riddell> NCommander, ebroder: so upload kexec-tools to maverick-proposed and natty?
<lifeless> mwhudson: 'debian' might be a better module to work with.
<NCommander> Riddell: bingo
<ebroder> Riddell: Yes
<abuDawud> NCommander, I am proposing the merge, who should I set as the 'reviewer'?
<mwhudson> lifeless: i'm writing something that creates debian packages on the fly (a bit like pbuilder does for build deps); am trying to test it
<NCommander> abuDawud: ubuntu-reviewers or ubuntu-sponsors I *think*
<ebroder> abuDawud: If you're merging to lp:ubuntu/whatever, you can leave the reviewer blank
<abuDawud> k
<ebroder> (It'll get automatically set to...something reasonable; no clue what, though)
<mwhudson> i went for python-apt because we're using that already in the project, but that's not actually a good reason to use it for this, i guess
<mwhudson> lifeless: is 'debian' documented somewhere? "python-debian documentation" is fairly google proof :-)
<abuDawud> Ergh... It won't let me propose a merge to apport-symptoms, should it be merged to apport?
<lifeless> mwhudson: pydoc ?
<mwhudson> yeah, that actually works ok
<NCommander> abuDawud: I'm not sure
<ebroder> abuDawud: I think you want to merge to lp:~ubuntu-dev/apport/apport-symptoms
<abuDawud> let me give that a try
<NCommander> ebroder: I think that's sane
<NCommander> wow
<ebroder> NCommander: It's the Vcs-Bzr field for the package
<NCommander> it just started snowing heavily outside :-/
<NCommander> ebroder: do you have a lucid box by any chance? :-)
<ebroder> NCommander: Wow, really? Where are you based?
<ebroder> NCommander: I have Lucid chroots
<NCommander> ebroder: about 20 miles north of Portland, OR
<NCommander> ebroder: https://bugs.launchpad.net/ubuntu/+source/cernlib/+bug/601732 - can you test and confirm on lucid? I already poked maverick
<abuDawud> neat :) I think I am to the actual pilot part, https://code.launchpad.net/~abudawud0/apport/apport-symptoms/+merge/41542
 * NCommander looks
<NCommander> abuDawud: your diff looks ... insane
<ebroder> NCommander: I tested it on Lucid before I submitted the MP
<NCommander> ebroder: MP?
<NCommander> abuDawud: your branch is badly broken, and has conflicts
<ebroder> merge proposal. I'm trying to get the abbreviation to catch on, but it doesn't seem to be working yet :)
<abuDawud> abuDawud, I honestly have no idea what I am doing, all I know is I believe I patched the issue
<ajmitch> ebroder: doesn't everyone call them MPs anyway? :)
<abuDawud> I have a pdebuild of it, is that what should have been uploaded?
<abuDawud> wow what the hell happened to my diff lol
<NCommander> abuDawud: no, you need a clean branch. The diff is very very messy. I don't know what you did ...
<ajmitch> NCommander: no common branch ancestor
<NCommander> ajmitch: ah, can you help abuDawud fix it?
 * NCommander marked it resubmit on LP for the merge proposal
<ajmitch> due to lp:ubuntu/apport-symptoms being a different branch from lp:~ubuntu-dev/apport/apport-symptoms
<abuDawud> ajmitch, any guidance on how to correct it, is it just because I messed up the upload to my personal branch?
<NCommander> ah
<NCommander> I see what happened
<NCommander> abuDawud: you pulled the wrong branch, you pulled the LP packaging branch and not the dev branch (I realize this is confusing, but basically, for every package, LP makes a bzr branch for each upload to the archive)
<NCommander> abuDawud: what you need is to grab the actual development branch and put your changes against it, then push to LP, and submit a new merge propsal
<NCommander> ajmitch: thanks :-)
<ajmitch> NCommander: sorry I can't help more right now, having to do some javascript hackery :)
<abuDawud> NCommander, I'll give it a run, thanks guys
<NCommander> ajmitch: eek :-P
<ajmitch> NCommander: jquery helps, but it's never fun :)
 * NCommander is properly caffinated now 
<abuDawud> NCommander, okay, now its not a bajillion pages long
<abuDawud> https://code.launchpad.net/~abudawud0/apport/apport-symptoms/+merge/41543
<abuDawud> shit and I already see an error
<ajmitch> 'head the test tones'?
<abuDawud> heh, before that
<abuDawud> press close this window
<abuDawud> *sigh*
<ajmitch> yeah, that was also a bit confusing
<ajmitch> at least pushing a new commit isn't too hard, I think the diff updates
<abuDawud> well, at least I am getting some practice lol
<abuDawud> well its pushed, I don't see it updating though, maybe it takes a sec
<NCommander> back
<NCommander> laptop decided it wanted to lock up
 * NCommander <3s irssi+screen+ssh
<ajmitch> abuDawud: it takes a minute or so, also there's a link on https://code.launchpad.net/~abudawud0/apport/apport-symptoms/+merge/41543 saying that it has been superseded by a later proposal - following that will take you to the new commit
<abuDawud> ajmitch, yea I resubmitted over it
<abuDawud> its up
<abuDawud> https://code.launchpad.net/~abudawud0/apport/apport-symptoms/+merge/41544
<mwhudson> the diff on merge proposals will be updated on a push of a new revision btw
<mwhudson> but it can take a couple of minutes
<NCommander> abuDawud: patch looks sane, but I'm not sure this is the correct approach. I'll mark that I looked at it, and the code changes look sane
<NCommander> abuDawud: but I'll leave it for pitti to decide if this is the correct approach or not
<abuDawud> NCommander, there is another way to do it but honestly I don't know how to create a new UI window, and don't know if its good to create the one UI window just for that specific window
<NCommander> abuDawud: as I said, I'll leave for pitti to decide, he's basically apport's upstream
<abuDawud> NCommander, k, thanks for all the help anyway. Back to my bug reporting land where I feel at least a bit comfortable
<NCommander> abuDawud: marked Approved by me, but pitti will be the final judge
<NCommander> Thank you for your contribution to Ubuntu
<NCommander> any core devs abount?
 * NCommander pokes asac 
<micahg> NCommander: if he's home, he's in UTC+1
<NCommander> micahg: I know, but I was gambling on him not having a life and being around
 * micahg thinks people w/out a life are definitely sleeping at 4AM
<ajmitch> heh
<NCommander> ajmitch: your not a core dev, are you?
 * NCommander has lost track on who is who
<ajmitch> NCommander: I am, what do you need?
<NCommander> ajmitch: review and sponsor please: https://bugs.launchpad.net/ubuntu/+source/cheetah/+bug/663343
<ajmitch> slightly confusing with the branch statuses & the comments
<ajmitch> 217k line diff is pretty special :)
<micahg> 217k lines deleted in 7 files?
<ebroder> That's the best kind of diff!
<ajmitch> yeah, one file was test.strace
<ajmitch> so you can imagine how big that was
<micahg> that was uploaded by someone?
<NCommander> >.<;
<ajmitch> not sure, I'm still trying to untangle the branches & what's been uploaded
<micahg> that shouldn't be in the merge proposal :-/
<NCommander> micahg: there are times where that is valid (massive diffs), but very rare
<ajmitch> this bug is a bit confusing with a couple of separate branches & differing statuses
 * micahg won't complain so much since it was uploaded over a year ago
<ajmitch> a year?
<micahg> ajmitch: http://bazaar.launchpad.net/~clint-fewbar/ubuntu/natty/cheetah/natty-merge-with-debian/revision/11
<ajmitch> I hadn't checked, I'd assumed that that file was added in the most recent upload this week
<ajmitch> what a waste of space :)
<micahg> ajmitch: so did I which should warrant a new merge proposal
<micahg> *should have
<micahg> but it wasn't
<ajmitch> orig.tar.gz is 186K, diff.gz was 1.4MB :)
<micahg> right
<NCommander> ajmitch: ugh, I hate when that happens
<NCommander> ajmitch: I think I sent you looking at a bad bug
 * NCommander fails
<ajmitch> NCommander: still valid, the first branch had been uploaded, the 2nd was a valid branch for review
<NCommander> thanks ajmitch
<NCommander> I'm calling it a day
<NCommander> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<NCommander> ...
<NCommander> oh
<NCommander> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<ajmitch> NCommander: ok, thanks for your efforts :)
 * NCommander decides if he wants to head home yet
 * ajmitch should decide if he should put his name down for the patch pilot programme
<ebroder> ajmitch: Dooooo it :)
<ajmitch> ebroder: requires time & dedication on a particular day
<ebroder> ajmitch: It's true. I'm kind of tempted to do it some time, given how much success NCommander had harrassing core-devs
<ajmitch> I'll be sure to hide next time then :P
<NCommander> ajmitch: talk to jono. Right now, all ubuntu devs from Canonical are on the list, but I'm pretty sure we can get more on there
 * micahg suggests a cloak that says ImNotACoreDev
<ebroder> NCommander: There's some space at the end of months for community members to fill in. Also weekends
<NCommander> micahg: heh ;-)
<ajmitch> NCommander: it certainly looks open to getting more people involved
 * micahg wonders if the main sponsors queue will be affected by this programme
<ajmitch> micahg: isn't that sort of the point?
<micahg> ajmitch: not from what I can tell
<ebroder> It was definitely a big motivator for the UDS discussion
<ajmitch> the patch pilot discussion came out of trying to get sponsoring to work well, from what I know
<ebroder> ajmitch: Right, and core is where sponsoring isn't working well already
<ajmitch> right, because we're all lazy
<ajmitch> or at least I am :)
<micahg> I think NCommander did a great job as pilot though
<NCommander> micahg: I pointed core developers to bugs and got three knocked out
<NCommander> I think its a success
<ajmitch> it'll depend on who's around to poke, though
 * ajmitch must run
<StevenK> RAOF: My theory was that if I locked my machine, DPMS wouldn't fire. My machine disproved that during my lunch break. Perhaps my DPMS has moods ...
<pitti> Good morning
<pitti> cjwatson: d-i> sure, thanks
<pitti> Sarvatt, bdrung: just wanted to rebuild those two (128 and mach), since these haven't changed in a while, and they carried big changelogs
<pitti> I uploaded no-change uploads for packages where the chance is very high that they won't get another "regular" upload in natty
<pitti> NCommander: apport package structure hasn't changed in ages; apport-symptoms has always been a separate package, FYI
<dholbach> good morning!
<NCommander> pitti: didn't know
<didrocks> good morning
<pitti> apw: the WI tracker is yelling at me now
<pitti>   File "/home/platform/work-items-tracker/report_tools.py", line 160, in workitems_over_time
<pitti>     ') GROUP BY status, date' % ms_sql, (team,))
<pitti> sqlite3.OperationalError: no such column: status
 * pitti RTFS
<apw> pitti, huh, that has to be my fault
<apw> but i'd swear i'd run the full tests
<pitti> and I don't see a fundamental change there, too
<apw> bibble
<pitti> oh, hang on
<pitti> there's a subselect now
<pitti> apw: ah
<pitti> it stumbles over the outer GROUP BY status in report_tools.py:160
<pitti> apw: not sure what the column header is called with that, "w.status"?
 * pitti tries a "w.status as status" in the inner select
<apw> well when i tested it in sqlite it was status ... hrm
<apw> i even have that exact piece of sql in my sqlite history
<apw> select status, date, count(status) from (SELECT DISTINCT w.status, date, w.description, w.assignee  FROM work_items w, specs s ON w.spec = s.name LEFT JOIN teams ON (s.assignee = teams.name OR w.assignee = teams.name) WHERE (teams.team = 'canonical-kernel-team' OR w.assignee = 'canonical-kernel-team' OR s.assignee = 'canonical-kernel-team')) group by status, date;
<apw> which runs and produces output !?!
<apw> pitti, just be aware there are 4 the same in that function
<pitti> *nod*
<pitti> platform@lillypilly:~/work-items-tracker$ ./burndown-chart -d ../work-items-db/natty.db -t canonical-desktop-team -o /tmp/x.svg
<pitti> ok, that reproduces it nicely and quickly
<apw> apw@dm$ ./burndown-chart -d current.db -t canonical-desktop-team -o /tmp/x.svgapw@dm$
<apw> hrm, no error for me
<pitti> apw: lillypilly is on hardy -- different python/sqlite?
<apw> poop
<apw> it must be something like that
<apw> as that command here produced a nice little graph :(
<apw> well at least i know why my testing is a fail
<apw> pitti, feel free to just revert that commit and i can go work out how to do it with hardy
<pitti> I'll try to bang on this for a while
<pitti> "w.status AS status" doesn't seem to work unfortunately
<apw> pitti, crap, well as i say i am happy to take it offline and sort it out
<pitti> oh, hang on -- just forgot a trailing space
<pitti> ah, that does it
<apw> pitti, where ?
<apw> after the ( ?
<pitti> apw: pushed
<pitti> apw: no, I forgot it when I added "AS status"
<apw> ahhh
<pitti> so it ended up being "w.status AS statusFROM
<apw> pitti, wel thank you for fixing that one
<pitti> thanks for fixing the original bug
 * apw adds 'test on people' to his list
<zyga> mvo, hi, I'm trying to upgrade my machine to maverick using do-release-upgrade, it fails and points me at some log files, would you mind having a look and telling me what is wrong? I've tried this several times but I fail to see the "that's why" error message
<zyga> mvo, the log (main.log) is here http://pastebin.ubuntu.com/535478/
<mvo> zyga: sure, could you mail me the "apt.log" file as well? it can not resolve some dependencies, that file contains the details
<zyga> mvo, may I pastebin, thunderbird fails to display on this device
<zyga> mvo, apt.log http://pastebin.ubuntu.com/535479/
<zyga> mvo, I removed all my PPAs and removed/purged all the packages that were "obsolete/local" in aptitude
<zyga> mvo, trying again
<zyga> mvo, that worked
<mvo> zyga: cool, looking at the log it seems like libdrm-poulsbo1 might be the trouble maker
<mvo> and xserver-xorg-video-psb  - out of curisoity, what repo has/had that?
<mvo> the "gma500" ppa?
<zyga> mvo, yes
<zyga> mvo, special handling needed?
<zyga> mvo, unfortunately without that ppa my hardware is useless
<mvo> zyga: yeah, I think there should be a quirk handler for this in the release upgrader if its a common ppa
<zyga> mvo, do you have any code for quirks like that already?
<mvo> zyga: not for the exact problem, but for similar ones in DistUpgrade/DistUpgradeQuirks.py
<zyga> looking
<AnAnt> Hello
<zyga> mvo, wow, you even have arm quirks!
<mvo> zyga: yes :)
<mvo> zyga: nothing that I can test it against, but there are some /proc/cpuinfo fixtures in tests/ for this
<mvo> (nothing real)
<zyga> mvo, yeah I wac curious if it's possible to test the quirk resolver alone against a set of fixtures
<zyga> mvo, othewise developing this is a lot harder
<mvo> zyga: the tests infrastructure in that code is not ideal :/ but its relatively straightforward to add the fixture stuff with apt.Cache(rootdir="./testdir"). then testsidr just needs etc/apt/sources.list, var/lib/apt/lists etc
<mvo> zyga: most importantly var/lib/dpkg/status
 * ogra puts on helmet and overall 
<mvo> ogra: what for?
 * dholbach cheers for ogra
<zyga> mvo, I see, ... still I have no idea how I'd use that to test the quirks code, sorry :-(
<mvo> ogra: fffffllllllyyyyyy
<mvo> zyga: no worries, if you report a bug I will check it out, make sure to include the system_state file (that contains the dpkg status file)
<ogra> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<ogra> @pilot on ogra
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<ogra> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ogra
<ogra> adies and gentlement, we welcome you on our flight to patchland today, please remain seated until we reached our flight altitude, life vests are under your seat ... in the unlikely event of cabin pressure loss oxygen masks will fall off the ceiling, try to find them on the floor if you can :P ... during the flight please make sure to wear your seatbelt while seated, as turbulences can occur at any time during the flight ... we wish you a pleasent fli
<ogra> ght with ubuntu airlines now
<dholbach> haha
 * dholbach hugs ogra
<ogra> ;)
<mvo> haha - you fly too often ;)
 * micahg hopes the pilot takes a walk through the "main" cabin later :)
<ogra> i surely do ;)
<zyga> mvo, can I do that while upgrading to maverick now? where's the file
<mvo> zyga: sure, its in /var/log/dist-upgrade/
<zyga> mvo, got it
<zyga> mvo, filing bug now
<\sh> mvo: moins :) do you have a link to your bzr branch for the fix you did yesterday regarding apt-key net-update and the timeout? :)
<mvo> \sh: yes, http://bazaar.launchpad.net/~ubuntu-core-dev/apt/ubuntu/revision/1835
<mvo> zyga: thanks!
<zyga> mvo, thank you https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/680422
<\sh> mvo: thx
<ogra> didrocks, hmm, i'm looking at the utouch-grail branch, in bug 667802 ... seems the branch you committed the last change to is the natty packaging branch instead of the maverick one
<ubottu> Launchpad bug 667802 in utouch-grail (Ubuntu) "Tap is sometimes not registered on touchscreens" [High,Triaged] https://launchpad.net/bugs/667802
<mvo> zyga: thanks
<didrocks> ogra: it's the same for both
<didrocks> ogra: the last one was a bugfix release
<ogra> the comments indicate differently
<didrocks> ogra: yeah, but I talked with them and the .1 was basically all the commits
<ogra> https://bugs.launchpad.net/ubuntu/+source/utouch-grail/+bug/667802/comments/28
<didrocks> ogra: they just thought that for an sru they don't have the right to make a new . version
<ogra> ah
<didrocks> thanks, I read it :)
<didrocks> I remember very well
<didrocks> Yes, utouch-grail/packaging contains the change in source, whereas
<didrocks> utouch-grail/packaging.maverick contains the change as a patch
<ogra> then i misunderstood, i just wondered how to sponsore a natty upload that way
<didrocks> same changes, better to keep the same version ^
<ogra> since the natty branch already has a maverick changelog entry
<ogra> and a tag
<didrocks> ogra: hum, I didn't push to the maverick branch, not sure why it diverged
<ogra> no, you commited to the natty branch
<ogra> https://code.launchpad.net/~utouch-team/utouch-grail/packaging has as last commit the changelog and tag for maverick
<ogra> i would have sponsored it for natty but dont know how now
<ogra> at least without messing up the changelog and tags
<didrocks> ogra: as it should be the same, just wait for -proposed to be accepted (if not already) and copy to natty
<didrocks> ogra: when we are in sync, no need for double uploadsâ¦
<ogra> k
<ogra> pitti, (or another archive admin) bug 667802 see above, can you copy it over from maverick to natty please ?
<ubottu> Launchpad bug 667802 in utouch-grail (Ubuntu) "Tap is sometimes not registered on touchscreens" [High,Triaged] https://launchpad.net/bugs/667802
<pitti> ogra: can we please do proper natty uploads at this point, so that they build against the current toolchain and pkgbinarymangler?
<ogra> oh, right, i forgot the toolchain :P
<ogra> didrocks, so it seems that wont work
<didrocks> ogra: yeah, just make a dummy .real maybe
<ogra> well, i cant even upload to any of the utouch branches, just piloting here
 * ogra leaves a comment on the bug
<quadrispro> hi all
<Keybuk> mvo: someone told me a German joke the other day
<Keybuk> Two bratwurst in a frying pan; first one says "Boy, i'm really hot".  The second goes "Argh! A talking bratwurst!"
<soren> *chuckle*
<zyga> time to reboot into maverick
<zyga> brb
<apw> Keybuk, heh, a real insight into their jokes :)
<mvo> Keybuk: heh :) I can only link to monty python http://www.youtube.com/watch?v=LhmnOpoGAPw
<Keybuk> mvo: you realise that Monty Python is hilarious, right? :p
<mvo> I do
<Keybuk> (context: ev is still trying to persuade me that The Onion is funny)
<ev> it is!
<mvo> I have no idea aobut the onion, but monty python rules :)
<davmor2> Keybuk: the iwheel from onion was funny you can't deny it...
<ev> mvo: http://www.theonion.com/video/obama-replaces-costly-highspeed-rail-plan-with-hig,18473/
<mvo> ev: haha - that is great
<ev> that settles it then
<ev> American humor wins
 * mvo is away for a couple of minutes to have lunch
<mvo> well, monty python and terry pratchett vs the onion ? isn't that 2:1 ?
<ev> I'd show you the daily show, but the videos are locked to the US
 * persia mumbles about proxy servers
<azeem> ev: you can watch the daily show from Germany
<azeem> at least the last three weeks
<ev> oh, there you go then :)
<mvo> lunch first :)
<tjaalton> the archives work too.. like this one http://www.thedailyshow.com/watch/tue-april-21-2009/the-stockholm-syndrome-pt--1
<tjaalton> and pt. 2
<ev> tjaalton: only in the US :(
<tjaalton> ev: I'm from Finland ;)
<ev> weird, it doesn't work in the UK
<tjaalton> hmm, sound only?
<ev> I guess Comedy Central hates us
<ev> "Sorry, videos are not currently available in your country"
<ev> I suspect it's because they have a deal with Channel 4
<tjaalton> oh
<azeem> right, individual clips still work (like the above), but full episodes only go back three weeks
<BlackZ> ogra: can you have a look at http://launchpadlibrarian.net/59440471/2.4.10.1-2_to_2.4.10.1-2ubuntu1.patch ?
<ogra> BlackZ, are you sure graphviz is still in the way ?
<BlackZ> ogra: what do you mean exactly? (sorry, going to lunch now, will reply later)
<ogra> ok, go to lunch, i'm here for a few more hours indeed :)
<didrocks> ogra: ok, I've upload utouch myself then, no need to make it harder than it should be :)
<mvo> tjaalton: don't do this to me (and my productivity ;)
<ogra> didrocks, great, thanks for being a co-pilot :)
<BlackZ> ogra: so, what do you mean exactly?
<tjaalton> mvo: :P
<didrocks> :)
<mvo> 10 weeks of payed vacation, eh? thats just like france!
<tjaalton> mvo: careful, or I'll post links to <gasp> finnish humor :)
<didrocks> mvo: !!!
<mvo> lol
<tjaalton> though youtube has some with english subtitles..
<ogra> BlackZ, a) you should close the bug in your changelog with the merge, b) are you sure the graphviz change you carry over is still needed
<ogra> assuming that patch belongs to bug 657324
<ubottu> Launchpad bug 657324 in libgphoto2 (Ubuntu) "Please merge libgphoto2 2.4.10-2 (main) from Debian experimental (main)" [Undecided,Confirmed] https://launchpad.net/bugs/657324
<BlackZ> ogra: a) the bug will be closed: "Merge from Debian experimental, remaining changes (LP: #657324):" b) checking that :)
<BlackZ> ogra: yes, it does
<ogra> oops, i missed the LP in the first line, sorry
<ogra> BlackZ, i think we can assume that the problem with the buildds and graphviz still exists (given the buildds didnt change), so let me just upload that for you
<BlackZ> ogra: yeah, thanks! :) (I didn't that merge but I'm interested in that merge too, that's why I'm asking you to review it)
<ogra> BlackZ, uploaded
<BlackZ> ogra: thanks! :)
<ogra> BlackZ, thanks for being a co-pilot !
<ogra> stgraber, i'm looking at bug 457702 has the promised upload from teh last comment ever happened ? (if so, could you close the bug)
<ubottu> Launchpad bug 457702 in ltsp (Ubuntu) "nbd+squashfs errors when rebooting ltsp thin clients" [Undecided,Confirmed] https://launchpad.net/bugs/457702
<tkamppeter> seb128, hi
<ogra> cjwatson, given that dpkg was uploaded without optimizations, should we probably revert the debootstrap hack ?
<ogra> cjwatson, talking about bug 674146 and lool's upload
<ubottu> Launchpad bug 674146 in gcc-4.5 (Ubuntu Natty) "dpkg segfaults during debootstrap on natty armel" [High,Confirmed] https://launchpad.net/bugs/674146
 * ogra thinks one fix is enough
<ogra> s/fix/workaround/
<cjwatson> ogra: I'd be fine with that
<cjwatson> I should deal with the Debian side of the bug at some point mind you
 * cjwatson is deep inside grub2 atm
<ogra> i didnt want to be pushy it just seems useless to work around the issue in two places
 * ogra is fine to work on the debsootstrap reversion
<ari-tczew> I'm looking for sponsorship, bug 626379
<ubottu> Launchpad bug 626379 in gnome-settings-daemon (Ubuntu Lucid) "gnome-settings-daemon crashed with SIGSEGV in g_main_context_dispatch()" [Low,Triaged] https://launchpad.net/bugs/626379
<bdrung> kenvandine: welcome in the core-dev team
<persia> Uh, it will be a few more minutes :)
<bilalakhtar> ken became core-dev? wow!
<persia> will become.
<bilalakhtar> but approved nevertheless :D
<seb128> tkamppeter, hey
<ogra> ari-tczew, heh, i didnt watch IRC while i uploaded the fix ...
<ogra> thanks for the pointer though, its already up
<ari-tczew> ogra: did you upload this one to lucid-proposed?
<quadrispro> persia, thanks for the add
<ogra> ari-tczew, yep
<ari-tczew> ogra: could you comment this on bug? thanks for sponsorship, but I'm not a witch
<ogra> ?? i commented
<ari-tczew> hmmm
<ogra> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/626379/comments/15
<ogra> :)
<ari-tczew> ogra: ah, 7 minutes ago ...
<ogra> yeah, i took the time to review it before uploading :)
<ari-tczew> nice
<ogra> feel frr to ping me directly while i'm patch pilot, i didnt look at IRC after my conversation with colin above
<ogra> *free
<ogra> only noticed your pint after the upload
<ogra> *ping
<ari-tczew> ogra: what is patch pilot?
<ogra> someone to help with patches and sponsoring
<ogra> we have one every day now, you can see who it is in the topic
<BlackZ> ari-tczew: https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch%20Pilots
<ari-tczew> ogra: so Canonical employees are patch pilots?
<cjwatson> there's no reason why it should be restricted to Canonical employees, but we are the only ones who can be *instructed* to take part ;-)
<doko> bdrung: why do you want to sync gcc-snapshot? what do you gain?
<ogra> ari-tczew, https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews there is a scedule
<ogra> *schedule
<ogra> doesnt need canonical amployees, anyone acn apply indeed
<ari-tczew> aha got it
<persia> Well, other folk who happen to do this for their day job can also be so instructed, but they are less common :)
<seb128> ogra: don't forget to use -v
<seb128> ogra: when you build merges from debian
<ogra> seb128, argh
<ogra> did i ?
<seb128> ogra: libgphoto yes
<ogra> ouch, sorry
<seb128> no worry
<ari-tczew> ogra: I see waiting bug 663343 :)
<ubottu> Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343
<ogra> will take care for it after the arm meeting
<ari-tczew> nice
<ogra> thanks for the pointer and for being a co-pilot :)
<ari-tczew> ogra: love it :D
<tkamppeter> seb128, it is about the photo printing Blueprint.
<tkamppeter> seb128, in the work items is mentioned for you to check why paper size widget is disabled by default.
<seb128> I will
<tkamppeter> seb128, as GNOME bug 551409 shows that a method to activate the page size and orientation widgets was added to the GTK printing dialog I consider the configuration without "Page Setup" as supported upstream and so I think we should change the photo applications now.
<ubottu> Gnome bug 551409 in printing "Print dialog should include page size and orientation" [Enhancement,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=551409
<seb128> tkamppeter, ok, can you open bugs on softwares that need to be updated and update the spec with the bug numbers?
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ogra, mdeslaur
 * dholbach hugs ogra and mdeslaur
<ogra> hey mdeslaur !
 * mdeslaur hugs dholbach 
<tkamppeter> seb128, I have looked into the patch for eog in GNOME bug 614451 and eliminating the Page Setup dialog is a small patch doing nothing more than calling said method when initializing the print dialog, saving page setup settings when clicking OK/Apply/Print in the dialog, and removing all code which creates the Page Setup dialog. I have done this with shotwell for testing.
<ubottu> Gnome bug 614451 in general "Embed page setup dialog in the print dialog" [Enhancement,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=614451
<mdeslaur> hi ogra :)
 * ogra offers mdeslaur a seat in the cockpit
<tkamppeter> seb128, I will report appropriate bugs.
<seb128> tkamppeter, thanks
<mdeslaur> -ETOOMUCHWIKIDOC
<ogra> mdeslaur, https://bugs.launchpad.net/~ubuntu-sponsors/+subscribedbugs is a good start
<mdeslaur> ogra: ah! the exact information I was looking for :)
<mdeslaur> ogra: thanks :)
<seb128> http://qa.ubuntu.com/reports/sponsoring/index.html
<seb128> why not using that?
<ogra> or that
<mdeslaur> ogra: so I don't start working on the same stuff as you...are you going down that list, or up?
<dholbach> seb128's list is better, it includes merge proposals too
<mdeslaur> dholbach: cool
<ogra> mdeslaur, random :)
<mdeslaur> ogra: ok
<ogra> dholbach, the buglist has them too
<dholbach> ogra: only if there's merges that have sponsoring bugs attached to them :)
<ogra> mdeslaur, i'm in a meeting atm, after that i'll look at bug 663343
<ubottu> Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343
<seb128> ogra: no it doesn't
<seb128> ogra: the launchpad list only has bugs
<ogra> seb128, well, libgphoto2 was a merge request (with ready made patch)
<seb128> ogra: which had a bug as well?
<ogra> yes
<seb128> well quite some people don't use bugs
<ogra> there are enough bugs for merges still
<seb128> see the sponsoring page for some example
<hallyn> lool: i just did 'bzr co lp:ubuntu/natty/qemu-kvm', and ended up with the maverick tree ?
<seb128> ogra: not sure what your point is, the qa reports list has bugs and things which don't have bugs, seems a better list to work on?
<seb128> ogra: or do you want to ignore people who don't file bugs for some reason?
<ogra> seb128, well, the title is "patch" pilot
<ogra> so i'm looking for patches
<ogra> which usually go with bugs
<seb128> well a merge request is a diff which is a patch is some way
<ogra> sure
<seb128> we are moving away from adding manual diffs to bugs
 * ogra really doesnt think it matters how the lists are getting empty 
<ogra> as long as they do get empty
<seb128> right, we are just telling that your list is not reflecting the really of things needed review
<seb128> if you drive your list to 0 you still ignore contributors, those who don't open bugs
<ogra> well, patches are patches
<ogra> if the list is 0 i will move on to another list
<seb128> ok, your call
<seb128> if you have enough to keep busy on the list you use go for it
<ogra> right
<seb128> the comment was just to point that things are waiting out of this list
<seb128> http://qa.ubuntu.com/reports/sponsoring/index.html reflects both
<ogra> yeah
<ogra> got that
<seb128> you might find things easy to sponsor there that interest you and are not on the other listing
<seb128> so it might be worth watching it
<seb128> now you do what you want from it ;-)
<ogra> thanks :)
<lool> hallyn: the importer didn't import the newer revisions yet as it seems
<persia> seb128, I'm not sure it's fair to say "we're moving away" from attaching diffs to bugs: I think it's better to say that we're supporting UDD workflows, and encourage their use.
<lool> hallyn: james_w is on leave this week, let's check whether barry can hepl
<lool> barry: hey!
<persia> There's just too many folk out there who know diffs and don't know bzr who can help to completely drop diff attachments.
<lool> barry: Would you have some time to help us with a qemu-kvm package-import issue?>
<seb128> persia, ok, said different "increasing number of request come without bugs"
<seb128> which is just what I noticed
<persia> seb128, I firmly agree with that.  Positive statements :)
<lool> barry: Basically, a new upstream version was merged without merge-upstream; I reverted these commits now, but the importer didn't reimport the uploads, despite a new qemu-kvm having been uploaded
<seb128> which suggest that a class of users is moving away from filing bugs
<seb128> there was nothing else suggested in my comment ;-)
<hallyn> lool: so what is 'the importer'?  isn't this just a bzr tree to be pushed?
 * hallyn googles while waiting for vpn
<cjwatson> not everyone uses branches, so there's a process that looks at uploads and constructs bzr trees for them if it doesn't already find them
<hallyn> uploads as in 'dput' ?
<hallyn> (if so, then i see - interesting.  given my last hard FAIL, i wonder if it's safer if i do that :)
<cjwatson> yes
<cjwatson> (as in dput, dupload, whatever)
<lool> hallyn: http://package-import.ubuntu.com/status/
<lool> hallyn: and see also the UnderTheHood link I sent in my email
<hallyn> lool: thanks
<pitti> quadrispro: congratulations to your core-dev badge!
<quadrispro> thanks for all the support pitti !
<bilalakhtar> Congrats quadrispro !
<sladen> cyphermox: that changelog of yours for evolution is *very* impressive
<cyphermox> sladen, there's a lot in it, yes
<cyphermox> and still ftbfs on i386 for some reason now, despite lots of build testing and functionality testing >.<
<apw> is it me or are we getting a much higher percentage of random 'failed to build's with no logs in PPAs ... all of a sudden
<om26er> 'Friendly Patch Pilots' is it on?
<diwic> BlackZ, about bug #680386, the reason it is two patches, is because there was two patches in F14
<ubottu> Launchpad bug 680386 in tvtime (Ubuntu) "Please apply alsamixer support patch (present in Fedora 14)" [Wishlist,Incomplete] https://launchpad.net/bugs/680386
<om26er> bug 652944
<ubottu> Launchpad bug 652944 in telepathy-haze (Ubuntu) "All my ICQ contacts have a webcam icon next to them in Empathy" [Medium,Fix committed] https://launchpad.net/bugs/652944
<diwic> BlackZ, could you explain why it is important to have it as one patch only?
<BlackZ> diwic: so any reason to not merge them? they exist for the same purpose, don't they?
<om26er> i have a branch with the fix backported. can anyone please sponser? https://code.launchpad.net/~om26er/ubuntu/maverick/telepathy-haze/telepathy-haze-fix-652944/+merge/41597
<diwic> BlackZ, the reason is mainly to keep things identical to F14. If that counts as a reason, I don't know
<seb128> om26er, subscribe ubuntu-sponsors or ask review from the team for it
<seb128> om26er, if the day patch pilots don't review it someone in desktop land will
<om26er> seb128, ok subscribed ubuntu-sponsors .thanks
<BlackZ> diwic: if they're not for the same purpose, choose a different name for each patch, if they're for the same purpose I don't see the point of splitting two patches for the same purpose
<seb128> om26er, thank you for working on that ;-)
<diwic> BlackZ, ok, so if I fix that according to your wishes, is it ready for upload or is it anything else I should do at the same time?
<BlackZ> diwic: you could add where you take the patch or the upstream commit, then it looks fine to me apart for that :)
<diwic> BlackZ, are you looking for an URL?
<BlackZ> diwic: an url where you took the patch from would be ok
<stgraber> ogra: oops, this bug should have been closed indeed (457702). I usually do a pass through all our bugs at the hackfest, but for some reason didn't this year :(
<ogra> stgraber, well, close it so it doesnt start smelling ;)
<stgraber> ogra: done ;)
<mdeslaur> cjwatson: I'm slightly stumped by this build log: http://launchpadlibrarian.net/59497625/buildlog_ubuntu-natty-i386.pbuilder_0.199ubuntu2_FAILEDTOBUILD.txt.gz
<mdeslaur> cjwatson: any ideas? the "LANG=C MANWIDTH=80 man --warnings -E UTF-8 -l pbuilder.8 >/dev/null" works fine for me in a natty schroot
<geser> I can reproduce this in my natty pbuilder (but not my natty chroot)
<cjwatson> mdeslaur: it happens only if you have no locales
<cjwatson> sounds like a man-db bug though
<mdeslaur> cjwatson: ok, will fiddle with man-db. What do you mean by "no locales"?
<cjwatson> mv /usr/lib/locale/locale-archive /usr/lib/locale/locale-archive.safe
<cjwatson> is enough to trigger the bug
<mdeslaur> cjwatson: hmm...I don't have locale-archive in my schroot, yet am not able to trigger it
<cjwatson> sorry, for avoidance of doubt, when I say "sounds like a man-db bug though" that's me accepting it as an upstream bug
<cjwatson> well, whatever's in /usr/lib/locale/
<mdeslaur> cjwatson: it's empty
<cjwatson> huh
<cjwatson> triggered it for me :)
<mdeslaur> odd
 * ogra grabs his parachute 
<ogra> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mdeslaur
<mdeslaur> ogra: bye! :)
<ogra> thanks for flying ubuntu airways today :)
<cjwatson> I installed a horrible hack for col's locale in response to Debian #555331
<ubottu> Debian bug 555331 in man-db "[col] improperly fails with Invalid or incomplete multibyte or wide character" [Serious,Fixed] http://bugs.debian.org/555331
<cjwatson> I bet it's related to that
<cjwatson> may depend on the locale in your environment too
<mdeslaur> cjwatson: huh...I can reproduce it now
<barry> lool: hi.  i had a school meeting this morning, but i'm back now.  what can i help with?
<cjwatson> actually, wait, man-db probably can't do anything more
<cjwatson> there's no UTF-8 locale available, so it can't make col work
<cjwatson> pbuilder should probably generate a temporary UTF-8 locale
<cjwatson> mdeslaur: see e.g. http://git.debian.org/?p=lintian/lintian.git;a=commitdiff;h=9b7c0896ae937cc29662cc4d385d94df27626268
<chrisccoulson> heh, i have to do something similar in firefox to get a UTF-8 locale so that some of the unit tests work properly
<mdeslaur> cjwatson: ah! thanks for the hint, I'll try that
<mdeslaur> (I'm still kind of stumped how it worked fine in my chroot 5 minutes ago, and now doesn't anymore...)
<lool> barry: Can you arrange for the package importer to retry qemu-kvm?
<lool> barry: I think it got flagged as broken, and I arranged to "fix" the branch
<barry> lool: i don't believe i have permissions to do that
<lool> barry: Ah how unfortunate; ok, thanks
<barry> lool: yeah.  i should really talk with james_w about that
<james_w> barry, please file an RT
<barry> james_w: file an RT on doing the retry or getting permission so i can request it?
<james_w> barry, on getting permissions
<james_w> lool, retried
<dholbach> seb128, I will never forgive you!
<seb128> dholbach, lol
 * james_w &
 * seb128 hugs dholbach
<seb128> dholbach, did you get the comment with it?
<lool> james_w: Thank you!  you go back to leave  :)
<dholbach> yes :)
<barry> james_w: gotcha.  are the retries done on package-import.ubuntu.com or launchpad?
<dholbach> seb128, can I still commit to the branches?
<dholbach> or don't you use them any more?
<james_w> barry, the former
<seb128> dholbach, ok, the ui is confusing, it's not clear if the comment is specific to expiration
<james_w> barry, you need to be in the pkg_import group IIRC
<dholbach> seb128, can I still commit to the branches?
<ogra> barry, hrm
<barry> james_w: gotcha.  i thought it was p-i.u.c but when i look at e.g. the qemu-kvm package page, i didn't see any knobs i could twiddle
<james_w> barry, the pages are read-only
<seb128> dholbach, you can commit for things you have upload rights for still
<ogra> barry, i just uploaded the diff from bug 663343 ...
<ubottu> Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343
<seb128> dholbach, other teams are subteam from this one
<dholbach> seb128, you don't use lp:~ubuntu-desktop/..... any more?
<ogra> barry, any idea why there is a newer cheetah in the archive but the bug is still open ?
<seb128> dholbach, we do but ubuntu main uploaders are members of ubuntu-desktop
<james_w> barry, we could add retry buttons, but going to a read/write webapp is a fairly large step
<ogra> (there is no newer one in debian)
<dholbach> seb128, alrightie
<dholbach> thanks
<seb128> dholbach, so anybody who can upload to main can commit to the team as well
<dholbach> gotcha
<seb128> dholbach, we still love you ;-)
 * seb128 hugs dholbach
<dholbach> yeah, I know... in a special way
<barry> james_w: ah. so when i get in the pkg_import group, how do i request a re-import?
 * dholbach hugs seb128 back
<dholbach> :-P
<seb128> lol
<seb128> dholbach, should I be scared now? ;-)
<dholbach> no, you kick me out of the team and say "yeah, don't worry - we still love you"
<dholbach> a special way of "love"
<dholbach> nevermind :)
<seb128> lol
<james_w> barry, https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood/Importer
<seb128> dholbach, you know what, if you are nice to me I can get you back in :p
<lool> https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood/Importer/Operational
<dholbach> don't worry - it's fine
<lool> ah too late
<dholbach> it's over!
<seb128> dholbach, now maybe you should be scared ;-)
 * dholbach storms out
<barry> lool: thanks
 * seb128 cries
<barry> james_w: thanks
<lool> barry: So if you're tempted to help fix that one, that would be appreciated
<barry> ogra: i think the bug report title is out of date.  we sync'd from debian but SpamapS has a couple of other minor changes to add
<lool> barry: What happened is that a new upstream version was committed by hand, but without bzr import-upstream; this broke the importer with bzrlib.errors.NoSuchTag: No such tag: upstream-0.13.0+noroms
<lool> https://bugs.launchpad.net/udd/+bug/494481
<ogra> SpamapS, feel free to ping me for a new upload once your changes are in sync
<lool> barry: then I bzr uncommit-ed all revs in the hope that the importer would just reimport all versions properly
<lool> barry: but now I get AssertionError: qemu-kvm 0.13.0+noroms-0ubuntu1 ubuntu natty is marked but not imported
<lool> http://package-import.ubuntu.com/status/qemu-kvm.html#2010-11-23%2015:13:47.151829
<barry> ogra: from the merge proposal, it looks like there's still some uncertainty about the patch.  i guess SpamapS has to straighten that out (i see he's waiting on a response)
<ogra> barry, ok, i'm fine to be the upload bitch once there is a patch ready
<ogra> since i touched it now already
<james_w> lool, looking
<BlackZ> diwic: uploaded
<barry> ogra: cool.  i think i'm out of the loop on that one now, though i'm happy also to re-review anything for SpamapS
<ogra> oki
<diwic> BlackZ, thanks :-)
<barry> lool: i agree with james_w on that bug.  subscribed now ;)
<lool> barry, james_w: I understand that the sqlite db mentions versions that were already imported but notin the bzr branch anymore
<james_w> lool, correct, and I just deleted that row
<james_w> lool, it's now importing
<lool> james_w: awesome, thanks
<lool> james_w: Branch looks good, thanks!!
<james_w> np
<bilalakhtar> james_w: Just a general question: Are there a large number of people using UDD already?
<hallyn> lool: fwiw i have not yet gotten the link you mentioned.
<bilalakhtar> I use it, but many AFAIK dislike it calling it a bit bulky to download branches
<barry> james_w: rt submitted
<james_w> bilalakhtar, I can't remember the numbers, but see recent mails to ubuntu-distributed-devel@
<james_w> barry, cool, thanks
<bilalakhtar> thanks james_w for the ML address
<lool> hallyn: Really?  mail from Date: Mon, 22 Nov 2010 16:47:34 +0100
<hallyn> lool: oh, the underthehoodone
<hallyn> got it.  thx
<pitti> cjwatson: would you mind uploading a d-i in maverick-proposed against 2.6.35-23?
<cjwatson> not at all, give me a minute to fettle branches
<pitti> skaet: lucid/maverick kernels copied to -updates, FYI
<lool> doko: alpha 1 is in 10 days, but in https://bugs.launchpad.net/gcc-linaro/+bug/675347/comments/20 you ask for no more compiler upload before alpha 1; however this breaks all builds based on qt including qt itself; what can we do to avoid this?
<skaet> pitti,  thanks!  :)
<lool> doko: should we change the default build flags on armel to -fno-strict-volatile-bitfields
<doko> lool: well, if I can pick the patch from the Linaro repo, or if it's accepted upstream, fine
<doko> currently doesn't have a review
<lool> doko: Ok; let's wait for an ack then
<lool> doko: what's the deadline to upload gcc-4.5 with that fix?
<doko> I thought alpha1 would be this week, but if I can upload it before the weekend, that should be ok
<lool> doko: I see eglibc was not updated in natty; the linux-libc-dev fix seems to be in the archive though
<lool> doko: it's a bit confusing since linux is still in NEW, but the linux-libc-dev changelog includes   * net: rtnetlink.h -- only include linux/netdevice.h when used by the kernel
<cjwatson> apw asked me to reject the kernel from NEW because it was broken
<doko> lool: well, I don't do the NEW processing. and I did want to wait with the eglibc upload for the 2.13 release
<lool> cjwatson: Yes; the linux-libc-dev changes are already in the archive though
<cjwatson> though I see there's a new upload there
<apw> cjwatson, yep there is a new kernel on its way through
<lool> doko: I mean linux is in NEW, but the one in the archive is good enough
<cjwatson> apw: is -6.17 healthier then?
<apw> it would be built already if we hadn't had a random failure on an i386 build
<apw> yep, muchly so
<doko> lool: did you test the merge?
<lool> doko: I've built it on maverick
<lool> doko: But I didn't build/test it under natty
<lool> and some additional commits made their way into the branch in the mean time
<lool> from Kees and you I believe
<doko> I'll try to do it this week, but IMO it's not a priority for me
<apw> cjwatson, looks like it would be finished building in about half hour
<lool> doko: Ok; I thought you wanted that before A1, that's why I bring it up as well
<cjwatson> apw: ok ...
<doko> lool: there's too much I want for alpha1 ... \o/
<lool> I want a pony!
<apw> lool, you really don't they are soooo expensive to run
<lool> ;)
<bdrung> doko: because angelabad requested it. the gain? probably getting it off the m-o-m list
<doko> bdrung: that's little gain, and blocking the buildds
<mdeslaur> lool: I'm trying to fix a pbuilder FTBFS on natty...the Makefile tests manpages with -E UTF-8, but locales aren't properly installed in buildds
<mdeslaur> lool: would you rather I disable the man page tests, or try and generate a locale in the rules file (ugh...)
<lool> mdeslaur: Perhaps test for the availability of the locale, and disable the tests if it's not available?  I could merge that in Debian
<mdeslaur> lool: ah, I'll try that...thanks
<mdeslaur> lool: in the Makefile, or in the rules file?
<lool> mdeslaur: Ideally in Makefile
<cjwatson> generating the locale would really be better
<lool> mdeslaur: I wonder what local is used
<cjwatson> it can be done without root access - you can generate one in a temporary directory
<mdeslaur> cjwatson: so, using localedef in the rules file and then setting LOCPATCH before the make test?
<SpamapS> ogra_ac: ping, that bug report includes a merge proposal to merge the /debian changes from 2.4.2.1-1 into 2.4.3-0ubuntu1
<mdeslaur> s/LOCPATCH/LOCPATH/
<lool> barry: Just wanted to let you know that the subversion failure on armel (KWallet test) is due to bug #675347
<ubottu> Launchpad bug 675347 in Linaro GCC "volatile int causes inline assembly build failure" [Medium,In progress] https://launchpad.net/bugs/675347
<cjwatson> it's certainly what I'd do (well, I haven't looked at exactly where the localedef should go)
<lool> so not subversion's fault
<mdeslaur> cjwatson, lool: ok, I'll generate a locale file in debian/rules
<ogra_ac> SpamapS, yeah, i was tricked by the title it seems
<cjwatson> pitti: uploaded
<pitti> cjwatson: cheers
<SpamapS> ogra_ac: you were tricked by barry running off and uploading 2.4.3 without applying the debian dir changes from 2.4.2.1-1 ;) the title is still more or less accurate. ;)
<ogra_ac> SpamapS, so are your changes in the branch ready for upload or do they still need to mature a bit ?
<tkamppeter> seb128, I reported bug 677575, bug 680483, bug 680521, and bug 680550
<ubottu> Launchpad bug 677575 in shotwell (Ubuntu) "To print in shotwell one has to call an extra dialog for setting the page size" [Medium,In progress] https://launchpad.net/bugs/677575
<ubottu> Launchpad bug 680483 in f-spot (Ubuntu) "f-spot: Embed page setup dialog functionality in the print dialog" [Medium,Confirmed] https://launchpad.net/bugs/680483
<ubottu> Launchpad bug 680521 in gimp (Ubuntu) "GIMP: Embed page setup dialog functionality in the print dialog" [Medium,Confirmed] https://launchpad.net/bugs/680521
<ubottu> Launchpad bug 680550 in geeqie (Ubuntu) "Geeqie: Replace the printing dialog by the standard GTK one" [Medium,Confirmed] https://launchpad.net/bugs/680550
<SpamapS> ogra_ac: they've been tested.. very minor stuff
<chrisccoulson> Sarvatt, ok, i've uploaded the fix for xulrunner-1.9.2 hanging now, hopefully that should work ;)
<Sarvatt> chrisccoulson: thanks! sorry to bug ya in IRC instead of a bug :)
<chrisccoulson> that's ok. i don't often read bug mail, so IRC is much quicker ;)
<SpamapS> cjwatson: ping? wondering if you can answer a plymouth question definitively for me
<SpamapS> cjwatson: trying to resolve this issue where apache2 has a very small window to ask for a password before the system boots.. does plymouth deactivate/quit terminate an ask-for-password ? Shoudn't it wait for that password to be entered first?
<ScottK> SpamapS: Isn't any server application asking for a password on boot broken by design?
<Keybuk> ScottK: SSL passphrases
<ScottK> That's not normally how I deal with that issue on a server.
<SpamapS> ScottK: how do you deal with it?
<cjwatson> SpamapS: the quit handler seems to just exit the event loop; I don't know for sure but my guess would be that that does not wait for pending input.  As for what it should do, I'm inclined to agree with you but you should ask #plymouth really
<ScottK> SSL certs the don't require a passphrase.
<SpamapS> I actually think "encryption pass phrases" seems to be the only reason for a system level service to ask for user input.
<SpamapS> cjwatson: will do
<ScottK> Perhaps.
<ScottK> I just don't see a boot process that involves human intervention being reasonably scalable for server use.
<cjwatson> at the same time we shouldn't design to intentionally break that, I think
<ScottK> True.
<SpamapS> ScottK: I happen to think that the encrypted private key is just a mediocre solution to the problem, but probably the best that software only can provide. You either need to trust that your root privileges + other security layers are secure, or you need to put your keys on removable media that can be physically secured.
<SpamapS> Either way, with the change uploaded to natty yesterday.. now you at least have a chance at entering the pass phrase during boot rather than having to start it manually post-boot..
<geser> cjwatson: I've tried to add anon login to edit_acl.py: querying the packageset contents works, but not the uploaders. Is that enough for your use case?
<pitti> didrocks: hm, I do have unity installed, but I don't see a session for it any more in /usr/share/xsessions?
<pitti> didrocks: I just created a fresh test user, but that starts GNOME, and I don't see how to select unity as a session in gdm?
<ogra_ac> gnome is the new unity ?
<didrocks> pitti: yeah, it will be the default this week as "Next release will mean unity by default" :)
<didrocks> pitti: wasn't stable enough last week, wanting to wait for a week
<didrocks> pitti: the gnome session will get unity by default (apart from existing natty user as explained because of the settings), I'll add a gnome-classic session in the same upload
<pitti> didrocks: ok, so it's not actually possible to test it right now?
<pitti> didrocks: thanks for confirming; seems it's all well underway :)
<didrocks> pitti: testing unity? you can, in checking it in ccsm
<pitti> ah
<didrocks> https://wiki.ubuntu.com/Unity/InstallationGuide
<pitti> well, when I said "starts GNOME" I should have said "half of GNOME", all the indicators crashed..
<pitti> but I guess I should be able to run ccsm
<pitti> didrocks: merci!
<cjwatson> geser: I suppose that would be OK; in that case anonymous login will have to be a non-default option
<cjwatson> geser: and yes, thinking about it that's probably what I saw
<didrocks> pitti: you're welcome
 * mdeslaur pulls ejection seat lever
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<RoAkSoAx> kirkland: howdy!! Let me know if you have a lil bit of time to discuss PowerNap
<lubosz>  hi. is there an automatic way to disable as much as unneeded modules possible in the kernel config, to shorten build time?
<lubosz> is there a possibility to not rebuild everything with make-kpkg every time?
<akheron> lubosz: try #ubuntu-kernel
<akheron> lubosz: and if you find out, tell me
<lubosz> akheron: thanks
<akheron> I once spent a week bisecting a kernel bug because one build took so long
<akheron> s/one/each/
<lubosz> sounds awfull :D
<lubosz> i have a core 2 notebook
<lubosz> and it takes about one hour
<lubosz> to compile the whole thing
<akheron> yes, for me it was like hour and a half
<akheron> and I had over 4k commits to bisect
<lubosz> i pulled patches today and had to recompile a lot
<lubosz> i guess the whole kernel
<lubosz> but i didnt check the time
<lubosz> 4k Oo
<lubosz> so a week sound fast for that :p
<lubosz> did you run git bisect with a script?
<lubosz> to check good or bad?
<akheron> no
<lubosz> hm, you had to do that by hand? :D
<akheron> yes
<akheron> after each build was finished, I copied the kernel to another machine and rebooted
<akheron> I had a boot time issue with an old laptop
<akheron> but hey, I found the offending commit and it's fixed now :D
<lubosz> so about 10 times to compile?
<akheron> no, it was more like 15 or 20
<akheron> as near the end there was a huge octopus merge of 10 branches or so
<lubosz> and you found the bug at the end ;) ?
<akheron> yes :)
<lubosz> nice
<akheron> actually, I'm using the laptop right now that didn't run back then
<lubosz> i hate compiling large things on a laptop
<lubosz> its a huge difference with a quad core with hyperthreading
<akheron> I didn't compile on a laptop, no way
<lubosz> my desktop is at home, and i'm at my partents, so i have to hack on my laptop :D
<akgraner> Anyone know the status of cobbler? https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-cobbler  I've got someone asking me and not sure where to point them to or just tell them it's permanently deferred?
<RoAkSoAx> akgraner: kirkland is looking into it for natty afaik
<akgraner> RoAkSoAx, thanks!
<RoAkSoAx> akgraner: ur welcome :)
<om26er> hi kenvandine
<kenvandine> hey om26er
<om26er> this is the branch https://code.launchpad.net/~om26er/ubuntu/maverick/gwibber/gwibber-fix-674894/+merge/40899
<om26er> can you upload it to -proposed
<kenvandine> om26er, sure can, i'll sponsor that
<om26er> kenvandine, congrats core-dev ;)
<kenvandine> thx
<kenvandine> :)
<fEnIo> hello
<fEnIo> could someone tell me why devscripts from Ubuntu doesn't contain debsign script?
<cjwatson> fEnIo: it does here
<cjwatson> $ zgrep debsign ~/ubuntu/dists/natty/Contents-i386.gz
<cjwatson> usr/bin/debsign                                             devel/devscripts
<fEnIo> ok... that was the most stupid question I've asked today
<cjwatson> :-
<fEnIo> sorry
<cjwatson> )
<cjwatson> (and that was stupid typing to make up for it)
<fEnIo> I installed devscripts but only in virtual machine, and then checked on host os
<fEnIo> nevermind
<fEnIo> sorry for bothering
<om26er> when i push a change to a branch does the reviewer get the email? or do i have to make a comment?
<lifeless> they do not [yet] get a notification that you have pushed more changes to the branch
<lifeless> assuming you have a merge proposal already existing :)
<stgraber> cjwatson: Hi, could you move sabayon from the ubuntu-desktop package set to the edubuntu packageset. It's a gnome upstream project but is only shipped by edubuntu and one of the upstream developers is in edubuntu-dev.
<ikonia> Riddell: you there ?
<testi> chrisccoulson, i made you the approver of a blueprint i wrote. (I'm new to this process, not sure if I'm doing things right here)
<testi> multiseat-admin-graph-ui
<quadrispro> hi all!
#ubuntu-devel 2010-11-24
<Riddell> ikonia: pong
<micahg> can we still upload SRUs to maverick-proposed on the assumption they will be copied to natty if maverick_version = natty_version?
<hallyn> doesn't an sru require fix committed in natty first?
<micahg> hallyn: well, normally yes, but I seem to recall a discussion about a script that auto copies stuff from maverick-updates to natty if maverick_version = natty_version
<hallyn> micahg: <shrug>  could well be, just doesn't match my understanding of the process.  my being wrong is by no means unlikely :)
<ebroder> micahg: My understanding was that that automated process was only for SRUs uploaded before the natty archive opened.
<ebroder> Was there a change made to plymouth between lucid and maverick that affects when the graphical vs. text splash screen is used?
<ebroder> On lucid I would ~always see a graphical splash, and if KMS wasn't working it would just be low res and low color. On maverick I seem to get a text splash if KMS doesn't work
<RAOF> ebroder: Yeah.  We turned off vga16fb to stop it *breaking everything*
<RAOF> Rather, there were a number of cases where vga16fb would load, scribble over the graphics state that the kms drivers were sure wouldn't change, and hang the machine.
 * ajmitch prefers the text splash :)
 * RAOF too.
<psusi> why?
<RAOF> It's *delightfully* geeky.
<lifeless> it boots my hardware
<ebroder> ROAF: Where was that change made? It doesn't look from the changelog like it was done in plymouth itself?
<psusi> I'm looking forward to grub immediately going graphic mode and staying that way
<lifeless> what I'd be happiest with is something that doesn't trash progress output from non lsb scripts.
<psusi> should be real nice if we ever get the grub gfxmenu set up by default
<lifeless> that would be like way retro: a readable boot console
<StevenK> lifeless: If it boots your hardware, you're one of the 1% or so :-)
<lifeless> StevenK: nokms boot my hardware
<lifeless> StevenK: everything else is fail
<RAOF> ebroder: It was made in the kernel, around the time of the Prague sprint when I went in to the kernel room and asked them to kindly stop breaking graphics ;)
<ebroder> RAOF: Ah, got it
<ebroder> RAOF: So...probably not something I could turn on in configuration if I was interested in living dangerously
<RAOF> You could get vga16fb to load; you just need to do it manually.
<RAOF> Although vesafb is probably a better bet; throwing a vga= on the end of your kernel command line should do it.
<ebroder> RAOF: Can I do that by hand by passing module arguments or something?
<ebroder> I guess I can probably just look in the source for that
<RAOF> Add âvga=askâ to your kernel command line in grub, after âquiet splashâ
<RAOF> Then when you boot the kernel will list the possible vesa modes, and you can select one.
<ebroder> RAOF: Right, but I want to setup something where it'll only use vesafb if KMS doesn't work (i.e. proprietary drivers). I'd prefer to not set a mode for all boots
<RAOF> Ah, yeah.  That's more difficult.
<ebroder> So I'm thinking of trying to pull something evil together like an initramfs script that runs after udev and before plymouth
<RAOF> I guess you could manually modprobe vesafb
<RAOF> *uvesafb
<ebroder> RAOF: Ah, that's what I was missing. I was looking at vesafb instead of uvesafb. Awesome, thanks
<ebroder> RAOF: Actually, do you know what happens if I just load uvesafb when a KMS driver already set the mode? Is it a NOOP, or does it break things?
<RAOF> If uvesafb touches the graphics state it's likely that the kms driver will explode into a thousand pieces.
<RAOF> Alternatively, it's possible that the kms driver will have changed the graphics state enough that *uvesafb* will explode in a thousand pieces :)
<ebroder> But either way if it's going to do something horrible, I should be able to test this and see something explode fairly obviously? It looks like passing video=uvesafb: might cause the /init-top/framebuffer script to do what I want
<RAOF> Sadly it's not guaranteed to explode immediately.  For example, when vga16fb was loaded, for most people it created /dev/fb1, which didn't get opened by anything.  But as soon as something *tried* to open /dev/fb1, graphics would hang.
<RAOF> There was a popular launchpad bug âRunning hwinfo -C causes the screen to go greenâ, caused because hwinfo probed /dev/fb1.
<RAOF> ebroder: Now that I think of it, the kms drivers have code to kick off a generic driver like uvesafb.  If you could guarantee that uvesafb loaded first you'd probably only have the problems with seamless-grub that caused it to slip for Maverick :)
<ebroder> RAOF: Ok, I can try that
<Sarvatt> vesafb loads early->plymouth loads framebuffer renderer plugin instead of drm->drmfb loads and kicks out vesafb->plymouth segfaults and your boot is screwed was the problem in maverick
<RAOF> Sarvatt: And wasn't there also one where radeon just plain died?
<ebroder> Oh, uh. Hmm...
<ebroder> Maybe I shouldn't try that...
<RAOF> I seem to recall that if you loaded the kms drivers into the initramfs it worked ok.
<Sarvatt> it was ok packed in the initrd but it was racy, 1 out of 10 boots or so would die here
<RAOF> Oh, that reminds me.  Time to un-framebuffer my grub so that I can actually see it.
<ebroder> Couldn't you work around that just by doing a udevadm settle in the udev initrd script?
<ebroder> (Doesn't it do that already...?)
<ebroder> Ah, no - just a trigger
<RAOF> I don't think it does, as that would kill boot performance?
<ebroder> What about something like trigger fb devices, settle, trigger everything else?
<RAOF> With a "load uvesafb if no other fb devices" bit?
<RAOF> You'll still lose quite a lot of boot time; i915 is pretty slow at initialising (from memory, pitti suggested it was ~2sec worth of initialisation)
<ebroder> Ouch. That's pretty bad
<ebroder> I...think I'm suitably convinced that I should figure out how to solve my problems using the text splash :)
<RAOF> It's still a goal to make seamless-grub work in Natty, I think, so you could piggy-back on that effort.
<RAOF> I don't think that's a solved problem yet, though.
<ebroder> RAOF: Yeah, I've got the workitem to figure out how to make hardware blacklisting/whitelisting work. I'm hoping to get that sorted out during some of my Thanksgiving time off
<jfer> can someone help me with packaging skype-call-recorder? it is my firsty package
<jfer> *first
<dholbach> good morning!
<bilalakhtar> Good morning dholbach
<dholbach> hey bilalakhtar
<didrocks> good morning
<pitti> Good morning
<RenatoSilva> anyone involved with purple-plugins-pack?
<micahg> RenatoSilva: I use it
<RenatoSilva> there's a typo bug which leads to a plugin not being included
<micahg> RenatoSilva: ok, can you file a bug and give me the bug #?
<RenatoSilva> I think ircmore was renamed to irc-more for some crazy reason, but the package maintainer didn't notice and package config is still outdated
<RenatoSilva> what is funny is that the package was succesfully built even when trying to include a non-existing plugin
<micahg> debian 604763
<ubottu> Debian bug 604763 in pidgin-plugin-pack "Missing IRC-More plugin" [Normal,Open] http://bugs.debian.org/604763
<micahg> filed an hour ago
<RenatoSilva> micahg: should still file one in Launchpad?
<micahg> RenatoSilva: well, we don't currently have a diff, but if the change is small enough, we might be able to SRU, so yes
<micahg> RenatoSilva: are you able to provide a debdiff for it?
<micahg> RenatoSilva: actually, we should really move this to #ubuntu-motu
<sladen> what happened to UpstreamVersionFreeze, did that get rolled into FeatureFreeze?
 * micahg didn't know there was an upstreamverisionfreeze :-/
<micahg> sladen: seems to fit the definition here: https://wiki.ubuntu.com/FeatureFreeze
<RenatoSilva> micahg: I'm there
<bilalakhtar> I got this email today, even though the source package got accepted: http://paste.ubuntu.com/535806/
<bilalakhtar> Could someone archive-admin please look at it
<bilalakhtar> binaries of other archs also got into the archive
<mr_pouit> bilalakhtar: https://launchpad.net/ubuntu/+source/gcc-defaults/1.82ubuntu2
<soren> bilalakhtar: In a nutshell, another source package has built those binary packages with a newer version.
<mvo> soren: could you please have a look at https://code.launchpad.net/~mvo/vmbuilder/add-natty/+merge/40977 ? or alternatively give me access to trunk so that I can just merge it myself?
<mvo> (or tell me who to nag instead ;)
<dholbach> Amaranth, heya - who's maintaining alacarte upstream now? I was just looking at gnome bug 608221
<ubottu> Gnome bug 608221 in general "Drag-and-drop of items downwards is off by one" [Minor,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=608221
<soren> mvo: I'm still the closest VMBuilder has to a maintainer.
<seb128> dholbach, nobody
<seb128> dholbach, it's not actively maintained for a while
<dholbach> seb128, that explains it :)
<bilalakhtar> Did someone reply to my thing?
<micahg> bilalakhtar: gcc-defaults is building the source package, you should probably talk to doko
<micahg> s/source/binary
<bilalakhtar> okay, thanks, micahg
<micahg> bilalakhtar: mr_pouit responded with that above :)
<bilalakhtar> thanks
<soren> mvo: Let me take a look.
<bilalakhtar> actually, my system went down due to processor overheat
<bilalakhtar> and I am fed up of this laptop
<vish> dholbach: i had spoken to Amaranth about that bug a while ago, and he mentioned we can patch it in Ubuntu.. since upstream is unmaintained..
<vish> the alacarte one..
<cjwatson> stgraber: done
<gaurava> hey all .. from yesterday .. I am struggling to setup a serial console on my ubuntu 10.10 machine ..
<gaurava> ny help would be great
<gaurava> I am basically following this article for the setup <https://help.ubuntu.com/community/SerialConsoleHowto> but no luck so far
<gaurava> Then I simply connect the serial cable .. and trying to write on it .. by using command: $ > ehco "abcd" > /dev/ttyS0
<gaurava> I can see that interrupts assigned to /dev/ttyS0 (IRQ - 4) is increasing ..
<gaurava>  but still there is no output on the other machine ..
<gaurava> group ..  ny idea what is going on and how can  i troubleshoot the problem further?
<cjwatson> use a proper serial console client, such as picocom, rather than writing directly to the device.  also make sure the baud rate and other settings match on both sides.
<gaurava> cjwatson, baudrate is same on both of my machines..
<gaurava> will try with the picocom on the sender side.. already using the minicom on the receiving end
<cjwatson> picocom, minicom, whatever
<gaurava> cjwatson,  can we use the picocom/minicom to send the data ?
<cjwatson> yes, if I'm understanding you correctly
<cjwatson> this really isn't a topic for #ubuntu-devel though ...
<gaurava> ok .. in dat case can you point me to the right forum/direction..
<Chipzz> #ubuntu or the forums
<gaurava> thanks Chipzz, since setting up serial console is the prestep to debug a kernel crash, I thought one can ask this question over here..
<Chipzz> you could try on #ubuntu-kernel
<Chipzz> but I'm not 100% sure if it's appropriate there
<gaurava> ok thanks once again .. will try my luck over there
<Chipzz> gl getting it to work!
<Chipzz> btw, are you sure you're using the right cable?
<Chipzz> and if it's working correctly?
<gaurava> I am not sure.. i just bought these cables from the market yesterday itself ..
<gaurava> so i guess.. they  would be fine
<Chipzz> right, probably should be. but there are serial cables and then there are serial cables
<gaurava> :)
<gaurava> if there is any quick test that I can run upon or ask someone else to check if the cables are fine or not?
<Chipzz> not sure, been a while since I messed with serial cables
<Chipzz> but I recall there being more than one way to wire them
<Chipzz> anyway, try on #ubuntu-kernel ;)
<gaurava> thanks once again .. will ping over there
<Amaranth> dholbach: I didn't see much point in fixing the little bugs while the big ones were still there then the big ones required a spec change then I gave up
<dholbach> a spec change?
<Amaranth> dholbach: Yeah, NoDisplay has too many meanings
<dholbach> ah ok, still it might be good to fix the small bugs already :)
<dholbach> but I understand - a shame that nobody has the time to look after it :/
<Amaranth> dholbach: Once the discussion on changing the spec didn't get anywhere I decided the menu system was even more broken than I thought when I was writing alacarte
 * dholbach nods
<Amaranth> So I switched to docky and gnome-do and removed my menu
<Amaranth> Someone else was trying to maintain it for awhile, even made a release or two
<ogra_ac_> cjwatson, urgh, thanks for spotting the shadow issue, i somehow only looked at the conflicts in the report on MoM
<dholbach> thanks Amaranth
 * ogra_ac_ merges now
<Amaranth> dholbach: heh, thanks for depressing you? :)
<dholbach> no for the feedback
<cjwatson> ogra_ac_: ok, please mark the sync bug Invalid then
<ogra_ac_> will do
<dholbach> it's that there's a patch in the sponsoring queue right now and it seems nobody uploaded because upstream didn't comment on it
<cjwatson> (there's a little archive admin script that prints all the changes since the last Debian upload; I routinely use it as a quick validator for sync requests)
<Amaranth> dholbach: The only patches I don't agree with are ones that add UI but someone else was making releases so I don't consider myself the maintainer anymore
<ogra_ac> well, i could have looked at the merged changelog first
<Daviey> no patch pilot :(
<cjwatson> it's mterry's turn today, but he's probably not around yet
<cjwatson> for the rest of this week there's only one pilot per day on the schedule
<BlackZ> cjwatson: can you please retry the build of the last apr version in natty?
<BlackZ> cjwatson: on all archs..
<cjwatson> BlackZ: what changed since the initial attempts?
<BlackZ> cjwatson: bug #671441 got fixed in launchpad-buildd
<ubottu> Launchpad bug 671441 in joblib (Ubuntu) "Can't mount /dev/shm as tmpfs in the buildd" [Medium,Confirmed] https://launchpad.net/bugs/671441
<cjwatson> BlackZ: ok, thanks, retried
<BlackZ> cjwatson: thank you :)
<freeflying> pitti, ping
<sebner> cjwatson: thanks for the quick syncs :) Should I use syncpackage in future as it's extrawork for you? I'm not really in a hurry so I use still requestsync
<cjwatson> no, please don't, requestsync is very little work nowadays
<cjwatson> syncs are generally processed at least daily
<sebner> cjwatson: aye aye :)
<doko> ScottK: no, gcc-defaults has just a symlink
<ScottK> doko: OK.  Thanks.
<ScottK> doko: Another gcc issue that I think needs some investigation is in this build log.  It looks like it's trying to buid in /usr/lib64 (built fine on Debian): http://launchpadlibrarian.net/58604511/buildlog_ubuntu-natty-amd64.libclamunrar_0.96.4-1_FAILEDTOBUILD.txt.gz
<doko> ScottK: that should be fixed in the package
<bdrung> sebner: use requestsync - some people don't like syncpackage
<sebner> bdrung: I noticed =)
<ScottK> doko: Is gcc in Ubuntu intended to be different than in Debian about this?
<doko>  /usr/lib64 is fine, but it's a symlink
<doko> 4.4 != 4.5
<ScottK> OK.
<ScottK> So what 4.5 change is this?
<doko> I think I fixed it in the repo, but the assumption of the package is just wrong
<doko> same with the 4.5.x and 4.5 symlink in gcc_lib_dir
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mterry
 * mterry waves
 * dholbach hugs mterry
<dholbach> woohoo!
<sebner> cjwatson: ah, I just noticed your comment. Of course we are before DIF! Sorry for that. Just a habit
 * sebner hugs dholbach =)
<dholbach> hey sebner
<cjwatson> sebner: np
<czajkowski> ShaneM: get sorted?
<ShaneM> czajkowski: Just doing it now.
<czajkowski> ok
<ari-tczew> mterry: could you sponsor bug 663343?
<ubottu> Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343
<mterry> ari-tczew, looking at it
<ari-tczew> mterry: IMO set as won't fix and unsubscribe sponsors ^^
<mterry> ari-tczew, well, the patch from clint looks legit.  I think I'll take advice from Barry and open a new bug for it though
<ari-tczew> mterry: Debian has older version.
<mterry> ari-tczew, agreed.  We wouldn't downgrade the version, but the Debian maintainer made some packaging changes at the same time as they updated the version.  In Ubuntu, we leapfrogged that version, but didn't make the same packaging chagnes
<mterry> They were good changes, so we should 'sync' up with those changes
<ari-tczew> mterry: aha, so go ahead
<highvoltage> 14:37 < stgraber> cjwatson: Hi, could you move sabayon from the ubuntu-desktop package set to the edubuntu packageset. It's a gnome upstream project but is only shipped by edubuntu and one of the upstream developers is in edubuntu-dev.
<highvoltage> cjwatson: did you perhaps have any chance to look at that?
<cjwatson> highvoltage: 10:22 <cjwatson> stgraber: done
<highvoltage> cjwatson: merci!
<mterry> ari-tczew, so I moved the bug and commented on the patch, but I can't actually upload to main.  But it should be all ready to go
<ari-tczew> mterry: ah, you're not core-dev member
<mterry> nope.  QQ
<bdrung> mterry: are you waiting for the next sponsor request?
<mterry> bdrung, if you have a suggestion, I'll look at it.  But I'm going through the queue otherwise
<bdrung> mterry: my suggestion is to go to http://reports.qa.ubuntu.com/reports/sponsoring/ and start from the top.
<mterry> bdrung, :)  OK thanks
<bdrung> mterry: the list is sorted by time in queue. picking the one on the top would processing the list like a queue. :)
<bdrung> mterry: do you know sponsor-patch?
<mterry> bdrung, no, that's nice!  I do that manually.  So painful
 * mterry adds these notes to the patch pilot wiki
<smoser> pitti, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/671103 put new cloud-init into -proposed, but it brought a new binary package
<smoser> which needs to be allowed into the archive
 * cjwatson lands >3 months of grub2 changes on Ubuntu at once and hopes that people's systems still boot
<smoser> (grub-legacy-ec2).  Can someone allow that backport in ?
<bdrung> mterry: i wrote sponsor-patch to make sponsoring simple. it does many checks and tries to build the package.
<highvoltage> ooh, risky updates! I'll be sure to test!
<AbsintheSyringe> once Ubuntu does move to rolling releases, will it be based on Debian CUT or ... ?
<bdrung> AbsintheSyringe: i think someone over-interpreted something
<ogra_ac> whats debian CUT ?
<AbsintheSyringe> bdrung, how come?
<ogra_ac> a new name for experimental ?
<AbsintheSyringe> ogra_ac, no no http://kitenet.net/~joey/code/debian/cut/
<AbsintheSyringe> there was a lecture on this years debconf10, and I think this is the way to go actually
<bdrung> AbsintheSyringe: gimme your sources
<ogra_ac> aha
<AbsintheSyringe> bdrung, http://linux.slashdot.org/story/10/11/24/1346221/Ubuntu-May-Move-To-Rolling-Releases?from=fb
<AbsintheSyringe> I personally think Debian CUT and Ubuntu rolling releases are future towards all linux platforms should be heading to, including android
<AbsintheSyringe> and I remember there was talk about ubutnu rolling releases before this, just can't remember where
<cjwatson> AbsintheSyringe: at present Ubuntu has no plans I'm aware of to move to a rolling model
<AbsintheSyringe> cjwatson, hype?
<cjwatson> I think overinterpreted long-term thoughts, perhaps
<cjwatson> I hadn't seen that comment from Mark before now
<bdrung> AbsintheSyringe: think about the extra repository - this is the first step in the direction of more frequently updates
<AbsintheSyringe> yea, I don't see it happening right now either, but on long term ... I think it should be done
<AbsintheSyringe> bdrung, true ...
<cjwatson> I suspect what we might end up with is a model with a stable base (of about the scale of current Ubuntu) and a collection of software-center-accessible PPAs with newer versions of things so you can pick and choose; but I really don't know, as I say Mark's comment is new to me
<cjwatson> it's certainly too early to be making concrete predictions about what it would be based on
<ogra_ac> "Today we have a six-month release cycle," Shuttleworth said. "In an internet-oriented world, we need to be able to release something every day."
<ogra_ac> intresting that they didnt make it "Ubuntu plans daily releases" on slashdot
<pitti> smoser: I already NEWed it yesterday
<smoser> pitti, ... so it requires an admin now ?
<pitti> smoser: no, I already did that
<smoser> i'm sorry for not understanding process. i just tried to verify and its not in archive
<cjwatson> let me modify my previous comment: we have nothing at the moment that I know of that resembles a concrete tactical plan, rather than long-term strategy
<bdrung> haha, imagine someone says: "ubuntu has daily builds" and a press guy writes "Ubuntu-May-Move-To-Rolling-Releases" :)
<AbsintheSyringe> :D
<pitti> smoser: "rmadison -s lucid-proposed -S cloud-init" says that it's in
<smoser> at least wasnt in ec2 archive ... hmm. i dont see cloud-init either in proposed there. maybe that mirror is just beind.
<pitti> smoser: so it might be mirror lag
<sladen> cjwatson: isn't Mark's comment actually about the extras repo
<jussi> pitti: for bu #617885 - how many people do you need to test it?
<cjwatson> sladen: it's too short to be able to tell :)
<jussi> thats bug 617885
<ubottu> Launchpad bug 617885 in gparted (Ubuntu Maverick) "gparted crash at start: glibmm-ERROR **" [High,Fix committed] https://launchpad.net/bugs/617885
<pitti> jussi: usually one is enough
<cjwatson> speculation filtered through news sites, what a way to go
<jussi> pitti: so all good to up it to the repo propper now?
<pitti> jussi: it needs to stay in -proposed for 7 days so that we have a chance to catch regression reports
<jussi> pitti: ahh, ok. great. please ping me if you need more testers for that (or others similar)
<seb128> doko, bug #677387
<ubottu> Launchpad bug 677387 in libgnome (Ubuntu) "libgnome b-d on libcanberra, which cannot be availabe at this time" [High,Confirmed] https://launchpad.net/bugs/677387
<seb128> not sure we can do something about that
<Gulfstream> I am using Natty (upgraded to it last night), and the bar above the window has disappeared (the bar for the minimize, maximize, and close buttons), is there a way to get it back?
<seb128> I guess you need to build it manually if you need to start a port
<seb128> Gulfstream, hi, try #ubuntu for user questions
<jussi> Gulfstream: support for natty is in #ubuntu+1
<doko> these are no build-deps, that's library incest
<Gulfstream> #ubuntu+1
<jussi> yes
<Gulfstream> ?
<Gulfstream> okay
<Gulfstream> thanks
<seb128> doko, well in any case it's not going to be worked
<seb128> doko, libgnome is deprecated, we are getting ride of it at some point but not this cycle
<doko> seb128: but honestly, it's time for a window manager in main, which doesn't depend on the whole of gnome
<doko> metacity has the same dependencies
<seb128> compiz?
<seb128> it's the default wm and it depends on nothing from GNOME
<ogra_ac> it depends on working GL
<epictetus> it took me hours and hours to re-compile a working kernel package including the OSS emulation drivers. Pulseaudio is awful -- it solves a bunch of problems I never cared about and creates a bunch of new problems that I actually do care about.
<seb128> ogra_ac, not really, 0.9 should fallback to 2d
<ogra_ac> sweet !
 * ogra_ac didnt know that
<seb128> it might still be buggy in that regard because it's new but that should work
<seb128> it should just turn off options that need gl
<doko> seb128: "it"? how?
<seb128> doko, how what?
<doko> <seb128> it should just turn off options that need gl
<doko> and works on powerpc?
<seb128> dunno about powerpc
<ogra_ac> on ARM !
<seb128> well that was discussed to use compiz 2d as fallback at UDS
<seb128> they say the code is a bit young and might need work
<doko> ok, so better stay away from it. honestly, I'd rather like to use twm, which doesn't change every few weeks ...
<cjwatson> is the "Subscribe someone else" ajax thing on Launchpad bugs broken for anyone else?
<ogra_ac> worked this morning for me
<seb128> cjwatson, how broken?
<seb128> doko, nobody stop you to use twm if you want
<cjwatson> seb128: does nothing
<cjwatson> hm, maybe I should try restarting firefox
<doko> seb128: just needs promotion ...
<seb128> cjwatson, works for me
<seb128> I just tried on a bug
<seb128> doko, you are in the mir team so just ack it ;-)
<pitti> doko: if twm is so much easier, I don't see anything wrong with promoting it for these test cases
<cjwatson> seb128: might be firefox 4 specific; I filed bug 681003
<ubottu> Launchpad bug 681003 in Launchpad Bugs "+addsubscribers AJAX link does nothing" [Undecided,New] https://launchpad.net/bugs/681003
<doko> pitti: I would prefer it, because you know that it doesn't change, and it does work
<pitti> so, let's do that then?
<doko> pitti: reopening the MIR. is it possible for past releases too?
<pitti> I don't think we can change it in stables
<pitti> we could do a no-change upload to -proposed, but frankly for those it seems easier to just use dbus-launch metacity
<doko> maybe, at least the old versions don't depend on canberra
<cjwatson> is anyone working on an evolution-couchdb upload for evolution 3.32?
<seb128> cjwatson, I'm using firefox4 there
<seb128> cjwatson, yes, rodrigo
<seb128> <rodrigo_> didrocks, ok, I'll release evo-couchdb, which includes the fixes to compile with 2.31/32, and package it
<seb128> that was a bit earlier today
<cjwatson> kees: you made cpu-checker depend on msr-tools in universe, so it's now uninstallable; can you deal with the MIR side of that?
<cjwatson> ok
 * ogra_ac sighs about shadow 
 * SpamapS curses the baby for letting him sleep until 8:30am and miss the tech talk
<cjwatson> it's only recently started
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<zul> pitti: will you accept a new SRU that has an upstart job that wasnt there before?
<SpamapS> zul: rrwhhhzaaaa? that sounds a bit crazy. ;)
<pitti> zul: would need a really good rationale; these can potentially break the system, so nothing with complex dependencies can be added
<zul> pitti: this is the one https://bugs.edge.launchpad.net/ubuntu/+source/tgt/+bug/574554 i was talking about
<zul> the upstart script is really simple and its not a widely used piece of software
<pitti> zul: http://launchpadlibrarian.net/53388867/tgt_1.0.4-1ubuntu4.debdiff ?
<pitti> zul: it would suddently start the daemon for people who have it installed, so that might be an unexpected behaviour change
<zul> pitti: right
<pitti> but it seems that the job is already there, but has a typo?
<pitti> post-start is not the right place to launch the main daemon, thuogh
<zul> pitti: i think its for lucid actually
<nijaba> zul: yep, we would need it in lucid
<pitti> ah, right, fixed in maverick already
<pitti> my feeling is that we shouldn't do those behavioural changes a year after release; it's too unexpected
<pitti> (in both directions)
<zul> hmm...ok
<pitti> -backports would be fine for me, if appropriate
<zul> gotcha
<nijaba> pitti: hmmm... that could work for me, indeed
<nijaba> zul: so, backport?
<zul> nijaba: yes
<nijaba> zul: I just need to find the correct way to document activating this particular package from backport in the doc.  should not be too hard
<zul> nijaba: https://help.ubuntu.com/community/UbuntuBackports
<pitti> good night everyoen
<nijaba> zul: pinning wilth apt-get install -t will work just great.  thanks a lot
<zul> nijaba: no problems
<ScottK> nijaba: What won't work with the repository pinned down is pulling depends also from backports.
<nijaba> ScottK: sure, but for that particular, we don't have that req
<ScottK> OK.
<nijaba> ScottK: but thanks for letting me know
<sladen> sense: re: papercuts-ninjas, I think the way that it is normally done is by subscribing the team (think ubuntu-archive and such) rather than assigning the team
<sladen> sense: assigning the team means that the team will stop getting emails when somebody /on/ the team evetually subscribes themselves and makes it  In Progress
<Keybuk> pitti: so do you think that talk was ultimately interesting or useful?
<Keybuk> I hoped that by covering some of the design history, the reason for its differences for systemd would be apparent
<Keybuk> but I'm not sure how successful I was at pulling that off
<mmoya> is launchpad.net down?
<htorque> mmoya, http://downforeveryoneorjustme.com/launchpad.net ;-)
<htorque> mmoya, or simply: "no" :-)
<mmoya> htorque: je, ok, didn't know that site
<SpamapS> Keybuk: after the talk, its clear to me why upstart was written, and why Ubuntu will continue to use it. Its not clear to me why systemd was created instead of just working on the state refactor.
<Keybuk> well indeed
<Keybuk> that's never been clear to me
<Keybuk> even if you assume Copyright assignment
<SpamapS> which is what I assumed before, but now it doesn't seem so obvious
<Keybuk> the upstart-socket-bridge process (if Lenny believes that's the killer feature) could have always been a separate tarball
<Keybuk> upstart-udev-bridge is separate, after all
<SpamapS> I also don't understand why service activation in the init daemon is all that key but thats probably because I'm a server kind of guy. ;)
<Keybuk> to be honest, I simply think Lennart wants to personally write his own OS
<Keybuk> it makes some amount of sense to have a single service supervisor
<Keybuk> something that can start things, stop things and keep things running
<Keybuk> so you may as well make it the init daemon
<SpamapS> I like that part, I don't know about the network sockets being passed around bit.
<Keybuk> well, in the design of upstart (and afaik systemd too) those are just separate services started by init
<Keybuk> which themselves tell init to start services
<Keybuk> so they're not "in the init daemon" - it's more that the init daemon is flexible enough to support people who want to do that
<SpamapS> That makes more sense then.
<SpamapS> I like the idea of having one, small file that defines the reason and method for a service starting and stopping.
<SpamapS> instead of it being an init.d, or in inetd.conf , or xinetd.d .. or or or..
<Keybuk> yeah, that's kinda a difference between systemd and upstart
<Keybuk> upstart is all about "one file to define everything"
<Keybuk> systemd is "one type of file to define one type of thing => lots of files to define *something*"
<SpamapS> so, to answer your question, I do think that the history section was helpful to many of us who have only recently arrived or were not involved in the discussions..
<SpamapS> But the discussion of systemd was harmed, I think, by Lenny's emotional rants.
<Keybuk> ultimately Lenny doesn't understand why I think upstart's design is better
<Keybuk> and therefore he'll never see the point
<Keybuk> and I have a strong suspicion that if it suddenly clicked with him
<Keybuk> and he realised why I like upstart's design
<Keybuk> his reaction would be to go and write something like that into systemd
<Keybuk> and come back with "there, systemd does that too, now you can use systemd?!"
<mneptok> 12:48 < Keybuk> it makes some amount of sense to have a single service supervisor   <---- are you channeling my wife?!
<Keybuk> mneptok: not only that, but she was channelling me last time you two were in bed together
<SpamapS> =-o
<mneptok> Keybuk: explains my greater-than-usual arousal. and her moustache.
<highvoltage> If I understood what you were talking about I'd probably say "TMI".
<Keybuk> TMK is probably equally valid
<ebroder> AbsintheSyringe: Did you see rickspencer3's blog post? (http://theravingrick.blogspot.com/2010/11/ubuntu-is-not-moving-to-rolling-release.html)
<AbsintheSyringe> ebroder, I haven't, I'll write my own post, it'll appear on planet debian, why this should be done
<AbsintheSyringe> ebroder, well this post explains term "press" :)
<AbsintheSyringe> ebroder, tnx for explain btw :)
<AbsintheSyringe> clarification that is
<bdrung> AbsintheSyringe: i was right. yeah :D
<ari-tczew> SpamapS: around?
<SpamapS> ari-tczew: yes, whats up?
<ari-tczew> SpamapS: did you reconsider SRU for bug 370994?
<ubottu> Launchpad bug 370994 in drupal6 (Ubuntu) "more info for the users needed" [Critical,Fix released] https://launchpad.net/bugs/370994
<SpamapS> ari-tczew: AFAICT its never been accepted
<SpamapS> ari-tczew: once its accepted for Lucid (I think the other two are pretty unlikely at this point) then we can certainly backport.
<SpamapS> ari-tczew: I'll bring it up at the next server team meeting.
<ari-tczew> ok thanks for your feedback SpamapS
<SpamapS> ari-tczew: btw, since drupal6 is universe, #ubuntu-motu may be a good place to ask.
<ari-tczew> SpamapS: sure
<bdrung> cjwatson: you broke my natty VM
<SpamapS> bdrung: thats like the old TV commercial.. "you sunk my battleship!"
<bdrung> SpamapS: 8 hours ago: "cjwatson lands >3 months of grub2 changes on Ubuntu at once and hopes that people's systems still boot"
<bdrung> cjwatson: i end up in the grub terminal. what should i do to debug the issue?
<sebner> bdrung: thanks you very much! Just wanted to do an update! :D :D :D
 * sebner hugs bdrung 
<bdrung> :)
<bdrung> sebner: make an backup / snapshot and then try to upgrade grub. maybe you don't hit that bug
<SpamapS> bdrung: no time like alpha1 for grub changes. ;)
 * sebner hides
 * sebner pokes cjwatson to fix the system of poor bdrung 
<sebner> wahhh
 * sebner just installed the grub update per accident xD
<bdrung> sebner: then don't reboot. muhaha
<sebner> xD
<sebner> bdrung: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/657788
<bdrung> sebner: maybe the problem was triggered by removing the old kernel
<AbsintheSyringe> bdrung, yep you were :)
<sebner> bdrung: hmm I think I'm too lazy to downgrade grub. so hibernate for today :D
<bdrung> sebner: hibernate? isn't suspend the right mode?
<bdrung> cjwatson: i have one menu entry in /boot/grub/grub.cfg: Ubuntu, with Linux 2.6.37-6-generic
<sebner> bdrung: hmm, I neither use suspend to ram nor hibernate so I'm always mistaking them xD
<bdrung> sebner: i am using suspend a lot on my desktop (because the bios takes too long to boot)
<sebner> bdrung: /here rebooting is actually faster than suspend to ram + extra time until wlan works again
<bdrung> sebner: my bios takes ~ 30 secs till grub and then http://overbenny.wordpress.com/2010/04/03/ubuntu-10-04-lucid-lynx-boots-fast/
<sebner> bdrung: that's really epic fail xD
<bdrung> sebner: gimme 400 bucks and i will replace the mainboard with as faster bios ;)
<sebner> bdrung: ask canonical instead, /me is a poor student :P
<bdrung> sebner: me too :)
<cjwatson> bdrung: what happens if you say 'insmod normal' and then 'normal'?
<cjwatson> might get better errors that way
<cjwatson> sebner: doubt it's the same as bug 657788
<ubottu> Launchpad bug 657788 in grub2 (Ubuntu Maverick) "grub minimal bash after first Maverick update" [Critical,New] https://launchpad.net/bugs/657788
<cjwatson> don't confuse symptom with cause :)
<bdrung> cjwatson: error: unknown command 'lua'.
<bdrung> syntax error
<bdrung> incorrect command
<cjwatson> huh, interesting
 * cjwatson blames ebroder :-)
<ebroder> Wait we have lua now?
<cjwatson> I merged your branch, like I said
<ebroder> Oh, awesome
<cjwatson> probably only temporary given Robert's comments though
<ebroder> ...except for the breaking bit :)
<cjwatson> I don't want to carry that divergence permanently, I just want to get moving on the boot graphics stuff
<cjwatson> /boot/grub/lua.mod exists in my natty vm
<ebroder> cjwatson: Yeah, sure. I was planning to try and create a "hwmatch" C-based command during my Thanksgiving time off that we could carry as a distro patch while we work out the best long-term approach with upstream
<cjwatson> bdrung: 'ls $prefix/lua.mod'
<ebroder> If there are objections to turning on Lua, then having the ugly C command at least avoids opening those floodgates
<cjwatson> indeed
<bdrung> cjwatson: there is no lua.mod in (hd0,1)/boot/grub/
<cjwatson> bdrung: tell me about your disk layout
<bdrung> cjwatson: (hd0,1) is the root partition mounted at /
<ebroder> bdrung: Do you have a lua.mod in (hd0,1)/usr/lib/grub/i386-pc/?
<cjwatson> it's definitely in the package, both i386 and amd64
<bdrung> ebroder: yes, (hd0,1)/usr/lib/grub/i386-pc/lua.mod is there (i am on amd64)
<cjwatson> any problems during the upgrade?
<cjwatson> oh, I bet you have grub-pc/install_devices set to nothing
<bdrung> no errors, but i don't know if there were any warnings
<cjwatson> you should have had a debconf warning about that, though it will only warn once
<cjwatson> (perhaps some time ago)
<cjwatson> that will mean you're running an old grub with a new configuration file
<bdrung> cjwatson: where do i find grub-pc/install_devices?
<cjwatson> in the debconf database
<cjwatson> so, slightly tedious but you can certainly boot this
<ebroder> cjwatson: I thought I checked that the config will fallback gracefully in that case...
<cjwatson> 'set pager=1', 'cat /boot/grub/grub.cfg', page through until you find the menuentry block you want to boot, make a note of the commands, enter them all in sequence, then type 'boot'
<cjwatson> ebroder: well, I had to modify your patch somewhat because it was syntactically invalid in at least two ways ... :-)
<cjwatson> ebroder: so might want to try the version in the archive
<cjwatson> bdrung: once you've booted, 'sudo debconf-show grub-pc | grep install_devices'
<ebroder> cjwatson: Oh, whoops. I'll take a look
<cjwatson> ebroder: could be that whatever version of normal.mod bdrung has doesn't deal with missing commands very gracefully
<bdrung> cjwatson: what's the alternative to specifying an UUID?
<cjwatson> it would be nice to know what version is actually installed
<cjwatson> bdrung: 'set root=(hd0,1)'
<cjwatson> it's probably there already, and if it is, just leave out the 'search' command
<cjwatson> I think  strings /boot/grub/normal.mod | grep '^1\.9'  should tell you what version of GRUB is installed (not very reliable of course but it works here)
<cjwatson> maybe I'm going to have to start recording the installed version, and implementing thresholds for popping up the debconf warning again, or something
<cjwatson> http://paste.ubuntu.com/536085/ is the warning that should have been produced at some point in the past, if this is what I think it is
<ebroder> cjwatson: Your code doesn't look interesting different from mine. I was using "if lua ..." so that we would handle the command not being there gracefully. If that doesn't work, maybe we can do an "if insmod lua; then lua ..."
<cjwatson> mm, perhaps
<cjwatson> revisions 2068 and 2069 were my changes
<ebroder> Oof, that's embarrassing. I *swear* I fixed that missing fi at least twice. Anyway, I can investigate if insmod'ing a non-existant module gives a useful error code later this evening
<cjwatson> I think we need to know what normal.mod version bdrung has first
<bdrung> cjwatson: mounting (hd0,1) on /root failed: no such file or directory
<bdrung> what did i miss?
<ebroder> bdrung: You need to set root=(hd0,1) for grub, but pass root=/dev/sda1 or whatever to the kernel
<cjwatson> you put root=(hd0,1) in the 'linux' line ... what he said
<bdrung> i put root=(hd0,1) in the 'linux' line
<ebroder> Right. That needs to be /dev/sda1 (or whatever)
<bdrung> next try...
 * bdrung hates the us keyboard layout
<sebner> cjwatson: so it might be safe to reboot for me?
<ebroder> sebner: Definitely check to see if you have a /boot/grub/lua.mod first
 * sebner checks
<ion> Itâs much, *much* better than the fi(nnish) layout.
<ion> fwiw
<cjwatson> sebner: 'sudo debconf-show grub-pc | grep install_devices'
<cjwatson> if you actually have a reasonable setting there (it should have at least one disk device in it), you should be fine
<cjwatson> and almost everyone should
<bdrung> ion: but not if you have a german keyboard and have to guess where "=", "/", ... etc are
<sebner> ebroder: it's there
<sebner> cjwatson: yeah my harddrive is listed (1 line)
<sebner> cjwatson: http://pastebin.com/3fyPZj6p
<sebner> bdrung: happens to me too all the time :D
<bdrung> sebner: but i am used to neo2 layout...
<ion> bdrung: It doesnât take long to store them into muscle memory. At that point, youâll notice programming anything or using the shell or using vim or whatever is a pain in the local layout where you need to do nasty altgr combinations to get special characters.
<sebner> bdrung: ok that's even worse then :D
<bdrung> ebroder: third try: it's /dev/vda1 not sda1
<cjwatson> sebner: should be fine
<cjwatson> ah.  I think there is a known bug about virtio devices not being listed in the install_devices select list
<sebner> :)
<bdrung> cjwatson: http://paste2.org/p/1108205
<bdrung> that's the result of 'sudo debconf-show grub-pc | grep install_devices'
<cjwatson> right, so you were warned about this in the past according to that :)
<bdrung> nice excuse :)
<cjwatson> easiest fix for now at least is probably:  echo SET grub-pc/install_devices /dev/vda | sudo debconf-communicate; sudo grub-install /dev/vda
<cjwatson> and bug 604335 is the rest
<ubottu> Launchpad bug 604335 in grub2 (Ubuntu) "grub-pc.postinst script fails to detect virtio vda disk in KVM guest" [High,Triaged] https://launchpad.net/bugs/604335
<bdrung> cjwatson: should i apply the fix or keep that version of my VM for testing bug fixes?
<ebroder> bdrung: Before installing the new grub, can you find out what version of normal.mod you had?
<ebroder> (If you haven't already)
<cjwatson> yes, what ebroder said
<cjwatson> aside from that you can go ahead and apply the fix
<cjwatson> as I said above:  strings /boot/grub/normal.mod | grep '^1\.9'
<bdrung> ebroder: 1.98-1ubuntu1
<ebroder> Looks like pre-release Lucid
<cjwatson> yes
<cjwatson> I'm surprised it's worked this long
<bdrung> ebroder: that's my devel release testing vm
<ebroder> cjwatson: Well, when I get a chance, I'll grab that version and test with it. If we can make the new config file compatible, there's no reason not to
<cjwatson> yes, although it's really just papering over a problem, upstream definitely doesn't guarantee compatibility there
<RAOF> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: RAOF
<bdrung> RAOF: my suggestion is to go to http://reports.qa.ubuntu.com/reports/sponsoring/ and start from the top if you want to process the request like a queue
<bdrung> RAOF: do you know sponsor-patch?
<RAOF> I do not, no.
<RAOF> It's in ubuntu-dev-tools?
<bdrung> yes
 * RAOF checks it out.
 * bdrung should blog about it
<bdrung> whom can i blame if compiz/metacity doesn't work in my second vm?
<RAOF> I'm surprised compiz works in your *first* VM :)
<ebroder> bdrung: the metacity fallback doesn't seem to be working, but you can run metacity by hand
<ebroder> (compiz crashes before it realizes that it doesn't work)
<bdrung> ebroder: why does the metacity fallback work in the first vm, but not in the second?
<ebroder>  that I can't help you with
<bdrung> second question: what can i do when the mouse cursor stops moving in the VM?
<sebner> RAOF: compiz works on my productive machine without problems (well the upgrade was painful but dpkg --force-all ftw!)
<bdrung> sebner: compiz in natty does not work correctly on my real hardware.
<sebner> bdrung: what's the problem?
<bdrung> sebner: i can't enable extra effects (no wobby windows) and it hang if i want to shutdown the computer
<RAOF> bdrung: That's probably fallout of the lack of settings migration; if you (a) kill your existing compiz settings with gconftool-2 --recursive-unset or (b) switch to the ini backend in ~/.config/compiz-1/compizconfig/defaults it should work.
<sebner> bdrung: well, I only use some minimal effects so I can't tell but I have the shutdown bug too
<bdrung> RAOF: i'll try that next time i boot into it.
<sebner> simple-compiz-configurator is b0rken btw, seems not to be compatible with compiz 0.9.x
<bdrung> sebner: i'll use the 'visual effects' tab in gnome-appearance-properties
<sebner> bdrung: right, stays at "None" (even though I have effects enabled)
#ubuntu-devel 2010-11-25
<sebner> bdrung: right, stays at "None" (even though I have effects enabled)
<GanonKiller> is combat arms still in development for linux?
<GanonKiller> is combat arms still in development for linux?
<aakshay> hi.. i am making the package using the packaging guide. the rules file is not complete as shown in tutorial..
<aakshay> does anybody know how to adjust rules file in pakaging..
<aakshay> does anybody know how to edit rules file in pakaging.. its not showing makefile in it
<RAOF> What do you mean?
<RAOF> The debian/rules file is a makefile, with various standard targets that the build process calls to make things happen.
<aakshay> raof: the rules file is not showin any rules in it
<aakshay> raof: its been restricted by developer
<aakshay> raof: its showin  < #!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. # This file was originally written by Joey Hess and Craig Small. # As a special exception, when this file is copied by dh-make into a # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make.  # Uncomment this to turn on verbose mode. 
<RAOF> aakshay: You should pastebin the rules file rather than paste it into IRC
<RAOF> (The pastebinit tool is useful here)
<aakshay> i m sorry.. i dont know how. it's my first time here...
<aakshay> raof: can u plz tel where is the pastebin option?
<RAOF> You can install the âpastebinitâ package.  That gets you the pastebinit tool, which you can use like so: âpastebinit debian/rulesâ, and it'll copy the debian/rules file to a pastebin and then return the URL.
<RAOF> You then want to paste the URL in here.
<aakshay> thanx...let me do this... plz wait.
<hallyn> if a bug affects debian as upstream, can i just hit 'also affects' in LP and it'll do the right thing wrt debian bugs, or do i need to separately file a debian bug through email?
<RAOF> You need to separately file a debian bug through email; Launchpad doesn't (yet!) _actually_ forward the bugs upstream.  That's a way to link existing upstream bugs into the Launchpad bug.
<hallyn> RAOF: thanks!
<aakshay> roaf: URL is "http://pastebin.com/SsusCmzz"
<aakshay> roaf: plz suggest something
<RAOF> Right.  As I suspected.
<RAOF> So, that *does* have all the targets of interest.
<aakshay> sorry??
<RAOF> The â%:â target is a catch-all target.
<RAOF> It matches everything.
<aakshay> okiez... it has this
<aakshay> roaf: so wat i can do ?
<RAOF> That's a fairly typical debhelper 7 rules file.
<RAOF> aakshay: Well, what do you want to achieve?
<aakshay> roaf: i am learning packaging
<aakshay> so i came across this file to edit this
<aakshay> roaf: but its not showing the complete rule file.. so i get stucked at this point
<RAOF> That *is* the complete rules file.
<aakshay> roaf: yes..
<aakshay> roaf: please suggest something
<RAOF> I'm not sure what you're trying to do.
<aakshay> roaf: i m doin packaging using deb-helper..... for this we need to edit the control, changelog, rules etc files
<RAOF> That rules file will work for a simple package with no unusual requirements.  Whether you need to modify it, and how you need to modify it, depends on what the software you're trying to package needs.
<aakshay> roaf: i am using deb-helper and packaging the simple hello-2.1.1 soy=urce....m doing this from ubuntu packaging guide..
<aakshay> roaf: *source
<aakshay> roaf: thanx for help...;-)
<RAOF> I'm still not sure what your question is :/
<aakshay> roaf: my question is how can i view my rules file completely.... there is no rules defined in it....;)
<RAOF> You *are* viewing your rules file completely.  That file defines a catch-all rule - â%:â.
<aakshay> roaf: these rules are inbuilt in it.... which are not there in this file...
<aakshay> okiez...
<RAOF> So when debian/rules is called with âdebian/rules buildâ, Make looks for the âbuildâ target, finds that â%:â matches âbuildâ, and executes the commands there (specifically, it runs âdh buildâ, because $@ gets substituted to the target name).
<aakshay> roaf: okiez.. let me try it other way...
<aakshay> roaf: thanx again for your help..;)
<aakshay> roaf: bye...
<RAOF> Good luck!
<wgrant> lamont: The extras.ubuntu.com resigning stuff doesn't seem to be working. It's now signed with the original PPA key, which isn't in the default keyring.
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<TheMuso> lol udevbot
<RAOF> Ok!  Who'd like to burn a few CPU cycles sponsoring a new mesa & Radeon DDX?
<RAOF> For those playing at home, http://cooperteam.net/Packages/mesa_7.9+repack-1ubuntu1.dsc and http://cooperteam.net/Packages/xserver-xorg-video-ati_6.13.2-1ubuntu2.dsc are awaiting someone's pleasure.
<StevenK> RAOF: You mean you aren't a coredev yet?
 * RAOF takes this as more evidence it's time to get his application wiki page in order.
<StevenK> RAOF: When you're done, point me at it and I'll stamp it
<RAOF> Thanks :).
<RAOF> I'm off for some exercise now; I'll be back online later.
<StevenK> RAOF: http://cooperteam.net/Packages/xserver-xorg-video-ati_6.13.2.orig.tar.gz is 404
<RAOF> StevenK: Now it's there.
<StevenK> RAOF: Yah, I just grabbed it, thanks
<StevenK> RAOF: Slow wet string?
<RAOF> No; forgetting to -sa
<StevenK> Ha
<RAOF> Note that there's a semi-dependency on the new mesa in the new xserver-xorg-video-ati
<StevenK> RAOF: So mesa should be uploaded and built first?
<RAOF> A new option in the new ati won't work until the new mesa is installed.
<RAOF> Peoples systems won't break unless they add an xorg.conf option before installing the new mesa; I don't think the ordering is particularly important.
<RAOF> Specifically, the ForceGallium option won't work until you've installed the new mesa, which builds the gallium driver.  It's only interesting if you want to test that.
<RAOF> Now, really going off to exercise :)
<kees> cjwatson: cpu-checker can be demoted to universe (I removed it from update-manager-common)
<ebroder> Does...anybody know why apt-get update in my natty schroot would be giving "Undetermined Error" when trying to download the natty-updates Packages and Sources files from my approx server?
<pitti> Good morning
<dholbach> good morning!
<ebroder> In the interests of whittling down the sponsoring queue, anybody want to mark https://code.launchpad.net/~hrw/ubuntu/natty/byobu/fix-cpu-freq-on-smp-arm/+merge/41427 as merged as of r89?
<dholbach> ebroder, done
<ebroder> Thanks
<dholbach> de nada
<ebroder> Looks like https://code.launchpad.net/~smoser/ubuntu/natty/euca2ools/euca2ools-1.3.1/+merge/41105 was merged as of r25
<didrocks> good morning
<dholbach> ebroder, done
<dholbach> RAOF, I had a chat with amaranth about bug 395692 yesterday - he said that it's unmaintained upstream
<ubottu> Launchpad bug 395692 in alacarte (Ubuntu) "Drag-and-Drop behavior in the menu editor is inconsistent and confusing" [Low,Triaged] https://launchpad.net/bugs/395692
<dholbach> it's probably safe to just upload it
<ebroder> dholbach: https://code.launchpad.net/~smoser/ubuntu/lucid/mountall/bug649591/+merge/37105, merged as of r337 :)
<dholbach> server team ^ mark your branches as merged!
<ebroder> dholbach: I'll stop and just harrass SpamapS next time I see him :)
<ebroder> And smoser, I guess
<RAOF> dholbach: Yeah.  I can't upload it, though, so I again call for sponsorship :)
<dholbach> ok, I'll have a look into it in a bit
<RAOF> StevenK: Are you able to upload mesa or -ati, or should I cast around for other sponsors?
<pitti> RAOF: toss me the URL to a source.changes, I'm happy to upload stuff for you
<StevenK> RAOF: I got distracted
<StevenK> RAOF: Sorry
<dpm> good morning cjwatson, great work with the interview on planet ubuntu, it was a very interesting read!
<RAOF> StevenK: No problem.  I'll punt it to pitti, then, since it's late for you.
<pitti> cjwatson: eww, "ps aux|grep cdimage" on antimony looks like there's a lot of stuck build live processes -- do you think we should kill them wholesale?
<geser> somebody else having problems with booting his natty system? grub greeted me today with "grub rescue>" instead the usual menu :(
<pitti> I just dist-upgraded and rebooted, worked fine here
<pitti> geser: did some package (kernel/grub) fail to configure or so?
<ebroder> geser: You probably didn't install the new grub, and the configuration doesn't seem to work with older grub
<geser> not that I noticed on the update yesterday
<geser> ebroder: I remember seeing the usual debconf question on which harddisk to install grub. What need I to do to fix it?
<ebroder> geser: Check the logs from yesterday around, uh...22:46 UTC. Probably the same thing bdrung ran into
<ebroder> geser: If you can manage to boot once, "grub-install /dev/sda" should fix it for now, and "echo SET grub-pc/install_devices /dev/sda | sudo debconf-communicate" should fix it forever (substituting your harddrive of choice for /dev/sda)
<geser> ebroder: -rw-r--r-- 1 root root 104084 2010-11-24 18:22 /boot/grub/lua.mod (if you mean that)
<ebroder> geser: Oh, never mind then
<ebroder> geser: Well, following cjwatson's script from earlier, does "insmod normal" then "normal" get you anything interesting?
<geser> ebroder: here is the output from debconf-show for grub-pc: http://paste.ubuntu.com/536214/
<ebroder> geser: Yeah, this isn't bdrung's problem
<geser> if it's matter I use RAID and LVM (/boot is on RAID1, / on LVM on RAID1)
<ebroder> geser: Unfortunately it's 3:30AM my time, and I meant to go to sleep 2 hours ago. Hopefully cjwatson will be around soon and can undoubtedly be more helpful than me in any case
<geser> I've to leave in a few minutes too (first for work then university) and should be back around 16 UTC
<RAOF> pitti: When you're free, http://cooperteam.net/Packages/mesa_7.9+repack-1ubuntu1_source.changes and http://cooperteam.net/Packages/xserver-xorg-video-ati_6.13.2-1ubuntu2_source.changes
<pitti> RAOF: debdiff looks fine to me; thanks, uploaded
<RAOF> pitti: Thanks muchly.  That should get us a long way towards fitting on a CD.
<pitti> oh, just uplaoded ati; /me looks at mesa
<RAOF> Heh.  -ati's not going to slim the CDs down much :)
<pitti> that's what made me wonder :)
<pitti> oops
<bilalakhtar> It appears there is a large list of NBS packages with no reverse deps. Why isn't someone cleaning them up?
<pitti> RAOF: can you please rebuild the source.changes with -sa?
<pitti> RAOF: my upload will be rejected, as the orig isn't there
<pitti> bilalakhtar: it's mostly the old kernel ABI; cleaning up now
<bilalakhtar> thanks pitti
<RAOF> pitti: Ah, yeah, sorry.
<pitti> RAOF: (if you rebuild, you'll have to reupload .dsc and diff.gz as well)
<StevenK> bilalakhtar: It's a manual process
<bilalakhtar> StevenK: of course it is :)
<StevenK> From my looking, it's just a kernel
<StevenK> You should see the list when it has 3 or 4 kernel versions in it
<pitti> should look much better in the next runm
<RAOF> pitti: There you go, should be good.
<pitti> RAOF: yep, thanks; uploading
<StevenK> pitti: You've already killed -5?
<pitti> StevenK: yep, since d-i was rebuilt against -6
<StevenK> pitti: Okay, then I won't try :-)
<pitti> and the old .35-22 kernels, too, plus three "no rdepends" packages
<pitti> warp10: warp11? physically impossible!
<pitti> warp10: hey Andrea, how are you?
<warp10> pitti: That's transwarp!
<warp10> pitti: pretty fine, thanks, and you? :)
<StevenK> Actually, I didn't think transwrap had numbers, they are just spacetime corridors?
<pitti> warp10: I'm great, thanks!
<bilalakhtar> pitti: Are you still in the OEM team or you're back?
<warp10> StevenK: yeah, think so. Sort of conduits through transwarp space
<warp10> StevenK: at least for Borg transwarp drive, IIRC
<pitti> bilalakhtar: I'm back since last UDS
<bilalakhtar> pitti: oh cool!
<mdz> pitti, hi
<pitti> hey mdz
<mdz> pitti, wondering if the retracer is down; I filed a crash report yesterday which is untraced as yet (bug 680968)
<ubottu> Bug 680968 on http://launchpad.net/bugs/680968 is private
<pitti> mdz: seems the amd64 one is
<seb128> pitti, do we have natty retracers already?
<pitti> seb128: no, we don't
<mdz> seb128, but that was a maverick crash
<mdz> which the U1 team wants to look at
<seb128> mdz, sorry I hijacked your question
<pitti> restarted the amd64 one
<mdz> pitti, thanks
<pitti> mdz: thanks for pointing out; I guess LP rollout
<seb128> mdz, I was just thinking about natty yesterday because of unity testing
<seb128> mdz, I your question made me think about it again ;-)
<cjwatson> kees: cpu-checker> the problem is that qemu-common recommends it
<cjwatson> dpm: thanks :)
<cjwatson> pitti: need to consult with lamont I think, as killing the trigger scripts on antimony won't kill the actual build processes on the livefs buildds
<cjwatson> lamont: ^-
<pitti> ah, right
<pitti> lamont: it seems that there are a lot of stuck livefs build jobs on the buildds right now? at least antimony has a plethora of very old calls there (ssh sessions, right?)
<soren> Argh.
<soren> Just... argh.
<bilalakhtar> soren: why?
<mdz> pitti, thanks for getting the amd64 retracer back up. I can now see that my bug is one of many apparent duplicates with equivalent stack traces
<pitti> :)
<mdz> pitti, I wonder why the retracer did not match them as duplicates in fact
<seb128> mdz, is there any missing symbols in the stacktrace?
<seb128> like ?? lines
<mdz> seb128, hmm, yes
<seb128> that's why
<mdz> there is one missing gobject symbol
<seb128> the autodup works only with exact matches
<seb128> exact and complete functions
<pitti> mdz: there's some difference in the 4th and 5th line of stack trace top
<mdz> pitti, a few, though there are many which have identical stacktracetop
<mdz> seb128, I see, thanks
<mdz> I wonder why it isn't resolving that symbol
<soren> pitti: Is pkgbinarymangler's test suite supposed to work as a regular user (and on systems that already have it installed)?
<pitti> soren: yes
<pitti> it's supposed to take the local binaries
<pitti> and it's all done in a temp directory
<pitti> soren: it runs on the buildds during package build, after all
<soren> pitti: If I run "test/run -v", I get a whole stack of these:     os.symlink('/usr/bin/dpkg-deb.pkgbinarymangler', os.path.join(self.srcdir, 'dpkg-deb.pkgbinarymangler'))
<soren> OSError: [Errno 17] File exists
<soren> pitti: Yes. As root.
<pitti> soren: that's from a failed run, you have to remove this file manually
<pitti> soren: I run it as user here
<soren> pitti: Sorry, which one is "this file"? :)
<pitti> dpkg-deb.pkgbinarymangler
<soren> Oh, that one!
<soren> Yeah, there it goes. Lovely. Thanks.
<pitti> "bzr clean-tree --ignored --unknown" for the win :)
 * pitti has that aliased as "bzcln"
<soren> pitti: Now that I have you attention anyway. I'm stunned that noone has noticed that the dpkg-deb wrapper fails if the path has a space in it.
<mdz> the libglib and libgobject symbol info seems to be missing
<pitti> soren: it happens seldomly enough
<seb128> mdz, could be that the ddeb retrievers bugged and that there is no dbgsym for glib on that arch for that version
<ari-tczew> archive admins: why squid3 is on blacklist? there is a new debian revision merge. is it possible to do?
<soren> pitti: Err.. Except when you click on a deb on a web site and it attempts to get installed through software center.
<pitti> soren: I try to quote my variables, but well, it's shell..
<soren> pitti: I have a patch, just need a test case.
<pitti> soren: what's that to do with the mangler?
<soren> pitti: If someone has pkgbinarymangler installed, and their locale's "Downloads" has a space in it (in Danish it's "Hentede Filer
<soren> "), you can't install deb's from firefox.
 * cjwatson is currently running http://paste.ubuntu.com/536260/ - approach may be of interest to others with large queues of apport-generated bugs
<seb128> mdz, doesn't seems to be the case, http://ddebs.ubuntu.com/pool/main/g/glib2.0/
<seb128> not sure why then...
<cjwatson> (sort of like a special-purpose version of bughelper optimised for very quickly scanning and duplicating lots of bugs onto a known base)
<pitti> soren: I'm still puzzled, but perhaps it'll clear up in your MP
<soren> pitti: I'm not sure what is unclear.
<soren> ?
<soren> pitti: ...and if I don't know, I can't clarify it in my mp :)
<cjwatson> ari-tczew: squid3 # overrides squid-cgi; needs manual resolution
<pitti> soren: where does the mangler come into play when you install .debs from firefox?
<ari-tczew> cjwatson: I see this one. so, merge-able
<ari-tczew> ?
<cjwatson> may not be true any more
<soren> pitti: It wraps dpkg-deb
<soren> pitti: dpkg -i -> dpkg-deb -x -> fail
 * cjwatson checks the bzr history
<pitti> aah
<ari-tczew> cjwatson: is it possible to check who did this change?
<pitti> soren: right, now I understand; sorry :)
<cjwatson> log message was "initial sync blacklisting for maverick"
<cjwatson> it was probably me
<cjwatson> I can't check for sure due to the way the archive admin shell access setup works
<cjwatson> but I don't think it matters
<ari-tczew> cjwatson: I dunno why this one didn't handle by MoM?
<cjwatson> ari-tczew: because it ignores everything on the sync-blacklist
<cjwatson> ari-tczew: I've unblacklisted it
<ari-tczew> cjwatson: thanks!
<ari-tczew> cjwatson: another issue with MoM: do you think that adding blank line at the end of debian/changelog is an issue?
<cjwatson> yes, though a minor one
<ari-tczew> cjwatson: ok, I'll report a bug
<seb128> mdz, pitti: ok, I figured why the glib symbols are missing
<mdz> seb128, oh! what is it?
<seb128> mdz, pitti: the retracers doesn't have a maverick-updates ddeb source
<pitti> oh, crud
<seb128> I'm fixing it
<pitti> seb128: merci
<seb128> they still have lucid-proposed and lucid-updates
<seb128> pitti, yw
<pitti> seb128: that was because we often copy SRUs from lucid-proposed to maverick (same for natty)
<pitti> but that doesn't reflect on the ddebs archive
<pitti> seb128: so please leave those in
<pitti> (proper soyuz support for ddebs FTW..)
<seb128> ok
<seb128> I will just add the maverick ones
<mdz> seb128, nice work
<seb128> thanks ;-)
<ari-tczew> pitti: could you accept packages in karmic-proposed? ;-)
<bilalakhtar> ari-tczew: <pitti> Pinging an ~ubuntu-sru member to accept packages won't help, sorry
<bilalakhtar> that's what he said to me a few months ago
<ari-tczew> bilalakhtar: odd.
<bilalakhtar> ari-tczew: try the poke, since karmic-proposed is a somewhat staler section of SRUing ATM
<ari-tczew> bilalakhtar: SRU work should be welcome. Answer which you showed me is pretty ignorant.
<bilalakhtar> ari-tczew: my answer was for an SRU into lucid-{proposed,updates} at a time when maverick was devel release
<soren> pitti: Can you review lp:~soren/pkgbinarymangler/no-mangle-args please?
<bilalakhtar> your case is different
<bilalakhtar> soren, ari-tczew: pitti seems /away for lunch
<soren> bilalakhtar: I can wait :)
<ari-tczew> bilalakhtar: I say that pitti's answer seems to ignorant, not yours.
<bilalakhtar> ari-tczew: in that line, s/my/pitti's/
<mr_pouit> and why would it be "ignorant"?
<ari-tczew> this answer is like 'I don't care, not my problem, still wait'
<mr_pouit> or maybe "~ubuntu-sru members aren't archive admins, only archive admins can accept packages, so you have to wait for the next archive admin day"?
<mr_pouit> but it's better to jump to conclusion as you did, and treat people as ignorant :]
<ari-tczew> mr_pouit: I'm pinging pitti as archive admin, not as sru team member.
<ari-tczew> and I'm not here to guessing about other people sentences
<ari-tczew> answer is answer
<seb128> the point is that people do work on those tasks when they have time
<seb128> doing IRC ping is usually of no use, it just create stress and discussions
<seb128> if you wait a bit SRU will be reviewed in the regular way
<ari-tczew> cjwatson: could you also take a look on package 'fai' on blacklist?
<ari-tczew> it seems to be outdated
<ari-tczew> \sh: has uploaded changes this year
<cr3> hi folks, anyone happen to know if there's a way to enable a wireless card, bcm4322 in this case, where rfkill unblock still doesn't seem to unblock the interface?
<\sh> ari-tczew: stop spreading fud pls...fai is already updated on maverick
<\sh> ari-tczew: and it's a native ubuntu package, because we really can't sync from debian at this stage
<ari-tczew> \what do you want from me? version looks like merged with debian. if version is -0ubuntu1 then it suggests to be ubuntu packaging
<ari-tczew> \sh:  ^
<\sh> ari-tczew: https://launchpad.net/ubuntu/+source/fai/3.4.3ubuntu1 <- this is an ubuntu native package
<azeem> how would a debian-native-with-ubuntu-changes version look like?
<\sh> azeem: the same like an ubuntu native
<azeem> ok
<ari-tczew> lol
<azeem> so in essence, it wasn't really possible for ari-tczew to tell
<\sh> azeem: you can see it on ubuntu1 ?
<\sh> if it's a package with -0ubuntu1 (which is actually not a native package) but a package with originates in ubuntu
<azeem> whatever
<azeem> I still think it wasn't obvious that 3.4.3ubuntu1 is a ubuntu native package and doesn't need a merge to 3.4.4
<\sh> if it's a package with something behind the version+<somthing like an ubuntu string> it's normally a native with ubuntu changes
<mdz> dholbach, where do the minutes from CC meetings get posted?
<cjwatson> ari-tczew,\sh: it was sync-blacklisted because it had been removed, so it makes sense to unblacklist it now (the Ubuntu version number will still stop it being autosynced, but now it will at least show up on MoM)
<cjwatson> ari-tczew: ideally, just file bug reports about these things and subscribe ubuntu-archive, so that the archive admin of the day can take care of them
<ari-tczew> cjwatson: ATM \sh blamed me about unblacklist
<cjwatson> well, the reason for the blacklist entry no longer applies so I've removed it
<ari-tczew> aha
<\sh> cjwatson: oh well...
<cjwatson> \sh: I think you may misunderstand what the sync-blacklist does
<ari-tczew> maybe archive admins should review all list to get update information
<pitti> ari-tczew: I can, yes
<cjwatson> \sh: packages that simply have Ubuntu changes don't belong there - there are other, better, ways to stop them being synced
<\sh> cjwatson: no..there was a reason...I think the sync blacklist entry was already there before it was even removed...I can't remember anymore..but in the past there was this ubuntu fai team who took care about FAI
<cjwatson> the sync-blacklist is for (a) packages that break the autosync process for one reason or another, usually binary package name clashes with another source package but occasionally something else (b) packages that have been deliberately removed from Ubuntu but are still in Debian (c) packages that are divergent in Ubuntu but don't use the *ubuntu* versioning scheme
<cjwatson> \sh: the blacklist entry said you are mistaken
<cjwatson> fai # stevenk, blacklisting due to removal, see bug 419099
<ubottu> Launchpad bug 419099 in fai (Ubuntu) "Please remove fai source package and all resulting binary packages from karmic" [High,Fix released] https://launchpad.net/bugs/419099
<cjwatson> \sh: when it was simply modified in Ubuntu, it did not require a sync-blacklist entry
<cjwatson> \sh: this is a non-issue, really
<pitti> soren: looking
<\sh> cjwatson: ok..as said, I thought there was already such an entry before the removal...what could we do to only have a special group of people taking care of this package?
<cjwatson> \sh: you already have that
<cjwatson> \sh: you don't need a sync-blacklist entry for that.  it's a great big hammer for special purposes that have nothing to do with what you're asking.
<cjwatson> \sh: of course, that special group of people must include MOTU; Ubuntu development is cooperative and they have upload access.  But I'm sure that they generally won't walk over your changes if the package is generally being well-maintained.
<cjwatson> if somebody's clearly actively taking care of a package then that's generally sufficient for MOTU to leave them to it
<\sh> cjwatson: so best practice as always...
<pitti> soren: nice one, thanks! merged, uploading now
<soren> pitti: np
<pitti> soren: hm, seems that lool beat me to it
<soren> pitti: Ah. Yeah, I wanted to make you the reviewer, but launchpad beat me to it and sent it to everyone.
<pitti> lool: are you going to upload mangler, or want me to?
<pitti> lofidellity: uploading now
<pitti> sorry lofidellity
<pitti> lool: mangler uploaded, FYI
<lool> pitti: I was takingit, yes
<lool> pitti: I assigned it to me and pushed the changes
<freeflying> pitti, how can I make changes to language-support-input-zh-hans?
<lool> pitti: I did additional tweals
<lool> tweaks
<pitti> lool: merci
<pitti> freeflying: in lp:langpack-o-matic, support-depends/*
<pitti> freeflying: you can tell me what needs to be changed, or do a branch
<pitti> freeflying: then I'll need to rebuild the package (that happens mostly automatically)
<freeflying> pitti, I will make a branch, and send you for review
<pitti> freeflying: thank you!
<freeflying> pitti, or which way you prefer?
<pitti> freeflying: branch sounds great
<freeflying> pitti, ok
<pitti> tseliot: FYI, I'm going to convert bcmwl to the new dh_modaliases in lp:ubuntu/bcmwl, so that I have a real-world test case for jockey development
<lamont> pitti / cjwatson: still wondering about those livecdfsbuilds?
<tseliot> pitti: great! I look forward to seeing the result of your work :)
<pitti> lamont: cdimage@antimony:~$ ps ux|grep buildlive|wc -l
<pitti> 56
<pitti> lamont: so, yes
<pitti> tseliot: dh_modaliases exists now, test case, too; now I need to add the jockey support for it
<pitti> tseliot: (exists in my local branch, not uploaded yet)
<freeflying> pitti, I plan to make language-support-input-zh-hans depends on ibus | fcitx, does the scripts support it?
<pitti> freeflying: yes, the dependencies are just copied verbatim
<tseliot> pitti: good. I'll do my part in nvidia-*, fglrx and in nvidia-common (the python library) when dh_modaliases is uploaded
<freeflying> pitti, and there is no natty available under support-depends, so I'd make changes in maverick? thanks
<pitti> freeflying: actually no, we need to copy maverick/ to natty/ first and then change stuff there
<pitti> freeflying: it's the first support-depends change in natty
<freeflying> pitti, I see
<cjwatson> pitti: is that something that somebody needs a reminder of as part of NewReleaseCycleProcess?
<lamont> pitti: you just want me to kill the amd64/i386 livefs builds with fire?
<freeflying> pitti, so are you going to copy it first, and then I make my branch? or vice versa?
<pitti> cjwatson: we could add it there, but since these never get uploaded automatically, it could just happen when first needed
<cjwatson> hm, ok
<pitti> freeflying: I can do that now and push if you want to
<pitti> freeflying: (before you branch)
<pitti> cp -r support-depends/{maverick,natty}; bzr add support-depends/natty; bzr commit
<pitti> something like that
<freeflying> pitti, thanks, then I will branch it after your push :)
<Rovanion> When running autogen.sh to build Docky from source I get the error that I'm missing the package: 'gnome-keyring-sharp-1.0'. There seems to be no such package in the Ubuntu repositories or Docky PPA. What can I do?
<pitti> freeflying: done
<pitti> lamont: I guess we can just eradicate them all and start over at that point; not much value at trying to rescue the two "good" ones (if there are any)
<Laney> Rovanion: This isn't the channel for such questions, but that is an error for pkg-config. The file you're looking for is called gnome-keyring-sharp-1.0.pc. It's in libgnome-keyring1.0-cil-dev.
<Laney> (in general, try apt-get build-dep packagename)
<lamont> amd64 had nothing queued, i386 had a plethora
<Rovanion> Laney, apt-get build dep has been failing because, according to #ubuntu, some amd64 repository is down
<lamont> i386 is clean and waiting for you
<pitti> lamont: cheers; buildlive processes are down to 8 now (from 56)
<ml> hello. im looking for an ubuntu dev to help resolve a package issue regarding main inclusion
<pitti> lamont: for xubuntu, kubuntu, mythbuntu, and ubuntu DVD
<lamont> cool.   back to my day off then
<pitti> lamont: oh, enjoy Thanksgiving!
<Rovanion> Laney, I seem to have cleared my xchat log with a keybinding. What were you saying that I should do? And forgive me for using the wrong channel. I thought this was where I should turn to get help when developing in an Ubuntu environment
<pitti> lamont: will the remaining 8 just time out by themselves?
<lamont> which architecture are they?
<pitti> hm, how do I tell?
<lamont> hrm... /me goes and looks
<pitti> ssh -t -o StrictHostKeyChecking no -o BatchMode yes buildd@royal.buildd /home/buildd/bin/BuildLiveCD -s ps3 -d natty xubuntu
<cjwatson> look for the ssh processes and look up the hostnames in cdimage/bin/buildlive
<pitti> lamont: oh, royal -- is that ppc?
<lamont> ppc
<pitti> cjwatson: right, figured a second after I asked, sorry
<cjwatson> powerpc+ps3 runs sequentially after powerpc
<lamont> more to the point, what machines are they.
<cjwatson> so that would be the natural result of killing a powerpc livefs build
<pitti> lamont: I see exactly one ssh process to royal
<lamont> I only killed the ones on cardamom
<lamont> from 10:06 london time today
<lamont> want it dead, or let it run?
<Riddell> ml: what's up?
<pitti> lamont: I guess kill them all for now
<pitti> lamont: I have a hunch that they took ages because of the apt compressed indexes thing
<pitti> that hit UEC builds as well
<pitti> I uploaded a new apt this morning which reverts that
<pitti> so they will hopefully work now
<ml> Riddell, i need to get help to resolve lp bug #311029 if possible. to resolve it we need to move libssh2-dev to main. current situation is that curl is configured without ssh support because libssh2-dev is in universe
<ubottu> Launchpad bug 311029 in curl (Ubuntu) "curl and pycurl is not compiled with sftp support" [Low,Triaged] https://launchpad.net/bugs/311029
<lamont> I see no ssh-invoking-BuildLiveCD processes on antimony
<lamont> s/no/no more/
<ml> Riddell, decision to disable ssh in curl was made in lp bug #175891
<ubottu> Launchpad bug 175891 in curl (Ubuntu) "[hardy] Drop libssh2-1-dev from Build-Depends" [Undecided,Fix released] https://launchpad.net/bugs/175891
<pitti> lamont: I killed the cron.daily-live processes around it now, so that they stop running into each other
<apw> is anyone running near alpha-1 natty with the traditional UI ?
<pitti> lamont: as I said, there was just one:
<apw> i don't seem to have any window decorations
<lamont> cool. victory and turkey are mine
<pitti> cdimage  22326  0.0  0.0  46384  3392 ?        S    10:26   0:00 ssh -t -o StrictHostKeyChecking no -o BatchMode yes buildd@royal.buildd /home/buildd/bin/BuildLiveCD -s ps3 -d natty xubuntu
<pitti> lamont: thanks a bunch!
 * apw notes that in english 'thanks a bunch' is generally carries negative connotations
<pitti> apw: thanks for pointing out
<pitti> lamont: so, "thank you very much" :) (and enjoy the turkey)
<apw> 'thanks a lot!' is more happy sounding
<diwic> pitti, setting "APPORT_SYMPTOMS_DIR=. ubuntu-bug audio" does not seem to work, it still looks for it in /usr/share/apport/symptoms
<lamont> apw: depends on the tone.
<Riddell> ml: we generally don't want two libraries in main doing the same thing, and libssh is already in main, so a start would be to check if curl can be made to use libssh instead of libssh2 or if whatever uses libssh can be made to use libssh2
<pitti> diwic: hmm:
<pitti> symptom_script_dir = os.environ.get('APPORT_SYMPTOMS_DIR',
<pitti>                                     '/usr/share/apport/symptoms')
<diwic> pitti, what file is that in?
<pitti> diwic: does it work with `pwd`? there might be a chdir issue here
<lamont> apw: interesting, both 'thanks a lot' and 'thanks a bunch' (and 'thank you very much') can go either way easily
<pitti> diwic: /usr/share/pyshared/apport/ui.py
<apw> lamont, yeah though i tend to assume bunch is bad and lot is good when in a tonless environ such as here
<ml> Riddell, okay hm. i read some about that and it seems to me that libssh2 is superior (support multithreading, active developed and so on) but i understand the reasoning. heres what i refer to http://www.libssh2.org/libssh2-vs-libssh.html
<lamont> I'll remember that.:-p
<apw> :)
<diwic> pitti, aha, I'm running a too old version of apport, I guess
<pitti> diwic: ah, sorry; it's just in natty
<lamont> I mostly go with my knowledge of the speaker, and assume they're thanking me if I don't know them.  That has the bonus value of annoying the sarcastic unknown twits
<Riddell> ml: but otherwise you want to follow https://wiki.kubuntu.org/MainInclusionProcess to get libssh2 into main
<diwic> pitti, as a workaround, can I copy ui.py to ".", hack it, and have PYTHON_PATH set to ".", would it pick up the right ui.py then?
<ml> Riddell, also cant find any evidence that curl would compile with libssh, only libssh2 is mentioned in the manual
<pitti> diwic: yes, except that it's PYTHONPATH :)
<pitti> diwic: or install python-apport from natty
<Riddell> ml: so needs checking if kdebase-runtime and remmina can compile with libssh2
<ml> Riddell, (i dont even use the kde kubuntu) ;-)
<dholbach> mdz, we haven't had anything on our agenda for quite a while, but also only managed to meet very irregularly - whenever we did we put minutes into the team reports
<mdz> dholbach, so they only go into the team reports, not also emailed to a list or something?
<dholbach> mdz, which list do you think would make sense?
<diwic> pitti, I noticed that more than 10 options does not work well with apport-cli, is that fixed in natty as well?
<pitti> diwic: that's news to me
<pitti> I don't think I ever specified more than 3
<Riddell> ml: that's irrelevant, if you're doing packaging in ubuntu you work everywhere you need to
<mdz> dholbach, I'm not sure. The TB usually sends them to ubuntu-devel-announce
<dholbach> yes, because it's "technical news"
<mdz> dholbach, what's the equivalent for non-technical news?
<dholbach> I feel it'd drown in noise in ubuntu-users@ and other places
<dholbach> ubuntu-news? :)
<diwic> pitti, ok, anyway, it shows up as "10" and when you want to select that, pressing the "1" in "10" makes it take the 1 item instead
<ml> Riddell, okay :) i checked that libssh2 dont have any dependencies outside main
<dholbach> but I don't think that's a mailing list any more
<dholbach> like a public one
<pitti> tseliot: hmm - bcmwl has debian/patches/*, but the debian/rules never actually applied them
<tseliot> pitti: right, because dkms does
<pitti> tseliot: ah, right
<pitti> tseliot: i. e. we need to ship them, not apply them inline?
<tseliot> pitti: yep
<pitti> thanks
<tseliot> np
<pitti> tseliot: so, no "3.0 (quilt)" for now :)
<tseliot> pitti: no, not yet ;)
<ml> Riddell, i created MIR request in lp bug #681423  does it look ok?
<ubottu> Launchpad bug 681423 in libssh2 (Ubuntu) "[MIR] libssh2" [Undecided,New] https://launchpad.net/bugs/681423
<Riddell> ml: " it replaces libssh" have you checked if it can do that?
<Riddell> ml: this will be a security concious package, have you checked its security history?
<pitti> tseliot: actually, would it be that bad to apply the patches at source package build time already?
<pitti> tseliot: it'd remove the requirement for "patch" at runtime
<pitti> tseliot: but it might be a license problem?
<tseliot> pitti: yes, unfortunately, since we have to apply different patches for different kernel versions
<pitti> ok
<ml> Riddell, hm your right. can i reword it into "it can be made to replace libssh, already in main" ?
<Riddell> ml: well do you know that it can?
<ml> Riddell, well yes. but it would require rewriting some parts of applications currently using libssh.. so its not a trivial undertaking. the libssh2 does not seem to offer a libssh wrapper api
<geser> cjwatson: how can I debug the cause for my grub boot issue in natty? I get only an error about a not found UUID and a grub_rescue prompt (I try booting from a RAID)
<Riddell> ml: right, so for the mean time it would need to duplicate what libssh does, that should go in the MIR
<pitti> tseliot, superm1: FYI, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/bcmwl/natty/revision/21 are the packaging changes to use dh_modaliases, and http://paste.ubuntu.com/536335/ is the result
 * tseliot has a look
<pitti> tseliot, superm1: oh, adding a Conflicts:/Replaces: to the old modalias package now, to clean up on upgrade
<cjwatson> geser: what happens when you 'insmod normal'?
<cjwatson> geser: and were there any errors on upgrade?
<tseliot> pitti: it sounds good to me
<geser> cjwatson: I don't remember seeing any errors on upgrade
<ml> Riddell, ok thanks ill rewrite that.. also looking for past security issues
<pitti> tseliot: it just occurred to me that this has a nice side effect: we don't explicitly need to test for apt package sources in jockey any more, since the package headers just won't be available when the driver packages aren't
<tseliot> pitti: do you mean to say that jockey currently checks the availability of universe and multiverse?
<pitti> tseliot: right after a fresh installation you won't have any apt packge lists, you need to run apt-get update first
<geser> cjwatson: "error: unknown filesystem" when I try "insmod normal"
<pitti> tseliot: before jockey actually checked that, you would get the drivers displayed, but they wouldn't install, because the package wasn't available in apt yet
<pitti> tseliot: now, as soon as you enable multiverse, or any other repo with extra drivers, they will just be picked up by jockey at the right time
<tseliot> pitti: aah, I see what you mean now. It should happen the same in case of PPAs. This is definitely a welcome feature :)
<apw> pitti, i assume you get informed of merge-requests for udev automaticially ?
<cjwatson> geser: how about 'ls', and could you also give me the module names listed by 'lsmod'?
<pitti> apw: I'm not sure; did you just send one?
 * pitti syncs mail
<apw> https://code.launchpad.net/~apw/udev/volume-key-updates/+merge/41870
<pitti> apw: yep, got it
<apw> pitti, cool, wondered how automated it really was
<pitti> apw: note that I won't directly merge this, I'll apply the changes upstream and then get it from there
<apw> pitti, ahh should i be doing something different to get these to your attention thats easier to handle?
<pitti> apw: it's automatic and easy "enough" for me, but if you prefer, you can send format-patch files against upstream git
<pitti> apw: (with those it'll be super-easy for me to push them upsream)
<pitti> apw: git://git.kernel.org/pub/scm/linux/hotplug/udev.git
<geser> cjwatson: ls => (hd0) (hd1) ; lsmod => Unknown command 'lsmod'
<apw> pitti, will do
<pitti> apw: (but don't worry too much about this one; I'll just get the diff from the MP)
<ari-tczew> what do you think, makes sense rebuild libproxy in karmic? bug 456907
<ubottu> Launchpad bug 456907 in libproxy (Ubuntu) "need rebuild against latest webkit" [Undecided,New] https://launchpad.net/bugs/456907
<cjwatson> geser: blast, no lsmod.  I suspect the appropriate raid modules weren't built-in.  can you get in with a live CD?
<apw> pitti, well if you are going to do so feel free to take a 'Signed-off-by: Andy Whitcroft <apw@canonical.com' for them
<pitti> apw: I was going to set you as the author, and me as sign-off
<pitti> credit where credit is due :)
<geser> cjwatson: sure, luckily I have an USB stick with grub lying around from which I can boot
<apw> for the kernel the author is also mean to sign them off, so if you need them
<apw> sign them off as well, and everyone in the chain as it were
<pitti> apw: ah; udev is small, we don't care much about that really
<apw> pitti, whatever works :)
<ebroder> apw: I'm having problems with window decorations in my natty VMs (and NVIDIA machines). It looks like compiz is erroring out (possibly segfaulting?) instead of falling back to metacity when you don't have OpenGL support
<apw> ebroder, that might explain my mess
<ebroder> apw: My panel still worked, so I was able to open a terminal and run metacity by hand
<cjwatson> geser: once you've chrooted in and bind-mounted /dev /proc /sys, I need the output from 'sudo grub-install --debug <whatever your usual grub-install devices are, probably /dev/sda and /dev/sdb?>'
<apw> ebroder, for me the appearance settings have been turned to 'None', so far turning them back has worked ...
<ebroder> apw: Huh, if you can get compiz to run at all, sounds like you have a different issue
<apw> ebroder, i think it just died
<ml> Riddell, i updated description for #681423
<Riddell> ml: groovy, now you just wait for a main inclusion person to get round to doing the review
<Riddell> ml: you should probably comment on the original bug pointing at the MIR bug
<ml> Riddell, thanks alot for your help! i did point out the MIR bug :)
<ml> Riddell, somewhat offtopic, digging around i found somewhat discouraging traces from libssh developer regarding not wanting to merge the libs into a single effort: http://daniel.haxx.se/blog/2010/03/04/two-competitors-or-one-united/
<Riddell> tsk
<ml> riddell, and it seems libssh2 is from one of the curl devs, probably why they didnt try to support libssh
<geser> cjwatson: http://bienia.de/tmp/grub_sda.log and http://bienia.de/tmp/grub_sdb.log
<cjwatson> /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=abstraction --device /dev/md0
<cjwatson> devabstraction_module=
<cjwatson> hmm with a capital hmm
<cjwatson> geser: I think  sudo grub-probe -vv --device-map=/boot/grub/device.map --target=abstraction --device /dev/md0  should be the next step
<dmart> kees: hi, do you have a moment?
<geser> cjwatson: http://bienia.de/tmp/grub-probe.log and http://bienia.de/tmp/device.map if you need the device.map too
<cjwatson> geser: yes, indeed I was going to ask for that.  I think the problem is that you have your md devices listed in device.map
<cjwatson> when you list a device in device.map, grub treats them as if they were BIOS-accessible
<geser> so edit the device.map and leave only the harddisk in and rerun grub-install?
<cjwatson> this policy was less clear in the past and maybe you added them to work around some other bug, or you might just have suffered from this changelog entry:
<cjwatson>     - Don't include MD devices when generating device.map (if you're using
<cjwatson>       RAID and upgraded through 1.98+20100702-1 or 1.98+20100705-1, you may
<cjwatson>       need to fix this up manually).
<cjwatson> (grub2 1.98+20100706-1)
<cjwatson> there was a 1.98+20100705-1ubuntu1 version in maverick with this flaw, unfortunately
<geser> I didn't add them manually
<cjwatson> ok, you were probably unlucky enough to have upgraded through that version then
<cjwatson> maybe I should try to clean it up automatically, I was just scared of breaking some working setup
<cjwatson> it might have to be a debconf question :-/
<geser> cjwatson: http://paste.ubuntu.com/536354/ after I deleted the entries for (hd2) and (hd3)
<ari-tczew> doko: could you take  a look for this bug 681447 ?
<ubottu> Launchpad bug 681447 in libatomic-ops (Ubuntu) "Merge libatomic-ops 7.2~alpha5+cvs20101124-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/681447
<cjwatson> hmm
<cjwatson> geser: maybe I broke RAID scanning or something.  can you wait while I bring up a test environment?  might take a little while
<geser> sure, no hurry
<cjwatson> thanks
<cjwatson> it's possible, there was a hairy patch merge that could have been relevant
<geser> cjwatson: my setup is: md0 is a RAID1 for /boot and md1 is LVM-on-RAID1 for /, /home, etc.
<geser> I know how I can boot my system from my usb-stick with grub, so this is only a big annoyance currently for me
<cjwatson> I'll try to mimic that as closely as I can
<seb128> mdz, do you still have the .crash for the bug you reported earlier? do you think you could submit it again to see if the retracer works for the glib symbols now?
<mdz> seb128, I do, yes
<mdz> seb128, now?
<seb128> mdz, when you want
<seb128> mdz, the retracer are running with the updated sources
<mdz> seb128, uploading now, it is 60MB so will take a little while
<seb128> ok, thanks
<mdz> seb128, right, that's what I meant. thanks.
<mdz> hmm, actually apport must be reporting the uncompressed size, it's only a 3.6MB file
<mdz> seb128, https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/681460
<seb128> mdz, thanks
<cjwatson> http://status.qa.ubuntu.com/qapkgstatus/grub2 - quite pleased with that for a day's bug work
<ogra_ac> yeah, you mopped up a lot of dirt today
<doko> ari-tczew: why? just merged it
 * ogra_ac is happy to finally have hix bugmail box getting quiet again :P
<pitti> cjwatson: you triaged ~600 bugs?!? wow
<pitti> cjwatson: ah, I guess part of that was your magic script you pointed out earlier?
<cjwatson> pitti: sadly I think you read that wrong :-)
<cjwatson> ah, the colours are misleading
<pitti> cjwatson: triaged went up from ~30 to a little under 600
<cjwatson> the top circle is actually where the New line will drop to when it next draws a line segment
<ogra_ac> should be between 100 and 200 i'd guess by the bugmail i got
<cjwatson> I don't know why the colours don't match
<geser> can a core-dev please give-back libssh on amd64? it failed to upload due to a bug in LP. https://launchpad.net/ubuntu/+source/libssh/0.4.5-2/+build/2012262
<seb128> geser, done
<geser> thanks
<seb128> yw
<siretart> pitti: regarding the new emacs upload: with '23.1+1-4ubuntu7.1' being in lucid-proposed, would '23.1+1-4ubuntu7.1+maverick1' be an acceptable version number for maverick-proposed?
<pitti> siretart: yes, but a simple 7.2 will do as well; or 7.10.10
<siretart> ok. I'd prefer to go with +maverick1, because then we can still use 7.2 for the next lucid SRU.
<ari-tczew> doko: I saw subscribed toolchain hackers, so I'd ask you for review or sponsorship
<doko> ari-tczew: what do you win? the version number?
<ari-tczew> doko: hmm.. more code?
<ari-tczew> maybe merging is something another than we do
<mdz> seb128, hmm, the backtrace in 680968 actually seems worse than the old one
<mdz> seb128, er, I mean bug 681460 is worse than bug 680968
<ubottu> Bug 681460 on http://launchpad.net/bugs/681460 is private
<ubottu> Launchpad bug 680968 in ubuntuone-client (Ubuntu) "nautilus crashed with SIGSEGV in g_str_hash() [ubuntuone_nautilus_observed_file_unref]" [Medium,New] https://launchpad.net/bugs/680968
<mdz> in terms of missing symbols
<seb128> mdz, yeah, I suck, I just fixed that, I added the ddeb for updates and proposed but the normal proposed source was missing
<seb128> mdz, if you try again that should work now ;-)
<seb128> mdz, I checked with an apt-cache policy in the retracer this time
<mdz> seb128, ok, i'll try again
<seb128> mdz, thanks
<mdz> seb128, https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/681472
<mvo> hey cjwatson - if you have a moment I would like to hear your opinon about bug #670629 - we need to display a eula there and the current pkg just fails if the user refuses. because the package is so popular it will likely cause a lot of failed installs from people runing with noninteractive frontend or just clicking etc. so I was wondering if we should just make it install on refusal but not download the fonts
<ubottu> Launchpad bug 670629 in msttcorefonts (Ubuntu Lucid) "EULA not shown for Microsoft Fonts" [Medium,New] https://launchpad.net/bugs/670629
<mvo> cjwatson: my feeling is that the current approach (exit 1) is (much) more correct
<mvo> but the amount of dupes to expect is also substantial
<seb128> mdz, ok, so it worked this time but you don't get a better stacktrace due to a known retracer "limitation"
<superm1> pitti, very cool. and yeah that's a great side effect
<seb128> mdz, it cleans all the infos on detected duplicates and it figured you opened a duplicate
<mdz> seb128, it was good enough to get it auto-duped, though
<mvo> (others are of course invited to comment on this issue too :)
<seb128> mdz, right
<cjwatson> mvo: your alternative approach sounds OK as long as it's easy to change one's mind (so dpkg-reconfigure should work, apt-get --reinstall install, etc.)
<cjwatson> mvo: in fact you could make it quite smooth if dpkg-reconfigure installed or deleted the fonts depending on your answer :)
<cjwatson> mvo: it's a bit nasty because dependencies on that package would be made into a lie, but that's OK in this case I think because you aren't supposed to Depends: on local fonts anyway
<mvo> cjwatson: thanks, I have similar feelings about it, its not really 100% correct, but will save our users a lot of headache (and the triagers as well)
<mvo> cjwatson: I will make it so that depending on the answer the fonts are either downloaded or removed
<cjwatson> sounds good to me
<mvo> thanks
<Laney> how does debian get away with not having the eula?
<mvo> Laney: I think in the long(er) run they will have to display it as well
<Laney> presumably you'll have to alter the license of the packaging otherwise I could just remove it
<micahg> siretart: .YR.MO.X is more common in Ubuntu, +seriesX is more common in Debian for stable updates
<geser> cjwatson: re my grub problem: I just noticed that disks are now sdb and sdc (as sda was the usb-stick I booted from). I downgraded grub for now so I can (hopefully) boot without the usb-stick again.
<geser> should I repeat the output you requested for sdb and sdc?
<cjwatson> geser: I guess so although I don't think it will matter very much
<cjwatson> geser: check that the boot loader on your USB stick is still what you expect it to be :-)
<geser> the error I got after removing the (md0) and (md1) from the device.map remains
<geser> at least the grub.cfg looks like I remember from the past again after the downgrade, so I hope it will boot
<cr3> hi folks, I have a package that is mostly python but with some C compilation, so architecture: any instead of all, and when I build in the ppa, I get: /bin/sh: python2.7: not found. any ideas what might be wrong?
<geser> cr3: most likely missing python-all-dev in Build-Depends
<cr3> geser: will try, thanks
<Chipaca> hi all. Is anybody here a moderator of ubuntu-devel?
<cjwatson> Chipaca: yes.  I've approved your post
<Chipaca> cjwatson: awesome, thank you
<Chipaca> cjwatson: why do my emails look so vacuous on https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/032169.html, any idea?
<cjwatson> Chipaca: I don't know, sorry.  compare mime structures?
<Chipaca> cjwatson: yeah, got to do that i guess
<Chipaca> that's what i get from using a version 0.5 mua :)
<ajmitch> Chipaca: probably mailman choking a bit when archiving it, it at least looks fine in evolution
 * ajmitch is just trying to find out why surveymonkey.com isn't resolving :)
<ebroder> Hmm...can anybody point me in the right direction for why plymouth wouldn't be setting the color palette or UTF-8 mode correctly on shutdown when it's running in text mode?
<mvo> lool: can you re-push lp:~lool/vmbuilder/fix-run-script-group-perms please? LP/bzr is a bit confused currently, but if you re-push it with a new name it should be fine and then I merge it into vmbuilder
<bdrung> ebroder: can you draft an interface for bug #681242?
<ubottu> Launchpad bug 681242 in ubuntu-dev-tools (Ubuntu) "[sponsor-patch] Support building with sbuild" [Wishlist,Triaged] https://launchpad.net/bugs/681242
<ebroder> bdrung: Sure
<ebroder> bdrung: Do you feel a compelling need for anything more clever than -B/--builder? I'm thinking that maybe the configuration file should be a separate bug (since I can work around that with bashrc aliases)
<bdrung> ebroder: maybe a environment variable instead of config file?
<bdrung> ebroder: we have already SPONSOR_PATCH_WORKDIR
<ebroder> Environment variable works for me
<ebroder> bdrung: Commented
<lamont> kirkland: is this true that I hear you're trying to sneak byobu-by-default into natty?  DO NOT DO THIS
<highvoltage> now onw.
<highvoltage> lamont: you mean more than the byoby-enable message that's currently displayed at login?
<lamont> highvoltage: byobu's belief that admins log into a machine to monitor it is just one of the many issues I have with that can of c*^*()&9
<lamont> and yeah, that
<lamont> s part of it
 * quadrispro doing a bit of sponsoring
<sebner> quadrispro: good to see you, quick question, when I want a dependency on jackd (no b-d, just dependency), which package should I use? jackd, jackd2, ..?
<quadrispro> sebner, jackd. It depends on jackd2 | jackd1
<sebner> quadrispro: take my thanks :)
<quadrispro> you're welcome :)
<paissad> hello all, there are some persons who encounter a problem about the start of an init.d script
<paissad> they say that the script start before the system gets an ip address, here is the related init.d script
<paissad> http://ps3mediaserver.org/forum/viewtopic.php?f=3&t=154&p=39964#p39964
<paissad> i thought that the following was enough, why is it not the case ?
<paissad> # Required-Start:    $local_fs $remote_fs $network
<paissad> and further, is there a workaround ?
<paissad> thanks in advance for helping
<Volvo> So, nmbd wont run on Ubuntu. Are there any plans to fix it so that SAMBA can work ?
<micahg> Volvo: bug 596064
<ubottu> Launchpad bug 596064 in samba (Ubuntu Maverick) "nmbd fails to start on boot - problem with upstart " [Medium,Triaged] https://launchpad.net/bugs/596064
<Volvo> It fails to start, Period. Someone has mispatched it ?
<Volvo> Its been like this for too long. Is anyone going to fix it ?
<Volvo> Works perfectly well if i install the upstream x2 version from source that is, from samba.org
<Volvo> Upstream Debian -> Upstream samba.org == x2. Whats really the problem here ?
<Volvo> seiflotfy: Hows the media TODAY :)
<xnox> Lintian gave me this: warning: collect info objdump-info about package xiphos-dbg failed
<Volvo> I guess that if you really want to scare off people from using Ubuntu for servers this is a way to do it.
<xnox> should I not be building -dbg packages at all? (this is updating to newer upstream using debian packaging)
<Volvo> xnox: YES, because wo those you cant properly debug a package as if at all.
<micahg> Volvo: it's assigned, so it's on someone's list, idk about the priority, maybe #ubuntu-server can help
<xnox> Volvo, Yes as in "do not build -dbg on Ubuntu, rely on -dbgsym. Do build -dbg package on Debian?"
<micahg> xnox: no, you can build it if you want
<Volvo> micahg: Show the bug url for the bug you showed because this has been going on for waaaay too long now. I feel a feud of some sort.
<micahg> xnox: there are toolchain changes in natty
<xnox> micahg, yes toolchain changes. It's just for the first time I see lintian tripping with objdump-info on a -dbg package! BTW xiphos does link agains xulrunner....
<RAOF> Volvo: Whereas I look at that bug and see steady progress towards working out what's wrong.
<micahg> Volvo: huh?, yes, it's marked as affecting releases back to Lucid, you might want to contact zulcss in #ubuntu-server during Canadian business hours
<RAOF> And with patches to test, to boot!
<micahg> xnox: I know :), is it compatible with xul20 yet?
<xnox> Hmmm =) considering I'm upstream, I'm the first one to upgrade to natty (noone is using f15 either) and I have build problems then I don't think it is =)
<Volvo> RAOF: Heheh, whilst id had done it in under 10 hours no matter how bad itd been you mean :) micahg: Thank you very much, ill look into that. Youre very good at what you do and i admire that. Keep up the good work!.
<xnox> micahg, will natty ship xul-1.9.2?
<micahg> xnox: no
<xnox> haha =)
 * xnox xiphos is blocking upgrades on xul20 and gtkhtml......
<bdrung> xnox: it would help to do the gtkhtml first
<micahg> xnox: we  either have to port it or drop it :)
<micahg> xnox: BTW, it's not blocking for xul, just needs to be done by March :)
<xnox> bdrung, working on it =)
<xnox> micahg, either xul20 or webkit =)
<bdrung> micahg: don't drop it! you will generate an angry ubuntu user otherwise, who will blame the mozilla team. :p
 * xnox sorry to all the xul lovers =)
<bdrung> i don't like the xul update policy
<micahg> bdrung: 5k by install on popcon
<micahg> bdrung: no, we'll try to help if xnox doesn't get to it first
<xnox> omg I better hurry =)
<xnox> 5k people but that is excluding those who are running xiphos of ppa or including those?
 * xnox is amazed. Build finished, back to work.
<micahg> xnox: that's only those that have popcon enabled and have ever installed it
<bdrung> xnox: i think it includes ppas
<bdrung> xnox: 5k popcon ~= 25k (assuming 9M user)
<bdrung> xnox: the package with the highest popcon count that i maintain is vlc (778k)
<xnox> 8865  libsword8                      10648   939  9263   443     3 (Unknown) for me =)
<bdrung> micahg: you failed rounding (5955 -> 6k)
<bdrung> oh, we have 12k for gnomesword
<xnox> libgtkhtml-editor-3.14.so.0.0.0 is this correct?
<xnox> it used to be libgtkhtml-editor.so.0
<micahg> xnox: this might be useful: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
<xnox> "bash upstream with libtool manual" yes i do remember reading that..... long time ago.
<xnox> It's just I don't uderstand why they renamed libgkthml-editor now, even though it doesn't build with gtk3 yet =)
<micahg> xnox: I have to give you the link because I still don't know exactly how it works :)
<Volvo> micahg: There seems to be absolutely no interrest in #ubuntu-server to make any kind of server going.
<micahg> Volvo: it's a holiday in the US and evening/night in Europe, so you're not likely to get much of a response right now
<Volvo> micahg: Aha, holiday. Im in Europe myself and im mostly online to do what i like best. Code for OSS and answer users questions.
<Volvo> Maybe theyre microsofters that doesnt like GNU/Linux ... im just guessing of course.
 * micahg has no where to be for the Holiday so just answering queries in IRC :)
<xnox> Is 6k users enough to push updates to backports? =)
<micahg> xnox: sure, as long as there are no crazy rdepends
<Volvo> Thats what good people do.
<xnox> Our ppa is very popular but backports can have a wider audience ;-)
<Volvo> Microsoft people go to conferences (booring ones) sit there and get bum-rot :)
<bdrung> xnox: 1 user would be enough for backports. :)
 * micahg is almost an official backporter
<bdrung> micahg: i am waiting for the backport natty changes for not installing all backports by default
<Volvo> micahg: Be honest, how long have you been packaging for ? / I can help if i wish.
<micahg> Volvo: I've been working with packaging for about a year and a half now
<xnox> micahg your are awesome =)
<Volvo> micahg: Not bad, not bad at all.
<micahg> Volvo: I still have plenty to learn
<Volvo> micahg: And learn you shall.
<bdrung> it's an exponential learning curve :)
<xnox> BTW I have just graduated with Electonics Engineering degree MEng. I'd love get into Open-source / linux / with packaging stuff work. But so far I have found just one graduate entry level job in the uk.
<xnox> I wish there were more jobs in OSS.
<Volvo> micahg: Uni student, private or company etc ?
<micahg> xnox: http://webapps.ubuntu.com/employment/
<bdrung> micahg: wow, that list got quite long
<micahg> Volvo: working for a company
<micahg> bdrung: indeed :)
<Volvo> micahg: If i look at their frontpage or some subpage i dont see "Microsoft gold partner", right ?
<micahg> Volvo: you might...
<micahg> actually noy
<micahg> *not, but I think they are anyways
<micahg> Volvo: my work happens to be with OSS though
<Volvo> Hmmz, doesnt mean youre tainted, but if you want you can priv the name and ill look it up.
 * micahg wonders if this qualifies for OT
<Volvo> Ah! Cool. There are many companies that love OSS
<Volvo> For Oh so many reasons or treasons towards them.
<bdrung> micahg: do you have time for sponsoring?
 * xnox facepalm. I had xiphos in the /usr/local/bin from development........
<micahg> bdrung: maybe, I was going to look at the rhythmbox-radio-browser bug
<bdrung> xnox: why should a ubuntu developer install something in /usr/local? ;)
 * xnox wants bash to print `which $command` if it's not in /usr/bin or /usr
<bdrung> micahg: can you look at bug #678283?
<ubottu> Launchpad bug 678283 in Ubuntu "Sync python-pyproj 1.8.8-1 (universe) from Debian experimental (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/678283
<micahg> bdrung: sure
<bdrung> micahg: thanks
<micahg> bdrung: in a bit though?
<bdrung> micahg: it doesn't hurry
<xnox> bdrung, waf-cache + build + install < 2s. Debuild + dpkg + libeatmydata > 2s
<micahg> bdrung: k, I'll do it after dinner
<bdrung> xnox: either build a package or build it locally (without installing it)
<xnox> right xiphos works fine with new gtkhtml and xul20 =)
<xnox> uploading to ppa for testing =)
<quadrispro> bye all
#ubuntu-devel 2010-11-26
<TheMuso> bdrung: Please include debian changelog entries with merge uploads.
<bdrung> TheMuso: damn, i forgot it again.
<bdrung> TheMuso: i need to make sponsor-patch usable for my own uploads, too. :)
<bdrung> TheMuso: you refer to vlc, right?
<TheMuso> bdrung: yes.
<TheMuso> As long as you are aware of it.
<bdrung> TheMuso: it happens way to often.
<TheMuso> Don't worry, you're not the only one.
<bdrung> TheMuso: now i have to close the bug manually.
<micahg> it seems to be happening quite a bit lately (I've done it a few times as well)
<bdrung> TheMuso: i hope that x264 is accepted soon (the we can sync vlc)
<TheMuso> Yeah.
<TheMuso> micahg: Yeah its easy to miss.
<TheMuso> Thats where MoM has an advantage...
<bdrung> TheMuso: but mom is too slow for my workflow (upload to debian, merge, upload to ubuntu)
<TheMuso> Yeah I understand.
<TheMuso> I am just saying that MoM has a merge-package script which includes the -v flag for you.
<micahg> TheMuso: last one I missed was when I didn't sign the file for testing, then I signed and uploaded, I intended to use -v when I regenerated and signed, but forgot
<TheMuso> heh
<bdrung> debuild should be more intelegent with Xubuntu1 versions
<TheMuso> That could be a solution, yes.
<micahg> bdrung: that's hard as the last upload might have been some random previous debian version, but now a merge is required
<bdrung> micahg: at least a warning would be nice
<micahg> bdrung: yep, that could work
<xnox> bdrung, micahg: from bzr bd --help
<xnox>   --package-merge       Build using the appropriate -v and -sa options for
<xnox>                         merging in the changes from another source.
 * xnox is not sure what that one does =)
<bdrung> xnox: that's nice
<xnox> I have just noticed this on launchpad:"A newer version of yelp is available for packaging: Yelp 2.30.2"
<xnox> Wow =) this is cool =)
<xnox> Where is launchpad *new features* changelog btw? for stuff like that.
<bdrung> xnox: link?
<xnox> https://launchpad.net/ubuntu/+source/yelp
<xnox> it seems that launchpad needs tarballs/milestones in launchpad to do that =)
<bdrung> nice
<bdrung> micahg: are you member of the pkg-mozext team?
<micahg> bdrung: nt yet
<micahg> *not
<bdrung> micahg: it's the place where we should update the extensions
<micahg> bdrung: makes sense, i still need to get comfortable with git though
<bdrung> micahg: that will take as long as it takes to learn packaging ;)
<xnox> bdrung, rubish =) git is easy =) easier than autoconf =))))
<bdrung> xnox: that's not hard (to be easier than autoconf)
<sivang> hi all
<sivang> I wonder if anybody could toss a quick pointer to where this is used in kubuntu? https://code.launchpad.net/~apachelogger/+junk/couchdb-qt
<Riddell> sivang: it's not
<sivang> Riddell: hey :)
<sivang> Riddell: so what was its purpose?
<Riddell> looks like harald was looking at using it with his summer of code ubuntu one kde project
<sivang> Riddell: I want to have a similar qt implementation to what Couchdbkit does, it might be a god start.
<sivang> Riddell: the code does feel as if it was left in the middle
<sivang> Riddell: I see, thanks for the note.
<Riddell> apachelogger is the guy to ask
<Riddell> but he'll be asleep
<sivang> Riddell: okay, I'll email him
<Chipaca> ajmitch: thanks for the info. I'll continue to hug my notmuchmail then :)
<ssj6akshat> How do i translate the debian-installer?
<cjwatson> I answered ssj6akshat in /msg
<hugoshi> this is wierd and quite specific - I've been having trouble with emacs because all the shift arrow keys work inside a terminal except for shift up
<hugoshi> I've fixed it
<hugoshi> by simply recompiling the terminfo for xterm-256color
<hugoshi> I'm not sure how that fixed it, but the recompiled binary is a different size than the original.. which is strange
<twb> On lucid in LSB sysvinit scripts, log_progress_msg is defined with the comment
<twb> # On Ubuntu, one would expect log_progress_msg to be a no-op.
<twb> ...but its definition appears to print things, and I'm no seeing anything being printed.
<twb> Ah, it seems that log_action_end_msg eats it
<twb> I'm still confused as to where the newlines between " * starting foo" and "   ...done." come from.
<ssj6akshat> Is there any ubuntu multitouch devel channel?
<bilalakhtar> ssj6akshat: #ayatana
<bilalakhtar> uTouch is a part of the Ayatana project
<ssj6akshat> bilalakhtar, ah thanks
<bilalakhtar> ssj6akshat: no, wait a minute, I don't think that is
<cjwatson> #ubuntu-touch
<bilalakhtar> ssj6akshat: ^
<cjwatson> https://wiki.ubuntu.com/Multitouch
<ssj6akshat> cjwatson, ah thanks
<ebroder> You know, it's still way too early to be declaring victory, but the length of the sponsorship queue appears to be gaining downwards momentum this week
<twb> Aha, busted. /etc/lsb-base-logging.sh redefines stuff
<twb> (To talk to usplash, which is weird, because plymouth replaced it.)
<twb> WTF
<twb> The GRUB_HIDDEN_TIMEOUT code is handled in /etc/grub.d/30_os-prober -- which exists despite os-prober being purged
<twb> Oops, wrong channel.
<ssj6akshat> no one in #ubuntu-touch seems to be responding
<ebroder> ssj6akshat: It's a holiday in the States and early morning in Europe. Be patient
<ssj6akshat> ebroder, ok
<twb> ebroder: oh, THAT's where everybody is
<pitti> Good morning
<nigelb> Morning pitti
<ssj6akshat> morning pitti
<didrocks> good morning
<dholbach> good morning!
<LetoThe2nd> g'morning! Yesterday I reported a bug via apport, which got marked as duplicate. the message said i shall lookup the original and see if i can provide additional information. i think i can (workaround), but the original bug is marked private. therefore, the mail i received is kind of pointless - i can't access and comment the original bug :-(
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: pitti
<pitti> welcome ladies and gentlemen, I'll be your pilot today
<twb> Hmph
<twb> The 10.04 udev security update assumes udevadm isn't dpkg-diverted by the local sysadmin.
<nigelb> pitti: heh, Martin Airlines ;) ?
 * ebroder is certain there's a good "Airplane" joke buried somewhere in this patch pilot business
<pitti> yes, they are a bit patchy :)
<dholbach> ebroder, I know the guy who draws http://www.chickenwingscomics.com/ - I'm sure you'll find enough ideas for airplane jokes in there :)
<ebroder> dholbach: I was thinking of http://www.imdb.com/title/tt0080339/ . Awesome comedy movie
<dholbach> oh ok - I didn't know it before
<goodwill> could someone with Ubuntu 10.04 tell me if inputlirc run there by default? You can do it by running this in terminal: ps auxw|grep inputlirc
<dholbach> goodwill, not as far as I can see
<goodwill> dholbach: thank you
<twb> goodwill: wouldn't that depend on whether it was installed?
<twb> It's not pulled in by any of the normal metapackages (e.g. ubuntu-desktop, ubuntu-standard).
<LetoThe2nd> (sorry, bump) g'morning! Yesterday I reported a bug via apport, which got marked as duplicate. the message said i shall lookup the original and see if i can provide additional information. i think i can (workaround), but the original bug is marked private. therefore, the mail i received is kind of pointless - i can't access and comment the original bug :-( - so how to make the maintainer aware of the workaround, which might lead to a fix?
<goodwill> twb: I did not think so ... but I had lircd vs. inputlirc issues in 10.10 I am writing about in XBMC which are a bit similar
<goodwill> dholbach: can you do me one additional small favor and tell me if inputlirc is at all available in 10.04. You can use: apt-cache search inputlirc
<ebroder> goodwill: You can find this out yourself by going to http://packages.ubuntu.com/inputlirc or https://launchpad.net/ubuntu/lucid/+package/inputlirc
<goodwill> ebroder: right ... forgot about that
<twb> Or the heavyweight solution: pbuilder create --distribution lucid; pbuilder login; apt-cache policy inputlirc
<ari-tczew> pitti: ready for sponsoring? :)
<pitti> yep, already working on one bug
<ari-tczew> pitti: could you take a look on this branch? https://code.launchpad.net/~om26er/ubuntu/maverick/telepathy-haze/telepathy-haze-fix-652944/+merge/41597
<pitti> ari-tczew: sure
<ari-tczew> pitti: do you will copy this change to natty? ^^
<pitti> ari-tczew: I'll upload it to natty
<ari-tczew> ok
<ari-tczew> dholbach: do you know who deals with hall-of-fame? It seems to be outdated so far
<dholbach> ari-tczew, it's in the process of being rewritten
<ari-tczew> aha ok
<dholbach> the old version is pretty much unmaintained
<dholbach> https://wiki.ubuntu.com/Spec/HallOfFameRewrite if you're interested in helping out
<pitti> ari-tczew: done
<ari-tczew> dholbach: I can't. I'm a n00b in code write.
<dholbach> like in all other things having interest in making it work is the most important thing :)
<pitti> lamont: I sponsored bug 533601 and attached a debdiff suitable for Debian; want me to create a Debian bug for this, or is this sufficient for you?
<ubottu> Launchpad bug 533601 in bind9 (Ubuntu) "Apport hook for bind9" [Wishlist,Fix released] https://launchpad.net/bugs/533601
<ari-tczew> pitti: could you check status of branch?  https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/apache2/maverick-passphrase-plymouth-change/+merge/36610
<pitti> ari-tczew: will put as second into my queue
<pitti> rodrigo asked earlier :)
<ari-tczew> pitti: for my question?
<pitti> for above branch review
<pitti> ari-tczew: seems it's already applied in natty
<pitti> but this is not ever something that I'd put into an SRU
<pitti> plymouth integration for apache on a server?
<pitti> this looks seriously broken
<pitti> wouldn't that stop your boot?
<ogra_ac> would it show your websites on plymouth ? :P
<ari-tczew> pitti: dunno, I'm only reviewing sponsors queue
<pitti> ari-tczew: I commented on the branch and bug
<ari-tczew> pitti: could you take a look on bug 677129 ?
<ubottu> Launchpad bug 677129 in xterm (Ubuntu) "Please merge xterm 266-1 (main) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/677129
<pitti> ari-tczew: yep, will do
<ari-tczew> pitti: thanks for your time and patience due to quantity of my highlights :)
<pitti> ari-tczew: that's my job today :) but I need to balance it with other requests, and also the old stuff which is in the queue, so I can't get to everything immediately
<ari-tczew> pitti: so, do you will review a couple of old bugs also?
<pitti> ari-tczew: I'm starting from oldest first
<ari-tczew> pitti: I'm pleased!
<ari-tczew> pitti: do you mind if me or someone else will take your merges?
<pitti> ari-tczew: how you mean "take my merges"?
<pitti> oh, my merges!
<pitti> ari-tczew: no, not at all
<pitti> ari-tczew: (sorry, I'm looking at merge proposals all the time, got confused :) )
<pitti> ari-tczew: I'd appreciate a quick ping if you do, since I've looked at some which don't make much sense to do
<ari-tczew> pitti: understand ;)
<xnox> how often does: http://reports.qa.ubuntu.com/reports/sponsoring/ update? My merge proposal is not visible yet =)
<xnox> or do I have to have a bug as well?
<pitti> at least every 30 minutes, possibly more often
<xnox> It's up there already =) never mind missed it in the sorting view =)
<xnox> ari-tczew, heya =) it's me with xiphos update branch
<xnox> I'll check the comments now ;-)
<ari-tczew> xnox: HELLO
 * ari-tczew sorry for caps
<xnox> ari-tczew, I'm the maintainer of Xiphos in Debian as well. We would like to push sword-1.6.2 to debian experimental first. and then update xiphos and bibletime against sword 1.6.2 in experimental.
<xnox> It is not a priority to get it into debian experimental since squeeze is frozen =)
<xnox> But bdrung has asked me about xiphos 3.1.4 to make it compatible with xul20 and gtkthml 3.32 so easy the migrations / dist-upgrades in natty asap
<ari-tczew> xnox: ok, would be nice. my proposition is: get these changes to Debian experimental first, then sync into ubuntu natty
<xnox> ok
<xnox> Will seek sponsorship now then.
<pitti> ari-tczew: xterm bug already seems to be in progress, and mvo had some concerns about it
<ari-tczew> ok
<xnox> micahg, with xulrunner-2.0 package there will be no incompatible changes between released 2.0.0 an 2.0.99 to the UPPER/LOWER_RANGES?
<xnox> or they have some new policy for those?
<chrisccoulson> xnox - the policy hasn't changed AFAIK, so there's no guarantee that there will be no breakage
<chrisccoulson> in fact, there's more likely to be breakage now (see https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0)
<chrisccoulson> "No more frozen interfaces"
<xnox> chrisccoulson, now that is just wonderful =) how do I keep up with future xulrunner updates and test xiphos before each new xulrunner revision in e.g. released natty?
<chrisccoulson> xnox, i'm not sure. watching the ubuntu-mozilla-security PPA for updates might be one way
<chrisccoulson> we generally don't test these updates on everything before we publish them (else I'd spend my entire time testing security updates)
<xnox> hm. 1.9.1 -> 1.9.2 transition failed for xiphos. Xiphos build against 1.9.2, users had 1.9.1 and 1.9.2 installed resulting in xiphos crashing.
<xnox> And then later 1.9.2.2 -> 1.9.2.3 updated cause UI bugs in Xiphos.......
<chrisccoulson> xnox, we need to tighten GREVersion to stop that from happening (for the 1.9.1 -> 1.9.2 case)
<xnox> well this is just me rumbuling =)
<xnox> chrisccoulson, I will tigthen GREVersion. But how tight?
<xnox> 2.0.0 - 2.0.99?
<chrisccoulson> for the 1.9.2.2 -> 1.9.2.3 case, i'm not sure what to do about that. in general, interfaces shouldn't break in minor versions, but there is no guarantee there
<xnox> or less than that?
<chrisccoulson> xnox, yeah, basically, i want everything in the archive in natty to only work with 2.0.0
<chrisccoulson> the reason for this is:
<chrisccoulson> sometime in the future, natty will get a new xulrunner version (when 2.0 goes EOL)
<chrisccoulson> we will port some applications to the new version
<chrisccoulson> but others need to carry on working with the current 2.0
<chrisccoulson> one of the difficulties we had when backporting 1.9.2 to our old releases, is that a lot of applications set crazy wide limits for the GREVersion, which meant i had to fix/patch a lot more applications than i wanted to
<xnox> chrisccoulson, ok. so currently I get build-dep on xulrunner-2.0 via shlibdeps so appropriate GREVersion limits are 2.0.0 and 2.0.99? And then hope for the best for no minor breakages in between.
<chrisccoulson> xnox, you'll need to set the lower version to 2.0b to work with the current version
<chrisccoulson> and i set the upper version to 2.0.0.* (gecko usually has a 4 part version number)
<xnox> Currently xiphos is fine from xulrunner 1.9.0 -> 2.0.0 so we should detect which xulrunner we are building against at configure time, and preserve the limits in the binary to ${xul-mayor}.${xul-minor}.0 - 99?
<chrisccoulson> yeah, that would be ok
<xnox> chrisccoulson, 2.0.0 loads fine on my natty for lower bound?
<xnox> with xul-2.0.....
<quadrispro> pitti, ping
<chrisccoulson> xnox, oh, that's good then. that probably means i can change that in gnome-python-extras too
<xnox> Yelp is no-go with xulrunner 2.0 yet?
<quadrispro> pitti, would you mind to review my commit? http://git.debian.org/?p=collab-maint/libmtp.git;a=commitdiff;h=75a69d
<lamont> pitti: looking at the bug
<xnox> chrisccoulson, also for Universe we get stuff from debian which has 1.9.2 in experimental so far.....
 * quadrispro having launch
<chrisccoulson> xnox, yeah, that is a side effect of our different maintenance policy in ubuntu. i don't think there is anything we can do about that
<chrisccoulson> i'm generally taking care of the packages which come from debian to make sure they work with our newer firefox version
<chrisccoulson> xnox, if you feel like helping out at all, i have a list here - https://wiki.ubuntu.com/DesktopTeam/Specs/Natty/Firefox4/XULRunner20Transition :)
<xnox> chrisccoulson, ok thanks =)
<quadrispro> pitti, it needs some work
<chrisccoulson> xnox - you might want to add your name to xiphos if you're working on that :)
<chrisccoulson> so i don't end up duplicating work
<xnox> chrisccoulson, yeap =) sure
<chrisccoulson> thanks
<xnox> chrisccoulson, about the four-part version number. Why the package is called xulrunner-2.0 and not xulrunner-2.0.0? or does it not matter?
<xnox> is the next one going to be xulrunner-2.0.1 or will 2.0.1.0 land inside xulrunner-2.0?
<chrisccoulson> xnox - unless it's changed, the current 2.0 series will all have 2.0.0.* version numbers, and 2.0.1 will be the next "major"-ish version
<chrisccoulson> just like with 1.9
<xnox> ok cool =)
<pitti> quadrispro, lamont: re (back from lunch)
<lamont> wb
<pitti> quadrispro: oh argh, there's a comma missing -- is that upstream as well?
<pitti> ++  char default_udev_action[] = "SYMLINK+=\"libmtp-%k\", MODE=\"666\" ENV{ID_MEDIA_PLAYER}=\"1\"";
<pitti> quadrispro: there needs to be a , between MODE and ENV
<pitti> quadrispro: otherwise it looks fine to me
<quadrispro> pitti, yes, it's upstream
<quadrispro> pitti, pushed. Now I should update udev's rule, but I'm wondering if it's needed to fill ENV{ID_MEDIA_PLAYER}=\"1\"" with the proper media-info device's ID
<pitti> quadrispro: shouldn't; MTP devices can tell by themselves which capabilities they have
<pitti> quadrispro: but I haven't actually tested banshee other music players what they do
<pitti> quadrispro: seems that at least in the current version, rhythmbox doesn't really need the ID_MEDIA_PLAYER flag on MTP devices, it just enumerates /dev/libmtp*
<pitti> so the patch isn't really necessary for rhythmbox
<quadrispro> yes, I see
<quadrispro> would it be sane to upload it now?
<pitti> quadrispro: so, I think you should just test banshee and perhaps amarok whether they care about it, and whether it makes a difference
<quadrispro> (sure, after doing a bunch of tests)
<pitti> quadrispro: I just saw that libmtp's rules come after 40-usb-media-players.rules
<pitti> so these need to make sure not to tag any device which is already an USB storage device
<quadrispro> mmm, so building now, testing later and then let you know
<xnox> chrisccoulson, you are right the min version must be 2.0b or something like that.
<xnox> chrisccoulson, can you add two variables to xulrunner pkg-config? GREVerMin and GREVerMax?
<chrisccoulson> xnox - yeah, i could do. that's a good idea actually
<xnox> with those values that are preferred in Ubuntu when building against that xulrunner e.g. 2.0b and 2.0.0.99 now and other pairs updated later?
<chrisccoulson> yeah, i'll do that
<chrisccoulson> thanks for the suggestion!
<xnox> cause I really don't want to have in my configure script "when it is alpha, when it is beta, when it is released" logic for xulrunner =)))))
<pitti> slangasek: does the plymouth bzr head package work for you? I do get a splash screen, but it looks very ugly (jittery font)
<ari-tczew> how long process backport?
 * ogra_ac glares at his local shadow build 
<ogra_ac> yacc   getdate.y
<ogra_ac> /bin/bash: yacc: Kommando nicht gefunden.
<ogra_ac> why the heck isnt yacc in the build deps if its used by the build
<ogra_ac> is yacc pulled in by anything in debian we dont ?
<pitti> ogra_ac: that doesn't matter, though; if shadow uses yacc by itself, it needs to b-dep on it, regardless of transitive build deps
<pitti> ogra_ac: which is to say, if it doesn't, that's a bug in Debian as well
<ogra_ac> well, i dont think that was added recently
<ogra_ac> and it built before
<ogra_ac> also we have the same deps as debian and it seems to have built there too
<soren> ogra_ac: Build logs for shadow in maverick don't mention yacc.
<soren> ogra_ac: Or bison, for that matter.
<pitti> ogra_ac: does the source already ship the preprocessed yacc output?
<pitti> ogra_ac: might be a race condition when the .y gets patched, and thus gets newer than the output
<ogra_ac> pitti, ah, that might be
<ogra_ac> hmm, though no patch touches getdate
<geser> cjwatson: as bug 681535 is "Fix committed", should I check the patch to confirm that it fixes my grub problem?
<ubottu> Launchpad bug 681535 in grub2 (Ubuntu) "Auto-detection of a filesystem of /dev/md0 failed." [High,Fix committed] https://launchpad.net/bugs/681535
<cjwatson> geser: feel free, or I'll upload it later this afternoon
<cjwatson> I'm pretty sure it does - I mimicked the setup you described and encountered a bug which was at the very least extremely similar
<cjwatson> geser: do keep the md lines out of device.map though
<geser> sure, as you said that the md lines got there by error, I removed them from device.map and kept only those for my harddisks
<cjwatson> *nod*
<geser> I'll check if booting from my usb-stick still works before upgrading grub again :)
<cjwatson> geser: the patch in bzr may not fix it on its own, of course - there was another patch I committed upstream, plus a postinst patch committed to Debian to avoid a spurious question
<cjwatson> geser: I'm merging all of that together for the next upload
<geser> ok, I'll wait on your upload then
<cjwatson> geser: source uploaded now
<ogra_ac> hmpf
<ogra_ac> debian touched the file but doesnt run yacc during build
<ogra_ac> we didnt touch the same file but yacc is executed
 * ogra_ac doesnt get that
<pitti> tseliot: can you handle bug 639976? it's a trivial change, but I can't commit to your git
<ubottu> Launchpad bug 639976 in Package Descriptions for Ubuntu "Typo in package description: NVIDIA 8 should be GeForce 8" [Low,Triaged] https://launchpad.net/bugs/639976
 * tseliot has a look
<ogra_ac> grrr, ok. yacc is not executed on x86
<tseliot> pitti: sure, I'll do it now
<pitti> tseliot: (no upload required for that, just to not forget it); thanks!
<tseliot> pitti: right, I'll just commit it in git, in case I forget
<pitti> dholbach: I like the slope of the first graph at http://reports.qa.ubuntu.com/reports/sponsoring-stats/ since we started this pilot thing ;)
<dholbach> pitti, same here :)
<dholbach> it's awesome
<dholbach> once we're done with that, there's still 2000 bugs with patches in LP :-P
<sladen> pitti: do you have a tag for  installed-footprint  opportunities and  cd-size  opportunities?
<pitti> sladen: I don't; feel free to invent one :)
<geser> cjwatson: thanks, the new grub version installs and boots without problems
<hallyn> all right is there any text-based browserthat works right with lp+openid?
<dholbach> w3m?
<geser> there was one: elinks or links if I remember correctly
<hallyn> lynx gives me an infinite loop,
<hallyn> i thought elinks had failed me, but i'll re-try hat i guess
<hallyn> think i tried w3m in prague, but wth i'll try again
<hallyn> w3m won't show me the 'submit' button at lp login
<hallyn> elinks just clears the form and asks me to fill it back in
<geser> see bug 628755 for the w3m issue which got fixed for natty
<ubottu> Launchpad bug 628755 in Launchpad Foundations "Impossible to log in in Launchpad using apport from a tty console with w3m (dup-of: 523229)" [Low,Triaged] https://launchpad.net/bugs/628755
<ubottu> Launchpad bug 523229 in Canonical SSO provider "The Continue button isn't selectable in w3m for sso login" [High,Won't fix] https://launchpad.net/bugs/523229
<bdrung> wow, the sponsor queue gets smaller!
<ari-tczew> yes, I agreed. today work is very good. thanks for pitti!
<ari-tczew> maybe pitti should be patch pilot more frequently?
<pitti> it wasn't just me :)
<pitti> we have had patch pilots every day now
<hallyn> geser: interesting, thanks.  so if i update that one to natty i could do it :)
<ari-tczew> pitti: but your activities are strong because you have expierence and knowledge with handling SRUs
<geser> hallyn: perhaps; there also some other bugs about cookies, LP and text-browsers: e.g. bug 535456
<ubottu> Launchpad bug 535456 in Launchpad Foundations "Log-in loop when authenticating to Launchpad with Lynx (dup-of: 586908)" [Low,Incomplete] https://launchpad.net/bugs/535456
<ubottu> Launchpad bug 586908 in Launchpad Foundations "OpenID login fails for non-beta LP users using lynx and possibly other browsers" [High,Triaged] https://launchpad.net/bugs/586908
<geser> just try every text-browser out till you find one that works
<hallyn> geser: well i've just tried lynx, elinks, and w3m, so think i'm resorting to install vnc+fvwm+firefox :(
<quadrispro> pitti, 40-usb-media-player.rules and 45-libmtp8.rules share several device IDs
<pitti> quadrispro: some devices offer both access modes
<quadrispro> so this is not a problem, isn't it?
<pitti> quadrispro: well, it means that the ="1" tagged ones will overwrite the ones in media-player-info
<pitti> quadrispro: ideally we could move libmtp rules before m-p-i rules
<pitti> then the hand-maintained mpi ones could fine-tune/override the autogenerated mtp ones as needed
<quadrispro> yep, I've written a small script to calculate differences between the two rules and so, what should we do to re-order them without introducing regressions?
<pitti> quadrispro: well, either move libmtp to 40-* (which would be more adhering to the current convention), or move m-p-i rules to 50-*
<pitti> or rather 46-*
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<pitti> now, 19 sponsoring items less :)
<dholbach> yeeeeeeeeeeeeehaw
 * dholbach hugs pitti
 * pitti hugs dholbach for his perseverance
<ogra_ac> but you could at least properly land the plane before jumping off :P
<ogra_ac> poor passengers
<pitti> dholbach: I have to admit it does work better if you have a schedule and a solid block, instead of this fuzzy "one hour a week"
<quadrispro> pitti, yep, it was clear :) sorry, my wrong question, 2nd attempt: what should we do *before* re-arranging them?
<pitti> ogra_ac: this is Unix. 90% solutions are okay!
<pitti> *cough*
<dholbach> pitti, now we need just more people on the schedule :)
<pitti> quadrispro: if we swap their order, I think the mtp change is just fine
 * quadrispro hugs dholbach 
<ogra_ac> pitti, dholbach, though a proper gmail schedule you can subscribe to for reminders would be a lot better
 * dholbach hugs quadrispro back
<pitti> ogra_ac: I just added my days to my calendar
<dholbach> pitti++ :)
 * ogra_ac isnt sure he will remember in two months when exactly his pilot days are
<ogra_ac> pitti, well, i'd like an automatic reminder
<dholbach> and there's people in the community who don't use gmail
<ari-tczew> dholbach: can we order pitti more frequently as patch pilot?
<ogra_ac> without having to add it every month
<ogra_ac> because i will surely forget to over time
<hallyn> where *is* the schedule again?
<dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Schedule
<pitti> ari-tczew: well, it's not like I've not done sponsoring before; I do that every other day (just not that intense)
<pitti> I think the point of this is to spread it to more people :)
<pitti> ari-tczew: also, it seems that I got signed up for Jan 3 and 10
<hallyn> thanks!
<pitti> dholbach: ^ :)
<ari-tczew> with that strong I believe that we get clean sponsors queue before FeatureFreeze
<pitti> (but that's ok)
<dholbach> pitti, it wasn't me!
<ari-tczew> pitti: I mean not only done clean today by you. I include feedback from our today cooperation.
<dholbach> I suspect a copying mistake, let me fix it
<geser> ogra_ac: I assume those with sponsoring items in the queue will remind you when it's your time to fly :)
<ogra_ac> geser, well
<bdrung> ebroder: around? i need your help for bug #681242.
<ubottu> Launchpad bug 681242 in ubuntu-dev-tools (Ubuntu) "[sponsor-patch] Support building with sbuild" [Wishlist,Triaged] https://launchpad.net/bugs/681242
<bdrung> ebroder: i need a sbuild equivalent for "sudo", "-E", "DIST=" + dist, "pbuilder", "--build", "--distribution", dist, "--buildresult", result_directory, "--architecture", self.architecture, dsc_file
<hyperair> result_directory is pwd, so i reckon you could chdir
<hyperair> otherwise there's sbuild -d $distribution-$architecture $dsc_file
<hyperair> bdrung: ^
<dholbach> holy cow
<dholbach> we're at 14 sponsoring items
<dholbach> erm
<dholbach> 44
<dholbach> 44Â°
<dholbach> 44!
 * dholbach is a happy man
<soren> Wow! 44! That like 2658271574788448768043625811014615890319638528000000000!
<soren> That's just crazy.
<dholbach> we were over 100 consistantly for a long time before :)
<dholbach> ... in case my excitement is not understandable :)
<soren> 44! = 2658271574788448768043625811014615890319638528000000000
<bdrung> hyperair: -d $distribution-$architecture? really?
<ttx> dholbach: would be better if you had 42. Let me see what I can do to fix that.
 * dholbach hugs ttx
<dholbach> :)
 * dholbach hugs soren too
<hyperair> bdrung: yep.
 * soren hugs dholbach back
<ttx> dholbach: my sbuild is a bit stuck in openldap tests for an update that pitti asked for, though :)
<bdrung> soren: 2658271574788448768043625811014615890319638528000000000! != 44!
<hyperair> bdrung: if you omit -$arch, then it defaults to uname -m
<hyperair> er i mean whatever architecture you're using, in dpkg's arch format
<mvo> dholbach: \o/
<geser> ttx: hopefully nobody sabotage you by adding items to queue
<soren> bdrung: Very much not equal, no.
<soren> bdrung: *My* "!" was an exclamation point, not the factorial operator. Clearly :)
<ttx> 46
<ttx> geser: stop that !
<soren> ttx: You did it wrong.
<geser> dholbach: http://interfacelift.com/wallpaper_beta/D0eee69d/02430_hugme_2560x1600.jpg :)
<dholbach> File Not Found
<dholbach> Error 404.
<geser> hmm, works here
<dholbach> no, sorry - not here :/
<bdrung> hyperair: does this command work too: "sudo", "sbuild", "-A", "--dist=" + dist, "--arch=" + self.architecture, dsc_file
<hyperair> bdrung: i'd avoid the sudo. sbuild doesn't need it.
<bdrung> k
<hyperair> -A, --arch-all
<hyperair> bdrung: ^^ got that from manpage
<hyperair> and --dist= works, yeah
<bdrung> hyperair: do you have time to test sbuild with sponsor-patch?
<hyperair> bdrung: mm give me a quick test case
<bdrung> hyperair: sponsor-patch -B sbuild -b 681418
<hyperair> bdrung: do i need to patch sponsor-patch first?
<bdrung> hyperair: you need to pull the latest u-d-t branch and apply http://pastebin.com/rA3ZpysD
<hyperair> bdrung: what's that in bzrfu
<bdrung> bzr pull lp:ubuntu-dev-tools
<hyperair> i suppose i'll need to branch
<bdrung> patch -p0 < patchfile
<bdrung> hyperair: yes (branch)
<hyperair> okay
<bdrung> tumbleweed: you fail with wrapping. please split "paragraph["Architecture"] = " ".join( sorted(archs, key=lambda x: (1 - int("any" in x), x)))" into two commands
<bdrung> tumbleweed: what's that for: lambda x: (1 - int("any" in x), x)? please comment it
<tumbleweed> right, to put wildcards first
<bdrung> tumbleweed: wildcards? like what?
<tumbleweed> linx-any
<hyperair> bdrung: ..
<hyperair> patching file sponsor-patch
<hyperair> patch unexpectedly ends in middle of line
<bdrung> tumbleweed: ah, ok. please comment that and maybe add an example
<hyperair> patch: **** malformed patch at line 145:
<hyperair> bdrung: could you use paste.debian.net? it's much more patch friendly.
<hyperair> bdrung: i aliased my pastebinit away from pastebin.com precisely for that reason
<bdrung> hyperair: gimme your alias
<hyperair> alias pastebinit='pastebinit -b http://paste.debian.net'
<bdrung> hyperair: there you are:
<bdrung> http://paste.debian.net/100818/
<hyperair> thanks
<hyperair> and there we go, it works
<stgraber> you can also store a configuration file in your home directory ;)
<hyperair> now then.. where was that command..
<hyperair>   File "./sponsor-patch", line 812, in <module>
<hyperair> NameError: name 'Sbuild' is not defined
<bdrung> ./sponsor-patch -B sbuild -b 681418 -v
<hyperair> same thing
<stgraber> bdrung, hyperair: http://paste.ubuntu.com/536749/ (~/.pastebinit.xml)
<hyperair> stgraber: hmm nice.
<hyperair> stgraber: but i don't like paste.ubuntu.com either, because you need to log in in order to download. makes it *extremely* annoying.
<hyperair> stgraber: if you know who maintains paste.ubuntu.com, please relay my message.
<bdrung> hyperair: http://paste.debian.net/100819/
<stgraber> hyperair: I'd guess #canonical-sysadmin. Obviously you can have your .pastebinit.xml file to point to paste.debian.net
<hyperair> stgraber: yeah, i'll do that
<bdrung> pastebinit lacks an killer feature - autodetecting file type
<stgraber> bdrung: patches are welcome :) I remember a few people asking me for that feature though I usually only spend 30min to an hour a year working on pastebinit :)
<hyperair> bdrung: actually, even if you told it that you were uploading a patch, those @@'s get stripped. stupid thing.
<stgraber> (and that's mostly reviewing patches, merging, testing and pushing to the archive)
<hyperair> bdrung: with pastebin.com, you'd be better off base64enc'ing everything before pasting
<bdrung> hyperair: i prefer paste.d.o anyway
<hyperair> .n
<hyperair> bdrung: okay, sponsor-patch keeps failing at debsign.
<bdrung> hyperair: add a -k option
<hyperair> ok
<cjwatson> geser: excellent, thanks for confirming
<hyperair> bdrung: okay, it's building. should i get worried now about it accidentally uploading a package or will it prompt me again?
<ebroder> bdrung: ["sbuild", "-d", dist, "--arch", self.architecture, "-A", dsc_file]. But I don't see a way to change the output directory, so you might have to play with your working dir
<hyperair> ebroder: http://paste.debian.net/100819/
<hyperair> ebroder: all done.
<hyperair> bdrung: and it works =)
<hyperair> bdrung: it ends at lintian. i assume that's correct?
<ebroder> hyperair: Yeah, noticed as I was finishing my scrolling
<ebroder> hyperair, bdring: You guys know that subprocess.call has a cwd= kwarg, right?
 * hyperair didn't have any part in modifying that patch
<ebroder> bdrung: Looks fine. Are you sure dsc_file is going to be an absolute pth? I don't have the code in front of me, just the patch, so I don't know if I'm missing something
<ebroder> pitti: Congratulations. Way to kick ass on piloting
<pitti> thanks :)
<ebroder> xnox: If you're going to fix xiphos through Debian, should I reject your merge proposal?
<mpt> I wonder if the people who use Ubuntu in Occitan wish that we didn't call it "Occitan (post 1500)"
<ebroder> Haha. Do we call our Hellenic language "Modern Greek" as well?
<bdrung> hyperair: yes, it ends with lintian. can you try the same with "-u ubuntu" (and say no if you get ask if you want to upload it)?
<bdrung> ebroder: yes, it uses absolute paths
<cjwatson> NCommander: AFAICS your last cdimage change has the net effect of not only stopping building ubuntu-netbook for armel+dove, but starting to build it again for i386 (due to the later wildcard).  Was this intentional?  if not, ubuntu-netbook/daily-live needs to be removed from the crontab if it isn't supposed to build for anything
<doko> JamesPage: could you have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt for the java stuff (the ones wanting to promote to main)?
<hyperair> bdrung: erm it says [Y/e/n]. what's e?
<bdrung> hyperair: edit
<hyperair> ah
<hyperair> bdrung: you should add a ? option to expand these things.
<hyperair> it's not particularly verbose there
<hyperair> i don't believe it's documented anywhere either
<bdrung> hyperair: file a bug. if you type something else, it will print: "Please answer the question with yes, edit, or no."
 * hyperair has exams and is lazy to file bugs. >_>
<bdrung> hyperair: look in the man page: "the user has an option to edit the patched source and try  building  it again."
<hyperair> ah okay, i missed that
<SeanInSeattle> Hey all.  Can anyone tell me whether or not the following functionality is slated to be included in a future and/or current release of Ubuntu:  When a laptop is disconnected from any, or is connected to one or more, external monitors is updates the nvidia/x configuration accordingly?
<RoAkSoAx> kirkland: ping
<JamesPage> doko: ack; will pickup first thing monday
<psusi> pitti, you mentioned about basing off the new rev in debian ( of lvm2 ).  Are you saying I should do a merge from the debian branch first, and THEN update to the new upstream?
<psusi> ahh, there's the debian bzr branch... hrm... now which one?  squeeze or sid?
<ebroder> psusi: Yes, that's definitely what you should be doing
<psusi> hrm.... ok...
<psusi> aw geeze... the debian package has the wrong version number
<psusi> lvm2 (2.02.66-3) by  Bastian Blank says:  Bastian Blank
<psusi> bah... Import upstream version 2.02.72:
<psusi> he forgot to bump the package revision number
#ubuntu-devel 2010-11-27
<psusi> ugh.... and they left the quilt patches applied in the debian lvm2 bzr branch
<lamalex> Hey devs, I know there's a command to get the packing for a package out of source control, but i can't remember and google is failing
<lamalex> anyone know off hand?
<psusi> apt-get source
<lamalex> psusi, that's not from version control
<lamalex> that's from the archive
<psusi> yep... vc would depend on what vc, if any, a package is using
<ebroder> psusi: That's the way that UDD works with 3.0 (quilt) packages, because it imports the unpacked source tree, and unpacking a 3.0 (quilt) package applies the patches
<psusi> ebroder, eh?  if the bzr repo contains the quilt patch, surly it should not already be applied?
<psusi> the whole point is to keep it separate from the upstream source
<ebroder> psusi: When you do dpkg-source -x on a 3.0 quilt package, it applies the patches
<ebroder> And UDD imports basically dpkg-source -x; bzr add
<psusi> right... but when you do a bzr branch, they should not be applied already
<ebroder> I don't think that's obviously true
<psusi> seems like it to me... when you bzr builddeb, it makes sure the source is clean and all patches are removed, then builds a source package, doesn't it?
<psusi> so when you check it out of the repository, it should already be clean and have no patches applied
<ebroder> I don't think the ordering is quite that obvious with 3.0 packages
<psusi> huh?  ordering is what the series file is for?
<psusi> but when you make a source package, no patches are applied
<ebroder> No, I'm saying that you don't remove the patches, *then* build the source package. Removing the patches is *part* of the build-the-source-package process
<psusi> well, yea... I suppose...
<psusi> it makes sure to remove them in case you forgot
<psusi> but I would think that the natural state of the bzr repository should be to not have them applied
<psusi> i.e. be clean
<ebroder> I think one of the files in debian/source/ specifies what the natural state should be
<ebroder> But I think the default is that the resting state is with patches applied
<psusi> hrm.... that's goofy, since it complicates the merge process since you have to remember to remove them first
<ebroder> Or alternatively, the next time you build the package, it'll create a new patch, and you roll that into other patches as appropriate
<psusi> huh?
<ebroder> I'm not actually sure what I mean. But patches applied is definitely the resting state of the package
<psusi> this is driving me nuts because when I bzr merge the debian version into ours, they have patches already applied and we don't
<ebroder> Well why don't we have the patches applied? If our package is 3.0, too, it should have patches applied
<psusi> so how am I supposed to review the quilt patches when they are already applied?  I have to remove them first, then review/merge/refresh the patches
<psusi> why?
<psusi> I thought 3.0 just meant it used quilt patches, not that they are already applied in the source package?
<psusi> the whole point of the source package format as I understand it is that no modifications are done to the upstream files, but rather they are kept aside in the debian/ directory to facilitate replacing the upstream files with a new release
<ebroder> I mean, modifications are going to be done to the upstream files at some point, so arguing about when is to some extent mincing words. But as I understanding it, unpacking a 3.0 (quilt) package by definition of the format involves applying the quilt patches
<ebroder> s/(understand)ing/$1/
<MattJ> echo "understanding" | sed 's/\(understand\)ing/\1/'
 * MattJ sneaks off to bed quickly
<ebroder> MattJ: echo "understanding" | perl -pe 's/(understand)ing/$1/'
<ebroder> :-P
<MattJ> .
<MattJ> should have known
<bilalakhtar> Can non-core-devs be patch pilots?
<ebroder> Of course! Patch piloting is only partially about sponsorship
<ebroder> One of the most important things you can do as a patch pilot is make sure that patches are in good shape for the people who can do sponsoring
<bilalakhtar> It was cool to see pitti come around and sponsor a UDD patch that I published 5 months ago during the maverick cycle. pitti also updated it to fit the natty package, cool! I had almost ignored the patch completely
<bilalakhtar> s/UDD\ patch/UDD\ merge/
<ebroder> SpamapS: wtf did you do to this mongodb package?
<SpamapS> ebroder: ?? I wish I knew
<SpamapS> ebroder: talking about the lucid backport to use the wrapper?
<ebroder> Yeah
<SpamapS> (which is, BTW, the dumbest thing ever... I really hate that we don't just dump libmozjs.so in /usr/lib :-P
<SpamapS> )
<ebroder> It's annoying me that it's the only package for universe in the sponsors queue, and now it's annoying me that I have *no* clue what the heck is going on, so we'll see if I can manage to channel my annoyance productively
<SpamapS> ebroder: it works on my sbuild and pbuilder, and a clean ec2 lucid instance
<ebroder> Yeah, same for me
<ebroder> (Well, I didn't try EC2, but I'll take your word for it
<SpamapS> I asked in #launchpad but got no response
<ebroder> I'm starting to suspect that something about the usr/bin/mongo symlink is broken as soon as it's created
<ebroder> Hopefully I'll be able to tell from https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066069
<SpamapS> thats just the first one
<ebroder> No, the others all look fine - that one isn't actually a symlink by the time dh_link is done with it
<SpamapS> I was thinking maybe the buildd's might not have the right version of tar
<ebroder> Check out the build log from https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066064 - I added a bunch of debugging printouts
<SpamapS> ebroder: btw, this patch pilot thing is *amazing* .. have seen more in depth reviews and sponsorship in 5 days than in 6 months of Ubuntu work prior
<SpamapS> ebroder: so thanks. :)
<SpamapS> ebroder: OH WEIRD.. why isn't it a symlink?!
<ebroder> SpamapS: That is a *fantastically* good question
<SpamapS> ebroder: also why does everything show up like 5 times in the debug build?
<ebroder> You mean the rm -f ...; ln -sf ... lines? dh_link goes through and "fixes" every symlink every time it runs
<ebroder> So it creates /usr/bin/mongo. Then it creates /usr/bin/mongod and fixes /usr/bin/mongo. Then it creates ...
<ebroder> (Except that something is screwed up with /usr/bin/mongo)
<SpamapS> ebroder: weird!
<SpamapS> ebroder: so might be better to create a manual .links file.. I just wanted to make sure I got everything.
<SpamapS> ugh
<SpamapS> something is wonky about my keyboard/mouse
<ebroder> Maybe. Although it wouldn't really be bad enough to care about if it was actually working, and I'm not convinced that changing how you create the symlinks will fix the issue
<SpamapS> brb.. trying to correct my keboard/touchpad weirdness
 * SpamapS really has to get the multitouch driver going.. the extra taps from the synaptics driver are driving me NUTS
<SpamapS> ebroder: doh stat: cannot stat `/build/buildd/mongodb-1.2.2/debian/mongodb/usr/bin/mongo': No such file or directory
<SpamapS> ebroder: thats after the files have been moved to /usr/lib/mongodb
<ebroder> SpamapS: Yeah, uploaded a new build and fixed that
<ebroder> (https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066075)
<ebroder> Oh, and screwed it up again. But still - usr/bin/mongo is a file coming out of that first dh_link
<SpamapS> ebroder: you should do 'file' on it too while you're hot. ;)
<ebroder> I'm pretty sure it's just a plain file with the contents "../lib/mongodb/xulwrapper"
<ebroder> I mean, a symlink is just a file with weird flags whose contents are the target of the link, even if it's not really exposed that way
<SpamapS> that would be *the suck*
<ebroder> The file is the right size for it to be that
<SpamapS> I suppose it could be an aufs bug.. do the buildd's use aufs like sbuild on our boxes?
<SpamapS> argh, this is so weird.. alt-tab just stops working for no reason
<ebroder> aufs bug would be interesting, but it would be *so* weird to be consistently reproducable for this build and only this symlink but not for anything else
<SpamapS> ebroder: agreed. It might be worth it to build a package that just does dh_link calls and then exits as a test case.
<ebroder> SpamapS: If it was a aufs thing, I would think that installing plain files into /usr/bin then moving them out, then creating symlinks might trigger it
<ebroder> Actually, I'm going to try something...
<ebroder> SpamapS: Alright, I got something for you: http://pastebin.com/EXS4a65j
<ebroder> Test build worked: https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066096
<SpamapS> ebroder: interesting
<SpamapS> ebroder: this still suggests a possible aufs bug.. rename then create symlink in place causes fail.. ?
<ebroder> SpamapS: I, uh, remembered seeing a comment about a bug like that somewhere in initramfs-tools, so figured I'd give it a go
<SpamapS> ebroder: cool.. thanks for lending a keen and capable pair of eyes to it!
<SpamapS> ebroder: applying your patch and re-pushing
<ebroder> SpamapS: Cool. Let me know and I'll sponsor it?
<SpamapS> ebroder: I pushed it already, should be updated in the MP
<ebroder> SpamapS: Ok, cool. Looks good to me. I'm going to add the set -e Stefano mentioned, and then I'll upload
<SpamapS> ebroder: right, cool!
<NCommander> cjwatson: ugh, will fix
<ebroder> NCommander: Is mame good to go? It's the last {uni,multi}verse package in the queue :)
<NCommander> ebroder: I got sidetracked on that
 * NCommander got sucked into visiting home >.<;
<NCommander> on my TODO list as w espeak
<ebroder> Awesome
<ari-tczew> could any admin reject clementine in natty NEW? I uploaded it by mistake. (dput ubuntu instead ppa)
<alex88> Hi, i've got a kernel patch to fix bug 658521. How do i test to see if it works? I'm rebuilding ubuntu kernel and going to test it. Is that the right way?
<ubottu> Launchpad bug 658521 in linux (Ubuntu) "In Live session or installation HD not recognized" [Undecided,Confirmed] https://launchpad.net/bugs/658521
<alex88> no one?
<BlackZ> !weekend | alex88
<ubottu> alex88: 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.
<alex88> oh..:) right..thank you BlackZ :)
<penguin42> alex88: Oh you found a patch?
<alex88> penguin42, sata kernel developer given to me
<alex88> i've added to the bug report
<penguin42> alex88: I tend to follow https://help.ubuntu.com/community/Kernel/Compile   , and yes building the kernel should be a good way to try - won't help on install though
<alex88> now compiling patched kernel
<alex88> penguin42, can't do on that..the board_ahci_yes_fbs isn't declared on older kernel.. i'm building lastest development version
<penguin42> ah right
<alex88> btw, it should build headers and image deb so i can test on usb installed ubuntu if it see the hdd
<alex88> also i've set bug as confirmed.. after testing if it works what to do?
<penguin42> alex88: Not too sure; you could try asking on #ubuntu-kernel, the bug should gain a patch tag automatically I think; can you set 'nominate for natty' - I can't see the botton at the moment
<alex88> np :)
<penguin42> alex88: In that bug it's probably right to be clearer about exactly who gave you the patch
<alex88> penguin42, Tejun Heo <htejun@gmail.com> from linux-ide@vger.kernel.org
<penguin42> yeh, just say that in the bug - it's always good to be able to trace patches
<alex88> done
<crimsun> alex88: as a note, that patch needs to land in Linus's tree and linux-2.6.36.y.git (stable) for the SRU
<penguin42> in which case the thing to do is to test it and confirm it works; Tejun's message says it's a blind patch without testing - so if it works and you can give it a good test let Tejun know, and maybe he can push it or do a bit more investigation
<crimsun> it would just follow normal commit procedure: Reported-and-tested-by: alex88   .. etc.
<nigelb> crimsun: Morning :-)
<crimsun> nigelb: hi
<nigelb> crimsun: Nice to see you around after long
<cjwatson> who runs http://reports.qa.ubuntu.com/reports/sponsoring-stats/?  it would be awfully nice if the graphs' y-axis started at 0
<cjwatson> non-0-based graphs are more usually used for statistical distortions to make a point :-)
<nigelb> cjwatson: that's probably bdmurray's territory
 * penguin42 is surprised that isn't one of the entries in '13 ways to say nothing in scientific visualisation'
<bilalakhtar> doko: Can I work on the gcc-4.3 merge?
<bilalakhtar> doko: ignore it, you have been uploading since a long time, leave it
<bilalakhtar> I mean, ignore my previous message on taking the merge
<bdrung> stgraber: pastebinit to paste.debian.net doesn't work any more. it outputs "http://paste.debian.net/"
<RenatoSilva> how to undo apt-get build-dep?
<ebroder> Of the releases that are still supported, Dapper and Hardy use usplash, Karmic uses xsplash, and everything newer uses plymouth, right?
#ubuntu-devel 2010-11-28
<alex88> hi, how is possible to change kernel on the usb live created with "startup disk creator"?
<psusi> RAOF, you seem to be the x/video guy... am I correct in understanding that the radeon driver loads binary blobs of firmware code provided by ati without source code?  so there is no way to understand how the code running in the card works or modify it in any way?
 * psusi wonders if he can run them through a disassembler
<penguin42> psusi: I might be wrong, but I don't think we know what CPU that firmware executes on
<psusi> heh... weird... apparently I keep getting these weird error messages related to npviewer on my terminal window because chromium and thus npviewer are using that tty for output even though it is not their controlling tty, I guess because chromium was started by apport-bug...
<psusi> surely somewhere along that chain of events, that fd should have been closed...
<hdon> hi all. i am using forkpty() and execve() to capture the output of a popular SDL+OpenGL game. i am now getting this error: SDL_Init(SDL_INIT_VIDEO) failed: No I/O port permissions
<stefano> Anybody here running Lubuntu?
<geser> cjwatson_, doko__: is someone of you working on merging bsdmainutils?
<cjwatson_> I have a merge in progress, yes
<cjwatson_> there didn't seem any major rush
<doko> geser: do you volunteer to comlete the MIR for libhdate?
<geser> cjwatson_: no there isn't, just looked why it's in DEPWAIT and noticed the package rename of libhdate-python
<geser> damn, a MIR is also involved :(
<cjwatson_> it's depwait in the same way both before and after the merge :-/
<geser> just realized that myself
<doko> bilalakhtar: merging gcc-4.3 is wasted time.  please use your time to remove build-dependencies on gcc-4.3 and then request it's removal
<bilalakhtar> doko: thanks, will surely do that from tomorrow onwards
<hdon> hi all. i am using forkpty() and execve() to capture the output of a popular SDL+OpenGL game. i am now getting this error: SDL_Init(SDL_INIT_VIDEO) failed: No I/O port permissions
<penguin42> hdon: Does it normally use X ?
<hdon> penguin42, i believe my problem is because i did not supply it its environment variables
<penguin42> yeh makes sense
<penguin42> I don't suppose anyone knows the details of swap signatures and in particular how hibernation signatures interact with them?
<hdon> hmm, well
<hdon> i'm execve()ing /usr/bin/env as a test that i constructed the environ correctly
<hdon> d'o
<hdon> d'oh
<hdon> i left a line in there that was memset() erasing my envs
<hdon> sweet
<hdon> it works :)
<hdon> (i am not writing in C btw, i am working on an FFI for JS)
<hdon> (programming in it right now is a little convoluted)
<hdon> yay, it worked :)
<pavolzetor> hi, I would like start develop RSS reader, but I cannot find vala and desktopcouch tutorial
<pavolzetor> wrong channel?
<lifeless> IIRC there is a debian ftp-master that lurks here...
<ebroder> Does bug #616682 fall under the GNOME microrelease exception, or should I turn it into a real SRU?
<ubottu> Launchpad bug 616682 in system-tools-backends (Ubuntu) "Backport system-tools-backends 2.10.0 to Lucid" [High,New] https://launchpad.net/bugs/616682
<bilalakhtar> lifeless: and he is Dktr-Kranz
<lifeless> bilalakhtar: thanks
<lifeless> DktrKranz: hi; if you had the time to look at python-fixtures in NEW, that would be awesome - its blocking new releases of python-testtools, python-testrepository and through testtools of bzr*
<DktrKranz> ss
<DktrKranz> err
<DktrKranz> lifeless: looking
<lifeless> DktrKranz: thank you!
<DktrKranz> lifeless: accepted, will be processed in ~11 minutes
<lifeless> DktrKranz: thank you very much!
<DktrKranz> you're welcome :)
<FTMichael> I'm using an application that needs its version updated in the repos.  (It's in Universe.)  How do I submit a bug report to request that the maintainer update it?
<lifeless> FTMichael: we don't have maintainers. You can file a bug asking that it be updated, but the best thing to do is supply an update to it.
<FTMichael> lifeless, the update is available for download as source to be compiled - I just want it to be in the repos to make life easier.
<FTMichael> https://github.com/andy-shev/LogJam/archives/v4.6.0 has the source code.
<lifeless> yes, I understand.
<lifeless> the #ubuntu-motu channel, which deals with universe, would be a better place to discuss this
<FTMichael> ah, okay.  Thanks :)
<FTMichael> How do I file a bug asking that it be updated though?  I was having a hard time finding that in Launchpad for some reason
<lifeless> we heavily depend on the data gathered by apport for bug triage for (most) bugs
<FTMichael> Gotcha
<lifeless> so non-developers have the web UI for filing bugs turned off
 * FTMichael found ubuntu-bug
<lifeless> developers (which we welcome more of!) have the web UI available (but are still meant to use ubuntu-bug where possible :)
<FTMichael> :)  Thanks muchly!
<micahg> sladen: I'm assuming the Firefox regression you reported was based on the version in Natty?
<sladen> micahg: FF4b7 (I think it notes this in the report).  Should it be against a different +source/package ?
<micahg> sladen: no, I'm just wondering which build it is (upstream, firefox-next, natty)
<sladen> micahg: firefox=4.0~b7+nobinonly-0ubuntu3  from the archive
<micahg> sladen: ok, that's natty, thanks
#ubuntu-devel 2011-11-21
<infinity>  3767 root      20   0  2140  332  256 R 35.0  0.0  10763:24 udevd
<infinity> ^-- That seems less than ideal.
<Laney> I have definitely SRUed pidgin for ICQ protocol changes in the past
<Laney> but they were cherry pickable IIRC, indeed
<lamont> cjwatson: alt-drag ftw
<broder> lamont: alt-middle also resizes
<pitti> Good morning
<pitti> slangasek: black/white screen> it's there as a work item, but I don't recall who wanted to look into it; it's assigned to me for now, and I can test it on my two laptops
<pitti> dupondje: oh, papyon take III?
<broder> pitti: any thoughts on bug #852603? part of me wants to advocate an sru since it would fix network compatibility for the game, but the rest of me can't get over how terrible of an idea that is
<ubottu> Launchpad bug 852603 in Oneiric Backports "Please backport hedgewars (0.9.16-1) from precise to oneiric" [Undecided,Incomplete] https://launchpad.net/bugs/852603
<pitti> broder: TBH I'm not that concerned about SRUing 0.9.16/.17
<pitti> it's a leaf app, it needs to be kept up to date with the online network version, and there's not much regression potential, or is it?
<broder> i don't think there's a whole lot of regression potential, but it doesn't really seem like they make a separation between bugfixes/features in their point releases
<broder> well, that's not true - they actually indicate them differently in the changelog, but they don't keep the new features out
<pitti> yeah; but I guess most games are like that
<broder> ok. well, if you're ok with it, i'll arrange an sru once 0.9.17 lands in precise
 * RAOF wonders if there should be a standing SRU exception for games of all kinds.
 * micahg thinks that sounds like trouble
<RAOF> Possibly on the âlots of work for usâ front, yes.
 * micahg thinks of someone wanting gnome-games 3.2 in lucid :-/
<broder> i thought we had been working on a standing exception for "things that broke because of changes in other systems on the internet" or some such, but i didn't remember it actually getting settled
<pitti> that was discussed in the context of ubuntuone stuff
<pitti> but in general SRU exceptions are granted for these kinds of software
<pitti> as changing server protocols obviously breaks the current version in the archive
<pitti> which clearly falls under the "regression" SRU policy
 * broder nods
<pitti> that said, focussed patches there are still preferred
<tumbleweed> OTOH updating it means any local servers need to be updated too
<pitti> and we usually require them for stuff like empathy plugins or server-ish stuff
<pitti> but for games I think we don't need to be as strict
<pitti> tumbleweed: if we have the local server software packaged, yes; that usually doesn't apply to things like "msn is broken"
<pitti> (a current SRU which we have right now)
<tumbleweed> pitti: of course. And I think in hedgewars, there are many public servers that run the latest version
<tumbleweed> I seem to recall my university's hedgewars-playing group distributing their own version of the game that matched their server (which was certainly newer than the lucid in the labs)
<broder> on the plus side, hedgewars in lucid is only several "point releases" behind - no minor releases even
<pitti> cjwatson, Daviey, slangasek: from the desktop team POV we'd like to re-enable apport in precise soon; when would be a good time for foundations/server?
<pitti> that's for picking up and reporting crashes
<dholbach> good morning
<lag> dholbach: Yo! GM. :)
<lag> Daviey: What are you on about?
<dholbach> hey lag
<dholbach> how's life over there?
<sladen> dholbach: hallo
<dholbach> hey sladen :)
<lag> dholbach: Cold and drab, and there?
<dholbach> cold as well, but here the sun is shining
<sladen> somebody painted all the Millbank windows white
<tsdgeos> tkamppeter_: ping
<tkamppeter_> tsdgeos, hi
<tsdgeos> tkamppeter: you opened a bug about "Okular should print PDF instead of Ghostscript"
<tsdgeos> rgiht?
<tkamppeter> tsdgeos, I asked someone to open it. We must do s/Ghostscript/PostScript/ in the title.
<tkamppeter> tsdgeos, can you post the number of the bug here?
<tsdgeos> tkamppeter: https://bugs.kde.org/show_bug.cgi?id=286825 https://bugs.launchpad.net/ubuntu/+source/okular/+bug/891199
<ubottu> KDE bug 286825 in general "Okular should generate PDFs when printing instead of GhostScript" [Wishlist,Unconfirmed]
<ubottu> Launchpad bug 891199 in okular (Ubuntu) "Okular sends print jobs in PostScript format" [Medium,Confirmed]
<tsdgeos> tkamppeter: i disagree totally this is a bug
<tsdgeos> and if ubuntu is failing to print the ps files we generate, well, then that's an ubuntu bug
<tkamppeter> tsdgeos, it was generally agreed on to send print jobs in PDF format, especially all GTK applications, LibreOffice, Firefox, Thunderbird, and all the other KDE/Qt applications send PDF.
<tsdgeos> "generally agreed" by who?
<tsdgeos> and even if it was "generally agreed"
<tsdgeos> does that "general agreement" also include the clause "and while we do that let's make printing PS fail"
<tsdgeos> because if i read correctly the ubuntu bug, the problem is more like that "ps printing fails" not that "okular does not print to pdf"
<tkamppeter> tsdgeos, CUPS in Debian and Ubuntu does PDF-based printing for years and from CUPS 1.6 on PDF-based filtering will be upstream standard.
<tsdgeos> so?
<tsdgeos> i am sending a file with .ps extension
<tsdgeos> cups started being stupid and decides to treat it as a pdf?
<pitti> I thought cups had a ps2pdf filter for that case?
<tkamppeter> tsdgeos, no one made PS printing fail intendedly, and I amm all the time  working with the Ghostscript people to fix bugs in any PDF->PS, PS->PDF, PS/PDF->CUPS-Raster conversion.
<tsdgeos> tkamppeter: good, then don't make it seem like if it is Okular having a bug ;)
<tkamppeter> tsdgeos, the PostScript printing bug mentioned here got fixed in upstream Ghostscript today and I will prepare an SRU for Oneiric.
<tsdgeos> awesome :)
<pitti> well, okular should still send PDF
<tsdgeos> sure
<tsdgeos> but that's a wish
<tsdgeos> not a bug
<pitti> okular converting PDF to PS, and then cups PS back to PDF is a bit pointless?
<pitti> tsdgeos: right
<tkamppeter> pitt, CUPS has the filter, but there was a Ghostscript bug which prevented correct conversions of files with certain fonts. This is fixed now and will get SRUed to Oneiric.
<pitti> tkamppeter: nice
<tsdgeos> i.e. if people complains Okular prints wrong, is not because we do not print to pdf, it's because lpr stopped knowing how to print PS
<Chipzz> tkamppeter: I'm... totally baffled. are you aware there are these tnings called postscript printers? why would a viewer which supports PS convert that .ps to a pdf when printing to a postscript printer? that's MADNESS
<tkamppeter> tsdgeos, the upstream report on Okular is not done by me, perhaps the user did not know how to mark it as feature request.
<tsdgeos> tkamppeter: while we are on this, do you know how can know if cups is "pdf aware" ?
<pitti> Chipzz: that's not what we said, though?
<pitti> Chipzz: if you are viewing a PDF document, it should be sent as PDF instead of being converted twice
<tsdgeos> Chipzz: the thing is we (Okular) convert PDF to PS for printing, this could be "shortcircuited" with the "new" cups
<tkamppeter> tsdgeos, CUPS is always PDF-aware as it has a pdftops filter.
<tsdgeos> tkamppeter: i don't want it going through a filter, because if it goes through a filter, and the output is different from the things in screen, people will blame me, not cups
<tsdgeos> which otoh sounds nice since i can just forward all printing bugs to cups :D
<pitti> well, in an ideal world all of these flows should work, so if they differ, there certainly is a bug
<pitti> so if you convert PDF to PS, and they both look identical, but print wrongly, that's a cups bug no matter which format it prefers internally
<pitti> (well, "cups" in a wide sense -- bug in anything in the filter chain)
<Chipzz> pitti: right. I'm not sure what makes pdf a better format for printing than ps though
<pitti> Chipzz: in general scaling, printing 4-on-1 etc. works a lot more robustly with PDF
<tkamppeter> tsdgeos, all conversions specific to the printer should be done by CUPS, not by the apps, so the app does not need to know whether a printer is PS or not. So let the PDF viewer simply send PDF and if the printer is actually PostScript CUPS does the needed conversion.
<tkamppeter> tsdgeos, one could add a comfigurable setting to Okular, to decide whether it sends PS or PDF. In the Debian and Ubuntu packages one lets default it to PDF, from CUPS 1.6.x on one default generally to PDF.
<tsdgeos> tkamppeter: the other side of the equation is systems without cups, i guess there you still need to print to ps
<tkamppeter> tsdgeos, with the configurable setting no problem. Let it default to PS if there is no libcups available.
<tsdgeos> asking to the user if he wants to print to ps or pdf seems like an over-configuration setting
<tsdgeos> my father would not know what to do with it
 * Chipzz wonders if anyone has ever done 'cat foo.ps > /dev/lpr' :)
<pitti> tsdgeos: it's not configuration at all indeed, it's an internal implementation detail
<pitti> tsdgeos: this only makes sense for printing into a file
<tkamppeter> tsdgeos, it must have a reasonable default. Perhaps it does not even need to be in the user settings. As far as I know there is already such a switch as build time switch for other Qt apps, making Qt send PDF in case of CUPS (libcups from a certain version on) being present and PS afterwards.
<tkamppeter> s/afterwards/otherwise/
<tkamppeter> tsdgeos, in addition a ./configure option allows the distro packager to change the default.
<tsdgeos> yeah, i'll think about it
<tsdgeos> otoh it's kind of a lot of work to make something that works, work :D
<pitti> I think it'd be easier to send PS as PS and PDF as PDF
<pitti> but anyway, let's just unbreak PS, then it doesn't matter much
<tsdgeos> sure, if you would not have to account for systems where printing PDF is not a feature
<tkamppeter> tsdgeos, see also http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
<tsdgeos> tkamppeter: yes, Okular works on "non linux systems", so telling me the linux foundation decided something, is not a reason good enough to punish freebsd users
<pitti> isn't that more a question of the printer spooler than the kernel?
<tsdgeos> yes
<pitti> cups works just as well on BSD, given that it's developed by Apple
<tkamppeter> tsdgeos, so it should decide on the presence of Linux and libcups at build time.
<Chipzz> tkamppeter: tbh that doesn't make much sense to me
<Chipzz> tkamppeter: a distro could choose always to compile against libcups
<Chipzz> while the user can choose not to install cups
<Chipzz> can you "detect" if there's sth at the other end of the line with libcups?
<tsdgeos> afaik not
<tkamppeter> Chipzz, and if the distro compiles against CUPS, the app could get built so that it sends PDF.
<tsdgeos> everyone just installs something called "lpr"
<Chipzz> tkamppeter: you... are missing the point
<tsdgeos> and there's not even a way to run lpr -v or something to know who you are talking to
<tkamppeter> Chipzz, you mean auto-detecting whether the local system runs a CUPS daemon, an LPD daemon or whatever and then decide at run time which format to send?
<Chipzz> yes
<pitti> the LP protocol doesn't have anything like "supported formats"?
<Chipzz> tkamppeter: *compiling* against libcups is a distro choice. installing cups itself is a user choice
<cjwatson> pitti: I don't have any particular blocker for re-enabling apport
<tkamppeter> Chipzz, the print dialog of Okular shows the CUPS queues, so it has recognized that we use CUPS, so we could send PDF in such a case.
<tsdgeos> tkamppeter: if you convince the Qt people to expose all that information they have so i can use it, you'll be my hero
<tkamppeter> tsdgeos, once somehow it works for the other KDE/Qt apps, and second, if there is no way for the app to find out whether it is used with CUPS or not, let us at least support the distros which ship with CUPS by adding a build-time option so that packagers can easily make Okular sending PDF.
<tsdgeos> tkamppeter: Okular is not the "typical" KDE/Qt application in the sense we can't use QPrinter since it does not expose lots of stuff (and that's why you'd be my hero if you get Qt dudes to expose it)
<tkamppeter> tsdgeos, so let us do the build-time option, so the packagers of the CUPS distros can simply do something like "./configure --with-pdf-printing" and Okular perfectly integrates with these distros.
<tsdgeos> yep
<tsdgeos> as said looks like a sane idea
<tsdgeos> just need to get the time to implement it :-)
<tsdgeos> is it me or is it libtiff4-dev uninstallable?
<pitti> works fine here (current precise)
<tsdgeos> in oneric it seems to want libjpeg-dev that seems to not exist
<tsdgeos> probably asking in the wrong channel :D
<pitti> tsdgeos: libjpeg6b-dev
<pitti> libjpeg-dev is a virtual packate that libjpeg6b-dev provides
<pitti> in precise it's provided by libjpeg8-dev
<tsdgeos> i see
<tsdgeos> much better now
<tsdgeos> tx
<dholbach> hey wendar - do you think you can clarify my action in https://blueprints.launchpad.net/ubuntu/+spec/community-p-app-review-board? I'm not quite sure what I'm supposed to do :)
<agateau> hey, I am working on a package for massif-visualizer and would like to provide a man page for it, is it acceptable to generate the manpage using a tool like help2man, pandoc or asciidoc?
<cjwatson> yes, although IMO that's the bare minimum for a manual page rather than something that's actually good
<cjwatson> (help2man that is; no experience with pandoc or asciidoc)
<tumbleweed> help2man really just gives a good starting point for a manpage, but yeah, maintaining a manpage in rst can be easier than nroff (and harder for tricking formatting)
<cjwatson> it's certainly fine to generate manual pages from other formats in general
<agateau> I thought help2man was a formatting tool, now that I see what it does, I realize it would not be appropriate
<agateau> tumbleweed: are there example of debian packages which maintain generated man pages? (I mean man pages provided by the packager, not by upstream)
<azeem> loads of them
 * tumbleweed greps thtrough the source packages on his working directories, and finds namebench, springpython, tweepy
<agateau> tumbleweed: azeem: thanks
<cjwatson> POD is a good format to generate these from too
<cjwatson> since we've already gone through the process of making sure its output is actually of decent quality
<cjwatson> (i.e. pod2man)
<cjwatson> I think I would advise that by preference over tools where we haven't yet gone through that process
<azeem> isn't the docbook2man thing which dh_make puts as template quite ok as well?
<cjwatson> azeem: it's had fairly bad problems in the past, although I think most of them got sorted out.  Still, I can't recommend something that involves humans writing XML
<tjaalton> jelmer: hey, the symbol versioning of libldb doesn't seem to work, since sssd needs a rebuild every time ldb is updated..
<jelmer> tjaalton: it works for libary users, not for plugins IIRC
<tjaalton> jelmer: hmm right
<tjaalton> i'll modify the package to depend on the libldb1 version that it was built against..
<xruud> Can someone point me in the direction of an development program I should use to develop a single linux program I will run on a machine with ubuntu installed? The program displays images from the internet, very much alike a photoframe. Except it has no user interface on the device
<xruud> The linux machine will have to boot and start the program. It needs to do nothing else (except when I need to access it for maintenance)
<Chipzz> xruud: please pretty please read the topic
<Chipzz> (and not just in this channel, but in ANY channel you join)
<dholbach> thanks jelmer
<brendand> xruud - #ubuntu-app-devel please
<dantti|2> cnd: around? the way to look for hid messages is using an application called PackageLogger? if so does it come in xcode package?
<xruud> Chipzz
<xruud> Chipzz: sorry, irc is new to me, believe it or not.
<xruud> brendand: thanks
<ockham_> didrocks: my branch for fixing bug 785101 has just been merged into unity-lens-applications, would you consider pulling it into ubuntu/u-l-a?
<ubottu> Launchpad bug 785101 in unity (Ubuntu) "unable to remove the "Apps Available for Download" section from Applications Lens" [Undecided,Fix committed] https://launchpad.net/bugs/785101
<didrocks> ockham_: this will go in precise with the new u-l-a release rather
<jelmer> tjaalton: actually, looking at that again I wonder if, as an upstream, we should drop that strict dependency between ldb modules and the version of ldb they can use
<ockham_> didrocks: sry, i'm not exactly aware of the sync'ing workflow for ubuntu-native packages. so this will happen automatically?
<tjaalton> jelmer: that would be great
<didrocks> ockham_: well, not automatically, but it will as soon as we release a tarball :)
<fish_> hi
<ockham_> didrocks: ok. and what about oneiric-updates?
<didrocks> ockham_: I'm not sure it qualifies for a SRU
<ockham_> didrocks: well, neither am i. i was just hoping it does...
<seb128> ockham_, seems like a backport thing rather
<ockham_> seb128: ok. how is that done within ubuntu?
<tjaalton> jelmer: and bump the so when the plugin api changes ;)
<fish_> I'm a bit confused by ffmpeg packaging. I just want to get this: looks like ffmpeg dropped support for the binary/old amr codecs and uses opencore codecs now. but it looks like ffmpeg was packaged without support for this (-> installing libopencore-amr* doesn't provide support for amr transcoding)
<seb128> ockham_, https://wiki.ubuntu.com/UbuntuBackports
<fish_> just want to know if this is supposed to be like that? or if I might be doing something wrong
<fish_> could somebody confirm that there is no amr support in ffmpeg, not in multiverse, not in a ppa and not in medibuntu?
<fish_> looks like ffmpeg dropped the support for those old, binary libamr* codecs and uses opencore codecs now
<fish_> but using them is disabled in the ubuntu packages ffmpeg
<fish_> at least in 10.04
<fish_> the opencore codecs are there, but no ffmpeg version with enabled support for them
<fish_> https://help.ubuntu.com/community/FFMpeg#Medibuntu <- this wiki page tells it should be possible with medibuntu but there is no ffmpeg for lucid
* cjwatson changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev
<cjwatson> sorry, mirroring was fixed ages ago, but I forgot to remove that from the topic
<zyga> any upstart developers around? I need some advice (no answer on #upstart)
<soren> zyga: See man init(5), search for "kill signal"
<soren> zyga: (init(5) is a treasure trove of information about upstart, by the way)
<zyga> soren, looking
<zyga> ah
<zyga> lovely
<zyga> why is this not in the cookbook then :)?
<jhunt_> zyga: it will be on the next update. If you find errors and omissions, you are more than welcome to provide patches :)
<cjwatson> infinity: I've fixed that debootstrap bug with perl-modules upstream
<ogra_> Waiting for network configuration...
<ogra_> Waiting up to 60 more seconds for network configuration...
<ogra_> hrm
<stgraber> ogra_: what kind of system and environment is that on and what do you have in your /etc/network/interfaces? (that's the new upstart magic implemented in Oneiric)
<zyga> jhunt_, is the cookbook somewhere in lp ?
<ogra_> stgraber, its an omap4 based tablet for which we dont have the right kernel
<ogra_> stgraber, so there are currently no network devices
<stgraber> ogra_: could it be that your /etc/network/interfaces contains an entry for eth0 but it never comes up as eth0 doesn't exist?
<jhunt_> zyga: sure is - https://launchpad.net/upstart-cookbook. Expect a large update in the next week or so, but feel free to raise bugs, etc.
<ogra_> ubuntu@ubuntu:~$ cat /etc/network/interfaces
<ogra_> cat: /etc/network/interfaces: No such file or directory
<ogra_> no /e/n/i
<stgraber> oh, is that legal? :)
<ogra_> no idea
<ogra_> i got a lo interface
<Riddell> ubuntu doesn't do armhf right?  only armel?
<pitti> I thought we were working on a port for this?
<juliank> Isn't it currently bootstrapping?
 * micahg thought he saw somewhere that is coming very soon :)
<infinity> cjwatson: \o/
<Riddell> ok I'll make packages assuming it's coming
<ogra_> Riddell, it is still in the buildd bootstrap phase but will happen soon
<ogra_> we will decide by FF if we support it or not
<agateau> hi again, thanks to your suggestions I was able to produce a man-page for massif-visualizer. I created it partly by copying content from https://projects.kde.org/projects/extragear/sdk/massif-visualizer . I added the standard "man page created for the Debian project" paragraph, but actually I am wondering if I am allowed to do so since roughly 75% of the man page comes from the site description (which has neither license nor author)
<agateau> any opinion?
<tumbleweed> is that text not also present in a readme or something? You can always mail the maintainer and ask for clarification. In fact, you should offer them the manpage, anyway.
<Riddell> agateau: well the man page is created for ubuntu so you can say that, you probably want to clarify the licence with upstrem (Milian Wolff)
<agateau> tumbleweed: no it's not in the README, would have been simpler that way, indeed
<agateau> Riddell: yes I can say the page has been created for Ubuntu, but can I say that it has been written by me and define its license myself?
<cjwatson> that paragraph isn't an assertion of copyright, and it also isn't mandatory
<cjwatson> the man page should have the same licence as the program; there is honestly no excuse for a program and its documentation having different licences, the GFDL madness notwithstanding :)
<cjwatson> if the paragraph makes you uncomfortable, omit it
<agateau> actually it's about whether I can claim copyright for it: the man page is also covered by debian/copyright if I am not mistaken
<agateau> maybe I am just too much of a nitpicker
<agateau> that project is a license party :)
<Riddell> agateau: if it's copy and pasted from elsewhere then you can't claim it's all yours no
<agateau> Riddell: I did some proofreading and reformatting obviously, but that's basically it
<agateau> I should have ignored the lintian warning :)
<Riddell> agateau: Milian is usually pretty responsive on IRC
<agateau> Riddell: haven't had much luck lately, but will give it a try
<Riddell> agateau: really we should get projects.kde.org to have a standard licence for its contents
<agateau> Riddell: indeed
<agateau> Riddell: have you already been in a similar situation with projects.kde.org?
<Riddell> nope
<agateau> Riddell: actually, we should get projects.kde.org to use the content of README files for the Overview page
<agateau> Riddell: that way we get proper licence and ownership and we don't even have to care because the content is in the tarball
<Riddell> ah well that's more fiddly, I'm sure kde sysadmin would be happy for your help though :)
<agateau> Riddell: heh, all of this for a manpage :)
<cnd> dantti|2, it might
<cnd> I have xcode installed
<apw> slangasek, just wondering where if anywhere we are on that udev race stuff, triggered by the bnx2 firmware load, are you on point for that one??
 * pitti exports first shot of http://people.canonical.com/~ubuntu-archive/apport-duplicates/ and gets his first client-side detected crash duplicate
<pitti> ev: ^ FYI :)
<ev> yay!
<ev> pitti: for what it's worth, I'm helping the DX team this week at Rick's request, so I'll only be working on the crash database in the evenings - if that time isn't absorbed by the DX work :)
<pitti> ev: ah, good luck with this! I'm sure they appreciate any extra hand they can get
<ev> cheers
<slangasek> apw: I think I'm on point for that one, but I haven't made much progress; the partial fix I was hoping to apply that could be SRUed quickly failed because it leaves the udev in the initramfs blocking the socket thereby preventing startup of the process on the rootfs
<slangasek> apw: so it looks like we have to fully implement what we discussed at UDS to make any proress
<slangasek> pitti: yeah, I don't kno anything that should hold up apport re-enabling
<apw> slangasek, hopefully the systemd stuff will help us there
<slangasek> apw: uh?
<apw> slangasek, the hooks in udev to allow passing of sockets in (which is there for systemd) ought to help us pass the ones we have over
<slangasek> ah
<slangasek> yes, should do
<apw> slangasek, ok so for now, you are the man (if not yet making progress), if you need help yelp
<slangasek> apw: will do, thanks :)
<tumbleweed> just ran into a situation where the recovery partition overwrote the partition table as soon as it was booted, before asking any questions. /me wonders if we should really be showing those things in the default grub menu
<agateau> reportbug cannot connect to Debian BTS, is it a known issue or is there something wrong in my setup?
<cjwatson> Sweetshark: when do you plan the next libreoffice upload?  it's involved in three library transitions so far; I don't like to upload libreoffice frivolously, but it would be good to know roughly how long those need to wait
<roaksoax> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: roaksoax, ev
<tgall_foo> doko, any questions or would you like me to start over ?
<doko> tgall_foo, please could you open a question in the launchpad project to increase the size of your PPA, and finish the rebuild?
<tgall_foo> doko, yes I've already opened up a quick on launchpad to request an increase in PPA
<doko> tgall_foo, are the few build failures related to libjpeg-turbo?
<tgall_foo> s/quick/question
<tgall_foo> if you look at : https://launchpad.net/~tom-gall/+archive/libjpeg-turbo,  there haven't been any failures
<wendar> dholbach: you're our CC liason for figuring out how to run elections where the number of candidates matches the number of slots
<tgall_foo> between imlib, imagemagick, koffice, gimp, ghostscript, v4l, webkit and so on?  there's a good number of heavy weights built against the new libjpeg-turbo thus far
<wendar> dholbach: will try to make a clearer action item
<tgall_foo> but as noted there's a couple more left to complete a rebuild of all packages that have deps against libjpeg-dev that are located in the main archive ?     with the additional ppa space I should be able to complete that and then get on to universe
<dholbach> wendar, ah, in that case, we often just set up a poll in LP for every person that's to be elected and did a confirmation poll - person X - yes? - no?
<dholbach> wendar, I can bring it up on the CC list and CC you in
<dholbach> so we can document it
<wendar> dholbach: good idea. I've tweaked your workitem to be clearer, and added one for me to document the results, so we have it captured for the next ARB election
 * dholbach hugs wendar
<dholbach> great
<An-iSociaL> do i understand correctly this would be a good place to talk about a kernel developed for ARM Tegra on a Stingray board?
<An-iSociaL> for the purpose of running ubuntu, of course
<doko> tgall_foo, yes, I would prefer to finish the rebuild before doing the rebuild in the main archive
<tgall_foo> doko, just to validate, you do want everything with libjpeg-dev deps validated from universe as well right ?
<doko> tgall_foo, well, we'll have to fix these too ...
<tgall_foo> np :-)
<tgall_foo> I noted the pkgswith libjpeg62 deps yet ..  I presume some "fixes" to move those to libjpeg8 would be welcome ?
<cjwatson> um, if it's ABI-compatible, why can't libjpeg-turbo just deliver a libjpeg8 pabinary package?
<cjwatson> I'm not happy about doing another transition just as we're most of the way through the first one
<An-iSociaL> hm
<cjwatson> s/pabinary/binary/ what happened there
<SpamapS> cjwatson: Ok to start the libmysqlclient transition today?
<tgall_foo> cjwatson, it does, but it it's good to validate
<cjwatson> tgall_foo: then why do we need a rebuild in the main archive?
<cjwatson> SpamapS: yes
<SpamapS> cjwatson: ty
<tgall_foo> cjwatson, in theory you wouldn't
<cjwatson> let's make that in practice, then
<cjwatson> tgall_foo: anything that build-depends: libjpeg62-dev or libjpeg62-dev | libjpeg-dev should be changed to build-depends: libjpeg-dev alone
<tgall_foo> cjwatson, and from what I've tested locally I haven't had issues replacing libjpeg8 with -turbo
<cjwatson> patches for that are fine; it's gradually happening in Debian
<tgall_foo> cjwatson, good to hear,  needs to be done and I'm happy to do it
<cjwatson> I've been working my way through slowly as well
<cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/libjpeg.html
<tgall_foo> ah cool :-)
<hrw> can someone tell me how often Packages.gz on ddebs.ubuntu.com are refreshed?
<pitti> hrw: 41 3,8,11,15,19,23 * * * for precise
<hrw> pitti: thanks
<pitti> 10 2,10,18 * * *  for stables
<pitti> that's UTC
<Sweetshark> cjwatson: I dont quit eget the question. the last upload was 3.4.4 for oneiric-proposed ...
<cjwatson> Sweetshark: I'm asking when you plan the next upload directly to precise, built against precise libraries
<cjwatson> perhaps I should say the first upload directly to precise, but even so :-)
<Sweetshark> http://wiki.documentfoundation.org/ReleasePlan/3.5#3.5.0_release <- I aim for beta0 as first release ...
<cjwatson> Sweetshark: OK, that's close enough for comfort I think; thanks
<cjwatson> I just want to make sure that we don't keep dragging around old libraries that only libreoffice depends on
<Sweetshark> cjwatson: ahhh, ok.
<\sh> mdeslaur, pingeling tomcat6 security update
<micahg> Sweetshark: you're aware that the oneiric update moving to -updates is blocked on something being uploaded to precise, right?
 * tgall_foo waves to arges 
<arges> tgall_foo, howdy
<Sweetshark> micahg: well, there 3.4.4-0ubuntu1 is uploaded to precise. however, by the time a 3.4.5 is coming around, there will be a 3.5.X release in precise, so do I still need to (forwardport) the outdated release?
<micahg> Sweetshark: 3.4.4 isn't published in precise
<cjwatson> micahg: well, normally that would happen after copying to -updates, in cases where the earlier -proposed has gone first; but in this case it would actually be quite nice to have a 1:3.4.4-0ubuntu2 that's actually built in precise rather than just copied in
<cjwatson> I could copy 1:3.4.4-0ubuntu1 to precise if that's the only blocker to that update moving to -updates
<cjwatson> but that doesn't help with getting it weaned off NBS libraries
<micahg> cjwatson: I thought the new policy was uploads must be to the devel release per: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-November/000908.html
<cjwatson> yes, but I think that was after the upload of 1:3.4.4-0ubuntu1 :-)
<cjwatson> oh, perhaps not
<micahg> well, either way, it can still be properly resolved :)
<cjwatson> right
<cjwatson> so we should really get a 1:3.4.4-0ubuntu2 in precise, in advance of 3.5.x, so that it can help with QAing the oneiric update
<ppetraki> Can someone triage this and get it assigned to a distro series? mterry has already reproduced/verified it but I need someone with more authority to move it to the next level: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/891707
<ubottu> Launchpad bug 891707 in firefox (Ubuntu) "java webstart creates infinite open windows, desktop DoS" [Undecided,Confirmed]
<jdstrand> doko, mterry: what is the MIR procedure for things that are mostly in main, but have a couple of binaries in universe, when we want to have them promoted. I am looking at apparmor-- there are several binaries in universe for no particularly good reason anyore: apparmor-notify, apparmor-profiles, libpam-apparmor, libapache2-mod-apparmor and python-libapparmor
<jdstrand> doko, mterry: none of these are servers, need security review, etc. apparmor is a canonical maintained project these days and we support those as if they were in main anyway
<mterry> jdstrand, I believe just file a MIR and mention the situation, which binaries you want to promote, etc.  What's the motivation here?  Does anything want to use those binaries?
<jdstrand> mterry: I just thought their placement should correctly repesent their level of support. python-libapparmor will likely need to be promoted for some upcoming tools
<jdstrand> mterry: I don't want people to be afraid to use them. They are well supported
<mterry> jdstrand, I think the general idea is to not promote something until it's going to be used, but doko would know more about that policy
<jdstrand> well, yes, but these are leaf applications
<jdstrand> (excepting python-libapparmor)
<jdstrand> (and apparmor itself is of course extensively used in Ubuntu-- ie, if the MIR were to happen today, these would all go to main as there is no reason why they should not)
<jdstrand> doko, mterry: ok, I filled a bug: 893266
<ubottu> Launchpad bug 893266 in apparmor (Ubuntu) "[MIR] move all apparmor binaries to main" [Undecided,New] https://launchpad.net/bugs/893266
<Thetawaves> is there a way to get a kernel with DEBUG config options set without compiling my own?
<seb128> jdstrand, mterry: no need of a bug to promote binaries
<seb128> jdstrand, mterry: things are demoted when they show on componentmismatch, i.e when nothing pull them in main
<seb128> jdstrand, mterry: you basically need something in main to depends or recommends on those binary (source or seed)
<jdstrand> seb128: I'm happy to seed them. Since I am requesting it and I am on the mir team, I thought I should ask someone about it
<jdstrand> seb128: similar to the "don't process your own uploads" rule
<jdstrand> I'm looking for permission to seed them basically :)
<mterry> jdstrand, seb128: bug is required if the last MIR for the source package ignored the code for those binaries.  but if they've been signed off on, then yah, no bug required.  i'd have to look at history
<seb128> mterry, ok, fair enough, usually we just promote or demote binaries without extra paper work I think
<seb128> but that makes sense
<seb128> if the source is in main it's supported anyway, it doesn't make a real difference where the binaries are I think
<jdstrand> well
<jdstrand> we don't always do that
<dobey> slangasek, SpamapS: could one of you accept ubuntuone-client 0ubuntu2.2 into oneiric-proposed? thanks
<mterry> in theory, these binaries could be crazy daemons and all sorts of stuff.  so they just need a quick MIR review to confirm.  jdstrand, I'll do that review right now
<jdstrand> eg, if a new binary comes in with a new upstream version, what is the decision to be made? I've generally adjusted the override for main if it isn't security sensitive
<jdstrand> (eg, when processing NEW)
<seb128> jdstrand, define "we"? ;-) I guess the practice is one of those which is not consistent between members of a team there
<jdstrand> if it is a daemon or something, I leave it in universe
<cjwatson> jdstrand: in practice, ubuntu-archive is going to promote binaries when the source is already in main without particular consultation
 * jdstrand nods
<cjwatson> jdstrand: if the security team is relying on us to not do that, this needs new infrastructure, rather than assuming that some process will be interposed
<jdstrand> that is what I do, unless it looks iffy
<cjwatson> I've always consistently said that people don't need permission to promote new binaries
<jdstrand> cjwatson: no, this isn't about my team
<jdstrand> that last bit is what I wasn't clear on
<cjwatson> well, if *anyone* is relying on us to not do that
<cjwatson> MIR team more than security team I suppose
<jdstrand> this is slightly different-- these aren't new binaries
<jdstrand> I am trying to clean things up-- they should be in main, they are already supported as if they were
<seb128> well same difference, usually when something starts pulling an universe binary from a source in main we promote it
<cjwatson> jdstrand: doesn't matter
<jdstrand> hey, I'm happy to 'just do it' :)
<An-iSociaL> snicker
<cjwatson> what I meant was "I've always consistently said that people don't need permission to promote binaries from sources that are already in main"
<seb128> jdstrand, well if you just promote it but nothing in main "is pulling it in" it will be demoted again because it will show up on the component mismatch list
<cjwatson> right.  seed/depend first
<jdstrand> yes, I would seed it
<mterry> cjwatson, is there a blacklist somewhere?  Because if I'm not mistaken, sometimes we promote certain binaries and intentionally don't want to promote others.  A blacklist would prevent mistakes in the process you outlined
<cjwatson> mterry: there is a theoretical blacklist in the heads of members of the MIR team ;-)
 * mterry isn't thrilled with that answer  :)
<cjwatson> I suppose we could use the !-seeding facility in the supported seed or something, but it would require some investigation
<cjwatson> problem is, you guys started doing this without ensuring that it fit into archive workflows ...
<cjwatson> I think there's only a handful of such cases?
<mterry> Probably, and I doubt apparmor's are part of them
<cjwatson> demotion> FWIW at least I tend to be not particularly trigger-happy about demotions, because I know that they're often just about to be depended on by something, or similar
<jdstrand> tbh, the split of main/universe within a package is quite confusing a lot of times
<cjwatson> I do think we need to sort out this blacklisting thing
<dobey> mterry: btw, care to help me understand how to get my avahi changes into debian, at some point? :)
<jdstrand> there are cases, of course-- where we don't want the crazy daemon but we do want the lib
<cjwatson> it might be easier to do it in component-mismatches itself rather than trying to express even more complex concepts in seeds
<jdstrand> (and that is coming from a member of the security team ;)
<mterry> jdstrand, what's this apparmor pam module do?
<cjwatson> I have a near-term work item to move component-mismatches off ftpmaster and into ubuntu-archive-tools, which ought to make it easier to work on in this kind of way
<mterry> nm, found the readme
<cjwatson> I very much want the archive admins not to have to search through MIR bugs, think about security policy, etc.
<mterry> cjwatson, makes sense :)
<jdstrand> mterry: it allows you to transition to roles based on your id. it makes things like MLS possible: http://wiki.apparmor.net/index.php/Pam_apparmor_example
<jdstrand> cjwatson: that sounds wonderful
<mterry> jdstrand, so I approved the bug.  I'd say in future, especially since you're a MIR member, such marginal things can be JFDI.  Full MIRs should still be double-checked, but it seems the rest of Ubuntu isn't as concerned about binary promotions as I thought they were.  :)
<jdstrand> mterry: works for me. I didn't want to do anything untoward is all :)
<jdstrand> mterry: thanks!
<hallyn> hey, i'm looking at bug 793070, which is fix released for dialog;  but dialog on my precise boxes still shows up in universe
<ubottu> Launchpad bug 793070 in im-config (Ubuntu) "[MIR] im-config and dialog" [Undecided,Fix released] https://launchpad.net/bugs/793070
<hallyn> I assume I shouldn't file a new MIR (as I was just about to do), but is there something else I should do, or will this happen automatically now?
<dobey> hallyn: i guess with the next upload to the archive, it will end up in main rather than universe when published?
<hallyn> dobey, ididn't realize it had to wait for that.  Is there some way to *verify* where it will go on next update?
<dobey> hallyn: well, the last comment in that bug suggests that it will go into main
<jelmer> FWIW, the MIR for subunit was accepted and marked fixreleased too, but it never made it into main (not even after a new upload)
<hallyn> dobey, ok, thanks.
<micahg> jelmer: something needs to depend on it to bring it in (this + MIR usually prompts the promotion)
<jelmer> micahg: ahh, thanks
<micahg> jelmer: and if you don't need the explicit depends, it should be added to the supported seed
<jelmer> micahg: and here I was, not wanting to build-depend on it until it made it into main.. :-)
<micahg> ah, yeah, build-depends will do it :)
<micahg> jelmer: without it being used/seeded, it shows up on one of the reports as a candidate for demotion
<hallyn> yes, that's good to know, i would've been waiting too :)
<broder> slangasek: fyi, just noticed that nthykier added a data.tar.xz-member-without-dpkg-pre-depends tag to lintian, so we'll pick that up next time i do a full lintian run (probably in a week or two)
<roaksoax> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev
<SpamapS> Daviey: --disable-debug dropped 9k ... down to 133k for the udeb ..
#ubuntu-devel 2011-11-22
<SpamapS> Hmm.. do we need NLS in the wget udeb? that would be another 3k down..
<cjwatson> SpamapS: we shouldn't
<SpamapS> cjwatson: right, BB doesn't have any either by the looks of it
<SpamapS> cjwatson: since I have you here, how do you feel about -Os ? I've never used it.. but it did drop nearly 20kB off the code size (and 10kB off the udeb size) for wget
<cjwatson> SpamapS: *shrug*
<cjwatson> SpamapS: we use it in a few places in d-i I think
<SpamapS> cjwatson: ACK. uploaded a new wget with as many disables and optimizations as I could find in 2 hours.
<SpamapS> cjwatson: from 159K to 130K
<cjwatson> better than nowt
<SpamapS> cjwatson: note that the rebuild just with precise's toolchain raised it from 152K to 159K
<slangasek> broder: cool :)
<An-iSociaL> whatup! ubuntu is booted with xdesktop on my Motorola Xoom!
<pitti> Good morning
<TheMuso> Morning pitti.
<An-iSociaL> mornin
 * SpamapS takes a deep breath and uploads mysql 5.5
<broder> bdrung: fyi, it looks like bug #808767 no longer affects the lintian build; i can build 2.5.4 on precise-i386 without error
<ubottu> Launchpad bug 808767 in binutils (Ubuntu) "objdump --only-keep-debug cause the resulting binary to be statically linked on i386 arch" [Medium,New] https://launchpad.net/bugs/808767
<dholbach> good morning
<pitti> hm, today's images grew by 8 MB
<sladen> pitti: KDE update last night/
<pitti> no, Ubuntu's
 * pitti checks
<pitti> == Added packages ==
<pitti> libicu48 (8.1 MB)
<pitti> ah, there we go
<pitti> libicu44 still has a few rdepends
<pitti> also, it was only 7 MB
<pitti> but at least the bulk of it will resolve itself with NBS
<micahg> pitti: can I get you do 2 PPA copies for me
<pitti> micahg: beer accepted
<pitti> micahg: sure, which?
<micahg> pitti: ubuntu-mozilla-security, firefox 8.0+build1-0ubuntu0.11.10.3 to ubuntu/primary oneiric (Security) and firefox - 8.0+build1-0ubuntu0.11.04.3 to natty-security
<pitti> micahg: done
<micahg> pitti: thanks :)
<hadess> somebody tell diwic to stop creating surveys for software he doesn't maintain
<sladen> pitti: has there been a recent upload to xdg-user-dirs?  bug #893526  has just been filed by a user.  We've seen it before as bug #209513 but what concerns me this time around is wanting to rename ~/./ to ~/Public/  (ie move folders between different levels)
<ubottu> Launchpad bug 893526 in xdg-user-dirs (Ubuntu) "Post login shows dialogue to rename homedir to homedir/Public" [Undecided,New] https://launchpad.net/bugs/893526
<ubottu> Launchpad bug 209513 in xdg-user-dirs (Ubuntu) "After upgrade, "Update standard folders to current language" threatens to rename your home folder" [Undecided,Confirmed] https://launchpad.net/bugs/209513
<pitti> this question also happens if you change your locale
<pitti> sladen: last upload was mid June
<cjwatson> pitti: icu> yep, remaining unuploaded piece in main is libreoffice; see last night's conversation ...
<pitti> cjwatson: right, seems fine; just wanted to make sure it's not something less transietn
<pitti> and yay typing
<sladen> pitti: the user claims not to have
<pitti> slangasek: is that oneiric or precise? might be a lightdm change
<pitti> slangasek, TheMuso: uploaded GTK 3 multiarch-ification, FYI
<pitti> TheMuso: so you can probably re-enable it in at-spi again, too
<seb128> do we need to file rm bugs for sources that got dropped from debian because they are deprecated and non maintained and buggy?
<seb128> or is somebody looking at those and mirroring the action in Ubuntu every now and then? (looking at pessulus in this case)
<pitti> occasionally; that's "process-removals"
<pitti> seb128: so, no need to file them now
<pitti> in fact, I'll take a run through this
<seb128> pitti, ok, thanks
<pitti> Riddell: libkipi was removed from Debian (debian bug 615579), with "taken over by kdegraphics from kde4"; but we still have rdepends
<ubottu> Debian bug 615579 in ftp.debian.org "RM: libkipi -- ROM; obsolete, taken over by kdegraphics from kde4" [Normal,Open] http://bugs.debian.org/615579
<pitti> Riddell: should we follow suit, or keep the sourrce?
<Riddell> pitti: let me investigate
<Riddell> upstream aren't entirely consistent there
<Riddell> pitti: libkipi has indeed been merged into kdegraphics but now kdegraphics is released as separate split tars so we have libkipi again, so please keep it
<pitti> Riddell: ah, ok; so eventually Debian will do the same, I figure
<pitti> Riddell: thanks for checking!
<Riddell> right
<pitti> cjwatson, mterry: I think I fixed the libgail-3-common induced uninstallability now
<pitti> on powerpc/armel buildds need to catch up
<mterry> pitti, sweet!
<pitti> mterry: just in case you look at precise_probs and want to LART me :)
<mterry> :)
<pitti> in hindsight I should have updated seeds and -meta first, then gtk
<Andy80> hi all
<Andy80> where can I find informations/tutorials about splitting something in multiple packages? (for example: foo, foo-docs, foo-libs, foo-data ecc....). I've given a look at the official packaging documentation but it looks like this thing is not covered (at least on the doc I was reading it wasn't). Thanks!
<SpamapS> Andy80: I'm not sure there are specific guides for that.. but usually you will need to be more explicit with each of the .install/.docs files to specify the package name.. and add sections to the control file for each
 * SpamapS changes gears
<SpamapS> so, I uploaded a merge of mysql-5.5 from Debian experimental and since it is new to Ubuntu, its in the NEW queue. Does it have to pass a full NEW review or am I just waiting for an AA to ack it?
<pitti> SpamapS: as long as it's a sync, we usually just wave it through
<pitti> SpamapS: so if it's a merge, an AA will at least have to do some cursory checks
<SpamapS> pitti: ACK.. so is there anyone I can poke for an expedite? I need to get the libmysqlclient transition rolling. :-P
<pitti> SpamapS: https://wiki.ubuntu.com/ArchiveAdministration#Archive_days says Riddell is the master of the day, but not sure whether that's still current
<Riddell> pitti: actually I'm just doing my first archive duties for many months
<Riddell> SpamapS: what needs doing?
<pitti> Riddell: ah, still know the knobs? :-)
<SpamapS> Riddell: mysql-5.5 .. merge from Debian experimental is in the NEW queue.
<SpamapS> Riddell: I would be most overjoyed if you could give it a high priority. Thanks! :)
<Riddell> SpamapS: then I'll get to it shortly as I do New processing (unless there's a paticular hurry)
<SpamapS> Riddell: next few hours is fine. It will take 2 hours to build, and then I have to start a rather large transition for the new libmysqlclient
<Riddell> that'll be fun :)
<pitti> SpamapS: ugh, ABI change? happy buildd warming :)
<Riddell> SpamapS: you'll probably need to poke me again once it's built then to let the New binaries in
<pitti> Riddell: JFYI, I'm currently running process-removals (man, looong backlog), so if you try to run some tools and you don't get a lock, that'd be me
<pitti> please poke me if you need it
<Riddell> ack
<SpamapS> Riddell: will do. :)
<SpamapS> pitti: what was fun was convincing MySQL upstream that there actually was an ABI change.. they didn't believe it until we showed them the crashes *of their own client software*
<pitti> superm1: ah, I can't push to ~mythbuntu/mythtv/mythtv-fixes -- can you please change ttf-droid to fonts-droid and ttf-liberation to fonts-liberation? (presumably some more fonts, too)
<pitti> superm1: they recently got renamed
<pitti> cjwatson: argh, sorry -- I removed ttf-farsiweb, saw too late that it is used by d-i; it was renamed to fonts-*
<superm1> pitti: can you give me a merge request, i'll sort out the permissions problem later and merge it?
<superm1> (assuming you already made changes locally of course)
<pitti> superm1: not yet, I just saw that I can't push the branch
<pitti> but can do
<slangasek> pitti: multiarchification - whee, thanks :)
<pitti> superm1: https://code.launchpad.net/~pitti/mythtv/font-rename/+merge/83047
<pitti> cjwatson: I pushed the change to bzr, but as I haven't done a d-i upload yet I rather don't try it now without your guidance
<bryceh> pitti, have you heard of anyone having troubles building pbuilder images for precise?  I posted my log at #893700.
<seb128> bryceh, he left for the day but that doesn't seem really pitti specific
<seb128> that maybe something the stable team can help with?
<seb128> i.e cjwatson or mterry
<bryceh> seb128, ok
<mterry> y
<mterry> o
 * mterry looks at bug
<bryceh> heya mterry, I poked around to see if anyone got that same error as I but found nothing; wondering if it's some odd perl conflict
<bryceh> or something particular to the pbuilder version I have installed
<mterry> bryceh, hm maybe cjwatson would know right away, he did the perl transition
<broder> bryceh: debootstrap was having issues with perl
<broder> perl-modules in particular
<broder> cjwatson fixed it with the most recent debootstrap upload to unstable, if you want to grab that
<bryceh> broder, ah that sounds like a plausible suspect
<broder> (as i recall, both the old and new versions of perl-modules were still getting published, and debootstrap couldn't handle it)
<bryceh> broder, ah
<bryceh> hmm, not sure if I can direct pbuilder to pull bits from debian, but sounds like we'll be syncing that in before too long?
<broder> bryceh: you use your own debootstrap, not the chroots
<broder> so you can just install it on your host machine
<broder> err, not host, but ykwim
<bryceh> broder, awesome, it built the precise pbuilder image now, thanks!
<broder> np :)
<SpamapS> Crap.. mysql 5.5 FTBFS on armel
<SpamapS> https://launchpadlibrarian.net/85702840/buildlog_ubuntu-precise-armel.mysql-5.5_5.5.17-4ubuntu1_FAILEDTOBUILD.txt.gz
<SpamapS> /build/buildd/mysql-5.5-5.5.17/sql-common/client_plugin.c:247:5: error: incompatible type for argument 5 of 'add_plugin'
<SpamapS> Guessing this is a common failure
<Sarvatt> SpamapS: http://bugs.mysql.com/bug.php?id=62769
<SpamapS> Sarvatt: nice.. thanks!
<jono> hey all
<jono> is Precise reasonably stable at the moment?
<jono> I am thinking of upgrading
 * SpamapS dist-upgraded a week ago but has yet to reboot
<bryceh> jono, I've just upgraded one system and fresh-installed 3 others
<bryceh> jono, aside from a few assorted glitches (that I think you'd be unlikely to see) it went smoothly
<jono> thanks bryceh
<Thetawaves> WW: Explicitly asked to ignore failures (probably not good)
<Thetawaves> II: New modules (you've been busy, wipe the poop off your nose)
<cjwatson> pitti: fonts-farsiweb> that's fine, thanks - no urgency on an upload, it can go into the next one that's needed for some other reason.  I've committed the corresponding seed change too
<cjwatson> bryceh: oh, yeah, I meant to sync debootstrap from unstable today for that but forgot (something to do with being on holiday maybe ;-) ).  Synced now
<bryceh> cjwatson, thanks.  Should the fix be sru'd, for folks that are doing pbuilder of precise on stable series?
<bryceh> cjwatson, if you can point me at the appropriate patch I can do the sru grunt work on it.
<cjwatson> bryceh: I commented on the bug.  I don't think it will get through the SRU process before the archive is changed such that it goes away on its own
<bryceh> cjwatson, ah ok
<cjwatson> bryceh: http://anonscm.debian.org/gitweb/?p=d-i/debootstrap.git;a=commitdiff;h=0fbf86aa8fbcd06cb62fddddcfd4605fef2ee8b2 if you want, though
<cjwatson> I could put it in -backports, that would be quicker
<cjwatson> (after this sync publishes)
<bryceh> cjwatson, ah that's not a bad idea
<bryceh> cjwatson, I'll wontfix the natty/oneiric tasks unless you think there's any chance that this could recur such as when q-series opens?
<cjwatson> at the very least it will recur at each perl transition
<broder> cjwatson: :-/ i recognize that we can move packages faster through -backports, but i'm not super thrilled about using backports for bugfixes
<jtaylor> has someone looked at backport sphinx 1.07?
<broder> jtaylor: bug #?
<jtaylor> none yet
<broder> then probably not :-P
<jtaylor> I'm asking first, not that I do duplicate work
<Laney> everything ought to be on bugs
<jtaylor> would be quite useful for some python pacakges using dh_sphinxdoc
<broder> searching the ubp project, i see bug #256017 and bug #291825, both of which should be killed off at this point anyway
<ubottu> Launchpad bug 256017 in Hardy Backports "Please backport python-sphinx 0.4-1 from intrepid to hardy" [Wishlist,Incomplete] https://launchpad.net/bugs/256017
<ubottu> Launchpad bug 291825 in Hardy Backports "please backport sphinx 0.4.2-1 from Intrepid to Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/291825
<broder> but nothing recent
<jtaylor> k thx
<broder> jtaylor: i'd encourage you to play with requestbackport in ubuntu-dev-tools, either from precise or from ppa:udt-developers/daily
<tumbleweed> broder: oh, I never added existing backport searching to requestbackport
<broder> tumbleweed: yeah, but i'm slowly ramping up to encouraging people to always using it for opening new bugs anyway
<cjwatson> broder: Well, it's not so much that as that historically I've kept debootstrap up to date in -backports anyway because lots of people want the new scripts symlink
<broder> cjwatson: i thought we sru'd those...
<cjwatson> Somebody started SRUing them without asking me first
<cjwatson> I'd already been backporting them for some time before that
<Laney> i only see it in updates for lucid
<broder> heh, ok. i have no problem if there's precedent
<cjwatson> So basically it's a mess
<cjwatson> Alternatively somebody could upload the relevant bits of KDE to make perlkde buildable and then the problem will go away for now :-)
<cjwatson> In principle perl transitions should be completeable in about two or three days; less if we had good enough tools to stage them somewhere
<Laney> It does seem more appropriate to cherry-pick that fix for SRU, but I recognise that it may be more work than it's worth. So I'm happy with carrying on keeping debootstrap more-or-less up to date in backports..
<Riddell> I am in the proccess of merging and uploading large parts of KDE so it should happen soon
<cjwatson> it's just smokekde and okular I think, if I can convince you to prioritise :-)
<Riddell> I'll see what I can do
<cjwatson> cool
<TheMuso> pitti: Thanks./
<jtaylor> cjwatson: you merged svn last, are you considering fixing bug 881862 in oneiric?
<ubottu> Launchpad bug 881862 in subversion (Ubuntu) "svn up Segmentation Fault" [Undecided,Triaged] https://launchpad.net/bugs/881862
<jtaylor> it would be shame when the good triaging of the reporter goes to waste
<jtaylor> the issue should be fixed in precise with the merge
<RainCT> pitti: Hey. Any idea why the Traceback of bug #760111 & dupes show "/home/username" (ie. with "username", literally) as the path?
<ubottu> Launchpad bug 760111 in zeitgeist (Ubuntu Precise) "zeitgeist-daemon crashed with OSError in makedirs(): [Errno 13] Permission denied: '/home/ubuntu/.local/share/zeitgeist'" [High,Triaged] https://launchpad.net/bugs/760111
<seb128> RainCT, some users consider their login name to be private info, apport replace it for privacy reasons
<RainCT> seb128: it's still in the bug titles, though
<seb128> "bug" ;-)
<seb128> the intend is to hide it
<seb128> the title case was not considered I guess
<RainCT> seb128: Okay, thanks for the info. So it's not XDG_HOME being messed up or something :P
<seb128> no it's not ;-)
<seb128> "    def anonymize(self):
<seb128>         '''Remove user identifying strings from the report.
<seb128>         This particularly removes the user name, host name, and IPs
<seb128>         from attributes which contain data read from the environment, and
<seb128>         removes the ProcCwd attribute completely.
<seb128>         '''
<seb128> "
<seb128> RainCT, ^ that's what apport is doing basically (that's from report.py in the apport source code)
<bdrung> broder: k, synced
<szymon_g> hi
<szymon_g> hm... why does ubuntu have 2 installation-cd: "desktop" and alternate? wouldn't it be easier to keep it on one (since space isn't that big problem- it will be to big for cd anyway...)?
<penguin42> szymon_g: Don't forget the desktop is also a live cd
<RAOF> szymon_g: You don't need both the alternate and desktop installers; they're two different ways to arrive at the same installed system.
<szymon_g> penguin42, yes, i know. i wonder- why they are seperated: on the start of system /when you choose like "check cd for defects" "check memory" etc etc/ someone could choose: either livecd /and maybe simple install from it/ or "advanced" way- i.e. textual installer, with lvm/raid etc
<szymon_g> so it would be easier for some people /like me: no need to get 2 images: livecd for checking how unity has been changed + alternate for installing on lvm/raid/
<TheMuso> szymon_g: That used to be available in the DVD version.
<szymon_g> "used to be" :?
<szymon_g> was dvd ceased?
<TheMuso> As of oneiric, I believe the DVD version in that form is no longer available.
<RAOF> They're separated because you can't fit both of them on the same CD.
<TheMuso> There is still a DVD version, but its a live system only, and much smaller.
<szymon_g> RAOF, but the next ubuntu wont be on CD either
<RAOF> It will be if it fits :)
<szymon_g> and textual installer + lvm/raid support wont occupy much space
<TheMuso> Yes it will actually, you need all the debs of the system to be installed.
<szymon_g> RAOF, i heard rumors that it will be approx 750mb o.O
<RAOF> Yes, it will.  it will occupy 700 MB of space. :)
<RAOF> There is essentially nothing shared between the livecd and the alternate installer.
<szymon_g> so- are there any chances to introduce lvm/raid configuration in livecd installer?
<RAOF> Of course.
<RAOF> It's a long-standing feature request.
<TheMuso> But not a priority afaik.
<RAOF> I don't think that anyone's currently working on it, but if you wanted to I don't know of any reason why good patches wouldn't be accepted.
<szymon_g> RAOF, i'm just asking. my only programs were "hello world" in C. the most beautiful 32 lines of code you could ever see
<szymon_g> ;)
 * Frostbite pats szymon_g
<szymon_g> :) btw, is anyone working on delta-deb?
<szymon_g> it's huge bandwith saving /my record is 96% of savings/
#ubuntu-devel 2011-11-23
<cjwatson> jtaylor: I only merged subversion to get through the perl 5.14 transition; I have to admit it's a pretty long time since I looked at the subversion codebase non-trivially
<infinity> cjwatson: The patch referenced in the bug is pretty trivial.
<infinity> cjwatson: The setup required to verify it is significantly less so, however. :/
<infinity> cjwatson: (Otherwise, I would have just done the SRU upload when I saw mention of it earlier)
<doomrobo> Hi, how exactly are program arguments passed to **argv?
<psusi> vanhoof, ping
<dobey> doomrobo: that's a rather vague question; and this probably isn't the channel for it. this channel is more about packaging in ubuntu
<doomrobo> ok, I've already tried ##linux, ##friendly-coders, and ##c in that order. I'm not sure where else to ask
<doomrobo> I haven't found *any* hard docs for this
<dobey> doomrobo: well, i'm not sure what you're trying to do exactly, but i can at least now guess that you want to do it in C, as opposed to some other language :)
<doomrobo> I don't want to do anything, per sei, I just want to know how the argument list gets into **argv when I run a program from the command line.
<doomrobo> on another note: how should I get started developing Ubuntu if I know C and C++ and I like to program and solve problems?
<dobey> doomrobo: for that you could search through the bugs filed against packages written in those languages, and work with ubuntu developers and upstreams, to fix them
<dobey> or find a bug that annoys you and fix it; or write some type of application that would be useful to the greater ubuntu community
<dobey> there are lots of ways to do that :)
<dobey> for the argument handling question, it's OS-dependant, but you might want to look at the POSIX section on command line handling, for specifics on how it generally works on most of the OSes you probably care about
<doomrobo> thank you
<ajmitch> doomrobo: something like http://linuxgazette.net/issue84/hawk.html might explain how the pieces work together
<doomrobo> ajmitch, THANK YOU! It's in sys_execve()!
<SpamapS> oi.. 6 hours and counting on mysql build on armel.. :-P
<doomrobo> and...error missing semicolon
<achiang> './usr/share/doc/libqt4-network/LGPL_EXCEPTION.txt' is different from the same file on the system -- known issue in precise?
<achiang> Errors were encountered while processing:
<achiang>  /var/cache/apt/archives/libqtgui4_4%3a4.7.4-1ubuntu3_i386.deb
<achiang> someone else already filed it, i guess: #893832
<achiang> and #893826 is essentially the same thing
<pitti> Good morning
<pitti> RainCT: that's quite deliberate; we anonymize username, hostname, cwd, etc.
<pitti> RainCT: thanks for pointing out, I filed that as bug 893863
<ubottu> Launchpad bug 893863 in apport (Ubuntu) "Standard bug title does not get anonymized" [Medium,Triaged] https://launchpad.net/bugs/893863
<SpamapS> argh.. arm builds fine.. now amd64 failing some insanely complex test
 * SpamapS curses mysql-5.5
 * pitti pats SpamapS on the back and hands him another bucket of patience
<dholbach> good morning
<tjaalton> anyone using sbuild/schroot? even if the chroot has a correct resolv.conf, it fails to resolv hosts on the local dns (which is the default)
<tjaalton> so i can't use my local mirror for builds
<tjaalton> wondering what's wrong with it..
<infinity> tjaalton: I certainly have no such issues with chroots...
<cjwatson> Nor I
<tjaalton> hmm, ok. must check my configs then
<cjwatson> Wrong nsswitch.conf or something?
<tjaalton> nsswitch.conf looks fine
<infinity> Define "resolve hosts on the local dns".
<infinity> Are you resolving FQDNS, or short hostnames?
<tjaalton> FQDNS
<tjaalton> sources.list has my mirror (and a.u.c) on it
<infinity> And you're positive the right IP for your nameserver is in resolv.conf?
<tjaalton> yep
<infinity> And said nameserver allows requests from said machine? :P
<tjaalton> using plain chroot seems to work fine
<infinity> Oh, that's even stranger.
<tjaalton> it's the same machine
<tjaalton> :)
<tjaalton> do-it-all monster
<infinity> There should be no functional difference between schroot and chroot, from the POV of name resolution.
<infinity> Unless someone's done something very hackishly evil.
<debfx> is dh_builddeb supposed to call dpkg-deb in the order of the packages in debian/control?
<tjaalton> uh oh
<tjaalton> so the chroot actually had the wrong hostname on sources.list..
<tjaalton> duh
<tjaalton> :P
<infinity> tjaalton: *slow clap*
<debfx> it doesn't do so causing pkgstripfiles to symlink doc files nondeterministically which breaks multi-arch
<tjaalton> infinity: :)
<tjaalton> actually no, the chroot only has a.u.c, so it's defined elsewhere.. but anyway
<debfx> pitti: ^
<infinity> cjwatson: Are you still merging P-a-s from Debian on a regular basis?
<cjwatson> infinity: now and again at least - why?
<infinity> cjwatson: I've been led to believe some armhf bits landed upstream recently, and it would be shiny if we had those before I go and create a bunch of build records.
<cjwatson> I just merged, no armhf stuff there yet
<cjwatson> unless it was VERY recenet
<infinity> lool may have misled me.  Looking. :P
<cjwatson> not seeing anything in git
<infinity> cjwatson: I'm seeing armhf stuff added and then removed (as entire entries were removed) in git. :P
<cjwatson> yeah
<infinity> cjwatson: And still some things that look wrong.  Though maybe for packages I don't care about.
<cjwatson> you could just land them in the Ubuntu branch for now if you're in a rush
<infinity> (gpart springs out)
<infinity> Yeah, I might do so tomorrow.
<infinity> Or, rather, "right before I create build records". :P
<infinity> I wonder if this is still accurate:
<infinity>  %wvstreams: !armel                                     # no working getcontext()
<infinity> Meh.  I'll look again when it's not 3:30am.
<ogra_> its 3:31 now
<ogra_> or even 33 :P
<infinity> ogra_: Helpful.
<pitti> debfx: do you see an actual package which breaks due to different symlinking? pkgbinarymangler already has some checks for this
<pitti> debfx: and the linking direction is quite predictable in all practical cases that I've seen; it wouldn't be for circular dependencies, though (which are rare fortunately)
<debfx> pitti: bug #893826
<ubottu> Launchpad bug 893826 in qt4-x11 (Ubuntu) "package libqt4-xmlpatterns 4:4.7.4-1ubuntu3 failed to install/upgrade: ErrorMessage: './usr/share/doc/libqt4-xmlpatterns/LGPL_EXCEPTION.txt' is different from the same file on the system" [High,Confirmed] https://launchpad.net/bugs/893826
<pitti> debfx: ah, thanks; will have a look
<lool> cjwatson, infinity: The armhf stuff was merged into Ubuntu some weeks ago; I had already poked cjwatson about it back then, and P-a-s was up-to-date
<lool> cjwatson, infinity: http://lists.debian.org/debian-arm/2011/10/msg00047.html
<infinity> lool: It's just that, entertainingly, the string armhf doesn't show up anywhere in P-a-s. ;)
<lool> the patches were merged and then Colin merged P-a-s
<debfx> qt4-x11 has a circular dependency libqt4-dbus <-> qdbus but these packages don't seem to be involved
<lool> infinity: Which is good  :-)
<infinity> lool: Not really, given that armel does...
<lool> infinity: The reason is that when packages got reviewed, the likely outcome was to remove them from P-a-s entirely
<lool> infinity: Because it's preferred to document these things in the Source package itself nowadays
<lool> infinity: So whenever the Source package was correct and P-a-s wasn't, I've asked for the entry to be removed
<infinity> lool: I see lots of armel in P-a-s.  Those entries won't get build records on armhf.
<lool> infinity: I think I reviewed all of the Debian entries in my debian-arm@ email; I didn't check the Ubuntu one, but differences were minimal
<lool> infinity: Some of them truly need porting, some of them are old cruft that we don't need to worry about
<lool> 2 or 3 I couldn't test
<infinity> lool: Kay, but some of them weren't removed (kexec-tools, for instance)
<infinity> lool: But I'll just mangle the Ubuntu branch for now.
<lool> infinity: Debian lacks armhf in control, I've filed a bug to remove the P-a-s entry
<infinity> lool: linux-wlan-ng, etc, etc.
<cjwatson> jamespage: hey, did you get anywhere with converting libcommons-discovery-java back to ant?
<lool> infinity: Debian #645652 + Debian #645675
<ubottu> Debian bug 645652 in kexec-tools "Please add armhf to Architecture list" [Wishlist,Open] http://bugs.debian.org/645652
<ubottu> Debian bug 645675 in buildd.debian.org "[p-a-s] misc armhf updates" [Wishlist,Open] http://bugs.debian.org/645675
<jamespage> cjwatson:  not yet - will look today
<infinity> lool: Sure.  But open bugs aren't quite the same as your claim that it was all merged. ;)
<pitti> cjwatson: d-i i386 failed to upload due to a "connection timed out" (WTH); I'll retry, ok?
<lool> infinity: I will poke pkern on the latter bug; I thought he had applied them, but he only applied the other bugs' patches
<infinity> lool: Like I said, I'll just fix it up locally for now.
<lool> infinity: pkern merged a bunch of fixes already, I hadn't realized he had left one open with 9 patches
<infinity> I probably should ask pkern for P-a-s commit access back, but it's been rather freeing not having to maintain it for a couple of years. :P
<lool> I poked him
<cjwatson> jamespage: thanks
<cjwatson> pitti: yes please
<pitti> debfx: oh, seems the Depends: field differs on i386 and amd64 then? as it goes in that order
<pitti> debfx: but anyway, I'll sort it before, to ensure predictability
<lool> infinity: outside of kexec-tools, which I've uploaded with armhf in control and for which I've updated Ubuntu's P-a-s now, do you have other packages of concern?
<infinity> pitti: You could still run into cases where you symlink to a package that doesn't exist on all arches...
<infinity> lool: I was just looking at "grep armel P-a-s"
<pitti> infinity: right, but that doesn't seem to be the case here
<cjwatson> I thought dpkg-gencontrol already sorted dependencies these days
<infinity> lool: Pretty much everything there (except for the d-i kernels) is a cause for concern, though some are clearly less interesting.
<infinity> pitti: No, but it's still a potential breakage.
<cjwatson> maybe only partially or in some cases
<infinity> pitti: I'm wondering how sane this "symlink to save space" thing is, when combined with multiarch's sctrict requirement of sameness across arches.
<lool> infinity: Seriously?  they all seem boring to me; I see fpc and qemu-kvm as potential issues for our images
<infinity> lool: Uhh.  Boring?
<lool> infinity: Yeah, irrelevant things for armhf hardware
<infinity> lool: We don't tend to refuse to build packages because they don't excite you. :P
<pitti> infinity: well, so far it kept up quite well; it already skips cases like "arch: any to arch: all dependency"
<lool> and definitely not on the critical path to building the archive, but I might have missed the goal
<infinity> lool: The goal is correctness.
<lool> sure, eventually it will be correct; the patches will get merged and packages will be fixed  :-)
<cjwatson> lool: it's good to get P-a-s right early, as if we fail to do so then we have to reupload packages to get build records created for them
<debfx> pitti: the order of the dependencies is the same but on i386 pkgbinarymangler has already processed libqt4-network before libqt4-xmlpatterns
<infinity> cjwatson: Not technically true, mind you. ;)
<lool> yup, but the said number of packages is small and they aren't relevant to our images and most of the time to our users
<infinity> cjwatson: But that seems to have been the annoying status quo for a few years.
<pitti> debfx: ah, I see
<cjwatson> infinity: in practice, though - the last time I asked the Soyuz people to do it otherwise, they ummed and ahhed and eventually told me it was easier to reupload
<cjwatson> infinity: speaking of annoying reuploads, please to be making sure that we start out with current imagemagick and icu as well as perl :-)
<cjwatson> oh, and ocaml
<infinity> Any other transitions? :P
<cjwatson> ghc, exiv2, libjpeg; and mysql is due to start soon
<cjwatson> I think that's about it
<infinity> Yeah, I've noticed libjpeg.  And aren't we about to do it again?
<pitti> meh, d-i hates me
<pitti> the first time it built fine on i386 and failed to uploaod
<infinity> Though, I guess ljt is meant to be a drop-in replacement for lj8
<pitti> the retry now fails to build
<pitti> "Disk full"
<cjwatson> they claim that libjpeg-turbo matches libjpeg8's ABI, so I've told them that they should just make it build the same binary package; I don't want another transition for no reason
<cjwatson> ah, that would be a kernel change
<cjwatson> leave it with me
<infinity> cjwatson: Any word on when the mysql bit's meant to land?
 * infinity is tempted to P-a-s out mysql until it does, to avoid wasting the cycles.
<pitti> infinity: mysql> how do you mean? it built on all arches, and is in NEW
<infinity> pitti: Ahh, I was going with Colin's "mysql is due to start soon".
<infinity> pitti: I guess very soon, then. :P
<cjwatson> SpamapS seemed to be having build problems last night?
<pitti> https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.17-4ubuntu2 looks fine
<Laney> there was an upstream patch that got cherry-picked
<cjwatson> but yeah, it's built everywhere now
<pitti> but I saw the "argh amd64 test failure" as well, not sure
<pitti> maybe he retried
<pitti> amd64 "Started 3 hours ago" -> looks like it
<pitti> "Retry this build", aka. "the knob of desperation"
<infinity> pitti: There is no way that I can make "knob of desperation" not sound filthy right now.
 * infinity thinks it might be time for sleep.
 * ogra_ sees pitti rarely does arm ... for us its often the "knob of relief" 
 * cjwatson chokes
<infinity> ogra_: And "knob of relief" is even worse...
<Laney> ahem.
<ogra_> *g* sorry :)
 * pitti sticks fingers in his ears, sings LALALA and goes back to real work
<lool> infinity: I merged the remaining armhf changes that Debian hadn't merged; the remaining packages need to be looked at before enabling (see notes on debian-arm)
<jamespage> cjwatson: libcommons-discovery-java build system switched and uploaded - should clear down component-mismatches significantly
<cjwatson> jamespage: yay
<lool> cjwatson, infinity: Merged latest P-a-s changes from an hour ago that Phil pushed; he had missed the last bug in the BTS noise; also enabled qemu-kvm on armhf since Debian and Ubuntu differ on the qemu/qemu-kvm/kvm/qemu-linaro packaging here
 * cjwatson works on fixing the php5 build failure and feels dirty
<lool> <??>
<nigelb> didrocks: Man, you've been working hard today!
 * nigelb just saw MPs on Tarmac :)
<didrocks> nigelb: heh, I just push all the work that I needed for the unity integration :)
<nigelb> :)
<smoser> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev, smoser
<cjwatson> ev: are you really still patch piloting? :)
<ev> oops!
<ev> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
<SpamapS> cjwatson: indeed, looks like that test just has a short timeout.. I may need to raise it if we see buildd failures again.
 * SpamapS does the happy dance and prepares to start the rebuilds.. only 2 days late. :-P
<cjwatson> heh, I'm just uploading php5 right now
<cjwatson> I guess that will need another rebuild?  needed to fix the build failure though
<SpamapS> Was it failing because libmysqlclient is multiarch now?
<cjwatson> yes, I fixed that
<SpamapS> If so, then you sir have saved me half a day. :)
<cjwatson> oh, we need to process mysql-5.5 through NEW don't we
<SpamapS> binary new's probably haven't passed yet
<SpamapS> forgot about that
<cjwatson> would it make sense for me to c-c this php5 upload until mysql-5.5 is NEWed?
<cjwatson> speak now if soo
<cjwatson> *so
<cjwatson> I think it will, so I've interrupted the upload
<SpamapS> yes it would
 * cjwatson goes to process NEW
<SpamapS> hmmm maybe somebody already did?
<SpamapS> I only see translations
<cjwatson> they're still in NEW
<cjwatson> translations go with the binary uploads
<cjwatson> accepted now
<cjwatson> SpamapS: you should be able to start uploads in about 20 minutes.  I'll tell you when
<SpamapS> cjwatson: ok that should give me time to eat breakfast. :)
<nigelb> pitti: The Apport retrace sounds handy! :-)
<pitti> thanks :)
<cjwatson> SpamapS: you can start now
<cjwatson> SpamapS: I'll upload php5 now - it's at level2, but only because of cyrus-sasl2 and I've checked that that doesn't matter here
<hallyn> Jinkeys, powertop claims multitail really sucks power.
<SpamapS> cjwatson: thanks, will start uploading shortly
<SpamapS> cjwatson: php5 failed because of missing libmysqlclient_r .. will fix that (its a deprecated library as of 5.5)
<cjwatson> yeah, I saw that - please do, thanks :-)
<cjwatson> silly me for only test-building with 5.1
<pitti> skaet: can I send my release report tomorrow morning? tl;dr is "no breakage" :)
<SpamapS> hrm.. not having libmysqlclient_r seemed like a good idea at the time.. but I think I may need to add it back in ... <sigh>
<cjwatson> SpamapS: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html - oof
<cjwatson> what went wrong there, I wonder
<Laney> would be nice if it said why they were uninstallable
<SpamapS> cjwatson: not sure, I've been testing installing them.. looking into it now
<cjwatson> Laney: would be nice if it knew, yes
<SpamapS> cjwatson: need to do another upload of mysql-5.5 to restore libmysqlclient_r ..
<cjwatson> that's output from britney, it's not very informative
<cjwatson> SpamapS: let's see what this is in case it can be fixed at the same time
<Laney> oh, britney output
 * Laney backs away slowly
<SpamapS> cjwatson: indeed
 * cjwatson updates a relevant chdist tree
<cjwatson> Laney: my thoughts exactly
<cjwatson> hmm, can't reproduce in chdist
<cjwatson> SpamapS: let's not worry about this for now, if chdist doesn't show it up it's probably transient somehow
<cjwatson> or britney being confused, although that's IME extremely rare (in fact I can't remember a case where that was true)
<SpamapS> I don't see those packages on archive.ubuntu.com yet...
<cjwatson> I just moved that code to a different machine so maybe that's at fault somehow
<cjwatson> it has a special back door
<SpamapS> ahh
<SpamapS> of course it does ;)
<cjwatson> rsyncs directly off ftpmaster
<mterry> barry, do you know much about zope?
<SpamapS> cjwatson: installing the deps manually in the right order seems to work in a precise chroot tho
<cjwatson> ah, you know, I think this actually is britney being wrong!
<barry> mterry: a bit
<cjwatson> I believe it's confused by there being multiple versions of mysql-common in Packages
<barry> mterry: what's up?
<SpamapS> cjwatson: I'd have thought that wouldn't happen
<mterry> barry, zope2.12 is FTBFS because it is currently demanding python2.6 (which was the supported version at time of release).  It builds if I change it to python2.7, but I'm not sure how likely that is to be safe run time wise.  Any ideas?
<cjwatson> SpamapS: relatively recent intentional LP change, to smooth out architecture skew
<barry> mterry: the what's new in zope 2.13 says it's added explicit support for 2.7
<mterry> barry, yeah, but the source package itself is "zope2.12" and 2.13 isn't packaged yet in Debian
<smoser> jamesh, were you going to merge https://code.launchpad.net/~cldunlap1/ubuntu/natty/mountall/fix2-for-805509/+merge/78135 ?
<smoser> or were you expecting something back.
<smoser> i can just mkae your two suggested changes, merge them and upload to precise.
 * SpamapS wonders if mysql's developers have *ever* used shared libraries..
<SpamapS> lrwxrwxrwx root/root         0 2011-11-23 08:52 ./usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18.0.0 -> libmysqlclient.so
<SpamapS> >:|
<mterry> barry, I suppose I could try to see if they applied a big "2.7 support" patch in their VCS and use it if so.  But I doubt it will be so easy
<barry> mterry: hmm.  you might pop over to #launchpad-dev and ask flacoste, gary_poster, or benji.  they probably know more detailed specifics on 2.7 support
<barry> mterry: right, probably not.
<mterry> barry, OK, thanks
<barry> mterry: let me know how it goes!
<skaet> pitti,  ok by me.
<smoser> mpt, could you maybe comment on https://code.launchpad.net/~cldunlap1/ubuntu/oneiric/xchat/fix-for-816506/+merge/80118 ? it seems that barry's logic is sane , but you are called out by name.
<mterry> barry, gary_poster pointed me at some email addresses, which I'm following up on.  will let you know
<cjwatson> so the problem is definitely that britney is selecting the earlier version of mysql-common
<cjwatson> I'm working on untangling that
<SpamapS> cjwatson: about ready to upload another version of mysql-5.5.. sounds like I don't need to hold off?
<cjwatson> SpamapS: go for it, this is purely a reporting bug
<cjwatson> to my amazement
<SpamapS> cjwatson: ok, test rebuild almost complete then I'll push it up
<SpamapS> hopefully I won't have to retry amd64 twice again
 * SpamapS ponders disabling the test
<cr3> if I package a python project that needs python-dev in buil-depends and I use makefile trickery in debian/rules (PYTHON_VERSIONS=$(shell pyversions -r); build-stamp: $(PYTHON_VERSIONS:%=build-ext-%)...), what happens if there are two versions of python installed, like 2.6 and 2.7 for example?
<cjwatson> that would cause both build-ext-2.6 and build-ext-2.7 targets to be built
<cr3> cjwatson: would python-dev be installed in the build environment for the corresponding version?
<cjwatson> you should depend on python-all-dev for that
<cjwatson> er, build-depend
<cr3> cjwatson: ah, and I guess I should also depend on python-all instead of just python. I didn't know about that magical package, thanks!
<smoser> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * smoser probably owes dholbach more piloting time. 
<Daviey> smoser: you owe it to yourself :)
<cjwatson> SpamapS: I am victorious
<cjwatson> SpamapS: (reporting bug fixed)
 * SpamapS annoints cjwatson with oil
<SpamapS> might want to avoid open flames for a while
<dantti> cnd: I found out how to probe the info from the trackpad (using the packateLogger),  I'm trying to test it now..
<mpt> smoser, done
<cnd> dantti, great!
<cnd> just this past week someone else has posted patches on linux-input for getting power from hid devices
<cnd> once you get the data, it may make sense to use that framework too
<dantti> cnd: yes, I saw it, first I tought it would grab the data it self, but it seems just to be a framework for that..
<dantti> cnd: actually I think I'll have to add a get_feature_report(int id) to the hid-core since it seems that 0x43 is the code to grab features, and OSX sends 0x43 and 0x47 which is the report id of the battery status
<jasox> Does someone know where is configuration files of alt tab in unity ?
<cnd> dantti, it looks to my like the hid battery framework works properly for hid-compliant devices
<cnd> or at least for the patch submitters device
<cr3> is there a way to optionally require a package if it happens to be available? the problem is that python-zope.testrunner was added and breaks some of the functionality of python-zope.testing, the latter is always required but the former only when available on later releases of ubuntu, but I don't want to branch the project on a per ubuntu release basis :(
<cnd> but apple products aren't hid-compliant for multitouch
<cnd> so they may not be for battery either
<dantti> cnd: but the patch does not grab the features values
<cnd> dantti, I think it may be handled by generic hid layer stuff
<cnd> I'm mostly making this assumption based on the submitter's message where he says it is working for him
<dantti> the HID spec says that to grab some feature you should call GetFeature(report_id) and it seems linux hid does not have that..
<cnd> hmm... I dunno
<dantti> well at least the battery stuff seems hid compliant
<cnd> ok
<cnd> have you tried his patch to see if it works magically?
<dantti> yes, and it didn't
<cnd> ok
<cnd> well, it sounds like you're on the right track at least :)
<dantti> now I'm recompiling everything because somehow my patch in magic mouse module to do tests is not loading anymore..
<dantti> cnd: yes, packagelogger said it very clear GET_FEATURE_REPORT , response: batery level 84% and the hex codes...
<dantti> reverse engeneering made easy :P
<cnd> yep
<SpamapS> ahh and more missing files found..
<JLuc> hello
<JLuc> dear ubuntu canonical team : please read https://plus.google.com/u/0/104550365344856778857/posts/ELAYPthqToL
<mterry> Who do I bug about problems with the wiki?   A page just got deleted when I tried to edit it...  I'd like to see if there's a backup somewhere
<sladen> mterry: #is?
<mterry> sladen, I'm in there now, thanks
<sladen> JLuc: you want dpm
<JLuc> i just want to share the linked concern
<sladen> JLuc: https://launchpad.net/%7Edpm/+contactuser
<sladen> JLuc: and it'll go to the person who can look into that, reply and do something about it
<JLuc> ok
<mterry> barry, FYI, the consensus is that zope2.12 and python2.7 should not be mixed (may not directly blow up, but there are security concerns, test failures, and it's just not a supported combo).  Talking to Debian about publishing zope2.13
<barry> mterry: sounds good, thanks
<mterry> jono, how did the Chuck meme start?
<jono> mterry, I took a picture of chuck in front of a golf cart, cut it out and photobombed him
<jono> it went on from there
<ajmitch> poor chuck
<chrisccoulson> lol
<ajmitch> though I haven't seen as many new chuck images in the last couple of days
 * chrisccoulson reminds himself to not get in the way of jono's camera
<mterry> jono, :)
<jono> haha
<zul> its very much to do on my list next time
<infinity> jono: At least it seems to have distracted you from other memes...
<ajmitch> zul: paper bags help
<zul> ill have to find more wham cds
<jono> infinity, lol
<jono> dig!
<jono> ding!
<infinity> There it is.
<jono> :-)
<chrisccoulson> jono, did you ever find out who left you the wham CD at UDS?
 * SpamapS so wishes it was him
<jono> chrisccoulson, I did, Krafty
<jono> and popey left me the Village People one
<seb128> lol
<popey> :D
<popey> http://popey.com/~alan/bargain_bucket.jpg <- sladen rummaging in the bargain bucket for YMCA
<sladen> still don't know anything about the Wham one
<sladen> but for about an hour I did briefly own a Village People CD
<popey> and those pancakes were ace
<dobey> heh
<popey> it was somewhat surreal driving round orlando with sladen with YMCA blaring out
<SpamapS> argh... 5 more hours until mysql 5.5 finishes building on arm.. :-P
<infinity> SpamapS: Aww, pumpkin.
<SpamapS> are we ever going to get like.. real ARM servers?! The thingy we saw at UDS was interesting.. but.. show me the money! :)
<infinity> SpamapS: As a man who's been bootstrapping a new port on the cell phones on his desk, I suspect I'm grumpier than most on that front. :P
<zul> infinity: dude grumpy is default for you
<infinity> zul: Slanderous lies.  I'm both happy and go-lucky.
<zul> infinity: sunshine and rainbows for everyone right?
 * infinity glares congenially.
<zul> heh
<mwhudson> well hey, the work i am doing right now is in the overall effort of "make the kernel work on a15" so ...
<infinity> mwhudson: Imaginary hardware, FTW?
<mwhudson> infinity: yep
<mwhudson> infinity: arm fast models, to be precise
<szymon_g> hi
<TheMuso> .c
#ubuntu-devel 2011-11-24
<shadeslayer_> ogra_: around?
<pitti> Good morning
<pitti> skaet: ah, Leann's mail confused me -- I saw it before leaving for the day, and I thought for a moment it was Thursday already :) so no panic
 * SpamapS rejoices as armel finally finishes building mysql 5.5 and unleashes the buildds on 111 rdeps..
<micahg> spamapS: haven't you already been doing that?
<SpamapS> micahg: unfortunately I got stuck on some silliness with the new cmake build
<SpamapS> micahg: and since it takes 9 hours to rebuild on armel.. that turned into a 3 day problem unfortunately
<micahg> spamapS: right, I'm just saying I've been seeing libmysqlclient rdep rebuilds from you for hours now :)
<SpamapS> micahg: so, there are two libraries.. libmysqlclient, and libmysqlclient_r .. or at least, there were.. and my first 2 uploads were missing libmysqlclient_r compatibility..
<SpamapS> micahg: so I could upload anything that used -lmysqlclient , but not -lmysqlclient_r
<micahg> ah
<SpamapS> Now that my final upload is available on all arches, I can just upload all the rdeps
<SpamapS> This being my first mass rebuild.. I'm surprised at how many packages can't pass 'debuild -S' withut their build-deps installed. :-/
<cjwatson> I use debuild -S -nc for mass rebuilds
<cjwatson> which is OK as long as you're careful to have just fetched a clean source package
<cjwatson> hmm, livefs build failures today
<SpamapS> cjwatson: ahh, which I have been careful at that.. so -nc will be less likely to hit problems with missing makefiles and debhelper bits... interesting
<cjwatson> wait, why are there livefs build failures timestamped 22:48
<cjwatson> timestamp of the web logs is sane; mysterious
<cjwatson> but those aren't the logs I just got mailed!
<cjwatson> oh, could be Chinese edition ones if the fix to their Subject regressed
<cjwatson> anyway, the proper ones just failed too
<cjwatson> aha, NEW
<SpamapS> question.. is libmysqlclient worth a libreoffice build?
<cjwatson> SpamapS: talk with Sweetshark about it; there are a couple of other library transitions involved too
<cjwatson> we may be getting to the point where the answer is yes
<tjaalton> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton
 * SpamapS defers that one
<dholbach> good morning
<SpamapS> ok.. time for actual sleep
<dholbach> SpamapS, sleep tight
<pitti> wgrant, cjwatson: are there known publisher problems again?
<pitti> I can't find out what happened with python-zeitgeist
<pitti> it's built, it's published, it's not in NEW, rmadison and queue on cocoplum have it
<pitti> but
<pitti> $ wget -O- -q http://archive.ubuntu.com/ubuntu/dists/precise/main/binary-i386/Packages.bz2| bzgrep '^Package: python-zeitgeist'
<pitti> $
<wgrant> pitti: More likely to be mirroring issues.
<wgrant> Let's see.
<cjwatson> pitti: I've already fixed it.
<pitti> wgrant: sorry, that's what I meant to say
<pitti> cjwatson: ah, great; OOI, what was it?
<wgrant> What was broken?
<cjwatson> You're an hour too slow, old man :-)
<pitti> didrocks: ^ FYI
<cjwatson> Nothing was broken in Launchpad.  python-zeitgeist was stuck in NEW.
<wgrant> Aj
<wgrant> Ah
<pitti> 09:33:21 didrocks | pitti: it's not a new one
<pitti> 09:33:24 didrocks | was there already
<pitti> didrocks: ^ so apparently it was NEW after all?
<cjwatson> It was NEW as far as Launchpad was concerned.
<pitti> cjwatson: ok, thanks
<didrocks> it's not, it was there, or am I dreaming with another unstable zg version?
 * didrocks checks
<cjwatson> didrocks: Launchpad disagrees with you.
<pitti> anyway, mystery solved, so it was just a race condidtion between me looking and cjwatson NEWing it
<cjwatson> And yes, archive.ubuntu.com may in general be a little bit behind.
<pitti> didrocks: dreaming :)
<didrocks> pitti: cjwatson: argh, you're right, it was in zg-core before, I prepared the split just after oneiric released and so, that's why I didn't see it in the diff I made this morning
<cjwatson> I've kicked off CD rebuilds too.
<pitti> didrocks: https://launchpad.net/ubuntu/+source/zeitgeist/0.8.2-1/+build/2806982 was the previous Ubuntu version and didn't have it; so I assume PPA
<didrocks> pitti: cjwatson: sorry, should take another cup of coffee it seems
<didrocks> thanks for newing it cjwatson :)
<pitti> cjwatson: FWIW, nice that rmadison is now actually faster than archive.u.c.
<pitti> since it stopped lagging for several hours it became even more useful
<cjwatson> heh, yeah
<cjwatson> in fact, I'm setting up chdist on ubuntu-archive@lillypilly
<cjwatson> bored with waiting for a.u.c to update
<cjwatson> most of the KDE chaos on precise_probs.html is due to akonadi build skew
<pitti> cjwatson: oh, does it actually pull from archive? I had assumed syncproxy
<cjwatson> it pulls from ftpmaster
<cjwatson> er, wait, what are you referring to by "it"?
<pitti> eh, nevermind; somehow I read that as "cd image build machine"
<cjwatson> ah, well, that pulls from ftpmaster too
<pitti> with "it" being the local mirror
<pitti> /srv/cdimage.ubuntu.com/ftp/ etc.
<cjwatson> generally I think most of our own processes don't have to wait for syncproxy any more.
<pitti> I just noticed that this sometimes takes up to 10 mins after the hour to pick up a new package
<cjwatson> cdimage will pick it up immediately the publisher has finished; actually even before the publisher has finished
<pitti> ah, is that new?
<cjwatson> typically as soon as the new dists/ is put into place, which is normally around :20
<cjwatson> yes, in the last month or so
<pitti> my last "*nnng* need this now* was probalby around oneiric beta-1
<pitti> ah, sweet
<cjwatson> part of the whole process of streamlining image builds
<pitti> \o/
<cjwatson> I'm hoping we can be on 30-minute publisher runs by the new year
<cjwatson> That is, roughly, December's project
<cjwatson> Wow, build queue depth.  I think that means it's time to go and get the child ready ...
<cjwatson> pitti: Incidentally, you can look at ~ubuntu-archive/mirror/ubuntu/ on lillypilly - that's where rmadison, cron.NBS, etc. get their data now
<cjwatson> And all the reports should be triggered from ~ubuntu-archive/bin/archive-reports.  I'll be moving *-mismatches over as soon as an RT gets processed to let me rsync germinate output too.
<pitti> that's so sweet! much less wasted wood from biting into tables while waiting for an urgent image build
<ogra_> shadeslayer_, i am now
<OdyX> tkamppeter: any news about the re-birth of the foomatic-* tarballs on openprinting.org ?
<EO_> How do you install debugging packages for libasound2, or any package?
<EO_> There's some reference to a 2006 system, but I assume it's been replaced by now
<EO_> oh here we go...
<pitti> apw: bigon says kerneloops.org is dead; should we keep the daemon running and enabled? (and even installed?)
<apw> pitti, hmm i wonder if that was/is hosted at kernel.org
<bigon> pitti: I was planning to orphan it in debian (as the maintainer is MIA)
<pitti> apw: do you know if the project itself is still alive? i. e. not just fallout from teh kernel.org intrusion?
<bigon> ah, well that could explain why the website is dead
<broder> i think bugzilla.kernel.org is still down from that, isn't it?
<broder> so i would have assumed they were just dealing with lots and lots of fallout
<apw> hmm with the rate that things are coming back, if its something we can disable and reenable later if iti comes back, then i suspect that that is the right approach for now
<apw> i've not heard anything personally about the project being abandoned, but things have been strange since the breakin
<EO_> got it!
<pitti> apw: yes, we can disable it easily
 * pitti does so
<pitti> uploaded
<pitti> apw, bigon ^ FYI
<apw> pitti, thanks, that makes sense to me
<bigon> alright, I'll see what to do in debian with that package
<seb128> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton, seb128
 * dholbach hugs seb128
<seb128> dholbach, ;-)
<shadeslayer_> ogra_: nvm, Wanted to talk to you about ARM v6 compiles on ubuntu, but then read your reply on bug 848154 ...
<ubottu> Launchpad bug 848154 in Ubuntu "ARM version not supporting V6 RaspPi" [Undecided,Invalid] https://launchpad.net/bugs/848154
<ogra_> yeah, we dont do v6 since karmic
<shadeslayer_> Kind of torn between your views and the reporters :)
<shadeslayer_> Its a pretty neat oppurtunity imho for students like myself
<ogra_> well, they are free to rebuild the archive on their own or to supply the needed resources to do it in the archive
<shadeslayer_> Yeah, that I agreed with
<ogra_> we wont do it, and ubuntu is switching to armhf over the next two releases
<shadeslayer_> ogra_: http://wiki.qt-project.org/Qt_RaspberryPi/Device_program << Nokia started a Device Program ... which is why I was looking at it
<ogra_> with that v6 wont even be an easy opportunity
<shadeslayer_> Ah ..
<shadeslayer_> ogra_: thanks for your time
<ogra_> np :)
<cjwatson> $ lp-remove-package.py -u $SUDO_USER -m NBS -b -y libperl5.12
<cjwatson> hooray
 * ogra_ applauds 
<dholbach> woohoo
<tumbleweed> tseliot: any plans for having nvidia-cuda-toolkit in Ubuntu (it's in Debian, but due to nvidia packaging differences, can't just be synced)?
 * cjwatson cuts three minutes off cron.NBS runtime
<cjwatson> (3m38s -> 25s)
<cjwatson> (well, for the archive-cruft-check bit)
<tumbleweed> not bad
<tseliot> tumbleweed: right, I should have a look at that. I'll put it on my todo list. Thanks for reminding me
<tumbleweed> tseliot: aha, thanks
<pitti> cjwatson: !
<pitti> today is feature definition freeze; I'd really like to have status.u.c. reset, so that all the trend lines are correct; slangasek, cjwatson, Daviey, apw, jibel: ok for you, too?
<pitti> I don't have access myself, so I'll ask IS to rename the current DB (in case someone still needs it)
<pitti> james_w: ^ do you still have access to this?
<cjwatson> fine by me
<cjwatson> I have two still to approve
<cjwatson> better do that :)
<cjwatson> actually, I think I thought FDF was tomorrow
<pitti> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule says Nov 24
<pitti> and usually all our freezes are on Thursdays
<pitti> anyway, resetting it tomorrow WFM, I'd just like to get it done this week
<cjwatson> oh, yes, I just misread the mail
<pitti> wohoo, https://staging.launchpad.net/! thanks wgrant!
<wgrant> pitti: Ah, great. Hoped it would come back eventually :)
<wgrant> It's on a fresh DB, so it might time out even more than usual for a while as the caches warm up.
<wgrant> Hmm, or not. It's *meant* to be on a fresh DB.
<james_w> pitti, no, just #is I believe
<Daviey> pitti: please do!
<Daviey> It would be nice to be able to easily reset it on demand, the trend line was useless last cycle for us - i didn't have the heart to raise an RT for it.
<pitti> Daviey: individual trend lines can be changed by anyone
<Daviey> oh?  Didn't realise that.
<Daviey> I thought since it moved, we couldn't.
<pitti> Daviey: https://code.launchpad.net/~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config/ is the config
<pitti> it's in bzr
<Daviey> I've not been getting mails recently for bad syntax, even though i saw some with it.. Anyone else not getting mail?
<Daviey> pitti: ta
<pitti> but it doesn't make sense to manually set hundreds of trend lines (NB all invidual users) around FDF
<Daviey> right
<jibel> pitti, ok for me
<pitti> ok, WI tracker reset
<apw> pitti, i don't mind either way, i am happy to leave things as they are and just reset the trend lines, but not bothered if you reset
<apw> doko, is that only on oneiric buildd's or any arm buildd building in an oneiric chroot
<doko> apw, should be for any buildd which is used to build precise (which I understand is oneiric)
<doko> at least scheat runs oneiric as the host system
<Andy80> hi
<Andy80> I had prepared a very small patch for XChat and I wanted to merge... the problem is that I found many XChat projects in Launchpad and I really don't know which one to branch and which one to push into. Please consider that my patch is Ubuntu related only so it must not be included in the upstream version of XChat. Any idea? Thanks.
<doko> apw, infinity, ppisati: so it looks like some buildds are still running on babbage boards (lucid?)
 * doko wonders why we have a delta in amule which just removes a paragraph in the package description ...
<pitti> doko: overzealous sponsors?
<seb128> Daviey, hey, do you plan to keep following on https://code.launchpad.net/~gandelman-a/ubuntu/precise/facter/lp888671/+merge/81894 ? it's in the sponsoring queue and you started reviewing it, it seems, the submitter updated following your comments
<Daviey> seb128: Ah, do you have thoughts on it?  It seemed bad to depend on ruby1.8.. but i don't care that much
<seb128> Daviey, no, I'm just trying to clean a bit the sponsoring queue, you seemed to be on this one so I was not sure if it was needed to let it still be in the queue
<Daviey> seb128: sure, take off sponsors.. i'll take ownership for now.
<seb128> Daviey, thanks
<roadmr> seb128: dumb question re: this merge request (https://code.launchpad.net/~roadmr/ubuntu/oneiric/checkbox/0.13/+merge/82719), how can I change the targetted series?
<roadmr> seb128: (btw, thanks so much for sponsoring our upload!)
<seb128> roadmr, (you're welcome)
<seb128> roadmr, not sure, I don't have an active merge request of mine handy to try, don't you have an edit or resubmit button somewhere?
<roadmr> seb128: oh yes, the "resubmit proposal" button lets me edit that.
<roadmr> seb128: sorry, I should have been able to figure that out myself, fixing it now
<seb128> roadmr, yw
<seb128> no worry
<seb128> roadmr, it's uploaded in any case so you can set it as merged
<doko> pitti, well, I'll drop it
<seb128> could somebody set https://code.launchpad.net/~kevin-lacqui/ubuntu/oneiric/eggdrop/fix-for-885329/+merge/81387 to work in progress or something else to get it off the sponsoring queue until it's updated?
<seb128> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton
<seb128> ok, enough for today
<seb128> (sponsoring)
<Laney>  
<tjaalton> what was the fix for bugs like bug 894141 again?
<ubottu> Launchpad bug 894141 in qt4-x11 (Ubuntu) "bug caused by gzip './usr/share/doc/libqt4-network/copyright' is different from the same file on the system" [High,Confirmed] https://launchpad.net/bugs/894141
<tjaalton> or workaround
<cjwatson> that's got nothing to do with the known gzip bug
<cjwatson> copyright isn't compressed
<cjwatson> it was a pkgbinarymangler bug when pitti fixed it recently, I believe
<tjaalton> ok
<cjwatson> though I don't see it in pkgbinarymangler's uploaded changelog; check IRC logs from a couple of days ago
<tjaalton> nothing in bzr either, since 106
<tjaalton> that was a week ago
<tjaalton> checking the irclog
<SpamapS> hrm, did something break sbuild recently?
<SpamapS> since sbuild-update'ing my precise chroot I can't build anymore...
<SpamapS> http://paste.ubuntu.com/748384/
<tjaalton> cjwatson: found the dupe, bug 893826
<ubottu> Launchpad bug 893826 in pkgbinarymangler (Ubuntu) "symlinked docs are different between architectures, depending on dpkg-deb package order" [Medium,Triaged] https://launchpad.net/bugs/893826
<SpamapS> hm seems I just happened to try and build two things that depend on locales-all | something-else
<jelmer> hmm, python-subunit has a MIR that was fixreleased several months ago, but I'm still getting a DEPWAIT trying to build-depend on it. Is there anything else I need to do ?
<g0twig> hey
<g0twig> is here the team that makes the ubuntu 12.04 isoÅ?
<cjwatson> g0twig: probably easier to just ask your question directly, as there's a lot of stuff in the images and it's dealt with by lots of different people
<cjwatson> g0twig: and please don't ask in multiple different channels
<SpamapS> UGGGH
<SpamapS> http://bugs.mysql.com/bug.php?id=61713
<SpamapS> ok.. thats too much to deal with on turkey day
<cjwatson> stgraber: update on fuse: I have what I think is a correct merge that builds, but I need to test it some more before uploading
<cjwatson> and it's EOD now I think
<stgraber> cjwatson: ok, thanks
<micahg> pitti: are you still around?  I have a question about a changelog from an SRU going into -security
<micahg> pitti: nevermind, I figured it out
<sladen> is Launchpad broken for everyone or just me.com ?
<ajmitch> sladen: define 'broken' - there's a new bug listing for beta testers but apart from that it's working for me
<penguin42> sladen: https://bugs.launchpad.net/ubuntu seems OK to me
<sladen> ajmitch: OOPS on submitting bug changes
<sladen> ajmitch: though making them individually appears to have worked
<lifeless> sladen: via email ?
<sladen> lifeless: +edit submit
<sladen> lifeless: I can no-longer reproduce it
<sladen> there will be some OOPS in there
<tjaalton> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<SpamapS> Hmmm...
<SpamapS> I need to convert mysql-server from a meta-package to a virtual package so that mariadb and percona can provide it as well.... do I need to have an archive admin drop the old meta package in order to do that properly?
<micahg> SpamapS: you could just have it provide alternate dependencies on those 3 packages with a preferred default first
<micahg> wait, maybe not...
<SpamapS> micahg: its orthogonal to my current goals.. so I'll leave it as a meta package for now
<micahg> SpamapS: as long as the binary is there, it will try to use the binary to install, but if something else is pulled in, I think the provides takes precedence
 * micahg is thinking of the notification-daemon package
<SpamapS> micahg: Eventually I'd like for other mysql derivatives to be able to provide: mysql-server and mysql-client. For now, its not necessary.
<micahg> SpamapS: makes sense
<lifeless> SpamapS: virtual packages can be named the same as a real package
<SpamapS> lifeless: *oh*
<SpamapS> I hadn't thought of it like that
<micahg> SpamapS: so, you can leave the provides off of the mysql-server-foo package and leave the meta package to pull that in as a sane default, and add the provides/conflicts to the others
<lifeless> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
<SpamapS> Ok cool I'll do that with percona and maria
<SpamapS> Which makes more sense.
<lifeless> 'If there are both concrete and virtual packages of the same name, then the dependency may be satisfied (or the conflict caused) by either the concrete package with the name in question or any other concrete package which provides the virtual package with the name in question. '
<lifeless> SpamapS: and http://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg
<lifeless> SpamapS: the other thing to remember is 'If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied (or the prohibition violated, for a conflict or breakage). '
<lifeless> SpamapS: so you can have simple deps on 'mysql-server' satisfied by percona, oracle, drizzle etc
<lifeless> SpamapS: but you can't have complex ones like 'version >= 5'
<SpamapS> Thats fine, it only makes sense in the simple case.
<azeem> Package: oracle
<SpamapS> LOL
<azeem> Depends: mysql-server (>= awesome)
<SpamapS> hahaha
<lifeless> \o/
<SpamapS> Breaks: *
<azeem> well, I meant Provides:
#ubuntu-devel 2011-11-25
<chrisccoulson> slangasek, regarding bug 894546, i've already asked that reporter not to do this once before already
<ubottu> Launchpad bug 894546 in wpasupplicant (Ubuntu) "Add --version switch" [Undecided,Invalid] https://launchpad.net/bugs/894546
<chrisccoulson> seems he doesn't listen though :(
<lifeless> erm wtf
<wgrant> Lucky we have task deletion now :)
<StevenK> Now we just need bug deletion
<JanC> I wish he/she would file bug reports about missing manpages instead...   :P
<dobey> ugh; man pages
<dobey> and what a wonderful descript that bug has; a simple duplicate list of the things which it is filed as affecting
<penguin_03> does ubuntu 10.04 obey the DEB_BUILD_HARDENING variable? In other worlds will it enable what http://wiki.debian.org/Hardening#Using_Hardening_Options says it does for debian?
<dobey> penguin_03: if it works with debhelper 7, i would expect it would work on ubuntu 10.04
<penguin_03> dobey, is there a obvious way to tell if its working or not?
<dobey> penguin_03: build a package with it, and check the build log?
<micahg> penguin_03: run hardening-check on the binary
<dobey> and do that, as the wiki says :)
<slangasek> chrisccoulson: ah, yuck
<pitti> Good morning
<pitti> tjaalton, cjwatson: pkgbinarymangler doesn't touch "copyright" either (symlink/compress)
<pitti> that must be yet something else
<pitti> tjaalton: 893826 is for everything _except_ copyright
<ankit-tulsyan> Hi All, My name is Ankit. I have been using ubuntu for a while and  wanted to help out in squashing some bitsize bugs. I do have a programming background, but completely new in developing on ubuntu. I was wondering whether this is the right place to ask for help in trying to get started with this? If not, could it be possible for you to direct me to the right chat group?
<ankit-tulsyan> Hi All, My name is Ankit. I have been using ubuntu for a while and  wanted to help out in squashing some bitsize bugs. I do have a programming background, but completely new in developing on ubuntu. I was wondering whether this is the right place to ask for help in trying to get started with this? If not, could it be possible for you to direct me to the right chat group?
<pitti> ankit-tulsyan: in general this is the right place, indeed
<pitti> ankit-tulsyan: thanks for your interest!
<pitti> ankit-tulsyan: https://wiki.ubuntu.com/HelpingWithBugs might be a good page for you to start with
<ankit-tulsyan> aah ok great. nope I have been using ubuntu for a while and been very appreciative of the work that has been done over the years..finally decided try and help out too and get my hands dirty ;)
<pitti> ankit-tulsyan: it links to https://wiki.ubuntu.com/Bugs/HowToFix which describes the process how to do that
<ankit-tulsyan> cool thanks
<ankit-tulsyan> great thanks...
<pitti> you're welcome, have fun!
<dholbach> good morning
<ogra_> cjwatson, hmm, Bug 893842 looks like there is an additional transition in order for dropping of the admin group
<ubottu> Launchpad bug 893842 in policykit-1 (Ubuntu Precise) "Move "admin" group to "sudo"" [Critical,Fix released] https://launchpad.net/bugs/893842
<cjwatson> ogra_: I brought that up on ubuntu-release last night
<ogra_> ah, i didnt read that yet :)
<cjwatson> ogra_: er, I commented on the bug so you know I'm aware of it - what are you asking me?
<ogra_> nothing, i just saw the recent comments ... sorry, probably i read them out of order
<cjwatson> OK :)
<cjwatson> as Martin says, there are probably a few places we've missed; I think it's worth doing it this way though, as it removes a long-standing divergence from Debian
<cjwatson> stgraber: trying a fresh Edubuntu build now ...
<pitti> cjwatson: I'm about to upload a new ubuntu-meta for the https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-default-apps stuff; is now a bad time?
<pitti> cjwatson: oh, and good morning!
<pitti> ogra_: BTW, I just saw that the ubuntu seeds had rhythmbox [armel] and banshee [!armel] all along, so that won't change much for you
<ogra_> pitti, it will, since that change didnt drop banshee ... thanks to U1 rdeps
<pitti> ah :)
<ogra_> just drop all armel specifics there :)
<pitti> yep, done
<ogra_> thx
<pitti> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.precise/revision/1959
<ogra_> pitti, on monday we need to talk about the tracker once again i fear (not all our specs are approved yet due to david traveling the whole week)
<pitti> waiting with dput for cjwatson's yay or nay
<pitti> ogra_: approved or not is not the issue, what's important for the trend lines is that the number of WIs don't change too much any more
<cjwatson> pitti: go ahead
<pitti> ogra_: but you can always adjust trend lines for individual milestones if you need to
<pitti> ogra_: (it's in bzr, everyone in ~platform can commit)
<ogra_> pitti, well, all unapproved ones dont show up on your page yet ... and i see specs we dont own at all
<pitti> http://://bazaar.launchpad.net/~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config
<ogra_> s/your/our/
<pitti> ogra_: they do; if they don't show up, they haven't been targetted to precise
<pitti> or have a syntax error (missing "work items:"?) in the whiteboard
<ogra_> oh, yeah, approval and atrgeting is the same thing in davids workflow :)
<pitti> ogra_: the tracker doesn't take the status into account
<ogra_> so not all show up yet
<alexbligh> I am packaging something that puts libraries in /var/lib/foo/*.so*. I apparently need to add a file /etc/ld.so.conf.d/foo.conf containing the path /usr/lib/foo. Is there a 'proper' way to do this, or should I just install a normal file there from foo.install? IE can dh_makeshlibs etc. do this for me?
<pitti> alexbligh: that looks utterly wrong; if they are private libraries that are loaded at runtime as plugins, they should go into /usr/lib/foo/*.so
<pitti> alexbligh: and if they are "real" public libraries, they need to go into separate binary packages into /usr/lib/<arch>/
<alexbligh> pitti, they are private libraries. It's actually the oneiric xen4 package being compiled on lucid. For some reason 'things to do not work' on lucid
<alexbligh> well, actually, they aren't private libraries because our own stuff uses them, but they are written as private libraries, which is probably the issue.
<alexbligh> e.g. libxen-dev package contains
<alexbligh> apols
<alexbligh> e.g. xen-utils contains
<alexbligh> -rw-r--r-- root/root    142672 2011-11-23 12:17 ./usr/lib/xen-4.1/lib/libxenctrl.so
<pitti> alexbligh: then adding them to ld.so.conf would be wrong, as that would make them public
<pitti> alexbligh: the startup scripts could set LD_LIBRARY_PATH for that
<pitti> alexbligh: but it's still wrong to put them into /var, they should be in /usr/lib/<pkgname>/
<pitti> alexbligh: ./usr/lib/xen-4.1/lib/libxenctrl.so looks fine
<alexbligh> I didn't suggest /var.
<pitti> alexbligh | I am packaging something that puts libraries in /var/lib/foo/*.so*. [...]
<alexbligh> libxenctrl.so is in effect a public library. You need it in order to build stuff that uses it
<pitti> so if that was just a typo, ignore me :)
<alexbligh> aaarggh s/var/usr/
<infinity> alexbligh: Those are plugins, surely?
<alexbligh> (sorry)
<infinity> alexbligh: Nothing's actually linked against them...
<alexbligh> We have a program which links against them.
<pitti> alexbligh: it doesn't seem to have a SONAME, though, so it shouldn't be a public one
<alexbligh> In another debian package
<alexbligh> which you need to do in order to control xen programatically
<alexbligh> but the package maintainer appears to have forgotten this.
<infinity> alexbligh: Which package links againt it?  And which binary?
<alexbligh> A proprietary package of ours (extility-xvpagent), but the same would be true of anything that links to xen using the modern xen API (I don't know if openstack have got that far yet)
<alexbligh> (package maintainer has probably missed it because no one is doing it yet)
<infinity> alexbligh: Err, but those pluginy things should be dlopen()ed, not linked at build-time.
<alexbligh> what do you mean by "plugginy things". I don't think it's intended as a plugin. It's a straight shared library.
<alexbligh> xen tools themselves are linked against it direct at build time.
<alexbligh> (AFAIK)
<infinity> adconrad@cthulhu:~$ ldd /usr/lib/xen-4.1/bin/xentop | grep xen-4.1 libxenctrl.so => /usr/lib/xen-4.1/bin/../lib/libxenctrl.so (0x00007fb3b737d000)
<infinity> Indeed.
<infinity> I smell rpath.
<infinity> Which may have something to do with Xen's bizarre installation method.
<alexbligh> infinity, no argument there!
<alexbligh> I was trying to avoid our packaging hard coding the location
<infinity> adconrad@cthulhu:~$ chrpath -l /usr/lib/xen-4.1/bin/xentop
<infinity> /usr/lib/xen-4.1/bin/xentop: RPATH=${ORIGIN}/../lib
<infinity> alexbligh: ^-- You probably want a similar RPATH setup in your packaging.
<infinity> alexbligh: And to avoid hardcoding it, you can probably yank it at build-time from the current xen build-deps you have installed.
<alexbligh> infinity, you would be assuming xen build deps actually work :-(
<alexbligh> I am actually doing all this on lucid, so have my own package variants anyway.
<infinity> Well, are you installing your stuff to /usr/lib/xen-4.1/bin?
<alexbligh> No.
<infinity> Despite the fact that they're Xenish binaries? :)
<alexbligh> Because it's not xen stuff. It's our own agent, and we have version for (e.g) kvm too,
 * infinity shrugs.
<infinity> Fair enough.
<infinity> But yeah, then you'll want an RPATH of /usr/lib/xen-4.1/lib
<alexbligh> ok, so either rpath or bodge ld.so.conf.blah.
<infinity> ld.so.conf is the wrong answer.
<infinity> As it makes all those Xen libraries public to every binary on the system.
<infinity> And there's no guarantees they won't collide.
<ogra_> you could mount some bumpers :P
<infinity> libflask.so and libfsimage.so, for instance, don't sound particularly namespace-friendly. :P
<alexbligh> that's probably not an issue as it's an embedded system effectively, so we know what's on it, but yes it is horrible. The reason I am worrying about rpath is I think we currently override dh_shlibdeps and -X all the xen stuff simply because the build deps don't work properly.
<infinity> I also wouldn't be shocked to discover that the rpath is necessary for the xen libs to load their own plugins.
<alexbligh> (i.e. the -dev package contains neither all the headers necessary nor all the libraries)
<infinity> But only one way to find out, I suppose. :P
<alexbligh> oh it works fine with ld.so.conf bodged
<alexbligh> I was just looking for an easy way to put it in the packaging.
<alexbligh> (and there isn't one, because it shouldn't be there...)
<infinity> In package.install works well enough.
<alexbligh> ya
<infinity> But I pray this package never sees the light of day outside your systems. ;)
<infinity> Nothing personal. :P
<alexbligh> Well hopefully someone will fix up xen-4.1 some time, then it should all build normally and we can take all this crap out.
<infinity> (Futzing with the rpath seems like the correct fix, however, if you want to spend another 15 minutes fiddling)
<infinity> I'm not sure xen needs "fixing" in this case.
<infinity> Those libraries shouldn't be on the search path.
<alexbligh> Is the fact that the -dev package does not contain all the necessary headers and libraries not a bug?
<infinity> It has everything for xenctrl, xenguest and xenstore...
<infinity> And, as an added bonus, has those three libraries as static libraries.
<infinity> Which is probably the real solution.
<infinity> Not rpaths and crazy dynamic linking.
<alexbligh> (let me find what is missing)
<infinity> It only allows you to dynamically link xenstore.
<infinity> xenctrl and xenguest are static-only.
<infinity> I suspect that's by design, not a bug.
<infinity> Looking at how they work with the xen tools.
<alexbligh> yup, and we static link xenctrl and xenguest, and dynamically link xen-store
<infinity> With all their little plugins and other insanity.
<infinity> Err, but if you statically link xenctrl, then you don't need to be loading the copy from /usr/lib/xen-4.1/lib
<infinity> And my head just exploded.
<alexbligh> So they miss libxlutil, libxenlight, and libblktabctl
<infinity> I suspect those are meant to only be used internally.
<infinity> Just as there are gcc stub libraries that don't ship on path or with headers, etc.
<alexbligh> Our link line is:
<alexbligh> -lxenlight -lxenctrl -lxenstore -lblktapctl -lxenguest -lxlutil
<alexbligh> (non-xen stuff removed)
<alexbligh> and that's pretty much the link line they use to build their own tools I think.
<infinity> But... Does it actually have to be?
<alexbligh> I believe that is the minimal link line to get things to compile, yes.
<infinity> If you only include the top level xenguest.h and xenctrl.h, I can't see how you'd need to link all the private libs.
<infinity> But alright.
<infinity> You might be doing crazy things.  I'll concede that. :P
<alexbligh> we do not only include xenguest.h and xenctrl.h
<infinity> At which point, yes, the rpath would be the right way to go.
<alexbligh> but we are not including private stuff.
<infinity> And linking statically becomes pointless, cause you may as well pick up the other libs dynamically from the rpath too.
<alexbligh> (i.e. the _priv headers)
<infinity> Well, you did claim some headers were "missing".
<infinity> That's often a sign that you're pulling private headers from the source. ;)
<alexbligh> from the -dev package yes
<alexbligh> it compiles fine if you build xen from source, do a make install, then build our stuff
<infinity> Ahh, fair enough.
<alexbligh> which makes me think that the package maintainer is not treating as much public as the xen folks do
<alexbligh> (which is also fair enough in a way)
<infinity> Well, please fil bugs on exactly what's wrong there, then.
<alexbligh> yep, we should do that.
<infinity> I won't deny that out xen packages haven't seen as much love over the last few years as I'd like.  Mostly just trying to get to the bottom of it all.
<cjwatson> stgraber: hooray, you have Edubuntu images again
<infinity> But yeah, for your quick-n-dirty "I promise I'm not giving this package to random people on the internet, just jamming it in an embedded device" use case, the ld.so.conf.d snippet works for now. :P
<alexbligh> ./hypervisor/xen_libxl.c:#include <xentoollog.h>
<alexbligh> ./hypervisor/xen_hypervisor.c:#include <xenctrl.h>		// Xen control
<alexbligh> ./hypervisor/xen_hypervisor.c:#include <xs.h>			// Xen store
<alexbligh> ./hypervisor/xen_hypervisor.c:#include <xenstat.h>		// Xen stat
<alexbligh> ./hypervisor/xen_xl_internal.h:#include <libxl.h>
<alexbligh> ^- that's all we include - public APIs only I think.
<cjwatson> stgraber: your new ISO tracker seems to be down?
<Daviey> cjwatson: Did you see that SpamapS shaved some size from wget-udeb?
<cjwatson> I did
<Daviey> rocking.
<alexbligh> infinity, FWIW the problem is that  libxen-dev_4.1.1-2ubuntu4 does not contain ANY of the libxl (xenlight) API stuff, which is the recommend Xen 4.1 API. Will file a bug.
<infinity> alexbligh: Please do.
<infinity> alexbligh: And feel free to bug Daviey about it every day until it's fixed.  He loves that.
<Daviey> alexbligh: Aww, sad - now it's at the bottom of the queue.. thank infinity for that :)
<Laney> I'd appreciate knowing if https://launchpad.net/ubuntu/+source/haskell-vector/0.9-2/+build/2952098 builds quickly. Could someone rescore?
<cjwatson> Laney: done
<Laney> ta muchly
<cjwatson> Daviey: I'll look into integrating that for the next d-i upload
<alexbligh> Hmm, https://launchpad.net/ubuntu/+search?text=libxen-dev persistently gives an error. Is launchpad foobar'd?
<infinity> alexbligh: https://launchpad.net/ubuntu/+source/xen
<pitti> cjwatson: ntfs-3g> do you know what uses the "syncio" mount option? does anything still? certainly not in udisks
<pitti> cjwatson: do some users have that in their fstab, from the installer?
<Daviey> cjwatson: It's not actually blocking for us right now, but it will be in a few weeks when we look to try and default to providing preseed via ssl.
<Daviey> So short term, no panic. ;)
<cjwatson> pitti: it used to be set by wubi and there's no provision for transitioning it
<cjwatson> it's no longer set by anything, that's why I marked it as compatibility :)
<pitti> cjwatson: ah, it's not in a place where a postinst or some such could change "syncio" to "sync" in fstab?
<pitti> thanks, I was just curious
<alexbligh> infinity, Daviey : LP #894711
<ubottu> Launchpad bug 894711 in xen (Ubuntu) "libxen-dev does not contain xl libs or includes" [Undecided,New] https://launchpad.net/bugs/894711
<cjwatson> pitti: I think it was set as a kernel argument, and there's already enough stuff futzing with those :)
<cjwatson> yeah, rootflags=syncio, and in the context of wubi I think it was pretty difficult to undo that
<ogra_> pitti, hrm, i cant access the branch, seems canonical-arm isnt a member of canonical-ubuntu-platform or wi-tracker-configurators anymore
<ev> pitti: regarding http://summit.ubuntu.com/uds-p/meeting/19445/desktop-p-dvd-image/ - 750MB is achievable on a CD with a 90min/800MB CD, no?  Just trying to understand why this needs to be a DVD.
<ev> (context: working with John on the web team to help plan their changes to ubuntu.com/download)
<cjwatson> the word I'd heard was that we probably wouldn't actually need that flexibility this cycle
<cjwatson> so maybe don't commit to web changes just yet ...
<pitti> ev: sure, I just don't know how widespread burners/readers for those are
<pitti> ogra_: invited to join, you need to approve
<ogra_> pitti, already fixed with michelle
<ogra_> we're back in platform
<ogra_> but thanks
<pitti> ah, that way around
<pitti> ogra_: so, please decline it the
<pitti> n
<pitti> I can't un-invite
<ev> cjwatson, pitti: noted; thanks!
<ogra_> yup, will do
<JanC> I think most CD drives can read/write 800 MiB (and even larger capacity) CDs (unless something changed in recent years, but I never had issues back when I still used CD-Rs quite often...)
<JanC> the thing that's trickier is that it's getting more & more difficult to find such CD-Rs  ;)
<JanC> in the past you could buy them in "every" supermarket, now you probably need to go to a specialized shop...
<bkerensa> Precise Pangolin is nice :D
<ogra_> JanC, well, i bet there are countries in south america, asia and africa where you still cant buy them
<ogra_> (that was one of the complaints that kept us from moving to 800MB in the past)
<JanC> right
<JanC> or if you can buy them there, it might be somewhere at the other side of the country, or whatever
<ogra_> yeah
<JanC> too bad USB sticks are still "expensive" compared to CD-Rs  ;)
<ogra_> yup
<nigelb> g29
<nigelb> ugh
<JanC> OTOH, we plan to order a bunch of USB sticks with our locoteam to replace at least part of the CD-Rs we distribute at events...
<hrw> any opinions on bug 894732?
<ubottu> Launchpad bug 894732 in eglibc (Ubuntu) " trying to overwrite '/usr/include/fpu_control.h', which is also in package libc6-dev-i386 2.13-20ubuntu5" [Undecided,New] https://launchpad.net/bugs/894732
<hrw> can someone confirm issue?
<mdeslaur> chrisccoulson: I'll buy you a steak and a beer if you add indicator support to gnote :P
<chrisccoulson> mdeslaur, i would like to renegotiate:
<didrocks> chrisccoulson: do not forget ubuntuone syncing as well :)
<chrisccoulson> how about, you buy me steak and beer and i don't add indicator support to gnote?
<chrisccoulson> i think that's a better deal :)
<mdeslaur> chrisccoulson: uh, not for me :)
<chrisccoulson> lol
<mdeslaur> chrisccoulson: a steak and _three_ beers?
<didrocks> mdeslaur: i can use a steak and try to add this support, if I'm sure someone is doing the ubuntuone syncing side :)
<chrisccoulson> is gnote even maintained?
<mdeslaur> didrocks: I'll buy you a steak if you do it
<didrocks> chrisccoulson: is tomboy really maintained? :)
 * didrocks adds a tomoby note to add indicator support in gnote
<chrisccoulson> lol
<didrocks> and we all see that chrisccoulson agreed on the ubuntuone syncing support, so we are all set :)
<chrisccoulson> heh
<mdeslaur> didrocks: well, ubuntuone support is not required now that couchdb support is being dropped...
<didrocks> mdeslaur: it wasn't using couchdb IIRC but another direct API
<mdeslaur> oh? ah, cool, I wasn't aware of that
<mdeslaur> chrisccoulson: so, if I understand your criteria, "maintained" means "Does the mozilla foundation work on it". Is that accurate?
<mdeslaur> heh, empathy popped up a window, and unity thinks it's gimp. Added a gimp icon to the launcher for it.
<ogra_> thats surely the newly added graphics editing functions of empathy :P
<SpamapS> mdeslaur: new feature of empathy.. shared drawing space
 * SpamapS eyes ogra_ suspiciously.. 
<ogra_> heh
<SpamapS> do I have to start wearing my tinfoil hat again?
<ogra_> to late, i got everything on disk already
 * ogra_ pulled a full backup
<SpamapS> Hm, ok.. so.. mysql-server is now in two places.. main and universe.. since 5.1 is in main and 5.5 has not been promoted yet.
 * SpamapS encrypts the entire contents of his brain with the WHISKEY-89 algorithm
<ogra_> *slurp*
<SpamapS> damn... one way algorithm.. oh well..
<mdeslaur> hehe
<cjwatson> Daviey: so, um - how is wget in d-i going to verify SSL certificates?
<SpamapS> anyway, seems we need to drop the 5.1 mysql-server as right now apt decides its better to remove it than upgrade it to 5.5's version
<cjwatson> SpamapS: actually, mysql-server-5.5 is in main
<SpamapS> cjwatson: any ideas? ^^
<SpamapS> Oh
<cjwatson> SpamapS: I've demoted mysql-server-5.1
<cjwatson> SpamapS: I doubt that will help with universe builds, though
<SpamapS> I see two mysql-server packages apt-cache show right now
<SpamapS> oh wait, one is installed
<cjwatson> yeah, but that should be fine
<cjwatson> Daviey: I'm really not keen on pulling ca-certificates into d-i - size aside, it would mean that we'd have to worry about security updates of d-i a lot more
<Daviey> cjwatson: right, i was wondering - could we preseed a cert fingerprint?
<cjwatson> Daviey: I suspect a lot of the use cases for this will be self-signed anyway, where HTTPS is just being used to prevent people tcpdumping for passwords.  Do you think we can just use --no-check-certificate and be done with it?
<Daviey> Considering /most/ IMO will use self-signed.
<Daviey> hah
<Daviey> Hmm, chicken -> egg.
<mdeslaur> cjwatson, Daviey: what are you talking about?
<Daviey> mdeslaur: d-i support for ssl..
<Daviey> grabbing preseeds via https.
<SpamapS> cjwatson: dist-upgrade wants to remove mysql-server ... presumably because mysql-common 5.5.17-4ubuntu5 breaks mysql-server-5.1 ..
<SpamapS> cjwatson: https://jenkins.qa.ubuntu.com/job/precise-upgrade/PROFILE=server-tasks-amd64,label=upgrade-test/lastBuild/artifact/server-tasks-amd64/apt.log
<SpamapS>   Removing mysql-server:amd64 rather than change mysql-server-5.5:amd64
<SpamapS> I don't understand why its doing that
<cjwatson> let's think pretty carefully before permuting packages to try to solve it :)
<SpamapS> I can remove the Breaks: line from mysql-common.. I think that will actually solve the problem.. but not in a way I fully understand.
<SpamapS> I added it because the new mysql-common will cause mysqld and the mysql cmdline client to abort.
<cjwatson> it's possible that adding "Breaks: mysql-server-core-5.1" would help
<cjwatson> (likewise client)
<cjwatson> this is just gut instinct though rather than a hard analysis
 * SpamapS ponders how to test that without uploading..
<SpamapS> reprepro maybe? :-P
<cjwatson> it sort of makes sense though; mysql-server-core-5.5 Breaks mysql-server-core-5.1 and it prefers to hold back mysql-server-core-5.5, so pruning from the bottom of the dep tree rather than the top seems to make sene  
<cjwatson> *sense
<cjwatson> yes, if you can construct a chroot that exhibits that problem then you should be able to add another repository to it
 * SpamapS is on it
<Daviey> mdeslaur: Do you have any suggestions for the miminal requirements to validate an ssl certificate.  We can't validate based on fingerprint, can we?  We need the ca-cert on the local machine?
<mdeslaur> Daviey: you need ca-cert on the local machine, but you need to be able to update that. If that can't be updated properly, you might as well not check certs, and properly document that certs are not checked.
<mdeslaur> Daviey: is this just to hide the passwords that are in the preseed file?
<Daviey> mdeslaur: So the local machine is a volatile enviroment (d-i).. so the problem is getting ther ca-cert to the machine, i don't imagine it fits on the kernel command line :)
<Daviey> mdeslaur: Yes
<SpamapS> I think there's a need to verify the identity of the cobbler server too
<cjwatson> AFAIK it's just for hiding passwords
<SpamapS> But it does sound more difficult. :-P
<cjwatson> can I suggest that maybe verifying the identity should be done in some simpler way than pulling ca-certificates into d-i
<mdeslaur> Daviey, cjwatson: in that case, I would much rather see the preseed file gain a way to specify a ssh public key
<Daviey> It also provides 'some' assurance that it is /the/ correct server :)
<mdeslaur> (if it's not already possible)
<cjwatson> mdeslaur: uh, you need some kind of login credential ...
<soren> Does pulling ca-certificates really provide any more confidence?
<Daviey> mdeslaur: then setup an ssh tunnel?
 * Daviey runs
<soren> a) People are likely to use self-signed certs.
<Daviey> soren: we discussed that :L)
<soren> There's a b), too.
<soren> Wait for it :)
<SpamapS> Daviey: to that end.. PXE booting is usually reserved for private provisioning networks for this reason
<cjwatson> mdeslaur: the preseed entries in question are things like the crypted password for the first user
<cjwatson> (which can ALREADY be crypted but apparently some compliance processes pointlessly mandate HTTPS)
<mdeslaur> no, I'm talking about giving an ssh public key as the initial user's login credential, instead of a password
<cjwatson> I think that's a wildly separate issue
<Daviey> ahh, that can be done with a late entry, right?
<soren> b) Even if not, if people can hijack the connection to fetch the preseed, aren't they likely to be able to send a forged initrd (with a forged ca-certificates) in it?
<cjwatson> and really rather considerably more complicated
<cjwatson> sure, you can do that with a preseed/late_command
<cjwatson> this doesn't solve the question of what to do with the wget command line used in the HTTPS case
<Daviey> soren: right, but i'd like to try to provide some assurance.
<cjwatson> easily broken assurance is worth nothing
<cjwatson> I honestly think this is a fig leaf at best
<Daviey> Well i agree it's worth less.. but we should start somewhere, rather than just not starting it?
<mdeslaur> definitely, we shouldn't be encouraging non-secure use of https
 * soren concurs
<cjwatson> I'm not arguing against putting https support in the installer as a compliance fig leaf; I'm arguing against making use of it in anything we care about ourselves
<SpamapS> better to encourage the provisioning network be separate from production than to imply you can provide assurances for the installer.
<cjwatson> IMO a compliance fig leaf can just use --no-check-certificate because I think it's just to defeat snooping
<Daviey> Hmm
<cjwatson> people with stricter requirements can customise the installer initrd to add a certificate
<Daviey> Then i could arp posion, MITM, and steal the creds regardless.
<Daviey> True
<soren> If you can do that, you can give the host a forged initrd as well.
<cjwatson> this is turning from "please add wget" into a serious spec ...
<soren> And if you can give a forged initrd, you can give a forged ca-certificates.
<soren> etc.
<mdeslaur> soren: yep
<pitti> Riddell: thanks for the userconfig fix; does that also take care of recognizing "admin" group members as administrators, or now just "sudo"ers?
<soren> In summary, if you can't trust the network you're passing the installer over, you're screwed.
<Riddell> pitti: just sudo I think, it'll list "admin" as just another group without comment
<SpamapS> PXE is effectively physical access.
<soren> Yup.
<cjwatson> Riddell: it needs to handle both; there's been no provision for migrating admin members to sudo
<Daviey> cjwatson: If someone wanted to add the distro ca-certificates as a customisation, what would it involved?
<pitti> Riddell: ah, the GNOME equivalent shows a list of users with "user" or "administrator", so there I had to make it recognize both
<Daviey> As in, not done at distro level, but end user
<soren> PXE is the easiest to forge, ironically.
<cjwatson> Daviey: make an /etc/ssl/certs/, cpio and gzip, cat to end of installer initrd
<soren> All communication is over UDP, isn't it? Or am I confused?
<Daviey> Just re-roll the initrd including them?
<Daviey> right
<mdeslaur> soren: it's tftp, so yes
<soren> That's what I thought.
<soren> So you don't even have to mitm to inject a poisoned initrd.
 * OdyX points that win32-loader does all the needed checking for trusted download of the debian-installer (gpgv with embedded debian-archive-keyring, md5sums, sha1sum)
<soren> Yo ujust need to be fast.
<cjwatson> the bug for this was bug 833994
<ubottu> Launchpad bug 833994 in debian-installer-utils (Ubuntu) "debian-installer does not support https when using with preseed files" [Medium,Triaged] https://launchpad.net/bugs/833994
<Daviey> cjwatson: Okay, a kernel command line argument of "ssl-check=true" (default to false?)... Does that sound reasonable?
<cjwatson> OdyX: which is fine as long as you have some trusted local thing to start with.  you can't do it securely when just pxe-booting
<cjwatson> the bug starts with "As part of a PCI Compliance process we need to ensure that confidential information is passed in a secure way. Currently one can pxeboot machines and the root password travels encrypted with MD5 which nowadays is breakable and it is not part of the PCI Recommendations as follow below:"
<OdyX> cjwatson: sure. And you have to trust win32-loader.exe. :->
<cjwatson> which leads me to believe that these alleged compliance recommendations are quite happy with PXE booting but not with HTTP
<cjwatson> which implies that they were written by a committee and confer no security
<Daviey> That is because those validating don't understand PXE, possibly. :)
<soren> cjwatson: It actually claims that it can fetch the kernel and initrd over https.
<Daviey> you can.
<soren> cjwatson: ...but I'll bet the thing that does that is fetched over tftp itself.
<soren> So => fail.
<mdeslaur> to achieve PCI compliance, he should simply be installing servers from a separate network
<mdeslaur> cjwatson: you can specify the preseeded passwords already hashed?
<cjwatson> mdeslaur: yep
<mdeslaur> cjwatson: problem solved
<cjwatson> although it is md5 crypt
<soren> He points to md5 being the specific problem. What if they were passed as SHA512?
<pitti> stgraber: http://91.189.93.73/qatracker/reports/defects -> oops
<soren> That should be "fine".
<soren> (as in "compliant", not as in "secure")
<cjwatson> let me check whether that's actually hardcoded
<soren> Certainly that'd be an easier problem to solve than any of the other things we've discussed :)
<mdeslaur> if not, we should simply fix that so he can specify it as SHA512
<cjwatson> it's just written straight to the password file.  I rather suspect that SHA512 will work fine
<soren> Win.
<Daviey> Note, that passwd isn't the only credential.
<cjwatson> well, passed to usermod --password=
<soren> Daviey: If it's the only credential his compliance doc cares about...
<soren> I forgot how much I hate this compliance nonsense.
<stgraber> pitti: that's jibel's fault ;) he's aware of it and should be fixed soonish. The report doesn't like having multiple active milestones
<SpamapS> Why is there even a password allowed. ;-)
<Daviey> soren: It's not only that bug that this is addressing. :)
<soren> So, on Amazon S3, you can configure a bucket to encrypted. This means that Amazon will encrypt the contents for you on disk. Whenyou retrieve it, it's decrypted before you see it.
<cjwatson> there are ways to arrange security that don't involve SSL, you know :-)
<soren> Or so they say.
<soren> I'm sure it fulfills some compliance requirements, but boy is it stupid.
 * mdeslaur is so glad he's not a PCI compliance officer anymore
<jibel> pitti, that's because there are different releases opened for testing, which shouldn't happen since there is only one development release.
<jibel> I'll fix that
<SpamapS> soren: you have to use S4 to be sure.
<soren> SpamapS: I love S4.
<soren> SpamapS: WEll, except that it doesn't work last I checked.
<SpamapS> www.supersimplestorageservice.com
<soren> SpamapS: It's a lovely idea. It's web scale.
<SpamapS> the most secure storage platform ever... write-only :)
<soren> I guess it might just be my SOAP skills that failed me when I tried it out.
<soren> Or maybe the fixed it. It's been quite a while.
<soren> *they
<SpamapS> soren: whether it works or not, it works the same. :)
<soren> SpamapS: Hey, if I'm a paying customer, it should at least *claim* that it has accepted my data and has... er... handled it.
<SpamapS> if you're a paying customer of s4, I have some beachfront property for you in Arizona.. :)
<soren> No comment.
<pitti> stgraber: is there a documentation or the source code for the new tracker? we should rewrite publish-image-set.py for the new one
<pitti> stgraber: and that probably should stop screenscraping, and use the API
<stgraber> pitti: source code is at: lp:~ubuntu-qa-website-devel/ubuntu-qa-website/drupal7-rewrite/
<cjwatson> pitti: there's already a new module in ubuntu-archive-tools for it
<cjwatson> publish-image-set should be updated, yes
<stgraber> pitti: the isotracker_xmlrpc.py module in ubuntu-archive-tools will just need to be extended to also fetch results, then publish-image-set can use it
<cjwatson> 'import isotracker_xmlrpc as isotracker' and work from there; see head comments in isotracker_xmlrpc
<pitti> cjwatson: sweet
<cjwatson> we're using that for posting images
<stgraber> pitti: I guess you'd need a new builds.get_list() call in the API to fetch the list of builds for a given milestoneid and status
<stgraber> status = 0 meaning that it's currently on the tracker and not marked as disabled
<stgraber> not sure if you also need to check the testcase coverage of the builds (not familiar with the publish script)
<pitti> cjwatson: I see that I signed up for release engineering alpha-1, so I guess I'll have a stab at this on Mon/Tue
<cjwatson> cool; you should have plenty of time since basically all the images are building cleanly ;-)
<pitti> I was just going to say :)
<pitti> some more months and we don't need REs any more
<cjwatson> mythbuntu is the only straggler and I gather that Daviey has just uploaded a fix for that
<ogra_> we'll all be jobless in two releases !!!
<pitti> ah, for the mysql 5.1 vs. 5.5 battle
<pitti> ogra_: more time to create bugs!
<ogra_> indeed
<ogra_> and we could hire new people to fix them !
<Daviey> cjwatson: I may not have, but leave it with me - i'll check in a bit.. it's on me
 * cjwatson nods
<cjwatson> out of the CD health checks, AFAIK the only outstanding issue is size, and at least for Ubuntu that may well have been fixed today
<pitti> yeah, with dropping mono
<cjwatson> so it's just bugs
<pitti> also, a tad of oversizedness is generally acceptable for A1, It hink
 * pitti kicks that space
 * Daviey stretches his legs
<pitti> cjwatson: although, for some reason i386 grew to 709 MB today; /me checks
<cjwatson> pitti: oversizedness> yeah
<pitti> ah, older daily ISOs have gone, can't compare; well, will compare with oneiric then
<cjwatson> you might be able to scrape info out of the build logs though
<cjwatson> that's one reason I keep so much detail in them
<pitti> *nod*
<pitti> jibel: I have some trouble figuring out what actually went wrong on https://jenkins.qa.ubuntu.com/view/Precise/job/precise-desktop-i386_default/148/ (it's marked as failed)
<pitti> d-i.syslog is empty (and that's ubiquity, so not totally unsurprising)
<pitti> is there an ubiquity syslog somewhere?
<pitti> or did it even fail to boot/start the live sesssion?
<jibel> pitti, this is bug 894768,
<ubottu> Launchpad bug 894768 in ubiquity (Ubuntu) "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [Undecided,New] https://launchpad.net/bugs/894768
<cjwatson> incidentally, any ideas on that, don't be shy
<jibel> pitti, the system doesn't install, if I run it again it passes
<pitti> jibel: does that crash appear somewhere in the artifacts?
<jibel> pitti, no, that's a problem with the framework I need to fix.
<jibel> syslog is not redirected as it should be
<pitti> cjwatson: on that actual bug, erk; would it be possible to add some logging how many blocks it already wrote? i. e. whether it fails in the middle or at the first block? that might give a hint which of teh EINVAL cases in write(2) applies here
<pitti> it does smell like a kvm/qcow2 issue, not that this would make it any easier
<pitti> cjwatson: or whether it fails on teh last block which isn't a full 16 KiB
<SpamapS> cjwatson: seems your hunch was correct.. needed to break the -core- packages as well
<pitti> jibel: would it be possible to get dmesg output after this happens? adding that to jenkins might generally be a good idea
<pitti> jibel: it might show an error on sda/xda which coincides with this
<cjwatson> SpamapS: ah, good
<cjwatson> pitti: yeah, I'll see if I can reproduce it locally and then instrument; I'd rather not instrument everything
<cjwatson> I don't think O_DIRECT is involved
<pitti> not in the code, anyway
<jibel> pitti, when it happened I connected to the VM and haven't found any error on /dev/sda
<pitti> jibel: in dmesg or with fsck?
<jibel> pitti, dmesg
<pitti> jibel: thanks, that's an interesting data point
<pitti> cjwatson, skaet: oh, 7 MB of oversizedness are due to LibreOffice needing a rebuild, and thus holding the old libicu44 on the CDs; so that will also go away
<pitti> won't happen for a1, though
<cjwatson> pitti: can we get that for alpha-1?
<cjwatson> awwwww
 * pitti asks Sweetshark
<cjwatson> there are at least two other NBS libraries it's holding in place
<pitti> I thought I overheard a conversation of uploading first 3.5 beta around December 5 or so
<cjwatson> we should rebuild 3.4
<cjwatson> IMO
<pitti> asking in #u-desktop
<cjwatson> I wouldn't do it for every single NBS library, but we've accumulated several now
<ogra_> just let me know early enough so i can worst case mangle the seeds on arm if it ftbfs
<pitti> good night everyone!
<jibel> pitti, cjwatson I found also an "invalid argument" error in an alternate run yesterday, don't know if there's a link
<jibel> Nov 24 10:01:11 in-target: dpkg: error processing /media/cdrom//pool/main/p/perl/perl-modules_5.14.2-5_all.deb (--unpack):
<jibel> Nov 24 10:01:11 in-target:  failed in write on buffer copy for backend dpkg-deb during `./usr/share/perl/5.14.2/IO/Uncompress/Base.pm': Invalid argument
<jibel> Nov 24 10:01:11 in-target: dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<pitti> it sounds likely anyway; both sound like invoking write()
 * pitti waves good bye for real
<cjwatson> jibel: if both ubiquity and dpkg see it, it seems improbable that it's anything but a kernel bug
<cjwatson> well, or possibly libc I suppose
<cjwatson> there's nothing else in common
<jibel> cjwatson, or kvm ?
<cjwatson> jibel: maybe; try with oneiric kvm?
<cjwatson> or an oneiric image, if you're already using oneiric kvm
<cjwatson> something to act as a differential
<cjwatson> apw et al: I'm going to process linux 3.2.0-2.4 through NEW early (i.e. before armel finishes building) because I want to be able to upload d-i at a vaguely reasonable time for me
<cjwatson> this will mean promoting crda and wireless-regdb in advance of wireless-crda being demotable (it's just a swap for the Debian packaging)
<cjwatson> I promise to remember about this and demote wireless-crda ASAP next week
<cjwatson> this will also mean d-i temporarily failing to build on armel
<cjwatson> I'm hoping that won't be a big deal
<alexbligh1> If I have a single source package that produces 2 binary packages, how do I make them each use a different debian/rules file?
<cjwatson> you can't
<cjwatson> debian/rules must deal with both
<alexbligh1> cjwatson, ok :-), how does the target get passed in then?
<cjwatson> (I mean, it can include other Makefiles if it likes, but that's only usually necessary for the very largest and most complicated packages, not for two binary packages; it must be the entry point)
<cjwatson> it doesn't :-)
<alexbligh1> hmm, so it only runs it once for each source package, not once for each binary...
<cjwatson> it gets told 'build' (non-root stuff), then it gets told 'binary' (assembling the .deb, usually under fakeroot)
<cjwatson> if you don't know the details, you should use /usr/share/doc/debhelper/examples/rules.tiny rather than trying to craft it yourself
<alexbligh1> ok, let's put this question another way :-)
<cjwatson> see 'man dh' for details on customising that
<alexbligh1> I have a package building fine at the moment using a completely minimal rules file (xen-3.3.1 fwiw). I want to put two files it generates in a different package from all the rest (literally just 2 files) - these are the hypervisor boot files. What's the easiest way to do that?
<cjwatson> debian/BINARYPACKAGENAME.install for each binary package listing what goes in each
<cjwatson> the path of least resistance is to list everything that goes into both packages separately, but you can list directories, so that's usually not particularly hard work
<cjwatson> (there are other ways; this is usually the simplest though)
<cjwatson> though, in cases such as xen where there's already a package in the archive, I find it surprising that you wouldn't start from the existing package?
<alexbligh1> ahh, I think I am beginning to understand. Could I also put an override target in for dh_install which did a -X for one package?
<cjwatson> yes
<cjwatson> override_dh_install:
<cjwatson>         dh_install -Ntheunusualpackage
<cjwatson>         dh_install -ptheunusualpackage -Xblah
<cjwatson> or possibly the reverse.  something like that
<Daviey> alexbligh1: What bug are you fixing?
<alexbligh1> there isn't a xen package is there? I thought the last one in ubuntu was 3.2 or something, then a big gap, then xen4
<cjwatson> https://launchpad.net/ubuntu/+source/xen-3.3/+publishinghistory
<alexbligh1> Daviey, the nonexistence of a xen-3.3.2 package
<Daviey> alexbligh1: have a bug number?
<cjwatson> it would be much better to take the last version in the archive and update it, rather than doing it all from scratch and reinventing package bugs
<cjwatson> *packaging bugs
<alexbligh1> nope
<alexbligh1> Sorry, that was Daviey, nope
<alexbligh1> cjwatson, yep, I could look at that. We've made some patches to xen-3.3.2 to unbreak the networking interface through xend, which have changed the API, so tbh it probably doesn't have general applicability, but yes you are probably right that xen-3.3.0 packages would have been a good place to start.
<cjwatson> apw: do you folks have a plan for when to update linux-meta?
<infinity> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<alexbligh1> Daviey, out of interest, would you be interested in a "proper" xen-3.3.2 package?
<Daviey> alexbligh1: Hmm.  Out of interest, what is wrong with xen4?
<alexbligh1> Daviey, the main problem is lack of a modern xenlinux dom0 kernel package, and I have an Ubuntu Natty kernel with xenlinux package based on Stefano Stab's patches
<alexbligh1> (sorry that was re xen3)
<cjwatson> apw: accepted now
<alexbligh1> the problem with xen4 is that piles of guest images are incompatible with it due to its different treatment of pv drivers.
<Daviey> alexbligh1: I personally wouldn't push for a real backport of this, the ongoing support would likely be lacking, and i fear it would give people a false sense of support :/
<Daviey> Oh wait.
<alexbligh1> Daviey, we have images that will boot on xen3 but not on xen4. The main issue is that if you configure xen4 to support PV drivers, then any modern linux will unplug the normal disk drivers using the pic unplug stuff, but if the image doesn't happen to contain pv drivers suitable for xen4, then it will fail to boot. That, plus device renames etc. makes for a really bumpy upgrade.
<Daviey> alexbligh1: You want to fix an issue of missing files in natty xen?
<alexbligh1> Daviey, I think Citrix will continue to support xen3 for a while yet as cloud.com have not even launched xen4 support, and their own use for Citrix stuff is very new.
<alexbligh1> Daviey, there is no Xen in Natty is there? I thought Oneiric was the first xen4. My missing files bug was xen4
<alexbligh1> Daviey, (we support both - sorry for the confusion!)
<Daviey> alexbligh1: There IS xen in natty, but only a source package :)
<Daviey> It failed to build, and nobody quite got it fixed
<Daviey> https://launchpad.net/ubuntu/natty/+source/xen-3.3/3.3.0-1ubuntu14
<alexbligh1> Daviey, and we run on Lucid, but for reasons too boring to explain, we need a newer kernel, and chose the Natty kernel for xen3 as the patches aren't around to do xenlinux on kernel 3.x.
<alexbligh1> Daviey, hmmm - perhaps using the 3.3.0 debian packaging files would NOT be a good idea then!
<Daviey> alexbligh1: Can you raise some bugs which address the issues you are trying to resolve.  I've got one, a few files missing?.. but it's kinda getting confusing.
<cjwatson> fixing the build failure would still be easier than starting from scratch
<alexbligh1> oh I have it all built and it works fine, it's just we want it in 2 packages.
<cjwatson> especially since it's a build failure in upstream code anyway, AFAICS (well, unless it's patched, but patches are easily amended)
<alexbligh1> Daviey, I raised bugs for all the xen4 stuff you asked me to.
<Daviey> alexbligh1: Yeah, it's really not safe for us just to throw different packages into the archive and say 'it works'.. we strive for the smallest patches possible, to the current packages
<alexbligh1> LP #894711
<ubottu> Launchpad bug 894711 in xen (Ubuntu) "libxen-dev does not contain xl libs or includes" [Undecided,New] https://launchpad.net/bugs/894711
<Daviey> ah neat
<alexbligh1> LP #894713
<ubottu> Launchpad bug 894713 in xen (Ubuntu) "xend init script should modprobe xen_gntdev" [Undecided,New] https://launchpad.net/bugs/894713
<alexbligh1> (latter has a patch too :-) )
<alexbligh1> Yeah, I sort of figured you'd be unwilling to take xen3.3 in any meaningful way into Ubuntu as to use it you need a xenlinux kernel, and there are no xenlinux kernels (to my knowledge) for the kernel versions you are targetting in Oneiric and Precise.
<alexbligh1> (hence I just hacked a package up for myself)
<alexbligh1> So I've only been filing xen4 problems.
<Daviey> alexbligh1: It does still make sense to try to base it from an archive package.  Sorry it seems like we can't do more...
<alexbligh1> Daviey, no problem at all
<Daviey> I would suggest putting it into a PPA tho :).. but not even sure you'll be able to build that..
<alexbligh1> Daviey, the main Xen problem we have is that no known Ubuntu operating system will boot as a Xen4 guest
<alexbligh1> (well, none since something really really ancient - pre lucid)
<Daviey> err, really?
<Daviey> smb: You managed to boot ubuntu on xen4, right?
<alexbligh1> yep, one of the modules is missing from the udeb. Let me find you the bug number.
<Daviey> (he might be afk)
<alexbligh1> smb agrees.
<Daviey> alexbligh1: IIRC, I did an upload last cycle which added two kernel modules, and that seemed to be enough
<cjwatson> there was a problem with blkfront/netfront not being loaded properly, but that was fixed
<alexbligh1> I thnk it's pasically 804219
<alexbligh1> LP #804219
<ubottu> Launchpad bug 804219 in linux (Ubuntu) "Xen PVonHVM can't mount rootfs" [Undecided,Confirmed] https://launchpad.net/bugs/804219
<alexbligh1> xen-platform-pci is missing from the udeb
<alexbligh1> it should really be build with CONFIG_XEN_PLATFORM_PCI=y not CONFIG_XEN_PLATFORM_PCI=m
<Daviey> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/804219/comments/15 , natty?
<ubottu> Launchpad bug 804219 in linux (Ubuntu) "Xen PVonHVM can't mount rootfs" [Undecided,Confirmed]
<alexbligh1> So modern kernels unplug the sda device, then can't communicate with the xvda device as they have no platform PCI
<alexbligh1> Oneiric too
<alexbligh1> I think we filed another one, let me see...
<alexbligh1> Problem only occurs on HVM guests, which is probably why you haven't found it
<alexbligh1> Daviey, the problem with running Ubuntu-anything on HVM Xen4 is LP #886521
<ubottu> Launchpad bug 886521 in linux (Ubuntu) "CONFIG_XEN_PLATFORM_PCI should be "y" when building 3.1 kernel" [Medium,Triaged] https://launchpad.net/bugs/886521
<Daviey> alexbligh1: I'd quite like to talk this over with smb on Monday, are you going to be around (euro day) to join in?
<alexbligh1> Daviey, possibly second half of afternoon. I have a "meeting of indeterminate length" AM (yippee)
<Daviey> hurray!
<mterry> jdstrand, heyo, archive-day-person.  :)  Could I impose upon you to NEW ruby-flexmock and drop libflexmock-ruby?
<mterry> jdstrand, I filed a bug for the latter... let me dig it up
<mterry> bug 896354
<ubottu> Launchpad bug 896354 in libflexmock-ruby (Ubuntu) "Please remove from precise" [Undecided,New] https://launchpad.net/bugs/896354
<cjwatson> mterry,jdstrand: I've processed that through binary NEW; that needs to publish before removal, though
<mterry> cjwatson, oh thanks
<hallyn> Question on how to stage a package change.  Right now, kvm-pxe is provided by etherboot.  We want to switch it to being provided by ipxe.  Is it good enough to upload them at the same time, but etherboot first?  Or is there a better way to go about that without risking conflicts on dist-upgrade?
<soren> Are you moving the files to a difference package or are you going to just build the same binary package from a different source package?
<hallyn> soren: the latter
<soren> What are the versions of the two source packages?
<soren> AT any rate, you won't have problems on dist-upgrade.
<soren> At that point, it doesn't matter which source package the binary package comes from.
<hallyn> soren: hm, etherboot was 5.4.4-7ubuntu3, ipxe is at 1.0.0+git-2.149b50-1ubuntu2
<soren> That's going to be a problem.
<hallyn> yeah.  hadn't thought of that.
<soren> By default, binary packages will have the same version as the source. They don't strictly have to, though.
<hallyn> i suppose i could just call it 'kvm-ipxe', and deprecate kvm-pxe
<hallyn> having different version #s for ipxe than kvm-pxe seems like it would cause gnashing of teeth at a later time.
<soren> It's bound to cause confusion, yeah.
<soren> I think qemu-kvm does something like that?
<soren> Or was it the old kvm package? I forget.
<soren> qemu-kvm does it.
<stgraber> you may want to have something like kvm-etherboot, kvm-ipxe, kvm-gpxe, ... all of them providing kvm-pxe
<hallyn> well the kvm package does something funky.  i try to ignore it
<soren> It builds a kvm package that has "84+dfsg-0ubuntu16+" prepended to qemu-kvm's version.
<hallyn> stgraber: that's voodoo i'm not familiar with.
<soren> Anything you do is going to be awkward to some extent.
<soren> You can either build kvm-ipxe from the ipxe package.
<hallyn> stgraber: mind you i don't care to leave the old etherboot-based kvm-pxe around.
<soren> To get upgrades to work, you need to replace kvm-pxe from etherboot with an empty package that depends/replaces: kvm-ipxe.
<soren> hallyn: You'll have to.
<stgraber> hallyn: you can have a Provide: kvm field in a binary package definition, that's what's done for things like mail-transport-agent
<stgraber> hallyn: mail-transport-agent has a package doesn't exist, but you can depend on it and the dependency will be solved if you install postifx or exim or ...
<soren> You could add an epoch to ipxe.
<hallyn> stgraber: ok, that has advantages, but then someone using etherboot-based kvm-pxe won't automatically be upgraded right?
<soren> Or just to kvm-ipxe (but that's really confusing).
<soren> hallyn: Right.
<stgraber> hallyn: indeed
<RoAkSoAx> hallyn: an easier solution is to do a Conflicts/Replaces to ensure the upgrade goes clean
<tumbleweed> urgh@epoch bumping
<soren> hallyn: Right, but then something needs to still build kvm-pxe.
<soren> er...
<soren> RoAkSoAx: Right, but then something needs to still build kvm-pxe.
<hallyn> tumbleweed: what is the downside?
<stgraber> yeah, I strongly recommend not to bump the epoch, especially for a package that's coming from Debian, unless you want to be the one merging it for the few years to come :)
<tumbleweed> hallyn: it'll never auto-sync again
<tumbleweed> hallyn: the epoch is for when upstream goes crazy and decides their next version is < the current one
<hallyn> i suspect they won't take the kvm-pxe package anyway, so i assume autosync won't work.
<hallyn> ok, so, i think i know what i need to do.
<micahg> hallyn: just because the current maintainer won't take it, doesn't mean in the future there wouldn't be room for consolidation
<hallyn> ipxe will provide kvm-ipxe; etherboot will provide an empty binary package that depends on kvm-ipxe.  both will provide kvm-pxe.
<RoAkSoAx> smoser: right, but wouldn't this work: 1. Remove binary package from etherboot 2. Add binary package to ipxe and add Conflicts/Replaces (kvm-ipxe <= 5.4.4-7ubuntu3)
<hallyn> RoAkSoAx: i think you meant stgraber :)
<micahg> RoAkSoAx: same problem since you're changing the versioning scheme for the binary in question
<hallyn> uh, no you didn't
<hallyn> all right let me go read up on how 'provides' works
<hallyn> thanks all
<RoAkSoAx> soren: err,  right, but wouldn't this work: 1. Remove binary package from etherboot 2. Add binary package to ipxe and add Conflicts/Replaces (kvm-ipxe <= 5.4.4-7ubuntu3)
<soren> RoAkSoAx: No.
<soren> RoAkSoAx: The whole problem is that ipxe's version is lower then etherboot's.
<soren> *than
<RoAkSoAx> soren: ahh right, didn't realize that :)
<soren> If it weren't we'd just move the kvm-pxe package to be built by ipxe.
<RoAkSoAx> yeah
<soren> That's the simple solution.
<micahg> hallyn's solution sounds sanest so as not to take over binaries from other packages
<soren> kvm-pxe is an Ubuntu specific addition. Why wouldn't be just move it?
<soren> micahg: ^
<soren> Moving a binary from one source package to another is fine. We do it every single release.
<hallyn> i'll have to check if anyone ever tried to push kvm-pxe to debian...
<micahg> soren: oops, I forgot it's built by etherboot
<soren> hallyn: I doubt it.
<hallyn> sigh
<micahg> soren: so, you're right, that would have been easiest :)
<soren> hallyn: I only added it to avoid getting etherboot into main.
<soren> hallyn: ..and because I didn't feel comfortable with the pxe ROMs from the kvm package.
<soren> I also don't really see what that would solve?
<soren> brb, coffee time.
<hallyn> soren: what it would solve is that then presumably Debian folks would have given ipxe a higher version # :)
<hallyn> is switching kvm-pxe from being a versioned binary package, to being a (unversioned?) virtual package ok?
<tumbleweed> hallyn: some of the issues here are discussed in http://wiki.debian.org/Renaming_a_Package ( method 2 )
<hallyn> thanks, reading now
<tumbleweed> creating a dummy that depends on the new package providing these files really seems the easiest way
<soren> hallyn: Making it a virtual package won't solve your problem.
<hallyn> soren: yeah i'm not doing that
<hallyn> soren: i'm just making kvm-pxe in etherboot an empty pkg depending on kvm-ipxe
<soren> hallyn: Consider the example given: mail-transport-agent. If that worked, you'd constantly have your mta replaced with whichever one had the highest version number :)
<hallyn> yeah, i realized that a few minutes ago - too bad though :)
<stgraber> soren: we might be getting interesting upstream version number wars then :)
<hallyn> soren: i'm playing in lp:~serge-hallyn/ubuntu/precise/ipxe/kvm-pxe-in-ipxe and lp:~serge-hallyn/ubuntu/precise/etherboot/kvm-pxe-notin-etherboot, fwiw
<stgraber> we could also create a default-desktop-environment or whatever else and see upstream start bumping their version number to become the default ;)
<tumbleweed> given that kvm-pxe only has one reverse dependency, this doesn't need to be very long-lived...
<hallyn> tumbleweed: it has one?  in precise?
<hallyn> qemu-kvm used to suggest it, but that switched recently to ipxe.
<tumbleweed> hallyn: yes, testdrive-common
<hallyn> ah
<hallyn> oh, jikes, etherboot fails to build for me.  oh maybe i hae to be on i386?
<mterry_> SpamapS, heyo.  did you see that libdbi-drivers failed to build?  It's internal autoconf macro is not looking in a multiarch dir for it
<Daviey> tumbleweed: if kvm-pxe is made a metapackage which depends on a NEW binary package kvm-pxe-files (or something) built from ipxe, we a are gold.
<Daviey> we don't NEED to use the same binary package name
<tumbleweed> exactly, that's the best way out of this, I think
<tumbleweed> hallyn: build deps are uninstallable for me on i386 too
<hallyn> Daviey: yeah, i didn't want to do that (bc i figure people are used to typing 'kvm-pxe') but that's what i'll do
<hallyn> tumbleweed, well jinkeys
<Daviey> kvm-pxe would need to stay in universe, and kvm depends (recommends?) on kvm-pxe-fils (or whatever)
<slangasek> cyphermox: bug #882817> what is nm-dispatcher.action?  It doesn't appear to be run here, but others are reporting it's a subprocess of NM getting killed on shutdown by sendsigs and causing problems
<Daviey> people still have an upgrade path, and etherboot stays in universe
<ubottu> Launchpad bug 882817 in rpcbind (Ubuntu) "shutdown screen stuck after upgrade to Ubuntu 11.10" [Undecided,Incomplete] https://launchpad.net/bugs/882817
<hallyn> Daviey: etherboot shoudl probably be gotten rid of actually!
<Daviey> hallyn: If it is dropped from debian, sure
<hallyn> Daviey: it won't build
<Daviey> hallyn: Does it FTBFS in debian aswell?
<hallyn> Daviey: and yes it's no longer indebian
<hallyn> only in lenny and squeeze
<Daviey> hallyn: well then, hell - drop it :)
<cyphermox> slangasek: AFAIK it's supposed to be a tiny program that just runs through /etc/NetworkManager/dispatcher.d to run the scripts there
<hallyn> Daviey: does anything dpeend on it though?
<mterry_> SpamapS, oh I think I have a fix for it
<Daviey> hallyn: Replace it with a meta/virtual package of the same or greater version string to give people an upgrade path until after precise.
<hallyn> Daviey: fine for kvm-pxe, but i dunno about etherboot itself, if it has users
<Daviey> hallyn: ipxe is a drop in replacement still, right?
<Daviey> with added foo.
<hallyn> Daviey: for my purposes, yes.  but i don't know about all of the roms
<hallyn> ebox-dhcp depends on etherboot
<Daviey> I believe it is still compatiable, including conf's
<hallyn> ACTION checks what that is
<slangasek> cyphermox: hmm; why would it be running at the same time as /etc/rc6.d/S20sendsigs?
<cyphermox> slangasek: I wonder if it's a race due to something else like dbus shutting down?
<Daviey> hallyn: I'd fire off an email to the ebox chaps and let them know that we plan to get rid of etherboot, i am certain they'd be happy to convert any code deps over.
<cyphermox> slangasek: I'd say it gets run when NetworkManager shuts down, because some interfaces are being taken down (thus change)
<slangasek> cyphermox: certainly not; dbus doesn't shut down until the 'deconfiguring-networking' event is received
<cyphermox> ok
<hallyn> Daviey: ok.  so then to drop it, do i just remove the source and make sure no files get installed by it, and tweak control to depend on ipxe?
<slangasek> and that's emitted by /etc/rc6.d/S35networking
<Daviey> hallyn: you need to raise a bug for an AA to remove it.
<slangasek> and /etc/rc6.d/S20sendsigs should finish before /etc/rc6.d/S35networking is called
<slangasek> so something's odd here - something that I can't reproduce locally
<slangasek> but that's been reported by multiple users of NFS
<hallyn> Daviey: i don't want to remove it yet though right?
<Daviey> hallyn: I don't see why not?
<cyphermox> slangasek: I have tried but failed to reproduce it as well. the thing is NetowrkManager is "stop on stopping dbus", and the only thing I can think of would be for NM to run this when it's taking down interfaces
<slangasek> hmm
<cyphermox> slangasek: I'll take a look at where this gets run
<slangasek> cyphermox: ok, thanks
<hallyn> Daviey: because etherboots and kvm-pxe, with their (bumped) verison #s, need to stick around and depend on ipxe and kvm-ipxe?
<Daviey> hallyn: Hmm.. it might be better to replace it with the meta package, rather than processing a removal + new
<cyphermox> (but a little later, I need to run to catch a bus now)
<slangasek> cyphermox: if you have any questions about the rest of the shutdown sequence, just ask
<hallyn> Daviey: hm, meta package.  new to me.
<cyphermox> slangasek: sure
<Daviey> hallyn: empty package, that simply Depends on something else.. aka virtual
<Daviey> hallyn: ie, ubuntu-desktop
<hallyn> Daviey: so how/were do I define that?
<hallyn> oh, virtual.  but then it's not versioned.
<Daviey> yeah, it is.
<hallyn> Daviey: the problem with that is that users of kvm-pxe won't ever be upgraded
<hallyn> oh?
<tumbleweed> Daviey: meta != virtual
<Daviey> hallyn: Yeah.. So...  we upload etherboot which is now an EMPTY package, other than a Depends on kvm-ipxe (suggestion)
<Daviey> kvm-ipxe is built from ipxe
<hallyn> Daviey: ok, sure, I guess that's what I was suggesting, except i was goin to just rm -rf src/ etc  :)
<Daviey> etherboot source package provides binary package kvm-pxe
<hallyn> Daviey: so, why would an AA need to be involved?
<Daviey> tumbleweed: right, sorry
<Daviey> hallyn: they don't... i was thinking procesing a removal of etherpad.. we don't want to do that
<hallyn> Daviey: ok.  sound like we were agreed all along then :)  thanks
<hallyn> Daviey: oh, ebox-dhcp only suggests etherboot.  so i see no problem
<hallyn> i'll get on it
<Daviey> hallyn: well they should still be kept in the know.
<hallyn> Sure, but nothing should break at least
<hallyn> Daviey: I've sent them an email fwiw
<hallyn> Daviey: everyone seems to use 'DEBIAN' for meta packages rather than debian/.  Is that convention?
<hallyn> ah i see now.  apparently it's required
<infinity> hallyn: ?
<hallyn> infinity: I'm switching etherboot into a meta package depending on ipxe.  trying to figure out the best way
<infinity> hallyn: That ? was for the debian versus DEBIAN thing. :P
<hallyn> oh,
<infinity> hallyn: debian/ is the directory in a source package that contains rules, etc.
<infinity> hallyn: DEBIAN is the control directory in a binary package's pre-pack state.
<hallyn> http://jeffhoogland.blogspot.com/2011/08/howto-create-debian-meta-package.html  says DEBIAN is used for meta packages...
<hallyn> <frown>
<infinity> That tutorial is not creating a source package.
<infinity> It's creating a raw binary package by hand.
<SpamapS> mterry_: I have a fix
<infinity> Just do a source package the same way as you always would (dh_make, for instance), and rejoice at the part where you have no actual source to build.
<mterry_> SpamapS, I already uploaded one (though it failed to build for a different, temporary reason while mysql is crazy)
<SpamapS> UGH
<hallyn> well there is pre-existing source.  i'm trying to figure out how conservative to be with rm -rf
<infinity> So, nothing to install, etc, etc.  Just a debian/control to fiddle with, and a rules file that does nothing in the build target.
<SpamapS> mterry_: mysql should not be crazy anymore
<mterry_> SpamapS, sorry, thought I said I had a fix
<SpamapS> mterry_: you did, but while you were saying that, I was finishing my test build for my fix
<infinity> hallyn: If there's a pre-existing source package that you want to maintain history for, deleting everything but control, rules, chagelog, and copyright, and then fixing them to do very little.
<mterry_> SpamapS, mysql-client and mysql-server are both 5.5 now?
<SpamapS> mterry_: yes
<infinity> hallyn: (Though you're just as well starting from scratch and just including the old changelog)
<SpamapS> as of a few hours ago
<SpamapS> maybe not in arm actually
<mterry_> SpamapS, I just uploaded a moment ago, not the case on the buildds yet
<hallyn> infinity: no point in keeping the source?  copyright files?
<mterry_> maybe hasn't propogated
<infinity> hallyn: The only copyright that matters once you've switched to a pure meta source is mentioning the packaging copyright in debian/copyright.
<SpamapS> Hmm..
<infinity> hallyn: Since there's no other source around anymore, right?
<hallyn> infinity: oh, right, so, i should bump the version number to get a new .orig.tar.gz then?
<hallyn> infinity: right, no other src
<infinity> SpamapS: Finished 16 hours ago (took 7 hours, 46 minutes, 46.7 seconds)
<mterry_> doko, speaking of, do you have a fix for gcj-4.6's FTBFS?  I think I do
<infinity> hallyn: There shouldn't be an orig anymore.  But yes, you'll need a higher upstream version number.
<infinity> hallyn: And then switch to native.
<hallyn> native?
<mterry_> SpamapS, apt-cache show mysql-client on my machine shows 5.1
<SpamapS> crap.. how did I miss that mysql-client needed to be a meta package too? :-P
<infinity> As in, use a foo_1.2.3.dsc version instead of foo_1.2.3-1.dsc version.  And you'll just get a tar.gz and .dsc
<infinity> Hard to have a Debian diff when there's no upstream source to diff against. ;)
<hallyn> infinity: ok, thanks.
<SpamapS> mterry_: I believe the fact that mysql-common breaks mysql-client-5.1 causes apt to choose mysql-client-5.5 instead
<SpamapS> but I could be wrong
<mterry_> SpamapS, the buildd didn't choose client-5.5, it just bailed
<infinity> SpamapS: The break might force an upgrade, but the metapackages were there for that reason. :)
<SpamapS> Ahh yeah that makes since
<SpamapS> indeed, the meta packages are coming back, I just forgot to resurrect the mysql-client one. :-P
<infinity> Has Christian given up Debian maintenance of MySQL?  He used to get this sort of thing right first go.
<SpamapS> Everyone has.
<infinity> Hrm, so I see.
<SpamapS> Norbert has kept the flame burning..
<infinity> Maybe I should come out of hiding sometime.
<SpamapS> But he's had *zero* time the last year
 * Laney sees a certain person has been maintaining -5.5 :-)
<SpamapS> Yeah its basically just me right now.
<infinity> Yeah.  And I don't love you half as much as ch.
<infinity> Mostly because he buys me cookies.
<SpamapS> I'd love *anybody* who knew all the pitfalls and trapdoors in this process and wanted to help out. :)
<infinity> I'm hat-shuffling a lot right now, but I'd be happy to come back and help in a few weeks.  That won't help you with the current pain, though. :P
<infinity> I wonder if I'm still in the right alioth groups and such...
<SpamapS> I think by then I'll have found most of the sharp sticks by falling on them. :)
<infinity> Probably.  But there are always new versions. ;)
<SpamapS> But it would be good for you to come help in case I bleed out.
<infinity> And bugs.
<infinity> So many bugs.
<SpamapS> Yeah I triaged for 4 hours last week.. barely made a dent. :-P
<SpamapS> Hrm the test suite is broken too...
<SpamapS> need to figure that one out.
<infinity> Apparently, I'm a "Senior Developer" on pkg-mysql.
<infinity> Shiny.
<infinity> So, I assume I stil have SVN write access. :P
<SpamapS> woot
<SpamapS> I'd actually love to move it to bzr or even git. svn.. so.. annoying
<infinity> I'm remarkably unpicky.
<infinity> And back when we set up all the LAMP pkg-$foo bits, SVN was better than, well, every other option.
<infinity> You can almost certainly blame me.
<infinity> Especially if it has a weird branch/directory structure.
<infinity> Apparently, no one ever saw eye-to-eye with me on my SVN workflow. :P
<SpamapS> it works fine right now..
<SpamapS> just not awesome
<SpamapS> mterry_: btw, the include dir for libmysqlclient-dev isn't multi-arched
<SpamapS> mterry_: best way to get the include and libdirs is just to run 'mysql_config --variable=pkglibdir'
<SpamapS> mterry_: or mysql_config --variable=pkgincludedir
<SpamapS> mterry_: I will upload a fixed libdbi-drivers once mysql-client is a meta package again
<hallyn> Daviey: soren: here's what I've got for a new met package to replace etherboot.  http://people.canonical.com/~serge/kill-etherboot
<hallyn> Needless to say this is not a friday-night upload kinda thing :)
<mterry_> SpamapS, it's not multiarched now, but I've seen libraries with a header in the multiarch include directory, so it seemed harmless to include it
<mterry_> plus, the other config flags use that idiom
<SpamapS> mterry_: its actually not harmless tho.. it will fail to find them and abort configure. :-/
<mterry_> SpamapS, I built with it...
<SpamapS> mterry_: libdbi-drivers is fairly broken. :-P
<SpamapS> mterry_: hrm.. had problems here.. but.. like I said, its just broken. :-P
<mterry_> SpamapS, I assumed it found them because /usr/include is always in the include path
<mterry_> SpamapS, well regardless, I could believe I screwed something up.  Please fix as you see fit  :)
<SpamapS> mterry_: its silly in that it just does file-finds not actual compile tests.
<soren> hallyn: 404?
<soren> hallyn: ...but you say you're adding a new meta package? What for?
<hallyn> soren: not a new one, replacing etherboot with a meta package
<soren> hallyn: Oh.
<soren> hallyn: Err..
<soren> hallyn: Hm. Ok.
<soren> hallyn: Why?
<hallyn> soren: don't know wha thappened that time.  http://people.canonical.com/~serge/kill-etherboot/etherboot_5.4.5.dsc should be up now.
<hallyn> soren: why? bc etherboot and kvm-pxe need to stick around with higher # to make ppl upgrade to ipxe and kvm-ipxe?
<soren> hallyn: But etherboot didn't used to be a metapackage.
<hallyn> soren: right.  why is that bad?
<Daviey> soren: etherboot become a just a etherboot source package providing a meta binary package of kvm-pxe, which depends on kvm-ipxe, providing an upgrade path.  ipxe will now build kvm-ipxe.
<Daviey> we are deprecating etherboot.
<soren> What if someone still uses it?
<soren> Not kvm-pxe. The other stuff.
<soren> I'm assuming there's still "other stuff"?
<Daviey> soren: to the best of our knowledge, ipxe itself is still a drop in replacement; still accespt the same config file format.
<hallyn> soren: then they are switched over to ipxe, which is supported?
<Daviey> the only reverse depends, hallyn is emailing.
<Daviey> (it's a suggest)
<hallyn> soren: etherboot won't build any more.
<soren> What's it status in debian?
<Daviey> Gone.
<soren> *its
<soren> Ah.
<soren> Ok, then I don't care :)
<Daviey> $ rmadison -uqa etherboot etherboot | 5.4.4-6~bpo50+1 | backports/lenny | source, all etherboot | 5.4.4-9         | squeeze         | source, all
<soren> -uqa means "show both Debian and Ubuntu"?
<soren> ERr..
<Daviey> no, just debian
<soren> No :)
<soren> Yeah.
<hallyn> and, fwiw, lp:~serge-hallyn/ubuntu/precise/ipxe/kvm-pxe-in-ipxe/ is the corresponding ipxe update
<hallyn> soren: ok, cool, thx.  Daviey: obviously no hurry for today, but if you could have a look in the next few days, i'd appreciate it :)
<soren> I didn't realise it was gone from Debian. That simplifies it quite a bit.
<Daviey> hallyn: Yeah, i'll check it out over the weekend/monday, unless soren is keen to touch it now? :)
<soren> Gosh no.
<hallyn> Daviey: great, thx, ttyl
<Daviey> o/
<soren> I couldn't even read your rmadison output without getting confused :)
#ubuntu-devel 2011-11-26
<buxy> slangasek: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/896452 => want to have a look maybe? M-A: same failing to install due to a difference on changelog.Debian.gz...
<ubottu> Launchpad bug 896452 in dpkg (Ubuntu) "package libqt4-xmlpatterns 4:4.7.4-1ubuntu4 failed to install/upgrade: ErrorMessage: package libqt4-xmlpatterns is already installed and configured" [Undecided,New]
<slangasek> buxy: yeah, the changelogs are mostly symlinks, and they're apparently architecture-dependent; we should reassign this to qt4-x11
<cjwatson> isn't that bug 893826?
<ubottu> Launchpad bug 893826 in pkgbinarymangler (Ubuntu) "symlinked docs are different between architectures, depending on dpkg-deb package order" [Medium,Triaged] https://launchpad.net/bugs/893826
<slangasek> cjwatson: ah, conceivably
<SpamapS> slangasek: wow.. libmysqlclient.. worst.. library.. evar
<SpamapS> slangasek: so many one-off autoconf macros to find it poorly
<slangasek> heh
<infinity> SpamapS: I'm not entirely sure you can blame MySQL for that one.
<infinity> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<SpamapS> infinity: monty taylor seems to blame mysql for that.. ;)
<SpamapS> infinity: and you have to admit.. in the land of library authors.. libmysqlclient is the court jester
<infinity> SpamapS: That's pretty unfair to libpng.
<infinity> SpamapS: And libgd.
<infinity> SpamapS: And, actually, almost every image-processing library ever written.
<SpamapS> ;)
<bkerensa> slangasek: You know what the publickey permission denied message means when I try bzr push
<bkerensa> disregard (I forgot to submit my new key)
<geser> cjwatson: do you mind if I merge vim? you're TIL due to the perl transition
<cjwatson> geser: go ahead
<cjwatson> thanks for asking
<jtaylor> cjwatson: are you planning on fixing svn bug 881862 in oneiric?
<ubottu> Launchpad bug 881862 in subversion (Ubuntu) "svn up Segmentation Fault" [Undecided,Triaged] https://launchpad.net/bugs/881862
<cjwatson> jtaylor: not at present
<cjwatson> I encourage somebody else to do so - I can't take on SRUs for everything I happened to touch as part of the Perl transition, sorry
<geser> cjwatson: do you know if the ppc64 work-around (DEB_GCC_NO_O3) in vim since natty is still needed? as I can't easily check if it's still needed, I keep this change in every merge
<cjwatson> geser: that experimental port is no longer active, so feel free to drop it
<SpamapS> cjwatson: the transition tracker seems confused.. several things are shown red, but they clearly depend on libmysqlclient18 ..
<cjwatson> SpamapS: can you give me an example?
<slangasek> bkerensa: "publickey permission denied" - that you don't have an ssh key that lets you access that server?
<SpamapS> cjwatson: mysql++
<SpamapS> cjwatson: Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libmysqlclient18 (>= 5.5.13-1), libstdc++6 (>= 4.6)
<SpamapS> thats libmysql++3
<SpamapS> cjwatson: also mysql-ocaml
<SpamapS> OH .. wait.. hmm
<SpamapS> the -dev libs still have libmysqlclient16-dev ..doh
<SpamapS> cjwatson: disregard, I get it
<JuN1x> Hi Everybody, What is the policy to import a Debian testing package ?
<petar> i'm unable to find the central repository for all ubuntu/debian source packages.. some place where i could take a look at the changes/commits and for example checkout older versions. any ideas?
<infinity> petar: Your first mistake is assuming such a place exists.
<enrico> Someone decided to subscribe me to a launchpad bug (655831) and it happened without any confirmation on my side. 1. WTF?  2. How do I ubsubscribe without logging into launchpad?  3. Can I report the thing as abuse, and how?
<infinity> petar: Older Debian source packages can be found on snapshot.debian.org, and older Ubuntu source packages can be found on launchpad (follow the "publishing history" for a source package).
<infinity> petar: But, in both cases, while sometimes the packages have been maintained in revision control, the authoritative versions are the source packages themselves, not any VCS that may or may not have been employed.
<petar> wow, i had no idea..
<petar> thanks
<infinity> enrico: I believe the only person who can unsibscribe you is you.
<enrico> infinity: and anyone can subscribe me without my confirmation or consent?
<infinity> enrico: (And by "you", I mean you'd need to be authenticated with LP to do so)
<infinity> enrico: And yes.  Just like any bug tracker, really.
<enrico> infinity: how about the procedure for reporting the abuse?
<mdeslaur> enrico: how many bugs did you get subscribed to?
<infinity> enrico: Unsure.  Might want to ask in #launchpad.
<enrico> mdeslaur: it does not matter how many bugs. Being subscribed to a mailing list without my consent is abuse
<enrico> infinity: thanks
<infinity> enrico: I don't know any bug tracker that doesn't have that feature.
<enrico> infinity: at least the Debian BTS doesn't require you to have an account in the system in order to unsubscribe
<infinity> enrico: It doesn't have accounts...
<mdeslaur> enrico: either the person thought you needed to be subscribed, or it's a mistake.
<enrico> infinity: quite. Isn't that nice?
<infinity> enrico: Note that you *have* an LP account.
<infinity> enrico: It's impossible to subscribe someone who doesn't.
<enrico> infinity: yes I do, but it asks me odd things at login
<infinity> (whereas, I can subscribe literally any email address to a Debian bug) :P
<infinity> Not arguing that one method's better than the other.  I tend to prefer debbugs too.
<mdeslaur> enrico: actually, there's an email interface to launchpad: https://help.launchpad.net/Bugs/EmailInterface
<infinity> But.  Neither seems more broken than the other.
<enrico> infinity: including confirmation of "making some of my personal information available", which I wouldn't want to give
<mdeslaur> enrico: as long as you gpg sign your email, you can unsubscribe to the bug
<infinity> enrico: It's making what launchpad knows available to launchpad.
<infinity> enrico: It's an SSO system that asks you for confirmation to pass your OpenID creds to each new domain that asks.
<enrico> infinity: pardon my naivety, but "making what launchpad knows available to launchpad" is nonsense to me
<infinity> enrico: Your account in launchpad is tied to a single-sign-on account at login.ubuntu.com.
<infinity> enrico: Any new domain asking for access to that OpenID account (including launchpad.net) has to ask permission.
<infinity> enrico: Hence the "do you permit us to tell (site) certain things about you?"
<enrico> infinity: right, after your explanation I know what it's trying to do, although the login page does its best not to tell me :(
<infinity> It could perhaps be a bit less terse.
<infinity> Or a lot less. :P
<infinity> Though, more verbose confuses everyone else.
<infinity> I might bring it up and see if a happy medium of "click here for more information" could be made or something.
<enrico> infinity: a "what's this?" link would be what I would have expected, idneed
#ubuntu-devel 2011-11-27
<broder> is there a tool for mass-closing bugs? i think it's probably about time to clean out the dapper-backports bug queue
<broder> ...also feisty-backports, it turns out
<SpamapS>  * State: Failed to build
<SpamapS>  * Duration: 18 hours
<SpamapS> *sigh*
<JackyAlcine> O.o that sucks.. :/
<micahg> SpamapS: are you fixing gnash or should I add it back to my list?
<SpamapS> micahg: I am leaving failures like that to the end.. so if you want to handle gnash.. have at it.
<micahg> SpamapS: ok, it's the same failure as I had for the original merge which is why I haven't fixed it yet, but will try to get to it soon (it's due to Firefox 8+)
<SpamapS> micahg: ok thanks!
<infinity> SpamapS: Ugh, why is MySQL still building with gcc-4.5?
<infinity> SpamapS: Oh, nevermind.  Looking at the bug from the changelog.
<cjwatson> SpamapS: akonadi-backend-mysql still depends on mysql-server-core-5.1, mysql-client-core-5.1, by the looks of things; I guess the transition tracker doesn't show that
<cjwatson> SpamapS: (breaks Kubuntu image builds)
<infinity> test 1082...OK (556 out of 628, remaining: 01:08)
<infinity> ^-- Counting is hard.
<cjwatson>   2618kB    17kB/s - Uploading data to master branch - Stage:Fetching revisions:Inserting stream:Estimate 322/108
<cjwatson> infinity: ^- ditto
 * infinity snickers.
<infinity> Also...
<infinity>  09:31:19 up 8 days, 13:41,  7 users,  load average: 5.13, 4.47, 4.87
<infinity> ^-- Does this mean my Panda passes the "server-class" test.  It hasn't died in over a week!
<SpamapS> cjwatson: will fix akonadi
<cjwatson> SpamapS: thanks
 * infinity apologises to the buildds.
<ockham_> hi, i'm trying to assign a version number to a binary package that is different from the source package's.
<ockham_> can someone help me or point me to something?
<tumbleweed> ockham_: it's doable by passing options to dpkg-gencontrol, but obviously this is a very weird thing to do, so be careful with it :)
<ockham_> tumbleweed: hi, thx for your reply. it's because of my pysolfc package (which you might recall) -- it's version 2.0, but it's superseding pysol 4.82 or so...
<ockham_> tumbleweed: so if i want my pysolfc control file to provide a dummy pysol package for transition, i'd need to assign in a version number > 4.82.
<tumbleweed> ockham_: how about just Replaces + Breaks ?
<tumbleweed> ah, ok
<ockham_> tumbleweed: i know; but does that provide a reliable upgrade path, given that version numbers issue?
<ockham_> tumbleweed: could you elaborate at what point to pass options to dpkg-gc?
<tumbleweed> it has a manpage
<ockham_> tumbleweed: hm, i checked it, but i couldn't really figure it out.
<ockham_> tumbleweed: do you think any other way would be preferrable? so far, i've even had separate source packages for the dummies, but i guess that's even worse.
<cjwatson> is it your own package, or a modification of one from elsewhere (e.g. Debian)?
<ockham_> cjwatson: sry, been afk for a while. it's my package -- been in ubuntu since lucid, and searching for debian sponsorss since then :-/
<SpamapS> hrm...
<SpamapS> aolserver's build process seems... almost totally nuts
<JanC> SpamapS: I always wondered if anybody still uses that?  âº
<cjwatson> ockham_: so if you're the original packager, then TBH, I'd consider just adding a 1: epoch to the source package as the path of least resistance; only if you're certain the transition is permanent, though
<cjwatson> ockham_: (I wouldn't suggest this if the package had a prior existence somewhere else, as that would mean you'd never be able to merge again unless you convinced the packaging-upstream to add the epoch as well)
<ockham_> cjwatson: thx. i was considering that, but http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519752#35 suggested the other way. but i think i'll probably really use  the epoch approach.
<ubottu> Debian bug 519752 in wnpp "ITP: pysolfc -- A Python solitaire game collection" [Wishlist,Open]
<ockham_> cjwatson: btw: TBH=?
<JanC> TBH = to be honest
<JanC> ockham_: ^^^
<cjwatson> yes
<cjwatson> ockham_: although it's technically an abuse of epochs, I think it's overall less confusing than using dpkg-gencontrol -v to fiddle with the version of a single binary package, so I respectfully disagree with Ariel
<cjwatson> although not enough to fight about it
<cjwatson> or I suppose you could add an epoch just for that binary package, which might be less confusing than adding some fixed integer to the version
<cjwatson> that might be a reasonable compromise position
<micahg> we've got an example of that in the thunderbird source
<cjwatson> on rereading I guess that's actually Ariel's second choice
<ockham_> micahg: thx, i'll take a look into that.
<ockham_> cjwatson: i'm a bit confused. so i'd end up using the epoch field only for that transitional binary package? not the entire source package?
<cjwatson> yeah
<cjwatson> VERSION := $(shell dpkg-parsechangelog | awk '/^Version:/ { print $$2 }')
<cjwatson> near the top of debian/rules
<cjwatson> then:
<cjwatson> override_dh_gencontrol:
<cjwatson>         dh_gencontrol -Npysolfc
<cjwatson>         dh_gencontrol -ppysolfc -- -v"1:$(VERSION)"
<cjwatson> assuming you're using dh, anyway
 * tumbleweed likes that approach
<ockham_> cjwatson: yup, using dh. thx, sounds good.
<ockham_> cjwatson: just to make sure i'm doing this correctly: this will make the pysolfc binary package version 1:2.0-1, which is greater than pysol's 4.8.something
<ockham_> but my dummy pysol will then be 2.0-1 which is less than 4.8.
<ockham_> so don't i have to use dh_gencontrol for pysol (not pysolfc)?
<tumbleweed> ockham_: yes
<ockham_> tumbleweed: and what about breaks/replaces/conflicts?
<tumbleweed> ockham_: Breaks + Replaces, yes
<mneptok> anyone have any ideas why a machine with a clean Xubuntu install to a dedicated / while preserving an exisiting /home from a previous version fails to allow a login?
<mneptok> credentials are correct, but supplying them just returns to the LightDM login screen
<mneptok> (also, it seems Xubuntu took it upon itself to encrypt that existing /home, without ever asking if it was OK to manipulate the data. Bad. very, very Bad)
<lifeless> no bikkie for xubuntu
<mneptok> amen
<mneptok> do NOT encrypt my data without my permission. it's mine. i'll decide.
<Ampelbein> mneptok: What installation iso did you use? I didn't have that problem while testing xubuntu.
<mneptok> alt-i386
<penguin42> mneptok: I'd check the .xsession-errors of the user you're trying to log in as for errors and the lightdm logs
<mneptok> alt-F2 is not getting me an alternate TTY
<mneptok> and i cannot seem to get a GRUB menu :(
<penguin42> mneptok: Have you ever noticed there are some days when computers just don't want to work with you?
<mneptok> penguin42: not really. Debian is fairly predictable. >:)
<mneptok> it's very clear that the existing $HOME was encyoted without permission
<mneptok> YAY! GRUB menu at last!
<penguin42> mneptok: Might be worth checking the logs from the installer - they should be somewhere
<mneptok> the only thing left in this user's $HOME is "Access-Your-Private-Data.desktop" and "README.txt"
<mneptok> and yet df -h reports the partition as 20GB used. so the data is there, it's just the installer decided to encrypt it without permission
<mneptok> is there an easy way to reverse this encryption?
<mneptok> kirkland: hjalp?
<lifeless> mneptok: what sort of encrpyiotn?
<lifeless> mneptok: should be a simple unmount to get back to the original data
<mneptok> lifeless: ecryptfs $HOME
<mneptok> lifeless: /home/$USERNAME that exisated from a previous install was encrypted with ecryptfs without prompting. to say i am disappointed is a massive understatement.
 * mneptok tries to find out how to decrypt this from a command line
<cjwatson> ockham_: sorry, yeah, I mixed up pysol and pysolfc
<ockham_> cjwatson: np. just got a little confused...
<cjwatson> mneptok: can you post /var/log/installer/cdebconf/questions.dat somewhere?
<ockham_> i'm building it right now...
<mneptok> cjwatson: can try
<cjwatson> /var/log/syslog wouldn't hurt either but is secondary
<mneptok> brb. need USB key
<mneptok> cjwatson: http://birdhouse.org/~mnep/cjwatson
<mneptok> bleh. fixing perms
<mneptok> fixed.
<lifeless> mneptok: its not really encrypted
<lifeless> mneptok: the existing data is just masked by the ecryptfs layer
<cjwatson> mneptok: um, sorry, I meant /var/log/installer/syslog not /var/log/syslog
<mneptok> cjwatson: oh, of course you did. my bad. brain fart.
<cjwatson> IRC scrollback suggests my bad, in fact ;-)
<mneptok> cjwatson: but i should have interpreted it
<ockham_> my pysolfc build failed:
<ockham_> dpkg-genchanges: error: badly formed line in files list file, line 2
<ockham_> dpkg-buildpackage: error: dpkg-genchanges gave error exit status 25
<ockham_> E: Failed autobuilding of package
<mneptok> cjwatson: the correct syslog is now there
<mneptok> lifeless: the "ecryptfs layer" should not even exist unless i was asked if i wanted it at *all*
<ockham_> btw, what does the -N arg to dh_gencontrol do? couldn't find it in the manpage.
<cjwatson> mneptok: 403
<cjwatson> ockham_: man debhelper
<mneptok> cjwatson: grah. fixed.
<cjwatson> that is very odd.  as best as I can tell, the installer did nothing with ecryptfs at all, and should have configured it off
<lifeless> mneptok: I agree; I"m not arguing that. I'm noting that recovery should be easy.
<mneptok> cjwatson: and yet the user's existing $HOME is devoid of anything that was there before
<cjwatson> no trace in the logs, and it didn't hit the ecryptfs paths in user-setup
<cjwatson> I believe you, I'm just trying to figure out *how*
<cjwatson> as lifeless said, though, a umount should correct this at least temporarily?
<mneptok> cjwatson: this happened on 2 subsequent installs, too.
<kirkland> installs of what version of ubuntu?
<cjwatson> are these logs from the first such install?
<cjwatson> kirkland: it's all in the logs
<mneptok> cjwatson: second
<cjwatson> do logs from the first exist?
<mneptok> cjwatson: sadly, no
<cjwatson> in fact, the installer AFAICT didn't even install ecryptfs-utils here
<mneptok> is there an easy way for me to decrypt this dir from a shell, rsync the data to another location, and see if i can login as a new user? my ecryptfs experience is limited
<cjwatson> can I see the output of 'mount'?
<mneptok> cjwatson: correct, the -utils pkg was not installed
<ockham_> any clue what's the reason for those errors? ^^^
<cjwatson> ockham_: hard to say without the full og
<cjwatson> *log
<cjwatson> and preferably a copy of the source package for reference
<ockham_> cjwatson: i'll pastebin the log
<cjwatson> mneptok: I'm wondering if a finger-fumble selected encryption on the first install, but then not on the second install
<cjwatson> is that at all possible?
<cjwatson> the bug is then that you get left in a confusing intermediate state
<mneptok> cjwatson: neither install ever asked me about encrypting homes
<mneptok> cjwatson: output of "mount" now in that same dir
<cjwatson> hmm
<cjwatson> so it deliberately doesn't ask if a home directory already exists
<cjwatson> but AFAICT it then doesn't configure encryption
<cjwatson> is it possible that the prior state of the system, before this sequence of installs, in fact had an encrypted home directory there?
<cjwatson> that would explain the symptoms
<mneptok>  /home is/was a separate partition. i told debian-installer to use that partition as /home, but not format it
<ockham_> log is at http://pastebin.com/erF4K6ha
<cjwatson> mneptok: understood; is it possible that ecryptfs was in use beforehand?
<cjwatson> I do see a bug here that in that situation we don't arrange for ecryptfs-utils to be installed so that it can decrypt the home directory
<mneptok> not likely
<cjwatson> but possible?  it does explain things perfectly
<mneptok> and i just created a new user, who also gets thrown back to a GUI login after entering credentials
<cjwatson> because in that case, you'd have /home/$USER/.ecryptfs and no arrangements for mounting it in the new system
<cjwatson> I just can't find any other way this could have arisen
<cjwatson> if that is the case, then installing ecryptfs-utils and ensuring that the user has the same password as before should be enough
<mneptok> OK, i'll try it
<cjwatson> I'm not sure why the new user login doesn't work; it's not entirely obvious to me that that has the same cause
<cjwatson> might be worth trying from a console to reduce possibilities
<mneptok> cjwatson: installing ecryptfs-utils allowed me to login
<mneptok> cjwatson: my deep and abiding affection for you has somehow become deeper
<mneptok> :)
 * mneptok backs up to an external drive and prepares to do a 100% clean install
<cjwatson> :-)
<cjwatson> I don't know how to convert from an encrypted home to an unencrypted home
<cjwatson> except of course by rsyncing everything off and back on again
<mneptok> cjwatson: exactly what i'm doing. rsync to an external. do a complete re-partiton of the disk, re-install and NOT use ecryptfs.
<cjwatson> and this is definitely a bug in user-setup for failing to install ecryptfs-utils when /home/$USER/.ecryptfs exists, which at the very least was true in the second and subsequent installs
<mneptok> one of my new personal rules is "Never send FUSE to do dm-crypt's job."
<cjwatson> though my hypothesis about the original cause is probably unprovable either way at this point
<mneptok> cjwatson: i would always cover my tracks sufficiently to ensure PEBKAC can only be a theory ;)
<kirkland> mneptok: fyi, ecryptfs is not FUSE
<kirkland> mneptok: its an in-kernel filesystem
<kirkland> encfs == fuse
<kirkland> encfs != ecryptfs
<mneptok> kirkland: when i was a whippersnapper we configured dm-crypt by hand. in a blizzard. while walking 25 miles to vote against Hoover. AND WE LIKED IT!
<mneptok> kids these days ....
<mneptok> :)
<broder> could i get somebody to accept the sru nominations for bug #629646?
<ubottu> Launchpad bug 629646 in libgweather "Locations using bom.gov.au for forecast data no longer can no longer retrieve forecast data" [Medium,Fix released] https://launchpad.net/bugs/629646
<tumbleweed> broder: doing it
<broder> thanks
<ockham_> cjwatson: about pysolfc... ^^^
<ockham_> cjwatson: can you take a look at the log?
<tumbleweed> ockham_: the error looks unrelated
<ockham_> tumbleweed: really? i don't think it's been there before
<tumbleweed> dpkg-genchanges: error: badly formed line in files list file, line 2
<tumbleweed> ockham_: sorry, can't be any more help without the source
<ockham_> tumbleweed: one moment...
<ockham_> tumbleweed: would you suggest i just push this faulty state of affairs to the games team git repo?
<ockham_> tumbleweed: or is that a bad idea?
<ockham_> ok, i'll just do it...
#ubuntu-devel 2012-11-19
<ScottK> I'd appreciate it if someone who understands how to troubleshoot multi-arch stuff would look at Bug 1079836.
<ubottu> Launchpad bug 1079836 in python2.7 (Ubuntu) "Python 2.7 fails to install after upgrade from 12.04 to 12.10" [Undecided,New] https://launchpad.net/bugs/1079836
<infinity> ScottK: I'm having a hard time not blaming that on his local from-source installation having been not entirely cleaned up...
<infinity> ScottK: Responded to the bug, however.
<ScottK> infinity: Thanks.  You're probably right.
<jimi_c> is it normal that the desktop iso only has a handful of .deb files on it, whereas the server iso has many more?
<jimi_c> i run the cobbler project, and just tried to import the 12.10 desktop distro and noticed the issue, since cobbler is looking for the linux-headers deb file
<StevenK> The server uses the alternate installer, the desktop iso uses Ubiquity and a squashfs.
<jimi_c> will the desktop version work with a normal preseed?
<pitti> Good morning
<dholbach> good morning
<ion> hai
<jibel> pitti, auto package tests are broken today. There is a bug in cloud images. The default user is not added to sudoers and cannot execute anything as root. I'll find a workaround until it get  fixed.
<pitti> jibel: thanks for letting me know
<pitti> jibel: can we use yesterday's?
<jibel> pitti, no it was already broken. Creation of the image runs fine because it runs as root, only the tests fail afterwards when then run through sudo.
<pitti> jibel, cjwatson: do you have time to talk about britney/autopkgtest now or in 10 mins?
<jibel> pitti, I do
<pitti> jibel, cjwatson: I'm hanging out in Platform QA -> Meeting room
<cjwatson> Yeah, 10 mins
<OdyX> tkamppeter: Q regarding foomatic-db-compressed-ppds: all cups interfaces I could check here (:631, system-config-printer-kde), show duplicated driver entries for foomatic-db-compressed-ppds (e.g. OKI B6300): what is at fault? compressed-ppds that has both "DRV" and "MFG" entries or interfaces that don't filter ?
<jibel> cjwatson, https://code.launchpad.net/auto-package-testing/
<jibel> cjwatson, http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/jenkins/trigger-adt-test
<tkamppeter> OdyX, system-config-printer filters duplicate entries, I do not know why system-config-printer-kde filters them, too. The best would be to add filtering of duplicate entries to pyppd.
<OdyX> tkamppeter: /usr/lib/cups/driver/foomatic-db-compressed-ppds list | grep B6300-Postscript
<OdyX> tkamppeter: ^ does the output of that make sense ?
<OdyX> tkamppeter: that looks like a line-split wrongly placed aftter TP; and before MFG, no ?
<hrw> doko: can you check one thing for me? "apt-get source gcc-4.7;cd gcc-4.7-*;echo aarch64 >debian/target;debian/rules patch"
<hrw> Applying patch svn-doc-updates.diff
<hrw> patch: **** Only garbage was found in the patch input.
<hrw> Patch svn-doc-updates.diff does not apply (enforce with -f)
<cjwatson> pitti: oh, OK, I got rid of all but one of the python-apt stderr failures :)
<pitti> cjwatson: oh wow, that was quick!
<cjwatson> no, I mean last week or before
<cjwatson> pitti: I suspect some of the remainder is fallout from gnupg being stricter about long IDs
<jibel> pitti, I worked around the bug in VMs used for adt and re-ran apport.
<pitti> jibel: cheers! I didn't even see that fail, I guess it wasn't mirrored to the public instance
<jibel> pitti, interesting, publication stopped 2 days ago :(
<doko> hrw, sure, just disable it for now
<pitti> jibel: FSVO "interesting" :(
<jibel> Thread state
<jibel> Dead(!)
<jibel> java.lang.NullPointerException
<jibel> jenkins' publisher strikes again
<hrw> doko: did that already
<mlankhorst> infinity: ping?
<tkamppeter> OdyX, yes, this looks really like a bug in pyppd.
<OdyX> tkamppeter: pyppd source says "    One ppd_file might result in more than one PPD. The rules are: return an
<OdyX>     PPD for each "1284DeviceID" entry, and one for each "Product" line, if it
<OdyX>     creates an unique (Manufacturer, Product) DeviceID.
<OdyX> "
<OdyX> I can't trace back to where it originates, but it sounds weird.
<OdyX> tkamppeter: 3a96ceb9526f9505b2a07a614a6c7d2d53dd1d7d in pyppd.git, from 2010-08-09, reasoning unclear to me.
<OdyX> tkamppeter: filed that as https://github.com/vitorbaptista/pyppd/issues/1
<mitya57> hi barry, we have just been missing you at #ubuntu-meeting :)
<barry> mitya57: yeah, i was having some system problems this morning :/
<mitya57> thanks for coming anyway :)
<wookey> infinity: I failed my core-dev entrance exam due to SRU cluelessness
<wookey> 'Don't know - I'd ask someone on IRC' was not deemed good enough
<wookey> they are quite strict :-)
<tumbleweed> wookey: when I'm unsure, I re-read the descriptions here https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu_Core_Developers
<wookey> yeah. I'd probably have failed me too. Thing is short of actually swotting up and treating it like an exam just filing bugs and letting other deal with stuff, I'm not actually going to get much more knowledgable about that stuff.
<tumbleweed> find a bug in a stable release, and SRU it :)
<stgraber> wookey: I'd recommend reading the SRU process wiki page and the release schedule for the current LTS and the current development release. That should help you understand the interactions between those two and have a clearer idea of how things work.
<wookey> I've already done that. The question wasn;t about 'did you know there was an SRU process' or 'have you used SRU process', it was 'for which transitiopns between suites is it appropriate'
<stgraber> wookey: FWIW, what I was expecting you to tell me was that a change that just landed in experimental would have to be synced or merged into raring, then can be SRUed to precise but as you need to keep an upgrade path, the change also needs to be SRUed to quantal
<stgraber> wookey: then you'd have had extra bonus points for noticing that the date I gave you was during the 12.04.2 freeze and so you could have told me that the precise part of that process would have to wait until the 31st (but as I said, that'd have been extra points ;))
<wookey> Right. Well I definately didn't know that
<wookey> But I can;t imagine why I'd ever want to get somethig into precise-updates
<wookey> so it's not very useful knowledge
<wookey> But I agree, I have quite a vague understyanding of the sync/merge paths and processes
<wookey> I have learned enough to know that I shouldn't presume anything from the way Debian does stuff. Which is why I default to asking someone clueful.
<wookey> If it's not obvious
<smoser> slangasek, at some point i think i'm going to need your help with what seems to me to be a race condition in networking coming up that is showing in raring images.
<smoser> https://bugs.launchpad.net/ubuntu/+bug/1078926
<ubottu> Launchpad bug 1078926 in Ubuntu "raring instance failed to find EC2 datasource" [High,Confirmed]
<smoser> it appears from /var/log/syslog that dhclient for an 'auto' interface was blocked, and couldn't finish until 'failsafe' finished. (note, also, that cloud-init-nonet probably had very similar timeouts, so it could have been it that was blocking)
<doko> kees, ping
<ritz_> barry ping, wrt https://bugs.launchpad.net/udd/+bug/848064 and https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/1078395
<ubottu> Launchpad bug 888615 in Bazaar "duplicate for #848064 UDD branch freshness checker breaks on incomplete history" [High,Confirmed]
<ubottu> Launchpad bug 1078395 in bzr (Ubuntu) "bzr: ERROR: Revision * not present in *" [Medium,New]
<doko> mterry, the boost stuff was promoted on Friday
<mterry> doko, yeah thanks.  The nux branch enabling tests landed
<mterry> doko, so whenever nux makes a new release, they will start being used
<ritz_> barry how do I fix this bug ?
<doko> unless pitti demotes it before ... that's why I don't like pre-promotions
<ritz_> is this bzr, or the lp import ?
<pitti> FYI, I don't do archive admin stuff these days unless someone asks me
<bdmurray> mpt: do you have an opinion on bug 1033226?
<ubottu> Launchpad bug 1033226 in update-manager (Ubuntu) "No close option, only restart" [Medium,Triaged] https://launchpad.net/bugs/1033226
<mpt> bdmurray, yes. I'd like to add a "Restart Later", I just haven't figured out what it should do yet, i.e. when and how it should remind you again.
<mterry> mvo, the update-manager test_update_origin.py test is failing.  Seems like the fake cache installs it sets up aren't working.  Could you look at it real quick and see if you know what it is?
<mterry> mvo, (not as in real soon, but as in don't spend a lot of time if you don't know what's wrong)
<barry> ritz_: are you looking to fix the bug itself, or to fix an import affected by that bug?
<mvo> mterry: test for libcupscgi1 fails?
<mterry> mvo, the name changes each time because of internal set sorting, but yeah
<mterry> mvo, the lines above the test go through a set of package names and "fake install" them into the apt cache used for the test
<mterry> mvo, but as soon as it tries to see if any of that worked, it fails
<mterry> mvo, this doesn't seem to have been caused by an update-manager checkin
<mvo> mterry: looking
<mvo> mterry: should be fixed in trunk now
<mterry> mvo, that was easy  :)
<mterry> mvo, ah interesting
<mvo> mterry: yeah :) took me a bit of head scratching, but then I figured what was wrong
<mterry> mvo, python-apt got stricter in the multi-arch world?
<mvo> mterry: apt itself got stricter, it used to assume missing architecture means native, but that is no longer the case for raring. fortunately that is exceedingly rare, except of re.g. testsuites and really old installs
<mterry> mvo, makes sense.  thanks!
<mvo> yw
<ritz_> barry either one
<barry> ritz_: i think you'll have more luck asking on the #udd channel
<ritz_> thank you :)
<ritz_> barry , hmm, where do I find #udd ?
<barry> ritz_: hmm, i guess #bzr is better
<ritz_> barry thanks you :)
<barry> ritz_: good luck!
<slangasek> smoser: I'm on vacation all week; you might want to talk to stgraber about networking races instead
<smoser> slangasek, thanks.
<cjwatson> pitti: I fixed all the python-apt autopkgtest errors I could, but I'm left with the ones you see in the current output; I can't reproduce that locally, even if I start up a process listening on the relevant port to deliberately confuse matters (which the test suite should now guard against)
<cjwatson> pitti: Any help gratefully welcomed, if you have time ...
<slangasek> smartboyhw: also, you're going to want to reproduce it with --verbose so we can get the ordering output from upstart.
<slangasek> er
<slangasek> smoser: also, you're going to want to reproduce it with --verbose so we can get the ordering output from upstart.
<smoser> slangasek, well... that'd be nice...
<smoser> yeah, i knew that'd be what you'd ask for.
<smoser> its non-trivial to produce since it doesn't happen all the time.
<toabctl> is there some documentation about adt-run ?
<infinity> mlankhorst: ?
<infinity> wookey: Don't worry, I don't know anything about SRUs either.
<bdmurray> bryce: does the xorg apport package hook need to run for package install failures?
<bdmurray> bryce: for example bug 1077509
<ubottu> Launchpad bug 1077509 in libdrm (Ubuntu) "Ubuntu will not update on my laptop" [Undecided,New] https://launchpad.net/bugs/1077509
<ChogyDan> RAOF: your analysis of bug 1068341 is incorrect.  Dpkg doesn't pull in the linux-headers dependency at all, which is why folks are having trouble
<ubottu> Launchpad bug 1068341 in software-properties (Ubuntu) "No way to specify correct dependencies for dkms packages (nvidia driver install fails to get matching header)" [High,Triaged] https://launchpad.net/bugs/1068341
<xnox> toabctl: not much really apart from the manpages.
<xnox> toabctl: use the wrapper script in lp:auto-package-testing
<toabctl> xnox, I got http://developer.ubuntu.com/packaging/html/auto-pkg-test.html and dholbach told me about https://wiki.ubuntu.com/TestCaseCompetition
<xnox> toabctl: it uses a cloud image to spin up a VM and execute adt-run for you based on a packaging bazaar branch pushed on launchpad.
<xnox> toabctl: since that's how the jobs are run in real jenkins
<xnox> toabctl: while that should work, it's also dangerous as it can destroy your machine.
<xnox> toabctl: for example a rm -rf gone astray can wipe everything.
<dholbach> xnox, maybe we should update http://developer.ubuntu.com/packaging/html/auto-pkg-test.html?
<xnox> dholbach: toabctl: yes, please use "prepare-testbed & run-adt-test" scripts from the lp:auto-package-testing. As that's the only way that we actually currently support results =)
<doko> kees, jdstrand: see gcc-4.8 in the ubuntu-toolchain-r/test ppa. had to disable gcc-default-format-security.diff, breaks the bootstrap. any idea why?
<xnox> if it doesn't pass with run-adt-test it will not pass in jenkins either.
<mlankhorst> bryce: see email btw, I want to get the backport stack into precise-proposed asap
<dholbach> xnox, https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/1080805 - I'll have a chat with pitti tomorrow (if nobody goes and fixes it in the meantime :))
<ubottu> Launchpad bug 1080805 in Ubuntu Packaging Guide "Update autopkgtest guide with current tool information" [Undecided,New]
<xnox> dholbach: lol =))))
<xnox> dholbach: to be honest those two scripts should be merged into ubuntu-dev-tools
<dholbach> xnox, sounds good to me - maybe you can file a bug about that ;-)
<xnox> dholbach: sure.
<jdstrand> sbeattie/sarnold: could you guys coordinate what might be going on with doko's question re gcc-default-format-security.diff (perhaps with kees)? ^
<kees> doko: it applies, but breaks the build? weird.
<mterry> mpt, am looking at an update-manager bug about what happens when an update error occurs.  So if an update error occurs, but there are still updates available (either from a previous check or a partial current check), do you have a preference for the wording on the "updates available" page
<mterry> ?
<mterry> Something similar to the stop-update message I imagine
<bryce> bdmurray, if you're 100% certain it's a package install failure and not, e.g. dkms build issues or similar, then much that's collected currently could be omitted.
<bryce> bdmurray, you thinking you'd like to optimize the hooks a bit?
<bryce> mlankhorst, ok looking
<robru> y
<robru> lol
<bryce> mlankhorst, is it the whole stack you're ready to upload or just the x11proto and apt updates referenced in your email?
<mlankhorst> I can upload the rest after x11proto and apt
<mlankhorst> that's why I want those in quickly, but since x11proto is a new version that's not a dot release I probably need more paperwork :/
<bryce> mlankhorst, ah, yes
<infinity> We need a new apt for the new X11 stack? *raise brow*
<bryce> infinity, patched, I expect, to handle smoother uploads
<mlankhorst> infinity: multiarch bug that makes switching impossible
<mlankhorst> it fails halfway through and only dpkg -r *-lts-quantal solves it
<infinity> mlankhorst: Oh, that bugfix is already in the queue.  Kay.
<infinity> mlankhorst: I thought it was something scary. :P
<bryce> mlankhorst, so in both cases you are going to be following the regular SRU process.  So start by for each filing a bug report stating the problem and solution clearly.  Follow the usual SRU syntax (Impact, Test Case, Regression Risk, etc.)
<infinity> mlankhorst: I'll review and accept that right now.
<mlankhorst> infinity: nah I don't dare to touch apt for that
<bryce> mlankhorst, in the case of x11proto, how many changes are in the changeset compared with the version in precise already?
<mlankhorst> bryce: it's just a header change
<bryce> mlankhorst, ok so < 8 changes in the git log?  that should be straightforward
<mlankhorst> is 1 bug for all 3 good enough?
<bryce> mlankhorst, in that case I think you can do it as just a regular SRU too.
<bryce> all 3 what?
<mlankhorst> x11proto packages
<bryce> x11proto binary packages?  yeah sru's usually target the source package
<mlankhorst> no it's separate, each proto has its own package :)
<bryce> ah, duh, right.
 * infinity frowns at mvo's apt SRU and all the vomit from using different autotools.
<bryce> that's probably more down to personal preference.  I'd do separate SRU's for each package, since they're likely to get processed separately.  But I think it should be ok to do them all together.
<infinity> Grr, and he also regressed the translations.
<bryce> mlankhorst, if the changes are related in some fashion it makes sense to do one sru, since then you just have to write a single description
<mlankhorst> yeah it would just be a copy paste 3x
<bryce> mlankhorst, if each is going to need a separate test case, then maybe separate
<mlankhorst> nah they're all used for the same
<bryce> mlankhorst, yep so just one bug with tasks for each of the source packages affected
<mlankhorst> yeah I'll do it tomorrow, eod for a while now :P
<bryce> no prob
<bryce> mlankhorst, hey, wanted to check in about how those synchronization rework patches are going?
<infinity> mlankhorst: I'm going to have to re-do this apt SRU and un-regress the translations, but I'll get it up today for you, since mvo's not around for me to bug him. :P
<mlankhorst> thanks!
<bryce> mlankhorst, also on bug 1010794 wanted to see if you'd already done uploads for the nouveau fix for quantal-proposed and precise-proposed, and if not do you plan to do it?  (If not, I'll take care of it when I get a chance.)
<ubottu> Launchpad bug 1010794 in xserver-xorg-video-nouveau (Ubuntu Quantal) "Graphics/text corruptions in some applications with nouveau drivers" [High,Triaged] https://launchpad.net/bugs/1010794
<mlankhorst> bryce: I think it was rejected because xxv-nouveau 1.0.3 had a regression in one of its fixes
<mlankhorst> it was fixed with 20995bb5920021668b8b607f886201c643ee0e9a
<mlankhorst> bryce: the synchronization changes are going slow btw, but I'm trying to get things upstreamed now, it makes the rest easier at least..
<bryce> mlankhorst, ok
<bryce> mlankhorst, hmm bug 1010794 says fixed in sync of 1.0.4; does that already include that commit?
<ubottu> Launchpad bug 1010794 in xserver-xorg-video-nouveau (Ubuntu Quantal) "Graphics/text corruptions in some applications with nouveau drivers" [High,Triaged] https://launchpad.net/bugs/1010794
<mlankhorst> raring has it fixed
<bryce> mlankhorst, ok.  and for precise and quantal, 20995bb5920021668b8b607f886201c643ee0e9a is the commit to be backported?
<mlankhorst> not sure if it counts for precise, it's probably unaffected
<mlankhorst> the corruption bug is only in xserver
<mlankhorst> was only more noticeable on nouveau since it did more fallbacks
<infinity> mlankhorst: apt for quantal reviewed and accepted, precise fixed and re-uploaded, just waiting on LP to spit out a diff for me to verify I didn't somehow break it while fixing mvo's upload. :P
<mlankhorst> thanks, will verify tomorrow :-)
<infinity> Shiny.
<doko> kees: exactly
<doko> barry, what does the new distribute fix?
<barry> doko: i am hunting down problems with virtualenv and python3.3.  i think this will fix it, though i also think the python-virtualenv package needs to be updated (which i'm working on, but upstream 1.8.2 is still broken)
<doko> ahh, ok
<barry> doko: and i need to get virtualenv working w/3.3 so tox will work, and i need tox to work so i can get piston_mini_client to work.  it's been a yak shaving day ;)
#ubuntu-devel 2012-11-20
<YokoZar> Could someone manually move wine1.4 through britney
<YokoZar> It's been waiting there for weeks now
<YokoZar> and I have SRUs sorta depending on it
<cjwatson> Let me just do a couple of manual checks then
<infinity> Oh, meh, I'd meant to get to that.
<infinity> And also to ask for a crash-source in hinting.
<infinity> s/source/course/
<cjwatson> infinity: Be my guest then.  Add "HINTS_ADCONRAD = all" (or whatever) in lp:~ubuntu-release/britney/britney2-ubuntu and create a file for yourself in lp:~ubuntu-release/britney/hints-ubuntu
<cjwatson> infinity: For the hint syntax you tend to have to RTFS.  In this case I suspect it needs "force-hint wine1.4/1.4.1-0ubuntu2" once you're happy that the new uninstallabilities are solely due to multiarch.
<cjwatson> (force-hint: "try anyway even if it increases uninstallability")
<cjwatson> (as opposed to plain force which is "ignore excuses")
<infinity> cjwatson: So, basically of the format "some-action: source/version"?
<cjwatson> I guess it might need force as well as force-hint, but try it without first.
<infinity> cjwatson: Where some-action is RTFS?
<cjwatson> Minus the colon, but yes.
<infinity> Oh, right.
<infinity> Reading, not my strong suit.
<infinity> But boy, you should see me type.
<infinity> Totally makes up for it.
<cjwatson> Oh look, found it.  http://ftp-master.debian.org/testing/hints/README
<cjwatson> infinity: ^-
<infinity> cjwatson: *nod*  Already read.
<infinity> Or, skimmed.
<infinity> Skum?
<infinity> Already skum.
<cjwatson> geskommen
 * infinity salutes.
<infinity> I think.
<infinity> Hrm.  Looks like britney needs to learn what :any means.
<infinity> Cause that wine output should really only be whining about "wine1.4/amd64 unsatisfiable Depends: wine1.4-i386", not the other two lines.
<infinity> YokoZar: So, testing this in a raring chroot with proposed enabled, it's not installable anyway...
<infinity> Oh, or this chroot is sad.  Sec.
<infinity> Okay, that works better...
<darkxst> Sarvatt, so I managed to get ppa-purge to correctly generate revert list on Precise, but it doesnt actually work since aptitude is horribly broken on precise.
<YokoZar> infinity: Thank you :)
<infinity> YokoZar: Also, I'm uploading to clean up that cruft that drives me insane every time I look at the diff.
<infinity> YokoZar: But I'll make sure this all migrates. :P
<YokoZar> infinity: Please do.  I was gonna decruft it myself but it took a while waiting ;)
<infinity> YokoZar: Also, britney does warn of:
<infinity> YokoZar: * i386: dssi-vst, lmms, pptview, pq, wine, wine1.4, wine1.4-dbg, wine1.4-dev, wine1.4-i386
<infinity> YokoZar: Some of those are clearly from the source itself, but can you verify them all?
 * infinity quickly does that himself for paranoia...
<YokoZar> please install pq
<YokoZar> it is a fantastic troll package
<infinity> YokoZar: Yeah, it all appears to install fine.  Probably just more fallout from the "wine1.4-i386 appears to not be installable" confusion.
<infinity> YokoZar: I'll pass on PQ for now. :)
<cjwatson> pq is very very silly
<infinity> The FAQ alone was silly.
<infinity> I love how he treats the bugs in the game as features "sorry, corrupted character just means it's gotten old and senile" sort of thing.
<YokoZar> infinity: it's because he literally lost the source
<YokoZar> persia: I hope you're enjoying the fact that pq is affecting us again
<infinity> YokoZar: https://bitbucket.org/grumdrig/pq implies he found it again. :)
<infinity> Oh, wait, this may prove to be a self-solving problem, since britney attempts to just make sure uninstallable counts don't go up, and wine will continue to be "just as broken as before". :P
<infinity> Still, would be nice if we could make it look less broken in the eyes of britney.
<YokoZar> infinity: you could remove pq :P
<infinity> No, no.  I mean it would be nice if wine itself didn't appear broken, but without allowing a free-for-all of cross-arch deps (which would be ungood, IMO)
<infinity> But 2 of the 3 issues it claims could be solved by making britney 's/:any//' when looking at deps.
<infinity> Then it's just the one cross-arch dep that'll take a head-scratch.
<persia> infinity: Removing pq would really do everyone a favor.  Have you looked at the license?  The "source" is a windows executable binary.
<persia> (yes, it's acceptable for multiverse, by special extension of policy when it was originally uploaded)
<infinity> persia: The source can be anything you want it to be for multiverse, as long as the license allows distribution.
 * infinity wonders why we're suddenly talking about removing something...
<persia> Yeah, one of the aspects of UFSG that isn't precisely as I'd prefer.
<infinity> persia: That has nothing to do with the FSG part, it's the same as Debian non-free.
<infinity> persia: In that any old crap can be there as long as it's not actually illegal for it to be.
<infinity> (From a licensing perspective, that is)
<persia> As much as I'd enjoy a discussion about the difficulty of verification of license compliance in the absence of either textual representations or open-standard metadata specifications for identified binary blobs, I have to go have a tooth pulled now.
<morphias> http://developer.ubuntu.com/packaging/html/packaging-new-software.html - i looked at this guide and i am trying to see how i would go about having one *.cpp file for my own program designed just using gedit to having all of the files that are included in the hello-2.7 tar so i would go about developing a debian package...
<morphias> can someone help me in packaging like my own idea?
<pitti> Good morning
<pitti> cjwatson: thanks! I'll see whether I can reproduce them
<pitti> xnox: so you are also awake on crazy hours?
<smoser> infinity, have you thought any more about https://bugs.launchpad.net/debian/+source/e2fsprogs/+bug/978012
<ubottu> Launchpad bug 978012 in e2fsprogs (Ubuntu Precise) "Please SRU micro bug fix release of e2fsprogs 1.42.4-3ubuntu1 (main) from Quantal (main)" [High,Confirmed]
<smoser> i was resizing a filesystem on precise from ~ 1.4G to 700+M and it was taking 10s of minutes (i gave up).
<smoser> it takes quantal 8 seconds.
<infinity> smoser: Hrm, I thought I'd left it in xnox's hands to do some patch auditing. :/
<infinity> smoser: I'll catch up with him about it tomorrow and see what we can work out.
<dholbach> good morning
<pitti> cjwatson: the 2.7 tests run fine for me, and the 3.3 tests don't run at all (KeyError: None in "<frozen importlib._bootstrap>", line 1271, in _path_importer_cache, I'm looking into that)
<rbasak> From https://wiki.ubuntu.com/SyncRequestProcess: "Do not change the Status of the bug or put it back to New as package sponsors use this field.". So can I mark a sync request as triaged to get it off a triage report, or will that confuse something?
<infinity> rbasak: Sync requests kinda only have three states: new, invalid, fix released.  Cause the only people who should triage them are people who can actually just do the sync, IMO.
<infinity> rbasak: With that in mind, bug number?
<rbasak> infinity: bug 1080961
<ubottu> Launchpad bug 1080961 in python-setuptools-git (Ubuntu) "Sync python-setuptools-git 0.4.2-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1080961
<rbasak> I can just ignore sync requests in our triage report then. There aren't many of them. And then one day maybe we can modify it to exclude those
<rbasak> infinity: dunno if you want to let zul look at it or maybe that doesn't matter
<infinity> rbasak: I just synced it, based on the explanation in the bug.
<rbasak> infinity: ok, thanks!
<infinity> rbasak: It really was based on his work, including his changelog.  It's pretty obviously derivative.
<rbasak> Yep
<smb> Now how can we get infinity to bed quickly? ... "hot potato"? ;-P
<pitti> cjwatson: oh, it's prepending None to sys.path, that's why; fixing..
<infinity> smb: You can make my test builds finish so I can prove this glibc testsuite regression is a binutils bug.
<infinity> smb: And then you can find the binutils bug.
<infinity> smb: And then give me pie.
<infinity> (The pie is not optional)
<smb> infinity, You could make me core-dev then maybe I had some influence on 1, fur 2 I got no good excuse and about 3 those Canadians have some similar strict customs regulations than the other North Americans. So I am sure you are certain I cannot do it. :)
<infinity> smb: core-dev won't help you with number 1, lending me a faster computer might.
<infinity> (But I think I'll just watch another episode of Dexter and pass out)
<persia> smb: There are 4 pie delivery services in Calgary (of which none are open at this hour)
<infinity> persia: I'm shocked that there are any.
<smb> infinity, Sounds like a plan.
<persia> infinity: There's 6 cookie delivery services :)
<smb> persia, Oh, I did not think of delivery service that is local
<infinity> persia: My whois info isn't a lie.  Just sayin'.
<smb> infinity, So not only strange wake hours... also strange places?
 * persia fails at infinity tracking
<brendand> whois infinity
<smb> who knows
<rbasak> dovecot is 1:2.1.7-1ubuntu2 in raring, and 1:2.1.7-5 in sid. So why doesn't it appear in merges.u.c? Is it because the upstream versions are the same, and we don't usually care about merging debian revisions? Except that I don't see anything but a straight version comparison in http://bazaar.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/view/head:/produce-merges.py
<persia> rbasak: We actually do care about merging debian revisions: that's where we get the good bits (CVE fixes, cherrypicks for critical bugs, etc.)
<persia> (but I don't know the answer to the actual question)
<rbasak> OK, thanks. Here, I do (slightly) care about merging a debian revision since it backports a fix to a bug someone filed
<persia> That's the common case: most Debian Maintainers don't bother to upload unless there's a good bug fix or a new upstream version.
<persia> I think there's something special about dovecot: it doesn't show in mdt either (yes, mdt is tracking wheezy, but that has 1:2.1.7-2, which should list as a merge candidate anyway)
<dholbach> diwic, happy birthday! :)
<diwic> dholbach, thanks :-)
<diwic> all communities needs someone to keep track of other people's birthdays :-)
<mlankhorst> I'm playing around with the renamed stack a bit more, installing some -dev packages can wipe it. I think the best fix would be to make the unrenamed mesa dev packages installable with the renamed stack to fix it. Are there even other solutions?
<pitti> cjwatson: FYI, jibel pointed out it's a proxy issue; I can reproduce it with http_proxy=http://nonexisting python3 test_auth.py
<cjwatson> ah; maybe just unset the proxy for that test then?
<pitti> cjwatson: yeah, but it shouldn't use the proxy for localhost in the first place
<cjwatson> that too
<cjwatson> ooh, I think I might actually have a working cloudy auto-cross-builder
<pitti> I'll have a quick look first
<cjwatson> minus interface for being able to tell what's going on, but you can't have everything
<cjwatson> the important bit is that I can do 'juju add-unit sbuild' and extra builders magically attach themselves and start building stuff
<pitti> \o/
<pitti> that's the bit that we always wanted
<cjwatson> not for LP mind :)
<cjwatson> but it's pretty cool for test builds
<pitti> cjwatson: like, now we could actually do test rebuilds using the technology we advertise everywhere? :-)
<jibel> if proxy is not set, tests that need one will fail. python-apt should honor no_proxy
<pitti> jibel: no_proxy is set to something like "localhost"?
<cjwatson> well, uh, this is with sbuild + buildd + wanna-build, which ain't exactly the technology we advertise
<pitti> cjwatson: right, I meant the cloud bit
<pitti> it seems a bit sad to have this at hand, and still block our distro builders for a week for a test rebuild
<cjwatson> jibel: python-apt isn't doing the network bits itself - that's gnupg
<cjwatson> I'm not saying the test harness should stop setting the proxy
<jibel> pitti, I tried it but it makes no difference
<cjwatson> I'm saying that one test should unset the proxy for itself, since it knows it's always talking to localhost so it's irrelevant
<jibel> right
<pitti> jibel: right, I meant what is no_proxy set to in the DC?
<jibel> pitti, it is not set
<pitti> ah, ok
<pitti> bug 789049 FTR
<ubottu> Launchpad bug 789049 in gnupg (Ubuntu) "gpgkeys doesn't find the key thru http proxy" [Undecided,Confirmed] https://launchpad.net/bugs/789049
<pitti> cjwatson: wrt. our discussion yesterday, we understood it like britney would calculate the reverse dependencies of the package and put them into the request file, minus the uninstallable ones, right?
<pitti> cjwatson: in which case we would need test states "pass", "fail", "pending", and additionally "n/a" for pacakges which don't have tests, right? or do you want to look at the XS-Testsuite: field yourself?
<pitti> cjwatson: or shall these be computed in the adt scripts?
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<xnox> cjwatson: https://code.launchpad.net/~xnox/charms/precise/sbuild/add-more-options/+merge/135099
<seb128> dholbach, \o/
<xnox> cjwatson: it adds options to select $home, disabling the bts party thing, supplying custom .mk-sbuild.rc  & .mk-sbuild.sources
<xnox> cjwatson: see if any of that fits your charms or not.
<cjwatson> pitti: I was expecting britney to call some part of auto-package-testing to do that, which looks at XS-Testsuite; I would actively prefer not to make adt requests for packages that don't need it, since that involves a round trip to the lab before we get to migrate them
<cjwatson> pitti: I think it's OK to simply not have any entry in the result file for the "pending" state
<cjwatson> xnox: Thanks.  It doesn't conflict, but I think it also doesn't overlap much.  (Although I implemented a rough equivalent of the home handling by just moving /var/lib/buildd to /mnt/buildd in the install hook; yours is cleaner.)
<xnox> cjwatson: yeah, that's what I though =) so when are you blogging about your wanna-build charms ? I want to run it for mingw & I bet wookey wants it too =)))))
<cjwatson> xnox: I want to polish a bit more and I have some patches to send around
<cjwatson> xnox: My understanding is that I'll eventually be taking over auto-cross-builder operation from wookey with this
<xnox> cjwatson: also with juju you can share the admin password & then people who have access to the openstack project / ec2 environment can all then ssh into the juju deployment to check up on things.
<pitti> cjwatson: ah, so britney would put the reverse depends into the request file, and adt would mark the ones without tests as n/a?
<xnox> cjwatson: that you way you can share the cloud administration / poking / troubleshooting between multiple people =)
<pitti> cjwatson: I thought you wanted britney to generate the rev dep list (adt could do it by itself as well, but I might have misunderstood you)
<pitti> jibel: ^ FYI
<pitti> cjwatson: no line for pending> ack, easier
<cjwatson> pitti: Other way round - britney will ask some piece of auto-package-testing to generate the initial request file, and then britney will filter it
<pitti> cjwatson: ah, ack
<pitti> jibel: ^ ok for you?
<cjwatson> pitti: that's what we discussed yesterday
<cjwatson> xnox: Thanks, but this doesn't help much as the person I'd want to share auto-cross-builder operation with doesn't have access to the cloud in question
<cjwatson> xnox: It's OK, I'll work it out :)
<pitti> cjwatson: yeah, I initially had that in the "API" part as requests-tests or so, and then we removed it because we said "easier to just use a file format for exchange"; misunderstanding then
<cjwatson> Yeah, we were going round in circles a bit
<pitti> cjwatson: ok, seems clear now
<cjwatson> Imagine the top half of trigger-adt-tests (or whatever it's called - minus the jenkins interaction) being called before the main body of britney starts
<pitti> *nod*
 * pitti throws a new python-apt archivewards and hopes for some green
<cjwatson> Cool, thanks
<dholbach> can somebody please reject https://code.launchpad.net/~logan/ubuntu/raring/strigi/debian-merge/+merge/134351 (was merged already)?
<zequence> cjwatson: Hi, could I bother you for a moment? I've made a merge request here https://code.launchpad.net/~zequence/ubuntu/raring/jackd2/fix-for-956438/+merge/134771
<zequence> I was wondering about the procedure for getting it merged a bit, how long it may take, etc
<zequence> This is a fix, that I would like to backport into 12.10 and 12.04 as well
<zequence> It's the first patch I've ever made, and may include some abundant code, but this is because I used the upstream commits as they were
<cjwatson> zequence: https://wiki.ubuntu.com/SponsorshipProcess
<zequence> cjwatson: Thanks
<jibel> cjwatson, ok for me. Can I use the same package index files than britney on lillypilly?
<jibel> i.e what's in data/raring*
<Laney> dholbach: For some reason this was not automatically closed.(?)> that happens upon migration to release
<dholbach> Laney, aha! I was too quick :)
<dholbach> thanks Laney
<Laney> kein problem
<dholbach> :-)
<zequence> cjwatson: Seems like sponsoring is an automatic procedure now, and a few things on that page are now obsolete. I did follow instructions here http://developer.ubuntu.com/packaging/html/udd-sponsorship.html, and I see that my merge proposal is listed here: http://reqorts.qa.ubuntu.com/reports/sponsoring/
<zequence> I would also like to take the opportunity to highlight how important I think this bugfix is
<zequence> Especially for 12.04, where people not used to Linux have a terrible time using jackd2
<zequence> Backporting to 12.04 will be my next step, if I can get this merge accepted
<cjwatson> jibel: Sure
<cjwatson> jibel: Or ~/mirror/ubuntu/ if you prefer
<cjwatson> zequence: Some bits of it may have been automated, but in general sponsoring is intrinsically non-automatable
<zequence> dholbach: Could I ask you for advice on my merge request? I noticed that you are the author of many of those pages :).I'm wondering if there is anything more I should/could do https://code.launchpad.net/~zequence/ubuntu/raring/jackd2/fix-for-956438
<zequence> Meaning, many of the doc pages concerning ubuntu development, bug fixing, etc
<zequence> dholbach: btw, I'm previously known as ailo (was at UDS to represent Ubuntu Studio)
 * mpt wonders how many of <https://bugs.launchpad.net/ubuntu/+source/update-manager?field.searchtext=ubuntu-minimal> are duplicates
<brendand> does anyone know where to look for information about different video ports  such as LVDS, DVI, VGA? preferably under /sys
<pitti> brendand: /sys/class/drm/card*, but it might not be present on non-KMS drivers
<pitti> mvo, cjwatson: il est vert! :-) https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python-apt/
<mvo> pitti: \o/
<dholbach> zequence, it looks good as far as I can see and turns up in http://reqorts.qa.ubuntu.com/reports/sponsoring/
<cjwatson> pitti: yay
<xnox> pitti: nice =)
<pitti> I have libarchive fixed locally as well
<pitti> mvo: any idea what causes the wrong component order in release-upgrader?
<zequence> dholbach: Ok, thanks. Then I suppose it will be processed in due time (looks like a que system there).
<nobuto> Sweetshark: I would like this issue fixed to be SRUed for precise and quantal. but how can I make the raring task "Fix Released"? Should I make a specific patch to the raring package or do you have a plan to upload 3.6.4 rc1 or higher package (containing the fix) in a few weeks? https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/585910
<ubottu> Launchpad bug 585910 in libreoffice (Ubuntu) "[Upstream] Impress Font fuzzy in presentation mode when Use hardware acceleration enabled" [Medium,In progress]
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/x11proto-randr/+bug/1081122
<ubottu> Launchpad bug 1081122 in x11proto-randr (Ubuntu) "x11proto-(gl,randr,dri2)-dev need to be updated for backport stack" [High,New]
<mlankhorst> bug create, now I just upload those packages for precise?
<mlankhorst> created*
<dholbach> zequence, uploaded
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> part 2 of my pilot shift tomorrow
 * pitti hugs dholbach
 * dholbach hugs pitti back
 * OdyX points to new usb-modeswitch{,-*} versions in experimental and wishes the Ubuntu forker some fun. :)
<pitti> argh, did upstream still not take the C rewrite?
<zequence> dholbach: Thanks a million!
<OdyX> why would he?
<mvo> pitti: sorry, need to check that out
<dholbach> zequence, anytime
<pitti> OdyX: I thought cyphermox discussed that with upstream and they reached some agreement
<pitti> I mean, there must be some more appropriate language than Tcl that is palatable to upstream..
<OdyX> pitti: the libjim solution has a quite small overhead though
<pitti> OdyX: if that avoids a tcl dependency, it's already a great step forward indeed
<OdyX> 300k , granted.
<pitti> it's still slow, but at least smaller
<OdyX> pitti: well, that's in Debian since ages.
<mlankhorst> I want to sru x11proto-dri2-dev which has 2.8-1 to precise which has 2.6-2, what would be the correct version number? I'm guessing 2.6-2+precise1 or something..
<OdyX> we don't care if it's slow btw, it's forked by udev...
<pitti> OdyX: right, AFAIR the C port was done "ages" ago, too :)
<OdyX> pitti: that's why I'm pointing to regular updates done by upstream. An outdated fork loses interest IMHO.
<OdyX> and as I'm not willing to maintain the C fork :-)
<pitti> yes, it wasn't meant to be permanent
<pitti> mlankhorst: you want to backport the full version, or apply a patch to 2.6-2?
<pitti> mlankhorst: in the former case, 2.8-1~precise, in the latter 2.6-2ubuntu1
<mlankhorst> ah I had tried 2.8.1~precise1 before I noticed xorg package set only applies to raring :-)
<hrw> ok, finally started do-a-release.sh script to bootstrap whole armel/armhf cross compiler
<hallyn> slangasek: bug 1080912 - if qemu-kvm.postinst does 'udevadm trigger --action=change' to reset /dev/kvm perms, then if upgading udev and qemu-kvm at the same time that fails.  But only doing that while udev is running doesn't suffice,
<ubottu> Launchpad bug 1080912 in qemu-kvm (Ubuntu Raring) "package qemu-kvm 1.0+noroms-0ubuntu14.4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Critical,In progress] https://launchpad.net/bugs/1080912
<hallyn> slangasek: because 'stop udev; start udev' doesn't recalculate the rules
<hallyn> is there a way to queue the udevadm trigger?
<Sweetsha1k> nobuto: raring will have 4.0.x
<apw> hallyn, as in if they are being upgraded at the exact same time ?
<hallyn> apw: as in 'sudo apt-get install --reinstall udev qemu-kvm' (to mimic a dist-upgrade), yes
<hallyn> apw: or will the udev upgrade do a better job than 'start udev' in reloading the rules?
<hallyn> recon i should check its postinst
<apw> hallyn, isn't there a dpkg header to say you need something complete before, for example some things say 'i need dpkg upgraded and complete before i start installing'
<hallyn> dunno, but that would suffice, googling
<hallyn> would that be the predepends?
<hallyn> apw: thanks, i'll try that.
<apw> hallyn, i cannot tell if you pre-depending on udev will make that complete before, or if that just means must have installed at least once before
<hallyn> apw: http://www.debian.org/doc/debian-policy/ch-relationships.html seems to imply it'll complete the update.  but, i'll test here first.
<apw> hallyn, i think the second half of the description may bite there, i think that implies 'has installed correctly at least once'
<hallyn> apw: heck, maybe a depends would suffice for this.
<hallyn> it says depends will ensure it's configured first...
<hallyn> and clearly the depends is now required, so a depends would be correct regardless
<nobuto> Sweetshark: If the next upload to raring is not scheduled in a few weeks, I would like to fix it in raring with a specific patch. Could you review and upload this debdiff if you have time? https://launchpadlibrarian.net/123530840/debdiff-for-raring.debdiff
<apw> worth a short then
<hallyn> apw: yup - thanks.
<hallyn> (off to mtg)
 * apw idly wonders if there is debhelper support for Built-Using in binaries
<cjwatson> Doubt it
<apw> cjwatson, what is the approved mechanism for adding a built-using to a binary package
<apw> or indeed any additional header
<cjwatson> apw: just put it in the control file.  see grub2-signed e.g.
<apw> cjwatson, thanks
<cjwatson> You can use substvars to construct the value
<cjwatson> man deb-substvars
<apw> cjwatson, oh that is very simplei
<apw> indeed
<slangasek> hallyn: interesting.  this has never been reported for any other packages that create udev rules
<slangasek> (at least not AFAIK)
<slangasek> hallyn: ah, solved by making qemu-kvm depend on udev so that the maintainer script ordering is always correct
<hallyn> slangasek: right
<hallyn> pushed to raring, just gotta get new sru candidates out for the rest :)
<apw> cjwatson, i believe that this is what they intended thsi field to say, for raring: "Built-Using: linux (= 3.7.0-2.8)"
<cjwatson> apw: seems fair
<hrw> ah, b-u... I should start using it for cross compiler
<apw> this is going to sound like a stupid question i am sure, but, i assume for a debian 3.0 package with multiple orig files, that all of those files are inviolate once uplaoded as the standard orig is
<Daviey> apw: You need to add more detail..
<Daviey> apw: You mean, uploading multipe upstream orig's works with our infra?
<Daviey> Is that the question?
<apw> i mean if a package has liek a foo_xxx.orig.tar.gz and a foo_xxx.orig-bar.tar.gz, i assume the latter is as imutable as the former once uploaded once
<Laney> Yes, AFAIK.
<Daviey> apw: Ah, you mean.. if you upload a subsequent upload, with the same upstream version, are you safe to upload the diff only?
<apw> Daviey, well i am expecting that both orig files have to be the saem and can only be the same from then on, ie. i need to be careful its right
<Laney> I would expect your upload to get rejected if they differ
<apw> (that matches my expectations, great)
<doko> cjwatson, I just did see that I accidentally bypassed -proposed with my doxygen sync from experimental ... should there be a warning?
<cjwatson> doko: No, because it only affects archive admins and isn't worth it.  Please update your ubuntu-dev-tools
<infinity> doko: You should upgrade ubuntu-dev-tools.
<infinity> (This isn't the first time I've pointed it out...)
<doko> ok, was using copy-package instead of syncpackage ...
<cjwatson> Oh, OK - yes, feel free to add a warning to copy-package if copying into the release pocket of the current series
<cjwatson> I think that'd be appropriate
<stgraber> if os.environ['USER'] == "doko": print("Use syncpackage!"); sys.exit(1)
 * doko slaps stgraber 
<cjwatson> hmm, I think we may have lost a cross-build-dep-handling patch from apt ...
<cjwatson> but in that case why isn't the test for it failing?
<seb128> bdmurray, thanks for catching that gtk upload bug, that diff was not wanted, I've rejected that update and reuploaded a clean version
<cjwatson> ah, I wonder if that test is actually run
<xnox> stgraber: pyflakes says you are missing "import sys, os;" =)))
<stgraber> ;)
<hallyn> slangasek: so, if i merge qemu-kvm and qemu-linaro into one source package, with the intent of MIR-ing the packages from qemu-linaro (except qemu-kvm-spice), what order should i go in?  should i first MIR the packages from qemu-linaro source?  i can't have the qemu source produce both main and universe pkgs right?
<hallyn> stgraber: ^ q to you as well if you have time
<cjwatson> Nothing wrong with a source package in main producing binaries in both main and universe
<hallyn> cjwatson: oh??  sorr i thought that wasn't possible,
<cjwatson> It is possible.
<hallyn> that it auto-promoted the binaries
<cjwatson> No.
<ScottK> Other way around is not possible
<stgraber> hallyn: sounds to me like this is just the equivalent to a source rename (binary packages will be the same), so components for the binaries can remain the same
<hallyn> cool!  so i don't really need to do anything in advance?
<cjwatson> Exactly.  Binary in main => source in main, but not vice versa.
<hallyn> awesome - thanks guys, i was fretting over this :)
<kees> hallyn: around?
<hallyn> kees: what's up?
<hallyn> kees: leaving soon for lunch, so if i don't respond, i'll do so soon as i get back
<hallyn> kees: heading off, ttyl
<kees> hallyn: eek, missed you. I was curious about your comments on rcu_read_lock(). seems you're right, and I wanted to make sure I understood the requirements correctly.
<hallyn> kees: rcu list traversals are always supposed to be done under rcu_read_lock or spinlock
<hallyn> doing it under rcu_read_lock will protect you from del and add
<hallyn> then the spinlock kjust protects simultaneous adds and dels from each other
<kees> hallyn: okay, yeah. looks like there are examples in the kernel of list-walkers not being under rcu_read_lock
<kees> (and they're wrong)
<kees> docs for list_for_each_entry_rcu say:
<kees>  * This list-traversal primitive may safely run concurrently with
<kees>  * the _rcu list-mutation primitives such as list_add_rcu()
<kees>  * as long as the traversal is guarded by rcu_read_lock().
<kees> so, yeah, I think I'm good now -- all list walks are wrapped by rcu_read_lock, and all _del and _add are spinlocked
<kees> my problem is that I have 2 list writers. for stuff with a single writer, that writer doesn't need to wrap the list walking in any rcu.
<hallyn> kees: what were the bad examples?  i'm dying to know :)
<hallyn> kees: note that most of my knowledge of sru is about the early (2004 and thereabouts) versions.  there have been a lot of changes since then.  SRU in parcitular.  that's why i was tentative in my email response :)
<kees> hallyn: drivers/base/power/opp.c jumped out at me. walks an rcu list with no read lock
<kees> but I couldn't find the writer, so maybe I'm wrong
<hallyn> kees: the callers of the fn however say they must be called under rcu_read_lock
<hallyn> opp_get_notifier being a notable exception
<hallyn> which becomes exposed through an exit hook at drivers/devfreq/exynos4_bus.c
<hallyn> i have no idea waht that thing is, but it's buggy :)
<hallyn> kees: do you have time to follow up on that?
<kees> hallyn: sure, I can do that
<maxiaojun> hi, would it be nice if Ubuntu has something like Boot Camp? i'm not requesting work for others, i just want to discuss the idea
<sarnold> what's Boot Camp?
<micahg> grub?
<maxiaojun> an OS X feature that allow users to shrink OS X partition and give room to Windows
<micahg> oh, gparted then
<sarnold> maxiaojun: lvm2 allows you to resize block storage..
 * micahg thought the installer allows that as well
<maxiaojun> i use Disk Utility in OS X to shrink OS X partition and install Ubuntu
<maxiaojun> the use case i thought is like this
<sarnold> micahg: it allows shrinking windows partitions to install ubuntu, though probably not much the other way around -- to shrink ubuntu to allow windows :)
<maxiaojun> say non-Linux savvy people buy a computer with Ubuntu pre-installed
<hallyn> kees: awesome, thanks
<micahg> sarnold: gparted should depending on which fs (whether windows will use what it's given is another story)
<sarnold> micahg: heh, good point there. :)
<maxiaojun> if we have a nice tool like Boot Camp, Windows dependent people may keep Ubuntu longer
<sarnold> I think it should, you're right, re-sizing filesystems has been around for ages (even though it feels like blackmagic to me...)
<maxiaojun> but the boot loader can still be a trouble
<sarnold> windows especially, it does plan on being the only OS on a machine.
<maxiaojun> Mac machines seems to give Windows a emulated MBR environment
<micahg> well, if grub could boot lxc containers...
<maxiaojun> lxc?
<maxiaojun> what's that?
<micahg> maybe it's not the right thing....https://help.ubuntu.com/community/LXC
<maxiaojun> i feel like a solution would be like this in theory
<maxiaojun> so the user want to install Windows
<maxiaojun> she use a tool to shrink Ubuntu partition and create a special boot entry in GRUB
<maxiaojun> use that boot entry will load Windows installer from DVD-ROM and jail it somehow so it cannot overwrite existing boot loader
<sarnold> it'd be easier to use the mbr package to install a known-good bootloader rather than let windows scribble over whatever it wants.. :)
<maxiaojun> the problem is that windows installer just overwrite mbr
<maxiaojun> you cannot stop it, i guess the same for recent Ubuntu installer
<maxiaojun> the difference is that Ubuntu's GRUB try to detect other os and show them in menu, that's it
<infinity> doko: You areound?
<infinity> doko: Or around?
<infinity> doko: Some headers (well, at least one) seem to have gone missing in your GCC package splitting shuffle.
<infinity> doko: http://paste.ubuntu.com/1373503/
<infinity> doko: Was the new location intended?  If so, glibc's testsuite needs mangling to cope, I think.
<infinity> doko: Hrm, could be a bug in glibc's configure, going to test a patch here in a bit.
<GunnarHj> slangasek: ping?
<infinity> GunnarHj: Pretty sure he's on vacation, unless I have my dates mixed up.
<GunnarHj> infinity: Aha, thanks for letting me know.
<jdstrand> cjwatson: hey, I am setting up a machine with secure boot and it is telling me that secure boot prohibits use of the normal.mod and drops me to a rescue prompt. rmmod is not available there-- how do I disable normal.mod, or, better, where can I find a grub configuration that is compatible with secure boot?
<doko> infinity, yes, intended. I assume it needs changes when -nostdinc is used
<infinity> doko: Yeah, working on testing a fix to glibc.
<infinity> doko: So, false alarm, sorry for the blame finger, etc. :P
<infinity> jdstrand: Our grub2-signed should be compatible, which is vaguely the point of it.
<jdstrand> maybe I didn't install everything I needed
<doko> I filed a bug for clang, forgot about glibc
<jdstrand> hmm, I have grub-efi-amd64-signed
<mercury00> I think this is a channel to ask about reprepro?
<infinity> mercury00: Seems unlikely.
<mercury00> sorry
<infinity> S'ok.  Not sure if they have a channel of their own, but user channels like #ubuntu (on freenode) and #debian (on oftc) might be a better choice.
<mercury00> ok , thanks!
<jdstrand> cjwatson: I think the actuall problem is I am not using grub-efi-amd64-signed correctly (I am setting up secure boot in an ovmf image after the fact)
<doko> kees, jdstrand: there is a second issue, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395
<ubottu> gcc.gnu.org bug 55395 in fortran "[4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi" [Normal,Unconfirmed]
<doko> this appears only when the compiler defaults to -fstack-protector
<jdstrand> sbeattie, sarnold: ^
<doko> kees, I assume the google test build were done without gfortran?
 * sarnold rubs his eyes
<sarnold> how would -fstack-protector cause a 'section type conflict' for a static const variable? O_o
<sarnold> doko: have you had a chance to test that untested patch?
<doko> sarnold, doesn't change anything
<sarnold> doko: somehow I'm not too surprised.
<doko> sarnold, the recent gcc-snapshot build has the same patches as my gcc-4.8 build, just the hardening patches disabled
<doko> so I'd say miscompilation of cc1 with -fstack-protector
<RAOF> doko: I'd like to push the gcc-4.6 SRU for precise into precise-proposed, but https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/972648 is missing instructions for the test case. Could you please clarify that bug, then I'll accept it from the queue?
<ubottu> Launchpad bug 972648 in gcc-4.6 (Ubuntu Precise) "ICE (segfault) in gsi_for_stmt" [Medium,Confirmed]
<doko> RAOF, let me look at this tomorrow, not tonight anymore
<RAOF> doko: No problem; it just looked like it was an important SRU that's been waiting around for too long :)
<doko> yeah, I wasn't following up as well
<infinity> RAOF: Actually, doko had promised me a fresh upload fixing one more bug...
<infinity> Though, he probably forgot. :P
#ubuntu-devel 2012-11-21
<infinity> doko: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52445
<ubottu> gcc.gnu.org bug 52445 in tree-optimization "[4.6 Regression] conditional store replacement causes segfault in generated code" [Normal,Assigned]
<infinity> doko: There are a few long threads around arm-linux and other lists about how that bug causes some kernel driver miscompilations.
<infinity> Now, if only I could remember who it was who brought it to my attention a few weeks ago...
<cjwatson> jdstrand: Disabling normal.mod doesn't make sense.  That's the module that provides the menu.
<cjwatson> jdstrand: You should be able to copy /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed into your environment as grubx64.efi and execute it from firmware configured to trust the Canonical key (or via shim from firmware configured to trust the Microsoft key).
<cjwatson> jdstrand: Or, if you already have an installed system that you're booting in OVMF rather than trying to bootstrap one from scratch, install the grub-efi-amd64-signed package and run 'grub-install --uefi-secure-boot'.
<cjwatson> jdstrand: (I believe I have a work item to make that the default even on non-SB systems, with a few associated tweaks)
<cjwatson> jdstrand: And rereading, it sounds as though you probably want the latter approach.
<cjwatson> jdstrand: A message refusing to load normal.mod indicates that you've tried to sign a minimal GRUB image (perhaps the one generated by plain grub-efi-amd64) that's expecting to load much of its brain from /boot/grub/x86_64-efi/*.mod - but GRUB insmod is forbidden in secure boot because all the boot loader code must be signed.
<Shinobi> The only rdp client I can get to connect is rdesktop, none of the rdp clients I've tried in 10.10 will connect. Is there some library that I need to add or something?
<Shinobi> Sorry. None of the rdp clients with GUI front ends will connect. CLI is fine.
<ScottK> 10.10 is long out of support in any case.  This isn't a help channel, but certainly not for old releases.
<infinity> Shinobi: This isn't a support channel, try #ubuntu.  Also, 10.10 is an EOL product, you might want to try 12.04 (or later) before asking for help.
<infinity> ScottK: Jinx.
<ScottK> ;-)
<Shinobi> infinity: Sorry. Nobody seemed to know in Ubuntu, so I thought I'd see if someone may have known. I plan to upgrade to 12.04 tonight.
<SpamapS> Shinobi: I seem to recall some serious bugs that were fixed somewhat recently in one of the other rdp clients
<jdstrand> cjwatson: thanks-- let me try grub-install --uefi-secure-boot. I that sounds like the missing piece-- but you gave a lot of info I can play with. much appreciated
<jdstrand> cjwatson: that was exactly it. perfect-o!
<jdstrand> cjwatson: huge thanks. I'll fiddle with the other options later as well (ie, Canonical key, shim, etc)
<pitti> Good morning
<ion> hi
<pitti> infinity: do you plan to do an initramfs-tools merge soon, or want me to ignore the warning in u-d-common for now?
<infinity> pitti: I plan to merge tonight or (more realistically) first thing in the morning.  That eglibc upload I just did a couple of hours ago was occupying me.
<pitti> infinity: ah cool, thanks!
<infinity> doko_: Ugh.  Shouldn't there be a /usr/include/i686-linux-gnu to match the cross target, rather than i386-linux-gnu to match the Debian arch (or maybe one a symlink to the other)?
<infinity> doko_: Or maybe I get to special-case i?86 in glibc's configure and it won't be upstreamable.
 * infinity ponders.
<infinity> doko_: Yeah, all the stuff that used to be in /usr/include/c++/4.7/`g++ -dumpmachine` is now in /usr/include/$DEB_HOST_MULTIARCH/c++/4.7 which is subtly different on i386.
<infinity> doko_: Oh, I guess I can conditionally use g++ -print-multiarch and still have this upstreamable.
 * infinity kicks himself for only testing on amd64 and powerpc.
<infinity> pitti: You wake up too early.  It always makes me thing (very incorrectly) that I can start talking to other Germans and expect a response. :P
<infinity> s/thing/think/
<pitti> hah, hardly
<pitti> infinity: I usually start between 5:30 and 6:30 these days
<infinity> pitti: I often stop around then...
<infinity> So, now that armel's out of the archive, can we get rid of i386 too?
<infinity> I'm sick of its quirks.
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hi pitti
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<infinity> doko_: Alright, fix uploaded for glibc/i386, you can ignore my whining about dumpmachine versus multiarch.
<didrocks> dholbach: hey, FYI, I'll have to swap my pilot timing for Thu/Fri I guess
<dholbach> didrocks, sure - I'll leave that to you - I split up my patch pilot session yesterday/today because there was no other way
<didrocks> dholbach: ok ;)
<pitti> Daviey: are you aware of the maas autopkgtest failure? It's reproducible locally as well (https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-maas/lastFailedBuild/ARCH=amd64,label=albali/)
<pitti> Daviey: looks like a dependency or component mismatch issue
<dholbach> didrocks, do you know if there's plans to get the new libnice from Debian experimental? it seems to be needed for bug 1078991
<ubottu> Launchpad bug 1078991 in farstream (Ubuntu) "Sync farstream-0.2 0.2.2-1 (universe) from Debian experimental (main)" [Wishlist,Triaged] https://launchpad.net/bugs/1078991
<infinity> Setting up tgt (1:1.0.17-1ubuntu3) ...
<infinity> start: Job failed to start
<infinity> invoke-rc.d: initscript tgt, action "start" failed.
<infinity> dpkg: error processing tgt (--configure):
<infinity>  subprocess installed post-installation script returned error exit status 1
<infinity> pitti / Daviey : That's your bug ^^
<didrocks> dholbach: I didn't hear about any blocker on that, it seems it didn't change its soname, and have gstreamer 0.10 and 1.0 bindings
<didrocks> dholbach: so if you want to test/syncâ¦ ;)
<dholbach> why did Robert file a sync request for this and not just sync it?
<infinity> Maybe he still lives in the past and no one's told him he can sync things?
<Daviey> pitti: i am now :).. thanks.  We'll get that fixed up today.
<didrocks> dholbach: maybe he's not aware we can sync directly
<infinity> Curious, tgt starts here just fine.
<pitti> Daviey: great, thanks; I start prodding people now as soon this will become critical path, and you couldn't land uploads any more when their tests fail
<pitti> I got a lot of them fixed, but I can't keep up with them all
<infinity> pitti: Curiously, I can't make it fail locally.
<infinity> (Not that I care terribly, cause I should be napping, but I figured I'd give it a try)
<pitti> "run-adt-test -s maas" fails with the same reason
<infinity> pitti: Sure, I was just installing the package that failed to start, rather than running the full test environment.
<infinity> pitti: Perhaps it fails to start because the daemon relies on a recent kernel?
<Daviey> pitti: well, fixing it directly in the archive wouldn't last.. as this package is strictly managed via bzr.
<pitti> infinity: the kernel in the VM is just as recent as raring is
<infinity> Was just a thought, since I can't make it die in a quick test here.
<pitti> mvo: do you happen to understand the metaclass magic in aptdaemon in https://code.launchpad.net/~pitti/aptdaemon/pygobject-fixes/+merge/134942 ?
<pitti> mvo: I wondered if it can/should be fixed, or just dropped completely for simplicity
<pitti> infinity, Daviey: "sudo apt-get install tgt" in a VM reproduces it well
<pitti> I'll file a bug with the details
<infinity> pitti: Right, it's the "in a VM" bit I'm missing here. :P
<infinity> pitti: Worked fine in a chroot on bare metal, which is curious.
<pitti> Daviey: I filed bug 1081495 with the output of tgtd
<ubottu> Launchpad bug 1081495 in tgt (Ubuntu) "E: Sub-process /usr/bin/dpkg returned an error code (1)" [Undecided,New] https://launchpad.net/bugs/1081495
<infinity> pitti: Oh, out of curiosity, do you have autopkgtests for eglibc, binutils, and gcc?
<pitti> infinity: no, we don't
<pitti> infinity: well, the new eglibc triggered all autopkgtests that we have of course
<pitti> so we do rdepends check
<pitti> but not for eglibc itself
<infinity> pitti: I'd suggest (since things like "try to rebuild the whole archive lololol" would be pointless) they their tests should consist of each one triggering a rebuild test of the other two.
<infinity> pitti: If upgrading any of those three manages to keep the testsuite of the others passing, that's a win.
<pitti> infinity: i. e. the test script woudl more or less be "apt-get build-dep binutils; apt-get source -b binutils", right?
<infinity> pitti: (This came up today after I just spent hours fixing a regression in glibc due to the new gcc, and the inverse happens all the time too)
<infinity> pitti: Yeahp.
<infinity> pitti: Oh, and linux-libc-dev (so, the linux source package) should also trigger those three to a rebuild test, same reason.
<infinity> pitti: If linux-libc-dev's headers survive the GCC and glibc testsuites, they're good enough for regular users. :P
<infinity> (And if they break regular users but not the toolchain, I'd humbly suggest the users are wrong)
<infinity> *cough*
<pitti> hehe
<infinity> Definitely would have been nice to know when gcc and the kernel were uploaded (so, a couple of weeks ago) that they broke glibc, instead of finding out today while I was uploading for other reasons.
<infinity> But, yeah, toolchain rdep testing needs to have some sane limits, cause I assume our resources aren't infinite (and our time certainly isn't, when we start plugging this in as a britney blocker)
<pitti> so binutils seems to have a proper Vcs-Bzr:; gcc-4.7 is just apt-get source/UDD?
<infinity> pitti: apt-get source is the only "proper" way to get any of them for a rebuild test...
<pitti> infinity: yeah, bintuils and glibc tests are bearable, but gcc does take some time
<infinity> pitti: We don't want to know if something staged in a VCS is broken, we want to know if the archive is.
<pitti> infinity: no, I mean for adding the autopkgtests
<pitti> these need to go into their source
<infinity> pitti: Oh.  These end up in the source package themselves?
<pitti> yes
<infinity> pitti: Right, forward the binutils and gcc ones to doko, the eglibc one to me, and the linux one to apw, then.
<pitti> okay
<infinity> pitti: I'd rather have a modicum of control over how often toolchains get uploaded for non-critical things. :)
<pitti> yeah, I wasn't going to upload them just for that, hence I was looking for the VCSes
<infinity> Righto.  eglibc's VCS header is a filthy lie, I need to fix that.
<infinity> And no idea about doko's.
<infinity> And the kernel's isn't a lie, but you can't commit to it. :P
<infinity> pitti: To cut down on the pain, we could potentially refine the tests to do something like only build a single pass of libc6 and run the tests, only build a single kernel, etc.  Most of these things take so effin' long cause they build 4 times.
<pitti> yeah
<pitti> let's put that into a bug to keep track of the status and have a place to attach patches to
<infinity> Be my guest.  I'm thinking a nap at 2am might not be a bad plan.
 * infinity snickers at jcm getting flooded off freenode.
<infinity> pitti: If you file a big meta bug, can you toss me the number?  I suck at bugmail filtering about as much as someone who doesn't put much effort into filtering bugmail.
<infinity> (I should probably fix that some day)
<pitti> infinity: bug 1081500
<ubottu> Launchpad bug 1081500 in linux (Ubuntu) "Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc-dev, gcc, and binutils" [Undecided,New] https://launchpad.net/bugs/1081500
<infinity> pitti: Great.  I look forward to patches that teach me all about autopkgtest by example. ;)
<pitti> infinity: http://developer.ubuntu.com/packaging/html/auto-pkg-test.html :
<pitti> :)
<infinity> I don't accept HTML patches.
<pitti> nah, I'll send a first one, and maybe a second
<pitti> I expect they will look pretty much alike, except for the "only build one flavour" bit
<infinity> The only one flavour bit may take some refinement.
<infinity> The kernel's pretty good at it (you can call individual targets out of debian/rules), glibc might actually take some wrangling to convince it to try.
<infinity> I'm happy to do that bit myself. :P
<infinity> Anyhow, nap time before morning meetings.
<pitti> yeah, once we enable those on armhf, any speedup will be greatly appreciated
<infinity> Gah, and that override bug.
 * infinity promotes kernels to main before going to bed.
<lifeless> good times
<lifeless> infinity: what TZ is infintytime aligned with atm ?
<pitti> lifeless: all of them :)
<infinity> lifeless: I reside in MST7MDT, I'm currently awake in... Actually, close to that.  It's only 2am.  Not a horrible bedtime.
<lifeless> pitti: I think that would get a dividebyzero error :)
<cjwatson> jdstrand: cool
<infinity> cjwatson: Having to override all the kernels in raring again after britney promoted them reminded me to be annoyed by that bug.  Did you have something filed for it?
<infinity> cjwatson: (Still wildly confused by why this happens for proposed->release but not proposed->updates, unless britney's somehow copying differently than sru-release does...)
<cjwatson> I don't think I filed one
<cjwatson> I was just doing morning "oh, images failed, oh look, component-mismatches"
<cjwatson> But the output suggests you beat me to it
<infinity> Yeah, c-m is a lie, I already fixed.
<infinity> Thankfully, you didn't notice until the publisher started. :P
<infinity> That double-override-eats-binaries bug is also a lovely one.
<infinity> And likely to get stumbled on a lot while this current "oops, I forget everything during migration" business is going on and people scrable to fix the release pocket.
<infinity> s/scrable/scramble/
<cjwatson> Overriding twice to main doesn't count, though, since that doesn't actually produce new pubs.
<infinity> Even if it was previously in universe?
 * infinity is unfamiliar with that bit, and is suddenly happy he is.
<cjwatson> infinity: By the time of the second override attempt, it's now in main so doesn't get re-overridden.
<cjwatson> (Sorry, I was busy trolling a phone scammer.)
<didrocks> hey cjwatson, it's been 10+ minutes I tried to copy 3 components from the ubuntu-unity ppa to the archive, and it seems the first attempt failed :/ any way to see what happened?
<dholbach> tkamppeter_, hello - do you think you can have a look at https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/1069324 and see if you can upload the patch?
<ubottu> Launchpad bug 1069324 in hplip (Ubuntu) "diagnose_queues.py crashed with NameError in su_sudo(): global name 'utils' is not defined" [Medium,Triaged]
<infinity> didrocks: If it failed, you should have gotten an email with an OOPS in it.  Maybe.
<didrocks> infinity: the thing is that the bot is https://launchpad.net/~ps-jenkins and it's a ML. But mmrazik isn't around to check them
<infinity> There's a bot auto-copying from PPAs to the archive?
<cjwatson> infinity: Yeah, didrocks and I agreed on this
<infinity> Fair enough.
<cjwatson> didrocks: Package name?
<didrocks> cjwatson: indicator-sound, indicator-power and indicator-messages
<cjwatson> "Cannot copy DDEBs to a primary archive"
<didrocks> ah, so we need to ask for removing the ddebs from the ppa
<cjwatson> Hmm
<didrocks> (would have been useful for the autopilot crash though)
<infinity> Yeah.
<pitti> infinity: actually, didn't we want to enable that for the main archive?
<infinity> pitti: We do, yes.  Hit me up tomorrow, and we'll talk. :)
<didrocks> like if autopilot crashed with a stack, we would use those ddebs to debug
<cjwatson> Nothing would take care of rebuilding the ddebs for the main archive, if you remove them
<infinity> didrocks: It's a devirt PPA, right?
<pitti> to replace those apache servers
<cjwatson> Which would mean that errors.u.c will be unable to display useful tracebacks for those packages
<infinity> cjwatson: No need to rebuild them.  The trick is to do the same thing the kernel PPA does.
<didrocks> infinity: yeah, it's building on all archs
<pitti> infinity: I thought you wanted to go to sleep an hour ago :)
<infinity> cjwatson: Which is to act like the primary archive.
<didrocks> cjwatson: right, but the tests are runned before copying to the main archive, so being able to debug there was useful
<infinity> cjwatson: IOW, not have the flag on that publishes ddebs in .changes
<mitya57> dholbach, I've already asked him to do that :)
<dholbach> mitya57, ok, perfect :)
<cjwatson> infinity: And they then get picked up for ddebs.u.c?
<cjwatson> Presumably as long as versions never clash.
<infinity> cjwatson: Sure, they're all slammed in public_html.
<infinity> Right.
<infinity> The real solution is some JFDIing by pitti and I to switch this all over.
<didrocks> how does the kernel do to have ddebs?
<didrocks> as it's not rebuilt
<infinity> And then scour the world for PPAs that do weird things and make them do what didrocks's does.
<infinity> didrocks: The kernel's PPA acts just like the primary archive.  It builds ddebs, but doesn't upload them.
<infinity> didrocks: And they get scraped off the buildds by pitti's evil script, the same as they are for the primary archive.
<pitti> cjwatson: we'd eventually like to stop having to stage them on the buildds for 7 days and those rather unreliable apache servers to publish them; I'd much rather pull them from the librarian
<didrocks> infinity: ah, ok, so evil hack :)
<infinity> But yes, we should fix all of this hackish crap.
<cjwatson> didrocks: In infinity's proposal, you'd debug by getting the ddebs from ddebs.ubuntu.com instead.
<infinity> My proposal is the "right way" to do things today.
<infinity> It may not be in a few days, if pitti and I get some ducks in a row.
<pitti> well, ddebs.u.c. would continue to only publish Ubuntu ddebs; but copying packages from PPA into the ubuntu archive shoudl copy the ddebs along?
<infinity> (The right way to do things if your PPA is essentially an extension of the primary archive, like kernel and security are)
<cjwatson> pitti: In some new world order that might be possible, sure.  I'm aware of the plans.
<infinity> pitti: Yeah, in the new world order, ddebs would be attached to build records, and copying with binaries will get the ddebs too.
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> pitti: That part looks like it might need an LP patch, but likely just removing a check.
<infinity> (We probably also need to test and make sure that the publisher doesn't try to vomit ddebs on disk when they show up in the primary archive)
<infinity> I guess I might need to dust off a local LP instance tomorrow, since I don't have dogfood to play with. :/
<infinity> Aaaanyhow.  pitti's right, I'm supposed to be asleep.
<didrocks> how can I help to make things happen? :)
<infinity> didrocks: Depends on which things.
<pitti> sing "soft kitty" to infinity, so that he gets to sleep, and is awake tomorrow? :-)
<didrocks> pitti: can do that :)
 * infinity might not appreciate this so much.
<didrocks> infinity: I'm not really familiar with the whole copy to ddeb.u.c process, but if you think I can be of any help
<cjwatson> infinity: Better to construct a unit test that exercises it, since you'll want one of those to go with any change anyway.
<infinity> cjwatson: Sure, this doesn't preclude the value of doing actual end-to-end testing to make sure it does what you think you claim the unit test is testing.
<cjwatson> didrocks: For the meantime, you could copy without binaries.  I know that strictly that partially invalidates your testing, but confirming that the source builds sensible binaries in autopilot is still a lot better than nothing.
<didrocks> cjwatson: well, if it's just a question of days, I think I'll better to wait
<infinity> Or, he could ask webops to twiddle his PPA to make it look "like the kernel team's".
<tkamppeter> dholbach, I can do so. Simply for Raring or as Quantal SRU?
<dholbach> mitya57, ^?
<infinity> But if you do that, you need to trat it like the primary archive, never reuse version numbers (even if you delete something), etc.
<infinity> didrocks: It could be more than days to get this all tested and sane.  I'm not about to commit.
<infinity> didrocks: But it's seconds to make your PPA behave differently.
<didrocks> infinity: I already do that, depends on the timing for the "proper fix" in your mind
<didrocks> infinity: ok, so right now, asking webops to twiddle the PPA seems to more robust idea?
<didrocks> the*
<mitya57> tkamppeter, it would be good to have this SRUed if you plan a SRU, otherwise I don't think it's worth that
<didrocks> waiting for the real fix?
<infinity> didrocks: Either that or, as Colin suggests, copying source-only.
<infinity> didrocks: But the kernel PPA method DTRT for now.
<didrocks> I'm not confortable with that, as we won't have in proposed the real stack/build order we tested
<infinity> didrocks: Where "the right thing" is "exactly the same awful hack as the primary archive".
<didrocks> infinity: yeah, I understood that ;) do you have anyone in mind knowledgeable about it in IS?
<cjwatson> Don't do that, ask webops.  It's an alias.
<cjwatson> Duty admins highlight on it.
<didrocks> ok, doing so :)
<cjwatson> (#launchpad-ops, internal)
<didrocks> thanks cjwatson, doing that right now :)
<infinity> cjwatson: Actually, they prefer #webops.
<cjwatson> Ah, that works too
<didrocks> ah, too late :)
<mitya57> hi barry
<mitya57> barry: do you know python's cElementTree code? If yes, maybe you can take a look at http://bugs.python.org/msg175235?
<mitya57> (this is cause of debian bug 692285)
<ubottu> Debian bug 692285 in src:python-docutils "python-docutils: FTBFS with Python 3.3: TypeError: must be Element, not _ElementInterfaceWrapper" [Important,Open] http://bugs.debian.org/692285
<infinity> doko_: Oh, for the love of... How am I meant to divine the mystery path for the multilib c++ includes?  *sigh*
<mlankhorst> :-)
<mlankhorst> gcc -v?
<infinity> Yeah, I was avoiding using the whole output of gcc -v, since it includes paths I might not want.
<infinity> Not much point in using nostdinc if you then end up appending all of stdinc's paths to your call.
<mlankhorst>   gcc -print-file-name=include
<infinity> Wrong one.
<infinity> Are there others? :P
<infinity> What I'm after is /usr/include/c++/4.7 /usr/include/c++/4.7/backward /usr/include/x86_64-linux-gnu/c++/4.7
<infinity> That last one is a bitch to construct for multilib builds.
<infinity> Since it ends up as /usr/include/x86_64-linux-gnu/c++/4.7/32 or /usr/include/x86_64-linux-gnu/c++/4.7/x32
<infinity> Rather than using the target triplet.
<infinity> (I suppose to avoid clashing with the multiarch version of same)
<mlankhorst> g++ -E -x c++ - -v < /dev/null
<infinity> Yes, I know.  That's where I copied and pasted the above from.
<infinity> But the list also includes things I don't want.
<mlankhorst> yeah :/
<infinity> If I could guarantee the top three were always the ones I want, I'd go with that.
<infinity> But I'm not sure that's a sane assumption.
<infinity> (Though currently true)
<mlankhorst> |grep c++ ? :P
<infinity> mlankhorst: Well, that's definitely correct today.  Almost certainly not upstreamable.
<infinity> mlankhorst: But meh.  For now, it might do.
<mlankhorst> what are you trying though
<mlankhorst> and if it's meant for upstream, you could just add a -dump-includes to gcc or something
<infinity> Hrm?  This is the glibc test suite.
<infinity> Which worked fine in hackish ways until doko's new gcc.
<mlankhorst> still, could be better in long term to just get it over with and add it, even though that menas dealing with gcc coding style..
 * mlankhorst shivers
<infinity> Ahh, -print-multi-directory gets me that...
<cjwatson> Hmm, has libnss-files started to autocreate /etc/{protocols,services} or something?
<infinity> Except I can't get the multiarch dir in the same invocation, cause that ends up wrong.
 * cjwatson is trying to debug chroot weirdness
<infinity> cjwatson: No, schroot copies those in unless you tell it not to.
<cjwatson> Oh is *that* it
<cjwatson> OK, thanks
<infinity>  /etc/schroot/default/copyfiles
<infinity> Or, no. /etc/schroot/default/nssdatabases
<infinity> That one.
<infinity> And in mine, #services and #protocols are commented out. :P
<pitti> didrocks: ^ please try the "soft kitty" approach :)
<infinity> Likely due to debugging a weird unreproducible "should have build-depended on netbase" build failure.
<cjwatson> Right, that explains rather a lot of failures any time netbase gets upgraded.
<cjwatson> Or rather, installed, since it isn't in the base.
<didrocks> pitti: yeah, it seems that's really needed, he will never stop! :)
<infinity> pitti: WRT your reverse-dep analysis, note that any of those packages having build-deps on each other is purely due to versioned build-deps (which can, and often do, go away).
<infinity> pitti: Since all of those packages are build-essential, they don't need to be in build-deps at all. :P
<pitti> infinity: right, I was mostly checking how the current deps would work wiht our current parser
<infinity> pitti: I suspect that relying on rdep triggering to always work for that set is either asking us to always carry build-dep cruft (which seems wrong), or just being naive. :)
<cjwatson> infinity: are services and protocols the only ones you have commented out there?
<pitti> infinity: I'm just discussing that with apw
<pitti> infinity: we can probably introduce an XS-Test-Depends: field or something like that
<infinity> cjwatson: Yeah, none others have caused me personal grief.
<cjwatson> OK, great
 * cjwatson tweaks his charm
<pitti> infinity: problem is that debian/tests/control isn't exposed in the apt indexes, so we cannot trigger on changes of pure test dependencies right now
<pitti> infinity: (mind you, this is stretching what autopkgtest was designed for quite a lot, so we need to make up things here)
<pitti> infinity, apw: of course we could also just special-case those four pacakges and hardcode their mutual trigger dependencies in our scripts
<infinity> pitti: That was sort of what I was suggesting when I brought it up.
<infinity> pitti: I thought it would be something server-side, not in the packages.
<apw> XS-Testsuite-Depends: i suspect if we do it there
<pitti> we still need to add the actual tests to the packages
<infinity> Yeah, we need the tests in packages, I'm fine with that.
<infinity> Does anyone in Debian use this stuff (ie: is it upstreamable without annoying people with "useless cruft")?
<pitti> infinity: no, the tests themselves should be in the packages, but I'm ok with hardcoding the depends set for this particualr "mini rebuild test" case
<pitti> infinity: yes, we upstream a lot of tests
<infinity> Alright, cool.
<pitti> they are supposed to run in http://jenkins.debian.net/ at some point
<pitti> infinity: dep-8 is a Debian standard, after all :)
<infinity> The only slight problem with hardcoding the set is that one of these four packages keeps changing its name.
 * infinity glares at gcc-X.X
<pitti> infinity: ah, if only there was some way of expressing that with a pattern or so..
<pitti> "regular patterns" or "globby expressions" or so
<infinity> pitti: Well, but if you express it as a regex, you just triggered a rebuild of ALL gcc versions in the archive, when that may or may not be what we want.  Actually, maybe it would be.
<infinity> But we wouldn't want the inverse.
<infinity> That's the problem.
<infinity> When gcc-4.5 revs (if it's still in the archive, too lazy to look), we don't care that it can't build the kenrel and glibc properly.
<pitti> infinity: anyway, hardcoding this in the scripts requires manual maintenance anyway; having to change it with each new compiler version isn't that big of a deal
<infinity> Nor do we care if gcc-4.8 can't do either of those things.
<infinity> (yet)
<pitti> infinity: but it can parse the defualt version from the "gcc" metapackage
<infinity> But we do care if glibc makes gcc-4.8 worse.
<infinity> pitti: If only it were that simple. ;)
<infinity> pitti: (Last cycle, the default gcc was 4.7, but glibc was built with 4.6, not sure what the kernel used)
<apw> so the source packages expressing that works no?
<infinity> apw: Yeah, expressing things in the source package might make more sense.
<apw> as i am saying linux -> gcc-4.7
<pitti> infinity: but that's fine -- glibc would then have a gcc-4.6 build dep, and the normal reverse dep parsing would kick in
<infinity> pitti: Oh, fair.
<infinity> I think I'll skip on the brown-paper-bag glibc upload tonight and finally go nap.
<infinity> And fix this in the morning with an ugly non-upstreamable hammer.
<infinity> And die a little inside.
<apw> pitti, so i think you are saying the following is enough: http://paste.ubuntu.com/1374603/
<pitti> apw: looks good, except that we don't implement XS-Testsuite-Depends ATM
<pitti> apw: and in fact we might not use that yet, as it's not covered by DEP-8
<pitti> apw: I think we should start with hardcoding those
<infinity> apw: And if that header actually worked, you'd want binutils in there too.
<apw> infinity, i think i already dep on that in reality, so its ok
<pitti> not needed, linux-source pulls in binutisl
<apw> though it might be clearer indeed
<apw> ack
<infinity> Eh.  While it's okay that there's an implicit one, I'd prefer being explicit.
<infinity> (Thinking of my specific glibc use-case where build-deps come and go more often than people I date)
<pitti> well, if no part of linux depends on eglibc, do we actually need to test that then?
<infinity> pitti: I'm trying to sort out what that header will mean.
<apw> i am expecting to need to test eglibc will still build after linux publishes
<infinity> pitti: Is it "when this is upgraded, test these" or "when these are upgraded, test this"?
<apw> as it consumes my binary packages
<pitti> infinity: the latter
<infinity> apw: Yes, I want to test eglibc when linux-libc-dev lands.  The inverse isn't necessary.
<pitti> but as I said, I wouldn't add this new header just yet
<pitti> and instead put that into lp:auto-package-testing for now
<pitti> we can clean it up when it works and we can convince Debian to adopt the header into DEP-8
<pitti> (and Debian's autopkgtest)
<infinity> pitti: Oh, and as to the DEB_BUILD_OPTIONS=whatever thing, that would probably be a DEB_BUILD_PROFILE in the new world.
<infinity> DEB_BUILD_PROFILE=autopkgtest or something.
<pitti> WFM :) I just wanted to take a variable taht already exists
<apw> pitti, ok so i'll add it commented out so we remember
<infinity> Yeah, this is precisely why DEB_STAGE was changed to DEB_BUILD_PROFILE, so it could be genericized into a "mangle your build order/output" thing.
<apw> pitti, when you are expressing those, linux-libc-dev only ever comes from linux
<pitti> infinity: it should be "rebuild-test", not "autopktest", IMHO (we'd want that for the full rebuild tests too, I think)
<apw> pitti, so DEB_BUILD_PROFILE=autopkgtest or DEB_BUILD_PROFILE=rebuild-test
<pitti> apw: right, but we'd set that in lp:auto-package-testing globally then
<apw> indeed, just adjusting my support within the package
<pitti> a package can't set the environment in autopkgtest
<infinity> pitti: I dunno.  A full rebuild test should just be a normal build.
<infinity> pitti: (My current glibc build failure wouldn't be a failure if I wasn't building the second pass, actually) :P
<apw> infinity, i am proposing to use it to build just the first flavour on each arch
<apw> infinity, for the autopkgtest case
<infinity> apw: Right, which is why I think it's wrong for it to be for "all rebuild tests".
<pitti> so if it's wrong for the "all rebuild tests", how is it not wrong for the "mini rebuild test"?
<infinity> pitti: It's a speed-versus-accuracy tradeoff.  The "right" thing to do when uploading a new toolchain is to rebuild test the whole archive before we let the toolchain in.  We're not going to do that, cause we'll get lynched.
<infinity> pitti: So, autopkgtest as a blocker to migration needs to hit good test coverage without being too heavy.
<pitti> okay
<infinity> pitti: A full rebuild test is async, and can be as heavy as you want.
<pitti> well, except that it still takes like a month on arm :)
<infinity> Not true.
<infinity> The last time was because buildds kept ABORTing every few minutes.
<infinity> The time before that, armhf finished before amd64.
<doko_> infinity, g++ -E -x c++ - -v < /dev/null | fgrep /c++/
<infinity> People have short memories.
<infinity> doko_: Yeah, I was going to settle on the grep c++ solution.
<infinity> doko_: Is that guaranteed to always only be the internal includes?
<pitti> apw: oh, and you might want to add a bug ref to #1081500 to the commit ?
<infinity> doko_: Like, in an unstreamably reliable way?
<doko_> ig glibc is that backward, it even includes the backward headers
<apw> pitti, will do
<doko_> bug 1081500
<ubottu> Launchpad bug 1081500 in linux (Ubuntu) "Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc-dev, gcc, and binutils" [Low,Triaged] https://launchpad.net/bugs/1081500
<apw> once you lot hash out what the DEB_PROFILE is going to be
<infinity> doko_: It might not actually need the backward ones, but it does need the tricky-to-construct arch-path ones. :P
<infinity> apw: Doesn't matter, we can change it once guillem tells us we're wrong.
<pitti> apw: so DEB_PROFILE=autopkgtest WFM at the moment
<infinity> (s/DEB_PROFILE/DEB_BUILD_PROFILE)
<infinity>  /
<apw> ifeq ($(DEB_BUILD_PROFILE),autopkgtest)
<infinity> apw: I bet you're having a good laugh now about having implemented all that do_* stuff reusably. :/
 * infinity suspects he's going to have to take some dull scissors to glibc to make this work.
<xnox> ifneq (,$(ADTTMP)) ?
<apw> infinity, i am feeling somewhat smug at having rejected those original crosscompile patches about 4 times before implementing them right indeed :)
<apw> pitti, so i guess are you happy enough for me to push these to our package for the next upload ?
<pitti> apw: sounds good, thanks! I'll commit http://paste.ubuntu.com/1374628/ then
<apw> expect carnage in the next upload :)
<pitti> apw: so the next linux upload would trigger a binutils autopkgtest, provided that we get the binutils test in by then
<pitti> apw: if that works, I can add the remaining "virtual" dependencies, so that the next upload will trigger all three
<apw> pitti, and presumably its own build test too
<pitti> but let's start small first
<pitti> apw: right
<apw> indeed small please
<infinity> pitti: Hrm, I guess this would be something I could add to glibc tomorrow as well, so my brown-paper-bag comes with the frills of at least some other change. :P
<pitti> infinity: yeah, hides much better in a changelog that way :)
<infinity> (Though mine won't do the "only one flavour" thing straight away)
<didrocks> cjwatson: infinity: it worked \o/ Thanks a lot :)
<pitti> infinity: so that should be http://paste.ubuntu.com/1374603/ with the obvious debian.master/control.stub.in â debian/control
<infinity> didrocks: NP.
<pitti> infinity: and dropping the XS-Testsuite-Depends thing
 * infinity is curious about needing a fake test to trigger a rebuild, but whatever.
<infinity> (I know why, it just feels a bit inelegant)
<doko_> infinity, if you have other suggestions for the path, I'm fine, but the current location wasn't good enough for multiarch
<pitti> infinity: this actually is intended for building the tests that you are about to run
<pitti> infinity: this is just abusing this to provide a rebuild test :)
<infinity> pitti: Well, because our rebuild also happens to run tests, so this makes some sense.
<pitti> infinity: but if we can run the built test suite against the installed glibc, this would be the intended (and ideal) case
<apw> pitti, it would be nice perhaps if you could just have Tests: <empty>
<infinity> doko_: Yeah, I'm not sure I have better ideas.  The mixing of both multiarch and multilib on the same path just hurts a bit.
<pitti> apw: that might or might not work, I haven't tried
<infinity> pitti: You mean after installing the one we just built?  Cause running it against the archive one is almost pointless.
<pitti> infinity: no, running it against the archive one is the whole idea of autopkgtest
<infinity> pitti: Yes, but pointless in THIS case.
<infinity> pitti: Cause we're trying to see if a new toolchain misbuilds everything.
<pitti> right
<pitti> in the context of a rebuilt test
<infinity> pitti: I agree that detached testsuites are handy for other things.
<infinity> Also a pain in the ass to do to some larger suites. :/
<pitti> but it's a good thing in its own right
<infinity> (We did it a ton at Nokia/Maemo, cause they also had an out-of-package-run-against-installed-packages test harness)
<infinity> The telepathy suite was very violently mangled to make this work.
<apw> pitti, i guess the sort of thing our real package test should do is check that the abi does not change
<infinity> Not my finest work.
<apw> pitti, as in check that the rebuild abi matches the binary packages we have in the archive
<pitti> apw: right, or integrate your existing tests to run in autopkgtests (file system tests and what not)
 * apw shudders
<pitti> apw: do we ship the abi files?
<apw> pitti, yep
<infinity> pitti: Yes, but not in the source that produced them.
<infinity> So, the test needs to grab the debs from the archive to compare.
<infinity> Which isn't hard, just a bit weird.
<apw> infinity, well i should be able to make the test build-dep: on the kernel binaries
<pitti> well, the kernel is already installed
<pitti> the files should be "just there"
<infinity> pitti: Oh, I suppose there's that.  If it's the same flavour that Andy builds. :)
<apw> are all my binar spawn installed then ?
<pitti> apw: all build, binary, and test depends are installed
<pitti> and of course whatever is in a base system (currently the cloud images)
<apw> ok so we can depend on the real binary generated packages if we need them
<infinity> Right, so just test-depending on all his kernel images would get him all his ABI files.
<pitti> you still need to check the installed kernel version of course, as the -proposed one might bump api
<pitti> abi
<infinity> Yeah, hence the test-depends, cause that could be exact versions.
<infinity> No guesswork.
<pitti> *nod*
<apw> sounds 'awsome' :)
<pitti> apw: debian/tests/control: Depends: @
<pitti> will install all binaries produced by that source package
<pitti> (which is in fact the default if you don't specify anything)
<apw> oh great, so it'll just be there
<infinity> What if the source produces conflicting binaries?
<pitti> you lose and can't use @
<infinity> I guess autopkgtst just explodes until you specify it?  Check.
<pitti> you can split your test and set different depends: for each of them
<pitti> infinity: yes, it'll fail with a package installation failure
 * infinity nods.
<pitti> much like maas' test
<pitti> (in which case it's a legitimate failure)
<infinity> didrocks: Alright, I'm ready.  Soft Kitty me.  Do it.
<infinity> Friggin' 5am.
<infinity> Oops.
<pitti> â© soooft kitty, waaarm kitty, little ball of fur âª
<cjwatson> didrocks: Oh good
<didrocks> infinity: :)
<didrocks> cjwatson: rerunning for checking that it's skipping part of the stack now, added the cron to lillypilly and we should be fine! :)
<cjwatson> Is this in cu2d/ ?
<cjwatson> (BTW you know the singular of "series" is also "series", right? :-) )
<doko_> infinity, but g++ in eglibc is only needed for the tests, not the build, afaik
<infinity> doko_: Yep.  I'll fix this when I wake up, using your grep suggestion.
<infinity> (Well, paring down the whole thing to be saner and upstreamable too)
<infinity> Nap time.
<didrocks> cjwatson: right cu2d :)
<didrocks> cjwatson: hum, I powndered, I'll fix it :)
<doko_> I think I won't upstream the gcc patch upstream
<infinity> cjwatson: I might not be at the meeting in the morning for the team I'm only sort of a part of.  Just pretend I'm American and took the week off.
<didrocks> (english is confusing)
<cjwatson> Mm, I suspect we'll have a low turnout
<cjwatson> didrocks: In this case I blame Latin.
<infinity> doko_: Well, I'm upstreaming the glibs bits cause I don't want to carry it.
<didrocks> cjwatson: :)
<nigelb> 32
<didrocks> indicator-sound as well autolanded and other project ignored :)
<pitti> https://launchpad.net/ubuntu/+source/indicator-sound/12.10.2daily12.11.21.1-0ubuntu1
<pitti> wow
<pitti> didrocks, jibel: congrats! this is awesome
<didrocks> thanks a lot to jibel :)
<pitti> will there be sane version numbers at some point, at the end of the release?
<didrocks> pitti: the goal is to have a simple version number before "daily"
<didrocks> then, it's <number>daily12.11.21
<pitti> so you want to do away completely with upstream releases?
<didrocks> there, the added .1 is because I had to rerun it ^ (I hopefully took care of this case)
<didrocks> pitti: once a cycle I would say
<didrocks> like, at the end
<pitti> *nod*
<didrocks> but it's up to upstream to do it
<didrocks> so, if I rerun right now, for the same components
<didrocks> and there is new code to land
<didrocks> it will be .2, .3â¦
<didrocks> until tomorrow :)
<didrocks> pitti: also, the credit is given to who fixed the bug: https://lists.ubuntu.com/archives/raring-changes/2012-November/001547.html
<didrocks> (don't worry about the 2 "Automatic snapshot from revision", one is for boostrap and was excepted. Didn't worth workarounding this)
<tumbleweed> didrocks: where is the script that's doing this published?
<didrocks> tumbleweed: https://launchpad.net/cupstream2distro
<tumbleweed> ta
<didrocks> yw :)
<tumbleweed> didrocks: should there not be a whitelist of packages that are allowed to be copied? not everyone in the team owning that PPA has upload rights
<didrocks> tumbleweed: there should be no direct upload to the ppa
<didrocks> tumbleweed: the scripts are doing the upload
<tumbleweed> that's not enforced by anything, though
<Daviey> Anyone have any thoughts on a merge of rsyslog from experimental ?
<didrocks> tumbleweed: indeed, but only the package in a stack can be copied
<tumbleweed> didrocks: what defines the stack?
<didrocks> tumbleweed: the jenkins jobs: https://jenkins.qa.ubuntu.com/view/cu2d/
<tumbleweed> given that administation of that jenkins instance has no corellation to uplaod rights, I'd still prefer a whitelist
<cjwatson> I tend to agree
<tumbleweed> cjwatson: does the tech board intend to review this workflow?
<cjwatson> tumbleweed: I reviewed it at UDS; I don't know that it needs full board consideration unless you want to raise a specific problem with us
<didrocks> tumbleweed: what the whitelist will give? people will in ~ubuntu-desktop will be able to edit it, and the desktop package set doesn't covered all components here AFAIK
<cjwatson> didrocks: Not if you put the whitelist in somewhere only ubuntu-archive@lillypilly gets to edit.
<cjwatson> Given that that account is the one whose privileges are being used, it's entitled to limit them.
<didrocks> cjwatson: I don't know what we try to fix here. We can have restricted access to jenkins to people who can have those upload rights
<cjwatson> didrocks: This job is not supposed to be an end-run around the system of upload rights.
<didrocks> cjwatson: it seems way easier that having a whitelist which will always be outdated compared to the stack
<cjwatson> didrocks: tumbleweed is rightly objecting to what seems to be such a system.
<didrocks> cjwatson: and it is not
<cjwatson> But it is, as long as people without upload rights can cause any package they like to be uploaded.
<tumbleweed> how often do you add new packages?
<didrocks> so duplicated list of stack? one in jenkins, one in lillypilly
<didrocks> tumbleweed: well, in the first weeks, it will be daily, as soon as they are bootstrapped to this process
<cjwatson> I don't care where the list of packages lives as long as nobody without upload rights can edit it.
<didrocks> cjwatson: so you are fine with that list being defined in jenkins?
<tumbleweed> I have no idea who has access to the jenkins instance. If I'm assure that only core-devs can admin it then I guess that'd be OK. Somehow, I doubt that's true, though.
<didrocks> knowing that only people with upload right can access to it (maybe not everyone, but some)
<cjwatson> didrocks: I'm fine with anything that meets the condition I laid out; I don't know how your jenkins instance is administered.
<cjwatson> So I can't answer that question.
<didrocks> because then, you can say the same with the jenkins machine
<didrocks> IS can administrate those macihnes
<didrocks> as IS can change something in lillypilly
<cjwatson> Yeah, I don't mind assuming IS aren't malevolent
<cjwatson> There's no point going down a rathole here
<didrocks> are you assuming that QA is?
<cjwatson> I think I should leave this conversation.
<tumbleweed> as an outsider, I accept that canonical have sysadmins who have root on all the machines
<cjwatson> I am assuming that people will use privileges they believe themselves to have to get their jobs done efficiently.
<didrocks> tumbleweed: QA are the sysadmins for jenkins
<tumbleweed> I'm not convinced that the QA team should have a backdoor to the archive
<didrocks> so we need to remove jenkins access to people administrating it?
<cjwatson> You're the one who wants the list to live in jenkins.
<didrocks> cjwatson: well, the list is one thing
<didrocks> what we upload is way more important
<didrocks> and the source packages are created by jenkins jobs
<didrocks> so this is the part that QA can play with, change the content and so on
<didrocks> the list won't prevent that
<cjwatson> That depends on your point of view.  There are plenty of things that the content of these packages doesn't affect at all.
<cjwatson> ubuntu-archive@lillypilly can do *anything*.
<cjwatson> But not all the world is Unity ...
<tumbleweed> but they're only reviewed g:q!
<tumbleweed> gaah
<didrocks> cjwatson: I know that, but I mean, if we have a whitelist, they can get something in Unity and break the rule of the upload rights
<didrocks> so I don't see what the whitelist is fixing here
<didrocks> I can do it, but that will fix nothing
<cjwatson> They can't decide that somebody isn't fixing a bug in some other package quickly enough and stick it temporarily (and well-meaningly) in jenkins
<tumbleweed> personally, I'd like the automatic uploads to be approved for a particular set of packages
<didrocks> tumbleweed: it's all packages that are from canonical upstream, the UDS session was clear for that
<cjwatson> And all I want to do is enforce that it can only be used for such packages.
<tumbleweed> didrocks: right, then it should be staright-forward to come up with a list of those
<didrocks> cjwatson: I'll implement the whitelist on lillypilly, still unsure what it adresses those
<cjwatson> I consider this due diligence.
<didrocks> tumbleweed: there are those that are bootstraped and the others that are not
<tumbleweed> didrocks: that doesn't concern me too much
<didrocks> tumbleweed: it does for me
<tumbleweed> it stops the robot doing things that it isn't allowed to
<didrocks> but again, i'll implement that whitelist
<tumbleweed> didrocks: thanks
<didrocks> it's still fixing nothing IMHO compared to what others can do with this
<didrocks> but I'll do it
<cjwatson> The limitation of upload rights is an important part of our organisational security.
<didrocks> cjwatson: I still reiterate that anyone having jenkins access to jenkins machines can change the tarball content
<cjwatson> And it's still valuable to limit the set of packages even if changes to those packages' content are unrestricted.
<tumbleweed> I'd also prefer it if the detection of packaging changes happened at the bot level, rather than jenkns. But that's a minor issue, compared to having unrestricted upload rights
<cjwatson> Because it is easy to review changes to a single package, or a small set of packages; it is very hard to review changes to the entire archive.
<didrocks> let me implement it, I'll ping you back then
<cjwatson> So I accept your point that anyone with jenkins access can change the tarball content, but it doesn't change my mind.
<cjwatson> tumbleweed: I agree, seems like the security boundary should be where the check happens
<tumbleweed> s/minor/contained/
<GunnarHj> cjwatson: Hi Colin, wondering if you could take a look at the proposed solution to bug 952185. Saw Steve's comment at bug 584249, but I felt that a pam config change might still be ok. And it works. :)
<ubottu> Launchpad bug 952185 in pam (Ubuntu) "~/.pam_environment not parsed when HOME is encrypted" [Undecided,In progress] https://launchpad.net/bugs/952185
<ubottu> Launchpad bug 952185 in pam (Ubuntu) "duplicate for #584249 ~/.pam_environment not parsed when HOME is encrypted" [Undecided,In progress] https://launchpad.net/bugs/952185
<cjwatson> GunnarHj: Sorry, I don't consider myself immediately competent to review that
<GunnarHj> cjwatson: Is Steve the one and only? (Think he's on vacation.)
<cjwatson> I don't know.
<tumbleweed> didrocks: so, what happens if some core-dev uploads an emergency PS stack packaging fix to the archive? it doesn't like like it would stop the bot from overwriting it the next day
<didrocks> tumbleweed: it would stop it
<didrocks> see prepare-package
<didrocks> and so the doc at the end of it
<tumbleweed> ah, there it is, ta
<GunnarHj> cjwatson: Think I'll wait til Steve is back, then, since he seems to do the bulk of the pam maintenance. Thanks anyway.
<cjwatson> Sorry I can't help.
<GunnarHj> cjwatson: No problem.
<tumbleweed> didrocks: shouldn't that check should happen as close to the copy as possible? rather than before the source build?
<didrocks> tumbleweed: we will never get to the "copy" state if the source build fails
<cjwatson> But consider a race condition
<didrocks> yeah, I can do a second check if needed
<cjwatson> We can't actually close it, but we can make it as narrow as possible
<didrocks> good point, adding that
<mspencer> pitti: png re. bug 657275
<ubottu> Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275
<apw> pitti, as the kernel depends on kernel-wedge, under autopkgtest i assume an upload there would trigger testing in linux -- correctly too
<didrocks> tumbleweed: cjwatson: whitelist built: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/86
<didrocks> I'll add the tests with the whole framework for testing
<didrocks> I need more investigation to build properly the last-minute check for upload (particularly as I'm out of jenkins, how to get emails about those failures, even if I read -changes without being spammed with the rest) and passing the "previous last automated upload" version to the rsync file
<nemo> Hey guys, I'm stuck on W:Failed to fetch gzip:/var/lib/apt/lists/partial/mirror.anl.gov_pub_ubuntu_dists_quantal_universe_i18n_Translation-en   after attempted upgrade.
<nemo> are not all the mirrors updated yet?
<nemo> also "bzip2: (stdin) is not a bzip2 file." on console.
<nemo> the other possibility is the idiots here screwed up their explicit whitelisting of mirror.anl.gov on the stupid Websense server. which I'm totally open to
<nemo> oh. right. part of that error was "Encountered a section with no Package: header"
<nemo> hm. maybe if I run ltrace -S on update-manager I can figure out what URL it is trying to hit
<didrocks> cjwatson: tumbleweed: and the extra check for an upload to distro just before doing the copy: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/87
<pitti> mspencer: hello
<pitti> apw: right, that makes sense I guess?
<tumbleweed> didrocks: thanks
<apw> pitti, i think it does indeed
<didrocks> tumbleweed: yw
<nemo> hrm. that didn't work :-/
<dholbach> Laney, where can I file a bug on the transitions tracker?
<mspencer> Hi pitti, for LP #657275, what do you want done with bug reports if there is no Internet connection?
<ubottu> Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275
<Laney> dholbach: is it a bug in the software?
<dholbach> Laney, it's a wishlist item and https://launchpad.net/ubuntu-transition-tracker does not let me file bugs
<Laney> ubuntu-bug ben
<nemo> ah. there's a tmp dir. let's see what's in there
<Laney> yeah, that's a different version to the one we have deployed but ho hum
<xnox> dholbach: what's the bug?
<dholbach> [dholbach] file bug on transition tracker (lp:ubuntu-transition-tracker) to produce Harvest JSON output: TODO
<pitti> mspencer: I'm not keen on implementing a wholly new UI for browsing .crash files; you can just double-click on them in nautilus after all; but the [Save] button sounds fine
<mspencer> pitti: So just save them to the user's home folder and tell them to report them later?
<pitti> mspencer: but honestly it's not quite at the top of my list; there is a --save option if you really need to
<dholbach> Laney, xnox: is there another place to report the bug then?
<Laney> just report it against the ben package
<dholbach> ok
<nemo> ah. !@#$ websense
<Laney> ben (newer versions) can output yaml already though
<mspencer> pitti: I know it's not very important, it was just something I came across that I thought I could handle since I'm new.
<xnox> dholbach: well. upstream is a package in debian called ben. Currently it can produce "text" and "html" outputs.
<dholbach> ok, I had no idea
<pitti> mspencer: oh, if you want to do that, great :)
<xnox> dholbach: in ubuntu we only replaced the logo & use our own transition good/bad/affects stanzas. Nothing fancy.
<pitti> mspencer: yes, it's not hard to do, just takes some time and love
<dholbach> ok, I see
<nemo> and the place to look is apparently /var/lib/apt/lists/partial
<xnox> dholbach: it's written in OCaml , so don't expect major json developments =/
<mspencer> pitti: where should I save the reports to? Home folder or a "Bug Reports" subfolder?
<Laney> xnox: I don't see what the language has to do with that?
<xnox> Laney: doesn't like PTS query ben somehow to show which packages are in a transition?
<Laney> via the yaml file I already mentioned
<Laney> but you started talking about OCaml being a hindrance to this feature's development somehow
<pitti> mspencer: it should show a file dialog IMHO
<mspencer> pitti: Okay, that's what I'll do, thanks!
<Laney> I would say that harvest should just work with the yaml file somehow, even if it's via some tool translating it to json. But it's moot ATM until we get the new ben deployed.
<xnox> Laney: in ubuntu we don't have many people who know ocaml, that is all. Didn't mean it, to come across the way it did.
<mspencer> Hi, I'm new to developing for Ubuntu and am interested in working on the Contributor Console (https://wiki.ubuntu.com/ContributorConsole). Is this something a beginner could do? So far I've worked on bug fixes.
<ScottK> mpt: ^^^ since it's your page.  Not sure who's working on development.
<xnox> mspencer: as far as I know, there are only mockups and no coding has started yet.
<mpt> mspencer, hi, I wondered if you'd be interested ;-)
<mpt> mspencer, no-one's started it as far as I know. You're welcome to.
<mspencer> mpt: I'm not very familiar with packaging - do I need someone else to start the project and then I contribute to it or can I start it myself?
<bdrung> JFYI: I started the gnustep transition
<mspencer> mpt: Would I be responsible for all the work on it or can I just work on as much as I can?
<mpt> mspencer, you can start it yourself, and merge in branches contributed by other people. If you get bored of it later you can hand over ownership to someone else.
<mpt> mspencer, for example, you might decide you're only interested in doing the "Bugs" tab, but others might contribute parts of other tabs.
<mspencer> mpt, Okay, I'll work on it.
<mspencer> mpt: So I'll just create a new project in launchpad and use quickly to do this?
<mpt> mspencer, great! Yep, Launchpad and Quickly would be a good start.
<mspencer> mpt: Will I need to do anything to get it included in the Ubuntu?
<mpt> mspencer, yes, but you don't need to think about that until later. Others can work on the packaging, in the same way that they can work on parts of the code.
<mspencer> mpt: Great, thanks for your help!
<mpt> Thank you, mspencer
<mspencer> Here's the new project: https://launchpad.net/contributor-console
<slangasek> ogra-cb_: I didn't say plymouth would be an easy merge, I said *don't merge it from Debian*, you should pull the new upstream version first and ignore the Debian package for now :)
<slangasek> ogra-cb_: s/would/wouldn't/
<slangasek> only after we're at the same upstream version, should we look at doing the packaging merge
<ogra-cb_> oh, k
<slangasek> ogra-cb_: I see you and xnox both active on the package bug... is one of you going to take on the merge?
<slangasek> (the upstream merge)
<slangasek> or do you prefer to leave it for me to play with?
<ogra-cb_> slangasek, i can try my best after the image stuff is done
<ogra-cb_> i fear though that this will keep me busy for this week still
<xnox> slangasek: ogra-cb_: I can poke it a little =)
 * xnox really doesn't like 293kB long britney output.txt
<ogra-cb_> slangasek, also, setting console=tty0 instead of tty1 seems to help with the hard crashing
<ogra-cb_> it still doesnt get us a splash but i havent seen any reboots anymore at least
<slangasek> ah, nice
<ogra-cb_> (still it shouldnt crash this hard indeed)
<GunnarHj> slangasek: Hi Steve, wondering if you could take a look at the proposed solution to bug 952185. Saw your comment at bug 584249, but I felt that a pam config change might still be ok. And it works. :)
<ubottu> Launchpad bug 952185 in pam (Ubuntu) "~/.pam_environment not parsed when HOME is encrypted" [Undecided,In progress] https://launchpad.net/bugs/952185
<ubottu> Launchpad bug 952185 in pam (Ubuntu) "duplicate for #584249 ~/.pam_environment not parsed when HOME is encrypted" [Undecided,In progress] https://launchpad.net/bugs/952185
<sarnold> arges: btw, "Fromat" in "RSYSLOG_SyslogProtocol23Fromat" in https://bugs.launchpad.net/bugs/1059592
<ubottu> Launchpad bug 1059592 in rsyslog (Ubuntu Raring) "Message and memory corruption in rsyslog" [High,In progress]
<arges> sarnold, whoops
<arges> sarnold, fixed : )
<sarnold> arges: woo :)
<slangasek> GunnarHj: hey there - so I'm still on vacation, don't know that I'll get a chance to look at that this week :)  Off the top of my head I'm not convinced this is a completely correct solution, so I need to look at it in some detail
<GunnarHj> slangasek: Oh, sorry, saw your comment here, so I thought you were back. Let's wait then.
<slangasek> GunnarHj: yeah, "vacation" is a sliding scale ;)
<GunnarHj> :)
<mspencer> mpt: I've created the Contributor Console project in Launchpad. Should the wiki spec get updated to point to it?
<seb128> hum
<seb128> unity fails to build in raring without code change
<seb128> -- Found Gettext: /usr/bin/msgmerge (found version "0.18.1")
<seb128> CMake Error at CMakeLists.txt:106 (if):
<seb128>   if given arguments:
<seb128>     "STREQUAL" "TRUE"
<seb128>   Unknown arguments specified
<seb128>  
<seb128> is there any toolchain/gettext/cmake known issue?
<bryce> Could an SRU admin approve the jockey 0.9.7-0ubuntu7.6 upload for precise?  This includes two important fixes, one for the LTS point release backport drivers, and one for Valve experimental drivers.  It should make things display correctly in jockey, and we'd like to get people able to start testing both fixes soon.
<bryce> s/approve/approve into -proposed/
<bryce> (if it matters, I did a quick code review of the change diff.)
<mterry> Is anyone familiar with passing file descriptors over dbus?  Apparently it has support for it, but I'm not sure how it is supposed to work
<mlankhorst> tell mterry that unix fd's are probably sent as any other parameter..
<tkamppeter> Someone knows the date of the next UDS?
<bdrung> robert_ancell: do you plan to SRU evolution 3.6.2 to quantal? evolution 3.6.2 crashes several time a day and i like to check the new version.
<robert_ancell> bdrung, do you mean 3.6.0 is crashing?
<seb128> bdrung, check with cyphermox, he's maintaining evo
<bdrung> robert_ancell: yes
<robert_ancell> there's heaps of changes in 3.6.2 so I don't know about how that goes in an SRU, but yeah, cyphermox is the right guy to talk to
<bdrung> robert_ancell: opening an mail with attachment has a high chance to let it crash
<bdrung> cyphermox: ^
<cyphermox> I agree, it's crashy. Perhaps we can SRU the specific fixes though
<ScottK> mails with attachments are a security risk.  Security feature, not a bug.
<cyphermox> ScottK: +1
<ScottK> ;-)
<bdrung> ScottK: so i can tell people that i can't review their debdiff sent by mail -> less work for me :D
<bdrung> s/debdiff/debdiffs/
<ScottK> Double win.
<bdrung> cyphermox: is the wrong handling of signatures in evo 3.6 already reported?
<bdrung> evo places my signature twice
<cyphermox> bdrung: yeah, and I spent quite a few hours trying to make sense of it without luck :(
<cyphermox> bdrung: did you look at 3.6.2 and whether things were better there?
<bdrung> cyphermox: not yet. i just tried to compile it under quantal without luck: http://paste.debian.net/211376/
<bdrung> the build dependencies seems to be not strict enough
<bdrung> ScottK: can you let gnustep-base pass through new?
<ScottK> bdrung: No time to review it now, sorry.
<bdrung> ScottK: it's just binary new
<bdrung> ScottK: are binary new package reviewed the same way new packages are reviewed?
<ScottK> bdrung: The review is not identical (don't review licensing), but there are still some checks to do.
<bdrung> ScottK: can you recommend someone i can nag? i have prepared the transition and like to get it done.
<ScottK> Not really.  This is a holiday period here in the US.
<bdrung> ah, okay
<ScottK> I don't recall if it is for Canada or not, so maybe infinity would do it.
<bdrung> infinity: do you have a little spare time to review the binary new packages of gnustep-base?
<infinity> bdrung: Yeah, I'll poke it in a sec.
<bdrung> thanks
<cyphermox> bdrung: I'll package evo 3.6.2 and push it to a PPA to begin with
<cyphermox> or I guess upload to raring, instead
<bdrung> cyphermox: robert_ancell uploaded evo 3.6.2 to raring.
<cyphermox> ah
<bdrung> cyphermox: if you upload evo 3.6.2 to a quantal ppa, i will be happy to test it
<cyphermox> ok
<cyphermox> bbl
<doko> all gcc-multiarch target patches accepted upstream, doko is opening a bottle of beer
<sarnold> doko: prost!
<cjwatson> nice!  slÃ¡inte
#ubuntu-devel 2012-11-22
<wookey> doko: well done
<mspencer> Should questions related to the development of an app with a specification on wiki.ubuntu.com be asked here or on #ubuntu-app-devel?
<mspencer> The app is Contributor Console, https://wiki.ubuntu.com/ContributorConsole
<ScottK> mspencer: Not here.  Not sure if that's better or not.  Perhaps #ubuntu-desktop too.
<bdrung> infinity: may i ask you to process gnustep-gui in around one or two hours once armhf and powerpc are built?
<infinity> bdrung: I'm sure you can.  (Someone will get to it regardless)
<bdrung> infinity: hÃ¤? gnustep-gui is/will stuck in binary NEW.
<infinity> bdrung: yeah, I know.  We'll get to it.
<cjwatson> roaksoax,Daviey: Where's the upstream bzr repository for maas-enlist?  It looks like it has a separate upstream existence and the upstream part of its version is "0.4+bzr36", but there's no lp:maas-enlist
<roaksoax> cjwatson: lp:~maas-maintainers/maas/maas-enlist
<cjwatson> Thanks
<epikvision> Hello all.  I have a question. Why do some packages that exist in lp not appear in the Ubuntu Software Center?
<jcastro_> someone needs to put the stuff from lp into ubuntu
<jcastro_> it just doesn't automagically happen
<infinity> jcastro_: I'm not sure if he meant "software in random PPAs and bzr branches" or "software in the Ubuntu archive (as shown on LP) that isn't indexed in SC"
<infinity> epikvision: ^?
<jcastro_> seems like he meant lp as a whole, which includes the things you just mentioned
<epikvision> yeah, that's what I meant.
<infinity> jcastro_: Given that software-center (intentionally) only indexes things with desktop files, I suspect it builds some confusion from people who, say, search for Apache and wonder why we don't "ship" it (when we clearly do).
<jcastro_> I'm answering your question on askubuntu, which I assume you just posted because it's just similar
<epikvision> I just did; thanks.
<epikvision> jcastro_ I also included a comment to extend the question.
<epikvision> jcastro_ so I guess having a packager in the app review board makes a powerful combination!  ^^
<ScottK> It's a fundamental flaw in the system that non-developers are on the board at all.
<jcastro_> even if the ARB was full of say, full MOTUs or Core Devs, they would still be doomed
<ScottK> Well sure.
<ajmitch> ScottK: there aren't any non-developers on the board, nor will there be going forward
<ScottK> OK.  Good to hear.
<ScottK> I guess I got confused by the new review policy.
<achiang> for a UDD package, where a bzr checkout only gets the debian/ directory (network-manager-gnome in this case), how do i build a test package for upload? with a normal package, i'd do debuild -S -sa -I -i
<infinity> achiang: Unpack the orig, export the debian directory into it, then debuild -S
<cyphermox> achiang: bzr bd should do it
<cyphermox> (or bzr bd -S)
<cyphermox> backtracking though, what branch did you use?
<achiang> infinity: what does "export" mean in this context? i was thinking: find .orig.tar.gz, .dsc, and .diff.gz files, dpkg-source -x, then rm -rf the debian directory, then cp -a the bzr branch's debian directory into it... i'm sure you're suggesting a less clunky method. :)
<achiang> cyphermox: bzr+ssh://bazaar.launchpad.net/~network-manager/network-manager-applet/ubuntu.precise/
<cyphermox> achiang: rock on :)
<cyphermox> yeah, bzr bd is what you're looking for, and if you want to make things easy you'll want to download the orig tarball from launchpad
<achiang> man... that is clunky
<cyphermox> I admit it needs a bit of new love :)
<RAOF> Full source branches work better, but suffer from slow branching.
<ScottK> FSVO better.
<ScottK> But then I use diff and patch to move stuff between what I plan to upload and bzr.
<cyphermox> RAOF: really I should just do away with that old concept of get-orig-source in that package, which I inherited from when I started maintaining the package and was the way it was due to daily builds
<cyphermox> and I already have a branch that fixes all this, I just had more important things to do than merging it :/
<bkerensa> is someone doing phantom patch pilot? :) I just got a few MP's that got merged with no review
<bkerensa> heh
<pitti> Good morning
<ScottK> bkerensa: patch pilot is a time for Canonical employees that's set aside for them to do sponsoring work.  Other people do it too.
<pitti> apw, infinity: argh, I suck; can you please change "Restictions: needs-build" to "Restrictions: build-needed"? *brown paperbag*
<pitti> I'll send a patch for binutils today
<scientes> what non-free software makes the ubuntu-nexus7-installer claim "non-commercial" use?
<scientes> cause the installer itsself is GPL 3
<pitti> scientes: I suppose it's related to the bits of non-free drivers that it ships, such as the Tegra one
<scientes> does it ship flash?
<scientes> cause i know flash for arm GNU/Linux (glibc/x11) is non-commercial
<scientes> if i install ubuntu will i still have android?
<scientes> can i dual boot?
<pitti> not with that image
<scientes> "
<scientes> There are currently no plans to support dual booting Ubuntu and Android."
<pitti> but you can download and restore the original android image
<infinity> pitti: Grr.
<infinity> pitti: I even read the spec, but didn't notice that you'd given me the wrong syntax.
<infinity> pitti: I won't fix it right away, but it'll make its way into the next glibc upload.
<infinity> scientes: We don't wipe out the partition layout, so if you backup with something like nandroid, you can restore.
<infinity> scientes: As for the non-commercial bits, pitti's right, it's drivers.  Though, the most restrictive one is some broadcom blob, not the nvidia one.
<infinity> scientes: Not that I think it matters, other than covering our butts a bit, since it's clearly a tech preview sort of toy, not something you're going to put on 1000 tablets and deploy in the enterprise. :P
<bkerensa> infinity: surely the drivers do not require Canonical/Ubuntu to demand no-commercial use?
<bkerensa> these drivers are already used commercially on the Nexus 7 when running Android?
<infinity> bkerensa: http://paste.ubuntu.com/1376568/
<pitti> infinity: it's not urgent, next upload is fine; thanks!
<infinity> bkerensa: That's the only license we have.  Clearly non-commercial, and only gives us the right to extend a non-commercial use grant to our users.
<infinity> bkerensa: I would assume that Google has a different license.  Not all licenses are created equal. :P
<bkerensa> infinity: huh
<infinity> bkerensa: If you, of course, have obtained the same binaries under a different license, you can do whatever you're allowed to do, but that's the license we have, so.  *shrug*
<infinity> (Well, the license is longer, obviously, but that was the relevant bit)
<bkerensa> infinity: I wonder how that works for Canonical employees who are trying to improve the core of Ubuntu on the N7 since their use would be commercial in nature?
<infinity> How is it commercial?
<bkerensa> well if they are paid by a company to improve Ubuntu Core on the N7 device using those drivers the nature of their use is not personal
<infinity> bkerensa: It's possible for commercial organisations to engage in non-commercial activities.
<infinity> bkerensa: We're not selling (or monetizing in any way) Ubuntu on the N7, and certainly not that firmware.
<bkerensa> infinity: The platform is monetized technically since the shopping lens ships with the image :)
<bkerensa> although I double Canonical will see any revenue on the N7
<bkerensa> ;p
<bkerensa> I can barely access the dash at this point
<infinity> Seems a great argument to file a bug to remove that lens in the N7 image. :P
<bkerensa> infinity: not worth my time ;p
<infinity> Nor mine.
<dholbach> good morning
<pitti> hey dholbach
<pitti> infinity, doko: I attached a binutils debdiff to bug 1081500; let me know if you want me to upload this; note that this is appropriate for Debian as well
<ubottu> Launchpad bug 1081500 in binutils (Ubuntu) "Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc-dev, gcc, and binutils" [Low,In progress] https://launchpad.net/bugs/1081500
<jamespage> is there any nice way to stop a prerm thats doing something wrong on package upgrade?  I need a way of preserving some data generated by a package but the prerm script in the version in the archive currently removes it
<tkamppeter_> Anyone knows the date of UDS-S?
<xnox> tkamppeter: tentative schedule here https://wiki.ubuntu.com/SReleaseSchedule the week that has may the 16th
<xnox> jamespage: i think "old" prerm is the first one that runs =( http://wiki.debian.org/MaintainerScripts
<jamespage> xnox, yeah - thats what I'm trying to avoid
<xnox> jamespage: well, if you have a dependency, you can make that dependency preinst script rescue your data.
<jamespage> xnox, ? not sure I understand
<xnox> e.g. if packageA eats data on prerm and depends on packageB, I think packageB preinst can rescue your data, but I have not tested this.
<xnox> since packageB new preinst will be run before packageA prerm, you might possibly need pre-depends.
<xnox> cjwatson: what's the best way to work around a broken prerm for a package already in the archive? (currently prerm is causing data loss on upgrade)
<jamespage> xnox, right - I see
 * jamespage looks at the Depends
<jamespage> hmm
<xnox> jamespage: if that is not possible, you might want to introduce a new pre-depends package called "packageA-rescue-data", but that is very extreme.
<xnox> jamespage: what's the package in question?
<xnox> jamespage: and the upgrade path? dist-upgrade or -security/-updates?
<cjwatson> jamespage,xnox: Old prerms that don't fail but that do something undesirable are tough to work around.  The only method I can think of is a preinst of something you Pre-Depend on, as xnox suggests.
<xnox> cjwatson: ack, thanks.
<cjwatson> (Well, actually, the postinst would do.)
<jamespage> cjwatson, yeah - its working OK using that approach - thanks for the feedback
<seb128> doko, https://launchpadlibrarian.net/123630730/buildlog_ubuntu-raring-amd64.unity_6.12.0-0ubuntu2_FAILEDTOBUILD.txt.gz
<seb128> "-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1")
<seb128> CMake Error at CMakeLists.txt:106 (if):
<seb128>   if given arguments:
<seb128>     "STREQUAL" "TRUE"
<seb128>   Unknown arguments specified"
<seb128>  
<seb128> doko, do you know if something changed in the toolchain around yesterday? the issue started recently in raring
<seb128> that's a no change rebuild (well a control recommends added) compared to the previous version which was building
<xnox> seb128: well cmake had a new upstream release uploaded on 2012-11-15
<seb128> xnox, the issue started around yesterday
<xnox> seb128: ack.
<seb128> we have daily builds in a ppa, they didn't break around the 15 but more recently
<xnox> i see.
<xnox> seb128: can I have a link to the build record to grab the source package?
<seb128> xnox, apt-get source unity in raring
<xnox> ok.
<seb128> https://launchpad.net/ubuntu/+source/unity/6.12.0-0ubuntu2
<seb128> xnox, or in fact it could be cmake... let me try to downgrade it
<didrocks> yeah, let's try that first
<xnox> seb128: for some reason the GETTEXT_FOUND is not set.
<xnox> seb128: yet the above find_package (Gettext REQUIRED) should have done so.
<xnox> unless it's now ${Gettext_FOUND} which is very not CMake like capitalization.
<seb128> yeah
<seb128> downgrading cmake fixes it
<xnox> seb128: so a change in FindGettext.
<seb128> Riddell, ^
<seb128> Riddell, you did the cmake update
<didrocks> that's a weird variable
<seb128> http://launchpadlibrarian.net/123100540/cmake_2.8.9-1ubuntu1_2.8.10.1-0ubuntu1.diff.gz
<seb128> is the diff
<didrocks> Gettext_FOUND as xnox said, is really not cmake-like
<seb128> there is a diff in FindGettext
<seb128> +set(GETTEXT_FOUND ${Gettext_FOUND})
<seb128> indeed, weird
<xnox> seb128: didrocks: file a bug against cmake package & (you or somebody else) should forward this upstream.
<xnox> currently it looks insane.
<xnox> in cmake.
<infinity> set(GETTEXT_FOUND ${Gettext_FOUND}) should be setting the old variable.
<infinity> But it could well just be failing to find it correctly.
<xnox> but I don't see them setting Gettext_FOUND either.
<infinity> Looks like a complete rewrite of the module.  :/
<didrocks> xnox: they don't apparentlyâ¦
<didrocks> not sure if the dep thing is magic in some wayâ¦
<seb128> http://www.cmake.org/Bug/bug_relationship_graph.php?bug_id=13691&graph=relation
<seb128> didrocks, ^
<didrocks> with the added target
<didrocks> PARENT_SCOPE
<didrocks> this is even more black magic :)
<seb128> we should maybe revert the FindGettext.cmake diff to 2.8.9
<seb128> until that's properly fixed upstream
<seb128> ?
<xnox> seb128: I agree.
<xnox> cjwatson: was there a magic wiki page for reverts?
<cjwatson> xnox: https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog
<seb128> xnox, revert the whole cmake?
<xnox> seb128: also we need autopkgtest in cmake for a sample FindGettext ;-)
<didrocks> +1 on revert
<seb128> or just FindGettext.cmake?
<cjwatson> Is the FindGettext change fairly isolated from everything else?
<xnox> seb128: I am hoping that reverting FindGettext should be sufficient.
<cjwatson> If so, probably simpler to just revert it alone
<infinity> Nothing else references that module.
<infinity> So, reverting it alone should be fine, assuming the old version works with the new CMake.
<didrocks> yeah, it seems standalone
<infinity> (Which is really should)
 * xnox is doing the revert, and will document it.
<pitti> OOI, didn't we use to have three powerpc builders?
<xnox> pitti: didn't like I see discussion somewhere of one ppc box disappearing?!
<pitti> thanks xnox, so it's known
<cjwatson> pitti: It failed to come back from reboot on upgrade - there's a high-priority RT about it
<xnox> seb128: didrocks: does this work? https://bazaar.launchpad.net/~pimvullers/maya/fix-1080713/revision/380
<didrocks> xnox: with the current cmake, you mean?
<xnox> didrocks: yes.
<seb128> xnox, it seems to work yes
<seb128> well applied to unity
<xnox> see related issue: https://bugs.launchpad.net/maya/+bug/1080713
<ubottu> Launchpad bug 1080713 in Maya "CMakeFile.txt: Unknown arguments specified: "STREQUAL" "TRUE"" [High,Fix committed]
<xnox> seb128: didrocks: does the "new" style also work with older CMakes?
<didrocks> seb128: want me to test or do you have a pbuilder handy?
<seb128> didrocks, xnox: I didn't test a full build but "cmake .." works fine with that change to CMakeLists.txt, using both old and new cmake
<seb128> where it was breaking with the new cmake before
<xnox> awesome.
<seb128> so it seems to be fine for both
<didrocks> seb128: ok, I'll try a full build and ensure we have translations
<seb128> didrocks, I've started one on my raring machine with the new cmake
<didrocks> seb128: do you test on quantal as well?
<seb128> didrocks, I can pbuild on quantal yes
<didrocks> seb128: ok, I'll let you handle this then :)
<xnox> cjwatson: no reverts after all =)
<didrocks> I think it broke quite some packages though
<didrocks> when I added the initial support, I looked at the doc
<didrocks> and that was what was published IIRC
<infinity> if(FOO_FOUND) is the more common usage, by far.
<infinity> Though maybe not for Gettext specifically, if some doc was suggesting the STREQUAL. :/
<infinity> rgrep through a lintian lab anyone?
<Laney> http://codesearch.debian.net/search?q=STREQUAL+%5C%22TRUE%5C%22
<infinity> Laney: Those aren't all necessarily wrong, if they're actually comparing strings, as I understand it.
<Laney> Quite. I'm not suggesting they are, but I couldn't think of a better string in ten seconds. There's not so many results there to look at anyway.
<infinity> I don't see a single GETTEXT in there, though.
<Laney> Depends if it's something unique to GETTEXT_FOUND
<Laney> But yeah, it's possible other PS packages have used the same idiom.
<infinity> I suspect the new and bizarre voodoo in play to make GETTEXT_FOUND get set... however it gets set... also swapped it from being a string to a bool or something.
<infinity> *hand wavy*
<seb128> xnox, Laney, infinity, xnox: I would still go with the "revert the cmake gettext change" until somebody who knows about gettext figure out why it broke and what should be done
<seb128> we don't even know how many builds in the archive that breaks
<didrocks> just unity in the PS stack
 * didrocks grepped
<seb128> ups, the second xnox was meant to be didrocks
<infinity> seb128: It breaks zero things in Debian, apparently.
<xnox> infinity: Debian does not have that version yet?
 * xnox goes to check
<infinity> seb128: And outside of Debian-derived packages, the PS stuff may well be the only cmake-using things we care about. :P
<infinity> xnox: No, we just grepped the archive.
<xnox> It did break Maya on gentoo =)
<Laney> I'd keep it. We'll find out if stuff breaks, and if it does then we know where the problem comes from and how to fix it.
<seb128> xnox, debian doesn't have that version no
<xnox> For future reference this is bug 1080713
<ubottu> Launchpad bug 1080713 in Maya "CMakeFile.txt: Unknown arguments specified: "STREQUAL" "TRUE"" [High,Fix committed] https://launchpad.net/bugs/1080713
<xnox> with a bug link to cmake bug tracker.
<didrocks> (I didn't grep through webapps, but if I see it failing, I'll fix it)
<xnox> And I commented in cmake's bug tracker that this change breaks previously working CMakeLists.
<seb128> it still seems an incompatible change
<seb128> is that wanted?
<xnox> seb128: which may or may not be appropriate for a new upstream cmake release.
<xnox> seb128: i'd like to wait on a response from cmake developers on this.
<infinity> It's a correct change.  That *should* be a boolean.
<Laney> Things doing wrong things and getting burned isn't something to get too upset about if almost nothing is affected, IMO.
<infinity> Reverting won't buy us anything here, if the impact is minimal.
<Laney> I codesearched for GETTEXT_FOUND and didn't see anything.
<xnox> seb128: until then, I'd like to keep ubuntu cmake package task as won't fix, as there is a way to work around in a sane backwards compatible way.
<infinity> (I've certainly broken more packages with glibc 2.16 than this will break)
<xnox> =))))))
<infinity> And, as stated, this affects zero source packages in Debian.
<infinity> So, if it affects us in any meaningful way, we're pretty special.
<infinity> It may well just be unity.
<xnox> infinity: and maya software see the bug report.
<xnox> infinity: which came up with the fix in the first place ;-)
<infinity> xnox: We don't ship maya.
<Laney> Not in archive â doesn't exist.
<Laney> :P
<infinity> xnox: But if upstream fixed their build system, go them.
<xnox> Laney: infinity: /me clearly confused maya with mayavi2 sorry
<Laney> Some software sets GETTEXT_FOUND to TRUE/FALSE and some 1/0. Don't know if that will be affected.
<cjwatson> xnox: Do please document that we had a discussion anyway; one of the things we wanted to know was how often we decided against reverting
<xnox> cjwatson: ack.
<infinity> Laney: No, no.  Those are packages shipping their own FindGettext module.
<infinity> Laney: Anything SETTING it can be safely ignored, you just want to find things testing it.
<infinity> Laney: And where they're a pair in the same source package, obviously it's using its private copy, so again, a red herring.
<infinity> I can't quite sort out why, every time I poke at cmake, it feels both elegant and awful at the same time.
<Laney> How does autotools feel?
<infinity> Sort of exactly the opposite.
<brendand> is there something special about variables starting with double underscore in python?
<infinity> CMake feels pretty and clean and such, but I end up banging my head repeatedly on flat surfaces when I can't sort out the crazy abstracted way to do X, Y, or Z.
<infinity> autotools, for all its ugly, is easy to just hack a quick DWIM test.
<brendand> something strange happening in pdb, where instance variables named like that are perfectly accesible by the running code, but pdb somehow sees them differently
<infinity> "Private name mangling: When an identifier that textually occurs in a class definition begins with two or more underscore characters and does not end in two or more underscores, it is considered a private name of that class."
<infinity> brendand: http://docs.python.org/2/reference/expressions.html#atom-identifiers
<xnox> seb128: didrocks: cjwatson: documented https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog
<didrocks> thanks xnox, looks good :)
<xnox> cjwatson: also made the outcome of the previous instance more clear, as a patch revert did happen in libgcrypt11, but not in cmake's case.
<seb128> xnox, thanks
<xnox> fixed grammar now as well =)
<brendand> infinity, that makes sense, but when pdb is inside a method shouldn't it be running 'inside' that instance? i'm going to guess that that isn't how pdb works
<cjwatson> My suggestion would be to avoid __var like the plague ...
<bdrung> dholbach: what kind of hardware do it need for hangouts?
<brendand> cjwatson, i will now
<dholbach> bdrung, a webcam helps - if you want to try it out, we could have a test hangout
<xnox> bdrung: i386 or amd64. The easiest with google chrome browser.
<infinity> xnox: Works just as well in firefox.
<dholbach> bdrung, https://tools.google.com/dlpage/hangoutplugin
<xnox> infinity: hmm... for me cpu blowsup under firefox... but maybe it's just me.
<infinity> xnox: I found it about equally crap in both the last time I cared to compare.
<xnox> noted.
<infinity> xnox: And discovered that an Atom N450 wasn't good enough. :P
<infinity> (This may have improved since... Man, I hope it has)
<infinity> When the first step to video chat/conference is "find the most powerful computer in your house and kidnap it for use as a very expensive microphone stand", something's wrong.
<dholbach> infinity, a tiny little bit maybe, but it's still taxing
<xnox> well. I have tried it on an arm netbook and google kept on pretending I am running 32bit x86 compatible processor.
<infinity> dholbach: Methinks the people who do their Android hangout client need to go smack the people who do the x86 browser plugin.
<infinity> dholbach: Given that it runs better on my phone than my laptop sometimes. :P
<bdrung> dholbach: then i need a webcam
<bdrung> xnox: chrome or is chromium enough?
<xnox> bdrung: chrome seemed to have everything built in. chromium needs a plugin just like firefox does.
<xnox> bdrung: webcam is needed if you want to broadcast your face =) just a mic works and then you will be broadcasting a static picture/avatar.
<bdrung> okay, then i have to test if my headset still works
<bdrung> last time, i tried, i had problems with recording. now i have a different sound card. so this problem may have solved itself.
<infinity> Alright, on a scale of 1 to nap, I think I'm going to go 13.
<bdrung> which value has nap? infinity?
<bdrung> ;)
<brendand> what's the most straightforward way to find the maximum resolution of a particular display (say VGA-0)?
<bdrung> brendand: maybe parsing the output of xrandr
<brendand> bdrung, that's what i was afraid of - it's a bit ugly
<bdrung> then i can't help you
<brendand> cat'ing in /sys/class/drm/card0* *would* be cleaner if it wasn't for proprietary drivers
<ion> slangasek: skype and skype-bin:i386 from the partner repo seem not to be installable at the same time.
<bizhanMona> HI does ubuntu 12.10 supports EFISTUB bootloader?thx
<mlankhorst> how do I request a package to be removed from universe? xserver-xorg-input-penmount has been broken in quantal and precise, and nobody noticed
<cjwatson> file a bug and subscribe ubuntu-archive; but it can't be removed from stable releases
<mlankhorst> ok
<alkisg> bdrung: hi, sorry for the ping, should we wait for an updated adblock-plus package from lp:mozillateam? The current version conflicts with thunderbird 17...
<alkisg> (unrelated) btw, upgrading skype on precise is broken, the new "skype-bin" wants to uninstall the old "skype" package, not upgrade it...
<xnox> alkisg: was the previous skype installed from skype.com or from the archive?
<alkisg> xnox: from the archive (using software center)
<alkisg> skype and skype-bin, versions: 4.0.0.8-0oneiric1
<alkisg> (oneiric even though I'm using precise)
<xnox> alkisg: is adblock-plus simply disabled in thunderbird, or it is preventing to upgrade to thunderbird?
<alkisg> xnox: upgrading thunderbird prompts for removing the adblock package
<alkisg> So update-manager says a "partial update is available"
<xnox> *sigh*
<alkisg> I purged skype and skype-bin. I tried installing skype, it says that it depends on skype-bin but that won't be installed
<alkisg> I installed skype-bin only, seems to work...
<xnox> alkisg: are you on amd64 or i386 architecture?
<alkisg> i386
<xnox> alkisg: thank you.
<alkisg> Thank you too
<xnox> alkisg: I will check & try to confirm both issues. Have you filed any bugs yet by any chance?
<alkisg> xnox: no, for neither
<xnox> alkisg: that's ok.
<alkisg> Thanks a lot, tell me if I should file a bug
<xnox> cjwatson: should we be running britney for security and updates pockets? ^^^^^
<cjwatson> Arguably but not planning on setting it up any time soon
<cjwatson> What's that got to do with it though?  skype's in partner, not security/updates
<cjwatson> In any case, this change appears at least somewhat deliberate - looks like it's switched to a multiarch scheme?
<xnox> cjwatson: ack. Let me correct myself: stuff that lands in a stable release post-release via reasonable & supported paths.
<cjwatson> bug 1081860 FWIW
<ubottu> Launchpad bug 1081860 in ubuntu-archive-tools "uploads to oneiric/partner are redirected to oneiric-proposed/partner" [Medium,Triaged] https://launchpad.net/bugs/1081860
<cjwatson> (probably wrong title now)
 * cjwatson fixes
<xnox> cjwatson: but switching to a multiarch scheme should not break upgrade on a i386 (non-multiarch) install.
<cjwatson> no, that's true
<geser> xnox: see bug #1082030 for the skype issue
<ubottu> Launchpad bug 1082030 in skype (Ubuntu) "skype-bin seem to have strange dependency" [Undecided,New] https://launchpad.net/bugs/1082030
<cjwatson> Yeah, looks like a busted Breaks
<cjwatson> xnox: I can go ahead and fix this if you like
<cjwatson> since Steve is probably gorging on turkey or will be soon
<cjwatson> And I think I remember how to upload to partner :)
<xnox> cjwatson: yes please. as it's a r_egression in a stable releases.
 * xnox was not punished with such privilege yet
<cjwatson> Hmm, that's a point, I don't think I actually have upload access to partner
<cjwatson> Unfamiliar feeling
<xnox> well stgraber & mvo can.
<stgraber> yeah, I "think" I'm in the magic team that has upload access to partner, never tried it though :)
<cjwatson> You are.  It should just be an ordinary upload with Component: partner
<seb128> xnox, the cmake fix from this morning didn't work
<seb128> if (GETTEXT_FOUND) works with with 2.8.9 but not 2.8.10
<seb128> xnox, just for info
<xnox> seb128: buildlog?
<seb128> xnox, https://launchpadlibrarian.net/123700184/buildlog_ubuntu-raring-i386.unity_6.12.0-0ubuntu4_FAILEDTOBUILD.txt.gz
<stgraber> cjwatson: ok, want me to take care of this then?
<seb128> xnox, but doing cmake .. the GETTEXT_FOUND line is not printed
<seb128> xnox, it is when using 2.8.9
<didrocks> xnox: yeah, it's printed
<didrocks> not*
<xnox> seb128: didrocks: I've asked you "does this work on both?" you say yes. Even to the fact of building it in quantal & raring. Now two uploads were done that FTBFS.
<xnox> didrocks: do you not do a clean build in pbuilder/sbuild before uploading?
<xnox> (with raring-proposed enabled)
<seb128> xnox, I did pbuilder on quantal, my raring build failed on a gcc/include issue
<cjwatson> stgraber: I've attached a patch to the bug, if you'd care to sponsor it?
<didrocks> xnox: I trusted seb128 when he told me he built it ;)
<seb128> xnox, so yeah, unfortunate chain of events
<stgraber> cjwatson: sure
<didrocks> yep, because of the other failure
<xnox> now, we see what happened here, LOL =))))))
<didrocks> let's try to fix it first
<didrocks> xnox: well, not the end of the world, fixing it is more important
<xnox> anyway. Yeah, I still was not convinced that even Gettext_FOUND was set or not.
 * xnox goes to play with cmake quickly.
 * xnox has reverted cmake to upload ready here, just in case.
<seb128> xnox, seems it's not
<seb128> if (Gettext_FOUND)
<seb128>         message(STATUS GETTEXT_FOUND = ${GETTEXT_FOUND})
<seb128> -> no message printed
<_val_> Hi there. Is anyone working on vdsm for ubuntu? Just out of curiousity.
<didrocks> ok, opensuse has a patch
<slangasek> cjwatson: so what's the fix you're applying to skype?  I'm thinking we should just use ${binary:Version} going forward
<didrocks> and it works
<didrocks> but full of black magic
<xnox> didrocks: link?
<didrocks> http://www.mail-archive.com/opensuse-commit@opensuse.org/msg28785.html
<didrocks> they remove the additional set
<didrocks> something else already set it right it seems
<didrocks> in cmake
<xnox> 8-/
<xnox> didrocks: that works.
<didrocks> xnox: grepping in the cmake module dir only show that one
<didrocks> yeah, I confirm
<didrocks> even if we don't really know what set it
<didrocks> I wouls propose uploading cmake with that patch
<didrocks> and give back the unity build
<xnox> ack.
<xnox> autopkgtest for GETTEXT_FOUND?
 * xnox so does not want to see this happening again, when cmake is fixed.
<xnox> or "not fixed upstream, yet again"
<didrocks> xnox: I'm adding that to my Friday TODO, would be a nice little hack on Friday afternoon :)
<didrocks> works for you?
<xnox> didrocks: sure. Well I remember people talking about a unity "needs-build" autopkgtest.
<xnox> that way if _any_ of unity's reverse build-deps change we will notice the failure.
<didrocks> xnox: hum? we won't have autopkgtest in unity
<cjwatson> slangasek: patch in bug 1082030 - I felt that since it was broken I should just apply the minimally correct fix
<ubottu> Launchpad bug 1082030 in skype (Ubuntu) "skype-bin seem to have strange dependency" [Undecided,Confirmed] https://launchpad.net/bugs/1082030
<slangasek> cjwatson: ok
<didrocks> xnox: we have an "autopilot" step in the ppa before copying to distro
<didrocks> xnox: but the unity integration tests need bare metal, which doesn't work with the current autopkgtest infra
<xnox> didrocks: i know. It's not a full/real smoke tests, just an in-archive single test.
<cjwatson> slangasek: if you fancy reviewing it in the queue, I'll copy it everywhere relevant once I can
<didrocks> xnox: if you have doc on that, I'm interested ;)
<cjwatson> didrocks: It'd still be enough to catch the bug and prevent it migrating from -proposed (once we finish that)
<didrocks> not really up to date with that infra and the reverse-dep building, just hear about the theory
<_val_> Hi there again.
<xnox> didrocks: which simply does a test build. Such that when gcc/boost/cmake/etc change, it is noticed =)
<didrocks> cjwatson: it's what jibel is currently (I mean, *today*) finishing right?
<cjwatson> didrocks: well, it needs work on my side too
<_val_> Hi there. Is anyone working on vdsm for ubuntu? Just out of curiousity.
<didrocks> cjwatson: how does it work? the package just need one autopkgtest?
<slangasek> cjwatson: trying, but seeming to have network issues getting to the queue
<cjwatson> didrocks: basically: it's in your interest to provide autopkgtest metadata even if it's incomplete, because it allows you to enforce constraints on your dependencies
<xnox> didrocks: yeah, in unity. that does nothing, but has "needs-build" requirement ;-)
<cjwatson> it could do something if you had some subset of tests that were worth running
<didrocks> wiki page would be appreciated :)
<cjwatson> I realise you can't run them al
<cjwatson> l
<didrocks> cjwatson: all is autopilot, the rest is run during build :/
<xnox> didrocks: that way, we would have noticed this breakage at the time cmake was uploaded.
<cjwatson> didrocks: we haven't implemented it yet, so it's a little unreasonable to want user documentation :P
<didrocks> but I can just ship a dummy test to trigger that
<didrocks> cjwatson: heh, ok, so once here, I'll do it :)
 * xnox will do merge proposal with that test against unity, but first let me upload this cmake thing.
<didrocks> xnox: ah, you are doing it? so you win the autopkgtest I guess :p
<xnox> didrocks: yes, yes.
<AbsintheSyringe> when will kernel 3.6 get into quantal?
<xnox> AbsintheSyringe: maybe ask in #ubuntu-kernel
<AbsintheSyringe> xnox, will do, tnx
<cjwatson> right, the busted skype dependencies are all fixed now
<xnox> seb128: didrocks: fixed cmake is uploaded & unity builds retried (2 succeeded, 2 building). I am EOD.
<seb128> xnox, thanks
<bitshuffler> Good evening. Question regarding debian packaging: Is the package name & its version somehow available in a post install script? (reasoning is I would like to have a post install script I don't have to touch when e.g. the version increases which is required somewhere in the script) With .rpm it is easily available within the .spec but I'm kinda lost how that is done with .debs.
<infinity> bitshuffler: The postinst isn't called with the current version as an argument, but since your source package knows its version, it's trivial to substitute it into your postinst at build time.
<bitshuffler> infinity: are there some helpers for substitution or do I have to use e.g. sed?
<infinity> bitshuffler: sed seems to be the most common go-to for this sort of thing.
<infinity> bitshuffler: Though, I will say that most of the times I think I might need to know my version in a maintainer script, I think about it and realise I'm wrong.
<infinity> bitshuffler: What's the actual problem and intended solution here?
<bitshuffler> infinity: thanks for the pointer :) Coming from rpm packaging I sometimes wonder why .deb packaging is that uncomfy â¦ ;D
<bitshuffler> infinity: in that case I need multiple sun jdk versions installable in parallel (managed via update alternatives) so one can install a specific version or multiple (in case of jenkins)
<bitshuffler> so I need the version to get the update-alternatives in post install working
<infinity> But surely, that's not the package version, just the upstream version?
<bitshuffler> best guess is some bash scripting by getting the version via ls
<tumbleweed> and if they're co-installable, it's in the packgae name somewhere
<bitshuffler> infinity: package names would differ for versions and all provide a common $jdk
<bitshuffler> and is the package name somehow available in a post install script?
<infinity> Yeah, it is.
<bitshuffler> awesome, how?
<tumbleweed> $0?
<bitshuffler> heh, really?
<bitshuffler> are there more arguments available or is there some doc on that somewhere?
<infinity> $0 isn't actually the package name, to be fair. :P
<bitshuffler> well what is it then?
<infinity> $DPKG_MAINTSCRIPT_PACKAGE is, however.
 * tumbleweed didn't know that
<infinity> $0 is the name of the postinst script, which would be $package.postinst, but isn't guaranteed to be, as that's a dpkg-internal thing.
<infinity> So, don't do that. :P
<bitshuffler> infinity: do you have some link to docs re what variables are available and what their meaning is? I'm unable to find any info on that.
<tumbleweed> bitshuffler: dpkg manpage
<bitshuffler> tumbleweed: thanks :)
 * bitshuffler goes and boots some .deb vm
<tumbleweed> I see non-zero packages on my system using $0 to find the pcakage name, but fortunately most of them are only using it to display helpful error messages
<infinity> tumbleweed: gcc is a classic offender here.  I should probably give a patch to doko.
<infinity> tumbleweed: Most cases of $0 in maintainer scripts are false positives, as it's actually being used to reference the maintainer script, not the package.
<tumbleweed> or it an awk's $0 or something
<infinity> (ie: echo "$0: called with unknown arguments")
<tumbleweed> yeah
<infinity> DPKG_MAINTSCRIPT_PACKAGE was a reasonably recent addition, to be fair, but even before that, the only sane way to know a package name in a script was to subst it in during the build.
<infinity> So, the cleverness I see in gcc and checkbox maintainer scripts should likely die. :P
<bitshuffler> hm, didn't find anything how dbpkg would be helpful in my case. So the most 'sane' way would be to get $package_name & $version from control file during packaging and generate post install files from there, correct?
<tumbleweed> you don't need the version, do you?
<bitshuffler> I do. How would I otherwise specify the correct version/priority for update-alternatives in my post install script?
<bitshuffler> what I want to achieve is to have one place I maintain that version and the rest gets it automagically somehow if needed
<tumbleweed> only one version of a package can be installed at a time, so you need the version to be in the packgae name
<bitshuffler> otherwise I'll just forget it somewhere sometimes and have a mess ...
<tumbleweed> (the upstream version, that is, you certainly don't need the package version for an alternatives priority)
<bitshuffler> tumbleweed: the package name differs as well. But all those provide a virtual package - e.g. 'jdk7' so I can easily the newest and get updates if I don't care about a specific one
<bitshuffler> so I have like sun-jdk-1702-1.7.02 and sun-jdk-1703-1.7.03 and so on
<bitshuffler> sounds kinda insane but the only viable solution I found yet ;D
<tumbleweed> right, so just extract the upstream version from that
<bitshuffler> that is the control file like suggested above or how do I get the package name during post install if I shouldn't rely on $0?
<tumbleweed> as infinity said, $DPKG_MAINTSCRIPT_PACKAGE
<infinity> DPKG_MAINTSCRIPT_PACKAGE
<infinity> But there's nothing wrong with substing values in at build time either.
<infinity> I have to say that, since I maintain a package that does that several hundred times per build. :P
<bitshuffler> heh, I guess I was dense regarding $DBPKG_â¦, googled for it and read the scripts docs :D
<bitshuffler> Thanks a lot for your help. Am happy to do as suggested just had hoped there would be a better way (like e.g. that script getting called with arguments or â¦)
<infinity> bitshuffler: DPKG, not DBPKG
<bitshuffler> infinity: yes, mistyped but read the right one
<cjwatson> bitshuffler: environment variables are better for this anyway - they're named rather than positional, which is generally more conveniently extensible
<bitshuffler> cjwatson: well, agreed, problem just is from where to get that env variable?
<cjwatson> bitshuffler: um
<cjwatson> bitshuffler: it's right there in your environment when the postinst is called
<bitshuffler> cjwatson: awesome, what's the variables name and from where does it get set?
<cjwatson> bitshuffler: the variable's name is DPKG_MAINTSCRIPT_PACKAGE, as per the above conversation.
<cjwatson> bitshuffler: It's set by dpkg, the package manager.
<bitshuffler> oh dear :D Sorry, I didn't try it yet, thought it contains just the package name
<cjwatson> It does
<bitshuffler> well, but I guess now the version as well ;D
<cjwatson> No, you don't
<cjwatson> You need the upstream version which you have embedded in the package name, ib the scheme you described
<cjwatson> You do not need the package version
<cjwatson> *in
<bitshuffler> ah, now, yes, that is how I now planned to do it. Thanks again :)
<infinity> bitshuffler: The only caveat in parsing DPKG_MAINTSCRIPT_PACKAGE is that, if your package is in any way multi-arched, under certain circumsances, DPKG_MAINTSCRIPT_PACKAGE might contain "package:arch", so you'll need to strip off ":.*" from the end of the string before playing with it.
<bitshuffler> infinity: thanks :)
<infinity> Something like "package=${DPKG_MAINTSCRIPT_PACKAGE%:*}" should do nicely.
<doko> infinity, ?
<doko> where is $0 used?
<infinity> doko: gcc-defaults.
<infinity> doko: pkg=`basename $0 .postinst`
<infinity> doko: From gcc.postinst
<infinity> doko: And g++
<doko> $ svn log debian/gcc.postinst.in
<doko> ------------------------------------------------------------------------
<doko> r1591 | doko | 2006-10-07 15:17:50 +0200 (Sa, 07. Okt 2006) | 2 Zeilen
<doko> - catchup commit 1.42 - 1.46
<doko> ------------------------------------------------------------------------
<doko> you didn't notice for at least six years ...
<infinity> doko: Nope, I didn't grep until just now during this discussion. :)
<infinity> doko: If that code is six years old, probably better to just remove it than fix it.  I'd assume the transition it's fixing is long over in oldstable.
<doko> yes, can do this
<doko> jdstrand, ping
<doko> jdstrand, unping
<bawf> I'm having trouble building gnome-system-monitor
#ubuntu-devel 2012-11-23
<scientes> how can i install ubuntu side-by-side android on the nexus 7?
<scientes> it seems like that would be nice
<xnox> scientes: see upvoted answer on http://askubuntu.com/questions/210870/nexus-7-dual-boot-with-android
<scientes> if i figured it out would my work be appreciated?
<scientes> using something like clockworkmod
<ScottK> Any suggestions what to do about http://paste.ubuntu.com/1378553/ ? It gets past this point on a buildd, it's just a local failure, but it's repeatable.
<ScottK> Makes it tough to get to the actual build failure.
<ScottK> It's armhf if it matters.
<pitti> Good morning
<pitti> doko, infinity: want me to upload the binutils autopkgtest (tested locally in a VM) in bug 1081500?
<ubottu> Launchpad bug 1081500 in eglibc (Ubuntu) "Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc-dev, gcc, and binutils" [Low,In progress] https://launchpad.net/bugs/1081500
<aaron> hey i have a question... how do you setup your email that i have from ubuntu.com?
<infinity> pitti: That's doko's call, I have no firm opinion on the matter, but he may have a new binutils staged for other reasons.
<pitti> infinity: ok, thanks; I'll ask him when he gets up
<infinity> pitti: (As for the brown paper bag fix to the eglibc autopkgtest, I'll be rolling that into Debian experimental and then merging back soon)
<pitti> thanks
<infinity> ... just in time to start revving experimental to 2.17
<pitti> infinity: so you and ScottK are the only Americans who are still on IRC these days/
<pitti> ?
<pitti> seems everyone else went off to indulging turkey
<ScottK> infinity might object to the characterizaton.
<pitti> I had no overnight backscroll pings at all, at first I thought my proxy was broken
<ScottK> Heh.
<pitti> I didn't say "USian" :)
<pitti> Canada clearly is in America
<Aaron> lol
<infinity> pitti: Yeah, but Canadian Thanksgiving was last month, so no turkey for me.
<pitti> ah, I see; it's earlier because of the (on average) colder climate in Canada?
<infinity> pitti: Or because we just like to be different.  Who knows.
<pitti> so the harvesting had to happen earlier?
<pitti> infinity: well, at least this reasoning would be more convincing than the one about imperial units :)
<ScottK> Maybe they lost a month in the Imperial to Metric conversion.
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
<darkxst> didrocks, can you take a look at this patch? https://bugs.launchpad.net/ubuntu/+source/gui-ufw/+bug/1071915
<ubottu> Launchpad bug 1071915 in gui-ufw (Ubuntu) "gufw is not displayed under GNOME session" [Undecided,Confirmed]
<didrocks> darkxst: sure, will do :)
<darkxst> didrocks, it probably should go into raring as well, but I dont think raring was actually open when I uploaded it
<didrocks> darkxst: it needs to get to raring first
<didrocks> darkxst: mind proposing a branch for it as well?
<didrocks> darkxst: then, I'll do the review :)
<darkxst> yeh I figured that
<darkxst> ok one moment
<didrocks> sure ;)
<dholbach> good morning
<pitti> ev: are you still waiting for apw's feedback on https://code.launchpad.net/~ev/apport/kernel-oops-crash-signature/+merge/129440 ?
<darkxst> didrocks, https://code.launchpad.net/~darkxst/ubuntu/raring/gui-ufw/lp1071915/+merge/135834
<didrocks> darkxst: excellent! I'll have a look this morning :) Thanks a lot!
<darkxst> ok thanks
<didrocks> darkxst: commented btw :)
<rbasak> didrocks: may I poke you about sponsoring bug 1014732 please? It's been in the queue a while. The problem is that for as long as it isn't fixed, triaging other mysql bugs is harder because nobody has error logs
<ubottu> Launchpad bug 1014732 in mysql-5.5 (Ubuntu Precise) "log_error not set in my.cnf, errors not written anywhere" [High,Triaged] https://launchpad.net/bugs/1014732
<didrocks> rbasak: sure, looking :) (not sure having the competence on mysql though, so no promess)
<rbasak> Thanks!
<rbasak> didrocks: it's a trivial conffile change, cherry-picked from the development release (which was at the time quantal!). So just apport and conffile stuff
<didrocks> rbasak: yeah, indeed, not really mysql-deeply-insane-code related :)
<rbasak> :-)
 * rbasak wonders if that is what was scaring off all the sponsors :)
<didrocks> rbasak: it looks good to me, and no mysql in the SRU queue already, sponsoring :)
<rbasak> \o/
<rbasak> Thank you!
<didrocks> rbasak: well, there are keywords that are a natural filters :)
<didrocks> rbasak: like "potentially breaking all dbs on a LTS :p"
<rbasak> I can see why that could be a problem!
<didrocks> heh
<didrocks> pitti: mind rejecting https://code.launchpad.net/~nabil-stendardo/ubuntu/quantal/compiz/fix-segfault-related-to-shaders-and-uniforms/+merge/130709 ?
<pitti> didrocks: done
<didrocks> thanks :)
<didrocks> pitti: rejection needed on https://code.launchpad.net/~jlangvand/ubuntu/quantal/gnome-control-center/fix-for-993440/+merge/133570 :)
<pitti> done
<didrocks> thanks :)
<didrocks> https://code.launchpad.net/~timo-jyrinki/ubuntu/quantal/gnome-settings-daemon/ubuntu.fix1058004/+merge/127430
<didrocks> pitti: ^ de mÃªme, stp :)
<pitti> didrocks: avec plaÃ®sir, Monsieur! fini
<didrocks> un grand merci :)
<pitti> didrocks: oh, "plaisir"
<pitti> dear French, please make up your mind about whether or not to put an accent into a particular word. Love, pitti
<didrocks> we'll do it, just for you. I propose to put that as #1 world problem ;)
<darkxst> didrocks, raring patch was done as distro patch (but i missed the actual patch) fixed now
<didrocks> darkxst: same url?
<darkxst> yes
<didrocks> darkxst: and do you know why upstream set it as OnlyShowIn=Unity?
<darkxst> didrocks, no idea, although one of the gufw devs did ok my patch in the bug report
<didrocks> darkxst: I'm ok to sponsor it if you talk to them to get them upstream, can you do that?
<darkxst> didrocks, ok will do
<didrocks> darkxst: you forget to bzr add debian/patches/series though
<darkxst> didrocks, oops, added that too
<didrocks> pitti: and another one: https://code.launchpad.net/~bkerensa/ubuntu/raring/ubuntu-artwork/fix-for-depends/+merge/135534
<pitti> *zap*
<didrocks> darkxst: sponsored, thanks! :)
<didrocks> merci pitti :)
<didrocks> darkxst: do you want to put the quantal branch as a distro patch as well?
<darkxst> didrocks, yeh
<darkxst> didrocks, https://code.launchpad.net/~darkxst/ubuntu/quantal/gui-ufw/lp1071915B/+merge/135844
<smb> pitti, Hi I wonder who nowadays would be the person to talk to about jockey (back in Precise) and apport (seems like Precise and Quantal)
<pitti> smb: Apport is still me
<pitti> smb: Jockey, I try to forget about it :-) , but I guess I can still answer questions
<smb> pitti, So I am not completly sure about whether its pebcak but starting with jockey-text which since yesterday (with precise-proposed enabled) fails running, and apport asking me about submitting the report and then just ignoring my yes
<pitti> smb: sounds liek a regression from https://launchpad.net/ubuntu/+source/jockey/0.9.7-0ubuntu7.6 then
<pitti> smb: tseliot and bryce recently changed jockey to include the experimental nvidia drivers, that might have something to do with it
<smb> pitti, If "from" means introduced by, yes seems like it
<didrocks> darkxst: excellent!
<smb> pitti, I am sure it did work the day before because the steam client I am playing around with always asked me about the newer fglrx
<smb> (which failed to install then btu oddly succeeded today in text mode. gah!)
<pitti> smb: if you can confirm it's a regression in -proposed (try downgrading and killing jockey-backend), can you please follow up in bug 1080588 ?
<ubottu> Launchpad bug 1080588 in jockey (Ubuntu) "jockey suggests not installable packages on renamed stack" [High,In progress] https://launchpad.net/bugs/1080588
<pitti> smb: apport didn't open a firefox tab? or it just crashed? do you have a /var/log/*apport*.crash?
<smb> pitti, Should be able to try that, yep. :) Anyway apport seems to come up and it seems like the real upload part is not executed. And that seems to be the the same with another Precise box without proposed and Quantal
<smb> pitti, It seems just to exit after saying upload
<smb> pitti, no apport crash
<pitti> oh, sure
<pitti> smb: it's uploading to errors.ubuntu.com
<pitti> not to LP, sorry
<smb> pitti, At least in Precise there never is a *.uploaded (this seems to be there in Quantal)
<smb> Though the experience is a bit weird then
<pitti> smb: oh, but you have an .upload stamp?
<smb> pitti, the upload stamp yes
<smb> in all cases
<pitti> smb: "pidof whoopsie"
<smb> 2067
<didrocks> pitti: https://code.launchpad.net/~darkxst/ubuntu/quantal/gui-ufw/lp1071915B/+merge/135844 can you mark it as merged? (was targeting quantal instead of quantal-proposed)
<pitti> hm, I don't see a whoopsie log file
<smb> pitti, Probably I am again just too "old school" and expect a lp bug to open which I can add info to
<pitti> didrocks: done
<didrocks> thanks :)
<pitti> smb: yeah, we never did that in stable releases though (at least not for crashes)
<pitti> smb: hm, I'm afraid I need to defer to ev about why whoopsie doesn't upload the report
<smb> pitti, Ok, sure. Well maybe it *does*, I just have no clue how I would know
<tseliot> smb: what happens exactly?
<pitti> smb: firefox http://errors.ubuntu.com/user/`printf $(sudo cat /sys/class/dmi/id/product_uuid)|sha512sum`
<pitti> smb: (how can that not be totally obvious :-P)
<pitti> smb: displaying your sent errors is quite hard right now, that's known
<smb> pitti, *grumble*
<smb> tseliot, Basically everything looks "normal" and after clicking send report nothing happens. But as I learn this is normal and I probably did not try doing that for released releases for a while... :-P
<pitti> didrocks: oh, our GPU freeze is the top crasher in 13.04 for today on errors.u.c.
<didrocks> pitti: I have freeze, but not crasher now
<didrocks> like some write on disk freeze the ui for 30s
<didrocks> and then, back to life
<tseliot> smb: if there really was a crash it should be in /var/log/jockey.log
<smb> pitti, So I guess *if* I want to create a bug for a stable release now, I have to unpack the *.crash, create a bug with that title and run apport-collect for the rest after it is created?
<pitti> smb: see privmsg
<smb> pitti, yup thanks
<smb> tseliot, There are things in there and it is some type problem in jockey-text -l, just ranting about my inability to know that I have sent info. ;)
<tseliot> smb: heh, ok. If you pastebin the log I'llhave a look at the log
<smb> tseliot, http://paste.ubuntu.com/1379087/
<smb> tseliot, btw, downgrading jockey-common/-gtk to the precise-updates version makes it work for me again
<didrocks> pitti: https://code.launchpad.net/~evfool/software-properties/lp1060543/+merge/135513 -> WIP please :)
<didrocks> pitti: oh sorry, I can on that one
<pitti> didrocks: eek, you can't even set WIP?
<didrocks> pitti: on some, I can't
<didrocks> and my reviews are set as "(community)"
<Laney> usually SRUs
<didrocks> (this one was a regular upstream branch, so not the case)
<didrocks> (man, the sql testsuite is awfully long)
<tseliot> smb: ok, I'll investigate the issue
<smb> tseliot, Thanks, meanwhile I marked 1080588 as verification-failed
<smb> tseliot, if you want me to attach my apport data, let me know
<tseliot> smb: yes, it would be nice if you could attach your apport data
<smb> tseliot, ok, its up there
<tseliot> smb: thanks
<brendand_> tseliot, hi
<tseliot> hi brendand_
<darkxst> didrocks, thanks!
<didrocks> darkxst: yw :)
<didrocks> thanks to you!
<darkxst> np
<pitti> did anyone use autopilot before? I have some trouble with running tests, it doesn't seem to find my tests
<tkamppeter> Someone knows about the impact on battery life of avahi-daemon
<tkamppeter> Someone knows about the impact on battery life of avahi-daemon?
<sladen> tkamppeter: I don't, though perhaps the group in Montreal, with power-monitoring harnesses would be able to give you an exact figure
<tseliot> smb: see my private message
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach hugs didrocks
 * didrocks hugs dholbach back
<jodh> cking: thanks! http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/revision/1390?start_revid=1390
<cking> jodh, thanks for apply it and +1 to smatch
<jodh> cking: yeah :)
<cking> ..I wonder what to smatch next...
<jodh> cking: what's already been covered? I vote for libc, libnih, udev and plymouth if they haven't been subjected yet :)
<cking> jodh, libnih was clean when I tested it yesterday evening. how about doing udev and plymouth for starters?
<jodh> cking: smatch barfs on udev.
<cking> jodh, why am not surprised..
<cking> smatch can produce some false positives that need looking at though
<cjwatson> doko: Hmm, is g++-4.7-multilib busted perhaps?  Have a look at the tail end of the current gmp/amd64 build log
<cjwatson> doko: bug 1082344
<ubottu> Launchpad bug 1082344 in gcc-4.7 (Ubuntu) "x86_64-linux-gnu-g++ -m32 fails to find <bits/c++config.h>" [Undecided,New] https://launchpad.net/bugs/1082344
<jamespage> are there any packages already in main that offer similar/same function as 'gdisk' (GPT format fdisk clone); I see some support in parted but can't see anything else...
<jamespage> ?
<cjwatson> jamespage: what are you trying to do?  the installer uses libparted everywhere
<jamespage> cjwatson, I'm working on enabling the upstart integration for ceph; it used gdisk to prepare storage devices before bootstrapping them into a ceph cluster
<cjwatson> should be straightforward to do that with parted
<seb128> jamespage, hey, you are looking at samba in Ubuntu right? Do you plan to merge on Debian (I see we are 3 minor releases behind)
<jamespage> seb128, I appear to be the samba merge monkey ATM - I'd not noticed the bump in experimental - I'll take a look
<seb128> jamespage, thanks
<mitya57> pitti: re https://bugzilla.gnome.org/show_bug.cgi?id=686006:
<ubottu> Gnome bug 686006 in general "Some gvfs-test improvements" [Normal,Assigned]
<mitya57> git *does* support file permissions: http://paste.debian.net/211760/ :-)
<pitti> well, they didn't work for me..
<mitya57> cloning a branch also correctly restores all permissions
 * mitya57 needs to stop reading his google+ and do some python-gdata upload
<mitya57> hi dholbach
<mitya57> can I remove emptry "_static" folder from lp:ubuntu-packaging-guide?
<mitya57> I think we don't need it
<mitya57> and I'll do a MP for ubuntu logo now
<dholbach> mitya57, perfect
<dholbach> mitya57, ÑÐ¿Ð°ÑÐ¸Ð±Ð¾
<mitya57> I think you should now bump the version to 0.3
<mitya57> and thanks for dep-8 article update, I found it useful for myself :)
<mitya57> I've already added 5 dep-8 tests since quantal release :)
<dholbach> NICE
<dholbach> pitti, ^ :)
<mitya57> (warning: some are not released yet)
<dholbach> mitya57, yes, I agree we should get another version out
<dholbach> mitya57, it will be just a question if we can easily backport it to older releases - it might require a very recent sphinx, no?
<mitya57> why?
<dholbach> I thought we just got u-p-g to build because we got a sphinx fix into the archive?
<dholbach> I might be mistaken
<mitya57> If we don't build translations (do we?) we can get it to quantal & precise without any issues
<dholbach> at least for precise it currently does not build
<mitya57> let me look
<dholbach> https://launchpad.net/~ubuntu-packaging-guide-team/+archive/ppa
<dholbach> precise: https://launchpadlibrarian.net/123783723/buildlog.txt.gz
<dholbach> and so far we got uploads into R, Q and P - the latter only through backports
<mitya57> the only difference between precise package and precise package in our PPA is the fix-l10n-footnotes patch, right?
<mitya57> (which (the patch) has been updated upstream recently â I will need to look at it)
<dholbach> mitya57, ah, it's fixed and committed upstream now? that'd be fantastic
<mitya57> not committed yet (but a pull request exists)
 * Laney does a sad at 'only' :(
<dholbach> Laney, hm?
<dholbach> Laney, can you explain why you're sad? :)
<Laney> dholbach: oh, because 'only' sounds like backports is somehow an inferior method of distribution
<dholbach> no
<dholbach> we're talking about something different
<Laney> righto
<dholbach> in the PPA we have a modified sphinx because i18n support in sphinx is still pretty fresh and we're trying to figure out issues together with upstream
<dholbach> mitya57 has done the majority of the work
<Laney> fair enough
<dholbach> but we're not 100% there yet
<dholbach> I'd love to have translations and up-to-date packaging guides in all pockets of Ubuntu
<dholbach> it's in the cards, but will likely take a bit longer
<dholbach> so no disrespect for backports here ;-)
<mitya57> dholbach: forwarded the patch to debian (to debian bug 691719)
<ubottu> Debian bug 691719 in src:sphinx "sphinx: Please cherry-pick changeset b7b808e46851 that fixes issues with localized projects" [Normal,Open] http://bugs.debian.org/691719
<dholbach> mitya57, you're a hero
 * dholbach hugs mitya57
 * mitya57 hugs dholbach back and joins ~dholbach-huggers team on LP :-)
<dholbach> haha :)
<doko> cjwatson, still looking, it searches /usr/include/i386-linux-gnu/c++/4.7/32 instead of /usr/include/x86_64-linux-gnu/c++/4.7/32
<doko> hmm, only wrong on amd64
<doko> cjwatson, ahh, wrong MULTIARCH_DIRNAME for all 64bit archs with multilib builds
<doko> hmm, no amd64 only
<slangasek> cjohnston: hey, are you resetting the trend lines on status.ubuntu.com now that we've hit FDF?  I don't think I have access to do this
<cjohnston> working with is right now on it slangasek
<stgraber> wendar, highvoltage: FYI bug 1082426
<ubottu> Launchpad bug 1082426 in Precise Backports "Please backport lxc 0.8.0~rc1-4ubuntu38 (universe) from quantal-updates" [Undecided,New] https://launchpad.net/bugs/1082426
<highvoltage> stgraber: cool
<stgraber> hallyn: ^
<hallyn> stgraber: excellent, thx
<stgraber> hallyn: oh, and bug 509647 and bug 1082431 too
<ubottu> Launchpad bug 509647 in lxc (Ubuntu) "[MIR] lxc" [Undecided,New] https://launchpad.net/bugs/509647
<ubottu> Launchpad bug 1082431 in libseccomp (Ubuntu) "[MIR] libseccomp" [Undecided,New] https://launchpad.net/bugs/1082431
<stgraber> jdstrand: I guess you'll want to look at those two when you have a minute (as I'm guessing any other MIR team member will redirect those to you anyway :))
<wendar> stgraber: awesome!
<hallyn> stgraber: heh, "all are direct cherry-pics of staging" - or rather vice versa :)
<hallyn> time to send that syslog-ns description to the kernel team methinks
<stgraber> hallyn: hehe, yeah, I should maybe have mentioned that we are the author of 90% of those so technically the staging branch cherry-picks from Ubuntu :)
<`|`roll> FELLERS, I discovered a bug in Unity that could lead a remote attack to compromised your system.
<xnox> `|`roll: file a bug on launchpad, make sure you tick security such that it is private and the ubuntu security team will collaborate with you to handle it.
<`|`roll> I have done that 2 weeks ago.
<`|`roll> I havent had any response.
<xnox> `|`roll: also see #ubuntu-security channel to enquire about the status
<xnox> `|`roll: what's the bug number?
<cjwatson> https://wiki.ubuntu.com/SecurityTeam/Contacts
<`|`roll> It is somewhere on my email
<cjwatson> `|`roll: https://bugs.launchpad.net/~/+reportedbugs should show it, if you're logged in
<`|`roll> I just emailed them again.
<`l`roll> Can I start developing for Ubuntu?
<slangasek> cjohnston: cheers :)
<`l`roll> niggers
<`l`roll> niggers
<`l`roll> niggers
<hallyn> stgraber: are you an appropriate one to ping on bug 1075717 in mountall?
<ubottu> Launchpad bug 1075717 in mountall (Ubuntu) "mounted-dev must not re-create consoles in a container" [High,New] https://launchpad.net/bugs/1075717
<stgraber> hallyn: yeah, I'll take a look. How comes we didn't see this before?
<hallyn> stgraber: because we didn't mount a separate /dev before
<hallyn> stgraber: thanks
<wbgs_gaming> hello guys will you be releasing a Openbox version of ubuntu casue thats really like the only version that works for me somthing like Openbox with either lxde,xfce or tint2 panel ?
<sarnold> wbgs_gaming: you can always install and run whatever window manager you want, no need for a different version of ubuntu.
<wbgs_gaming> sarnold I was thinking of making a my own distro but i need more help if I dont get linux running good then i might as well as throw my pc out lol
<wbgs_gaming> could I use Ubuntu as base for open box style distro also might run low latency kernel
<sarnold> wbgs_gaming: yeah, there's no need for that :) you just need to make sure you get your windowmanager of choice installed...
<sarnold> wbgs_gaming: you sure could
<wbgs_gaming> sarnold you a dev
<sarnold> wbgs_gaming: but making a new distribution is a fair amount of work.
<wbgs_gaming> I think ubuntu tweak can uninstall useless apps right
<wbgs_gaming> i wanna strip ubuntu down to its core and just have a menu where you can choose to install games in teh repositroy and when steam release have that there along side POL
<wbgs_gaming> the liter te kernel the better
<wbgs_gaming> we re only focusing on browsing the net and gaming -_-
<wbgs_gaming> the distro should be under 500mb
<ogra-cb> use lubuntu then
<sarnold> https://wiki.ubuntu.com/Core -- ~20 megabytes
<ogra-cb> it has an openbox install that you can pick as your default desktop on the login manager
<ogra-cb> and its under 500M
<sarnold> you get to pick exactly what you want. :)
<ogra-cb> no
<ogra-cb> dont use ubuntu-core
<wbgs_gaming> sarnold any how thanks alot for your help I think ill reinstall ubuntu and try my idea DE's lag my pc also Lubuntu has errors all the time in 12.10 and the graphics preformence is junk with AMD
<ogra-cb> unless you know exactly what you are doing
<sarnold> wow
<wbgs_gaming> what you reconmend
<sarnold> wbgs_gaming: try lubuntu first.
<wbgs_gaming> sarnold already have
<ogra-cb> well, you could do a cmonnadline install using the mini iso, then install openbox and xorg and be done
<ogra-cb> *commandline
<wbgs_gaming> sarnold Xubuntu is what i like but snap to screen is a pain alwasy enabling and teh AMD graphics dont preform up to par
<sarnold> wbgs_gaming: indeed, amd has historically been a pretty poor partner
<wbgs_gaming> well on all the ubuntu distros AMD has not preformed upto par
<sarnold> wbgs_gaming: nvidia has done better, if you don't mind running proprietary drivers
<sarnold> s/ubuntu/linux/
<wbgs_gaming> well i am not gona switch to nvidia just to run Linux lmao
<sarnold> intel's drivers on the other hand are open and good.
<sarnold> their performance may not be nvidia, but I'd pick intel every time. they're a good partner. :D
<wbgs_gaming> not as powerfull and again that requires me buying another pc
<wbgs_gaming> the only soulution is openbox too bad there aint a flavour of that ubuntu has every thing but that
<wbgs_gaming> any how i am gona reinstall my ubuntu i burned it too fast before i am gona try it agian see how it goes.
<wbgs_gaming> sarnold thansk alot and ttyl
<sarnold> have fun wbgs_gaming :)
<Logan_> vila: Are you around?
<achiang> does ubuntu ship valgrind suppression files anywhere?
<jtaylor> achiang: pkg -L valgrind | grep supp
<jtaylor> dpkg
<achiang> jtaylor: hm, let me ask another way. i want to ship a suppression file for fontconfig. is there a standard way to do so?
<jtaylor> achiang: python3 places a file in the valgrind folder
<achiang> ah, ok
<jtaylor> but I kind of doubt that is really how it should be done
<jtaylor> a valgrind.supp.d folder would be nice
<jtaylor> better ask the valgrind maintainers
<infinity> Looks like they go in /usr/lib/valgrind/${package}.supp
<infinity> Seems reasonable.
<infinity> Don't know why you'd need another level of abstraction.
<infinity> achiang: ^
<jtaylor> infinity: we have .d folders for so much why not for this too?
<infinity> Why would it need one?
<achiang> infinity: yep, i'm playing with ${package}.supp now
<jtaylor> consistency
<jtaylor> if I wouldn't have found python3 in there I would never have guessed that that works
<jtaylor> (if it even works, did not test it)
<achiang> strange, i dropped fontconfig.supp into /usr/lib/valgrind and it doesn't seem to get autoloaded (or used or whatever)
<jtaylor> I'll file a bug in valgrind, at least a clear strategy for package should be documented
<infinity>        --suppressions=<filename> [default: $PREFIX/lib/valgrind/default.supp]
<achiang> ok, /usr/bin/valgrind is a wrapper
<infinity>            Specifies an extra file from which to read descriptions of errors to suppress. You may
<infinity>            use up to 100 extra suppression files.
<infinity> ^-- I see no mention that they'll be autoloaded (except for default)
<achiang> that calls valgrind with a --suppressions arg
<achiang> for the libc-dbg package
<infinity> Right, but it's not going to autodetect all others.
<achiang> nod
<infinity> Maybe it could/should?  I dunno.
<achiang> well... so here's the thing
<achiang> we want to recommend to lots of people to start valgrinding packages everywhere for the nexus7
<achiang> but i don't want to be flooded with false positives
<infinity> Are suppression files sufficiently well namespaced that they can't clash/conflict?
<jpds> jtaylor: Erm, .d is for a configuration file that can be split into other configuration files.
<achiang> i can write suppression files, but it would be super nice if valgrind would automatically use them
<infinity> If not, then autoloading /usr/lib/valgrind/*.supp would be a losing strategy.
<jtaylor> jpds: kind of applies to suppression files
<achiang> no clue really, which is why i'm asking here. :)
<jtaylor> jpds: you can cat them together or just add multiple --suppression args
<infinity> jpds: I could see an argument for moving suppressions to /usr/lib/valgrind/suppressions/, but that would not only require patching valgrind, but every package that already ships the other way.
<infinity> Which doesn't seem like a win, just for aesthetics.
<achiang> ignoring the aesthetics question for now, how about simple tractability? the namespace issue seems annoying (but not insurmountable)
<jtaylor> btw someone should merge valgrind from unstable
 * jtaylor hides
<infinity> achiang: The file namespace is clear, it's $package.supp, and we can't have conflicting package names.
<jtaylor> infinity: what is with user suppressions?
<infinity> jtaylor: Those tend to be in your build directory.
<achiang> infinity: nod. i'd agree with that
<jtaylor> there are reasons to have those system wide
<jtaylor> though probably rare
<achiang> the next question is, how to make valgrind magically use them
<achiang> i don't want a situation where well-intentioned (but not super technical) folks flood LP with bogus reports
<jtaylor> achiang: if lib/valgrind/ does not work then file a bug
<jtaylor> to me it looks like a useful feature
<infinity> achiang: The wrapper could be changed to walk /usr/lib/valgrind/*.supp and use them all, I'm just unsure if that's a good idea.
<infinity> I don't know enough about valgrind suppressions to say one way or the other if you actually always want them all loaded.
<achiang> jtaylor: see above, i wrote a fontconfig.supp and put it into /usr/lib/valgrind, but it doesn't get autoloaded. and i think i agree somewhat w/infinity that it might not be a good idea
<achiang> maybe a better way to do this would be to write a user-friendly valgrind wrapper that knows to load specific suppression files based on the app you're profiling. except that's signing up for a *lot* of manual maintenance
<infinity> achiang: Actually, that wouldn't be wildly difficult.
<achiang> sketch an outline for me?
<achiang> see also discussion here - https://code.launchpad.net/~achiang/ubuntu-nexus7/valgrind-ubuntu-dbg-packages/+merge/134841
<infinity> achiang: Well, for C, it's easy.  Parse ldd output, trace owners of libraries to map lib->package, add $package.supp to command line.
<achiang> maybe some sort of apport wrapper thingy that not only installs the -dbg packages but also adds $package.supp to cmdline?
<infinity> achiang: For interpreted languages, a bit stickier, you'd need to parse the dpkg depends for the package, since there's no simple way to know all the deps of a shell script, for instance.
<infinity> apport-retrace does indeed have most of the magic already, perhaps it could be leveraged for valgrindiness too.
<achiang> infinity: i don't mind doing a simple thing first and then iterating to something fancy later
<infinity> Since it also handles debug symbols and the like.
<infinity> pitti / ev / bdmurray: Opinions on the suitability of genericising apport-retrace to also do valgrind dep-tracking magic?
<achiang> but we run apport-retrace on the server side, right? i'd want something that's dead simple for users to run... the end goal is: ./wrapper <app> => *useful* log to upload to LP
<achiang> (without multiple rtts)
<infinity> achiang: It can be run locally too.  Some people do.
<infinity> achiang: But this is more about possibly refactoring its dependency tracing and ddeb-installing magic, so it could be used in a valgrind wrapper, not really about retracing.
<infinity> But writing code twice seems silly.
<achiang> libnih? ;)
<infinity> Not my project. :P
<achiang> but yeah, +1 to code reuse
<infinity> I'm a glibc maintainer, I believe in improving on old codebases, obviously.
<infinity> (We'll ignore the ancient history of libc4 and libc5...)
<achiang> infinity: looks like pitti is suggesting exactly that -- apport-valgrind <package>
<infinity> achiang: Great minds and/or fools.
<achiang> https://code.launchpad.net/~achiang/ubuntu-nexus7/valgrind-ubuntu-dbg-packages/+merge/134841/comments/291330
<achiang> guess i should go stare at apport code
<achiang> oh, oops, it was actually this comment where he suggests it - https://code.launchpad.net/~achiang/ubuntu-nexus7/valgrind-ubuntu-dbg-packages/+merge/134841/comments/291343
<infinity> achiang: Right, of course that should be "apport-valgrind <binary> -- -args" with apport figuring out the package itself, but otherwise I agree that seems a sane way to go.
<achiang> infinity: so not being entirely familiar w/apport, would someone be able to have a long running process in the -S sandbox?
<infinity> achiang: I'm not hugely familiar with it myself, but I don't see why it wouldn't be possible.
<infinity> achiang: Though, sandboxing may be overkill.  apport can do sandbox-free as well, I believe?
<infinity> achiang: Just means removing the ddebs/-dbgs you install, instead of blatting a sandbox chroot.
 * slangasek looks around for the library that libnih is redundant with ;)
<infinity> slangasek: Possibly glib?
<slangasek> I think that might've been the joke, but I know I'd much rather use libnih than glib
<infinity> slangasek: Wasn't the intent to write a slimmer and more targetted glib, to avoid having glib as a low-level system dep, and then glib ended up a low-level dep of everything else anyway?
<slangasek> it didn't
<slangasek> not at that level
<infinity> Pretty close.  It's required on Debian/Ubuntu.
<slangasek> hmm, that appears to be a bug?
<slangasek> I don't see any Prio: required revdeps in Ubuntu
<infinity> udev?
<slangasek> nope
<infinity> Yep...
<slangasek> though that reminds me, I should probably see about getting libjson moved to /lib before I reboot again
<slangasek> libjsonc
<slangasek> ah, udev does depend on it, weird that grep-available doesn't know this
<slangasek> ok, so *why* does udev depend on glib? :)
<infinity> Looks like a ton of the utils in /lib/udev link it.
<slangasek> only /lib/udev/udev-acl
<infinity> slangasek: You and I have divergent definitions of "only".
<infinity> slangasek: http://paste.ubuntu.com/1380670/
<slangasek> infinity: only one of those is from the udev package
<infinity> Ahh.
<infinity> Fair enough.
<slangasek> the rest are hooks to the crazy train
<infinity> Seems like mostly a non-issue since any sufficiently interesting system will have glib installed anyway.
<infinity> Though, if that's the only thing dragging it into initrds as well, that's a bit irksome.
<mspencer> Is this a good channel to ask questions about quickly?
<bkerensa> mspencer: #quickly might be more adequate
<mspencer> bkerensa: Thanks, I didn't know there was a specific channel.
#ubuntu-devel 2012-11-24
<ScottK> doko_: Do you mind if I rescore your GCC 4.7 upload down on powerpc?  We are still way behind there and it's holding up migrations from proposed.
<ScottK> doko_: I'm going to go ahead and do it.  Let me know if that's a problem?
<lollisoft> General advice in managing vendor repositories when using build services like CC or Hudson / Jenkins? How do you handle this? Pull at build or keep a vendor src code copy?
<penguin42> hmm; if I've got a fix for a crasher that's caused by a debian patch, but doesn't seem to trigger on debian, what do I do - add another patch or change the debian patch?
<cjwatson> penguin42: Judgement call, mostly depending on what you think will be easier to merge in future, or on the flip of a coin.  I've done both in the past.
<cjwatson> I don't think it's desperately important.
<cjwatson> Sometimes if the patch stack on top is complex then modifying the Debian patch can be less confusing all round.
<penguin42> ok, I think I'll modify the patch, it's a 1 line removal; (it's bug 1069897)
<ubottu> Launchpad bug 1069897 in gdb (Ubuntu) "gdb crashes on startup if run as root via sudo and ~/.gdbinit exists" [Medium,Triaged] https://launchpad.net/bugs/1069897
<penguin42> cjwatson: I'm tempted to open a debian bug for it as well, even though it doesn't seg for them, but they're on gdb 7.4 so it's possible that something has changed in the gdb cleanup system
<penguin42> if there's a bored patch pilot hiding, I'd appreciate if they could have a glance at my branch to fix bug 1069897
<ubottu> Launchpad bug 1069897 in gdb (Ubuntu) "gdb crashes on startup if run as root via sudo and ~/.gdbinit exists" [Medium,Triaged] https://launchpad.net/bugs/1069897
<patr|ck> sorry to intrude once again, but the support channel is not the right place for such questions. how can i find out what CPU and I/O scheduling settings are used in Ubuntu 12.04 and newer, please?
<jtaylor> patr|ck: in /boot/config*
<jtaylor> I guess, please be more specific
<patr|ck> jtaylor, thats the entire configuration, no config file settings?
<jtaylor> patr|ck: what exactly are you looking for?
<patr|ck> e.g. when i copy large chunks of data around my desktop is unusable till these transfers are complete. or i have a software that is indexing wikipedia and using xulrunner a lot. and my system freezes frequently
<patr|ck> i wanna get to the source of the problem
<jtaylor> those are pretty common problems with linux defaults in general, /boot/config* should contain the information you need
<jtaylor> you are probably interested in the schedulers and swapping settings
<patr|ck> can you point me to resources that instruct how to fix this common problem?
<jtaylor> I'm not sure there is a solution, if it is its probably by using non standard schedulers that may require recompilation
<patr|ck> okay, thank you
<jtaylor> e.g. bfs is supposed to be better for interactive use, but don'T know how true that is nowadays
<hrw> hi
<hrw> can someone explain to me why apport has so broken dependencies?
<hrw> hrw@krolik:/var/log$ apport-collect 1082742
<hrw> You need to run 'sudo apt-get install python-apport' for apport-collect to work.
<hrw> hrw@krolik:/var/log$ apport-collect 1082742
<hrw> ERROR: The launchpadlib Python module is not installed. This functionality is not available.
<hrw> 1. apt-get install apport 2. apport-collect 3. apt-get install python-apport 4. apport-collect 5. apt-get install python-launchpadlib
<hrw> WHY?
<hrw> if apport-collect is useless without python-launchpadlib and python-apport then split it to separate package if you do not want to add those packages when apport is installed
<cjwatson> hrw: You might do better to ask when pitti is around
<hrw> cjwatson: now I am reporting bug about it. this way I will not forget
<hrw> Bug #1082743
<ubottu> Launchpad bug 1082743 in apport (Ubuntu) "apport-collect requires 2 extra packages to be installed by hand to be usable" [Undecided,New] https://launchpad.net/bugs/1082743
<hrw> sometimes I am tired of missing dependencies in ubuntu packages
<xnox> hrw: because we do not want launchpadlib on the cd.
<xnox> hrw: use ubuntu-bug in small environments / live-cd the apport-collect indeed wants more dependencies than ubuntu-bug to talk to launchpad.
<hrw> xnox: split apport-collect to separate package?
<hrw> xnox: I use launchpad directly for reporting bugs as this is easier that way.
<hrw> Bug #1082742 is more annoying anyway
<ubottu> Launchpad bug 1082742 in plymouth (Ubuntu) "plymouthd: ply-terminal.c: 611 ply_terminal_open: Assertion `terminal != ((void *)0)' failed." [Undecided,New] https://launchpad.net/bugs/1082742
<xnox> hrw: I see your usecase. Maybe it should be split.
<hrw> or rather users which ask me on google+ how to get rid of it
<hrw> xnox: cool
<slangasek> hrw: is bug #1082742 new with plymouth 0.8.8-0ubuntu1?
<ubottu> Launchpad bug 1082742 in plymouth (Ubuntu) "plymouthd: ply-terminal.c: 611 ply_terminal_open: Assertion `terminal != ((void *)0)' failed." [Undecided,New] https://launchpad.net/bugs/1082742
<hrw> slangasek: no, it is also in precise and quantal iirc
<slangasek> ok
<slangasek> it's possible this is related to the bugs ogra-cb_ was reporting on the nexus7
<hrw> maybe
<hrw> slangasek: do you have bug numbers?
<slangasek> hrw: no, just a verbal report on IRC
<hrw> ok
<hrw> I prefer to not move to kernel with hardcoded cmdline (if this is reason)
<slangasek> but yeah, he was talking about the issues with parsing of console= in plymouth
<hrw> yep, same problem
<slangasek> console= args are obviously meant to be "all of the above", not "either/or"
<iamsrp> hi
<iamsrp> it looks like 'git clone git://kernel.ubuntu.com/hwe/ubuntu-nexus7.git' is currently failing
<iamsrp> "kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection refused"
<iamsrp> known issue?
 * achiang is playing around w/apport-retrace... where can i find a sample apport crash report to play with? would i just download all the .txt files in bug #252046, e.g.?
<ubottu> Launchpad bug 252046 in gvfs (Ubuntu) "gvfs-hal-volume-monitor crashed with SIGSEGV in strlen()" [Medium,Fix released] https://launchpad.net/bugs/252046
#ubuntu-devel 2012-11-25
<achiang> anyone around and familiar with valgrind?
<DNS> heya :) i have a question about the ubuntu linux kernel source... is in general all in ubuntu/ and include/uapi on a free license or is there something unfree in it?
<DNS> looks for like all is on free license but i want to be sure
<DNS> *looks for me
<dontknow> i cant enter http://kernel.ubuntu.com  could you verify
<mitya57> dontknow, I can confirm that it doesn't work
<mitya57> dontknow, maybe you can get the info you need from some other service?
<dontknow> mitya57: thanks. where can i download ubuntu kernel patches
<mitya57> dontknow, it seems that that there are no mirrors of their git... You may ask tomorrow when there will be some kernel team members here...
<mitya57> dontknow, or you can download the .tar.gz from https://launchpad.net/ubuntu/+source/linux
<dontknow> mitya57: thanks a lot
<benJIman_> Hi. Is there an API/machine readable listing of all PPAs on http://ppa.launchpad.net/ ?
<jtaylor> benJIman_: launchpadlib probably has something
<benJIman_> Ta
<jtaylor> benJIman: https://launchpad.net/+apidoc/1.0.html
#ubuntu-devel 2013-11-18
<apachelogger> slangasek: http://bazaar.launchpad.net/~apachelogger/+junk/plymouth-stop-kdm/revision/1461 does that look sane to you?
<stokachu> Noskcaj: i think i was waiting on some feedback from some internal channels before merging
<stokachu> Noskcaj: for precise anyway, haven't done anything with trusty yet so feel free
<RAOF> So, uh, where's the libudev bug tracker these days?
<pitti> Good morning
<Noskcaj> stokachu, I was meaning trusty, but i'm not really able to fix the ubuntu patch fot this
<Noskcaj> *for
<arun> Hello guys  may I ask a question?? Does the locale of Ubuntu comes from Debian or glib
<arun> *glibc
<pitti> arun: from upstream glibc, with some Debian and Ubuntu patches
<arun> pitti: that means if I upload my locale in glibc, it will be applied in Debian and Ubuntu ?
<pitti> arun: yes; and we can even do that early, but we require a locale to be submitted (and if possible, reviewed) upstream before we include it
<arun> pitti: so, how can I upload the locale to Ubuntu that I have already done in glibc
<arun> pitti: should I have to again in Ubuntu if I have already done in glibc ?
<pitti> arun: please open a bug against "langpack-locales" and give the URL to the upstream bug
<arun> pitti: so, when may the patch get update in distro?
<pitti> arun: should be in the next couple of days then
<arun> or can I download the package of the updated one ?
<pitti> arun: well, you submitted the locale upstream, I'd assume you have it actually installed to test it :)
<arun> pitti: then after that will the language packs get updated in Installer also?
<pitti> arun: yes, then we'll build langpacks, as soon as we get them for trusty (they aren't enabled yet)
<arun> pitti: can't I apply or test it in my own system ?
<arun> pitti: I would I do that, I can't figure out !!
<pitti> arun: how did you test it if you didn't do that?
<arun> *how
<arun> pitti: I just created the locales not tested it
<pitti> please see "man localedef"
<pitti> arun: you can copy it to /usr/share/i18n/locales/, add it to /usr/share/i18n/SUPPORTED, and then run "sudo locale-gen xx_YY.UTF-8" to test it like if it was shipped by the distro
<pitti> with localedef you can build it without mucking around in /usr
<arun> pitti: ok wait ok , I am testing please be in touch
<arun> Pici: yes then what to do after locale-gen ?
<arun> pitti: are u there?
<arun> Pici: sorry
<arun> pitti:  yes then what to do after locale-gen ?
<pitti> arun: you run your program under that locale
<pitti> LANG=xx_YY.UTF-8 gedit
<pitti> or whatever else
<pitti> or set it as system default locale to test everything
<pitti> of course you won't have many translations (unless you installed a few from your translation efforts), but you can check time format and the like
<arun> pitti: yaa I wanted to check that time thing, how to ?
<pitti> "date", or look in the panel
<arun> pitti: didn't work
<arun> pitti: it didn't get applied I think
<arun> pitti: hello are u there?
<arun> pitti: what should I do the next
<pitti> arun: do you see your locale in "locale -a"?
<arun> pitti: no there no
<pitti> so you didn't run locale-gen with your new locale name
<arun> pitti: I did
<pitti> then it failed; do you get some error message ther?
<arun> pitti: no , I don't
<pitti> arun: please pastebin the whole command that you ran and its output
<arun> pitti: I did this :- sudo locale-gen the_NP.UTF-8 and enter but no errr\or
<arun> pitti: and then did sudo locale -a and there is no the_NP in that list
<pitti> arun: did you get the "Generating locales..." "the_NP.UTF-8... done" output? (pretty please just show me the whole output -- I can't pull every single piece of information like that)
<arun> pitti: no that thing didn't come
<arun> there is no such output , I mean no output
<pitti> arun: then you didn't add it to SUPPORTED
<arun> pitti: i did it , dude
<arun> pitti: oh ya
<arun> pitti: I had missed it sorry
<arun> pitti: I had got an error in 1st try that is http://dpaste.com/1470055/ then in second attempt no errors output was without error
<pitti> yeah, that's why you need to test a locale :)
<pitti> so, apparently "the" needs to be added to some place I don't know
<arun> pitti: oh
<arun> pitti: but the date is not being appplied
<pitti> so that localedef knows it
<pitti> probably some place in libc which knows about the 2/3-letter iso codes
<arun> pitti: now its listed in locale -a
<pitti> at this point this really needs a bug report
<pitti> to track this between the different packages and upstreams
<arun> pitti: and when I type  LC_TIME=the_NP.UTF-8 it says
<arun> bash: warning: setlocale: LC_TIME: cannot change locale (the_NP.UTF-8)
<pitti> yeah, as the generation of the locale failed due to the unknown "the"
<arun> pitti: oh wait
<infinity> Looking at the commit upstream, it looks like there might just be a stray "the" on the line before lang_term (or, perhaps, that was meant to be preceded with a "lang_ab")
<infinity> +postal_fmt  "<U0025><U007A><U0025><U0063><U0025><U0054><U0025><U0073>/
<infinity> +<U0025><U0062><U0025><U0065><U0025><U0072>"
<infinity> +% the
<infinity> +lang_term    "<U0074><U0068><U0065>"
<infinity> +% the
<infinity> Oh, wait, I'm reading that backward.
<infinity> Yeah, that looks like it's right.
 * infinity shouldn't try to understand new things at 7am.
<arun> infinity: ok
<pitti> infinity: I think libc-bin (localedef) has some kind of compiled form from iso-codes which hardcode the available language names and 2/3 letter ISO codes
<infinity> pitti: You think it's picking it out of localedata/SUPPORTED at compile time instead of runtime?  That seems silly.
<pitti> infinity: no, just the definition of "the"; localedef verifies that the language name is known (and what it actually expands to)
<pitti> I'm not sure where that lives, though
<arun> yes guys have a look https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/iso-639.def;h=56db3c81d53709194486bc579f0ec5cc4a14cc3d;hb=b46d046e7bf7e0f96e41e522da731b89177e31ab
<pitti> looks like it
<infinity> Ah-ha.
<arun> so, where that thing is compiled !!
<infinity> So, the big question is, is Tharu/the defined by iso-639?
<infinity> Oh, it's already in there.
<infinity>  463 DEFINE_LANGUAGE_CODE3 ("Tharu, Chitwani", the, the)
<pitti> infinity: yes, it's in /usr/share/xml/iso-codes/iso_639_3.xml
<infinity> I'm just blind.
<pitti> ah, but not in langpack-locale's copy of iso-639.def
<pitti> so that needs to be synced
<pitti> one more reason to merge them back to glibc :)
<pitti> I didn't actually think it would be used/installed anywhere, though
<pitti> it can probalby just go from langpack-loclaes
<pitti> infinity, arun: or perhaps this has been added later than the ubuntu release arun is running this on?
<infinity> It's not in the 2.18 iso-639 (and, of course, this locale isn't in 2.18 either), so if someone wants me to pull it back into 2.18, a bug filed would be nice, before I go fly for 12 hours and forget about this.
<pitti> ah
<pitti> arun: ^ what I said about "this needs an ubuntu bug report at this point to coordinate"
<dholbach> good morning
<arun> pitti: ok brother as this is  a new locale , I had just added that in the glibc 2 days ago
<infinity> arun: Indeed, I can see the upstream commits.  But if you want it in a distro before 2.19 comes out, we need to pull some patches.  If you don't care about it working until 2.19 is in the distro, you can do nothing and just wait.
<infinity> (I'd do it now in my 2.18 packaging, but I'm literally 2 minutes away from closing my laptop and running to a train station)
<arun> the thing is the packing didn't worked for me that I tried
<infinity> arun: So, if you want it backported, please file a bug on eglibc and assign it to "adconrad".  If you're happy waiting for 2.19, wait.
<arun> infinity: when are u returning home?
<infinity> arun: I'll be home in half a day or so.
 * infinity runs off.
<arun> infinity: when will glibc get released
<arun> pitti: bro so whats next
<arun> pitti: what should I do
<arun> pitti: any way to test that crap ?>
<pitti> arun: as I said, please file an ubuntu bug with pointing to the upstream bug where you submitted the locale (unless it's already committed), and we'll coordinate the glibc/langpack-locales uploads
<pitti> arun: whoa, calling your work "crap"?
<pitti> arun: you could locally build eglibc with that patch applied, but that will take a bit
<arun> pitti: oh thanks brother
<arun> pitti: thanks a lot
<arun> I will surely bug a report
<arun> pitti: when is LTS releasing?
<pitti> arun: next April
<arun> pitti: oh that mean 6 months left?
<Noskcaj> arun, yep
<arun> and should I finish all the things before that to get it in it
<Noskcaj> arun, For the actual code, yes. translations can be added (i think) in LTS point releases
<arun> Noskcaj: what if the translations are not made in it, willl the work in it
<arun> Noskcaj: WILL IT BE AVAILABLE IN Language Option during installation ?
<Noskcaj> arun, If the code changes get done, and launchpad recognises the language, yep
<arun> Noskcaj: cool, yes Launchpad does
<arun> but the translations are done in another stream can we submit the po file to the maintainer later on ?
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<jamespage> morning folks
<arun> jamespage: hello
<jamespage> hey arun
<arun> jamespage: how are u ?
<jamespage> arun, all good here
<arun> jamespage: cool, are u in locale maintaining ?
<Noskcaj> Laney, just wondering, when do you think evolution 3.10 will be in ubuntu?
<jamespage> arun, not quite sure I understand the question - I'm on pilot duty this morning
<jamespage> so working through the sponsorship queue right now
<Noskcaj> jamespage, he's trying to add a new language to ubuntu
<arun> Noskcaj: yup like that
<Laney> Noskcaj: once webkit stops being sad
<Noskcaj> ok
<Laney> it keeps being oom killed on the porter box so I can't be sure if my fixes work :(
<jamespage> arun, can't help you with that - sorry
<arun> jamespage: ok
<arun> jamespage: thanks
<seb128> is update-apt-xapian-index segfaulting in trusty for others as well?
<xnox> just unity-panel-services yere.
<seb128> xnox, do you have a backtrace?
<xnox> seb128: whoopsie uploaded a crash & ubuntu-bug *.crash doesn't do anything to launchpad.
<seb128> xnox, can you give me the error id?
<seb128> xnox, you can access your list of report from gnome-control-center -> privacy iirc
<xnox> xnox: the top three at https://errors.ubuntu.com/?package=unity-services&period=day is what I see.
<xnox> seb128: ^
<xnox> seb128: to trigger, open oboard and wait or some such. eventually it has a fizzy fit.
<seb128> xnox, is that on trusty?
<seb128> xnox, but yeah, seems like a11y related, which probably explain why I don't see those, I didn't activate a11y
<seb128> xnox, it's weird, those 3 reports haven't been seen in versions > precise according to e.u.c (which is right, they got fix in quantal iirc)
<xnox> seb128: you need a touch screen notebook ;-)
<seb128> xnox, feel free to send me one ;-)
<seb128> xnox, are you sure it's the same bug though?
<xnox> no, but i have no idea how to force ubuntu-bug to upload a crash. it now says that my packages are obsolete, duh
<xnox> anyway, need to do real work.
<seb128> xnox, can you copy the file somewhere where I can download it?
<darkxst> xnox, just point ubuntu-bug at the crash file in /var/crash
<darkxst> you might need to retrace locally though, if you have obsolete packages
<darkxst> crash reports bit rot pretty fast ;(
<cjwatson> arun: If you want a locale to be available during installation, you need to start work ASAP on getting debian-installer translated to it, and that work needs to be done in Debian.  See https://web.archive.org/web/20130923213600/http://d-i.alioth.debian.org/doc/i18n/
<cjwatson> (alioth.d.o is down right now so you get an archive link ...)
<arun> cjwatson: yaa, its down so, I am in idle now
<arun> cjwatson: and how can I get the glibc compiled
<cjwatson> Please don't ask me about that.
<cjwatson> I'm just telling you that you need to start on this work in Debian as soon as possible because the translations will take some time to filter through to Ubuntu.
<cjwatson> (And we don't enable new installer translations unless they've been done in Debian; it just doesn't scale for us.)
<arun> cjwatson: but the server is down now , isn't it ....
<cjwatson> Yes, but that doesn't stop you getting started on some of the other parts of that.  For example, have you contacted the d-i development team yet?  Start from https://web.archive.org/web/20120401055952/http://d-i.alioth.debian.org/doc/i18n/ch03.html
<yolanda> hi doko, i saw you filed some failures about trusty complaining for not finding ac_nonexistent.h file, how did you solve it? it happens to me with couchdb
<doko> yolanda, hmm, can't remember, which ones I did file ...
<yolanda> http://people.debian.org/~doko/logs/arm64-20131023/logs/buildlog_ubuntu-trusty-arm64.rtmidi_2.0.1~ds0-3_FAILEDTOBUILD.txt
<yolanda> so i'm seeing same errors when building couchdb for trusty
<doko> yolanda, well, I didn't fix these =)
<yolanda> doko, so you just left it, is there some issue with trusty then?
<doko> yolanda, most likely. but I didn't do a test rebuild for trusty yet. this was just the initial arm64 build
<yolanda> doko, ok, i'm adding some new features for trusty to that packages and having that problem. Not sure if just build for saucy instead
<Ampelbein> Hi there. Could somebody with the rights to do so accept the nomination of bug 1183580 for saucy?
<ubottu> bug 1183580 in librcc (Ubuntu) "[SRU] librcc segfaults on latest saucy" [High,Fix released] https://launchpad.net/bugs/1183580
<pitti> Ampelbein: done
<Ampelbein> pitti: Thank you.
<xnox> yolanda: do you have a link to the full build-log?
<yolanda> xnox, just built locally, i can rebuild and pastebinit
<xnox> yolanda: cause "ac_nonexistant.h" is usually a red-herring, it's used intentionally by autoconf to test non-existing headers =)
<yolanda> xnox, seems that cannot find any header
<yolanda> let me paste the log
<xnox> yolanda: e.g. in http://people.debian.org/~doko/logs/arm64-20131023/logs/buildlog_ubuntu-trusty-arm64.rtmidi_2.0.1~ds0-3_FAILEDTOBUILD.txt the actual error is:
<xnox> checking build system type... Invalid configuration `aarch64-linux-gnu': machine `aarch64' not recognized
<xnox> configure: error: /bin/bash config/config.sub aarch64-linux-gnu failed
<xnox> after that it just does "cat" of config.log which has all internal details of what configure script did.
<infinity> So, just a simple config.{sub,guess} update.
<xnox> correct.
<infinity> (Please use dh_autotools-dev)
<xnox> infinity: snapping my answers =)
<infinity> xnox: I don't board for 3 minutes, I need something to occupy my time. :)
<xnox> infinity: =))))
<yolanda> xnox http://paste.ubuntu.com/6436923/
<infinity> Missing build-dep.
<infinity> Though, that seems hard, given that dpkg provides an install-info binary...
<jamespage> smoser, utlemming: are you OK with https://code.launchpad.net/~med/ubuntu-seeds/sosreport/+merge/179485 ?
<yolanda> inifinit, i double checked and i have that install-info package installed
<yolanda> infinity ^
<cjwatson> You may have but it's not in your build-deps
<cjwatson> dpkg's version is in /usr/sbin/install-info so not on the default PATH for a package build; TBH trying to detect install-info in configure seems silly anyway
<cjwatson> I guess it's using it in its "make install"
<cjwatson> It's probably simplest to add a build-dep on install-info and move on
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dobey> seb128: hey. sorry. was on vacation last week.
<seb128> dobey, hey! oh, nice, I hope you had fun ;-)
<tseliot> pitti: can you approve the binaries for nvidia-331 and nvidia-331-updates in NEW, please?
<dobey> not as much as i wanted to, but it was ok :)
<pitti> tseliot: done
<tseliot> pitti: great, thanks!
<xnox> doko: is it ok if I re-introduce arm-linux-gnueabihf-gcc-4.6 into universe? it's still needed for ubuntu-touch development at the moment.
<seb128> tseliot, hey, do you know if there is any known bug with nvidia drivers' xrandr support in 13.10?
<seb128> tseliot, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1224254
<ubottu> Ubuntu bug 1224254 in gnome-settings-daemon (Ubuntu) "xrandr Xerrors with the nvidia binary drivers" [Medium,Confirmed]
<seb128> tseliot, not sure where to reassign? nvidia-drivers?
<doko> xnox, 4.6, are you joking?
<xnox> doko: goldfish 3.4 kernels misscompile with 4.7 and FTBFS with 4.8. =/
<xnox> doko: $ apt-cache showsrc linux-goldfish | grep gcc-4.6
<tseliot> seb128: let me check
<rsalveti> Mirv: https://code.launchpad.net/~rsalveti/ubuntu/trusty/qtbase-opensource-src/android-emulator-workaround/+merge/195622 mind reviewing it?
<rsalveti> Mirv: needed to get Qt working with the android emulator
<seb128> tseliot, thanks
<tseliot> seb128: yes, that happens with hybrid graphics. It's a bug in either nvidia or in the modesettings driver
<seb128> tseliot, can you reassign/add a comment?
<tseliot> seb128: sure
<seb128> tseliot, thanks
<doko> xnox, which kernel version is this?
<xnox> doko: goldfish is 3.4 but has plenty of emulator devices written by google / non-mainline
<xnox> doko: grouper, manta, maguro, goldfish are all compiled with gcc-4.6. mako is the only touch kernel compiled with 4.7.
<slangasek> apachelogger: yep, looks sane
<xnox> doko: see https://bugs.launchpad.net/ubuntu/+source/linux-goldfish/+bug/1236444
<ubottu> Ubuntu bug 1236444 in linux-goldfish (Ubuntu Saucy) "kernel panic" [Undecided,Fix released]
<xnox> which was "fixed" by compiling with 4.6.
<jamespage> xnox, just love that kinda fix
<jamespage> :-)
<xnox> jamespage: the other day i was thinking to abuse multiple-tarballs of 3.0 formats and make an "automake-all" package which builds all automakes from 1.4 -> 1.14
<rbasak> doko: please could you triage bug 1252290? I don't know why you temporarily demoted tomcat7 so not sure how to deal with this one.
<ubottu> bug 1252290 in tomcat7 (Ubuntu) "tomcat7 is disabled in the trusty server seeds starting from 20131115.1" [Undecided,New] https://launchpad.net/bugs/1252290
<seb128> dholbach, what's the website you use again to know what packages you sponsored for somebody?
<dholbach> seb128, http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi - but it's down with the rest of alioth
<xnox> seb128: it's linked of qa.ubuntuwire.com (at the bottom)
<seb128> dholbach, oh right, thanks anyway
<seb128> xnox, thanks
<dholbach> seb128, here's what mitya57 suggested to do: http://paste.ubuntu.com/6416445/
<orbisvicis> i really thought they'd have alioth back up after this weekend...
<xnox> orbisvicis: i'm wathcing #alioth on OFTC, where nagios says, it's down.
<seb128> dholbach, danke
<orbisvicis> if I want to revert a particular commit from an (ubuntu) source package maintained at alioth, would it be possible. Does ubuntu mirror anything?
<xnox> orbisvicis: ..... all debian/ubuntu packages can be fetched with: pull-debian-source / pull-lp-source respectively and one can do anything to them....
<xnox> orbisvicis: if you know changes that you want to revert, that's easy to do.
<xnox> orbisvicis: there are no mirrors.
<orbisvicis> xnox: i don't know the commit in particular, but it is either fully upstream (which is maintained at git.debian.org [alioth]), or includes changes to the debian/ directory. Either case... pull-lp-source wouldn't track such commits?
<xnox> ogasawara: pull-*-source download latest debian .src package.
<xnox> ogasawara: unping.
<Laney> You get the latest thing in the archive, but nothing from the vcs.
<xnox> orbisvicis:  pull-*-source download latest debian .src package. Not vcs history.
<Laney> If there's history or new things there
<xnox> orbisvicis: but e.g. if it's an individual patch under debian/patches, it's easy to revert.
<xnox> orbisvicis: or you can look at commit-diff mailing lists if there is one for repository in question.
<orbisvicis> xnox: that's an idea, thanks. I'
<orbisvicis> ll give that a shot later
<stokachu> barry: you seen this project yet : https://bitbucket.org/tpn/pyparallel/
<stokachu> barry: http://vimeo.com/79539317
<orbisvicis> I have a build failure I can't figure out: http://lpaste.net/3009038909163175936
<orbisvicis> any other command in override_dh_auto_test works fine, and in the c10shell hook, I can run "xvfb-run -a dh_auto_test" without any problems
<orbisvicis> as well as make -f debian/rules override_dh_auto_test
<mathfreak_> Hello. Is there a video stream for UDS I can watch?
<Ampelbein> mathfreak_: The sessions take place in IRC and google hangouts (I think), just click the link on summit.ubuntu.com
<mathfreak_> Thanks!
<orbisvicis> think I figured it out... xvfb is automatically started once installed..?
<sergiusens> jamesh, hey, wrt to go-dbus, how about making the trunk series point to your trunk branch?
<barry> stokachu: i haven't watched the latest video yet, but i was at trent's talk at pycon and i'm following the mlist thread.  pretty cool and crazy stuff :)
<stokachu> barry: yea man pretty interesting
<allstarsnorks2> Hi guys]
<jkitchen> hi
<allstarsnorks2> can I talk about issues with my Ubuntu build (I used Ubuntu  Builder)
<jcastro> hey ogra_
<ogra_> yo
<jcastro> in the spirit of your blog post maybe there's room at UDS for a session on the update thing?
<allstarsnorks2> I'm having problems with my build of Ubuntu
<jcastro> IMO I bet the phased updates handle like 90% of what they're trying to avoid
<ogra_> jcastro, sounds good, think we can get clem to participate _
<ogra_> ?
<jcastro> if he's interested, sure, gotta start somewhere!
<ogra_> just having a session wont hellp if not the right people are in it
<jcastro> yeah, I mean, maybe it's something we do later or something
<jcastro> I just wanted to bring up that UDS is here and we've got the right people in the right virtual rooms
<allstarsnorks2> I'm currently running my build of Ubuntu 13.04. But instead of the XFCE Desktop Manager I wanted to see, I get Busybox.
<tarpman> allstarsnorks2: hi! I'm not sure, but ubuntu-builder seems to be a separate project, so maybe you'd have more luck reporting your problem to its developers... they have a bug tracker is on google code: https://code.google.com/p/ubuntu-builder/issues/list
<tarpman> allstarsnorks2: in fact https://code.google.com/p/ubuntu-builder/issues/detail?id=52 sounds similar to what you wrote above
<allstarsnorks2> Made a bug report
<molgrum> is unity development using this channel?
<ogra_> there is #ubuntu-unity i think
<rsalveti> xnox: when testing the emulator, do you remember if it was also stuck sometimes? quite frequently it gets to a point where I cannot start any other program, like top
<rsalveti> same kernel and emulator works fine with android, just wonder if something we might be doing or missing
 * ScottK waves to ogra_.
<ScottK> I guess it's been a 'fun' day.
 * ogra_ wavws back to ScottK 
<ogra_> it has !
<ogra_> :)
<ScottK> FWIW, I think Mint's default policy on updates makes it unsuitable for casual users, but that's just me.
<ogra_> well, they claim the updates make it unstable, if thats true there is clearly something to do on our side
<ogra_> (in fact they show you a scary dialog that points to "may harm your system" security updates, i think that could even be worse than suppressing them ... teaching people that security adds instability)
<stgraber> ogra_: well, all of the systems I manage (around 300 containers, 50 or so servers and a dozen desktops) are configured to apply any security and bugfix update automatically every hour (thanks to unattended-upgrade). I have seen breakage but nothing that we didn't fix immediately and nothing that could have really been prevented (the last in date being procps failing to upgrade in containers, requiring manual action to resolve...)
<ogra_> stgraber, right, i'm not really sure from when this Mint policy comes though ... we might have done worse in the past, might have burned them and now they are scared
<ogra_> would be good to hear a clear word about the reasons really
<tarpman> in the past linuxmint achieved some customizations by overwriting or editing dpkg-owned files in place without creating derived packages or even diverting... so installing updated packages from ubuntu would undo their changes
<tarpman> I don't have a linuxmint install handy, but glancing quickly at e.g. http://packages.linuxmint.com/pool/main/m/mintsystem/mintsystem_7.9.0.dsc it seems to still do the same sort of thing :|
<crhrabal> anyone willing to sponsor this for me:  https://bugs.launchpad.net/debian/+source/apt/+bug/1206047
<ubottu> Ubuntu bug 1206047 in apt (Debian) "typo? in /etc/cron.daily/apt : MinAgeSec variable does not exist" [Undecided,New]
<ogra_> tarpman, oh my
<crhrabal> hey can someone review my merge request:  https://code.launchpad.net/~tjguthrie4600/ubuntu/trusty/apt/bug-1206047/+merge/195553
#ubuntu-devel 2013-11-19
<stgraber> ogra_: hey, you're on slashdot now ;)
<ogra_> yep, just linked my blog there
<mdeslaur> ogra_: dude, rainbows and unicorns from now on :)
<ogra_> haha
<slangasek> I personally don't want rainbows on my computer
<StevenK> slangasek: But you don't object to unicorns?
<mdeslaur> slangasek: that's ok, rainbows are level 5, so they don't get installed by default
<gaughen> slangasek, I missed a rainbow and unicorn discussion? I'm so sneaking a rainbow onto your laptop next time I see you.
<slangasek> heh
<Mirv> rsalveti: ok (for the qtbase patch)
<pitti> Good morning
<arun_> Hello to the devs
<arun_> and the lurks xD
<sabgenton> are the trusty builds usable at the moment (fun enough)
<sabgenton> ?
<zyga> good morning
<pete-woods> didrocks: good morning! If I want to land a new(ish) package (https://launchpad.net/unity-voice) are you still the go-to guy?
<didrocks> pete-woods: yeah, please get a landing ask added for tracking it (with a rationale ;))
<didrocks> pete-woods: and then, we'll take care of it
<pete-woods> didrocks: is that in the spreadsheet thingy?
<didrocks> pete-woods: right!
<pete-woods> okay, thanks!
<didrocks> yw ;)
<pete-woods> hmm, no write permissions, manager get!
<didrocks> pete-woods: time to make them working! :)
<xnox> rsalveti: yes it does. At the moment apart from limited RAM, it also limits available heap which may need increasing. I didn't figure out how to "trigger" stuck or what is causing it.
<tseliot> pitti: hey, I've just uploaded nvidia-settings, as you requested, but it ended up in NEW
<sveinse> Is there a one-line tool to install the build depends from the list in debian/control ?
<pitti> tseliot: ah, so it's possible to make them versionless?
<tseliot> pitti: yep. If there are compatibility issues, I'll just patch the code. I did it in the past
<pitti> tseliot: nice! so this needs to C:/R:/P: the old versioned ones until after 14.04
<pitti> tseliot: ah, I guess we still need transitional packages as well, but fortunately we can drop them all in some 5 months
<tseliot> pitti: yes, the transitional packages are there and the package also C:/R:/P: the nvidia-settings-binary virtual package
<pitti> tseliot: after that we'll remove nvidia-settings-* sources, right?
<tseliot> pitti: that's the hope
<pitti> tseliot: so glad about dropping python-gtk2 :) (what does the UI use? is that C?)
<pitti> tseliot: would you mind fixing the package descriptions for the transitional packages?
<pitti> tseliot: +Package: nvidia-settings-319-updates
<tseliot> pitti: nvidia-settings is C and GTK+ (2)
<pitti> +Description: Transitional package for nvidia-settings-319-updates
<pitti> tseliot: it should be a transitional package for nvidia-settings, i. e. please specify the "target" package name, not the package's own name
<pitti> (just a nitpick)
<pitti> tseliot: and we need one for -310 as well
<pitti> (two, for -updates)
<pitti> tseliot: I guess you can probably drop the control.in magic then (not relevant for NEWing, just jumped my eye)
<tseliot> pitti: and for nvidia-settings-313-updates, nvidia-settings-experimental-304 and nvidia-settings-updates too, I assume
<pitti> tseliot: ah, I don't see these in the trusty source lists, but they might be in precise or PPAs?
<tseliot> pitti: definitely in precise. I can see them in trusty if I call apt-cache search nvidia-settings
<pitti> tseliot: looks good otherwise; shall I reject and you reupload with the transitional fixes?
<tseliot> pitti: yes, please reject
<pitti> tseliot: done
<tseliot> pitti: would something like this be ok (I'll drop the control.in in a later release)? http://paste.ubuntu.com/6442329/
<pitti> tseliot: LGTM
<tseliot> pitti: ok, let me reupload
<pitti> tseliot: these old versions all provide nvidia-settings-binary, right?
<tseliot> pitti: I think so but let me check
<pitti> tseliot: e. g. nvidia-settings-experimental-304 doesn't
<tseliot> pitti: it's a transitional package
<pitti> tseliot: so that needs an explicit C/R
<pitti> ah
<pitti> indeed, to nvidia-settings-304-updates
<pitti> tseliot: ok, sorry for the noise
<tseliot> pitti: all the nvidia-settings packages in trusty http://paste.ubuntu.com/6442345/
<tseliot> everything seems ok
<tseliot> pitti: it's in new again
<pitti> tseliot: splendid, thanks! accepted
<tseliot> pitti: thanks!
<seb128> Laney, mardy: I tried e-d-s 3.10 from https://launchpad.net/~laney/+archive/gnome-transition/ with uoa, that doesn't work nicely :/
<seb128> Laney, mardy: the first thing that happens after adding a google account is a notification saying that the account has been desactivated and that you need to grant access again ... which seems to happen when you start evolution as well
<seb128> Laney, mardy: I never managed to have my calendar working either, it's showing in evolution but stucked on "loading" and never loading any content, the indicator is empty as well
<mardy> seb128: so, I think that the first issue is actually the correct behaviour: the first time you use EDS, you need to authorize it
<mardy> seb128: because it's using its own application key for Oauth
<seb128> mardy, the UI saying that your account has been desactived, when you just added it, feels weird
<seb128> could we serialize ask for it before ending the account adding?
<mardy> seb128: mmm... are you sure? It should just say that it needs to be authorized
<mardy> seb128: that would be nice
<mardy> seb128: yes, I think we could do that
<Laney> yeah the calendar doesn't work for me either
<Laney> email does though, which is an improvement on before
<mardy> seb128: can you please file a couple of bugs?
<seb128> mardy, sure, on what component? uoa for the UI/workflow one? e-d-s upstream for the calendar?
<mardy> seb128: gnome-control-center-signon for the UI, EDS for the calendar
<mardy> seb128: BTW, is there something broken with autolanding? In the last few days I updated a few projects, got the new code to trunk, but I cannot find any new packages in the archives
<mardy> seb128: like this one: https://code.launchpad.net/account-plugins
<mardy> (it adds Windows Live support to e-d-s)
<Saviq> slangasek, hey, just noticed one, potentially easy fix for cross-building, but I still can't wrap my head around what needs to be done there ;)
<seb128> mardy, thanks
<Saviq> slangasek, unity8 depends on qt5-default, which provides /usr/lib/arm-linux-gnueabihf/qtchooser/default.conf
<seb128> mardy, the notification says that "the application no longer has access to..." (just checked the wording), which is weird when you just created the account
<Saviq> slangasek, but for the cross-build to work, it should install qt5-default:amd64 instead, so that it provides
<Saviq> /usr/lib/x86_64-linux-gnu/qtchooser/default.conf
<seb128> mardy, @landings: they stopped happening automatically, somebody needs to do a landing ask nowadays ... they did that to limit regressions because saucy and it's still the rule
<seb128> mardy, you need an entry on https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1
<Saviq> slangasek, but qt5-default:amd64 pulls in qtbase5-dev:amd64, which conflicts with otherwise-needed qtbase5-dev:armhf
<Saviq> slangasek, so what do we do for qt5-default:amd64 to be pulled in, but for it not to be pulling in qt5base-dev:amd64?
<mardy> seb128: mmm... will it be forever like this, or will landings return automatic soon?
<xnox> Saviq: i mangled local config files for qt to make it "work"  thus avoiding installing qt5-default package at all.
<xnox> (well qmake et al)
<seb128> mardy, they are redesign the system, it's not going back to full automatic but it should be light way to ask for landing
<Saviq> xnox, well, sure, it's as easy as exporting QT_SELECT
<seb128> mardy, they idea is to control better what is landing and when so they can keep touch images under control
<xnox> Saviq: and CMake needs fixes to find correct multi-arch paths, which I should really fix up and upload into archive.
<Saviq> xnox, I recently sent a unity8-cross-build-recap to slangasek, let me fwd it to you
<mardy> seb128: OK, thanks, I'll request access to the document then
<xnox> Saviq: i think you can get away with Build-Depends: qt5-defaults:any
<seb128> mardy, thanks
<Saviq> xnox, can I? that might pull in :amd64, sure, but then would pull qtbase5-dev:amd64 as well
<Saviq> xnox, when we need :armhf for that
<xnox> Saviq: you cannot specify ":armhf", but you can specify "qtbase5-dev" as a build-dep.
<mardy> seb128: actually, to whom should I request access to edit this document?
<xnox> Saviq: hm, maybe i got this wrong. let me look at the actual packages.
<Saviq> xnox, sure, we do already, but how will that help with qt5-default:amd64 pulling qtbase5-dev:amd64?
<seb128> mardy, the managers and techleads should have access ... so ask your manager, or just go ask on #ubuntu-ci-eng if you can get write rights (that's the channel for the CI work)
<xnox> Saviq: wait, can you not instead of qt5-default build-depend on: qtbase5-dev-tools:native, qtbase5-dev ?
<xnox> Saviq: with appropriate config, cause it's the qtbase5-dev-tools that provide the "moc" utility.
<Saviq> xnox, you tell me ;)
<Saviq> xnox, I need moc, qdbusxml2cpp at least
<xnox> Saviq: imho qt5-default package is evil, as it's not co-installable for cross-compilation, nor co-installable for qt4/qt5 compilations.
<Saviq> xnox, qt5-default is just the easiest, 'cause then I don't need to hunt for the binary
<xnox> Saviq: =)
<xnox> Saviq: yeah, so qtbase5-dev-tools has syncqt, uic, moc, qdbusxml2cpp qdbuscpp2xml rcc qdoc
<Saviq> xnox, seems to be coinstallable for cross-compilation at least
<xnox> Saviq: well at one point in time it had conflicts. E.g. sudo apt-get install qt5-qmake:amd64 qt5-qmake:armhf, conflict with each other.
<Saviq> xnox, the only thing that conflicted now for me was qtbase5-dev:armhf and :amd64
<Saviq> xnox, biab, otp
<xnox> Saviq: for cross, one should build-depend on dpkg-cross and use the CMake toolchain file /etc/dpkg-cross/cmake/CMakeCross.txt
<xnox> Saviq: which actually finds the correct pkg-config =)
<xnox> Saviq: and corrects library search paths.
<Saviq> xnox, that's new :)
<xnox> Saviq: that has been available from way before this new thing MultiArchCross.cmake
<xnox> Saviq: I guess the two should merge, and it would be nice for upstream to ship that file.
<xnox> Saviq: where are your sources which I can play around with? or is it pure unity8 src package as in the archive at the moment?
<Saviq> xnox, lp:unity8 yeah
<Saviq> xnox, everything else that was needed is in my email
<xnox> Saviq: gotcha.
<xnox> Saviq: here is my poor mans solution to cross-compile https://wiki.ubuntu.com/Touch/CrossCompile
<xnox> Saviq: if one is using chroot, one can avoid co-installing libapparmor1 for example.
<Saviq> xnox, oh yeah I'm doing sbuild of course
<xnox> cool =)
 * xnox waiting for mk-sbuild --target=armhf trusty to complete
<Saviq> xnox, I wonder, how can we make CMAKE_TOOLCHAIN_FILE=/etc/dpkg-cross/cmake/CMakeCross.txt more automagic?
<geser> ogra_: I hope you know what you have started with your mail to the ubuntu-devel ML about Mint: http://www.golem.de/news/sicherheit-mit-linux-mint-wuerde-ich-kein-onlinebanking-machen-1311-102830.html
<ogra_> geser, no,  i didnt notice that i'm standing in the middle of a shitstorm since two days :P
<xnox> Saviq: debhelper already does many magic stuff for cross-case, so dh can be taught to add that. As long as it works for many / most cmake packages.
<xnox> Saviq: but it needs an extra build-dep. Not sure if dpkg-cross is build-essential enough in cross-cases.
<ogra_> geser, sadly golem refuses to also link my response to their article it seems http://ograblog.wordpress.com/2013/11/18/lots-of-canonical-in-my-mouth/
<ogra_> geser, like omgubuntu, phronix or other news sites do ... http://news.softpedia.com/news/Ubuntu-Developer-Says-Mint-Controversy-Might-Help-Them-Fix-the-Security-Updates-Problem-401422.shtml is the only one that picked it up ...
<highvoltage> that whole issue is such a nontroversy. any rational person would always agree with ogra_ no matter what he says.
<ogra_> thanks :)
<seb128> ogra_, ignore the trolls, that one is not even a good troll ;-)
<ogra_> seb128, well, what bothers me is that news sites i used trust suddenly seem to lose all objectivity and refuse the opportunity to to state my opinion even though they report about me ... (golem and heise are two i regulary read, heise hasnt picked up on it yet, but golems ignorance towards me is pretty disappointing)
<seb128> ogra_, having a good troll probably bring them more readers :/
<ogra_> definitely
<ogra_> i totally understand the intend and process ... but it would still be nicer if they could also show my POV
<highvoltage> ogra_: if they twist your words to mean something completely different to what you said then their intent was definiely not in good spirit
<ogra_> no, indeed not, but pushing an update with "Canonicasl developer responded" would at least give them another few clicks ... and at least pretend some objectivity
<sladen> ogra_: s/maintained one for/maintained one of/
<xnox> ogra_: I only read BBC News and New York Times. Neither of which are yet to miss-quote you =)
<ogra_> xnox, damn ... so much about my career in the TV ad business ... still not enough popularity
<sladen> now where's a link to those Canonical TV ads when you need one
<ogra_> lol
<ogra_> sladen, thanks, fixed..  btw
<Saviq> xnox, if you manage to reduce the steps needed to cross-build u8, please let me know :)
<rsalveti> xnox: right, I'm trying to disable a few services to see what is causing it, at least to isolate it a bit more
<rsalveti> Mirv: thanks
<rsalveti> Mirv: I can sponsor the upload, but need to check with the landing team
<rsalveti> seems xnox just uploaded it, so cool
<rsalveti> xnox: did you coordinate the landing with the landing team?
<rsalveti> xnox: as I know they were working on landing mir and a few other big blocks yesterday
<Mirv> rsalveti: yeah, it got uploaded already
<Mirv> it probably flew past the landing chart as such
<slangasek> xnox: hi, coming to http://summit.ubuntu.com/uds-1311/meeting/22028/core-1311-dmraid2mdadm/ ?
<xnox> slangasek: yes. it looks like i'll have to setup the hangout?
<rsalveti> Mirv: right, well, it's already in, so let's hope it'll not cause any issue :-)
<slangasek> xnox: no, it's set up and waiting for you
<xnox> slangasek: one hour too early?
<slangasek> orly
 * slangasek checks his clock
<slangasek> oh hah, plenaries this hour
<seb128> right
<seb128> slangasek, you almost scared me for a minute there ;-)
<slangasek> ok, nevermind then :-)
<xnox> slangasek: yeah, i think summit should "pre-star" the plenaries.
<xnox> for everyone.
<arges> cjwatson: hey. I know you spoke with jpds about this already. would you like me to handle the SRU for bug 901700? thanks
<ubottu> bug 901700 in netcfg (Ubuntu Precise) "netcfg segfauts when preseeding 12.04 LTS" [High,Triaged] https://launchpad.net/bugs/901700
<cjwatson> arges: Oh, if you like and if you can readily test it, I certainly wouldn't object to having it taken off my hands :-)
<arges> cjwatson: sure, I'll handle it then. : )
<cjwatson> Brilliant, thanks
<seb128> mardy, https://bugs.launchpad.net/ubuntu/+source/gnome-control-center-signon/+bug/1252751
<ubottu> Ubuntu bug 1252751 in gnome-control-center-signon (Ubuntu) "when adding an account, should register apps as well" [Undecided,New]
<seb128> mardy, https://bugzilla.gnome.org/show_bug.cgi?id=712687
<ubottu> Gnome bug 712687 in Calendar "Ubuntu online accounts support doesn't work with calendars" [Normal,Unconfirmed]
<seb128> Laney, ^
<mardy> seb128: thanks!
<Laney> cheers
<Laney> seb128: maybe we should leave it off
<seb128> Laney, yeah, but I still would like to see it fixed before the LTS...
<Laney> indeed
<roaksoax> apw: ping
<roaksoax> apw: do you maintain avahi?
<seb128> roaksoax, I don't think we have an official avahi maintainer, it's mostly in low maintainance mode/maintained in Debian, why?
<apw> roaksoax, not especially, i have recently fixed it for kernel feature missmatches
<apw> roaksoax, need something?
<roaksoax> apw: I'm about to sponsor this http://people.canonical.com/~serge/avahi-nproc.debdiff
<roaksoax> seb128: ^^
<roaksoax> just wan't to make sure people is ok with us doing that
<apw> not an issue for me indeed
<roaksoax> since we need it sru'd into saucy
<roaksoax> apw: thanks!
<Laney> isi t upstreamed?
<seb128> roaksoax, ^ what Laney asked, we should have an upstream bug reference in the patch there
<Laney> patch headers ;-)
<roaksoax> hehe ok
<fishor> any devs for sound subsystem here? (pulseaudio/alsa) ... i tried to find some one upstream, but no answers for a week. Now to the issue: internal mic in my laptop has too match boost, if i set on on maximum noise will go to the capture limits.  It make troubles for VoIP apps. I can blacklist it in alsa driver and provide patch for it... but before i do it i would like to know if there other options
<bregma> should Trusty packages be using Standards-Version 3.9.5 now?
<mitya57> bregma: Yes, but keep in mind that a Lintian version with 3.9.5 support is not yet released.
<bregma> mitya57, upstream in Debian or here in Ubuntu?
 * bregma is used to lintian complaining about future Standards-Version in Ubuntu
<mitya57> Lintian is mostly in sync now.
<mitya57> So we'll quickly merge the new lintian when it's released.
 * mitya57 notices that the latest lintian FTBFS
<ev> heads up: we're going to be discussing how the CI engine is going to be rearchitected, starting in 10 minutes. If you'd like a speaking slot in the hangout, let me know.
<cjwatson> oww, now I have to rebase grub2/debian/patches/install_signed.patch across to a rewrite of grub-install in C
<cjwatson> I guess it'll be neater on the other side :-)
<ev> http://summit.ubuntu.com/uds-1311/meeting/22092/core-1311-ci-airline/ being the URL for that
<hero> hello
<hero> I get an error when trying to compile gtk3;
<hero>  could someone help ?
<hero> http://paste.ubuntu.com/6443915/
<vermahim> hi, i am using ubuntu 13.10, i am looking for a software(preferably small in terms of code) which is written(or majority of code) in C/C++, please help me out
<kenvandine> xnox, ping
<xnox> kenvandine: hi!
<kenvandine> boost1.54 is held in proposed because boost-mpi-source1.54 has depends binaries from boost1.54
<kenvandine> specific versions
<kenvandine>  libboost1.54-dev (= ${binary:Version}),
<kenvandine> xnox, i assume a no change upload would fix it
<xnox> vermahim: well, upstart for C, and unity8/mir e.g. C++.
<kenvandine> but that seems fragile...
<kenvandine> xnox, i see you recently touched it... so i pinged you :)
<xnox> kenvandine: we split boost packages into main and universe ones because of mpi. And it should alway be uploaded in a matching pair.
<kenvandine> ok, so that was expected :)
<xnox> kenvandine: if it's held up, then it was a mistake. sorry about that. Let me check.
<kenvandine> there was an upload yesterday
<kenvandine> doko did an upload
<xnox> kenvandine: and he should know better =)))))
<kenvandine> hehe :)
<cjwatson> yeah, looks like doko forgot about the split-source thing here
<xnox> kenvandine: i'll fix it.
<kenvandine> xnox, mind uploading a fix?
<kenvandine> thx!
<kenvandine> robru, ^^
<kenvandine> robru, once that is gets rhough, we'll be able to build that stack
<kenvandine> s/rhough/through/
<xnox> kenvandine: after the sessions end. I'll fix it. so you will have it today.
<kenvandine> thx
<robru> xnox, thanks for fixing boost
<robru> kenvandine, alright
<vermahim> xnox: please provide the link for unity8/mir
<vermahim> code
<xnox> vermahim: bzr branch lp:upstart; bzr branch lp:unity8; bzr branch lp:mir
<xnox> vermahim: or http://pad.lv/c/unity8 http://pad.lv/c/upstart http://pad.lv/c/mir
<slangasek> ScottK: hi, able to join us? https://plus.google.com/hangouts/_/72cpjem29pg1ifaht4etlvkqc0
<ScottK> slangasek: I thought the meeting was in like 10 minutes from now.
<slangasek> ScottK: hmm, nope :/
<ScottK> The time says 2013-11-19 19:05..20:00
<slangasek> ScottK: so the one big question we couldn't answer... you've said that qt5 alignment is "not an issue" for 14.04, just to confirm, that means Kubuntu is not moving to Qt5 this cycle, right?
<ScottK> Isn't that now?
<slangasek> ScottK: no, it's currently 20:50 UTC
<ScottK> Sigh.
<ScottK> We anticipate packaging some parts of KDE Frameworks 5 this cycle, but not doing any fundamental switching.
<slangasek> ok
<ScottK> I don't know what the upstream version requirement will be.
<ScottK> This is even less than we did for KDE 4 in Hardy.
 * slangasek nods
<infinity> ScottK: You actually remember hardy?
 * infinity barely remembers last month.
<ScottK> infinity: I have scars.
<lifeless> the halycon days
<ScottK> slangasek: I'm told (reading my backscroll) that 5.2 is what's needed for KF5.
<ScottK> So we want 5.2, but we wouldn't fall over dead if we didn't get it.
<slangasek> ScottK: ok - 5.2 is also what's targeted for the phone
<ScottK> I'm listening to the session now.  I didnt' get annoyed yet.
 * xnox giggles.
<xnox> ScottK: are you shipping Framework5 for 14.04?
<ScottK> xnox: Possibly some of it.
<ScottK> Beta versions.
<ScottK> We may just land them in backports to avoid having to be stuck with them.
<xnox> ScottK: i see, but to do that you'd want 5.2 to be in.
<ScottK> Yes.
<ScottK> So I think we agree on what version we want.
 * robru shakes fist at mterry!!!
<mterry> robru, :(  what did I do?
<robru> mterry, your merge *just* landed on unity-system-compositor, which conflicted with my own.
<mterry> robru, hah!  I win
<robru> mterry, jerk!
<mterry> robru, what are you doing in usc?   /me peeks
<robru> mterry, bad boost deps. https://code.launchpad.net/~robru/unity-system-compositor/drop-libboost-all-dev/+merge/195860
<robru> mterry, but then I also did wrap-and-sort and it made a big ugly diff that conflicted with your really badly
<mterry> robru, I see.  If what I'm looking at is right, please don't re-introduce xmir dep on u-s-c
<mterry> robru, I moved that to new tiny package ubuntu-desktop-mir
<robru> mterry, pushed a new commit, can you check it's sane?
<mterry> robru, what's the beef with libboost-all-dev?  Just that it's lazy?
<mterry> robru, yeah looks fine, thanks!
<mterry> robru, I guess I'll approve then
<robru> mterry, well it's explicitely forbidden from main, which means when we eventually converge this change will be a prerequisite of the MIR, however the reason it came up today is because there was a minor boost transition that caused this to fail, specifically because of the -all-dev
<jtaylor> were is the best place to ask about the vagrant cloud images?
<utlemming> jtaylor: here works...whats up?
<robru> mterry, thanks for the approve.
<jtaylor> using virtualbox as provider the /vagrat folder blocks forever with the saucy images
<jtaylor> precise images work
<utlemming> jtaylor: I have seen that happen from time to time, but haven't had a chance to dig on that. Can you file a bug against it with supporting evidence? i.e. strace cat /vagrant/foobar?
<jtaylor> utlemming: busy loop on getdents(...)
<jtaylor> against which package should I file it?
<utlemming> virtualbox itself...that is a problem with the the vfs that they present
<jtaylor> actually cating a file works
<jtaylor> but ls blocks
<utlemming> odd
<jtaylor> utlemming: bug 1252872
<ubottu> bug 1252872 in virtualbox (Ubuntu) "saucy vagrant image shared folder 'ls' blocks" [Undecided,New] https://launchpad.net/bugs/1252872
<utlemming> jtaylor: are you using our version of virtualbox or the one from upstream?
<jtaylor> packaged virtualbox
<jtaylor> 4.2.16-dfsg-3
<utlemming> it would be interesting  to find out if you were to user the upstream what happens
<jtaylor> I can try
<jtaylor> hm vagrant in saucy does not support vbox 4.3 :/
<jtaylor> but that should be fixed upstream
<jtaylor> utlemming: same with latest vbox 4.3
<utlemming> jtaylor: ack
<jtaylor> I'll use a raring image in the meantime then
<jtaylor> utlemming: trusty images have the same issue
<utlemming> lovely
<xnox> robru: i should have uploaded into archive, then mterry would conflict as well ;-)
<robru> xnox, hahaha. well it's merged now and building in PPA, should hit archive soon
<xnox> mterry: libboost-all-dev is (a) in universe (b) non-multiarch:sam (thus no cross-compilation) (c) causes un-neccesory FTBFS if boost is not in sync with boost-mpi-source (d) makes the build longer (e) causes the package not suitable for main inclusion.
<mterry> xnox, makes sense  :)
<xnox> =)
<RAOF> Bah!
<RAOF> vUDS hangouts on air tell me of all sorts of things that I could usefully have contributed to if they weren't on at 3am last night?
<slangasek> RAOF: that's ok, we gave you all the work items
<slangasek> I can haz system compositor?
<RAOF> Indeed.
<RAOF> That's *exactly*  what I'm listening to.
<slangasek> :-)
<RAOF> Yes, the plan is indeed to be able to run a Mir compositor in the initrd :)
<RAOF> Good, good. You've argued yourselves 'round to the correct solution.
<RAOF> Actually, we *do* have a partial Mir backend for plymouth.
<slangasek> ok, where is it?
<slangasek> I don't have anything that I can include in the plymouth package
<slangasek> I'd love to do that, but so far I've been told everything is proof of concept
<slangasek> as for including Mir in the initrd, the final conclusion of the session is that we'd rather not do any of the graphics stuff from the initrd, and just boot to the rootfs as fast as possible
 * RAOF goes hunting for plymouth backend
<infinity> slangasek: Does this mean we'll continue to have two different paths for encrypted root versus not?
<slangasek> infinity: for the nonce
<infinity> slangasek: I hate that the plymouth-in-initrd codepath is so poorly tested in contrast to the default.
<slangasek> no it's not
<RAOF> slangasek: https://code.launchpad.net/~rocket-scientists/plymouth/mir should work, I think.
<slangasek> it's the only path I test before upload :-P
<infinity> slangasek: Poorly exericed for corner cases that affect people who aren't Steve? :P
<slangasek> RAOF: are you willing to turn that into an MP on the package?
<infinity> exercised, too.
<RAOF> slangasek: Sure, in the near future.
<slangasek> RAOF: great :)
<slangasek> anyway, plymouth-in-initrd becomes even hairier if we start using a mir backend... because while plymouth goes away and releases the framebuffer after boot, the system compositor would not
<slangasek> at least, not by definition
<infinity> I'm sure this was all covered in the session, but won't bringing up Mir take even longer than the already irritatingly long process of bringing up plymouth on a kms framebuffer?
<slangasek> so then we either cope with never freeing the initramfs, which is a fair chunk of memory, or the system compositor needs to re-exec seamlessly
<RAOF> Yeah; we need to re-exec the system compositor.
<slangasek> infinity: "it depends"
<RAOF> That should fall out naturally from our other goals.
<slangasek> infinity: currently, waiting for the framebuffer device on Touch is probably slower
<slangasek> RAOF: right; but it needs to be implemented before we can change plymouth's backend
<RAOF> Indeed it does.
<slangasek> and I'm very enthusiastic about getting to that point, since it means we no longer have to kill plymouth when lightdm starts
<slangasek> and plymouth can continue to display/prompt as needed
<slangasek> yay compositing :)
<RAOF> :)
<RAOF> Ah, I love that bit of a UDS session. âSo, I think we know what needs to be doneâ¦ who's going to do it?â
<stgraber> that's usually the point at which we start throwing work items at everyone who should have been in the session and instead tried to escape it
<infinity> I guess I should show up to more sessions.
<sergiusens> slangasek, hey, this is the wrong channel; but can you do a review for me or forward me to someone friendly? http://mentors.debian.net/package/golang-gocheck-dev
<slangasek> hmm
<slangasek> I wonder if that's something doko would be comfortable reviewing?
<slangasek> afaik we don't have very strong policy around go packages yet, so there are probably only a handful of people who would feel comfortable reviewing - doko is one, the golang package maintainer is another
<sergiusens> slangasek, is that stapelberg?
<slangasek> sergiusens: yes
<sergiusens> makes sense, I used his dh-golang and followed his wiki :-)
<sergiusens> thanks
<sergiusens> I'll see how I can reach out to him
<infinity> If running it doesn't then proceed to go and download the actual package from an S3 bucket, you're miles ahead on quality from other Go packages I can mention...
<jkitchen> hahahaha
<slangasek> sergiusens: his email address is in the Maintainer: field :)
#ubuntu-devel 2013-11-20
<pitti> Good morning
<pitti> stgraber: what I didn't understand yet: why do we conceptually need a daemon for the cgroup management anyway? why can't this just be a library which does proper locking to avoid cgroup fs write conflicts?
<stgraber> pitti: because it's unsafe to allow a container to mount cgroupfs, so we want to let a container alter only a sub-section of the hierarchy
<pitti> stgraber: ah, so the daemon's API would always be "relative" to the calling cgroup?
<stgraber> a container wouldn't be able to access cgroupfs directly but would have access to the daemon's socket which will let it write only in its sub-section of the hierarchy
<stgraber> pitti: correct
<pitti> stgraber: thanks
<stgraber> so we can do any level of nesting and user switch (with userns) without ever having to grant access to cgroupfs and therefore preventing any of the containers from escaping their limits
<Noskcaj> Can someone look into removing rhythmbox-radio-browser? It is pretty much non-functions due to rhythmbox api changes
<asac> 10:40 < jibel> asac, confirmed: apt-get install libc6-amd64 && apt-get remove libc6-amd64
<asac> 10:40 < jibel> and get a broken system for free
<asac> 10:42 < asac> jibel: thats on i386?
<asac> 10:43 < jibel> asac, amd64 with i386 enabled
<asac> hmm... doko not around :)
<Laney> probably infinity
<jibel> asac, doko has issues with his provider this morning
<asac> infinity: ^ (in case you are in a eur zone)
<didrocks> asac: infinity is sick today
<Laney> I guess file a bug and assign him
<infinity> asac: There's already a bug for that.  I was just trying to think up a clever fix right now, while I can't sleep.
<infinity> (Not a new bug, it's been like this since precise, but it's very rare for people to install libc6:amd64 and libc6-amd64 on the same machine)
<didrocks> Laney: yeah, I guess you will volonteer in hosting vUDS session btw as I can't start anything on my machine now :p
 * ogra_ would blame the package that installs it ... 
<seb128> infinity, it was, until the emulator started pulling it in
<asac> infinity: right. i think for now didrocks just needs a good idea how to recover (e.g. what exactly is now wrong)
<seb128> ogra_, that's the android emulator :p
<ogra_> the emulator deps should just be fixed
<didrocks> asac: agreed ;)
<asac> infinity: maybe just unpack libc6:amd64 ?
<Laney> didrocks: have you /seen/ me try to use hangouts?
<ogra_> it cant even use any amd64 stuff ...
<seb128> didrocks: oh, so you did that to sneak off vUDS hosting!
<Laney> :P
<infinity> asac: What's wrong is that /lib64/ld-linux-x86-64.so.2 is gone.
<seb128> lol
<didrocks> seb128: clearly ;)
<seb128> Laney, man, you and hangouts don't get along for some reason ;-)
<infinity> asac: So no amd64 binaries will run.
<asac> yeah
<infinity> asac: Recreating the symlink from a rescue CD would do the trick.
<infinity> didrocks: ^
<didrocks> yeah, no /lib64/ld-2.17.so binary
<ogra_> infinity, whats wrong is that a package that can only make use of libc6-i386 pulls in libc6-amd64
<didrocks> infinity: the symlink is there, just not /lib64/ld-2.17.so
<infinity> didrocks: /lib/x86_64-linux-gnu/ld-2.17.so
<infinity> didrocks: The symlink should point to that.
<asac> i assume thats in libc6:amd64? so ifyou have that and can unpack it should be ther?
<didrocks> ah ok, so lrwxrwxrwx    1 root     root            10 Nov 20 09:41 /lib64/ld-linux-x86-64.so.2 -> ld-2.17.so
<didrocks> which points to /lib/x86_64-linux-gnu/ld-2.17.so
<didrocks> right?
<infinity> didrocks: No, just directly aim the symlink at /lib/x86_64-linux-gnu/ld-2.17.so
<didrocks> ok, trying that in my busybox
<infinity> didrocks: /lib64/ld-2.17.so is only in libc6-amd64
<didrocks> making sense
<infinity> ogra_: That makes no sense.  Why is an i386 package pulling in libc6-amd64?
<asac> infinity: android :)
<ogra_> infinity, thats what i'm saying
<didrocks> of course, I need to be root
<infinity> (Not saying there isn't a massive glibc bug here, but installing libc6-amd64:i386 on amd64 is never a desired result)
<didrocks> and can't in this / busybox
<didrocks> so needing to reboot in initrd busybox
<ogra_> infinity, its the android-emulator package apparently
<asac> http://paste.ubuntu.com/6447333/
<asac> thats the stuff in android-emulator
<infinity> asac: That doesn't explain why it's forcing this weird set of packages to be installed.  What are its deps?
<asac> infinity: it has emulator64 binaries in there
<infinity> Oh, it explicitly depends on libc6-amd64 ... FUN.
<asac> can the package say: libc6:amd64 | libc6-amd64 ?
 * ogra_ has never used the package, i build it from the tree ... which 
<asac> guess not :)
<ogra_> ... requires the i386 libs installed already
<infinity> xnox: Want to make android-emulator depend on libc6:amd64 and libstdc++6:amd64 instead, and just make it not work without multiarch?
<infinity> Oh, wait.  Can't do that.
<infinity> Grr.
<infinity> Of course, it could just be an amd64 package, period, which would solve the issue.
<infinity> Just make it not available on i386.
<seb128> heh, why so much hate for i386 users
<infinity> Or if it has i386 and amd64 bits, build one on one, one on the other, and have a metapackage that pulls in -i386 and -amd64 bits.
<infinity> pull-lp-source: Downloading android_20131120-0225.orig.tar.xz from archive.ubuntu.com (191.659 MiB)
<infinity> Gah.
<ogra_> dont cry ... that used to be 500M in the past
<infinity> I'm all for people reminding me that I have a glibc bug that really needs fixing, but I'm not sure this was the way to do it. :P
<infinity> Quite entertaining if we've been telling people to install this.
<ogra_> well ... https://wiki.ubuntu.com/Touch/Emulator
<infinity> Okay, so it's already arch-restricted to i386... Splitting it to an i386 and amd64 bit wouldn't be rocket science.  And we already seem to be assuming users of this will have multiarch enabled.
<ogra_> we only offer it in trusty
<asac> I am pretty sure its not rocket science, but I assume that the android build system will have to be taught to build things separated by archs :)
<ogra_> nah. that wouldnt work
<asac> I assume ricard tried to avoid carryuing a big delta there for the time being
<infinity> asac: No need to tell it to break things up.  Just find the i386 binaries and put them in emulator-i386, do the same for the amd64 binaries, and package it up.
<infinity> Aaand, it's an hour-long build.  This'll be fun.
<infinity> Oh well, can't sleep anyway with this cough.
<infinity> Oh, derp.  This means I'd have to build it twice, though.
<infinity> Once per arch.
<infinity> Oh, wait.  You *can* depend on foo:arch.  crossbuild-essential does it.
<asac> didrocks1: managed to get past the point of no command?
 * asac assumes that no news is good news for now
<didrocks1> asac: well, I need to create an usb stick
<infinity> Doing a test build of this blind change: http://paste.ubuntu.com/6447414/
<asac> nice one :)
<Laney> bahaha, I like that hack
<didrocks1> asac: that will teach me to not always have a root terminal openedâ¦
<didrocks1> (to start busybox as root)
<mlankhorst> sabdfl: hey since we now lack a TB, can you make a decision on the MRE's I requested on technical-boards@lists.ubuntu.com ? https://lists.ubuntu.com/archives/technical-board/2013-October/001737.html
<infinity> I'll see if I can fix the actual linker switcheroo mess in 2.18 (I was looking at that earlier anyway), but either way, we shouldn't be encouraging people to install the multilib stuff.
<didrocks1> asac: seb128: maybe one of you can annotate the wiki with those infos (to not install the emulator on amd64 for now)? ^
<infinity> mlankhorst: A one-time version bump like that isn't really a standing MRE that the TB should have to worry about anyway, the SRU team can probably take that in hand.
<didrocks1> especially if people wants to clean up their machine then :p
<mlankhorst> infinity: I just want to move things forward soon if possible. Pixman is the one I'm most worried about. But libdrm seems to require a bump every release, so it sort of would need a standing MRE. :P
<infinity> mlankhorst: Sure, libdrm could use a standing MRE (or, though the versions make it look like "micro" releases, they're clearly not, and it probably needs something more like the firefox exception), but it's never had one before, so we can live without for a bit.
<infinity> mlankhorst: Is this all well tested in a PPA somewhere?  Do you have a placeholder HWE SRU bug that you can attach tasks for all these packages to and detail the testing done and subscribe the SRU team?
<mlankhorst> infinity: libdrm is weird, most of the driver stuff is just a c wrapper for the kernel interface
<mlankhorst> https://launchpad.net/~ubuntu-x-swat/+archive/s-lts-backport
<Saviq> seb128, "don't uninstall libc6-amd64"? or "don't install libc6-amd64"?
<infinity> Saviq: Yes.
<infinity> Saviq: Don't install it, but if you have, uninstalling it is also dangerous.
<seb128> Saviq, don't uninstall it if you have it installed
<mlankhorst> I think I created a bug for the pointer barriers specifically, but I didn't make one for pixman and libdrm yet.
<Saviq> seb128, so I can still try the emulator on amd64, just never uninstall it? ;D
<mlankhorst> ppa with all components at https://launchpad.net/~ubuntu-x-swat/+archive/s-lts-backport
<seb128> Saviq, basically, or better wait for infinity to fix those stuff ;-)
<infinity> I wonder if I could work around this hackishly by providing a libc6-amd64 on amd64 that just Depends: libc6.
 * infinity shudders a bit at the ickiness of that.
<mlankhorst> infinity: or finally implement cross-arch depends. :P
<infinity> mlankhorst: If you could just do up a meta bug for "lts-s backports" and detail what needs review, and what's been tested and how, then we can point any discussion there.
<infinity> mlankhorst: cross-arch deps work.
<mlankhorst> ok
<mlankhorst> I think I will make the metabug the bug for pixman/libdrm backporting too
<infinity> mlankhorst: That doesn't solve this particular issue of people installing libc6-amd64:i386 on amd64.
<infinity> Which explodes hilariously.
<mlankhorst> why have that? o.O
<infinity> Maybe we just need a Multi-Arch: dont-even header.
<infinity> Package: libc6-amd64
<mlankhorst> I thought that was what the Architecture: field was for, just build it on amd64 only. :P
<infinity> Multi-Arch: hahahahano
<infinity> mlankhorst: Erm it's only built on i386.
<mlankhorst> oh
<infinity> mlankhorst: But then people install an i386 package that depends on it.
<infinity> On their amd64 system.
 * didrocks1 wonders why usb-creator doesn't want to finish the current usb stick creationâ¦ will go with dd if this continuesâ¦
<infinity> didrocks1: Just use dd.  usb-creator is a steaming heap of needs a lot of love.
<infinity> (I think there may even be a UDS session about that?)
<smb> infinity, was
<didrocks1> infinity: yeah, I can testify this right now :)
<infinity> Or was. :P
<infinity> smb: How did that go?
<smb> infinity, I think we use something different
<mlankhorst> oh found the pointer barriers bug https://bugs.launchpad.net/ubuntu/+source/x11proto-input/+bug/1242633
<ubottu> Ubuntu bug 1242633 in x11proto-input (Ubuntu) "unity pointer barriers sru bug" [High,In progress]
<pitti> dd wrapped in a GTK dialog?
<mlankhorst> I'll open a metabug
<infinity> pitti: Well, the reason for usb-creator (the only valid reason, other than the pretty GUI) is that it knew how to set up the weird partition scheme required for persistence.  dd alone can't pull that off.
<smb> infinity, Actually there seems to be a more interesting issue on the side about having something that works with uefi and secure boot but not wasting most of your usb key
<pitti> infinity: right, was mostly kidding
<smb> infinity, Plus I thought there was an issue at least with older bioses of not booting an iso fs on a usb key
<infinity> But for 99% of people who just want an installer USB key and don't give a crap about persistence, yeah, usb-creator really could just fork dd.
<pitti> I actually successfully used usb-creator in saucy still, it's sad that it broke down so quickly
<infinity> pitti: It's been broken for several releases, success rates seem to vary from person to person and moon phase.
<smb> amd64 being better that trying to do i386 images in my experience
 * infinity shields his eyes from all the code duplication he sees zipping past in this Android build log.
<infinity> LA LA LA, CAN'T SEE YOU, HANDWAVE, GOING FOR A DRINK.
<smb> Sadly coffee has not the desired effect... and at least its not ktb#1 time for me
<infinity> smb: Choice of beverage really doesn't matter to me right now.  I should be either asleep or at a doctor's office, and I'm neither, so I'm failing at life.
<smb> infinity, Yeah well, highly depends on your current location which often is hard to guess
<infinity> smb: Calgary.  I think.  It's a bit hazy.
<smb> infinity, That might be true now but was not last(?) week. Which could probably be part of the issue, too
<didrocks> phew
<didrocks> thanks infinity, asac (et jibel for testing in a vm)
<infinity> didrocks: All gooder?
<didrocks> yeah ;)
<infinity> I really need to come up with a clever fix for that.
<didrocks> the longest was to download/create this usb stickâ¦
<infinity> I was going to use dpkg diversions when I first found this issue in precise, but dpkg-divert had a bug that prevented it...
<didrocks> I'll build an initramfs dropping me in a busybox for next time :p
<infinity> That's now fixed, but it would break on upgrades FROM precise...
<infinity> So.  Whee.
<didrocks> infinity: oh? interesting
<infinity> Only mildly interesting.  Mostly just annoying.
<didrocks> (but, can be epic between the version without the fixed dpkg and then)
<infinity> I can either bury my head in the sand and pretend the bug doesn't exist until 14.10 and fix it with diversions when I can do it safely.  Or come up with a more clever hack to work around it now.
<infinity> And I think I almost mapped out a clever fix in my head about an hour before you broke your computer.
<infinity> But that could just be the drugs talking.
<infinity> I'll need to commit it to code when I'm more aware of my surroundings and see if I'm drunk.
<didrocks> infinity: heh, sounds like a good plan, meanwhile, le'ts put an info in the wiki for the emulator, as I guess it's the main case for people getting into that bug
<mlankhorst> infinity: https://bugs.launchpad.net/ubuntu/precise/+source/libdrm/+bug/1253041
<ubottu> Ubuntu bug 1253041 in libdrm (Ubuntu Precise) "lts-saucy enablement in precise" [High,In progress]
<infinity> didrocks: I might pull the emulator binaries from the archive for now.
 * infinity does that.
<infinity> Removing packages from trusty:
<infinity> 	android-emulator 20131120-0225-0ubuntu1 in trusty i386
<infinity> Comment: High chance of breaking amd64 systems
<infinity> Remove [y|N]? y
 * infinity waves bubye.
<infinity> If my test build goes okay, I'll upload that.
<asac> thx. let us know
<infinity> With a nasty side-effect that people who *did* install the broken version of the emulator might get libc6-amd64 autoremoved and land in your situation...
<infinity> What fun that will be.
<didrocks> infinity: TBH, I won't test you hack today :p
<seb128> infinity, asac, didrocks: since that was announced on the list (https://lists.launchpad.net/ubuntu-phone/msg05195.html) I guess we can count on quite some people installing/trying it... would be better to not autobrick their systems with the update (e.g maybe fix the libc side if we can before updating the emulator)
<didrocks> your*
<didrocks> right, I'm going to summarize what to do in case someone is broken?
<infinity> seb128: The libc fix will take some more thinking.
<seb128> didrocks, is that a question? yes please follow up on the list ;-)
<infinity> seb128: And people installing the emulator might be removing it too.  Which already puts them in this situation.
<infinity> (Granted, very few people also do autoremove religiously)
<asac> isnt update-manager doing autoremove?
<infinity> Oh, is it?  Fun.
<seb128> asac, not in normal update mode at least, maybe in dist-upgrader mode
<asac> not sure... asking :)
<infinity> I didn't *think* it did.
<asac> (i have to admit that i got stuck in old apt-get habits)
<didrocks> I did autoremove religiously, not sure if one of our tool is doing that :)
<asac> seb128: right. i think dist upgrading does autoremove
<asac> not normal upgrades
<asac> dont think thats better though ... just makes the support bomb more intense :)
<infinity> Nah, buys me time until April to fix it!
<asac> otoh, we can add arbitrary hackery to mitigate such issues in update-manager...
<infinity> (I'll make it a priority right after 2.18 is otherwise ready, unless the answer comes to me while I'm at the doctor's in the morning)
<tseliot> pitti: sorry to bother you again but the binaries for nvidia-graphics-drivers-304 and its -updates flavour are stuck in NEW (trusty)
<tseliot> pitti: they include the same changes that you approved in the 331 series
<pitti> tseliot: ah, the new libraries, yes; looking
<tseliot> thanks
<tseliot> pitti: thanks a lot!
<ahasenack> hi guys, I have a recipe (https://code.launchpad.net/~ahasenack/+recipe/juju-deployer-daily) that started failing to build on trusty,
<ahasenack>  dpkg-source -i -I -b recipe-{debupstream}+bzr{revno}-0~{revno:packaging}
<ahasenack> dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision
<ahasenack> but my packaging branch has source format "3.0 (quilt)"
<ahasenack> is this an artifact of how recipes are built in launchpad?
<ahasenack> the same package builds on saucy, for example
<ahasenack> maybe a flag was switched in trusty to make that a fatal error?
<infinity>   * Catch mismatches between version strings and format versions in
<infinity>     dpkg-source. Ensure that a 3.0 (quilt) package has a non-native version
<infinity>     and that a 3.0 (native) package has a native version. Closes: #700177
<infinity> ahasenack: New dpkg enforces this, yes.
<ahasenack> ok, so it looks like launchpad recipe builds will break if your package is 3.0 (quilt)?
<ahasenack> http://bazaar.launchpad.net/~ahasenack/juju-deployer/juju-deployer-packaging/view/head:/debian/source/format is what my recipe uses
<StevenK> You need pristine-tar information in the branch for the recipe to construct a tarball, otherwise it will override your recipe to 3.0 (native)
<ahasenack> https://launchpadlibrarian.net/156978348/buildlog.txt.gz buildlog
<ahasenack> StevenK: what's "pristine-tar information"?
<StevenK> ahasenack: pristine-tar allows you to regenerate any tarball you've made from the repository information, 'man pristine-tar'
<ahasenack> StevenK: but there is no tarball on my side, it's a launchpad recipe, it builds the package from branches
<infinity> StevenK: Oh, does pristine-tar actually allow recipes to DTRT here?  Nice.
<StevenK> infinity: Yes
<infinity> ahasenack: Yes, but pristin-tar is the glue that allows you to recreate the orig.tar.gz out of your branch.
<StevenK> infinity: Do you want to help ahasenack since it's like 2240
<ahasenack> infinity: and what do I do with it? I have to upload it to the ppa manually first, then recipes will work, or what's the idea?
<infinity> StevenK: Not really, it's 0440 here, and I'm sick. :P
<ahasenack> oh boy :)
<StevenK> Haha
<ahasenack> looks like you both need to be asleep
<ahasenack> infinity: that bug number from the changelog snippet you pasted seems wrong, btw, it's about "os-prober failed to detect both Windows bootable partition" ;)
<xnox> ahasenack: the answer to your troubles, is to modify the recipe version used for the package, such that it is a native one.
<infinity> ahasenack: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
<xnox> ahasenack: otherwise, you need original tarball, which you say you don't have.
<ubottu> Debian bug 700177 in dpkg-dev "dpkg-dev: please reject native/non-native version when building native/non-native source packages" [Wishlist,Fixed]
<ahasenack> infinity: ah, debian
<StevenK> xnox: He can recreate an orig tarball with pristine-tar
<ahasenack> xnox: it's a recipe build, I would think that LP would take care of it (generate the tarball)
<ahasenack> do you guys use launchpad recipes? Maybe I'm barking at the wrong tree
<xnox> StevenK: he wants to daily-build master crap no matter what it is, not generate orig tarball for each commit ;-)
<xnox> ahasenack: so in {debupstream}+bzr{revno}-0~{revno:packaging}, remove the "-" =)
<ahasenack> xnox: yeah, was going to paste
<ahasenack> {debupstream}+bzr{revno}~{revno:packaging} maybe
<ahasenack> or s/~/+/
<xnox> ahasenack: then your recipe will be native, no original tarball needed, and it will just build.
<ahasenack> will have to think about it
<xnox> ahasenack: that one will work too.
<infinity> Depends: libstdc++6:amd64 (>= 4.1.1), libc6 (>= 2.15), libc6:amd64 (>= 2.15), libgcc1 (>= 1:4.1.1), libgl1-mesa-glx, libstdc++6 (>= 4.6), libx11-6
 * ahasenack ponders upgrades and all that stuff
<infinity> I win.
<xnox> ahasenack: i think "+" will be better.
<ahasenack> yep
<ahasenack> xnox: thanks
<xnox> infinity: enlighten me about your winnings =)
<ahasenack> and lp will still add ~ubuntu<release-number> at the end
<xnox> yes
<ahasenack> ok, let's kick it
<ahasenack> thanks again
<infinity> xnox: Making your emulator stop pulling in libc6-amd64:i386
<xnox> infinity: patches welcome.
<xnox> infinity: what should I do? =)
<infinity> xnox: You can pull the patch from the archive shortly. :P
<xnox> infinity: ah, even better. thanks for that.
<infinity> Man, this source takes a while to re-pack on a rotary disk.
<xnox> =)
<infinity> xnox: http://paste.ubuntu.com/6447754/ FWIW.
<infinity> xnox: With bonus guilt-induced tech-debt swap.
<infinity> Also, I can't spell dirty.
 * infinity doesn't upload.
<arun> hello guys I had a question !!! should we ask any sort of permission on developing a distro based on UBuntu named as Obuntu under the support of Obuntu group ?
<infinity> arun: Yes.
<xnox> arun: yes, "*buntu" is protected.
<ogra_> infinity, your patch drops xz compression, doesnt it ?
<infinity> arun: https://forms.canonical.com/trademark/
<arun> Guys, where can we ask for it ?
<xnox> ogra_: xz is default. see changelog entry above.
<infinity> ogra_: Reading changelogs is hard?
<ogra_> bah, i only looked at the bottom :P
<xnox> arun: see link infinity pasted.
<infinity> xnox: Uploaded.
 * infinity is going to see if he can nap for a few minutes before coughing himself awake again.
<xnox> infinity: .... thanks. it doesn't help any other packages that build-depend on gcc-multilib though. Or would this be solved by builders having multiarch enabled?
<arun> and by the way , what is  loCo ?/
<infinity> xnox: There aren't many packages that actually end up depending on libc6-amd64/libc6-i386, but you're right, this won't help those that do.
<infinity> xnox: I still need to fix the libc bug that causes that situation to explode, but depending on biarch libs is generally wrong regardless, IMO.
<xnox> arun: LoCo = Local Community, i.e. local community groups representing ubuntu in their region.
<arun> xnox: oh
<xnox> arun: typically they are known and participate in the Ubuntu community and thus are registered with Ubuntu Project and receiving sponsorship (e.g. free CDs & marketing materials) to promote Ubuntu.
<ogra_> https://wiki.ubuntu.com/LoCoTeams
<arun> Guys , does Canonical feeds Ubuntu devs ???
<brendand> arun, we have to feed ourselves
<xnox> arun: there are girls here as well. and these sort of questions you are asking are not related to development of ubuntu core itself. Maybe you can take this conversation to #ubuntu instead?
<xnox> arun: i'm sure there are plenty of people who can answer these generic questions about Ubuntu Project.
<arun> brendand: oh ok
<arun> xnox: ok thanks a lot ; I think I went off topic
<arun> Guys, is Unity based on Gnome 3 ?
<mlankhorst> hmz
<mlankhorst> MismatchError: True != False
<mlankhorst> but that statement is true :o
 * jpds wonders why we have a super-old util-linux on Ubuntu.
<jpds> infinity, lamont: Oh, hi. :)
<mitya57> Hi, I see bug 1253003 in the sponsoring queue. Any hint why that has not been auto-synced yet?
<ubottu> bug 1253003 in Ubuntu "Sync wxwidgets3.0 3.0.0-1 (universe) from Debian sid (main)" [Undecided,New] https://launchpad.net/bugs/1253003
<mitya57> gilir: Hi, may I ask you to look at https://code.launchpad.net/~m-alaa8/ubuntu/saucy/pcmanfm/fix-for-993996/+merge/195625 please?
<pitti> $ LANG= bzr branch ubuntu:systemd-shim
<pitti> bzr: ERROR: Revision {package-import@ubuntu.com-20130502111419-gg4b0m966tgp1p72} ist nicht in Â»Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))Â« vorhanden.
<pitti> err, what does that want to tell me?
<pitti> any known workaround?
<pitti> err, neither LANG, LC_ALL, LANGUAGE help -- says something like "... revision ... isn't present in Graph.."
<seb128> pitti, it's telling you "stop using udd"?
<mdeslaur> lol
<seb128> dunno about the specific error though :/
<pitti> seb128: probably :/ I wanted to give it another try for developing some autopkgtests, but I guess I'll just go the classical way
<Laney> omg, a lesser spotted wednesday troll
<seb128> ups, did I troll again?
 * seb128 needs to stop that
<ogra_> yeah, not friday yet
<Laney> haha
<pitti> one of the few packages which don't have patches, and thus would be manageable with UDD>.
<ogra_> fix my firefox tooltip instead :P
<cjwatson> [New] wxwidgets3.0_3.0.0-1
<cjwatson> No previous publications in Ubuntu
<cjwatson> OK (Y/n)?  y
<cjwatson>  * Trying to add wxwidgets3.0 ...
<cjwatson> wxwidgets3.0_3.0.0-1 is trying to override modified binary wx-common_2.8.12.1-14ubuntu2.  OK (y/N)?  n
<cjwatson> mitya57: ^- that's why
<cjwatson> mitya57: somebody needs to work out if those two changes need to be forward-ported to 3.0
<mitya57> cjohnston: oh thanks, will reject the bug for now then
<mitya57> Bad xchat.
<cjwatson> I should tee the output of auto-sync to a file on people or something
<seb128> roaksoax, hallyn_: hey, did you guys upstream that avahi patch you uploaded to trusty?
<smoser> slangasek, around ?
<slangasek> smoser: vUDS
<smoser> would you think that bug 1235231 is fixable ?
<ubottu> bug 1235231 in plymouth (Ubuntu) "plymouth loses output to /dev/console (such as ci-info: messages)" [High,Confirmed] https://launchpad.net/bugs/1235231
<hallyn_> seb128: we could try submitting it to debian...  i'm not sure it's appropriate.  it's a workaround for lack of user namespaces, and i'm not very happy with it
<hallyn_> seb128: oh, actually no we can't submit it to debian really, bc it relies on upstart
<slangasek> smoser: what do you mean, "fixable"?  I already said in the bug log that the cloud images should just override plymouth to stop it from running
<seb128> hallyn_, hum, k, next time it would be nice to put those details in the patch header to make work easier for whoever is looking e.g at merging that package next
<hallyn_> agreed
<seb128> thanks
<smoser> slangasek, i just added a comment there.
<smoser> by "fixable" i meant "stop being broken".
<smoser> plymouth is explicitly "supposed" to replay content it captures. its a clear bug that it does not do that.
<hallyn_> seb128: sorry, it didn't occur to me yesterday that it depended on upstart.
<smoser> (as are most dataloss issues :)
<seb128> hallyn_, no problem, thanks for the reply to my questions!
<slangasek> smoser: don't count on a fix for that any time soon.  Workaround is known, and we don't have resources to fix all the plymouth issues any time soon
<smoser> ok. well, then i would appreciate your thoughts as to my comment 19 there, and i'll look to get this in sooner rather than later.
<slangasek> smoser: replied
<smoser> slangasek, yeah, but you didn't reply the way i wanted.
<smoser> i'd much rather have the disabler package close to plymouth, so that when/if a new upstart job is added its obvious it needs ot be fixed.
<slangasek> there aren't going to be more upstart jobs
<slangasek> and half those overrides are niceties
<pitti> ooooh! http://alioth.debian.org/ just came back
<tseliot> \o/
<mlankhorst> yay
<cjwatson> Yeah, it's on its way, I think they're still putting some pieces back together
<Laney> ssh vasks works, at least, although the filesystem doesn't seem (fully) restored
<cjwatson> Er
<cjwatson> vasks is going away
<cjwatson> It's being replaced by a new host
<roaksoax> seb128: i didn't yet.
<pitti> yeah, host key changed (understandably)
<pitti> Laney: moszumanska now
<cjwatson> I suggest waiting for an announcement from the alioth admins before pushing stuff
<Laney> ah
<Laney> I've been checking d-i-a
<Laney> no news of that there
<pitti> might still take a bit until it gets official, but I'm happy to see it alive again after two weeks
<shadeslayer> cjwatson: uhm, stupid question, there was this package which had a script to build your own ubuntu live cd ( not live-rootfs ), do you know which one it was?
<shadeslayer> oh
<shadeslayer> it *is* live-rootfs
<cjwatson> livecd-rootfs
<cjwatson> but ignore livecd.sh, use the live-build hooks there
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
<shadeslayer> *nod*
<smoser> mhall119, what circumstances make the 'Join hangout' link appear ?
<jcastro> I beleive the person who runs the session needs to provide summit with the link
<smoser> http://summit.ubuntu.com/uds-1311/meeting/22045/servercloud-1311-maas/ has hangout details, and i'm logged in, but id ont see it.
<smoser> ah. its there now.
<smoser> it must only appear after start of session (it should have a grace "join" period)
<mhall119> smoser: 1) it's within the slot's start & end times, 2) the user is logged in, 3) the user is marked as attending the UDS
<mhall119> also 4) you're not getting a stale page from the caching server sitting in front of summit.u.c
<smoser> mhall119, well can i suggest that '1' be tweaked to include 10 or 15 minutes prior ?
<slangasek> rbasak, smoser: do you want anyone from the server team to come to the Secure Boot session?
<smoser> is that now ?
<smoser> :-(
<mhall119> smoser: you can if you file a bug for it
<mhall119> lp:summit
<seb128> tjaalton, tseliot, mlankhorst, coming to the xorg for t vUDS session? https://plus.google.com/hangouts/_/7ecpjg4e7ibk4vghv8fkul3tt8?authuser=0
<smoser> k
<slangasek> smoser: yep
<smoser> k.
<seb128> RAOF, ^ up? or is it still night time for you?
<smoser> slangasek, joining
<smoser> slangasek, can you give me a link ?
<slangasek> https://plus.google.com/hangouts/_/72cpj2k5dn4bjr053d5ehn1lpo
<smoser> anyone interested, http://pad.ubuntu.com/lower-third
<smoser> thats my "howto" for vuds and lower third
<josepht> smoser++
<tedg> stgraber, I couldn't come to the Upstart session, but do you expect the cgroup to be created for pre-start or only when executing the job.
<stgraber> tedg: I think we decided to go with consistency with other limit stanzas, so pre-start would also be put in the cgroup
<tedg> stgraber, So then would pre-start be able to configure the cgroup?  i.e. this group can only use 100MB of RAM
<stgraber> tedg: yes but it shouldn't cgroup limits should be applied through the cgroup stanza
<tedg> stgraber, Ah, okay.  I thought the stanza only created, didn't realize the limits could be there.
<stgraber> anyway, I'm planning to send a mail to upstart-devel later today with the suggested implementation
<tedg> stgraber, K, I'll wait for that before I get confused :-)
<seb128> it seems that powerpc-porter is still down, do we have any alternative solution to debug ppc issues?
<cjwatson> I used the "machine in infinity's house" solution last time I needed it
<dholbach> jibel, congratulations! finally! :)
<pitti> jibel: oh, got your membership?
<highvoltage> tedg: it's ok, you can spawn your own upstart session :p
<ogra_> jibel, whee !
<seb128> jibel, congrats!
<seb128> cjwatson, thanks, we did that last time as well for indicators issues, might need to do it again...
<seb128> infinity, ^
<cjwatson> seb128: or you could get the package cross-building
<seb128> I guess that's an option, less easy to set up though
<tedg> highvoltage, I'm partially responsible for *everyone's* upstart session ;-)
<seb128> would be nice if we had a porter box available :/
<tedg> seb128, You can probably get a PlayStation 3 cheap :-)
<cjwatson> we desupported those rather a long time ago :)
<seb128> tedg, funny that you speak, the issues are indicators one, I could just get you to fix your stuff... ;-)
<seb128> tedg, if you buy a ps3 for that, fine by me :p
<tedg> seb128, Heh, it's a lot more than just indicators.  Webbrowser, upstart-app-launch, etc.
<ogra_> heh
<seb128> tedg, do we have an idea if that's a toolchain issue or what?
<seb128> cyphermox, ^
<tedg> It seems a lot of them are actually dependency waits.
<seb128> oh, indicators are failing tests
<tedg> So some false positive just looking at the icons.
<tedg> I'm curious if it's not starting the X wrapper or something like that.
<seb128> google test hiding the output sucks :/
<seb128> tedg, e.g https://launchpadlibrarian.net/156991211/buildlog_ubuntu-trusty-powerpc.dbus-test-runner_14.04.0%2B14.04.20131120-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> the log is pretty much useless
<Laney> blame automake not google
<seb128> https://launchpadlibrarian.net/156995004/buildlog_ubuntu-trusty-powerpc.hud_13.10.1%2B14.04.20131120-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> is interesting
<seb128> *** stack smashing detected ***
<tedg> Yeah, it is odd.
<tedg> Seems like a common thread is Python?
<seb128> I've seen similar stack smash errors in one of the indicators
<tedg> Some of the tests that use python was failing, and the dbusmock tests obviously use python.
<seb128> doko, ^ is there a known issue with python3 on ppc on trusty?
<tedg> *** stack smashing detected ***: python3 terminated
<doko> seb128, updated python3 yesterday, so it could be possible
<seb128> didrocks, cyphermox, tedg: when did those tests issues start?
<cyphermox> two or three days ago. I'm not sure
<cyphermox> I don't think this is python issues
<doko> python3 changed yesterday
<seb128> ok :/
<tedg> Not sure either.  I just updated dbus-test-runner to use dbus-mock, so we've started using more of it as a result.
<cyphermox> I'll get the logs shortly, there's a build running for powerpc now
<cyphermox> tedg: seb128: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5249058
<seb128> cyphermox, well, e.g https://launchpadlibrarian.net/156995004/buildlog_ubuntu-trusty-powerpc.hud_13.10.1%2B14.04.20131120-0ubuntu1_FAILEDTOBUILD.txt.gz has smashed stack python errors
<cyphermox> well, yeah, but that might well be something different
<cyphermox> I'd like to know for sure, and that we can get with full logs.
<marrabld> I have a few questions about packaging.  I used to package an App in my ppa.  But since Ubuntu moved where it keeps the QT libraries my recipes have failed for modern versions of Ubuntu.  So I have to take another look at my packaging scripts.  I am going to separate my packaging scripts from the code repo (currently in the same repo as the code).
<marrabld> So my first question is, should I put my debian directory in a separate branch and then get my recipe to merge the branches or should I put them in a separate repo.?
<seb128> cyphermox, tedg, doko: https://launchpadlibrarian.net/157024833/buildlog_ubuntu-trusty-powerpc.indicator-messages_13.10.1%2B14.04.20131120.0-0ubuntu2_FAILEDTOBUILD.txt.gz
<seb128> *** stack smashing detected ***
<seb128> seems like a ppc toolchain issue
<seb128> test-gactionmuxer is having the same problem than python
 * tedg blames the stack for allowing itself to get smashed
<tedg> Yeah, thinking so.
<tedg> Not sure what, I guess we'd need a valgrind run to get some clues on what is happening.
<seb128> doko, ^ did the ppc toolchain change recently? any idea about that?
<smoser> anyone interested, http://paste.ubuntu.com/6449132/
<smoser> thats a hacky script that reads a vuds link and makes nicely formated list of links to Hangout, Etherpad, IRC ...
<hikenboot> hello I have saucy and am wondering if there is packages for gmp mpfr and mpc (prepackaged version for this version of ubuntu)
<hikenboot> trying to consistently compile gcc correctly a package would be helpful
<jtaylor> hikenboot: sure all build depends of gcc are packaged
<jtaylor> apt-get build-dep gcc
<jtaylor> also gets you ppl cloog etc
<hikenboot> ah awsome ok didnt see that one coming but should have!
<cjwatson> well, "apt-get build-dep gcc-4.8" is more likely to be useful
<cjwatson> gcc -> just the defaults links
<jtaylor> right different source :/
<hikenboot> thanks a bunch..its really appreciated!
<pitti> jibel: how difficult is it to fix britney/the test scripts to run newly uploaded autopkgtests?
<pitti> jibel: e. g. I just added tests to systemd-shim, and it got promoted without running the new tests
<pitti> s/promoted/propagated/
<jamespage> doko, hey are you OK to attend at least the first part of the juju activities for trusty session - specifically to discuss golang support in main
<doko> jamespage, sorry no
<jamespage> mwhudson, ^^ any chance you could attend as doko v2?
<doko> seb128, ?
<Saviq> Mirv, still around?
<Mirv> Saviq: following the sessions for a bit still
<Mirv> what's up?
<Saviq> Mirv, when you have a minute (doesn't have to be today) - any reason why http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/qtdeclarative-opensource-src/trusty/view/head:/debian/patches/qtquick_delegate_creation_range_itemviews.patch is dropped from 5.2?
<seb128> does anyone know how to debug "invoke-rc.d: initscript dbus, action "start" failed." issues (happening in a chroot)
<seb128> unping, dbus is not needed to debug that build issue (though still happening when those happen)
<Mirv> seb128: /var/lib/dpkg/info/dbus.postscript?
<seb128> Mirv, postscript? postinst you mean?
<seb128> Mirv, well, ideally the start job wouldn't fail which is real issue
<seb128> Mirv, but yeah, it can be hacked around by hacking the postinst or the init job
<Mirv> seb128: exactly :) I've removed the failing lines when installing packages in chroot
<Mirv> Saviq: probably it didn't apply or I thoight it's merged upstream
<seb128> Mirv, ideally we would make the install work in a chroot rather than ask everyone to workaround it though ;-)
<Saviq> Mirv, yeah, we'd need to port it, that one is something we're carrying ourselves, unfortunately
<Mirv> Saviq: ah, ok
<Mirv> seb128: sure.. I've thought it'd probably work with enough bind mounts (/dev, /sys etc) but I haven't bothered to automate those although there are tools for that too
<infinity> seb128: My chroots all have a policy-rc.d in them that prevents daemon startup.
<infinity> seb128: mk-sbuild does this for you.
<seb128> thanks, I was mostly trying to help one of the Debian guys who wants to look at the smashed stack trusty issues
<xnox> seb128: mk-sbuild is in debian.
<xnox> seb128: "sudo apt-get install ubuntu-dev-tools; mk-sbuild trusty; schroot -u root -c trusty-amd64/i386" works on debian.
<seb128> xnox, yeah, I don't know what he's using, he was just hitting dbus not installing because of that error
<seb128> but that's fine, he forced over it and that's good enough for debugging the issue
<seb128> Laney, mardy: just for info, e-d-s upstream reply about uoa/calendar
<seb128> "I think I know what's wrong: I forgot to update the UOA .service files for
<seb128> Google's OAuth-based CalDAV interface.  Just need to find time to test it."
<pitti> zul: python-misaka tests fail with "ImportError: No module named 'misaka': https://jenkins.qa.ubuntu.com/job/trusty-adt-python-misaka/1;
<pitti> zul: sorry, email notifications are broken since the CI lab change, thus playing relay..
<zul> pitti:  crap ill fix it up
<pitti> zul: thanks (probably just a missing test dep)
<zul> pitti:  yeah :(
<slangasek> mlankhorst: are you able to join the session for hwe planning for 14.04?
<slangasek> mlankhorst: https://plus.google.com/hangouts/_/72cpi5mshd3mujd9pk5te8c50s
<lool> cjwatson, slangasek: If either of you feels like joining the Go session, that might be useful for packaging related questions
<slangasek> lool: can't, running another session; cjwatson?
<cjwatson> yeah
<smoser> bdrung, thoughts? https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/1253208
<ubottu> Ubuntu bug 1253208 in distro-info (Ubuntu) "python-distro-info hard to use for some cases" [Undecided,New]
<mwhudson> jamespage: send me email but probably not, i am on leave in an inconvenient timezone :)
<ogra_> cjwatson, is there some config file that needs editing to get ubuntu-touch onto http://people.canonical.com/~ubuntu-archive/germinate-output/ ?
<cjwatson> ogra_: script, but yes - edited snakefruit:~ubuntu-archive/bin/update-germinate, so that should appear for you on the next run
<ogra_> thanks !
<ogra_> pmcgowan always asks me weird questions why a package is in the image ... that might help a bit :)
<pmcgowan> thanks
<cjwatson> Yep, indeed
<cjwatson> My oversight that it wasn't there already
<bdrung> smoser: hi, i am happy to accept patches.
<bdrung> smoser: returning a dict has the drawback that it could be hard to support if we want to change the internal
<bdrung> smoser: we could add functions instead that take a series and return the fullname/version/etc
<xnox> cjwatson: I get "dpkg-checkbuilddeps: Unmet build dependencies: libdbus-1-dev:native (>= 1.4) libexpat1-dev:native (>= 2.0.0)" when i did $ sbuild --host armhf, on just pushed lp:ubuntu/libnih
<xnox> cjwatson: that's using trusty chroot, am I missing something? should i use some specific build-deps resolver in sbuild?
<mlankhorst> slangasek: sorry I was eating at that time :(
<mlankhorst> and had to be somewhere at 9, evenings are terrible
<slangasek> mlankhorst: eating, in the middle of UDS?  surely not
<barry> kirkland: LP: #1253458
<ubottu> Launchpad bug 1253458 in byobu "Switch to Python 3" [Undecided,New] https://launchpad.net/bugs/1253458
<pero> can anyone help me get back the unity webapps extension in chromium? it somehow disappeared and i'm at a loss on how to get it back
<mlankhorst> oh well night
#ubuntu-devel 2013-11-21
<smoser> bdrung, i think its generally more functional to give me straightforward access to all data.
<bdrung> smoser: i would prefer to keep a simple, supportable API.
<smoser> how is returning a dict of data not supportable?
<smoser> many times i've wanted data in the form that my function gets it.
<smoser> its very common to want a release adjective, its version, and whether or not its an lts.
<smoser> oh, i see. you're thinking about api other than python.
<smoser> :-(.
<bdrung> smoser: in case we want to change the file format, the content of the dict could change. the question is: which attributes would we guarantee to be present?
<smoser> which of the ones i have there would you imply would not be present?
<smoser> i didn't expose anything not already exposed
<smoser> other than more conveniently
<bdrung> we export codename, fullname, and release
<bdrung> and codename
<bdrung> how about accepting "all" as result to return a dict with these values?
<bdrung> smoser: and you probably want a function that can map a codename to this kind of dict
<bdrung> i'll go to bed now. good night.
<pitti> Good morning
<RAOF> Morning pittmasterflash!
<pitti> RAOF: Qapla', member of the Klingon home world!
<pitti> RAOF: oh, and you misspelt Qo'noS as "Khronos", BTW :)
<RAOF> :P
<pitti> cjwatson, jibel: hmm, why did britney trigger the python-imaging test? the binaries are still in NEW, so there's no point in running them
<jibel> pitti, I did manually
<pitti> jibel: ah, ok; thanks
<jibel> I was verifying publication to the public instance, which is broken for new jobs
<pitti> rbasak: sorry, I forgot: what's the reason why adt-virt-lxc has an --ephemeral switch which isn't the default? (as AFAICS you really always want this)
<pitti> rbasak: I'm changing some CLI in 2.5 anyway, so now would be a good time to drop --ephemeral and replace it with --clone?
<Laney> seb128: great!
<seb128> Laney, what was that about? ;-)
<Laney> eds calendar reply
<seb128> Laney, oh, right ;-)
<mlankhorst> slangasek: I was viewing the HWE session, I like how the kernel people only think about the kernel in their suggestions and forget the whole reason is userspace, repeatedly. ;)
<mlankhorst> anyway auto upgrading X.org is HARD
<mlankhorst> kernel can simply depend on a newer package, userspace on the other hand
<mlankhorst> it has to do a scary path where all the old packages need to be removed and the new packages need to be installed.
<pitti> eek, lxc regression
<pitti> stgraber: FYI, filed bug 1253573; downgrading lxc unbreaks it
<ubottu> bug 1253573 in lxc (Ubuntu) "[trusty regression] lxc-clone: failed to write /etc/hostname" [Undecided,New] https://launchpad.net/bugs/1253573
<tseliot> pitti: do you know if a versioned breaks/replaces would work with a virtual package?
<pitti> tseliot: no, virtual packages don't have versions
<pitti> and thus Breaks: don't make sense for them
<pitti> usually you C:/R:/P: virtual-pkg
<pitti> or depend on them; there's not much else that you can do with them
<tseliot> pitti: I suspected that, thanks
<tseliot> pitti: I need to provide an icon within nvidia-settings, the same icon  which the nvidia-driver currently install (well, they actually ship a link to the icon)
<tseliot> and I'm trying to avoid to conflict/break all the nvidia packages in nvidia-settings
<pitti> tseliot: and you can't just put that into a different icon path?
<tseliot> pitti: true, that would make things so much easier. Thanks
<cjwatson> xnox: :native> mail me a repro recipe maybe?  :native on those targets should work ...
<xnox> cjwatson: ok.
<mlankhorst> can we have multiple versions of the same package in the same pocket?
<cjwatson> mlankhorst: Not really
<cjwatson> Occasionally you get multiple versions of a source for short periods, but it's only ephemeral
<cjwatson> You certainly can't assume that anything like that will stick around for any length of time.  Pick a different design
<mlankhorst> I see no sane way of upgrading between lts stacks then :/
<mlankhorst> unless we stuff it in backports
<mlankhorst> but that's not enabled by default either
<ogra_> cjwatson, hmm, that germinate output seems to not take into account that recommends are off in ubuntu-touch
<ogra_> (unless i'm reading the "Why" column wrong)
<ogra_> (looking at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.trusty/touch)
<speakman> Hi folks! Any ideas how to programmatically set the "master" volume in Ubuntu? I can't find any way using DBus. Are there other ways? (And no, not simulate media key presses)
<cjwatson> ogra_: I've fixed your seed STRUCTURE file to declare that properly.
<ogra_> hmm, i thought you had done that ages ago ?
<cjwatson> No.
<ogra_> no, actually i'm sure you have
<ogra_> in raring
<cjwatson> Not in the seeds, only in livecd-rootfs.
<ogra_> oh
<mlankhorst> cjwatson: well the recommended way to rename packages is to provide a transition package. I really see no way to force an upgrade without one though. :/
<mlankhorst> and a manual upgrade wouldn't need a new package, they could just install xserver-xorg-lts-saucy manually when it becomes available
<rbasak> pitti: --ephemeral breaks tar extraction in certain I/O load conditions due to overlayfs.
<rbasak> pitti: example: reproduce with the php dep8 test.
<rbasak> pitti: it reliably reproduces for me on an openstack instance.
<pitti> rbasak: ah, too bad
<pitti> rbasak: so you'd recommend to keep "clone" as the default for the time being?
<rbasak> pitti: right
<pitti> rbasak: that's unpacking the orig.tar?
<pitti> rbasak: I am just running them through adt-virt-lxc --ephemeral adt and it's way past that
<pitti> hm, but that's on trusty
<pitti> rbasak: finished, worked fine; did you see these problems on your local system too, or is that an issue with lxc in kvm on hardware (as we have in cloud instances presumably)
<rbasak> pitti: it's when adt-run copies things in and out of the container.
<rbasak> pitti: my failure happens right near the end of the php5 test. I can try and reproduce and give you access to the instance if you want to follow it up?
<pitti> rbasak: not interested/capable of debugging overlayfs kernel bugs; but would be interesting to determine in which environments they happen indeed
<infinity> mlankhorst: Why do you want multiple versions of something in a pocket?
<mlankhorst> upload a 0~~ version that's only selected by pinning the version :P
<mlankhorst> as a transition package
<speakman> Once again; Any ideas how to programmatically set the "master" volume in Ubuntu? I can't find any way using DBus. Are there other ways? (And no, not simulate media key presses)
<mlankhorst> I played around a bit, apart from forcefully doing apt-get install xserver-xorg-lts-saucy I don't see how you can upgrade automatically
<infinity> mlankhorst: But if installing xserver-xorg-lts-saucy works, then upgrading works.  I'm a bit confused here. :P
<mlankhorst> infinity: yeah but it doesn't allow opt-in automatic opt-in upgrading on EOL
<infinity> mlankhorst: The thing we were discussing in the session is that there should just a -latest type package that matches the icky-named eol-upgrade package in the kernel.
<mlankhorst> oh is that all?
<infinity> mlankhorst: So, said -latest package would be updated to point to -lts-trusty when it's available, and job's done.
<infinity> mlankhorst: Not sure why that's impossible or even hard. :P
<mlankhorst> infinity: but if you upgrade to lts-saucy and then the latest version is lts-trusty, strange things happens
<infinity> ...
<infinity> mlankhorst: wat?
<mlankhorst> I mean if the package pointed to lts-saucy before, and now points to lts-trusty
<infinity> mlankhorst: That's a non-problem.  If you have lts-saucy installed and you install lts-trusty, the upgrade works.  Why would a package yanking you around not work the same?
<mlankhorst> because in case of the kernel the solution is to only install a new package, and keep the old
<infinity> Sure, okay, it'll not work in update-manager without serious quirking, because it tries to remove a ton of packages.
<infinity> It'll work fine in apt.
<mlankhorst> in case of userspace, it has to remove the packages from some 40 source packages, then install from another 40-ish new ones
<infinity> There's nothing stopping us fixing that in update-manager, though.
<infinity> Since we know the name pattern of packages that are going to be swapped.
<mlankhorst> infinity: it only works if you manually resolve it with apt-get install, dist-upgrade won't I think
<infinity> Don't see why dist-upgrade wouldn't work.
<infinity> Except that no one's ever tried it because we don't have that -latest meta.
<mlankhorst> except that I was just testing that now
<mlankhorst> hm *tries without breaks/replaces/conflicts in meta package*
<stgraber> pitti: thanks
<infinity> What would it have been breaking/replacing/conflicting?
<stgraber> smoser, hallyn_: bug 1253573
<ubottu> bug 1253573 in lxc (Ubuntu) "[trusty regression] lxc-clone: failed to write /etc/hostname" [Undecided,New] https://launchpad.net/bugs/1253573
<mlankhorst> infinity: was trying it to nudge apt-get in the right direction
<hallyn_> stgraber: groan
<mlankhorst> infinity: anyway to test.. install the lts-raring stack from the main archive, and upgrade-to-lts-saucy 0.0 deb from https://mblankhorst.nl/etc/ -- after that enable ppa:canonical-x/x-staging and try to upgrade upgrade-to-lts-saucy
<mlankhorst> I tried a few variations but none get the correct answer
<stgraber> hallyn_: I checked and the hook didn't change with the latest upload, so it must be something else...
<smoser> stgraber, you have any idea what would have done that ?
<smoser> did the interface to clone hooks change?
<smoser> the only way i can see that failing that way is if /etc didn't exist in the target (quite odd) or $root_d was set wrong which gets set with the value of "$LXC_ROOTFS_MOUNT"
<BrotherBrick> hello, can someone help push a SRU (for Ogre on Saucy) through? I can confirm that it works for me: https://bugs.launchpad.net/ubuntu/+source/ogre-1.8/+bug/1250924
<ubottu> Ubuntu bug 1250924 in ogre-1.8 (Ubuntu) "[SRU] Ubuntu changes to Ogre install plugins in wrong directory" [Undecided,Triaged]
<stgraber> smoser: nothing obvious at least...
<stgraber> pitti: can you pastebin your /var/lib/lxc/<container>/config and /var/lib/lxc/<container>/fstab?
<hallyn_> pitti: and contents of /var/lib/lxc/<container>/rootfs/etc - i.e. does hostname exist there
<stgraber> smoser, hallyn_: oh, one thing I just saw now is that it's a regression from saucy's LXC (alpha1) vs trusty's LXC (alpha3), so not just between alpha2 and alpha3, so quite a few more things that could have gone wrong
<hallyn_> oh nm my q
<infinity> BrotherBrick: I'll sponsor that.
<showard> thank you infinity
<stgraber> hallyn_: anyway, reproduced here with a clean container on trusty
<BrotherBrick> awesome, thanks infinity :)
<BrotherBrick> and OpenMW thanks you
<stgraber> hallyn_: lxc-create -t ubuntu-cloud -n p1 && lxc-clone -o p1 -n p2
<hallyn_> stgraber: ditto
<stgraber> hallyn_: well, with the missing -- -r saucy since trusty doesn't seem available yet for ubuntu-cloud
<smoser> stgraber, apt-get install distro-info
<stgraber> hallyn_: we probably ought to add an autopkgtest once we get that one solved, easy enough to test ;)
<stgraber> smoser: ii  distro-info     0.11         amd64        provides information about the dist
<hallyn_> stgraber: ok i think i know the problem
<hallyn_> it's because i stopped mounting rootfs for the dir case.  had to be done for lxc-create, wasn't ready to do it for lxc-clone
<hallyn_> (for unprivileged use)
<hallyn_> well,
<stgraber> ah, that'd explain it :)
<hallyn_> ah here we go,
<hallyn_>                 if (setenv("LXC_ROOTFS_MOUNT", conf->rootfs.mount, 1)) {
<hallyn_> that should be using bdev->dest.
<hallyn_> but i need to run to a session
<stgraber> yeah, I'm sure pitti can wait a few more minutes :)
<stgraber> hallyn_: send that to lxc-devel when you have a minute, I'll ack, push to master and cherry-pick in the Ubuntu package
<hallyn_> stgraber: cool, thanks
<pitti> stgraber: in case you still need it: http://paste.ubuntu.com/6453636/
<pitti> $ sudo cat /var/lib/lxc/adt/rootfs/etc/hostname
<pitti> adt
<pitti> stgraber: ^ and that
<hallyn_> stgraber: sent
<mlankhorst> infinity: anyway you should have all the pieces to reproduce that lts-stack switching doesn't work :-)
<infinity> mlankhorst: Yeah, I don't have the time to play with it right now, but I believe you that it might need some work. ;)
<mlankhorst> Ã¬t really needs transition packages to do a smooth upgrade :\
<seb128> Laney, mardy: https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-10&id=e99485221e2786bda015c14cc7f2287fd223d8aa
<Laney> neat
 * Laney tries
<seb128> I can try as well, once I'm not in hangouts anymore
<seb128> I'm not sure how much the hangout would like me switching to another user session
<Laney> seb128: works for me now!
<seb128> Laney, \o/
<mitya57> Can anybody please reject https://code.launchpad.net/~m-alaa8/ubuntu/saucy/pcmanfm/fix-for-993996/+merge/195625 (See the last two comments)?
<Laney> done
<rbasak> pitti: I've reproduced the issue. I can give you access to the instance if you like?
<mitya57> Thanks Laney.
<mitya57> Also, https://code.launchpad.net/~albertsmuktupavels/gnome-panel/lp-1199074/+merge/196032 â please reject (duplicate of 196031)
<stgraber> pitti: LXC uploaded to the archive
<pitti> rbasak: sorry, between UDS sessions
<pitti> stgraber: merci!
<Saviq> mardy, joining the app startup session? we could use some faces in the hangout ;)
<lool> cjwatson, pmcgowan, sergiusens: Can you guys make the framework followup session?
<sergiusens> lool, oh, look at the time
<sergiusens> joining
<pmcgowan> lool, ah, was going elsewhere but will go there instead
<mardy> Saviq: one minute
<cjwatson> lool: remind me when that was?
<lool> cjwatson: now  :-)
<cjwatson> lool: er, I could have sworn I looked at the calendar invite and it was next week
<lool> cjwatson: I didnt send any calendar invite
<cjwatson> lool: I'm sorry, I'm already one-and-a-half booked for this session :-(
<cjwatson> I definitely need to be in the sru/webapp session
<lool> understood
<lool> maybe we should followup after vuds then
<cjwatson> I thought you'd booked it for outside uds for some reason
<cjwatson> can you carry on without me and I can review it later?
<pitti> xnox: wrt. porting to py3, did you notice my review in https://code.launchpad.net/~xnox/system-service/python3/+merge/192805 ?
<xnox> pitti: yes, i did notice, didn't have time yet to fix it up yet.
<pitti> xnox: ok, thanks (no hurry, just wanted to make sure it didn't get lost)
<pitti> barry: I updated python-gconf status in your doc
<barry> pitti: thanks!
<seb128> pitti, can you share the url of that document? /me is curious of what is still using python (I guess that's the topic?)
<seb128> s-c-p u1 mostly I guess?
<pitti> seb128: https://docs.google.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE#gid=0
<seb128> danke
<pitti> seb128: hplip, ubuntu1, software-center, etc.; still quite a bit
<barry> i'm hoping to at least attack s-c
<barry> since mvo did so much work to get it nearly there, and we have some experimental xapian support in upstream svn
<seb128> what are yellow/blue?
<mitya57> Why isn't that doc linked from the blueprint?
 * mitya57 adds a link
<barry> blue means canonical is upstream
<barry> yellow means there's some hope :)
<barry> e.g. upstream has support, maybe not officially released, or not packaged yet, etc.
<seb128> ok
<barry> mitya57: thanks.  it's linked from the wiki spec
<seb128> is s-c really worth the effort?
<seb128> I though it was going to be deprecated
<barry> ralsina_: says it is not going away for 14.04
<seb128> it's buggy like that (see e.u.c), if we spend efforts on it we should spend those fixing bugs
<Laney> surely not for 14.04
<seb128> well, it's not like we are going to get ride of python2 for 14.04
<pitti> right, there's almost no hope for hplip, s-c-p, sso, and the like
<barry> not entirely, no
<seb128> so s-c seems like wasted effort/chances to destabilize it more
<pitti> so keeping s-c as it is in 14.04 would be sensible
<seb128> if it's not properly maintained/moving forward, we should just fixes the most important bugs for the LTS and minimize resources spent on it imho
<pitti> if we have so much time to spend on py3, let's rather do it on the pieces that we keep :)
<seb128> right
<barry> if that's the case (which is fine, there's plenty of other work to do), then it'll mean we won't need to spend time on deps that only those pieces pull in
<barry> seb128, pitti, Laney if you guys can review the list (look at applications and library tabs) and let me know what has no hope of porting or just isn't worth it and i'll mark them in the spreadsheet
<seb128> barry, sure, seems like pitti got the ones I know about
<Laney> not sure what the deal is on ibus
<barry> seb128: thanks
<seb128> Laney, not sure about ibus either...
<Laney> mmm
<zyga> jodh: is http://upstart.ubuntu.com/wiki/DBusInterface the best place to learn about dbus interface for upstart?
<pitti> rickspencer3, jono: yes, we'll support direct Q->T upgrades
<pitti> (that was just discussed an hour ago)
<jono> thanks pitti
<rickspencer3> thanks pitti
<tkamppeter> Anyone from the design team here? I am starting a session about the mobile print dialog now.
<jodh> zyga: currently, yes. it's on my todo to add a table to the cookbook...
<Noskcaj> Is there a way to test if a package will build on ARM? Some GL changes to evas mean it can be synced if it build on ARM IIRC
<ogra_> Noskcaj, you could use a PPA ... got to #launchpad and ask them to enable armhf for it
<tumbleweed> Noskcaj: or create an arm schroot / pbuilder (using qemu-user-static)
<Noskcaj> I'll do the first one
<zyga> jodh: thanks
<bdmurray> cyphermox: bug 1198315 is missing SRU information
<ubottu> bug 1198315 in gnome-control-center (Ubuntu Saucy) "[network]: gnome-control-center SIGSEGV in append_escaped_text() (invalid utf8 ssid name)" [Medium,In progress] https://launchpad.net/bugs/1198315
<cyphermox> oh, oops, quite right
<cyphermox> bdmurray: actually, could you reject it, I have a patch that would be better than what I uploaded earlier
<bdmurray> cyphermox: done
<cyphermox> thanks
<RAOF> slangasek: This is your UTC+11-morning last-night's vUDS reply messageâ¦ No, we won't have a system compositor on the desktop by default for 14.04; only XMir or Unity8 would run under a system compositor, and we've stated we're not going to be defaulting to either of those for 14.04
<bdmurray> bdrung: your upload of apt-mirror to the precise proposed queue does not reference bug 977278
<ubottu> bug 977278 in apt-mirror (Ubuntu Precise) "apt-mirror does not support armhf arch" [Undecided,Fix committed] https://launchpad.net/bugs/977278
<bdrung> bdmurray: ups
<bdrung> bdmurray: should i reupload it?
<bdmurray> bdrung: that'd be great and if you let me know I'll approve it
<bdrung> bdmurray: reuploaded
<slangasek> RAOF: so, we wouldn't consider using the system compositor up to the greeter, e.g., and then stopping it in favor of X?
<RAOF> You mean up to and including the greeter, right?
<slangasek> RAOF: yeah
<RAOF> That wouldn't solve the text-on-shutdown problem, and would require us to have nvidia and fglrx drivers that I hope we'll have but am not sure that we'll have...
<slangasek> righto
<RAOF> And I'm not sure how it'd interact with user switching; we'd need to bring the sc back up for the greeter, then tear it down again for X, etc?
<RAOF> Hm, no, that bit would be fine.
<RAOF> We'd just do the same VT dance we normally do.
<RAOF> Hm.
 * slangasek nods
<RAOF> And that actually *would* solve the text-on-shutdown problem, assuming we did things in the right order...
<RAOF> And we wouldn't actually stop the sc, we'd just VT switch from it, so the greeter could still be all up andn ready.
<RAOF> slangasek: So, I think there are only two reasons why we wouldn't be able to have a sc - (a) do we have the manpower, and (b) will we get nvidia/fglrx Mir drivers?
<sarnold> are there any concerns about multiple GUI contraptions taking up memory bandwidth and disk bandwidth when paging them in?
<RAOF> The sc would be pretty small; probably on the order of X (which ends up being ~20MB), and we could make it even smaller if necessary.
<sarnold> ah once they hit steady state tht's not so bad
<slangasek> RAOF: <nod>
#ubuntu-devel 2013-11-22
<pitti> Good morning
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<pitti> stgraber: confirming, current lxc is happy again; thanks for the super-fast fix!
<BrotherBrick> morning ;)
<BrotherBrick> infinity: the new [SRU] Ogre3D package works great on amd64 and i386, thank you
<BrotherBrick> Cheers :)
<seb128> Laney, mardy: btw, confirmed, uoa/e-d-s calendar integration works great with mbarnes's fix!
<Laney> seb128: cool, feel free to upload
<seb128> Laney, ok
<Laney> oh, /me remembers reading an email about e-d-s
<Laney> man, having work email on your phone is a bad idea
<Laney> "yeah, I'll reply to that tomorrow" â forget because it's read now
<seb128> can't you tag/flag emails from your phone?
<Laney> probably
<seb128> doko, hey, could you look at the python2.7 autopkgtest?
<seb128> doko, one test is failing, see https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python2.7/9/ARCH=amd64,label=adt/console
<seb128> doko, that makes the new libffi be blocked in trusty-proposed
<ogra_> cjohnston, the germinate output still has recommends in it ... annd i noticed that it does only x86
<cjohnston> I'm guessing cjwatson ^
<ogra_> oh
<ogra_> (sorry)
 * Laney hugs cjohnston 
<cjohnston> :-)
<mitya57> What should I do to let csound migrate to -release? Some binary packages were intentionally renamed/dropped.
 * mitya57 didn't notice the rdepends :)
<seb128> directhex, hey, seems that banshee/tomboy needs to be built with the new dbus-sharp, is anyone working on making those changes?
<directhex> seb128, tomboy is on my TODO but i've been busy. banshee is hyperair's and i've been bullying him into doing it, although he's been busy
<seb128> ok
<seb128> directhex, I guess that means "being handled", which is good enough for me, thanks ;-)
<directhex> seb128, there's a tracker on release.d.o now, so we're aware of it, it just needs finishing
<seb128> right, as long as somebody is looking at it I'm happy ;-)
<seb128> thanks
<directhex> seb128, i've mostly been busy with architecture concerns, of late. armhf packages should be available by xmas, finally
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> ogra_: remind me next week when I'm not on vacation
<ogra_> cjwatson, oh, sorry, i didnt know
<ogra_> enjoy !
<pitti> dholbach: patch pilot report> wow! *hug*
<dholbach> pitti, I knew I was going to be a bit busy this Friday, so I got some sponsoring done during the last days
<dholbach> but yeah... it's good we're a bit closer to 0 again
<seb128> nice to see all those packages going in sync as well
<seb128> dholbach, good work ;-)
<dholbach> merci beaucoup
<pitti> brainwash: finally! bug 1252121
<ubottu> bug 1252121 in systemd-shim (Ubuntu) "missing resume signal because D-BUS connection goes away" [High,In progress] https://launchpad.net/bugs/1252121
<brainwash> pitti: yes, finally :) systemd-shim did cause quite some trouble =S
<dobey> cjwatson, infinity: was there agreement to revert dpkg strictness in trusty?
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<infinity> zul: Please use dh_autotools-dev instead of patching config.{sub,guess}.  Patching is much harder to maintain, and just breaks for the next port.
<zul> infinity:  ack
<infinity> zul: I think I'll redo openchange right now, so you can see what I mean.
<zul> infinity:  thanks
<zul> infinity:  its blocking samba 4.0
<infinity> Oh, but there's the ordering confusion that comes in with mixing with dh_autoreconf.  I guess I'll leave this one alone.
<infinity> Until I sort out how to get that properly fixed and documented in Debian.
<infinity> zul: Nevermind, carry on. :P
<mterry> infinity, I'm looking at SRU bug 859600.  xnox uploaded an SRU to precise, but it was rejected.  Was that because we didn't also SRU to quantal yet or for some other reason?
<ubottu> bug 859600 in gnome-keyring (Ubuntu Quantal) "Please convert gnome-keyring to multiarch" [Undecided,In progress] https://launchpad.net/bugs/859600
<mterry> (I'm assuming you were the one that handled it, just because you're mentioned in the bug)
<doko> seb128, python2.7 uploaded to unstable, will sync over the weekend
<seb128> doko, thanks
<seb128> doko, btw, the libffi fixed the indicators tests stack smash issues, thanks!
<infinity> mterry: No idea who rejected it, or when, or why.  The uploader would have gotten an email detailing all those things at the time.
<mterry> xnox, ^ ?
<mterry> infinity, thanks
<xnox> mterry: let me check my mail archive.
<xnox> mterry: "Rejected by Chris Halse Rogers: The Breaks/Replaces versioning is wrong; it should contain the most recent version ts, rather than unconditionally breaking any package younger than the most recent build"
<mterry> xnox, ah right, it shouldn't have binary:Version or whatever in the Breaks
<mterry> xnox, OK, I can prep new Q and P uploads today
<stgraber> pitti: np
<xnox> mterry: thank you.
<xnox> mterry: i guess it's easiest to download the rejected package files and tweak them.
<mterry> xnox, ok
<infinity> doko: If the eglibc test build in my PPA goes okay, I'll copy it with binaries to a toolchain PPA.
<infinity> doko: (if not, I'll fix it :P)
<Cas> hi charles, I have a few questions about indicator-bluetooth code
<bdmurray> slangasek: looking at bug 708517 and its corresponding error this has not occurred in a release later than 12.04.  I'm thinking about closing it.
<ubottu> bug 708517 in plymouth (Ubuntu) "plymouthd assert failure: plymouthd: ./plugin.c:540: map_to_device: Assertion `head->size > 0' failed." [High,Triaged] https://launchpad.net/bugs/708517
<slangasek> bdmurray: closing 708517> yes, sounds reasonable to me
<tumbleweed> infinity: aww. all that way, and then a non-ported execstack (pypy)
<tumbleweed> I wouldn't worry about it on arm64, though. There's no JIT support
 * infinity glares at the one test regression on glibc/ppc...
<smoser> cjwatson, can I use gpt partition table on a root disk and have only a single partition  and have grub-pc as my loader ?
 * smoser realizes that cjwatson has no business being around this time on a friday.
<maxb> smoser: I think you need a special 'biosgrub' partition to make that work, into which grub puts the bit of itself it embeds after the MBR on an MBR disk
<maxb> 'set <number> bios_grub on' is the parted command for marking a partition as such
<smoser> maxb, yeah. hm.. so does that mean for uefi you're minimum is 3 partitions ?
<smoser>  1. bios_grub
<smoser>  2. /boot
<smoser>  3. /root
<smoser> ?
<maxb> If you're doing UEFI, you'd be using grub-efi instead of grub-pc and could just have a single partition, I would think
<maxb> If you're doing booting using grub-pc, then I would think only two partitions would be needed, bios_grub and /
<maxb> Though some swap would probably be nice too :-)
<infinity> smoser: Not only does he have no business being around, he's actually on VAC.
<smoser> thanks maxb
<slangasek> maxb: UEFI "single partition"? If you're doing UEFI, you need a UEFI boot partition
<maxb> Um, yes, brain skipped over that somehow :-)
<slangasek> smoser: as for GPT, as long as the firmware can *address* the root partition to actually find the stage2 bootloader from grub, yes, it's fine to have a single GPT partition
<slangasek> (for bios)
<slangasek> you don't per se need any special biosgrub partition, since GPT is backwards-compatible with MBR in terms of layout and you have space for the grub stage1 in the usual place
<slangasek> but the question is, if you don't set up a special partition for grub stage2, will grub stage1 be able to find stage2 at $random_offset on your disk
<Noskcaj> Would we be able to update memtest86+ to 5.01 in ubuntu since debian is going very slowly on this?
<slangasek> Noskcaj: how will we validate the new version?
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2013-11-23
<Noskcaj> Do we follow the CoC for copyright files? http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/hexdiff/trusty/view/head:/debian/copyright
<slangasek> the code of conduct applies to everything we do while acting as representatives of the Ubuntu community; but I'm assuming you're referring to the choice of language in that copyright file, which we have no control over, because those are the actual terms of the license
<slangasek> (it's childish, but that doesn't change that this is the license... and that's not the only package in the archive under that license)
<ari-tczew> if a package got in d/control in Architecture something like "mips mipsel s390x", do we need to remove them or can be there?
<shadeslayer> cjwatson: I think ARCH isn't considered with the script-rootfs
<shadeslayer> erm
<shadeslayer> live-rootfs I mean
<ogra_> shadeslayer, because it is ARCHES iirc
<shadeslayer> 0.o
<shadeslayer> auto/config has no thing as ARCHES
<shadeslayer> only ARCH
<ogra_> oh, right
<ogra_> how do you hand ot to the build command ?
<ogra_> (should be a prefix)
<shadeslayer> hm? I don't follow ...
<shadeslayer> I added --architectures i386 to the lb config command in auto/config
<ogra_> no, you need to set ARCH="foo" in the line of the build command
<shadeslayer> I did
<ogra_> hmm, works fine for me ...
<shadeslayer> http://pastebin.kde.org/pmaktsria
<shadeslayer> this is on 14.04
<ogra_> try exporting it instead
<ogra_> https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
<shadeslayer> ogra_: I did tryhat too t
<shadeslayer> *I did try that too
<shadeslayer> http://pastebin.kde.org/pd2bgu85z
<shadeslayer> ogra_: ^^
<arun> guys ; is there APIs  site of Ubuntu ?
<shadeslayer> arun: developer.ubuntu.com
<infinity> shadeslayer: Run it under linux32, that's what the buildds do.
<shadeslayer> infinity: yeah, but then this should be doable should it not?
<infinity> Perhaps ARCH should also set --architecture, sure.  I'm just telling you how it works right now.
<infinity> (And you want to be running under linux32 anyway, to avoid the possibility of something misbehaving when it sees an x86_64 uname)
<shadeslayer> roger
<shadeslayer> infinity: other problem, when booting the x86_64 image, it says can't find /casper/vmlinuz
<infinity> That, I'm less sure about.  We don't actually use live-build to build ISOs, so your results will be a bit different from the "official" builds.  Patches welcome to bring them more in line.
<shadeslayer> googling that issue gives me a number of hits where people said it's /casper/vmlinuz.efi
<infinity> doko: Which toolchain-r PPA do you want me to copy this glibc upload to?
<doko> ubuntu-toolchain-r/test
<infinity> Done.
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/1199239
<ubottu> Ubuntu bug 1199239 in unzip (Ubuntu Raring) "[SRU] unzip list utf-8 (non-ascii) filenames as ??" [High,Fix committed]
<maxiaojun> why it stuck for quantal and raring?
<shadeslayer> would anyone know why livecd-rootfs doesn't symlink binary/casper/vmlinuz-3.11.0-13-generic to binary/casper/vmlinuz?
<shadeslayer> since syslinux looks for binary/casper/vmlinuz
<Ampelbein> jamespage: Since you merged bsh, could you have a look at bug 1254335 ? It causes multiple build failures in Ubuntu.
<ubottu> bug 1254335 in bsh (Ubuntu) "bsh: Builds libbsh-java package without needed maven-repo files" [High,New] https://launchpad.net/bugs/1254335
<Ampelbein> jamespage: The bug is fixed in Debian's -15 revision
<shadeslayer> cjwatson: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1254344 when you have some time :)
<ubottu> Ubuntu bug 1254344 in livecd-rootfs (Ubuntu) "Syslinux for kernel + initrd that are not present" [Undecided,New]
<Noskcaj> Is anyone here a DD? If so, can you please review http://mentors.debian.net/package/testdrive
<directhex> Noskcaj, debian/control says Depends: debhelper (>=9), but debian/compat says 6
<Noskcaj> directhex, really? crap
<directhex> Noskcaj, debian/changelog says UNRELEASED, not a real debian version to target (i.e. unstable or experimental when closing an ITP)
<directhex> Noskcaj, those are the two which leap out at me. am on windows right now so hard to test
<Noskcaj> I've fixed them both, will upload now
<Noskcaj> Can someone please rebuild kreversi and krfb on armhf? The chroot failed
#ubuntu-devel 2013-11-24
<Noskcaj> I'm working on a fix for bug 718640 at http://pad.ubuntu.com/kagXFCAjfh , could someone please proofread it?
<ubottu> bug 718640 in Ubuntu Packaging Guide "Guide to fix FTBFS bugs" [High,Triaged] https://launchpad.net/bugs/718640
<Noskcaj> Can someone check https://launchpadlibrarian.net/157440169/buildlog_ubuntu-trusty-arm64.python3.3_3.3.3-2_FAILEDTOBUILD.txt.gz ? i think a rebuild will be enough to fix
<ScottK> Noskcaj: kreversi and krfb done.
<ScottK> python3.3 is built on arm64 now.
<Noskcaj> thanks
<doko> xnox, in drizzle you disable the compiler option because it doesn't work with 4.8, but you build with 4.7 ...
<ogra_> bah
 * ogra_ notices the kde hackfest and switches his trusty-changes mailbox to "auto mark as read"
<Riddell> ogra_: what's the matter slow boy? can't handle the eliteness of our packaging? :)
<ogra_> lol
<infinity> s/eliteness/automatedness/?
<Riddell> ogra_: you're missing some free Irn Bru in Munich
<ogra_> yeah, i saw the pics ... have a nice hackathon :)
<xnox> doko: yeah, i noticed that when gcc bug report comments arrived. I can't remember now, if disabling loop optimisations was enough or not. I can try another try with 4.8 on affected arches.
<Riddell> Laney: you added a dependency to user-manager for consolekit, how do you know it uses consolekit?
<mitya57> doko: will you take care of python-imaging â pillow transition or should I do that?
<mitya57> (We need to reapply the delta, remove the old package and let the new one migrate)
<doko> mitya57, please go ahead. although I'm wondering if we need the old ones
<mitya57> I think we'll be able to drop transitional packages after Trusty release
<mitya57> doko: done: https://launchpad.net/ubuntu/+source/pillow/2.2.1-1ubuntu1, now please remove the old package
<mitya57> And it will still be nice if you applied first two parts of our delta to Debian.
<mitya57> pitti: you may want to retry https://launchpad.net/ubuntu/+source/pygobject/3.10.2-1/+build/5254937 to make the new pygobject migrate
<infinity> mitya57: Done.
<mitya57> Thanks.
<lfaraone> Hm. A HWE X package diverted a file in precise, then after upgrading to trusty the HWE package is unremovable since it is trying to undivert a file, but the file has already been updated by another package, so dpkg-divert errors out.
<lfaraone> How is it possible that the original path (since diverted) was modified, since any writes by the original owning package should go to the diverted location, right?
<Laney> Riddell: It was using the D-Bus interface, but it seems that is no longer true with the current version in trusty
<quidnunc> E: Logic failure in hook handling. Directory /var/cache/pbuilder/build//10794/tmp/hooks should exist but it does not.
<quidnunc> ^ Why am I getting this when running backportpackage?
#ubuntu-devel 2014-11-17
<Laibsch> cjwatson, xnox: I guess you've seen my application for PPU?  I haven't heard a thing about it since.  Is everything on track?
<dholbach> good morning
<pitti> jodh: FYI, I add some bugs to https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration which correspond to some of the WIs, so we don't need to duplicate all of those as textual WIs
 * didrocks is listening to the session
<jodh> pitti: thanks!
<pitti> jodh: so everything in "Blockers for switching the default in vivid" is now covered by linked bugs, your automatic list, and one remaining WI which I just added
<pitti> jodh: I also added two "nice to have" WIs for me, but the WI list is of course not complete yet
<pitti> jodh: I don't want to meddle too much with your BP (you are the drafter, after all), so feel free to move around the milestones etc.
<LocutusOfBorg1> wow I triggered a bug in launchpad https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1393202
<ubottu> Launchpad bug 1393202 in hedgewars (Ubuntu) "in rope training game the target don't disappear when one kicks them" [Unknown,Confirmed]
<LocutusOfBorg1> I can't change the status
<LocutusOfBorg1> lol
<pitti> LocutusOfBorg1: try the expander on the left and then change the status with the combobox
<pitti> (I don't see the AJAXy change status either)
<LocutusOfBorg1> pitti, yes, I already did the workaround, I was just reporting a bug :)
<LocutusOfBorg1> thanks
<didrocks> pitti: 2 things while I'm thinking about them: during the systemd session, you are talking about session not properly shutting down, this is I guess the timeout I'm seeing (like 30s with no screen refresh) before having the system brutally stopping?
<pitti> didrocks: I sometimes get the 90 s timeout on user@1000.service shutdown (something is hanging there); but there's nothing about "brutally" stopping, it's just killing that user@1000.service
<didrocks> pitti: I get it at each shutdown it seems, didn't find a bug about it though?
<pitti> didrocks: oh? I don't get this
<pitti> didrocks: I sometimes see it in an nspawn'ed vivid instance
<didrocks> ok, will be a nice next-step exercise for debugging it seems
<didrocks> ah, if I can reproduce it here, would be easier to debug
<pitti> didrocks: right; enabling the debug shell, and while it's hanging check systemctl about what it's hanging on?
<didrocks> pitti: will do (opening http://freedesktop.org/wiki/Software/systemd/Debugging/ for enabling the debug shell)
<didrocks> pitti: second thing is that we don't enable journald persistency across reboots (there isn't the /var/log/journald IIRC directory created)
<didrocks> is that on purpose?
<pitti> didrocks: I haven't thought about this yet TBH; I guess we shoudl only have that *or* rsyslog by default, otherwise we waste twice the amount of log file space?
<didrocks> exactly
<didrocks> so, something to discuss, I find it weird for users that they can see only current journald boot, and have to go to rsyslog for older entries (and less info)
<didrocks> but the opposite is true as well anyway :)
<pitti> yeah; but I think I'd rather have it this way around, and then decide at some point to drop rsyslog by default and switch on persistant journal
<pitti> didrocks: even more clever would be to auto-enable persistant journal dependeing on whether rsylog is enabled :)
<didrocks> good idea!
 * didrocks notes down as an easy one
<jodh> pitti: I don't mind - feel free - it's going to have to be a team effort after all :)
<pitti> hm, I was about to test LVM+encrypted, but this seems broken in vivid :( (bug 1393341)
<ubottu> bug 1393341 in ubiquity (Ubuntu) "automatic LVM+encrypted partitioning fails" [Undecided,New] https://launchpad.net/bugs/1393341
 * pitti downloads an utopic ISO and tries with that
<pitti> slangasek, jodh: yay, cryptsetup+systemd works fine; both the full LVM with root (thus asking in initramfs), and only /home on LUKS (thus asking in the real system)
<caribou> Laney: I just created a backport bug for tcpdump; should I assign it to myself while I complete some of the testing ?
<Laney> caribou: sounds reasonable
<caribou> Laney: k, will do
<LocutusOfBorg1> seb128, sorry for the typo on bug 1367260
<ubottu> bug 1367260 in tcpdump (Ubuntu) "tcpdump needs merge from debian" [Wishlist,Fix released] https://launchpad.net/bugs/1367260
<seb128> LocutusOfBorg1, no worry
<cjwatson> pitti: question for you in bug 1393341, since you're unfortunate enough to have touched lvm2 last :-)
<ubottu> bug 1393341 in partman-lvm (Ubuntu) "[vivid regression] automatic LVM+encrypted partitioning fails" [Undecided,New] https://launchpad.net/bugs/1393341
<pitti> cjwatson: ah yeah, thanks; yeah, I fixed the init.d script once and it seems now I need to maintain it forever without understandin a thing about our delta :/
<caribou> Laney: I tested everything required for the tcpdump backport  & everything is ok. So I'm leaving the bug unassigned
<cjwatson> heh, well, it was a question more than a request :)
<cjwatson> I don't claim to understand our delta either
<pitti> but yes, "we should merge LVM2" indeed
<pitti> cjwatson: everyone who did (kees, xnox) left, so I guess we'll have to make-do; I'll try to have a look at it soon, but I can only test it in a rather limited fashion
<cjwatson> pitti: if it can't be done in some reasonably short period (by which I don't mean to rush you), then I guess the alternatives are to cherry-pick that option into lvcreate, to patch it out of partman-lvm (but then we risk forgetting about it and it'll likely break again later), or to figure out if partman-lvm can be made to work with both old and new lvm2
<cjwatson> the problem was IIRC that new lvm2 broke partman-lvm differently without that option
<xnox> cjwatson: pitti: partman-lvm & lvm2 need merging?
 * xnox can look at that in the evening.
<cjwatson> partman-lvm is in sync.  lvm2 needs merging.
<xnox> ack.
<xnox> slangasek: you should pinch hallyn into foundations team ;-)
<pitti> zul: hah! got it
<pitti> zul: adt-run --apt-pocket=proposed -U keystone --- qemu /srv/vm/adt-vivid-amd64-cloud.img --cpus 2
<pitti> zul: that's the bit that the wiki page is missing; we run with 2 virtual CPUs by default, thus SMP
<pitti> zul: with that I can reproduce the segfault fairly reliably (4 out of 5 runs)
<pitti> zul: sorry, not segfault, it's a SIGKILL
<zul> ah ok :)
<pitti> zul: it also happens in vivid-release (adt-run keystone --- qemu /srv/vm/adt-vivid-amd64-cloud.img --cpus 2), so not a regression
<pitti> zul: but "fails on machines with more CPU" still sounds rather serious?
<zul> pitti:  so is there something i can do
<pitti> zul: I'm ok with letting python-babel and python-keystoneclient in, as this isn't a regression from those two; but this will still hit the next time, of course
<zul> pitti:  eventlet as well?
<pitti> zul: yes
<zul> pitti:  ok thanks
<pitti> zul: FYI, keeping track/notes in bug during autopkgtest
<pitti> bah, weechat
<pitti> or, rather, bah firefox
<pitti> zul: bug 1393474
<ubottu> bug 1393474 in keystone (Ubuntu) "su call in postinst fails with "Killed" when not running from a logind shell" [Undecided,New] https://launchpad.net/bugs/1393474
<zul> pitti: ack
<chiluk> hey infinity I know you are sprinting and stuff but can I get some upload love on https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1391662
<ubottu> Launchpad bug 1391662 in nfs-utils (Ubuntu) "mount.nfs does not downgrade NFS version when connecting to dual-stack NFS server" [Medium,In progress]
<tkamppeter> Does someone know about the Python3 support of pyqt4? There is a python-qt4-dbus but no python3-qt4-dbus for example.
<cjwatson> tkamppeter: I think you want python3-pyqt4.
<cjwatson> IIRC they took the opportunity of adding python3-* to fix some naming mistakes.
<tkamppeter> cjwatson, and pyqt4-dev-tools?
<jtaylor> those are binaries and don't need modules
<jtaylor> *provide
<tkamppeter> What replaces python-imagin in Python3
<jtaylor> python3-pil
<tkamppeter> jtaylor, if hplip build-depends on pyqt4-dev-tools, what does it need when ported to Python3?
<jtaylor> the same package
<tkamppeter> python3-gobject-2?
<jtaylor> you shouldn't need to care if binaries need python2 or 3
<jtaylor> unless there is a packaging mistake of course
<panbalag>  Looking for any developer who has updated the fields "when, Confirmed, Assigned, Started work, Completed" in launchpad while working on a bug... Please reply back if you have updated any of these fields. I would like to clarify the definition for these fields.
<cjwatson> python3-gi would be more usual for gobject-related stuff
<cjwatson> python-gobject-2 is the deprecated old-style bindings that AFAIK weren't updated to Python 3 (see python-gi for the new-style ones in Python 2)
<tkamppeter> python3-notify?
<tkamppeter> python-notify
<tkamppeter> What replaces python-notify in Python3?
<ScottK> mitya57: Why did we not make a python3-pyqt4-dev for the sip files?  Did we conclude they were the same for python/python3?
<cjwatson> It looks as though python-notify has never been ported to Python 3, but there's a separate python-notify2 package (slightly different API, apparently) that has been, as python3-notify2.
<dobey> panbalag: those sound like blueprint fields, not bug fields
<tkamppeter> cjwatson, jtaylor, ScottK: Thank you very much.
<mitya57> ScottK: they are the same
<mitya57> http://www.riverbankcomputing.com/pipermail/pyqt/2014-August/034612.html
<ScottK> mitya57: Thanks.
<undRmindcntrlX2>  Does ubuntu error reporting send error data encrypted?
<dobey> Unit193: it's uploaded over https, yes, if that's what you're asking
<dj> hello
<dj> i have a question to ask?
<Noskcaj> !ask | dj
<ubottu> dj: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<dj> How the installation process goes on ubuntu?
<rbasak> arges: https://issues.apache.org/bugzilla/show_bug.cgi?id=56919#c6 is the deep dive / full description of the issue.
<ubottu> issues.apache.org bug 56919 in mod_ssl "Creating a large number of SSL sites using DBDDriver pgsql causes a SIGSEGV / SIGILL on load" [Major,Resolved: duplicate]
<arges> rbasak: cool reading through all that now
<Unit193> dobey: I'm not the droid you're looking for. ;)
<dobey> oh. bloody people asking questions and then quitting five minutes later
<Unit193> Yep. :/
<dobey> oh well
#ubuntu-devel 2014-11-18
<pitti> Good morning
<pitti> rbasak: FYI, new apache seems to cause some regressions: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apache2
<pitti> rbasak: it seems to break redmine too: https://jenkins.qa.ubuntu.com/job/vivid-adt-redmine/6
<dholbach> good morning
 * smb notes that it looks like some google API shutdown may have broken current xul-ext-lightning (at least all my gcalendars stopped working as of yesterday which seems to match some info on the lightning support page)
<seb128> wgrant, hey, any news on the vivid translations opening?
<xnox> jdstrand: anything i can do to progress bug #1388889 ?
<ubottu> bug 1388889 in iucode-tool (Ubuntu) "[MIR] intel-microcode & iucode-tool (multiverse -> restricted)" [Undecided,New] https://launchpad.net/bugs/1388889
<ypwong> cjwatson, hey, could you suggest who is the best one to give some hints on bug 1330410 ?
<ubottu> bug 1330410 in Ubuntu Kylin "All keyboard types in "Keyboard layout" are not localized during installation" [High,Triaged] https://launchpad.net/bugs/1330410
<cjwatson> ypwong: I don't know, sorry
<cjwatson> ypwong: I mean it's probably me but I'm not at all sure I have time in the remaining few weeks I have on Foundations.  Ask slangasek, and maybe he'll bounce it back to me or maybe he can find somebody else?
<ypwong> cjwatson, okay, I will try to rebuild the package in a utopic chroot and see if I can reproduce it
<ogra_> pitti, so i'm playing with this emergency remount stuff in adbd (by echoing u into systq-trigger) ... sadly i notice that the process issuing the reboot alredy dropped privs ... which means it runs as phablet ... do you thinkit would be overly evil to have /proc/sysrq-trigger owned by the phablet group ?
<tkamppeter> I need some help for Python. I want to switch system-config-printer to use Python3. Problem is that on a system with both Python2 and Python3 iot always builds for Python2. Is there a way to force building for Python3?
<doko> tkamppeter, wasn't that already switched? I remember some discussion with pitti
<didrocks> mvo: small question regarding bug #1387090, did you get a tmpfs ro mount for /etc/machine-id once you reboot with your workaround to truncate the file?
<ubottu> bug 1387090 in systemd (Ubuntu) "boot breaks if /etc/machine-id is missing" [Medium,Triaged] https://launchpad.net/bugs/1387090
<tkamppeter> doko, sorry I mean hplip, not s-c-p.
<doko> ahh
<doko> tkamppeter, do you have a test package?
<tkamppeter> doko, the problem is that there is no appropriate option in the ./configure script, like "--with-python3" or similar.
<doko> tkamppeter, should I look at the current package in vivid then?
<mardy> tedg: hi! I've started using the launcher for the helper: http://bazaar.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/click-plugins/view/head:/online-accounts-service/ui-proxy.cpp#L274
<mardy> tedg: how can I monitor the new process, and be notified when it ends?
<tkamppeter> doko, I can send my test package, packaging is as the current one, but the upstream source I got as a beta version from HP, which cannot be published. The beta version is language-wise converted to be Python3 compatible, so that it works on Python3-only systems using Python3, but on systems with both it seems always to default to using the system default.
<doko> tkamppeter, try PYTHON=python3. it is using AC_ARG_VAR to get this value
<tkamppeter> doko, thanks, will try.
<tkamppeter> doko, and how do I get the PYTHON_DEFAULT_VERSION and PYTHON_SITENAME variables correct?
<doko> $ py3versions -dv
<doko> 3.4
<doko> tkamppeter, ^^^
<tkamppeter> doko, thanks.
<mvo> didrocks: yeah, I get a new mount with a valid machine-id
<tkamppeter> doko, I get
<tkamppeter> dpkg-gencontrol: warning: Depends field of package hplip-gui: unknown substitution variable ${python3:Depends}
<tkamppeter> what do I need to change for this?
<doko> tkamppeter, sorry, this is too unspecific
<didrocks> mvo: but this mount is using tmpfs, right?
<tkamppeter> doko, thank you very much. Now I can build the package as native Python3 package, hp-systray and hp-setup work as Python3 programs.
<mvo> didrocks: yeah
<didrocks> mvo: ok, the behavior is coherent with what I see at least, thanks!
<mvo> didrocks: yw
<tkamppeter> doko, what do I have to install so that
<tkamppeter> from dbus.mainloop.qt import DBusQtMainLoop
<tkamppeter> works under Python3?
<doko> tkamppeter, what did you install for Python2?
<tkamppeter> doko, should be python-qt4-dbus.
<tkamppeter> cjwatson, jtaylor, ScottK: Do you know which package I have to install to get the module "dbus.mainloop.qt" in Python 3?
<cjwatson> tkamppeter: python3-dbus.mainloop.qt - could you please use apt-cache search before asking?
<tkamppeter> cjwatson, have found it out by myself, googling.
<tkamppeter> doko, seems that now everything is working.
<jdstrand> xnox: no, it is in ok shape, I just need to find a bit of time to do it (it is on my list)
<tedg> mardy, You need to register an observer: http://bazaar.launchpad.net/~indicator-applet-developers/ubuntu-app-launch/trunk.15.04/view/head:/libubuntu-app-launch/ubuntu-app-launch.h#L471
<xnox> jdstrand: kk. It's just ideally i would like it in by alpha 1 (~3 weeks) such that both canonical and intel QA can verify and test it on wide variety of hardware and finallise before feature freeze whether or not we will be installing it by default.
<xnox> the current plan is that it will be wonderful with no regressions or bugs(tm)
<rbasak> pitti: I'm on it. There's at least one bug to do with ordering of module configuration which causes things to fail.
<pitti> rbasak: ah, cheers
<asac> anyone knows if i can hook a trigger to bip that does something if i get a highlight?
<pitti> I don't think so, it's mostly just a relay/logging thing; seems easier to make your IRC client act on hilight?
<ogra_> asac, yes, you can write a client :P
<ogra_> (which can be as much as a scrip wrapper around nc or telnet that attaches in parallel to your bip)
<asac> hmm. ok
<asac> will come back :)
<xnox> mdeslaur: congrats on owning 30% of changes to mountall in 2014 so far. I believe this makes you the new maintainer of mountall. =)
<pitti> hopefully not for very long any more :)
<caribou> what's the best way to upgrade from Utopic to the dev release ? do-release-upgrade -d ?
<mdeslaur> xnox: I get a blanket exception from owning anything since I'm on the security team :)
<mdeslaur> xnox: nice try though :)
<xnox> mdeslaur: damn, i should have been in the security team.
<mdeslaur> hehehe
<pitti> caribou: TBH I always just s/utopic/vivid/ in /etc/apt/sources.list and "apt upgrade"
<pitti> caribou: I think do-release-upgrade -d needs mvo or some other wizard to create some vivid meta-files first, but it doesn't hurt to try of course
<mvo> pitti: I thought I did that
<mvo> caribou: I think that should work
<pitti> mvo: ah, great
 * xnox used do-release-upgrade to get vivid
<caribou> pitti: the only time I did that was when I started with Canonical; completely hosed my laptop & had to reinstall but it was on stable release
<mvo> caribou: *ick*
<caribou> mvo: pitti: back on Natty
<sladen> perhaps it was when the bootload changed to UUID etc
<caribou> sladen: wasn't a boot issue, but looked like many packages never upgraded correctly; I was left with a bootable laptop but no GUI
<mardy> tedg: thanks
<mardy> jdstrand: hi! I'm working on confining the account plugins; I'm still unsure about the apparmor implications of it
<mardy> jdstrand: I guess that account plugins will have to ship an apparmor policy file?
<rbasak> stgraber: feature request. lxc-stop -k should be default on ephemeral containers. Not doing so doesn't make any sense, right?
<jdstrand> mardy: hi! before I answer that, how will you be handling the profile attachment?
 * jdstrand suggests aa_change_onexec
<jdstrand> (man 2 aa_change_onexec)
<Saviq> ogra_, hey, have there been plans to unify terminal sessions between touch and desktop? (i.e. getting the upstart env etc.)
<Saviq> it's currently so confusing when you switch between the two...
<ogra_> Saviq, not yet, once we use proper sessions perhaps ...
<Saviq> ogra_, "proper session"?
<ogra_> lightdm greeter and all that
<Saviq> we are using lightdm sessions already, are we not? just no greeter, but that == autologin?
<ogra_> oh, wait you said terminal sessions ... :)
<ogra_> well ... we do our best to cheat adbd into behaving as much as a real session (by forcing the upstart env and dbus envs into it on "adb shell") the prob is that adb simply behaves more like a serial terminal than a login tty
<rbasak> mvo: around? I have dpkg-query when called from within a postinst behaving differently between sid and Vivid, even though dpkg is merged and up to date in Vivid.
<mvo> rbasak: what is the difference?
<rbasak> I'm just trying to find the code for your online now.
<rbasak> mvo: the code is http://anonscm.debian.org/cgit/pkg-apache/apache2.git/diff/debian/debhelper/apache2-maintscript-helper?id=804b53b7d5901e47c2751cdf78908ccd9c594c5b
<rbasak> mvo: "dpkg-query -f '${Status}' -W apache2|grep -q installed" doesn't work in Ubuntu, but does in Debian, it seems.
<rbasak> mvo: I know it's dubious, but it's hard for me to submit a bug in Debian if it works there :)
<rbasak> mvo: (note that this line is called from inside the postinst of a module package)
<rbasak> So in Ubuntu, apache2 is configured before libapache2-mod-passenger, but libapache2-mod-passenger runs that code and thinks that apache2 isn't configured yet.
<rbasak> I modified the binary package to add "set -x" to verify it's definitely this line that's behaving differently.
<rbasak> I can reproduce using a direct dpkg call.
<slangasek> xnox: what's the process for translating between boost1.55 and boost-mpi-source1.55?  There's a Debian merge to merge in and I'm averse to manual busywork ;)
<rbasak> (installing both apache2 and libapache2-mod-passenger in the same call)
<rbasak> mvo: ^^
<mvo> rbasak: sorry, I'm a bit slow today, lots of stuff going on. so it might be that dpkg behaves the same but the different order of install might cause the difference in the output (or am I misreading what you wrote earlier?)
<xnox> slangasek: i believe i got it to the point of rename boost1.55 src package & run debian/rules clean and it should do everything.
<slangasek> xnox: ah, I like that answer, thanks :)
 * xnox looks at changes.
<rbasak> mvo: I accounted for the difference in order of install by calling dpkg directly with just the two packages involved, and got the same behaviour with the same configuration order.
<xnox> slangasek: is merge actually needed? i thought we had that all applied in ubuntu already...
<rbasak> mvo: I filed https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1393832 to track this as the explanation is a little complicated
<ubottu> Launchpad bug 1393832 in dpkg (Ubuntu) "Modules fail to enable when configured after apache2 is configured" [Undecided,New]
<xnox> slangasek: if that's not enough diff boost1.55 / boost-mpi-source1.55 - i think there are two variables in the debian/rules as well or maybe not.
<xnox> slangasek: ah, you do want the ppc64 patch i guess.
<slangasek> pitti: the hard-coding of paths for all commands in systemd units is hateful and wrong (and, I assert, contrary to Debian policy).  Is there a way to make this more robust?  Could we have systemd use a default path, as a distro patch if necessary?
<slangasek> xnox: I want it to not be on my list of pending merges, whether there's anything new in Debian's version :)
<mvo> rbasak: yeah, makes sense to file a bug
<xnox> slangasek: lolz. ok.
<xnox> slangasek: if grab-merge works with proxies i can do it ;-)
<slangasek> xnox: and then you would be TIL, that would be great!
<slangasek> ;)
<xnox> slangasek: also it would be helpful to get https://code.launchpad.net/~xnox/launchpadlib/proxy/+merge/241176 in as well
<xnox> without that, my hands are tied.
<cjwatson> grab-merge is basically a fancy wget
<xnox> hm. barry wants tests =)
 * xnox ponders what to test in launchpadlib proxy test thing.
 * xnox can do auto-pkg-tests cause there is proxy support there.
<barry> xnox: :)
<xnox> barry: would auto-pkg-tests do, or do you want unit tests?
<xnox> proxy support is there, i only add auto-detection logic - hence i should be testing the autodetection logic?!
<barry> xnox: dep-8 would be cool
<rbasak> So I've filed a bug to track the issue that is preventing proposed migration.
<rbasak> Is there any way to get that to the update_excuses page, so others can follow it?
<rbasak> block-proposed tag, even though it isn't really for that?
<rbasak> OTOH, maybe it does make sense, since even if the dep8 tests happen to pass, we probably still don't want to introduce the regression that the bug represents.
<rbasak> Any opinions? Would this be abusing the tag?
<cjwatson> Seems reasonable enough to me.
<rbasak> Oh, one catch.
<rbasak> It has a dpkg task. I don't want to block dpkg migration
<rbasak> So I'd better not I guess (or delete the task).
<pitti> slangasek: ah yeah, I'd like that too; I see little point in not using $PATH
<slangasek> pitti: what do you think is the right way to do it?  I'm looking at a dry-run conversion of an upstart job, and was pondering EnvironmentFile=/etc/environment
<pitti> slangasek: that would certainly work for ubuntu only units, although it's a bit ugly; but certainly more explicit than an ubuntu-only path (as these units wouldn't apply to Debian)
<pitti> slangasek: so if we can get agreement in Debian to add a patch to support $PATH resolution of Exec=, we can at least share stuff that way
<pitti> slangasek: does that actually work? it's not immediately clear that EnvironmentFile= is already taken into account for the Exec= binary?
<stgraber> rbasak: so you may still want a clean shutdown if you've got a shared database or something with it as bind-mount. Also we've got semi-persistent ephemeral containers (with --keep) which you wouldn't want to kill but instead shutdown cleanly
<didrocks> pitti: slangasek: from my tests last week that doesn't work (I tried this as well), The Environment* are only for the process env, not the systemd wrapper when executing it
<rbasak> stgraber: fair enough I guess. I'll just have to get used to -k then.
<rbasak> As well as -n -n -n -n :-)
<stgraber> rbasak: :)
<slangasek> pitti, didrocks: right - I didn't test this, was just wondering if it worked.  Obviously we wouldn't really like to have to set this in each unit anyway
<doko> RAOF, https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493 please check if an empty jar helps
<ubottu> Launchpad bug 1389493 in openjdk-7 (Ubuntu) "Package dropped pulse-java.jar, breaking some development environments" [High,Confirmed]
<bdmurray> pitti: systemd no longer seems to produce a libudev1-dbgsym package. Do you know why?
<bdmurray> pitti: also any news on bug 1370230?
<ubottu> bug 1370230 in Apport "apport-retrace has become slower" [High,Triaged] https://launchpad.net/bugs/1370230
<Noskcaj> Laney, IS there anything in particular i should be doing for my MOTU application or do i just wait
<Laney> Noskcaj: I pinged the others to reply with any questions
<Noskcaj> ok
<Laney> If we don't hear back in the next day or so we should up the pressure
<mdeslaur> slangasek: I've figured out bug 1384502, but I'd like your opinion whether that's an upstart issue, or just needs the rpcbind package to be modified...
<ubottu> bug 1384502 in mountall (Ubuntu) "fstab entry for nfs /home fails to mount on boot" [Undecided,Triaged] https://launchpad.net/bugs/1384502
<mdeslaur> slangasek: argh, I added my comment to the wrong bug, one sec
<slangasek> mdeslaur: hmm.  1) the portmap event was meant to be for backwards-compatibility only, and nfs-utils should be fixed to not rely on it; 2) yes I think it's an upstart bug
<mdeslaur> slangasek: thanks, I've added that to bug 1391296
<ubottu> bug 1391296 in upstart (Ubuntu) "14.10: NFS drives in fstab not mounted automatically" [Undecided,Confirmed] https://launchpad.net/bugs/1391296
<slangasek> mdeslaur: cheers
<wgrant> Pici: Hmm, did you approve some vivid templates?
<wgrant> Oops
<wgrant> pitti: ^^
#ubuntu-devel 2014-11-19
<ZZambia_> is anybody following the ubuntu touch development for MT6595 platforms, like Meizu MX4?
<ZZambia_> I would need some tech info, plz
<pitti> Good morning
<pitti> wgrant: no, I don't think I ever approved vivid templates, why? (just recently some RTM ones)
<wgrant> pitti: Someone approved three, so there's some surgery required before I can open. But I should be able to get it done tomorrow.
<pitti> wgrant: ah, thanks
<pitti> wgrant: btw, can we move the RTM tarball generation?
<wgrant> pitti: I was going to do that in the same step as changing the crontabs for vivid
<wgrant> But that ended up blocked by the various issues.
<wgrant> If I don't get it done tomorrow, I'll shift RTM anyway.
<pitti> wgrant: cheers
<Noskcaj> doko_, syncing libexplain should fix the ftbfs you introduced, it still ails on aarch64 though
<dholbach> good morning
<doko> Noskcaj, synced
<Noskcaj> cool
<ZZambia> is anybody following the ubuntu touch development for MT6595 platforms, like Meizu MX4?
<ZZambia> I would need some tech info, plz
<cjwatson> #ubuntu-touch would be more likely to know
<cjwatson> (if anyone does)
<davidcalle> doko, hello, I've been told this would be in your area of interest : https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/1394131
<ubottu> Launchpad bug 1394131 in bzr (Ubuntu) "UnicodeDecodeError on Vivid for non-ascii characters in config files" [Undecided,New]
<pitti> jodh: I need to uplaod a packaging fix to upstart; there are some staged changes in bzr, do you see a reason to not upload them?
<jodh> pitti: should just be that logrotate fix, so upload should be fine.
<pitti> jodh: and Dmitry's upstart-sessions update (also looks ok)
<pitti> jodh: ack, thanks
<jodh> pitti: ah yes, that looks fine too.
<GunnarHj> pitti: As regards bug #678421, is bash out of the question?
<ubottu> bug 678421 in lightdm (Ubuntu Trusty) "Error message for a faulty ~/.profile script" [Low,In progress] https://launchpad.net/bugs/678421
<pitti> GunnarHj: no, not at all IMHO
<pitti> GunnarHj: but your trap is also rather clever :)
<pitti> jodh: I get FAIL: test_conf_preload.sh
<pitti> jibel: ... when building locally in schroot; is that common/expected?
<pitti> jodh: not otherwise very verbose (http://paste.ubuntu.com/9094158/)
<pitti> jibel: sorry, that was meant for jodh
<GunnarHj> pitti: Yeah, it gets it to ~/.xsession-errors, but doesn't alert the user via a dialog. What I found out about bash is that it automatically carries out syntax checks when sourcing, and it does so recursively. So switching to bash would allow for a really elegant solution.
<pitti> GunnarHj: that, and some people (hello barry!) might also have bashisms in their scripts, too
<GunnarHj> pitti: Right.
<GunnarHj> pitti: Are you saying that you wouldn't object if I proposed a solution with /bin/bash in the shebang line? ;)
<pitti> GunnarHj: exactly; as I said in teh bug and above, I think bash is fine
<jodh> pitti: checking...
<pitti> jodh: I pushed my packaging fix, but I wonder if that failure will also affect buildds
<GunnarHj> pitti: Ok, thanks. Getting back with a MP then.
<pitti> GunnarHj: cheers!
<barry> pitti, GunnarHj: thanks!
<jodh> pitti: I think the upstart failure is caused by a missing libtool binary (again). The binary seems to be in libtool-bin now.
<cjwatson> jodh: You should never be using /usr/bin/libtool.  Use the version that's generated as part of your build system.
<cjwatson> Build-depending on libtool-bin would be the wrong fix.
<cjwatson> jodh: I think you probably want something like http://paste.ubuntu.com/9095744/
<cjwatson> (untested)
<jodh> cjwatson: thanks
<pitti> jodh: re (sorry, was at lunch) -- so this is a proper failure then, not just on my setup?
<jodh> pitti: correct, we've seen this libtool issue before but I didn't realise we shouldn't use the packaged version. I've tested + pushed a fix to lp:ubuntu/upstart if you want to retest then upload?
<jodh> pitti: well, a proper failure, but not an upstart bug :)
<pitti> jodh: ah, sure (oh, we use inline patching in the package?)
<mardy> jdstrand: hi! About your question from yesterday, I'm using libubuntu-app-launcher to start the confined plugin
<mardy> jdstrand: I didn't know about the aa_change* functions, it looks like I could have used those instead
<pitti> xnox: are you already working on the lvm2 merge? I can give it an initial shot, and ask for more in-depth testing on u-devel@ otherwise
<mardy> jdstrand: now the problem is that the plugin needs to connect to a unix socket, so that needs to be allowed by the policy (while if I used aa_change_profile() after connecting to it, I understand that changing the apparmor policy wouldn't have been necessary, right?)
<jdstrand> mardy: I'm not sure if the policy would have to have changed there due to revalidation. perhaps sbeattie can comment
<jdstrand> mardy: so, the confined plugin is running in its own process?
<jdstrand> mardy: and this is a different security context from the app? who is using libubuntu-app-launcher?
<mardy> jdstrand: the trusted helper (our background service, unconfined) uses libubuntu-app-launcher to start the confined plugin, which is its own process
<mardy> jdstrand: to be clear, the process consists of a container we develop, which loads the plugin QML code
<mardy> jdstrand: the security context is going to be different from that of the app
<jdstrand> mardy: so the connection to a unix socket if for communication between the plugin and the trusted helper?
<jdstrand> (as opposed to the app)
<mardy> jdstrand: exactly
<jdstrand> ok cool
<jdstrand> so that all sounds like a fine design
<jdstrand> mardy: remind me, what is the question from yesterday?
<mardy> jdstrand: will account plugins have to declare an "apparmor" entry in the manifest file?
<mardy> jdstrand: and how do we let them access the socket?
<jdstrand> mardy: it depends on what you (as the signon developer) need them to do
<jdstrand> mardy: actually, signon does not run as root
<jdstrand> I was thinking we could have a sorta 'generic' profile that you could transition them to
<jdstrand> while that profile would protect the system, etc, it would not isolate the plugins themselves
<jdstrand> to isolate the plugins themselves, we'd need the profiles to be individually named (ie, declare an "apparmor" entry in the manifest)
<jdstrand> so, we would create a separate template for them, like we did for push helpers
<jdstrand> mardy: does tha make sense?
<mardy> jdstrand: and then we combine the apparmor entry in the manifest with the generic plugin profile?
<mardy> jdstrand: like we do the union of the two?
<jdstrand> mardy: now, the template becomes the generic plugin profile, with a few plugin-specific bits sprinkled in
<jdstrand> /wnow/no/
<jdstrand> meh
<jdstrand> 'no'
<jdstrand> :)
<jdstrand> mardy: eg: /usr/share/apparmor/easyprof/templates/ubuntu/1.2/ubuntu-push-helper
<jdstrand> mardy: except we call it 'ubuntu-qml-plugin' and use rules that are appropriate for it
<mardy> jdstrand: I'm not sure I understand; so we have a template which just a few rules to allow connecting to the socket, and then we add any policy declared by the plugin in their manifest (like "accounts" and "network", typically)?
<jdstrand> mardy: we tailor a template that will work for qml plugins in general, but use apparmor variables (like APP_PKGNAME, which is the click pkgname, or APP_APPNAME, which is the key in the hooks database)
<jdstrand> for various paths so the plugins themselves are isolated
<mardy> jdstrand: but will it be possible for the plugins to get more permissions?
<mardy> jdstrand: I don't have any serious example in mind, but what if a hypothetical plugin wanted to use the location?
<jdstrand> mardy: we can make that possible or we can make that not possible. what permissions are you thinking of?
<jdstrand> mardy: the more direct answer is that policy groups are automatically supported
<jdstrand> mardy: but the click-reviewers-tools can say certain ones are not allowed
<mardy> jdstrand: ah, ok, that sounds perfect than
<jdstrand> we would probably start by saying only networking is allowed, and anything else is flagged as 'unusual'
<mardy> jdstrand: I would keep the template very minimal, and require plugins to explicitly require all their policies
<jdstrand> that way we can get a feel for what people are doing
<mardy> jdstrand: not all plugins even use network
<jdstrand> that's fine
<mardy> jdstrand: the only common thing is "accounts"
<jdstrand> that's fine too
<mardy> jdstrand: then many would use "network" and "webview", but I'd rather let them specify that explicitly
<jdstrand> the click-reviewers-tools can make sure that if providing a qml plugin, the security policy must include accounts
<jdstrand> networking is optional
<mardy> jdstrand: right
<jdstrand> everything else is 'unusual' for the time being
<mardy> jdstrand: "webview" is not unusual, though
<jdstrand> ok
<jdstrand> that's fine too :)
<jdstrand> point is, it is flexible
<jdstrand> I'm happy to work with you on the policy, and I will update the click reviewers tools as appropriate
<seb128> wgrant, hey, is there any news of the vivid translations opening?
<wgrant> seb128: Ran into some issues just before EOD yesterday, just catching up with the situation now.
<seb128> wgrant, ok
<pitti> cjwatson: does it actually make sense to have initramfs-tools scripts in udebs?
<bdmurray> pitti: I uploaded libnih on the 17th and amd64 ddebs made it but i386 didn't. Can you rescue them?
<pitti> bdmurray: ah thanks, I will
<cjwatson> pitti: example?
<pitti> cjwatson: i. e. does d-i ever call update-initramfs (aside from in the target/ chroot)
<cjwatson> pitti: No
<pitti> cjwatson: current Ubuntu delta in lvm2 which I need to port over to a changed package structure
<pitti> cjwatson: but this part doesn't seem to make sense to me, looks like cruft
<cjwatson> pitti: you mean things like this?
<cjwatson> +../../tree/dmsetup/usr/share/initramfs-tools /usr/share
<pitti> cjwatson: right
<cjwatson> pitti: yeah, I don't see any point in those, probably an accident somewhere along the way
<pitti> cjwatson: dmsetup-udeb and lvm2-udeb ship those
<pitti> cjwatson: ok, thanks for confirming; I adjusted the udev rules (as these do make sense in the udeb), and just drop the initramfs hooks/scripts
<cjwatson> Sounds good
<pitti> I now also have a vivid LVM install for testing
<pitti> (i. e. utopic + dist-upgrade)
<xnox> pitti: i thought we needed those, for something rather udev autodetection of hard-drives and things in the installer.
 * xnox tries to remember.
<pitti> xnox: yes, of course we need the udev rules
<pitti> xnox: but not the initramfs hooks/scripts in the udebs
<xnox> yeah those do sound odd, cause installer's initramfs clearly doesn't need that.
<pitti> right, I cleaned them up
<pitti> I just finished the merging and got my first successful build \o/ testing it now
<pitti> and lo and behold, still boots with both upstart and systemd
<pitti> now I need to clean up some unnecessary systemd units (as we use udev 85-lvm2.rules)
<pitti> xnox, kees: I sent a call for testing for new LVM to u-devel@; testing appreciated!
<xnox> pitti: tah.
<wgrant> pitti: We currently do precise, trusty, utopic and 14.09. vivid is now open and importing. I can move utopic to Tuesday, but what should we do about vivid?
<wgrant> I guess we could just start doing things on Friday as well. No problem with that from my end.
<wgrant> Monday: vivid, Tuesday: 14.09, Wednesday: precise, Thursday: trusty, Friday: utopic?
<wgrant> Since I guess we want both vivid and 14.09 before Wednesday for images.
<ogra_> we dont currently do milestones for vivid
<wgrant> Though we can potentially do more than one a day nowadays.
<wgrant> Sure, but we will eventually.
<wgrant> Anyway, I need to wander off for a few hours.
<wgrant> pitti: Let me know what you think.
<ogra_> 14.09 now has a milestone process where we try to have the candidate image ready on wed. evemning EU TZ
<wgrant> Right, that's why we're moving them to Tuesday.
<pitti> wgrant: sounds perfect tome
<ogra_> (like ... now  (or in about 2h at least))
<wgrant> pitti: 21:00 Tuesday works for 14.09?
<pitti> wgrant: although we don't really need precise and utopic builds any more, there's releatively little interest in them
<pitti> ogra_: when do you want to have the rtm packs again? (for freezes)
<ogra_> pitti, well, we are just preparing to build the final milestone right now
<ogra_> so generally before now ... :)
<pitti> ogra_: ah good, so if new packs would be in RTM archive on Wednesday (our) mornings, does that fit?
<ogra_> tue. evening, wed. morning would be fine
<pitti> wgrant: so, 21:00 Tue sounds great; I suppose I can kick off the source pkg build around Wed 03:00 then?
<ogra_> yeah, we usually call out the archive freeze after the landing meeting around 11am local time
<pitti> src pkg preparing+upload+build is usually ~ 2 h
<wgrant> pitti: Um maybe. We'll have to see how long it regularly takes at that time of day.
<pitti> wgrant: ack, so let's start with that; if it takes too long, we can move it a tad earlier, but it should have enough reserve
 * pitti waves good night then
<ChrisTownsend> In vivid, what is now responsible for setting the /dev/shm -> /run/shm symbolic link?  It seems in past releases, it was done in initscripts.postinst, but that doesn't seem to be the case now.
<ChrisTownsend> I ask, because unpacked images don't seem to have that link anymore.
<infinity> ChrisTownsend: Should be done by /etc/init/mounted-dev.conf
<infinity> ChrisTownsend: Unless you've switched to systemd, then I think the answer is that nothing does it currently.
<infinity> ChrisTownsend: But an "unpacked image" won't have the link, it happens at boot.
<ChrisTownsend> infinity: Well, here's the thing.  I have an unpacked image that I then start in an LXC.  That linked is created when using a Utopic image, but not with a Vivid image.  Also, that upstart job doesn't run unless /dev is it's own mount point, right?
<infinity> ChrisTownsend: Ahh, for what lxc is and isn't doing about that, probably a question for stgraber  or hallyn.
<infinity> Who are both at a sprint right now, I believe.
<ChrisTownsend> infinity: Ok, thanks.  I'll investigate some more for now.
 * hallyn lays low
<teward> not to be annoying, but is there anyone who can, say, take a peek at a merge debdiff and perhaps sponsor it in for vivid?
<ChrisTownsend> infinity: Hey again, I downloaded the ubuntu-14.10-desktop-amd64.iso image and mounted the squashfs and sure enough, the /dev/shm -> /run/shm link is there already.  I presume this is due to initscripts.postinst which sets this.  However, on Vivid, initscripts.postinst does not set this link, so the squashfs does not have it.  So something else is setting it on boot...maybe the mounted-dev upstart job, but I have
<rbasak> Bits of Debian infrastructure down? Where's the appropriate status page/IRC channel for this stuff? Google doesn't seem to be getting me anywhere.
#ubuntu-devel 2014-11-20
<bdmurray> pitti: armhf ddebs of mir didn't make it on to the server
<pitti> Good morning
<dholbach> good morning
<dholbach> diwic, happy birthday!
<diwic> dholbach, thanks! :-)
<pfSmorigo> hi, I'm using preseed but I'm stuck in "No root file system is defined."
<pfSmorigo> my preseed has a "d-i partman-auto/disk string /dev/sdb"
<pitti> stgraber, hallyn: is there a concrete attack scenario why /var/lib/lxc needs to be 700? or is this just an additional defense line in case of containers with broken permissions?
<pitti> I mean, system root dirs are usually world readable, and secret stuff has appropriate permissions
<mdeslaur> pitti: bug 1244635
<ubottu> bug 1244635 in lxc (Ubuntu Saucy) "setuid executables in a container may compromise security on the host" [Medium,Fix released] https://launchpad.net/bugs/1244635
<jdstrand> hallyn, arges: fyi, https://chinstrap.canonical.com/~jamie/lp1292234/ has forhallyn-trusty-amd64.img.gz and forhallyn-trusty-amd64.img.corrupted.gz
<jdstrand> hallyn, arges I couldn't reproduce it until last night
<didrocks> pitti: if we separate upstart system services and upstart session only services, the number of packages to convert this cycles aren't horrible: http://people.canonical.com/~didrocks/systemd/packages-to-convert/2014-11-20.txt
<jdstrand> let me double check the the hashes
<pitti> mdeslaur: ah, thank you!
<jdstrand> hallyn, arges: weird-- it is like a tenth of the size...
<jdstrand> (compressed)
<pitti> didrocks: yes, indeed! we don't need to convert the session ones, but we must replace any system upstart event that they listen to by something else
<didrocks> pitti: yeah, that's why I still list them and counted them at the bottom
 * didrocks waits for jhunt to merge his branch with those changes
<pitti> didrocks: also, note that there are a lot of false postiives in that list too
<didrocks> yeah, I know, I'm looking at why now
<didrocks> pitti: actually, do you have an example of a false positive ones? The one I thought actually had some upstart session service in the end
<pitti> didrocks: I mean hostname, mountall, upstart, upstart-bin, ureadahead
<didrocks> ah that
<didrocks> yeah
<didrocks> not sure it worth a blacklist, we know about those
<pitti> didrocks: yes, just pointing out that the list is even a bit shorter :)
<didrocks> yeah :)
<pitti> didrocks: oh, and rfkill too
<didrocks> well, ok, let's build the blacklist then :)
<pitti> didrocks: don't waste time on it -- apart from rfkill it's quite obvious, and I didn't spot others
<didrocks> ok, I would totally have forgotten rfkill TBH
<Saviq> pitti, hey, I was wondering, is it possible, using gdbserver or similar, to debug stuff on a remote host, while supplying symbols locally? I'm thinking being able to attach to a running process on the phone without having to install the symbols on it?
<asac> whats the current best practice to record my desktop?
<ogra_> use your phone ;)
<Laney> I've used kazam recently with success
<mitya57> There is a package named recordmydesktop, I think it worked fine when I tried to use it.
<teward> any patch pilots awake to peek at a merge debdiff and maybe sponsor it?  i heard i might need a patch pilot to assist with that.
<caribou> When upstream provides a new major version, what should I do about the Ubuntu version ? Directly sync it to Vivid ?
<caribou> I mean, there is no longer any delta b/w Ubuntu & Debian
<ScottK> teward: Subscribe ubuntu-sponsors to the bug with the debdiff in it.  That'll get someone to look at it.
<teward> ScottK: did that - been almost 3 weeks
<teward> ... with no movement
<ScottK> Sometimes it goes like that.
<ScottK> caribou: If the new version is in Debian and there's no remaining Ubuntu delta, yes.  It should be synced.
<caribou> ScottK: yes that's the case (I maintain both debian & Ubuntu)
<ScottK> caribou: Sync away then.
<caribou> ScottK: any place to look to learn how it is done ?
<caribou> first time I have to do it since I got PPU for that package
<caribou> nm, I found it
<caribou> ScottK: and what happens to the merge request on Merge-O-Matic ?
<ScottK> caribou: Once the sync is done, it'll go away.
<caribou> ScottK: ah, ok thanks
<pitti> mvo: I suppose we want https://tracker.debian.org/news/585559 now? (new perl is already in vivid)
<pitti> mvo: you are TIL, but I'm happy to merge it
<pitti> (if you want)
<mvo> pitti: cool, yes. go for it, I'm super busy
<pitti> mvo: yeah, thought so :)
<mvo> pitti: but its getting better :)
<mvo> pitti: just don't make my image bigger ;)
<davidak2> hello. i think i found a bug in ubuntu 14.04
<davidak2> installed nginx from repo, it don't start at boot
<pitti> mvo: well, that's now the proper fix for tha
<pitti> t
<davidak2>    /etc/rc3.d/S20nginx -> ../init.d/nginx
<mvo> pitti: yeah
<davidak2> if it is /etc/rc3.d/S21nginx it will work
<mvo> pitti: how is it done (I'm curious), did all the required stuff move into perl-base?
<pitti> mvo: https://tracker.debian.org/news/585385
<davidak2> i think postfix, rsync, screen-cleanup or sysstat is a dependency and must start first
<davidak2> where does the 20 come from?
<mvo> ta
<davidak2> maybe i can fix it but it would be my first time contributing to ubuntu and don't know what repository and how is the workflow
<stgraber> pitti: there is
<pitti> stgraber: mdeslaur already pointed to bug 1244635, that pretty much answers it
<ubottu> bug 1244635 in lxc (Ubuntu Saucy) "setuid executables in a container may compromise security on the host" [Medium,Fix released] https://launchpad.net/bugs/1244635
<stgraber> right, that's why
<caribou> ScottK: ok, before I go and make a big mistake (I hate the --force options) I suppose that it is normal to use --force since I'm overriding the ubuntu specific changes that are now in the new version
<ScottK> caribou: That's normal if you're overriding changes.
<caribou> ScottK: yes and I've just re-confirmed that everything ubuntu specific in 3.1 is now in 3.2
<ScottK> Then go for it.
<caribou> otherwise I'll blame the other schizophrenic side of me who is the debian maintainer
<ScottK> Worst case it needs another upload later to add something back and that's not a big deal.
<davidak2> isn't this the right place for my question?
<caribou> davidak2: http://packaging.ubuntu.com/html/fixing-a-bug.html is a good start
<caribou> davidak2: but that describes UDD which is not frequently used in fixing bugs on stable releases
<caribou> davidak2: but I would say that the first thing to do is to create a bug that will describe the issue & how you think it can be fixed
<davidak2> caribou: thanks.
<pitti> bdmurray: libnih ddebs are all on http://ddebs.ubuntu.com/pool/main/libn/libnih/ except for i386, as that FTBFSed: https://launchpad.net/ubuntu/+source/libnih/1.0.3-4ubuntu27/+build/6576097
<pitti> bdmurray: I retried the build, hoping for/looks like an unstable test
<pitti> bdmurray: Mir seems complete? http://ddebs.ubuntu.com/pool/main/m/mir/
<bdmurray> pitti: yeah, the armhf one just was slow to appear
<pitti> bdmurray: about libudev1-dbgsym: "libudev1 has no unstripped objects, ignoring"
<pitti> bdmurray: that's surprising indeed, I'll create a bug to check that
<didrocks> jodh: hey, not sure if you noticed, but I've enhanced a little bit your detect upstart script to tell which packages contain upstart session jobs only (and we will only check for events in them, but won't convert them this cycle to systemd). I've run it and the output is http://people.canonical.com/~didrocks/systemd/packages-to-convert/2014-11-20.txt
<pitti> bdmurray: filed bug 1394627
<didrocks> jodh: my branch is at lp:~didrocks/+junk/separate-upstart-session-system if you want to give it a look and eventually pull the extra commit :)
<ubottu> bug 1394627 in systemd (Ubuntu) "no libudev1 debug symbols" [Medium,Triaged] https://launchpad.net/bugs/1394627
<bdmurray> pitti: thanks
<jodh> didrocks: yes, thanks. maybe you could merge your changes into lp:~ubuntu-foundations-team/+junk/migration-to-systemd (or raise MP)?
<didrocks> jodh: IIRC, you can't propose for merging into a +junk/ branch
<Riddell> jdstrand: patches for your pleasure on bug 1393479
<ubottu> bug 1393479 in kde-runtime (Ubuntu Vivid) "security: Insufficient Input Validation By IO Slaves and Webkit Part" [Undecided,New] https://launchpad.net/bugs/1393479
<jodh> didrocks: ok, didn't know that - patch? :)
<didrocks> jodh: hopefully, I just made it one commit, so easy for you to pull/push: http://bazaar.launchpad.net/~didrocks/+junk/separate-upstart-session-system/revision/7 :)
<jdstrand> Riddell: thanks! I'm going to point mdeslaur at those since he is on community this week, but he may reassign
<jodh> didrocks: thanks - merged and re-run for http://people.canonical.com/~jhunt/systemd/packages-to-convert/2014-11-20.txt
<didrocks> jodh: nice, thanks! :)
<ah> Hi. I'm wondering if anyone knows the status of migrating to bluez5 in ubuntu. As I understood it the main reason to hold back a while ago was because of bluetooth headset support. As I understand it now, this will be adressed with the upcoming pulseaudio release. Does anyone here know if there has been any discussions about going ahead with bluez5 some time in the future? (Sorry for being so out of touch
<ah>  with whats ...
<ah> ... happening in ubuntu.)
<didrocks> ah: we discussed it at least UOS, you can see the hangout video here: http://summit.ubuntu.com/uos-1411/meeting/22332/update-to-bluez-5/
<ah> didrocks: thanks. will check it out.
<didrocks> ah: yw, you have a blueprint to track the progress: https://blueprints.launchpad.net/ubuntu/+spec/desktop-v-bluez5
<bdmurray> zul: your upload of keystone to utopic proposed contains some extraneous changes, well I think at least you don't want to change the Vcs information. https://launchpadlibrarian.net/190573428/keystone_1%3A2014.2-0ubuntu1_1%3A2014.2-0ubuntu2.diff.gz
<bdmurray> zul: and the related bug could use some updating for the SRU
<zul> bdmurray:  reject it please
<jdstrand> hallyn, arges, rharper: hey, did you guys see backscroll? I was able to upload a corrupted image last night: https://chinstrap.canonical.com/~jamie/lp1292234/
<rharper> jdstrand: yeah, thanks!
<jdstrand> it is curiously way smaller compressed than the other
<jdstrand> but uncompressed it is the same size
<rharper> mmmm zeros
<jdstrand> rharper: cool
<jdstrand> hopefully that will shed some light on it
<rharper> jdstrand: du reports the same allocation ?
<jdstrand> well, if I uncompress and use file, it tells me it is the same
<jdstrand> QEMU QCOW Image (v2), 8589934592 bytes
<jdstrand> that is corrupted ^
<jdstrand> QEMU QCOW Image (v2), 8589934592 bytes
<jdstrand> that is uncorrupted ^
<jdstrand> qemu-img shows that the uncorrupted doesn't have a pristine snapshot. that should be correct
<jdstrand> so, the 'disk size' is bigger with corrupted
<jdstrand> (since it has an internal snapshot, that makes sense)
<arges> jdstrand:oh awesome
<jdstrand> but yean. going from 1.2G compressed to 104M, something is not right
<jdstrand> yeah*
<arges> jdstrand: i'll look at it after lunch
<jdstrand> arges: one nice thing about it being smaller-- it is faster to download while at the sprint :)
<jdstrand> arges: thanks!
<jdstrand> rharper, arges, hallyn: oh, this came up before and might be helpful: sarnold and I both are using ext3 where the qcow2 are stored. I know there were some extant bugs with qcow2s that hallyn pointed us at, but I read the reports and commits and didn't think those fixes would tix our issue
<jdstrand> that said, if you as experts thought otherwise, I'd be happy to try other things
<jdstrand> sarnold: can you confirm I am remembering your system correctly?
<bdmurray> chiluk: don't you men nfsv3 in the impact part of bug 1391662?
<ubottu> bug 1391662 in nfs-utils (Ubuntu Precise) "mount.nfs does not downgrade NFS version when connecting to dual-stack NFS server" [Medium,In progress] https://launchpad.net/bugs/1391662
<bdmurray> s/men/mean/
<sarnold> arges,hallyn,jdstrand, I am using ext3 on my laptop where I've had the qcow2 corruption
<chiluk> bdmurray, checking..
<chiluk> bdmurray, correct... fixed
<arges> sarnold: jdstrand good to know
<chiluk> thanks bdmurray
#ubuntu-devel 2014-11-21
<hallyn> sarnold: jdstrand: fwiw I spent a week trying to reproduce on my server specifically on ext3...  but tha tdoesn't mean ext3 isn't involved of course
<hallyn> down to 104M.  that's impressive
<hallyn> call it a feature and call it a day :)
<sarnold> hallyn,jdstrand, did you ever have any luck recreating the problem on your server?
<hallyn> sarnold: I never did.  not once
<hallyn> now there is a bug i was sru'ing today which made reference to qcow2 corruption due to try_fiemap(), but i dont' think it's related
<hallyn> infinity: bug 139209, a straight sync looks sane to me.  since you last touched it, just wanted to make sure you didn't have any objections
<ubottu> bug 139209 in network-manager (Ubuntu) "disconnect vpnc connection doesn't terminate vpnc" [Undecided,Fix released] https://launchpad.net/bugs/139209
<hallyn> well, seems fine.  few more test-builds
<darkxst> slangasek, could you take a look at bug 1391102 its been sitting in unapproved for nearly two weeks now
<ubottu> bug 1391102 in tracker (Ubuntu Utopic) "[MRE] Update to tracker 1.0.6" [Undecided,New] https://launchpad.net/bugs/1391102
<didrocks> diwic: hey! not sure if you noted, but cyphermox uploaded bluez5 to the ppa, if you can upload a snapshot of pulseaudio soon, that would help us knowing if bluez5 support works (as it's one of the first use-case to test)
<diwic> didrocks, cool, thanks for the heads up
<didrocks> yw!
<dholbach> good morning
<LocutusOfBorg1> hi dholbach :)
<dholbach> hi LocutusOfBorg1
<seb128> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<tjaalton> gpg-agent doesn't seem to start on utopic, and there's no logfile created either.. anyone else seeing this?
<seb128> tjaalton, gnome-keyring is the defautl gpg agent
<tjaalton> well gpg-agent worked fine on trusty, and it has an upstart session job too
<tjaalton> gnome-keyring doesn't know about my key, seems to be running though
<tjaalton> how to configure it?
<seb128> tjaalton, could be a fallover from https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1271591
<ubottu> Launchpad bug 1271591 in gnome-keyring (Ubuntu Trusty) "upstart job race prevents gnome-keyring from being ssh agent" [High,Fix released]
<seb128> see recent comments
<tjaalton> ah
<tjaalton> thanks
<seb128> xnox, hey, is https://code.launchpad.net/~xnox/ubuntu-seeds/platform-init/+merge/225850 still a thing?
<seb128> slangasek, ^ you could maybe review that one? it's the sponsoring queue since july
<seb128> cjwatson, hey, do you have an opinion on https://code.launchpad.net/~tj/ubuntu/trusty/grub-installer/lp1354730/+merge/230222 ? It's in the sponsoring queue since august, would be nice to have it out one way or another :-)
<Laney> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768600 â could we apply similar to ureadahead in Ubuntu?
<ubottu> Debian bug 768600 in readahead-fedora "readahead-fedora: cycle found while processing triggers" [Serious,Open]
 * Laney just got a trigger cycle
<seb128> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mardy> greyback: hi! Can you please join #ubuntu-touch?
<xnox> Laney: yes.
<Laney> xnox: ya, uploading
 * Laney finds the triggers documentation hard to grok
<xnox> Laney: yes, currently the policy maintainers are looking for reviewers to review the triggers implementation to review the triggers policy patch for sanity.
<xnox> Laney: no takers yet....
<Laney> interesting - I didn't look in policy
<xnox> Laney: well, it's not /in/ policy yet =) because it's too cryptic to find reviewers to +1 it.
 * xnox set off world rebuilds and now off for lunch.
<infinity> hallyn: I feel like that bug number was probably missing a digit...
<mdeslaur> Riddell: FYI, I'm still working on your updates, it's taking a while because I have to rebuild a bunch of dependencies in the -security pocket
<hallyn> infinity: doh
<hallyn> infinity: bug 1392095
<ubottu> bug 1392095 in libcap2 (Ubuntu) "Sync libcap2 1:2.24-6 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1392095
<hallyn> basically, sync libcap2.  seems to work.  built fine, let me still build qemu/lxc at lest.
<hallyn> mdeslaur: is there any part of qrt that would exercise libcap2?
<infinity> hallyn: Seems fine to me, go for it.
<hallyn> thanks, will do.
<mdeslaur> hallyn: not sure, maybe test-kernel-security.py
<hallyn> mdeslaur: ooh, nice.  maybe i should find time to move some of the old ltp tests into there
<caribou> seb128: thanks for sponsoring libnss-ldap, though there were concerns expressed around the changelog descriptions
<seb128> caribou, those concerns should have been expressed on the bug then I guess?
<caribou> seb128: agree
<seb128> caribou, well now it's done, sorry about that
<caribou> seb128: you don't have to be sorry, I should have done better & remove the debdiff
<caribou> seb128: that's the problem with doing merges w/o upload rights, it is mostly useless
<seb128> caribou, it's not useless
<seb128> well depending of how complex the merge is and how much you are trusted
<seb128> caribou, but it's at least useful in the sense you get sponsoring and experience which puts you on the way to ask for upload rights ;-)
<caribou> seb128: yeah right, but in that case, it leaves the merge bugs in situation prone to errors
<seb128> well, my fault as a sponsor for not spotting the error
<seb128> it's also not of the best taste to have somebody reviewing it/having comments and not writing those on the bugs to avoid duplications or errors
<caribou> seb128: tbh, I prefer to have it uploaded in that state (missing a more explicit changelog description & one useless Build-Dep) than the opposite
<caribou> currently, all of the libnss-ldap package in the archive will generate Segfaults and unbootable systems if they're rebuilt
<seb128> urg
<seb128> that merge was also overdue
<seb128> so thanks for putting efforts on it, it was non trivial
<caribou> seb128: good learning experience I must say. Anything I should do to complete ?
<caribou> seb128: like propose a debdiff with the missing bits in a new version ?
<seb128> caribou, if you want to do a followup upload with some extra fixes/changes feel free yes
<caribou> seb128: missing bits == more descriptive debdiff & remove po-debconf from the Build-dep
<caribou> seb128: ok, will do. I have it ready but got dragged into other things
<seb128> caribou, thanks
<jdstrand> sarnold: I don't have a server. I was talking to them yesterday and they said it would be useful to have both the pre-corrupted image and then the corrupted image, so they could compare the qcow2 data structures for before and after
<jdstrand> sarnold: so I was able to do that for them
<mwhudson> mitya57: are you awake still?
<mitya57> yes I am
<mwhudson> mitya57: i commented on bug 1393583, i'm a bit confused as to what happened though
<ubottu> bug 1393583 in gccgo-go (Ubuntu) "stdlib.go misses packages" [Undecided,New] https://launchpad.net/bugs/1393583
<mitya57> mwhudson: the patch headers are correct, I just ran quilt refresh locally to remove some noise from there.
<mitya57> (to be more precise, I have QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" in my .quiltrc)
<mwhudson> mitya57: then why does applying the patch fail to add the last two lines of the file?
<mitya57> And the reason for it FTBFS is probably some change between utopic and vivid.
<mwhudson> no
<mwhudson> (i do really need to get around to setting up quilt properly)
<mitya57> Hmm indeed the last two lines are missing.
<mwhudson> quilt bug?!
<mitya57> maybe it is, my gccgo-stdlib-ignore ends with
<mitya57> +       "unicode":             true,
<mitya57> +       "unicode/utf16":       true,
<mitya57> +       "unicode/utf8":        true,
<mitya57> +       "unsafe":              true,
<mitya57> +}
<mwhudson> the difference i see between the patch i uploaded and the one quilt made for you is that mine says @@ 1,143
<mwhudson> and yours says @@ 1,141
<mitya57> I see, it's probably my fault
<mitya57> Sorry, and let me fix it
<mwhudson> np
<mwhudson> and let me finally set up a .quiltrc
<mitya57> $ cat ~/.quiltrc
<mitya57> QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
<mitya57> QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
<mwhudson> mitya57: thanks
<mitya57> mwhudson: uploaded
<mwhudson> mitya57: yay thanks
<mitya57> no need to thank me, it was my fault after all :)
<mitya57> (and it built this time)
<mwhudson> mitya57: well thanks for looking at my patch at all :)
 * mwhudson reads about SRUs
<mwhudson> (this bug breaks lxd when compiled with gccgo)
<ogra_> you could fix it in lxe then
<caribou> seb128: new debdiff is ready for LP: #1389152
<ubottu> Launchpad bug 1389152 in libnss-ldap (Ubuntu) "please merge libnss-ldap 265-3 (main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1389152
<caribou> seb128: the debdiff is over the .ubuntu1 version that you uploaded recently, not over the orig debian pkg
<seb128_> caribou, great, thanks, going to review that in a bit
<teward> has anyone noticed that the time it takes apport to actually generate error report data for the user to see has drastically increased since 10.04 all the way up to 14.04?  It takes, sometimes, 20 minutes to get data from the apport 'report error' window when xorg crashes, even in 14.04...
<sarnold> jdstrand: heh, I hjadn't considered that a before-and-after might be more useful than just the "after" -- but it makes a lot of sense. nice work grabbing one :)
<jdstrand> sarnold: thanks! though the idea to compare was rharper's. it makes a lot of sense
#ubuntu-devel 2014-11-22
<Fazer2> hi, I want to patch qt package and upload it to PPA, should I use this tutorial? http://packaging.ubuntu.com/html/patches-to-packages.html
<Fazer2> is this "tutorial" up to date? http://askubuntu.com/questions/454/what-is-the-proper-way-to-patch-wine-for-a-custom-ppa
<Riddell> Fazer2: that patches-to-packages.html uses UDD which is quite complex, just use apt-get source qt4-x11  to get the current package
<Riddell> Fazer2: then follow that page for quilt which manages the patches
<Riddell> Fazer2: or just put the patch in debian/patches and name it in debian/patches/series
<Riddell> Fazer2: what's the patch for?
<Fazer2> Riddell: it's a workaround for Virtualbox bug - https://bugreports.qt-project.org/browse/QTBUG-42415
<Fazer2> Riddell: I'd need to add 3 lines to Qt .cpp file
<Riddell> Fazer2: yeah so slap the patch in debian/patches and debian/patches/series  quilt push to check it applies
<Riddell> dch -i to add a new changelog
<Riddell> debuild -S  to make the source package
<Riddell> dput ppa:myppa/foo *changes
<Riddell> to upload
<Fazer2> Riddell: thanks :-)
<Noskcaj> cjwatson, Can you take a look at https://code.launchpad.net/~noskcaj/ubuntu/vivid/sagan/liblognorm-transition/+merge/242573 ? It will let you finish the liblognorm transition
<Noskcaj> cjwatson, libscalar-list-utils-perl has been fixed with the new perl in debian, could we sync it (You RMed it in trusty for breaking with perl 5.18)
#ubuntu-devel 2014-11-23
<Fazer2> Riddell: hi, I followed your "guide" about creating a patched package from yesterday, but I got stuck on dput command
<Fazer2> Riddell: when I wrote "dput ppa:piekarzarkadiusz/ppa .libqt5gui5_-5.3.0+dfsg-2ubuntu9ppa1_source.changes" I got "Can't open /home/fazer/dev/qtbase-opensource-src-5.3.0+dfsg/.libqt5gui5_-5.3.0+dfsg-2ubuntu9ppa1_source.changes"
<Fazer2> Riddell: I also tried "dput ppa:name/ppa *changes" and got "Not a .changes file. Please select a .changes file to upload."
<Fazer2> if anyone else knows the answer, I'll be glad to hear it :-)
<Riddell> Fazer2: ".libqt5gui5" why the random dot?
<Riddell> use the filename
<Fazer2> Riddell: damn
<Fazer2> Riddell: without the dot I get can't open file
<Riddell> Fazer2: well does the file exist?
<Fazer2> Riddell: I assume I should have a *.changes file generated by debuild -S, but it's not there
<Riddell> what happens?
<Fazer2> Riddell: debuild -S ended successfully with Successfully signed dsc and changes files
<Fazer2> Riddell: strange, I also don't see *.dsc file
<Riddell> Fazer2: cd ..
<Fazer2> ooooooooh
<Fazer2> I'm an idiot
<Fazer2> Riddell: now it looks like I have to correct distribution from UNRELEASED to utopic
<Riddell> Fazer2: that seems like a good idea
<Fazer2> Riddell: it's building right now on Launchpad :-D
<Fazer2> Riddell: thanks for help :-D
<Riddell> awooga
<Fazer2> XD
<Riddell> Fazer2: lots more packaging to be done in kubuntu land, join #kubuntu-devel to become an elite kubuntu ninja :)
<Fazer2> Riddell: I assume it will create a couple of binaries, including libqt5gui5
<Fazer2> it's funny, I'm on Kubuntu now ;-)
<Fazer2> I don't think I have so much time now, maybe after finishing degree
<Riddell> Fazer2: you're welcome any time
<Riddell> Fazer2: or.. make kubuntu your degree, lots of disseration projects to be had
<Fazer2> haha
<Fazer2> I already chose to make some simple game with AI
<Riddell> put it in KDE :)
<Fazer2> Riddell: ha, if I'm satisfied with it ;-)
<Fazer2> Riddell: I can see launchpad builder shows only a few last lines of output and has to be refreshed manually, can it be changed?
<Riddell> Fazer2: no I think you just need to be patient, you can download the whole build log at the end
<Fazer2> Riddell: yeah, but it's not the same, Jenkins has an advantage here
#ubuntu-devel 2015-11-16
<pitti> Good morning
<pitti> popey: how is dropbox involved in a caja <-> apport crash?
<pitti> elbrus: no, it magically started working, apparently some dependency got uploaded/synced
<pitti> slangasek: I saw the kernel autopkgtest install failure on Friday, on my radar for today; if autopkgtest itself installs test deps it falls back to removing the pin, but that doesn't work if tests themselves call apt
<pitti> slangasek, infinity: yeah, I mentioned that in the announcement -- right now we dist-upgrade to -proposed as we have a lot of packages in the base image without any tests
<Mirv> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
<dholbach> good morning
<bipul> Good morning :)
<popey> pitti, dropbox has shell integration, I'm speculating, but it locks up every time I touch dropbox folders in caja
<popey> pitti, by "shell integration" I mean hooks into the file manager
<bipul> Hi.
<pitti> apw: can you see what's wrong in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux/20151116_071523@/log.gz ?
<apw> pitti, looking
 * pitti will look at the "crash" regression, that's infrastructure related
<apw> pitti, END ERROR ubuntu_qrt_kernel_aslr_collisions.test-kernel-aslr-collisions.py
<apw> pitti, we've got a whine out to #security about that one failing _a_lot_
<pitti> apw: want me to push the retry knob?
<apw> pitti, let me check if it always fails
<pitti> apw: I retried it once more, the previous failures were due to util-linux
<pitti> let's see
<pitti> it passed on 4.2.0-17.21
<apw> ok thanks
<pitti> apw: and it passed on i386 too
<pitti> otherwise I'll hint it to unblock binutils
<apw> then its likely random when it fails, i have someone looking to see if we can make it work better and quicker
<apw> but yes, if its blocking something in -proposed it is known and very likely not real
<pitti> apw: I fixed the "apt get source" case of "Temporary failure resolving" btw, the other is still on my list
<pitti> apw: thanks for checking; I had a hard time spotting the error in the log
<apw> and cirtianly the kind of error which means "we are less secure against attacks" than "functionally broken"
<apw> pitti, yeah they are all autotest under the hood so "END\ " is your search term
<pitti> good to know
<LocutusOfBorg1> good morning
<bipul> Hi, i have question. Do you mind if i discussed here.
<bipul> I don't know what's wrong with my gnome-terminal. It is getting vanished all of sudden (gnome-terminal). when ever i am trying to open it.
<tvoss> pitti, do you happen to know the launchpad project powering geoip.ubuntu.com
<tvoss> ?
<apw> pitti, i have asked for the "END"s to be summarised at the end of the run before exiting, much as adt run does
<seb128> tvoss, there are https://launchpad.net/ubuntu-geonames and https://launchpad.net/ubuntu-geoip but unsure that includes the geoip server side
<tvoss> seb128, ack
<seb128> ted or evan probably know better
<highvoltage> 4~/win last
<popey> morphis, in the bluez5 transition (specifically on touch) do we plan to add support for other device types? I'd like to have joypad support in if possible?
<morphis> popey: that depends, generally everything should be the same as before
<morphis> popey: but should be a lot easier to add new ones now
<morphis> popey: joypad, never heard of it before, it is a special gamepad?
<popey> morphis, no, just another word for the same thing
<popey> pretty sure "joypad" is what bluetooth calls them
<s1aden> mmm, joypad
<morphis> popey: which bt profiles does it support?
<s1aden> presumably it's just a HID device
<popey> it is
<pitti> utlemming: would it be possible to manually publish a more up to date xenial cloud image?
<popey> with lots of buttons and other interesting things
<morphis> popey: good, than this maybe just need a small adjustment in the settings app
<popey> morphis, would be good for a demo I wanted to make for the converged phone, playing a game with a bluetooth controller.
<morphis> popey: when do you want to do the demo?
<popey> Not any time soon.
<popey> Post OTA-9 for example
<morphis> popey: good
<morphis> popey: we're going to land bluez5 support in a bit
<morphis> popey: I can push up a MP after that for you to test
<popey> morphis, great, thanks.
<nobuto> pitti: hi, can you please move language-pack-ja-base and language-pack-gnome-ja-base from trusty-proposed to trusty-updates? we received such unmet dependency bug reports recently.
<nobuto> such as bug #1512262
<ubottu> bug 1512262 in language-pack-gnome-ja-base (Ubuntu) "language-pack-gnome-ja-base 1:14.04+20150804 not published in trusty-updates, cause language-pack-gnome-ja installation error" [Undecided,Confirmed] https://launchpad.net/bugs/1512262
<nobuto> and bug #1511405
<ubottu> bug 1511405 in language-pack-ja (Ubuntu) "Cannot install package language-pack-ja" [Undecided,Confirmed] https://launchpad.net/bugs/1511405
<pitti> nobuto: done, sorry about that
<nobuto> pitti: brilliant! no problem.
<pitti> cjwatson: hah, now LXC has started acting up for me as well, I can't start wily or xenial containers
<pitti> Failed to create root cgroup hierarchy: Permission denied
<pitti> Failed to allocate manager object: Permission denied
<pitti> cjwatson: sorry, can't remember any more -- was that what you were seeing?
<cjwatson> pitti: no, I was seeing http://paste.ubuntu.com/13247579/
<pitti> ah right, ns/mnt
<rbasak> mariadb-10.0 is on 10.0.22-0ubuntu1 in xenial's release pocket and 10.0.22-1 in xenial-proposed which FTBFS on some architectures so isn't migrating. The Debian maintainer will work on it in Debian. Will subsequent uploads to sid autosync? That is: does the autosync avoid stepping on merges by examining the release pocket or the proposed pocket?
<cjwatson> rbasak: It takes the newest in release or proposed.
<cjwatson> rbasak: So subsequent uploads should auto-sync, yes.
<cjwatson> rbasak: (The code is auto-sync in lp:ubuntu-archive-tools)
<rbasak> cjwatson: OK, thanks!
<cpaelzer> hi everybody, we have a bug and ask ourself what the right approach is #LP 1516543
<ubottu> Launchpad bug 1516543 in dpdk (Ubuntu) "dpdk-init depends on executables in /usr/bin" [Undecided,New] https://launchpad.net/bugs/1516543
<cpaelzer> Eventually we could: a) just add a path to /usr/bin/ b) fix the script to not rely oon /usr/bin (more complex)
<cpaelzer> is there anything against a) in terms of usual policy or best practise?
<rbasak> cpaelzer: is it an init.d script or something else?
<rbasak> cpaelzer: it seems pretty common for init.d scripts to set their own PATH at the top.
<cpaelzer> yes, it is an init script
<rbasak> Debian policy doesn't seem to say much about it.
<cpaelzer> rbasak that sounds good as it indicates it is somewhat common
<rbasak> I only know of https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html which is about maintainer scripts and says:
<rbasak> "Programs called from maintainer scripts should not normally have a path prepended to them. Before installation is started, the package management system checks to see if the programs ldconfig, start-stop-daemon, and update-rc.d can be found via the PATH environment variable. Those programs, and any other program that one would expect to be in the PATH, should thus be invoked without an absolute pathn
<rbasak> ame. Maintainer scripts should also not reset the PATH, though they might choose to modify it by prepending or appending package-specific directories. These considerations really apply to all shell scripts."
<rbasak> But maintainer scripts are called from a better defined environment (dpkg).
<rbasak> init.d scripts can't rely on much, so perhaps deviating from that and setting PATH manually is fine.
<cjwatson> One thing to bear in mind is that systemd units don't do any path expansion, so you end up having to execute specific paths for that anyway.  My solution for things I'm upstream for is to generate all the init files and substitute @bindir@.
<cpaelzer> rbasak, yeah I took a loog and you are right a lot of PATH= in /etc/init.d
<cjwatson> e.g. http://git.savannah.gnu.org/cgit/binfmt-support.git/tree/init
<cjwatson> I'm not really wild about hardcoding that way, but that ship has sailed regarding systemd so we might as well be consistent, and it's fairly tolerable if the substitution is automatic.
<cjwatson> At least if the executable is within your own package.
<cjwatson> Ah, but this bug implies that maybe we're talking about standard utilities in /usr/bin/ that aren't part of dpdk.
<cpaelzer> cjwatson - right
<cpaelzer> head and cut
<cpaelzer> for some text processing
<cjwatson> In that case, yeah, I'd tend to agree that ensuring that the directories you need are on PATH is OK, provided that you can guarantee that even if /usr is a separate mount it's always available by the time your init script runs.
<cpaelzer> smb, is dpdk be late enough in terms of dependencies to assume mounts are ok atthe time?
<rbasak> cpaelzer: so in this bug, systemd is calling the init.d script and not giving it a sane path? That's a shame.
<rbasak> I presume it's intentional if it is, but I don't like it :-(
<cpaelzer> rbasak, well I trust jamespages initial check that it only provides /bin and /sbin
<cpaelzer> never checked that detail of systemd
<smb> cpaelzer, Not really sure... the intention was to be relatively early to take away the nics as soon as possible
<cpaelzer> rbasak, smb - well then for simplicity lets consider dropping head&cut - any votes for the tool of choice?
<cpaelzer> sed ?
<cjwatson> systemd.exec(5) claims that systemd uses a fixed PATH of "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", which would be OK here.
<cjwatson> sed is usually pretty good for this kind of thing.
 * smb wonders whether cloud-images differ there... 
<cpaelzer> cjwatson - hmm, interesting find on systemd.exec
<cpaelzer> jamespage, are you around to share what you have seen in detail?
<smb> cjwatson, I think that should be possible and would combine two callouts into one
<rbasak> cjwatson: would that apply for ExecStart?
<rbasak> I didn't realise before but that's how this script is being called - not init.d
<jamespage> cpaelzer, I hit that error in a backport of dpdk to 14.04 - I need to reconfirm it on 15.10/16.04 as its possible that its working in later releases
<rbasak> Ah, no systemd.
<smb> rbasak, I tried to provide both ways
<jamespage> cpaelzer, that said this was not as startup - it was just calling the init script with 'start'
<rbasak> Ah, that makes more sense.
<rbasak> And there's the culprit
<rbasak> PATH="/sbin:/bin"
<jamespage> I set that to include /usr/bin and everything sprang to life
<rbasak> In debian/dpdk.init which ends up as /etc/init.d/dpdk
<rbasak> Sorry, I had completely misunderstood the problem.
<cjwatson> There we go.  But if it's early, using sed is still (overall) simpler.
<cpaelzer> rbasak, you still solved it faster than we did :-)
<marga> Hi, the files in http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/ are from Nov 4th.  The kernel there is 3.13.0-67-generic, but the latest kernel is already -68 since Nov 10th.  Any reason why the installer was not regenerated?
<cpaelzer> let me try create an sed to make sure we would work on the conditions of not yet mounted /usr as cjwatson suggested
<cjwatson> infinity,apw: ^- fancy doing a trusty d-i update?
<cpaelzer> but I'd still suggest we add that to the path in dpkg.init to not search for the issue again
<smb> cpaelzer, Ok, so this sounds like another item on my list
<cpaelzer> smb, let me give it a try
<rbasak> Related to me mariadb question earlier. We autosync from sid always nowadays, right? Even for LTses?
<cpaelzer> I'm done with paperwork
<cjwatson> rbasak: Yes.
<rbasak> OK, thanks for confirming.
<cjwatson> rbasak: Auto-syncing from testing turned out to be more trouble than it was worth.
<cpaelzer> smb, and that simple test probably needs a full day and would be bad to start now
<cpaelzer> smb, how would you prefer the patch ?
<cpaelzer> smb, it is not part of your git - hmm - merge proposal to lp:ubuntu/wily/dpdk then ?
<cpaelzer> on that bug?
<smb> cpaelzer, well this and probably the other things would be updates to the wily version as well... I can live with a simple diff
<cpaelzer> ok I'll post something in the bug later on and assign it to you then
<cpaelzer> smb, ok ?
<smb> cpaelzer, ok, wfm
<cpaelzer> rbasak, sorry but I can't set it to triaged, could you ?
<smb> cpaelzer, looks like I could too...
<smb> cpaelzer, done
<smb> cpaelzer, well only the dpdk part... lets ignore the cloud-archive half... :-P
<cpaelzer> smb, I agree
<rbasak> smb, cpaelzer: maybe an idea to throw the dpdk packaging into git and maintain it from there now?
<rbasak> (if we weren't already)
<cpaelzer> rbasak, smb, I'd love that
<smb> rbasak, well it is
<smb> rbasak, lp git... actually
<cpaelzer> smb, is https://git.launchpad.net/~ubuntu-server/dpdk what you work on ?
<smb> cpaelzer, yep... there is a wily branch and we could add a xenial one
<rbasak> smb: we should have upstream branches and tags that match the Ubuntu uploads.
<smb> cpaelzer, master I would use as upstream
<rbasak> Also ~ubuntu-server is available for everyone to force push to, including potentially vandals.
<rbasak> I'm not sure of a good solution to that issue, since you won't be able to push to ~ubuntu-server-dev.
<rbasak> We could have a separate ~dpdk-dev launchpad group I guess, but that seems overkill.
<cpaelzer> rbasak, let keep it there in SMBs hope to get rid of it one day anyway
<apw> cjwatson, thanks for hte heads up
<cpaelzer> and then move it to ~ubuntu-server-dev
<smb> cpaelzer, rbasak, I put it there on rbasak's request, but yeah maybe some group that is a bit more closed
<rbasak> The problem is that ~ubuntu-server-dev is a DMB-managed group and cpaelzer and smb won't be able to push there.
<rbasak> OTOH you could submit merge proposals and acceptance would effectively be an endorsement for upload of those changes.
<rbasak> smb, cpaelzer: I'm happy for you to decide what workflow you prefer between yourselves, and I'll support that ;)
<smb> rbasak, I guess there is one thing how to do it for now but maybe another thing how to properly do it for the future
<rbasak> In the future Launchpad will do something dgit-like and it'll all be like a bed of roses :)
<cpaelzer> rbasak, thorny roses?
<rbasak> No, nice-smelling ones :)
<smb> with thorns
<smb> :)
<smb> cpaelzer, btw I just pushed tags and current upstream to lp
<rbasak> smb: it would be useful to have packaging tags that correspond to Ubuntu uploads. Eg. ubuntu/2.0.0-0ubuntu1
<smb> rbasak, yeah now that there is an actual upload that makes sense
<cjwatson> Odd_Bloke: I don't know if you remember, but there's a missing --rename in the dpkg-divert handling for grub-probe in the cloud images
<cjwatson> Odd_Bloke: It's fixed in the patch set that landed in livecd-rootfs in the archive, but do you know if it might be possible to produce at least fixed wily/arm64 cloud images without having to wait for the full migration to LP to finish?
<cjwatson> Odd_Bloke: I ask because it's currently blocking upgrading arm64 scalingstack guests to wily, which we'd like to do as part of the "flail desperately until we find something that makes them more stable" plan
<smoser> slangasek, or infinity, do you plan on addressing my comment in https://bugs.launchpad.net/ubuntu/+source/distro-info-data/+bug/1508759 ?
<ubottu> Launchpad bug 1508759 in distro-info-data (Ubuntu Wily) "Update to include xenial" [Medium,Fix released]
<smoser> i'm guessing you just didn't see it. but we really should fix that completely.
<slangasek> smoser: if you want to upload, I'm happy to process the SRUs
<smoser> k.
<smoser> slangasek, uploaded.
<Odd_Bloke> cjwatson: I'm sprinting this week, would you mind filing a cpc-core bug and assigning it to me?
<Odd_Bloke> cjwatson: (I should be able to get to it, but I'll lose track of it amongst all the other stuff happening otherwise)
<infinity> marga: The installer doesn't need to be revved with every kernel bump.
<slangasek> smoser: I only see an upload in wily; was that the only one that was missing the full name?
<marga> infinity, uhm, but if you don't then errors like the one I mentioned in #u-kernel happen (i.e. update-initramfs triggered by dkms at the end of the installer fails, due to the running kernel not being installed in the chroot)
<infinity> marga: Guessing you're using a custom preseed with dkms?  I would consider that a dkms bug we should look at, if it tries to generate for a kernel that's not installed.
<smoser> slangasek, correct.
<smoser> everything else was right.
<smoser> wily went in before xerus was released as a name.
<infinity> marga: Anyhow, there will be a new d-i sometime this week for other reasons, but we don't rev stable d-i builds every single kernel.
<smoser> then the srus got the real name
<marga> infinity, yeah, a custom preseed that pulls in additional packages (in this case it's nvidia-dkms).  I guess the bug might be in update-initramfs
<marga> (the package isn't called nvidia-dkms, I meant to write nvidia's dkms package)
<infinity> marga: Err, yes, update-initramfs.  Do you have a log of the issue?
<marga> Yes, sec
<infinity> marga: FWIW, while we do update trusty's d-i ona fairly regular basis because we build dailies from it, we almost never update d-i in non-LTS stables (vivid, wily, etc), so this is a bug that should be filed and fixed.
<infinity> marga: Can you file a bug in initramfs-tools and point me at it?
<marga> yeah, if you are sure that's it
<marga> I'll give you paste of the error in a sec
<marga> infinity, http://paste.debian.net/333067/
<marga> Should I go ahead and open the bug?
<infinity> marga: Well, that'll either be a bug in initramfs-tools or in dkms for calling it incorrectly, but do file the bug on one of them and give me the #, I can figure it out when I have some time.
<marga> ok, thanks
<tsg> ScottK: wanted to check with you on backports - bug 1515710 and bug 1516259 - critical for openstack swift.  If there is additional validation I can provide, I will be happy to
<ubottu> bug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New] https://launchpad.net/bugs/1515710
<ubottu> bug 1516259 in Precise Backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to precise" [Undecided,New] https://launchpad.net/bugs/1516259
<mterry> chiluk_, that trusty update of coreutils is ftbfs
<chiluk_> really?
<chiluk> I know I ran build tests, because I'm running the package on my desktop as we speak
<chiluk> mterry are you building with pbuilder again?
<mterry> chiluk, I mean it's ftbfs in the buildd servers, when it hit trusty-proposed
<chiluk> huh... but it builds for you locally right?
<chiluk> yeah mterry, just verified, I definitely built that debdiff locally... coreutils is such a pita.
<marga> infinity, https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1516705
<ubottu> Launchpad bug 1516705 in initramfs-tools (Ubuntu) "update-initramfs fails during debian-installer if running kernel doesn't match installed kernel" [Undecided,New]
<marga> Sorry for the delay, got caught up in other things
<mterry> chiluk, it doesn't build for me locally in pbuilder, as we discussed.  I never did the sbuild setup, since I figured that was a PITA for me if you had already done it
<chiluk> yeah pbuilder does something weird with it..
<chiluk> E: Build failure (dpkg-buildpackage died)... well that's weird
<chiluk> mterry 1 of 423 tests failed
<infinity> marga: S'ok, won't be as bad as the delay for me investigating/fixing. :P
<infinity> marga: Thanks for filing, though, I'll look when I have a bit of time to context switch out of mainframe land.
<marga> infinity, that's fine
<chiluk> mterry FAIL: tests/df/total-unprocessed.sh
<marga> You got me thinking with the non-lts thing
<marga> This issue used to happen for us A LOT when we were using the hardware enablement installers for precise. But we are still using trusty's installer for trusty and it hasn't happened in over a year or so, I guess this is why.
<chiluk> mterry .. I'm rebuilding again now... just to sanity check..
<infinity> marga: Without looking, I suspect the bug is that dkms triggers an initramfs build for all kernels, not just the one it built modules successfully for, but I'll have to investigate a bit to see what's really happening.
<cking> pitti, who can we asked to get https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1491729/ moving a bit further on the SRU process?
<ubottu> Launchpad bug 1491729 in dkms (Ubuntu Wily) "dkms: add module build ordering for ZFS on Linux" [Undecided,New]
<chiluk> mterry  PASS: tests/df/total-unprocessed.sh
<chiluk> worked for me.
<chiluk> very confusing.
<mterry> chiluk, I suspect it will work for you locally again.  I think this is a difference between buildd and local sbuild.  yeah
<chiluk> yeap
<marga> infinity, dkms actually realizes that it's in this weird situation and does the right thing with regards to module building, so I think the fault lies at update-initramfs for not realizing.
<chiluk> I'll take a closer look at the test.
<infinity> marga: Well, no.  If dkms knows what kernels it built for, it should only be triggering update-initramfs for those kernels, IMO.  But I could be off, and it could be using a generic trigger that just sucks at its job.  We'll see when I dig.
<chiluk> hmm mterry it appears as if the only difference is df is printing directional ticks and compare on the buildds isn't liking that.
<chiluk> mterry give me a sec to see if I can figure out if I did that or if we can change that somehow.
<chiluk> mterry yeah it has something to do with the smart quotes being printed by df..
<chiluk> which is super odd.
<chiluk> I'm not seeing that out of sbuild, but am seeing it when I run the test manually
<chiluk> which is also nuts.
<mterry> chiluk, well...  good that you can reproduce?
<chiluk> yeah give me a sec to see if I can fix it so we don't have to disable the tests.
<cjwatson> That'll probably be LANG=C vs. LANG=C.UTF-8
<cjwatson> or similar
<cjwatson> though launchpad-buildd currently uses LANG=C, so the symptoms seem backwards
<cjwatson> unless I'm misunderstanding
<cjwatson> Odd_Bloke: OK, sure - filed https://bugs.launchpad.net/cpc-core/+bug/1516715 but I can't assign it to you because I'm not a cpc-core bug supervisor
<ubottu> Error: launchpad bug 1516715 not found
<chiluk> thanks cjwatson.. I think you are on the right track.. I'll try setting the LANG explicitly in the test case, and hopefully that will help
<cjwatson> chiluk: Yep, sounds sensible
<chiluk> cjwatson, I think it's a new test, but setting LANG=C in the test itself seems to resolve the issue.
<chiluk> mterry .. do I need to create a new bug to fix the FTBS?
<chiluk> cjwatson: what's the process for fixing ftbs
<chiluk> when it's failing in -proposed?  open a new bug, increment source version reupload?
<cjwatson> chiluk: I'm sure I'm out of date, but I can't see why a new bug is needed
<chiluk> cjwatson, mterry, so what's required here?
<cjwatson> chiluk: just upload a fix?
<chiluk> I'm not coredev yet..
<cjwatson> well, get a sponsor to do so
<chiluk> but I'll upload a new debdiff..
<chiluk> does the debdiff have to be versioned newer than the ftbs?
<cjwatson> you can't reuse the same version, indeed
<chiluk> ok.. I wasn't sure if that was required..
<cjwatson> use 8.21-1ubuntu5.3
<chiluk> that's newer..
<cjwatson> the reason it shouldn't need a new bug is that the bug is principally required for tracking verification, and a build failure fix to something that's already on its way through -proposed for a different reason doesn't need separate verification
<cjwatson> chiluk: err ... yes it is
<cjwatson> I meant it to be
<cjwatson> your debdiff should be on top of 8.21-1ubuntu5.2, and should result in a new package versioned 8.21-1ubuntu5.3
<chiluk> Ok.. that's what I thought.
<chiluk> thanks.
<cjwatson> because you cannot reuse 8.21-1ubuntu5.2, and there's certainly no reason to pretend it never existed
<chiluk> right..
<chiluk> mterry arges ...fix for ftbfs uploaded https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871
<ubottu> Launchpad bug 1432871 in coreutils (Ubuntu Trusty) "`df` shows bind mounts instead of real mounts." [Low,Fix committed]
<chiluk> it seems to resolve it when run outside of a chroot on my local machine where the lang is set to  en_US.UTF-8
<chiluk> do you want me to run a test build on the buildd's first?  I really don't think that should be necessary
<apw> pitti, i added that [!ppc64el] test dependancy to fix the ppc64el linux package install failures, but it seems it is not valid
<apw> pitti, if i am reading this dep_re correctly it only supports positive [arch] lists
<cjwatson> dep_re where?
<apw> autopkgtest lib/testdesc.py
<apw> which isn't a big deal i guess we don't change the list very often
<mterry> chiluk, I can try uploading in a bit
<mterry> chiluk, sorry was afk for a quick errand
<chiluk> no worries mterry we all have life to deal with.
<chiluk> mterry I uploaded it to my ppa in case you want to wait a sec to see if it builds.
<chiluk> mterry should be almost done
<mterry> chiluk, oh nice
<chiluk> mterry coreutils has been such a pita..
<mterry> chiluk, :)  every package is its own sweet little pile of pain
<chiluk> mterry still FTBFS.
<chiluk> maybe I forgot to add it to 00list
<mterry> chiluk, I'm so glad Debian got behind quilt instead of dpatch or others  :)
<mterry> Still can forget to add to series, but just much harder to mess up
<chiluk> yep that was my problem.. working too fast.
<chiluk> well crap mterry still failing...
<chiluk> mterry it looks like the testcase is failing, but after playing around a bit it looks like there's a similar regression somewhere.. where df -t nfs isn't reporting filesystems.
<chiluk> so that's not good.
<mterry> chiluk, hrm
<chiluk> that should probably be remedied.
<mterry> chiluk, so yay for tests  :)
<chiluk> yeah.. so the the testcase is incorrectly failing as far as I can tell.
<chiluk> there's definitely something going odd.
<mterry> chiluk, oh sorry I thought you said there was a real regression
<chiluk> yeah there is a real regression
<chiluk> the testcase didn't really find it.
<mterry> chiluk, ah  :)
<chiluk> but I found it while playing around with the commands the testcase is testing.
<mterry> chiluk, so yay for busted tests!  :)
<chiluk> yeah something like that
<mterry> chiluk, this regression is trusty-specific?
<chiluk> it's all in similar logic.
<chiluk> haven't figured that out yet.. but I'll definitely check upstreams.
<chiluk> basically df -t nfs isn't finding nfs shares.
<chiluk> so that's odd.
<mterry> hm
<chiluk> but the test case somehow finds a - mount.
<chiluk> which is beyond me.
<chiluk> anyhow I'll need a few to get this squared away.
<chiluk> mterry looks like wily's affected as well.
<chiluk> I guess it's better for us to discover it than someone else ..
<chiluk> it might even be an upstream issue.
<Odd_Bloke> cjwatson: Thanks for that; looks like utlemming has picked it up. :)
<jibel> bdmurray, hi, about bug 1494442, could you count the crashes for ubuntu-touch/rc-proposed/* instead of ubuntu-touch/devel?
<ubottu> bug 1494442 in Canonical System Image "Turn crash generation off by default for phone on stable channel" [High,Fix released] https://launchpad.net/bugs/1494442
<bdmurray> jibel: where * = ubuntu or something else?
<jibel> bdmurray, I'd be interested in ubuntu, bq-aquaris.en and meizu.en
<bdmurray> jibel: updated
<jibel> bdmurray, thanks
<bdmurray> no problem
<chiluk> mterry so I just compiled upstream coreutils, and df has the same issue with remote filesystems..
<ScottK> tsg: you might check with micahg.
<tsg> thanks ScottK
<tsg> micahg: I was wondering about bug 1515710 and bug 1516259.  This is a fairly simple backport and I can provide any validation needed (already have validated the wily pkgs work on trusty and precise)
<ubottu> bug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New] https://launchpad.net/bugs/1515710
<ubottu> bug 1516259 in Precise Backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to precise" [Undecided,New] https://launchpad.net/bugs/1516259
<chiluk> mterry, so after stepping through the code, it looks like the move to /proc/mountinfo has had some odd side effects.
<chiluk> this is because the filesystem type is now more accurate.. for example it's no longer just nfs , it's nfs4.
<chiluk> so I don't think this is a regression.. more of a change in behavior.
<chiluk> but one that's necessary.
<mterry> chiluk, ok
<mterry> chiluk, so we don't do anything?
<chiluk> mterry do you know the correct way to disable a test?
<mterry> chiluk, we can't fix the test?
<chiluk> I'm still trying to figure out why it's failing.
<chiluk> I'm basically not getting the same output ..
<mterry> chiluk, well there's no standard way to disable a test, because there are so many frameworks.  Often a patch to comment it out.  Or a debian/rules adjustment to skip it if possible.  But skipping tests is obviously the least preferable way to solve the problem
<chiluk> yeah.. I'll look a little closer.. but setting the LANG=C in the test directly didn't seem to help
<mterry> chiluk, odd
<mterry> chiluk, dumb question , but did you forget to maybe export it, instead of just set it?
<chiluk> well looking at the build log.. it seems that we are actually getting output from "df --local -t nfs --total ."   from within the buildd.
<chiluk> where the error is expected.
<chiluk> it might be a cgroups related failure.
<chiluk> mterry http://pastebin.ubuntu.com/13303587/  that's the part that's causing the failure.
<mterry> chiluk, so is that just because it's using nfs instead of nfs4?
<chiluk> it almost makes me wonder if the filesystem being mounted to / in the buildd is somehow local and nfs.
<chiluk> cjwatson, are the buildd's run under kvm or cgroups?
<chiluk> df shouldn't have any outpu on that test.
<chiluk> but something is weird enough about the buildds that it gets confused
<mterry> chiluk, I'm going eod, good luck :-/
<chiluk> thanks for all the help mterry.
<sarnold> chiluk: check the build logs, there's some hints about what it does; iirc all the builders are virtualized these days, but within those VMs, they also use chroots, managed by an sbuild that may or may not be similar to the sbuild that we use on our dev workstations
<chiluk> yeah.. that's the weird thing.. sbuild succeeds locally for me.
<chiluk> sarnold: it's something particular to the buildds
<chiluk> sarnold:  see http://pastebin.ubuntu.com/13303587/
<chiluk> sarnold basically the testcase is expecting df to fail.
<chiluk> but for some odd reason it's working fine at least on trusty
<chiluk> that didn't get hit on wily or vivid
<chiluk> which is also strange
<sarnold> chiluk: i'm quite surprised that --local -t nfs doesn't throw a fit
<chiluk> yeah it's supposed to.
<chiluk> and it does for me locally
<chiluk> but not on the buildds
<chiluk> which is why it's so odd.
<sarnold> chiluk: that -is- odd :) that's a good one, hehe; can you plop a 'strace' in front of that thing and try to figure out the series of systemcalls it's working with?
<chiluk> sarnold it's just going to be processing /proc/mountinfo
<chiluk> I know this code fairly well at this point.
<sarnold> chiluk: ltrace then?
<sarnold> chiluk: heh, sorry to hear that :)
<chiluk> hah yeah.. me too.
<chiluk> sarnold: df doesn't really make any library calls.. it statically includes gnulib.
<cjwatson> chiluk: Speaking as a heavy gnulib user, gnulib serves two purposes: it provides replacement functions if autoconf says that something's missing from the system, and it provides various utility functions of its own.  For functions in the former category, seeing a function in included gnulib source does *not* imply that df won't prefer the version from libc if it works properly.
<cjwatson> The point of gnulib isn't to statically link libc into everything that uses it :-)
<chiluk> cjwatson, I said df statically links with gnulib not libc
<cjwatson> chiluk: Yes, but the bits of gnulib that might substitute for library calls that df would otherwise make are basically libc.
<chiluk> I'll check to see if it's making libc calls, but I don't think there's any code for an equivalent to mountlist
<cjwatson> df certainly does make library calls.
<chiluk> yes it does..
<chiluk> I"m not arguing that.
<cjwatson> But sure, mountlist is linked in directly.
<chiluk> I just don't think those library calls are affecting this build.
<chiluk> then again I wont' know till I know.
<cjwatson> sarnold: The sbuild in use is nowadays extremely close to that in the archive.  You can find it in ppa:~canonical-is-sa/ubuntu/buildd
<chiluk> cjwatson can you take a look at http://pastebin.ubuntu.com/13303587/ , and tell me why the rootfs comes up as - ?\
<cjwatson> sarnold: We're currently in a state where for upcoming xenial-based builders it will be identical.
<sarnold> cjwatson: cool, thanks!
<cjwatson> chiluk: Not sure just from looking, or from looking at the source - definitely a case where it will be quicker to slap ltrace -S on the front than to try to guess
<chiluk> alrighty will do.
<cjwatson> chiluk: The buildd's FS is certainly not NFS.
<chiluk> yeah it's super f-ed up... My locally built version succeeds on that test.. so there's something strange still going on.
<cjwatson> chiluk: Each x86 builder instance is an OpenStack instance, so kvm will be involved in there, and then as sarnold says there's sbuild under that (though using sudo chroot rather than schroot for mainly historical reasons).
<cjwatson> chiluk: However, if you're seeing this on all architectures in a build for the Ubuntu primary archive, some of them are still just bare metal.
<tsimonq2> wxl: where?
<tsimonq2> aw crap, sorry
<chiluk> alright I'll pick this up tomorrow .. I have to meet a friend for dinner.
<cjwatson> chiluk: While there isn't an equivalent of mountlist, I believe that mountlist uses various libc functions such as getmntent
<chiluk> cjwatson: yes it used to
<chiluk> but with the move to /proc/mountinfo and /proc/self/mounts it processes those directly now
<chiluk> which may be part of the problem.
<cjwatson> Well, I was looking at the version you uploaded, but maybe not very closely.
<cjwatson> Anyway, bed.
<chiluk> yeah have fun cjwatson thanks.
<chiluk> i really appreciated it..
<chiluk> cjwatson: afaik all the getmntent calls get ifdefed out.  i will verify that though.
#ubuntu-devel 2015-11-17
<pitti> Good morning
<pitti> apw: hm, https://www.debian.org/doc/debian-policy/ch-relationships.html says that they are supported with !
<dholbach> good morning
<dholbach> mvo_, do you know where http://pastebin.ubuntu.com/13309322/ could be coming from?
<mvo_> dholbach: hm, thats usually if the wily.tar.gz and wily.tar.gz.gpg are out of sync, could you try again as user without the sudo and see if that makes a difference?
<dholbach> mvo_, now it seems to work - it didn't work in update-manager earlier, which is why I switched to do-release-upgrade
<mvo_> dholbach: I suspect network/proxy or similar effects :/
<dholbach> ok, thanks
<apw> pitti, right they are normaly, it seems that the regexp that extracts them for tests/control doesn't expect !
<popey> pitti, got my cpu spinning on apport with caja again, what debugging should I do?
<popey> pitti, http://paste.ubuntu.com/13310423/ is a few moments of strace from apport
<pitti> apw: oh! that does sound something that can be fixed easily
<pitti> read(4, "651-475c-811c-ce2' failed: No su"..., 4096) = 4096
<pitti> popey: that looks interesting
<pitti> popey: can you look into /proc/<apport pid>/fd/4 what this points to?
<pitti> read(4, "glibtop(c=4170): [WARNING] statv"..., 4096) = 4096
<pitti> that too
<pitti> that could be a d-bus call
<popey> lr-x------ 1 root root 64 Nov 17 09:40 /proc/22274/fd/4 -> /var/crash/_usr_bin_caja.1000.crash
<pitti> uh, wth
<popey> -rw-r----- 1 alan whoopsie 67466388 Nov 10 14:50 /var/crash/_usr_bin_caja.1000.crash
<popey> from days ago
<pitti> ok, this is apparently from reading the previous file to determine the CrashCounter: value
<popey> would you like me to file a bug against apport perhaps?
<pitti> popey: yes, easier for tracking, that doesn't seem a trivial issue
<popey> okay, any additional logs I should attach?
<pitti> popey: is it still looping over reading from fd 4 if you attach strace now?
<pitti> popey: please don't kill it yet, I'd first like you to run some experiments which would reproduce this
<popey> okay. It's making my laptop hard to use though, just so you know :)
<popey> http://paste.ubuntu.com/13310583/ is the latest from the strace log
<pitti> $ python3 -c 'import apport.fileutils; print(apport.fileutils.get_recent_crashes(open("/var/crash/_usr_bin_caja.1000.crash", "rb")))'
<pitti> popey: ok, so still looping over reading the old file; what does that ^ say for you and how long does it take?
<popey> pitti, that doesn't feel like it's going to finish any time soon :) 24328 alan      20   0   78124  30796  10508 R  89.8  0.2   0:26.35 python3
<popey> that's now eating a core too
<pitti> popey: oh, good! so that reproduces it
<popey> :)
<pitti> popey: so you can kill apport
<popey> yay
<popey> and the python3 thing?
<pitti> popey: can you scp that .crash to people.u.c., or just attach it to the bug (if you are reasonably sure it doesn't have s3kr1t stuff in it), so that I can try here?
<popey> sure
<pitti> popey: you can kill it too
<pitti> popey: but please try again if it still hangs after you killed apport, to be sure
<popey> pitti, it does
<pitti> popey: cool; so we have a much easier handle on this
<pitti> popey: if I can reproduce it with your .crash file, then you are entirely off the hook :)
<popey> woot!
<popey> uploading now
<popey> pitti, https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1516947 is the bug for it, link to crash in the bug
<ubottu> Launchpad bug 1516947 in apport (Ubuntu) "apport looping on an old crash dump" [Undecided,New]
<popey> thanks for the help!
<Mirv_> heh
<Mirv_> @pilot out
<Mirv> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> popey: reproduces fine, thanks!
<popey> super
<Mirv> (not really pilotting for 27h)
<halfie> hi, the .deb packages seem to be missing from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc1-wily/
<halfie> which is a bit unusual
<cyphermox> good morning!
<mdeslaur> hi cyphermox!
<seb128> hey cyphermox mdeslaur
<tsg> micahg: checking in to see if you would have a few to take a look at bug 1516259 and bug 1515710 today. Thanks!
<mdeslaur> hi seb128
<ubottu> bug 1516259 in Precise Backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to precise" [Undecided,New] https://launchpad.net/bugs/1516259
<ubottu> bug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New] https://launchpad.net/bugs/1515710
<LocutusOfBorg1> hi, who is patch piloting today? I have a quick and easy SRU to ask you :p
 * LocutusOfBorg1 is joking, there is no easy SRU, but a really difficult one
<LocutusOfBorg1> sometning like this  2729 files changed, 779602 insertions(+), 142675 deletions(-)
<nils17> perhaps anybody knows it in this channel: where can I disable the warning "granted permissions without asking for password" when I execute e.g.   gksudo nautilus ?
<seb128> LocutusOfBorg1, you can try barry or TheMuso (though he's probably eod for a while) or bdmurray
<barry> LocutusOfBorg1: i'm around, but have a couple of other things on the stack atm.  give me some info and i'll try to take a look
<LocutusOfBorg1> barry, I'm doing test builds right now
<LocutusOfBorg1> TLTR: I need to upgrade virtualbox-precise as SRU from 4.1.12 to 4.1.44
<LocutusOfBorg1> and trusty from 4.3.26 to 4.3.34
<LocutusOfBorg1> I already did the same for debian, with a great success
<LocutusOfBorg1> and I'm starting from that version to do the same for ubuntu
<LocutusOfBorg1> (also wily needs fixing, but we can just SRU with the xenial version)
<barry> LocutusOfBorg1: ok.  i'm not a virtualbox expert, so i might defer, but i'll take a look when you're ready
<LocutusOfBorg1> the rationale is many CVE fixes, stability fixes, and kernel building again
<LocutusOfBorg1> thanks
<LocutusOfBorg1> I'm going to open a bug to keep track of patches if it is ok for you
<barry> yes please!
<rbasak> pitti: please could you see bug 1511899? What's the logic for where /bin/running-in-container should belong now? If in init-system-helpers, then do we just need a versioned breaks/replaces for upstart?
<ubottu> bug 1511899 in init-system-helpers (Ubuntu) "init-system-helpers and upstart need to conflict/replace" [High,Triaged] https://launchpad.net/bugs/1511899
<rbasak> It seems upstart 1.13.2-0ubuntu17 doesn't ship /bin/running-in-container.
<pitti> rbasak: hallyn moved it to i-s-h in bug 1442228; can't say I'm happy about this as it's a permanent delta, but that's the status quo
<ubottu> bug 1442228 in lxc (Ubuntu) "lxc fails to start inside vivid container" [Critical,Fix released] https://launchpad.net/bugs/1442228
<pitti> rbasak: so I guess i-s-h needs to B/R: upstart (<< 1.13.2-0ubuntu13)
<rbasak> pitti: OK so I'll just upload a Breaks/Replaces then?
<rbasak> Ack.
<pitti> rbasak: in the long run I'd rather get rid of it
<hallyn> i did what?
<rbasak> hallyn: https://launchpad.net/ubuntu/+source/init-system-helpers/1.22ubuntu10
<rbasak> hallyn: a necessary Breaks/Replaces has gone missing since, though I see that you did upload one originally.
<rbasak> Maybe some move between upstart and upstart-bin?
<hallyn> hm
<pitti> could also be a merge error in i-s-h
<pitti> (much more likely, as the B+R need to go there, not into upstart)
<rbasak> Yeah looks like a merge error.
<hallyn> woulda preferred systemd depend on upstart? :)
<rbasak> I'll upload a fix.
<hallyn> where do we need running-in-containers these days?  maybe it's too early for me to thinkabout this.
<pitti> probably only an archive grep can tell
<pitti> mostly in LXC, but a few otehr packages might have picked it up too
<gQuigs> is udisks2 something we plan to support for a long time?
<seb128> gQuigs, is it being replaced?
<seb128> but I guess it any case even if it is that's not for the coming LTS
<gQuigs> seb128: trying to convince adobe to move off of hal, and want to make sure it's not going anywhere
<seb128> so yeah, we probably keep to support udisks2 for a while
<pitti> the only potential replacement today is storaged, but we haven't looked at that so far, and it's D-BUS API compatible (it says, anyway)
<gQuigs> awesome, so I'll recommend they move to use the D-BUS api
<gQuigs> thanks!
<didrocks> ximion: hey! after Laney poke me about some appstream-dep11, I did fix it and create a PR: https://github.com/ximion/appstream-dep11/pull/1
<didrocks> ximion: I tried to summarize my findings as much as possible on the description, do not hesitate to tell me if you think I should do any modification
<ximion> didrocks: neat, thank you!
<ximion> using setuptools properly was on my todo-list even, but admittedly at a very low position ;-)
<Laney> I tried to install a checkout in a virtualenv and it didn't work
<Laney> so invoked the didrocks :P
<didrocks> ximion: yw! Indeed, I guess those kind of crashs are the only way to motivate changing things that basically worked :p
<didrocks> ximion: oh, I didn't write it on the PR, but I reinstalled on our machine a new blank virtualenv with my branch, installed it there and did a successful run
<ximion> didrocks: that's a pretty interesting bug you've found there - I wasn't aware that this couls happen at all...
<didrocks> ximion: I wasn't aware about that __spec__ + multiprocessing either beforeâ¦ today :p
<ximion> btw, initially the python3-dep11 module was meant to be used by Python applications reading DEP-11 data, so there initially was a split between all the database/building stuff in scripts/ and read-only stuff in dep11. That just made things harder anyway, so the change is fine
<ximion> (and actually, reading DEP-11 in Python is as simple as safe_load'ing a YAML file)
<ximion> didrocks: multiprocessing leads to some very weird and hard-to-debug issues...
<didrocks> yeah, that was my feeling when reading the code
<didrocks> ximion: I'm using futures module now, not sure if there is a constant pool functionality though
<ximion> for example, one that I still haven't tracked down, opening a LMDB database in the main process and then starting multiprocessing doesn't work - the child processes simply return without an error, and that's it
<ximion> so we now close the db and reopen it everytime :-/
<didrocks> (but it's quite nice for ThreadPoolExecutor and ProcessPool)
<didrocks> urgh, yeah, that's why it's quite slow I guess
<didrocks> that was your comment on calling "fork_server", I saw this
<ximion> that even was a different story at first, involving an issue with apt_pkg, which is now fixed...
<ximion> the code was fast once, but in order to not double-process data from different suites, we unfortunately need to give the generator access to the database. Which results in better data and increased speed
<ximion> I am not happy with how that thing looks, especially the icon-searching code is insane - but it's working well now
<ximion> (and a proper fix would be to enforce stricter icon-naming and placement for applications, which won't happen anytime soon)
<didrocks> ximion: yeah, we had a similar issue with ubuntu-software-center as far as I know, I guess you have a similar insane icon-naming search path :/
<Laney> I think we're going to have to fix humanity
<didrocks> (I guess Laney is talking about the theme) ;)
<didrocks> the meaning will be harder to fix :p
<didrocks> other*
 * seb128 votes for Laney
<ximion> didrocks: mvo told me that at Debconf, made me feel a bit better - I still feel a bit guilty for sending my GSoC student through that ^^
<ximion> at least since the "appstreamcli validate-tree" command is used by some upstreams, they all started to name their .desktop files and MetaInfo files corectly and added missing tags \o/
<sergiusens> cyphermox, hey, random question, if I apply for PPU no, do I become an ubuntu member or is that a separate process?
<cyphermox> sergiusens: you should mention in your application that you want to apply for ubuntu member too, but it's documented as being granted at the same time.
<sergiusens> cyphermox, great; last question, can I reuse an application or should start from scratch?
<cyphermox> sergiusens: fwiw it's a discussion we're having : https://lists.ubuntu.com/archives/devel-permissions/2015-August/000815.html
<cyphermox> sergiusens: if you already have an application wiki page done, by all means feel free to reuse it ;)
<sergiusens> cyphermox, I do, from my previous PPU request :-) (which at the time thought included Ubuntu Membership) ;-)
<sergiusens> cyphermox, thank you
<rbasak> slangasek: could you advise on bug 1507151 please? Is the appropriate fix just to call insserv from sysv-rc.postinst with a hardcoded path, or should we drop or alter the insserv delta?
<ubottu> bug 1507151 in sysvinit (Ubuntu) "sysv-rc.postinst calls insserv by name, but insserv package does not provide the command in a bin directory" [High,Triaged] https://launchpad.net/bugs/1507151
<LocutusOfBorg1> barry, lp: #1517161
<ubottu> Launchpad bug 1517161 in virtualbox (Ubuntu) "virtualbox SRU for CVE" [Undecided,New] https://launchpad.net/bugs/1517161
<LocutusOfBorg1> :)
<LocutusOfBorg1> BTW can anybody please sponsor an easy backport? https://bugs.launchpad.net/wily-backports/+bug/1512982
<ubottu> Launchpad bug 1512982 in wily-backports "Please backport hedgewars 0.9.22-dfsg-2 (universe) from xenial" [Undecided,New]
<LocutusOfBorg1> upstream is bothering me about it, because of the online game features
<LocutusOfBorg1> (users are asking upstream to update, and upstream is asking me to do it)
<LocutusOfBorg1> and I'm asking you :p
<barry> LocutusOfBorg1: okay, i opened a tab.  no promises - i seem to be just getting swamped :/
<LocutusOfBorg1> barry, no problem :)
<LocutusOfBorg1> please consider that sponsoring the upload will fix at least 200 bugs
<LocutusOfBorg1> :D
<slangasek> rbasak: you are describing a different bug than what was reported in bug #1507151.  The submitter's system apparently had no trouble locating insserv?
<ubottu> bug 1507151 in sysvinit (Ubuntu) "sysv-rc.postinst calls insserv by name, but insserv package does not provide the command in a bin directory" [High,Triaged] https://launchpad.net/bugs/1507151
<slangasek> rbasak: oh - no, I see, the maintainer script gives a generic error and the real error is in the log.  ok.  Yes, the postinst already does "Make sure insserv is in the path", so it just needs /usr/lib/insserv to be part of that path, I think
<smoser> hey...
<smoser> i have a curtin testcase that fails sometimes
<smoser> whathapens is that it ends up not powering off the system even though poweroff was called.
<smoser> wondering how i'd get more data out of that.
<smoser> cloud-inti invokes shutdown -P now
<smoser> and then system just doesnt seem to go down
<slangasek> smoser: and you say this is intermittent?
<smoser> seemingly
<slangasek> I'm not sure what systemd debugging options are available on shutdown
<slangasek> smoser: do you get the kernel's "powering off" message at the end?
<smoser> no.
<smoser> itll finish like http://paste.ubuntu.com/13316912/
<slangasek> hmm
<smoser> the cloud-init message is after it has invoked shutdown (and it has received SIGTERM after having done so)
<slangasek> what's the kernel commandline? is ttyS0 the only console?
<smoser> [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.19.0-33-generic root=UUID=ef812a22-0d30-4d05-b0ba-8a46c02777f2 ro console=ttyS0 luks=no nomdmonddf nomdmonisw
<smoser> heres a very verbose log http://paste.ubuntu.com/13317017/
<slangasek> seb128: I see you synced fop, which brought in two new build-dependencies not in main; are you planning to do the MIRs for these?
<seb128> slangasek, I've that somewhere on my todolist but rather low, feel free to steal it from me if you want ;-)
<Unit193> slangasek: Did you get a chance to re-review the MPs after the fix?
<slangasek> smoser: well, the verbosity we need here is from the kernel+init, which is still lacking; I think you need to get systemd logging more verbosely to console, which I don't know how to do offhand - pitti would of course know if he's around
<slangasek> seb128: I don't want to do them, I want the people causing the mismatches to follow through ;P
<smoser> systemd.log_target=kmsg systemd.log_level=debug maybe
<smoser> i'll try
<slangasek> Unit193: hi, sorry can you give me the pointer to the MPs again?
<seb128> slangasek, right, I sort of agree, though technically I just put back in sync since the delta was good to drop the new version would have come through autosync then without me :p
<slangasek> Unit193: I don't remember seeing new emails, so either the MPs weren't 'resubmit'ted or I missed the mails somehow, sorry
<seb128> slangasek, speaking about following through, do you know if doko is around? unsure what to do with packagekit in xenial-proposed, it seems there is no concrete plan to deal with it in a reasonable timeframe and it's going to block other things
<Unit193> slangasek: https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167
<slangasek> seb128: I haven't spoken to doko today; but I don't think doko's packagekit merge implies any kind of committment to follow through on the issues you outlined.  Maybe we should kick that back out of xenial-proposed?
<slangasek> Unit193: cheers, queued for looking at this afternoon
<seb128> slangasek, yeah, that's what I was going to do, I just wanted to hear back from doko first
<Unit193> Great, thanks.
<nagromlt> is there a good channel for ubuntu support?
<Unit193> nagromlt: #ubuntu is for support.
<nagromlt> thx
<tsg> doko: any ideas on who could help with https://bugs.launchpad.net/trusty-backports/+bug/1515710
<ubottu> Launchpad bug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New]
<jetsaredim> pitti: any comments on a workaround for the following bug?
<jetsaredim> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1491658
<ubottu> Launchpad bug 1491658 in linux (Ubuntu) "systemd[1]: Failed to insert module 'kdbus': Function not implemented" [Medium,Expired]
<Unit193> jetsaredim: What's the bug?
<sarnold> pitti: (I suggested jetsaredim head here and ask you about it, it feels funny to see systemd require kdbus moments after fedora yanked kdbus from the distro -- https://lists.fedoraproject.org/pipermail/devel/2015-October/216235.html )
<Unit193> sarnold: It's not so much that systemd requires it, but it tries to load it if it exists and thus gives output if it doesn't.  It works like it always has.  If you want, you can try the kdbus-dkms package (from Debian experimental only, IIRC.)
<sarnold> Unit193: oh, is -that- it? just a silly informational message?
<jetsaredim> the system won't boot past that
<Unit193> sarnold: It's insignificant unless you have kdbus-dkms, pretty much.
<Unit193> jetsaredim: Maybe, but that's not the issue.  You'll see that on any wily boot.  [    8.683505] systemd[1]: Failed to insert module 'kdbus': Function not implemented   here locally.
<jetsaredim> Unit193: other way around i think
<jetsaredim> hmm
<Unit193> jetsaredim: Nah, if you have kdbus-dkms, you likely want it loaded.  Otherwise just ignore it.
<jetsaredim> maybe i grabbed the wrong error line
<Unit193> (And FWIW, I personally wouldn't recommend kdbus.)
<jetsaredim> just noticed the last line before the systemd freeze message is something about mtab not being a symlink
<jetsaredim> I certainly didn't go out of my way to set up kdbus
<Unit193> That's the issue, and was a known Xenial bug.
<Unit193> LP 1511376
<ubottu> Launchpad bug 1511376 in ubiquity (Ubuntu Xenial) "install writes /etc/mtab as file, not symlink" [High,Fix released] https://launchpad.net/bugs/1511376
 * Unit193 passes it back to sarnold.
<jetsaredim> hm
<jetsaredim> ok
<jetsaredim> i'll give that a rty
<jetsaredim> *try
<jetsaredim> even
<sarnold> Unit193: many thanks :)
<jetsaredim> sorry for the confusion
<Unit193> sarnold: Sure, glad I was actually able to help you!
<sarnold> pitti: aha, nevermind, Unit193 covered it nicely, suggested 1511376 is the cause of the problem :)
<smoser> slangasek, http://paste.ubuntu.com/13318228/
<smoser> theres a 15M pastebin there for you.
<jetsaredim> so, small-ish?
<smoser> jetsaredim, yeah.
<jetsaredim> seems like the fix is - boot to recovery then create link and then init 2?
#ubuntu-devel 2015-11-18
<dupingping> https://bugs.launchpad.net/lightdm/+bug/1517309
<ubottu> Launchpad bug 1517309 in Light Display Manager "X run again." [Undecided,New]
<pitti> smoser, slangasek: booting with systemd.log_target=console will make the logging visible to the console if you don't want it in the journal; systemd.log_level=debug only increases verbosity of systemd itself -- if you want also kernel debugging, use "debug" (the kernel reads that by itself)
<pitti> logging to kmsg is also useful in some cases, mostly if the journal is broken
<pitti> sarnold, jetsaredim: err, do you still see bug 1511376 with current images? I'm not aware of anything else right now that still creates broken /etc/mtab, what/how did you install?
<ubottu> bug 1511376 in ubiquity (Ubuntu Xenial) "install writes /etc/mtab as file, not symlink" [High,Fix released] https://launchpad.net/bugs/1511376
<pitti> and yes, you can ignore kdbus, it's not at all related
<jetsaredim> pitti: it got sorted
<jetsaredim> thanks
<pitti> jetsaredim: still some installer problem?
<jetsaredim> turns out systemd was complaining about a fstab entry for a mdadm device that had yet to be created in the boot cycle
<pitti> that still sounds like a bug
<jetsaredim> it was a user-created md
<jetsaredim> if that matters
<jetsaredim> I regularly have issues with the system every time it reboots having to go in and manually stop & re-assemble the dev
<pitti> I mean, MD arrays are supposed to be auto-assembled at boot, and if fstab wants to mount something from it it should wait until that has happened
<pitti> so apparently the waiting part works, but not the assembly
<jetsaredim> it certainly waited
<jetsaredim> yea
<jetsaredim> not sure what's with my config i don't reboot the system that often so it only comes up about twice a year
<jetsaredim> its like the auto-config that's supposed to happen on boot is just not smart enough to do it right
<jetsaredim> when the system's finally up and I can login I literally just have to run "mdadm -S <dev>; mdadm --assemble <dev>" and all is right with the world
<jetsaredim> which you'd *think* would work during boot too...
<nils17>  Does any one have an idea: when executing the command (alt+f2)  gksudo xfce4-terminal I get the warning "granted permissions without ask for password"... do you know where this setting is stored? (to disable it)
<dholbach> good morning
<FourDollars> pitti: Could you help to review https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326 for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381625 ?
<ubottu> Launchpad bug 1381625 in linux (Ubuntu) "Adjust brightness to lowest value caused screen whole black" [High,Confirmed]
<pitti> FourDollars: that looks more or less like a straight port of the upstream gnome-settings-daemon heuristics, right?
<FourDollars> pitti: yes
<pitti> replied
<pitti> FourDollars: this is loads better than https://code.launchpad.net/~kaihengfeng/unity-settings-daemon/add-brightness-limit-mechanism/+merge/277416 :)
<FourDollars> pitti: yup
<FourDollars> pitti: Thx a lot. BTW, when will it be merged into lp:unity-settings-daemon if everything is OK?
<pitti> FourDollars: it's CI train managed, so I guess you can just reuqest a landing
<FourDollars> pitti: How can I request a landing?
<pitti> FourDollars: there's a new system, https://requests.ci-train.ubuntu.com/
<pitti> I haven't used it myself either yet, but hopefully not too different from the old spreadshet
<pitti> otherwise the desktop team can certainly help you with that
<seb128> that system is to do landings though
<seb128> not to request somebody else to do one for you
<pitti> right, but can't FourDollars request/do a landing?
<seb128> and we do regular u-s-d landings when there are enough changes to justify one
<pitti> ah, ok
<seb128> pitti, dunno what team membership is needed
<seb128> if you have upload rights you can
<seb128> but FourDollars probably doesn't have upload rights on the desktop set
<FourDollars> Yup, I don't have the upload rights.
<pitti> seb128: I thought that was the purpose of the train?
<pitti> most phone developers don't have archive upload rights either
<seb128> right
<seb128> I think there is a lp team you need to join though
<FourDollars> Ha~ After I login https://requests.ci-train.ubuntu.com, there are many pages I can not access.
<seb128> better to ask on #ubuntu-ci-eng
<LocutusOfBorg1> dupingping, hi, you there?
<LocutusOfBorg1> wrt your virtualbox pkg join request
<dupingping> LocutusOfBorg1: yes, i'm here.
<LocutusOfBorg1> why did you request to join?
<LocutusOfBorg1> that team is well... empty
<dupingping> debian virtualbox team?
<LocutusOfBorg1> you asked to join to the ubuntu virtualbox team, not the debian one
<LocutusOfBorg1> I maintain virtualbox, but I use the alioth debian infrastructure for doing it
<LocutusOfBorg1> anyway, do you plan to contribute in virtualbox?
<dupingping> yes, right.
<dupingping> And what is launchpad.net url for join?
<LocutusOfBorg1> https://alioth.debian.org/projects/pkg-virtualbox
<dupingping> LocutusOfBorg1: I created a new account.
<dupingping> It shows me, https://launchpad.net/~pkg-virtualbox-devel and "Debian Virtualbox Team" team.
<dupingping> wow, I have been joined.
<dupingping> thank you.
<LocutusOfBorg1> yes, but there is nothing to do on launchpad
<LocutusOfBorg1> you need to apply to alioth
<dupingping> oh, yes.
<dupingping> I logged in to alioth, LocutusOfBorg1
<LocutusOfBorg1> before accepting you I would like to see some patches, or some work on virtualbox
<LocutusOfBorg1> it is a really deep package, and *really* difficult to maintain
<dupingping> yes, i'll show a patch on oracle i made.
<LocutusOfBorg1> e.g. you might start with testing this https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1517161 :)
<ubottu> Launchpad bug 1517161 in virtualbox (Ubuntu) "virtualbox SRU for CVE" [Medium,New]
<dupingping> can you see https://forums.virtualbox.org/viewtopic.php?f=37&t=74546&p=345693#p345693 ?
<LocutusOfBorg1> "You are not authorised to read this forum."
<dupingping> yes, perhaps, you are not a virtual box contributor on oracle?
<dupingping> virtualbox 5.0.x's revision r58717 is my patch.
<cpaelzer> smb and I were discussing about the proper use of debian/watch
<cpaelzer> we wondered if it should be encoded in a way to refer to the latest "possible" tarball
<cpaelzer> or the latest tarball to the currently packaged version
<cpaelzer> e.g. if we have Package-2.0 - should it
<cpaelzer> a) only fetch and report 2.0.x updates
<cpaelzer> b) or any >2.0 updates
<cpaelzer> rbasak (and others) ^^ ?
<pitti> cpaelzer: if you package multiple major upstream series, restricting it to the current microversion of that series seems adequate
<LocutusOfBorg1> hi folks, is the ci sleeping today?
<LocutusOfBorg1> http://autopkgtest.ubuntu.com/packages/v/virtualbox/xenial/amd64/
<LocutusOfBorg1> I don't see the tests going
<FourDollars> pitti: I saw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381625 is changed to "Won't Fix" by you. Could you help to change it back to Confirmed?
<ubottu> Launchpad bug 1381625 in linux (Ubuntu) "Adjust brightness to lowest value caused screen whole black" [High,Confirmed]
<pitti> FourDollars: ah, you can't? done
<pitti> ("in progress")
<FourDollars> pitti: I don't have the permission to do that.
<FourDollars> pitti: In fact, I also want to fix it in trusty. But I don't have the permission to also affect trusty series too.
<pitti> FourDollars: added
<FourDollars> pitti: thx
<cpaelzer> pitti: thx
<rbasak> cpaelzer: it's entirely up to you. For an Ubuntu-only package there isn't anything that runs uscan automatically for you. So debian/watch is only as useful as your ability to run uscan. So make uscan do what you want :)
<cpaelzer> rbasak, thanks++
<FourDollars> pitti: Could you help to set https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326 as a top approved?
<pitti> FourDollars: done
<FourDollars> pitti: Cool. Thx.
<Laney> cjwatson: What's the status on the ppc64el/wily upgrade?
<Laney> We have gtk+3.0 -> mir -> liburcu blockage coming up. :)
 * Laney sees some comments on the ticket
<cjwatson> Laney: waiting for IS to see if wily images work on arm64 this time, then I should be able to ask for ppc64el/production shortly after
<Laney> 'k
<cjwatson> Laney: ah, progress on the ticket so I've replied asking for ppc64el/production
<Laney> cjwatson: Oh, great, thanks
<dupingping> hi lightdm developers.
<smoser> pitti, thanks for following up.
<pitti> smoser: what? where?
<Mirv> could a core-dev do a QA acked copy to xenial (train is not understanding our switch of one binary package to new source package, so publishing manually): ./copy-package --from=~ci-train-ppa-service/ubuntu/landing-005 --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed -b ubuntu-ui-toolkit - everything else is done
<Mirv> ticket https://requests.ci-train.ubuntu.com/#/ticket/670
<pitti> Mirv: done
<MrBIOS> good morning, would anyone who is familiar with the casper/livecd boot process happen to be around? Iâm trying to debug some stuff and not having much luck
<MrBIOS> bdmurray: ping
<bdmurray> MrBIOS: hi
<MrBIOS> bdmurray: I wanted to ping you regarding an (old, sadly) casper ticket https://bugs.launchpad.net/ubuntu/+source/casper/+bug/504103
<ubottu> Launchpad bug 504103 in casper (Ubuntu) "textonly parameter has no effect when booting from usb-stick" [Medium,Triaged]
<MrBIOS>  any reason why thatâs gotten zero love in four years? :"(
<bdmurray> MrBIOS: Is that really the question you want me to respond to?
<MrBIOS> well, if thereâs a known workaround, Iâd happily employ that
<MrBIOS> Iâm unfamiliar with the Ubuntu bug triage process
<MrBIOS> all I really want to do is accomplish an install
<Laney> xnox: you want to take the mdadm merge off me?
 * Laney spots the new maintainer :)
<bdmurray> There are lots and lots of bugs and this one only affects a couple of people, based off the bug, and is something of a corner case.
<bdmurray> Are you trying to install a desktop version of Ubuntu?
<MrBIOS> bdmurray: yes, Iâm definitely in corner-case-land
<MrBIOS> deep into it. I should set up a fort
<MrBIOS> out of curiosity, do you guys accept man page improvements? :)
<bdmurray> MrBIOS: Of course we'd accept a fix.
<MrBIOS> bdmurray: Iâm also getting an error when scripts/casper-bottom/25adduser gets called, where the  step fails with âpwconv: failed to change the mode of /etc/passwd- to 0600â and I have no idea why. Is that a known issue? I see it a lot in google searches, but not as the focus of attention
<MrBIOS> this is unfortunate, since I then have no way to log in to examine log files to figure out why things arenât progressing further
<bdmurray> What release are you installing and how did you create the usb stick?
<MrBIOS> this is 16.04, and I DDâed the ISO to the stick.
<MrBIOS> the same thing happens with 15.10 and earlier though
<tsg> micahg: can you please comment on https://bugs.launchpad.net/trusty-backports/+bug/1515710?  what is needed to resolve this - there are 3 openstack bugs that are pending on this request, so I can provide any help needed
<ubottu> Launchpad bug 1515710 in vivid-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to precise, trusty, vivid" [Undecided,New]
<tsg> micahg: the trusty and precise backports are more critical
<Laney> cjwatson: https://launchpad.net/ubuntu/+source/liburcu/0.9.1-2/+build/8293095 excellent
<cjwatson> Laney: liburcu built now; will just need a bit of proposed-NBS cleaning
<Laney> hah
<cjwatson> yep :)
<cjwatson> ppc64el guests are wily now
<Laney> thanks for getting that fixed
 * Laney nods
<cjwatson> np
<Laney> maybe autopkgtest will be less extremely backed up by tomorrow morning
<Laney> gtk's triggered tests have barely moved all day
 * Laney floats some more clouds
<slangasek> according to pitti the queue is about a day long currently
<cjwatson> Laney: liburcu2 proposed-NBS cleaned up too.  so now it's just whatever remains from that library transition
<cjwatson> (2 -> 4)
<Laney> Yeah. I'll look when update_output.txt has something to say about the matter tomorrow
<Laney> 'night
<lpotter> is there any way to edit my comments on a bug in launchpad?
<dobey> no
<smoser> hey
<smoser> is this a known issue
<lpotter> awe: ping
<awe> lpotter, pong
<lpotter> awe: in regards to nm bearer plugin. upstream has been refactored a bit, so it might benefit to use that
<lpotter> I thought it had already been updated to it
<awe> lpotter, has the code been released by upstream yet?  or is it just part of their latest devel?
<awe> I'm super new to the Qt codebase
<awe> I only started looking at as I started chasing this bug
<lpotter> I am sure it was released
<awe> ok, I'll poke around this afternoon
<awe> it'd be great if they've already fixed this match rule leak
<awe> it looks to me like a ref count problem
<awe> as I'm never seeing the match rules ever get released by QDBusConnectionPrivate
<lpotter> well, I refactored all objects so the are derived from QDBusAbstractInterface
<lpotter> the old code is pretty fugly
<awe> lpotter, I think the current code does that
<awe> eg. QNetworkManagerInterfaceAccessPoint does so
<awe> and it's the obect that's not properly disconnecting a signal watch for "PropertiesChanged"
<awe> it also apparently sends a "GetAll" in response to the "PropertiesChanged" signals
<awe> which is kinda broken too
<lpotter> hmm.. I must have wrong ubuntu repo or something. all I see is original really ugly code
<awe> well.... I've actually downloaded the source package from the phone overlay PPA
<awe> as I didn't want to hunt for the VCS
<lpotter> upstream uses the property map from PropertiesChanged
<awe> when you say upstream, do you mean the 5.5 release, or code in devel branch?
<awe> I just cloned the git5 repo...
<lpotter> should be 5.5 but I could be wrong. I've lost track of Qt releases
<awe> this is a slippery slope
<awe> lpotter, k
<awe> I'll take a look this afternoon...  so close to solving this bug, which has a *huge* perf impact
<lpotter> yes 5.5.0 release has the changes
<awe> ok; I'll def compare our code to that branch then
<lpotter> :q
<micahg> tsg: commented
<lpotter> awe: but then the problem will be those blocking dbus GetAll calls when those objects are created. Which cannot really be changed as QNAM depends on syncronous backends
<awe> lpotter, so... in the bug I'm working on, it sounded like "blocking" was an ambiguous term
<awe> are you describing "blocking IO"?
<lpotter> blocking as it waits until is gets an answer
<awe> or apparmor "blocking"?
<awe> got it
<awe> we're on the same page then
<lpotter> :)
<awe> Mirv mentioned something about "apparmor blocking"
<lpotter> there's that too.
<awe> I care less about that, as it's a confined app problem, and I'll let others solve it
<lpotter> which is why I wrote and suggested the connectivity-api plugin
<awe> I'm just trying to ensure the plumbing works when used by unity, maliit, ...
<awe> and doesn't gum up the rest of the system
<awe> we have a security team to worry about apparmor, and they're all smarter than me anyways...
<awe> ;D
<lpotter> :)
 * awe hopes the qt submodules don't eat all his diskspace
<lpotter> at least its not aegis
<lpotter> because of app armor restrictions on phone, all thats really needed in bearer is connected/disconnected
<awe> for confined apps you mean?
<awe> because the system apps need to distinguish between connected 'wifi' vs. connected '3g'
<awe> and I think every process also needs to know about flight-mode
<awe> and/or individual 3g blocked, wifi blocked
<lpotter> do they use QtBearerNetwork?
<lpotter> I meant for things using QNetworkAccessManager and QNetworkRequest & friends
<awe> it's a bit confusing, and I can't answer all of those questions directly
<awe> as I don't know the code bases all that well
<lpotter> if they use QNetworkConfigurationManager than yes, that connectivity-api will not be useful
<awe> ( I typically work on ofono, NetworkManager, ... )
<awe> lpotter, https://bugs.launchpad.net/ubuntu-rtm/+source/location-service/+bug/1480877/comments/68
<ubottu> Launchpad bug 1480877 in location-service (Ubuntu RTM) "Access points' "PropertiesChanged" dbus signals freeze UI on mobile devices" [High,In progress]
<awe> this doesn't include all system processes, but it mentions the ones that show up in my dbus scans
<lpotter> cleanup code rely's on Qt's own object clean up. but if that is delayed due to parent not getting deleted for long time I can see thats a problem. with app armor on top those signals wont get disconnected straight away.
<awe> so again... this is only when used from unity8 directly, which should be totally unconfined
<lpotter> hmm maybe QDBus does things differently
<awe> I'm assuming if the layer can add dbus signal match rules
<awe> it can remove them
<awe> if it can't
<awe> it's badly broken
<awe> I see the correct calls happening in the networkmanager plugin
<awe> it's just that qtdbus doesn't seem to be removing the rules
<awe> it looks like the rules are ref counted
<awe> so someone's holding on to a ref somewhere
<awe> I'm rebuilding with a bit more debugging added to qtdbus
<lpotter> I think the logic in QNetworkManagerEngine::removeAccessPoint is wrong. Are you seeing the QNetworkManagerInterfaceAccessPoint d'tor getting called?
<awe> yes
<awe> Also, I enabled QDDBUS_DEBUG=1
<awe> before starting  Unity
<awe> I see a log message that tells me the DBusConnection.disconnect() function succeeded
<lpotter> it looks like when an AP is known to the system, the accessPoint object will not get deleted when it is removed
<awe> but what I don't see is a corresponding "Removing match rule..." from QDBusConnectionPrivate
<awe> it looks like the intention is to reference count them
<awe> and remove if/when someone calls disconnect()
<awe> and the ref-count == 1
<awe> the code in 5.4.1, doesn't explicitly disconnect in that destructor
<awe> bottom line is NM is continually adding and removing AccessPoint objects
<awe> so the plugin needs to track them, and adjust it's match rules on the fly
<awe> otherwise we swamp the dbus daemon
<awe> as the plugin just continues to add match rules till WiFi is disabled, or the phone dies and/or reboots
<lpotter> I assumed that those got disconnected when it gets desctructed
<awe> when what gets destructed? the AccessPoint object?
<lpotter> yes. internally to QDbus
<awe> I looked at the doc for DBusConnection and it doesn't mention auto-disconnect for signals anywhere
<awe> well.. it's not working automatically, and it's not working if I try to explicitly disconnect either
<awe> ;(-
<lpotter> there is also a problem if two AP's have the same ssid
<awe> also, I wrote a small QtCoreApplication and played around with connect/disconnect
<awe> and was able to properly add a match rule for the same AP
<awe> and then remove it by calling disconnect
<awe> so the DBus code works
<lpotter> so the engine is holding on to an object :)
<awe> lpotter, yea... as previously discussed this is all no-op code
<awe> thanks for all your thoughts on this
<awe> I'll know more if my build ever finishes
<awe> by the way, I diffed our code to 5.5.1 and 5.6
<lpotter> I usually try to build only QNetwork library or plugin
<awe> and there's very little different in qnetworkmanagerservice/enginer
<lpotter> ok
 * lpotter wonders where that repo is
<awe> however there's quite a bit different in qdbusintegrator.cpp
<awe> lpotter, the ubuntu repo?
<lpotter> yes, with the newer plugin
<awe> well, from what I can tell... our version of Qt isn't that different than the Debian package ( at least that's what it looks like from the debian/changelog )
<lpotter> there doesnt seem to be one master-of-all
<awe> I'm not sure it was worth us importing into a VCS
<awe> but Mirv_ would know better than I
<awe> again, I just grabbed the source package from the phone overlay PPA, and extracted it locally.  Some I working with quilt
<awe> the base is 5.4.1+dfsg-2
<awe> with the "dfsg-2" being what appears to be the Debian version
<awe> I've got the upstream git5 repo cloned though, so that's what I'm using for comparison against our source package
<lpotter> it's nearing chaos hour where kids wake up and go to school...
<stgraber> awe: +dfsg means that the source tarball was repacked by the Debian maintainer to conform to the Debian Free Software Guidelines, so you'll probably be getting a fair amount of diff compared to upstream just for that
<stgraber> awe: there typically is documentation as to how the dfsg tarball was generated in debian/ either in a README or as code in debian/rules
<awe> stgraber, thanks!
<lpotter> not sure I know how to grab the phone overlay PPA
<awe> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages
<lpotter> thanks
<awe> you can download the orig tarball, debian diff, and dsc files, and reconstruct with dpkg-source
<tsg> micahg: thanks - will resubmit using requestbackport - thanks for your attention!
#ubuntu-devel 2015-11-19
<tsg> micahg, kitterman: submitted backport request again as suggested - https://bugs.launchpad.net/trusty-backports/+bug/1517713
<ubottu> Launchpad bug 1517713 in trusty-backports "Please backport liberasurecode 1.1.0-2 (main) from xenial" [Undecided,New]
<tsg> ScottK: ^^
<pitti> Good morning
<didrocks> good morning pitti
<pitti> bonjour didrocks !
<RAOF> Aloha didrocks, pitti!
<didrocks> hey RAOF!
<Mirv> lpotter: only Qt packaging is in git, and mostly it's as a branch of Debian's packagings like irssi http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/log/?h=ubuntu
<Mirv> lpotter: for in-use package you'd do dget file.dsc by finding the .dsc file from for example https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?batch=75&memo=150&start=150
<Mirv> s/irssi// :)
<lpotter> hmmm
<dholbach> good morning
<lpotter> Mirv: so how does the bzr repo fit in? it doesn't seem to be used at all
<Mirv> lpotter: depends which bzr. the old packaging bzr:s have been emptied and declared obsolete, but there are also the automatic Ubuntu branches that are not that useful at the moment since the vivid overlay is PPA separate from Ubuntu archives, and 5.5 is not yet in xenial archives either.
<lpotter> specifically qtbase
<lpotter> https://code.launchpad.net/ubuntu/+source/qtbase-opensource-src is what I am looking at
<lpotter> https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/qtbase-opensource-src/wily this seems to contain 5.0.2
<Mirv> lpotter: right, you're correct, they are completely obsolete. I haven't had an explanation though why some of them are totally stalled and some seem to import the latest package.
<Mirv> lpotter: as another example, https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/qtdeclarative-opensource-src/wily seems to be just correct
<Mirv> the good thing about /ubuntu/ branches is that they include the whole source, so they're easier to work with. I've local bzr:s of those 5.4.1/5.4.2 branches that need updates (usually just qtbase/qtdeclarative) so that I can cleanly use bzr builddeb with them
<Mirv> I create them with dget <url.dsc> ; bzr init ; quilt pop (repeat so that all are popped) ; bzr add * .qmake.conf ; bzr commit -m import
<rkuska> Hello, regarding your latest decision of making Python3 the default interpreter in Ubuntu 16.04, whats your plan with Samba?
<seb128> hum, is https://errors.ubuntu.com stucked on "loading..." for others as well?
<seb128> ah, loaded now
<seb128> so maybe just slow
<pitti> wgrant: can we open https://translations.launchpad.net/ubuntu/xenial/+language-packs ?
<seb128> pitti, cjwatson opened xenial translations some weeks back
<seb128> aren't the langpack automatically enabled when a serie opens?
<pitti> I figure LP needs to adjust the cronjobs for the exports
<pitti> wgrant: export on Sunday/build on my side on Monday seems to be a free slot?
<cjwatson> seb128,pitti: I didn't completely open it, I did part of the steps and then handed over to ubuntu-translations-coordinators@, and got no response: http://paste.ubuntu.com/13344194/
<pitti> cjwatson: ah, thanks
<pitti> dpm: ^ what is the next step there?
<dpm> cjwatson, pitti, the ubuntu-translations-coordinators is not really active anymore. However, I generally look at the e-mail. For some reason I missed this one, though :/
<dpm> the e-mail seems to list all steps already, but let me double-check
 * xnox waves hi
<pitti> hey xnox
<dpm> cjwatson, pitti, I think the next steps are simply to make the translations visible in LP and setting the focus to Xenial. I can do that now.
<cjwatson> dpm: our master list says that should be after cron jobs are set up, though I suppose it doesn't matter *too* much
<cjwatson> dpm: https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings
<dpm> yeah, I think it's fine. Translators can start doing their jobs before the cron jobs are set up
<dpm> I've just approved a couple of templates in the imports queue and going through the rest quickly
<dpm> I think after that I can just open them in LP
<cjwatson> pitti,wgrant: I agree that the Sunday export slot seems clear.  Is "30 10 * * 0 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu xenial --force-utf8-encoding -q --log-file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log" OK for you then?
<pitti> cjwatson: Sunday export is fine for me (can't speak about the rest, but I suppose that's c&p)
<cjwatson> Yeah
<dpm> cjwatson, pitti, translations are now visible and focus is set to xenial. cjwatson, one last thing: could we add a cron job to export translations for xenial? IIRC, it's a matter of enabling it in a cron job, similarly to https://code.launchpad.net/~dpm/lp-production-crontabs/add-wily-l10n-stats/+merge/266073
<cjwatson> dpm: see immediately above
<cjwatson> dpm: oh, you mean stats, not translations
<cjwatson> dpm: sure, I can include that in the same ticket
<dpm> cjwatson, I think we're talking of a different type of export: I mean the .json export for translation stats
<dpm> yeah, that'd be great, thanks
<cjwatson> *mutter* that's such an evil job
<cjwatson> I must have another go at those webservice exports at some point
<cjwatson> dpm: I'm just waiting for webops to get the crontab back in sync with reality after the last change before I propose this
<dpm> ok, thanks!
<Laney> tyhicks: hey, I'm just merging dbus and I'm reminded of https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1489489 - do you think we can get dropping this method targetted for this cycle?
<ubottu> Launchpad bug 1489489 in dbus (Ubuntu) "The org.freedesktop.DBus.GetConnectionAppArmorSecurityContext() method is deprecated" [Medium,Triaged]
<Laney> It'd be good to not have to carry the patch into the release
<cjwatson> marcoceppi: can you see what's going on with the CI failures on https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/xz-indexes/+merge/277880 ?  they look like testbed issues to me ...
<cjwatson> (but I'm not sure)
 * popey hugs xnox 
<cjwatson> pitti,dpm: OK, this is RT#86504 now
<kenvandine> pitti, ubuntu-system-settings is blocked on some autopkgtests that say they're in progress but the tests aren't actually running
<Laney> kenvandine: that means they're in the queue
<pitti> kenvandine: yes, the queues are still very long
<kenvandine> ah... is there a way to view the queue?
<kenvandine> it's been more than 24 hours, figured it would have been done by now :)
<pitti> I now added some capacity (let's see how long it'll hold), but lots of xenial uploads + lots of them being KDE (long tests) plus lots of kernel tests from stables plus troubles with cloud -> taking ages :(
<kenvandine> i'd imagine
<pitti> kenvandine: queue view> yes, but not publicly yet; I'm working on it
<kenvandine> ok, thx for the info
<kenvandine> pitti, ok, cool
<Laney> really?
<Laney> with that management plugin or something?
<seb128> unsure what to do about such issues, is that dpkg bugs?
<dpm> thanks cjwatson
<seb128> https://errors.ubuntu.com/problem/a00c6c70c46827e0854c65da57937aa7bd2d14b1
<seb128> " 	
<seb128> Processing triggers for mime-support (3.59ubuntu1) ...
<seb128> dpkg: error processing package libbsd0:i386 (--configure):
<seb128> package libbsd0:i386 is already installed and configured"
<seb128> same with https://errors.ubuntu.com/problem/923088c36748eaa801974b5e87dd89022f3f12b8 " triggers looping, abandoned?"
<pitti> Laney: you know how to get the queue count; I think queue contents can be done with the mgmt plugin
<pitti> Laney: or that trick to read the entire queue without ack'ing (I'll see if that scrambles the order; if not, that's fine)
<Laney> pitti: ah, yeah, I thought you meant you had a prototype of contents
<matsubara> psivaa, hi, do you know what happened to https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix/+merge/258620?
<tyhicks> Laney: hello - I think it is doable
<psivaa> matsubara: that was waiting for a little too long for merging i suppose, and was pinged a couple of times regarding that in #ubuntu-ci-eng by those cleaning up Ubuntu sponsoring queue. I had to delete that
<matsubara> psivaa, hmm ok, rbasak was ready to review it...
<psivaa> matsubara: https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix is the personal branch for that. please feel free to fork it
<rbasak> matsubara: the other one was https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298 which also 404s.
<rbasak> psivaa: do you want anything merging right now?
<matsubara> rbasak, right, likely it was deleted in the same way. I can't find om26er around here, so I'd ask him
<teward> need some guidance on a bug fix... https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1517865 indicates there is an fd leak in a package, yet to fix it the only way we can really 'fix' it is to update the corresponding included third-party module in the package, is that SRU-qualified or do I have to hunt and peck for a specific upstream patch that only fixes the issue?
<ubottu> Launchpad bug 1517865 in nginx (Ubuntu) "nginx-extras push module fd leak" [Undecided,New]
<rbasak> teward: generally a cherry-pick is what is required for an SRU.
<rbasak> teward: that doesn't mean you have to do it. If only one person has been affected in 18 months since release, it seems pretty low priority to me. You could ask the reporter to identify the cherry-pick.
<teward> (I already know the cherrypick, there's a Debian bug on it)
<teward> but Debian's solution was to just update the module
<psivaa> rbasak: not at the moment
<rbasak> OK, thank.s
<hallyn> stgraber: if there is a security update on package foo, do init scripts in foo which are marked as no-restart-on-upgrade get restarted in that case?
<stgraber> hallyn: no
<stgraber> hallyn: standard behavior is to write to /run/reboot-required and /run/reboot-required.pkgs
<stgraber> hallyn: which will show the reboot warning in MOTD and if on desktop, the matching notification
<stgraber> that's what e.g. network-manager does
<stgraber> and those packages' postinst typically write to reboot-required for every update, so not trying to be clever and do it only for security (because you can be sure someone will forget about it)
<hallyn> i thought maybe th epackaging would look at the priority or pocket...
<hallyn> hope springs eternal
<stgraber> hallyn: it could but I don't believe we have any precedent for doing so and it wouldn't trigger on backports, PPA builds and uploads to the dev release
<hallyn> yeah tha's no good
<hallyn> obvoiusly foo=lxcfs.  so i'm thinking that we need to have a hook triggered from the host to the container to re-mount.  anyway, still testing
<stgraber> hallyn: since we're stateless the best really would be to have a way to re-exec without dropping the fuse connection, but that'd likely need a bit of fixing in libfuse
<stgraber> security updates upstart-style
<hallyn> where's jodh when you need him
<stgraber> well, I hear we got xnox back :)
<xnox> hallyn, hello.
<stgraber> hallyn: an alternative would be to split 99% of lxcfs into a library that we dlopen into a tiny bit of code which is the daemon. On update we can signal the daemon to reload the library and use it. Limiting the amount of stuff we can't update without breaking all containers.
<hallyn> yeah
<hallyn> i know, a dbus service :)
<stgraber> how about, no? :)
<xnox> if one is stateless, re-exec whilst keeping sockets open and passing them across should be trivial, no?!
<xnox> without even a library split.
<xnox> with extra magic systemd unit restart commands.
<xnox> hallyn, ^
<stgraber> yeah, I'm just not sure of how that'd affect fuse
<stgraber> our code wouldn't mind for sure, libfuse might
<xnox> one can totally reuse systemd socket activation for that, to serialise opened sockets to keep them for re-exec.
<xnox> stgraber, well, true.
<hallyn> the dlopen might be complicated by  our now threaded nature...
<hallyn> xnox: lxcfs is not completely stateless.  in particular fuse keeps pointers on directory entries to cached data (for open files/dirs) in our memory
<hallyn> so if we go the dlopen way we could perhaps add a version # to those structs and invalidate any versions older than our curren tone (bump version # on every dlopen)
<hallyn> i suppose dlopen must be process-wide, so just doing it once under a global mutex should suffice
<stgraber> Looks like some folks published a re-fuse paper back in 2010 or so where they describe how to allow respawning a fuse fs on crash without affecting existing users. I'm not finding any code for that though...
<hallyn> simpler way would be to have containers bind-mount a ms_slave directory from host which has lxcfs mounted under it;  have lxcfs register a start hook that prints the container's name into a file;  have lxcfs on start trigger a hook in each contaner named in that file to re-set the mountpoints
<hallyn> not has elegant
<stgraber> and from past experience, very tricky to get right, wrt running random binary in the container from the host in a safe way :)
<stgraber> had some problems when we were doing that in apport :)
<hallyn> the dlopen method would require a mutexed count of # of threads running in the api right now
<hallyn> so on every api call we would grab whatever is the fastest userspace lock there is; bump the use count; drop the lock; do the call; get lock; drop count; drop lock;
<hallyn> then for re-exec we would grab  a big mutex, set NO_NEW_API_CALLS true; grab the little lock, check for use count == 0; drop lock; spin until count is 0; do new dlopen; dset NO_NEW_API_CALLS false; drop the big lock
<hallyn> or mayb we can just keep a refcounted list of dlopen() results
<hallyn> (where 'on reexec' means when we get a sighup)
<teward> so, should I be concerned if my schroots in sbuild can't update to Xenial because libuuid1 throws postinstall fails
<teward> (Xenial)
<infinity> teward: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804167
<ubottu> Debian bug 804167 in libuuid1 "fails to upgrade" [Serious,Open]
<infinity> teward: It's specific to your host system being somewhat mismatched with the chroot, but will be fixed soon anyway.
<hallyn> stgraber: https://github.com/lxc/lxcfs-pkg-ubuntu/pull/2 look ok ?
<stgraber> hallyn: so I'm not sure that the killmode change is actually required.
<stgraber> hallyn: I mean, we do want "systemctl restart" and "systemctl stop" to work with lxcfs, we just don't those called on upgrade
<hallyn> yeha, wasn't sure.  i'll revert that
<bdmurray> Laney: Your glib2.0 upload to the Wily SRU queue seems to have no LaunchpadBugsFixed
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<pgquiles> why can't I comment on developer.ubuntu.com/blog ? Always a "CSRF verification failed" error :-(
<pgquiles> zbenjamin: re your post on the new ubuntu-sdk- packages, shouldn't a "Conflicts:" in debian/control take care of the removal of qtcreator and qtcreator-plugins-* ?
<dobey> pgquiles: Breaks: would do it
<teward> infinity: okay, odd though that creating a fresh schroot doesn't appear to trigger the same problem.
<teward> only the 'upgrade' portion
<teward> thanks for the info though :)
<pgquiles> dobey: shouldn't one use Conflicts: in this case? According to the Debian Policy, "Conflicts should be used when two packages provide the same file and will continue to do so", which is the case e. g. with /usr/bin/qtcreator in qtcreator and ubuntu-sdk-ide
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ari-tczew> robert_ancell: I've just send you an email, did you see?
<ari-tczew> about network manager
<robert_ancell> ari-tczew, I was just replying
<ari-tczew> cool
<zbenjamin> pgquiles: you need to talk to bzoltan_ about the sdk packaging.
<zbenjamin> pgquiles: he did most of it, but i think there was a reason why we could not use it
#ubuntu-devel 2015-11-20
<pitti> Good morning
<pitti> yay, autopkgtest queues finally caught up over night
<bzoltan_> zbenjamin:  the reason for not using Conflicts was that it was forcing the users to manually upgrade the sdk packages. So a simple apt-get upgrade would hve kept back our packages. I have tried all options. Nothing worked. Apt seems to be too sensitive or our dependency tree is just too complex.
<zbenjamin> bzoltan_: yeah, i think the guy is not here anymore :D
<bzoltan_> zbenjamin:  I tried to address him, but yes he is offline
<zbenjamin> bzoltan_: not even dist-upgrade worked?
<bzoltan_> zbenjamin:  we need to simplify the package dependencies in the whole SDK
<zbenjamin> (what you need for ppa upgrades anyway right)
<bzoltan_> zbenjamin:  no ... dist and normal upgrade simple kept back the packages.
<bzoltan_> zbenjamin:  but when apt-get install ubuntu-sdk-ide was used it went fine and it did remove the conflicting packages. No idea why it could not do it automatically
<zbenjamin> bzoltan_: right i remember now :/
<FourDollars> pitti: Hi, could you help to review https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/278108 and https://code.launchpad.net/~fourdollars/ubuntu/trusty/gnome-desktop3/fix-lowest-brightness/+merge/278110?
<dholbach> diwic, happy birthday! :)
<diwic> dholbach, thanks! :-)
<seb128> oh, happy birthday diwic!
<diwic> seb128, thanks! :-)
<diwic> seb128, FYI, I went writing some code on that subwoofer bug, but not really happy with the result just yet.
<seb128> k, still quite some time before feature freeze anyway ;-)
<Mirv> hi friendly core-dev again, to workaround train not understanding trunk translation updates in https://requests.ci-train.ubuntu.com/#/ticket/621 , please do ./copy-package --from=~ci-train-ppa-service/ubuntu/landing-060 --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed -b unity-api - everything else is already copied
<seb128> Mirv, what do you mean by "train not understanding trunk translation updates"?
<Mirv> seb128: the ticket claims unity8 has unbuilt changes, because translation updates land to trunk automatically https://code.launchpad.net/~unity-team/unity8/trunk
<Mirv> train just got a feature that detects trunk changes, unfortunately it doesn't understand translation updates are alright
<Mirv> and the publish can't be forced
<seb128> don't you have a checkbox to overwrite those errors?
<Mirv> no, there's no force for the publish job
<seb128> k
<seb128> but why are some copied then?
<Mirv> seb128: because they're in universe and I'm MOTU
<seb128> I see
<seb128> thanks for the details
<seb128> Mirv, copied for you
<Mirv> seb128: thanks, and mzanetti thanks you too!
<seb128> yw!
<seb128> infinity, new selinux seems to make glibc autopkgtests grumpy, http://autopkgtest.ubuntu.com/packages/g/glibc/xenial/amd64/ seems like we need to backport https://sourceware.org/git/?p=glibc.git;a=commit;h=808696696837b8b8fc858f2e6f8d4e40e26e1308
<seb128> pitti, dbus ones being unhappy are what you pinged Laney about earlier right?
<pitti> seb128: yes
<infinity> seb128: We'll get that for free with 2.22, but I might have to pull it in earlier if 2.22 and I keep fighting.
<seb128> infinity, ok, I was just pointing it because it's blocking selinux which is blocking some other things
<seb128> but anyway needs to sort out dbus as well, so it's probably not going to be today
<pitti> do we urgently need libselinux in xenial?
<pitti> seb128: oh, is that a library transition?
<seb128> pitti, no, but there are a bunch of things batched with it
<seb128> I was just looking at excuses
<pitti> ah right
<pitti> yofel: FYI: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/k/kdelibs4support/20151119_133155@/log.gz -- the same version worked before, is that acc failure due to a dependency change?
<pitti> yofel: this was the run for kio
<infinity> If glibc 2.22 and I don't agree soon, I need to do an opload for a 1-liner for s390x anyway, so I can grab that fix too.
<pitti> yofel: kdelibs4support/amd64 works fine against other -proposed packages, so kio does sound related
<pitti> infinity: uploading glibc on a Friday afternoon, what could possibly go wrong :)
<infinity> pitti: No meaningful code changes.  But yes, it would explode your infra something nasty. :P
<infinity> pitti: Until we're building s390x in LP, though, I don't care, I can hand-edit my 1-liner for my bootstrap stuff. :P
<infinity> pitti: (It's a Breaks against a binNMU version of something only on s390x, derp)
<didrocks> bdmurray: slangasek: hey, do you mind subscribing foundations-bugs to https://bugs.launchpad.net/ubuntu/+source/ptyprocess? That will enable me to promote it to main. It's a new dep of pexpect (process handling part has been externalized in 4.0) for which foundation is already the bug subscriber
<infinity> didrocks: Done.
<pitti> infinity, Laney: please remove http://autopkgtest.ubuntu.com/running.html from your browsers/brains and use http://autopkgtest.ubuntu.com/running.shtml from now on
<pitti> (link in the menu is updated, of course)
<pitti> apw too ^
 * mgedmin mutters "apache rewrite rules" under his breath
<pitti> using SSI to include the dynamic bit is a bit icky; I tried for about 45 mins to use JS for that, but failed
<pitti> including that on the client side, possibly with auto-refresh would be great
<pitti> but I'm a web/JS n00b; if someone knows how to do that, please talk to me :)
<mgedmin> I once made apache process SSI directives in .html files: http://paste.ubuntu.com/13363773/
<infinity> pitti: You give my brain too much credit.
<pitti> infinity: the entirety of what I know about internet addresses is contained in my firefox' awesome bar cache :)
<infinity> pitti: Yeah, ditto, though in that case, I follow the link from the front page.
<infinity> pitti: That said, if you want to fix firefox's brain, a 301 will make it rewrite the cache.
<infinity> (If you have enough control to 301)
<pitti> mgedmin: I know, but the .shtml page is autogenerated, so it's prone to get  lost
<cjwatson> pitti: The crontab change to build xenial langpack exports on Sunday is live now, so you can set your end of it up to run on Mondays.
<pitti> cjwatson: cool, thanks! I need to run the first one by hand, so I'll do that next Monday and then set the crontab
 * pitti adds it commented out for now
<yofel> pitti: probably a dependency change, at least I didn't change anything explicitely - except I did the acc change wrong. I'll have time to look at this in the evening (and at all the arm64 FTBFS)
<pitti> yofel: I retried teh arm64 FTBFS, seem happy now
<pitti> was a weird temp issue with installing the b-deps
<pitti> yofel: the test seems to work in general, as it does succeed when running against other packages, just not against kio
<yofel> oh ok, I got a couple mails earlier, but if that's solved great. Thanks
<yofel> ok, I'll look into that
<pitti> yofel: ah, the new ones you got from this morning are real
<pitti> like https://launchpadlibrarian.net/227091984/buildlog_ubuntu-xenial-arm64.kio_5.15.0-0ubuntu3_BUILDING.txt.gz
<pitti> uninstallable b-deps again, looks like some ongoing transition again
<yofel> dangit ^^. Ok, I'll check if it's something kde-internal anyway.
<pitti> at least it's now a "real" error, not this weird "refusing to remove b-deps" one
<VsyachePuz> does ubuntu-panel support panel applets, similar to DBus-based panel applets of gnome and mate?
<cpaelzer> pitti, is adt-buildvm-ubuntu-cloud supposed to work with "-r xenial" already?
<seb128> VsyachePuz, there is no ubuntu-panel
<seb128> if you mean the unity panel, it doesn't support "applets"/isn't compatible with the gnome-panel ones no, but it has indicators
<cpaelzer> pitti, when I try adt-buildvm-ubuntu-clou with xenial - I get this http://paste.ubuntu.com/13364697/ (seems to pass cloud init, but then hangs)
<cpaelzer> pitti, I lack an example of one that works to compare
<cpaelzer> fyi my system where this is running is trusty - if that might be a reason
<coreycb> pitti, do we list the current MRE packages anywhere?  they used to be listed on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<VsyachePuz> seb128: so, may i say, that ("Application Indicators" === "Panel Applets") and ("System Indicators" === "System Tray Icon") ?
<seb128> the other way around rather
<seb128> system indicators are things like the sound control or the session menu
<seb128> so the equivalent to applets
<sladen> Windicators!!!
<VsyachePuz> seb128: I want to implement "minimize to progressbar" feature
<seb128> what is a progressbar?
<VsyachePuz> seb128: and that progressbar should be long (i.e. 200 pixels long, not 22x22pt as an icon)
<VsyachePuz> seb128: https://en.wikipedia.org/wiki/Progress_bar
<seb128> yeah, I know what that widget is
<seb128> but "minimizing to a progress bar" is not a concept I grasp I think
<VsyachePuz> seb128: I have an application which have an UI for making queries, and performs long frocessing for each query
<VsyachePuz> I want to minimize it, but track the completion of operations
<VsyachePuz> the concept is "minimize to tray", but I used it as an analogy
<seb128> well, use an appindicator
<VsyachePuz> i don't want small icon, i want long widget
<VsyachePuz> may be even several of them
<VsyachePuz> one for each query
<seb128> that's not possible
<seb128> you can have the status/summary in the indicator menu though
<VsyachePuz> seb128: "that's not possible" - I am not sure. This is possible on MATE, and in Unity Menu is Indicator (long indicator). So long indicators should be  possible
<seb128> VsyachePuz, indicators can only contain a label or an icon in the panel
<seb128> no custom rendering or other widgets
<pitti> cpaelzer: the host system shouldn't matter that much; but I highly recommend using a current autopkgtest version
<pitti> cpaelzer: I think I remember having to add some hacks for newer cloud-inits; so if that's indeed trusty's autopkgtest, please try with a recent one
<pitti> coreycb: they are gone, we generalized the SRU policy instead
<pitti> coreycb: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html
<coreycb> pitti, ok thanks
<VsyachePuz> seb128: what is "icon"? Can it be nonsquare? Can it be 200x22px ?
<mterry> seb128, thanks for the gdal rdep rebuilds
<cpaelzer> pitti, yeah seems so on my wily system it just worked
<cpaelzer> pitti, I'll try updating to a more recent autopkgtest on my Trusty and try again
<cpaelzer> pitti, just FYI here would be the full log that worked http://paste.ubuntu.com/13365391/
<cpaelzer> and the difference starts at some cloud-init things, so yes it could be just as you suggested
<cpaelzer> I'll let you know later if it worked
<pitti> stgraber: hm, that i386 lxcfs failure seems fairly resistant against retries: http://autopkgtest.ubuntu.com/packages/l/lxcfs/xenial/i386/
<seb128> mterry, yw
<seb128> VsyachePuz, I don't know, I guess you can try
<mterry> kenvandine, poke about that deja-dup branch
<doko> xnox, are you going to address the cmake merge?
<xnox> doko, well, i win the TIL...
<infinity> xnox: You do now, anyway. :P
<infinity> doko: Shame about your versioning breaking the merge a bit, though.
<xnox> doko, i believe steve tricked me into doing that, via infinity.
<infinity> xnox: Oh, I guess you could work around the version issue by merging from experimental, if you're feeling bold.
<infinity> (Might want to test in a devirt PPA first...)
<kenvandine> mterry, sorry... i will look at it today!
<mterry> kenvandine, no worries  :)
<cyphermox> good morning!
<kenvandine> mterry, actually this MR isn't nearly as big as i thought... i don't need to worry about the vapi :)
<mterry> kenvandine, but that's where I hid all my bugs!
<kenvandine> :)
<nemo> Say, anyone here use VPNs and might have a little sympathy for the rather-broken-yet-easyish-to-fix-once-figured-out behaviour of opensc and vmware-view ?
<nemo> https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770  I documented the fix I ended up doing, here.
<ubottu> Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed]
<kenvandine> mterry, to test this, i just need to uninstall duplicity right?
<kenvandine> and run deja-dupe, which should prompt to install it?
<mterry> kenvandine, yeah should do
<mterry> kenvandine, specifically, run either of the preferences interfaces (running deja-dup from command line will just give an error)
<VsyachePuz> seb128: look at this article - http://www.omgubuntu.co.uk/2010/11/omg-5-five-ways-to-switch-between-workspaces-in-ubuntu there is a workspace switcher, which is long indicator - http://www.omgubuntu.co.uk/wp-content/uploads/2010/11/Selection_0021.png
<seb128> VsyachePuz, if you say so
<seb128> VsyachePuz, to me it looks like an icon with a menu
<seb128> it's 3.
<VsyachePuz> seb128: ok, i am wrong. first looks like gnome workspace switcher
<nemo> VsyachePuz: and the MATE one
<nemo> gnome2 that is
<nemo> I have it on my monitor just in front of me
<nemo> my fav 'cause it has window shape, and icon for fullscreened windows
<nemo> and, well, 'cause MATE
<VsyachePuz> nemo: yes, I set wanda fish to 0 frames, and panel height to 64 pixels. Receive long image without problem.
<nemo> VsyachePuz: ah. to each their own.  me, I set the panel even smaller, to free up more vertical space on the monitor.  I'm using 24px height
<nemo> and only one bar
<VsyachePuz> There is also WingPanel from Elementary OS, it allows widgets and AppIndicators, but didn't find specs
<didrocks> VsyachePuz: there is clearly a way to achieve something like that with indicators (I guess generating multiple images and pushing them one after another). Look at workrave, they have some progress bar in their unity indicator
<Mirv> hello. the big Bluez 5 landing (biggest part to vivid overlay, but also some to xenial) needs a core dev for one of the three silos: https://ci-train.ubuntu.com/job/ubuntu-landing-043-2-publish/15/ - packaging_changes there, run a job when ok with it
<VsyachePuz> didrocks: it have a class for each type of panel... - https://github.com/rcaelers/workrave/blob/branch_v1_10/frontend/applets/indicator/src/indicator-workrave.c
<Mirv> ticket with QA Granted approval at https://requests.ci-train.ubuntu.com/#/ticket/242
<didrocks> VsyachePuz: indeed
<Mirv> morphis is your point of contact regarding the silo itself
<cpaelzer> pitti, I can confirm after updating autopkgtest to 3.18.1 it works on my trusty system - thanks
<pitti> cpaelzer: great
<VsyachePuz> didrocks: there https://github.com/rcaelers/workrave/tree/branch_v1_10/frontend/applets is "cinnamon", "common", "gnome-shell", "gnome2", "gnome3", "indicator", "mate", "Win32", "xfce". Are you it's author?
<davmor2> cyphermox, seb128, pitti: is that silo something you could help with at all please  ^^^
<didrocks> VsyachePuz: not at all, just pointing something that I saw that could help you
<kenvandine> mterry, i'm also seeing an error trying to install
<kenvandine> The version 0.7.01-1ubuntu1/Ubuntu of duplicity isn't available.
<VsyachePuz> didrocks:seb128:  thanks
<didrocks> yw
<kenvandine> mterry, oh... i think i know why
<mterry> hm
<kenvandine> mterry, apt currently isn't happen with keys on my desktop :)
<kenvandine> i bet that's causing packagekit to barf
<mterry> kenvandine, keys?
<kenvandine> apt spews GPG errors right now
<mterry> oh ah
<kenvandine> i need to sort that out, just haven't had time
<kenvandine> mterry, i'm more concerned with the test failures, ideas?
<mterry> kenvandine, test failures?  Oh, I hadn't noticed.  Let me run tests again
<kenvandine> in package build http://paste.ubuntu.com/13365813/
<mterry> kenvandine, say what
<mterry> weird
 * mterry will try to reproduce, maybe that's only in a chroot
<kenvandine> mterry, i fixed the gpg issues in apt and it's still failing to install
<kenvandine> same error message
<xnox> Laney, we have webhooks now, right? can transition tracker update itself everytime there is a push to the config branch?
<kenvandine> mterry, could it be a missing depends?  i don't have packagekit installed :)
<mterry> kenvandine, I think you just need libpackagekit
<mterry> kenvandine, it talks to aptdaemon
<kenvandine> ah
<mterry> kenvandine, nothing in this branch is working for you!  :)
<kenvandine> so not it
<kenvandine> nope :/
<morphis> cyphermox, seb128, pitti: anyone having time to help merging that silo?
<seb128> morphis, "that silo"?
<seb128> I lack context
<cyphermox> morphis: looking...
<seb128> k, seems cyphermox is on it ;-)
<morphis> <Mirv> hello. the big Bluez 5 landing (biggest part to vivid overlay, but also some to xenial) needs a core dev for one of the three silos: https://ci-train.ubuntu.com/job/ubuntu-landing-043-2-publish/15/ - packaging_changes there, run a job when ok with it
<morphis> <Mirv> ticket with QA Granted approval at https://requests.ci-train.ubuntu.com/#/ticket/242
<morphis> cyphermox: thanks!
<morphis> awe: ^^
<seb128> oh, that's landing, great!
<morphis> seb128: yes, finally :)
<cyphermox> hum, wat
<awe> w00t!
<awe> seb128, looks like we have a fix for qt dbus too
<seb128> awe, this week is a good one :-)
<seb128> and way to wrap it
<morphis> seb128: one of the next steps is to sync the landings of bluez on desktop and Touch
<cyphermox> morphis: is indicator-bluetooth just a port to bluez5? that's not so obvious from the changelog
<morphis> cyphermox: it is and just and merge with what is in wily/xenial
<morphis> no further changes
<seb128> morphis, right
<cyphermox> I wasn't aware that we could permit this kind of very obvious deviation from SRU/backport rules for a stable release
<awe> huh?
<Mirv> cyphermox: overlay is treated differently vs features from actual Ubuntu releases
<awe> isn't this a landing to the PPA?
<cyphermox> Mirv: sure but I was under the impression that we were still asking that things that got in the overlay also got in SRUs
<awe> um, no
<awe> not for bluez5
<awe> that would be super risky
<infinity> cyphermox: The overlay is pretty Wild West.  Sadly.
<awe> if folks want bluez5 on the desktop, they upgrade to wily
<infinity> cyphermox: Its entire raison d'etre is to circumvent SRU policy. :P
<awe> this isn't a case of wild-west
<awe> we landed bluez5 in wily
<awe> and are backported to just touch
<awe> as it's a huge change
<awe> and requires lots of QA
<awe> it'd be way too risky to SRU
<awe> and AFAIK, nobody is asking us to
<infinity> awe: It's a battle I lost long ago, but I think "it's too risky to SRU" also means "it's too risky to push in an OTA".
<cyphermox> infinity: well, most things that happen in the overlay should still not just happen in the overlay, but backporting bluez is special
<awe> desktop can be installed on an order of magnitude more devices than a touch release
<awe> not a fair comparison at all
<morphis> cyphermox, awe: there is some worked needed to get the same experience in a Touch image produced from xenial but that is a different story and will be worked on next
<awe> morphis, indeed
<cyphermox> morphis: so why does bluez have +15.04.20151023? just because silo, or is that frankensteined or a git cherry-pick?
<morphis> cyphermox: it's landing through the citrain
<morphis> and the origin for this is a MP
<cyphermox> ok, that's what I thought
<cyphermox> morphis: please make sure to upload all the extra patches you're adding to xenial, too, unless they'd be for some reason phone-only
<cyphermox> (and upstream as appropriate)
<morphis> cyphermox: that is the plan
<morphis> I really want to align bluez uploads for current devel and phone
<morphis> so that we upload the same to both together
<morphis> but that is one of the next steps
<caribou> I'm preparing a new kdump-tool package which require a change in its config file (/etc/default/kdump-tools)
<caribou> what should the maintainer script do : display a warning ?
<caribou> I also need to add a prompt to enable it by default
<caribou> what is the appropriate way to address such a situation ?
<mterry> kenvandine, ok, added missing build-dep to let deja-dup build in a pbuilder (whoops), and all tests pass there, as well as locally
<mterry> kenvandine, how are you running it?
<rbasak> caribou: was /etc/default/kdump-tools being shipped as a conffile previously?
<caribou> rbasak: yes
<rbasak> caribou: then you can just update it, and dpkg will take care of the prompt. Unless you want to avoid the prompt somehow.
<mterry> kenvandine, ahem, accidentally pushed to trunk, will fix that
<rbasak> caribou: ah, but adding a prompt to change the file based on the answer is trickier.
<kenvandine> mterry, i just did a 'bzr bd'
<cyphermox> morphis: same applies to pulse, I think we should have HSP support patches there too, and upstreamed, etc.
<caribou> rbasak: yes, I understand that I will have the standard one, but is it expected to be sufficient ? if the user select the default which is to keep the old one, it may cause problems
<caribou> rbasak: two config variable that were not used previously are expected to be enabled now
<caribou> (i.e. they come with the new conffile)
<morphis> cyphermox: yes, but as already said, that is the next step
<rbasak> If the user blindly picks to keep the old conffile then there will always be problems IMHO.
<morphis> cyphermox: take this for all changes in silo 43
<rbasak> So I wouldn't be too worried about that case.
<kenvandine> mterry, any ideas why it's failing to install?
<rbasak> If you can detect it then you could warn the user through debconf in the postinst I suppose, if it's really important.
<caribou> rbasak: ok, just wanted to be sure that showing a warning was not required
<mterry> kenvandine, no, that also worked for me last time I tried it
<kenvandine> mterry: The version 0.7.01-1ubuntu1/Ubuntu of duplicity isn't available.
<kenvandine> that version string looks odd, with the /Ubuntu in it
<cyphermox> morphis: yes, but I'm pointing it out because it's important, just ask here for a sponsor when you have an upload ready for xenial.
<caribou> rbasak: well, in wily & xenial, kernel crash dump will fail if they're not enabled :-/
<kenvandine> but i don't think your code is involved in that
<mterry> kenvandine, it's also an old version
<kenvandine> mterry, i'm on vivid + stable overlay
<rbasak> caribou: I'm not sure what others would say but I'd say that no warning is required if all you're doing is updating a conffile. Providing it's really a conffile as seen by dpkg.
<mterry> kenvandine, what release are you on?
<mterry> kenvandine, ah hrm
<morphis> cyphermox: yes
<mterry> kenvandine, why?  ;)
<rbasak> caribou: however, if you want to prompt to change the file, that's tricker, because your maintainer script can't just go and modify the conffile.
<rbasak> Since if it does dpkg will think the user modified it.
<kenvandine> mterry, that's what i'm developing for right now :)
<mterry> and xenial!
<kenvandine> i'll switch soonish :)
<kenvandine> mterry, do you think that's why it's failing?
<mterry> kenvandine, looks like tests work for me in bzr bd too (just sanity checking)
<mterry> kenvandine, probably not?
<mterry> imma try again on my machine to install
<morphis> cyphermox: btw. does anything speaks against releasing bluez through citrain with MP to xenial as well?
<kenvandine> mterry, i already have libpackagekit-glib2-dev
<mterry> kenvandine, yeah, if you didn't, it wouldn't even build
<cyphermox> morphis: not really, aside from that it shouldn't be an MP, it should be a direct upload
<cyphermox> that way we don't have outlanding version numbers
<morphis> which makes a coordinated review process pretty hard
<cyphermox> ie. we should be more or less in line with the debian packaging if possible, and not have special versions
<cyphermox> no
<kenvandine> mterry, could the test failures have anything to do with me being on vivid?
<caribou> rbasak: my guess is that if the user doesn't bring in the new config file which is part of the fix, then he shouldn't be surprized if it doesn't work
<cyphermox> it's the same review in silos
<mterry> kenvandine, I also doubt that
<kenvandine> i wouldn't think so
<morphis> cyphermox: so where do I do my review then? there is no real instance I can put my comments in
<cyphermox> morphis: do it in a bug
<cyphermox> if you want to do things in a MP, you're free to keep stuff there
<cyphermox> but the upload through the silo shouldn't be via a MP
<mterry> kenvandine, ok install worked for me (w/ deja-dup-preferences, but "unity-control-center deja-dup" crashes for me!)
<mterry> kenvandine, so I'm going to look at that crash
<cyphermox> should work just the same as NM, basically. you have a packaging branch, just it's not relevant to the silos
<mterry> kenvandine, and I can't explain either of the failures you see
<kenvandine> i'm building in sbuild now
<rbasak> caribou: agreed
<rbasak> caribou: that part is fine.
<cyphermox> that is, unless there's a way to use the MPs anyway but not having version number mangling because of it
<mterry> kenvandine, what does "apt-cache policy duplicity" say?
<caribou> rbasak: ok, thanks!
<rbasak> caribou: but if you want to display a prompt on install and ask the user about a default, then you can't just modify the conffile to store the result.
<kenvandine>   Installed: (none)
<kenvandine>   Candidate: 0.7.01-1ubuntu1
<rbasak> caribou: because then the user will get an unexpected dpkg prompt on a future upgrade.
<morphis> cyphermox: so where can I comment then directly on the source which is landing in the bug?
<cyphermox> morphis: I don't know what you mean by that
<caribou> rbasak: the conffile will come with the default, so choosing the default will not modify the conffile
<rbasak> caribou: what if the user chooses the non-default?
<caribou> rbasak: then we would want him to confirm that he changed the default behavior on the next upgrade, right ?
<cyphermox> merge proposals don't *have* to be used with a silo landing, they're not linked to it. You're free to prepare a merge in a separate branch for a new package upload and file a merge request against the real packaging branch
<caribou> rbasak: default being kernel crash dump is enabled
<rbasak> caribou: no, then the next upgrade should remember what the user asked for and make it continue to happen without prompting.
<rbasak> caribou: there is a distinction here between users modifying conffiles themselves directly (in which case we expect them to know what they're doing and handle a conffile prompt by themselves) and choosing an option in a menu (in which case a conffile prompt isn't acceptable).
<caribou> rbasak: ok, then the script will check if a previous value exist (I suppose that it is the expected way to do)
<cyphermox> morphis: the problem with silo version numbering is that in the case of non-Canonical projects, it's confusing: it essentially means you're taking a snapshot of a source code repository at a specific point in time, which is false for bluez -- we're taking a release tarball, and adding patches on top via quilt or whatnot.
<rbasak> caribou: there are a few different ways of approaching this. ucf might be appropriate here.
<caribou> rbasak: that's the first time I do one from scratch, I'll fetch a few example in other packages
<mvo> infinity: took a bit longer (wanted to get to it at the start of the week already) but https://launchpad.net/~mvo/+archive/ubuntu/apt-xenial/+packages is coming together, I guess early next week we can land the new apt 1.2^W2.0 in xenial
<caribou> mvo: what can be longer than infinitty ?
<mvo> caribou: lol
<infinity> mvo: 2.0, you say?
<morphis> cyphermox: basically I prefer the way of handing things of to automatic process and only say yes or no to what needs to land. With this I have to merge the MP, build a source package myself and upload it (through someone else) to the silo
<infinity> mvo: I guess it does have a lot of new shiny, but after a decade of 0.x, jumping to 2 is very chrome/firefox of you. :P
<caribou> rbasak: if you don't mind, I'll show you what I got working before I upload. You should be back by then
<morphis> where in the last two steps through the manual process something can be added to the package which I didn't reviewed
<rbasak> caribou: sure
<cyphermox> morphis: what?
<cjwatson> mvo: FYI I've been doing some very preliminary work on by-hash support in LP, but I want to get xz indexes landed first
<cyphermox> morphis: whatever the method used is, bluez should certainly *not* have a version number of 5.35+32095 in the archive, because it's completely incorrect and misleading
<awe> cyphermox, it's something I've pointed out in the past as well
<awe> cyphermox, I thought this was about a landing to the PPA?
<cjwatson> mvo: which is going to involve some internal shuffling, because I think the right approach for that is to enable xz only for >= xenial (and disable bz2 once things are working well)
<rbasak> xz indexes would be really nice. Thank you for working on it!
<morphis> awe: it is
<cyphermox> awe: notice I said in the archive, and I let your silo through already
<awe> cyphermox, thanks
<cyphermox> which, in retrospect, was wrong because now it's be always higher than anything unless we upload 5.36
<infinity> Yeah, that shouldn't be in the overlay either.
<morphis> cyphermox: thanks!
<infinity> If it was copied to the overlay, please get someone to delete it and re-upload with a sane version.
<cyphermox> oh, but we do have 5.36 in xenial
<infinity> Or, I guess, if xenial is already higher, whatever.
<cyphermox> infinity: I'm tempted to not care for this case because xenial is already higher, yeah
<infinity> But distro packages with a proper orig shouldn't be re-packed with strange versions for silos.
<mvo> cjwatson: nice! will by-hash use apt-ftparchive? if so I might need to put some more work into it, I'm not sure how well the current approaches scale in there (i.e. if it can handle this size of an archive without getting too slow)
<morphis> cyphermox, infinity: why don't we modify citrain then to do proper version numbers for those packages?
<mvo> infinity: 1.2 vs 2.0 is a bit of an internal joke :P its probably going to be 1.2 its pretty nice and shinney but maybe not 2.0 shinny
<awe> morphis, +1
<cyphermox> morphis: by all means.
<cyphermox> robru: sil2100: ^
<morphis> there are multiple things:
<morphis> having a MP gives us a review protocol with all things documented
<morphis> all back and forth
<morphis> using an MP in citrain and a silo ensures that we only land what is in the MP and nobody has the chance to include anything else
<morphis> which isn't reviewed by others
<cyphermox> nobody would include anything else when doing a direct upload to the PPA
<awe> morphis, yes... you're correct, and there's been much back and forth over this issue for as long as I've worked on touch
<awe> cyphermox, but they *could*
<cyphermox> those who have access to do it are expected to know better, unless they have a very good reason
<morphis> exactly
<cyphermox> meh
<awe> people can make mistakes
<awe> it's a valid point
<morphis> if we have the automatic to do such things why don't we use them?
<awe> morphis, we do
<awe> primarily for packages developed by Canonical
<awe> it gets trickier when we're talking about packages that we mostly maintain
<morphis> but I don't see any reason not to use them (optional) for other components too if the maintainer / developer wants to
<morphis> my primary reason for bluez is that we have to coordinate now between different kinds of users
<morphis> Desktop, touch, IoT
<morphis> which brings in a bunch of different use cases and we have to ensure nothing breaks any of those use cases
<awe> morphis, sure... except there are some problems when doing so.  One being the version mangling
<infinity> And what's the MP against?  It's not against the archive.
<infinity> Which is authoritative.
<infinity> So "the MP makes sure no unwanted changes get in" is false.
<morphis> against the packaging branch
<awe> how do you propose a MP against a tarball??
<awe> if there is one
<cyphermox> infinity: morphis has a pretty good packaging branch
<infinity> I don't propose an MP against a tarball.
<infinity> Cause the tarball shouldn't change. :P
<infinity> Except, it is changing.
<cyphermox> morphis: the point is people could upload and not notice there was a packaging branch
<cjwatson> mvo: We need to have a way to put things into the by-hash arrangement for PPAs too, so we might as well just do that bit of it ourselves - so we'd still be using apt-ftparchive, but then moving the results around afterwards
<infinity> Which is wrong.
<morphis> infinity: IMHO all changes should go into the packaging branch first even if the archive is the authoritative
<cyphermox> or upload not going through the silo, because any core dev is free to upload any package
<cjwatson> rbasak: Is your interest just for size reasons?
<awe> morphis, not all packages have packaging branches
<infinity> morphis: That's a lovely opinion, but factually incorrect for anything I can upload to the archive.
<awe> eg. qtbase
<infinity> morphis: Sorry to burst your bubble with reality.
<awe> come on guys
<awe> can we please re-focus
<morphis> awe: I don't mean everything in the archive needs to take this approach
<awe> on what needs to happen for bluez5?
<cjwatson> rbasak: (it's a little smaller, but not lots smaller)
<awe> and save this discussion for later?
<morphis> however for a single component I need to maintain across different use cases it makes life a lot easier
<cyphermox> awe: simple, either upload directly to the silo, and/or fix the versioning in citrain.
<awe> no argument
<awe> cyphermox, there are three silos
<awe> one for ofono dual landing
<awe> AFAIK, that's OK
<awe> then we have a silo for indicator, et al that's dual-landing
<cyphermox> any bluez upload in a silo should be a direct upload until the train knows not to touch the version number in that case
<awe> the final silo for bluez5 is just PPA
<awe> so are you asking us to fix the second silo?
<infinity> cjwatson: Assuming apt is picking a sane dictionary size, xz is probably also faster to decompress than bz2, which is a nice win.
<awe> cyphermox, so the issue is that the version number of the bluez silo for ppa upload only is wrong?
<cyphermox> and tbh, it could be as simple as looking at .bzr-builddeb/default.conf for a specific option, depending on what morphis uses in the packaging branch
<infinity> cjwatson: bz2 is so terribad that I tend to force gz all over the place and take the bandwidth hit instead. :P
<cyphermox> awe: I suppose. I have only looked at one silo
<awe> so which silo are you objecting to?  # please?
<cyphermox> I was objecting to the verion that was in silo 43
<cyphermox> I let it through, but it was wrong
<dupingping> I am proud that I became a Ubuntu member.
 * awe looks
<cyphermox> except it's not the biggest deal for this case because it's still lower than what is in xenial
<morphis> cyphermox: so there is no TODO left for us to land bluez5 for right now?
<cyphermox> are you trying to do other bluez landings?
<morphis> not yet
<cjwatson> infinity: I think it just uses xz's default, i.e. -6
<cjwatson> which is an 8MiB dictionary size
<morphis> cyphermox: but I would like to ugprade to .36
<morphis> cyphermox: so lets do it like this:
<morphis> we take what we have right now
<infinity> cjwatson: Yeah, I think -6 is generally faster than bz2 for decompression (much worse for compression, but who cares).
<morphis> we have to do some bug fixes anyway for bluez during the ota9 cycle
<morphis> and I would like to get 5.36 into ota9 as well
<cjwatson> infinity: I care a little, but it's probably dominated by other things
<morphis> as it includes bug fixes we should better have
<cjwatson> Will find out a bit later
<morphis> cyphermox: so my next landing will not use a MP but a manually uploaded package which fixes the version number, ok?
<cyphermox> if you want to get to 5.36 in the overlay, just merge whatever we have in xenial with what is currently in the overlay, and then direct upload to the silo you'll do your landing with
<cyphermox> you can still use a packaging branch, the only thing that won't be a MP will be what the train uses to land
<rbasak> cjwatson: decompression speed reasons.
<cyphermox> you're still free to use MPs to prepare the work
<morphis> cyphermox: agreed
<awe> cyphermox, unless we get a fix for CI by then
<cyphermox> awe: sure
<awe> we should be able to special case this
<rbasak> cjwatson: bz2 decompression often seems to be the reason that apt holds things up. I don't have numbers but I believe xz decompression is significantly faster.
<awe> if we can't get a more generic fix
<stgraber> hallyn: can you look at the lxcfs test failure? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/l/lxcfs/20151120_091728@/log.gz
<stgraber> hallyn: doesn't seem to be racy or if it is, well, it's mostly failing
<cjwatson> infinity: So, it'll certainly slow down the publisher some.  Unscientific: http://paste.ubuntu.com/13367748/ (those are apt's default settings)
<infinity> cjwatson: Given the nature of Packages/Sources/Translation (ascii and/or utf-8, only one or two languages, highly repetetive), one could probably experiment with even smaller dictionaries than the default, but I'm not sure it's worth it.
<cjwatson> infinity: Dictionary size also determines memory requirements for decompression
<infinity> cjwatson: Indeed, I'm quite familiar with the handy table in the manpage. :)
<cjwatson> infinity: http://paste.ubuntu.com/13367838/
<rbasak> So when is apt going to automatically drop back to gz when the dictionary in the xz is too big? :)
<cjwatson> corresponding Packages.bz2 is 6971349 bytes, Packages.gz is 8998549 bytes
<rbasak> Big leap seems to be at -4 from a quick glance
<hallyn> stgraber: i386, bet it's a 32/64bit error in the recentmeminfo code i merged
<cjwatson> decompression (on pepo) of default settings for Packages.bz2 is ~1.3s, Packages.xz ~0.65s
<infinity> cjwatson: Yeah, that's kinda leading me to believe -6 is just fine, so long as the publisher doesn't have a massive sad about it.
<cjwatson> decompressing xz -4 is about the same, maybe a few centiseconds slower
<infinity> We don't support anything where the memory pressure from decompressing -6 should be a problem.
<stgraber> hallyn: that's an amd64 failure, different and probably caused by the change of uptime layout: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxcfs/20151120_051440@/log.gz
<cjwatson> infinity: suggests to me that it will add about two minutes to publisher runtime for a release pocket
<hallyn> stgraber: uh, i chnaged that testcase to handle that.  wtf
<infinity> cjwatson: Drop ls-lR, and you come out even. :P
<cjwatson> infinity: xz -4 would be more like a minute or less I think
<infinity> cjwatson: Yeah, I like -4 on the publisher side, but I like it less on the client side, at least from those numbers.
<kenvandine> mterry, i get the same failures in sbuild
<mterry> kenvandine, you're a monster
<cjwatson> infinity: It's a little less compelling, true
<infinity> cjwatson: I suppose benchmarking decompression on something craptastic like a Panda (or a Fast Model!) would perhaps also help.
<kenvandine> mterry, :-p
<kenvandine> mterry, vivid chroot though
<cjwatson> infinity: do you have one handy?
<kenvandine> mterry, i'll try with xenial
<infinity> cjwatson: I do indeed.
<mterry> kenvandine, I don't know why it would be different, but worth a shot
<hallyn> stgraber: the amd64 testcases id efinately ran locally...
<cjwatson> infinity: (anyway, ls-lR is in finalize, so it's not on the critical path for e.g. proposed-migration kicking off)
<stgraber> hallyn: well, it does pass, sometimes: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxcfs/20151120_014250@/log.gz
<cjwatson> I'm more concerned by timings before the dists switch.
<hallyn> stgraber: oh, but wiat, that amd64 failure, args are opposite of what i expected.  the test isn't wrong, for some reason lxcfs really did spit out ints instead of floats.
<hallyn> all righ ti'll figure it out
<infinity> cjwatson: Well, I can tell you that Pandas sure suck at compressing things. :P
<infinity> cjwatson: When that's done, I'll decompress a bit for you.
<hallyn> stgraber: those two runs are installing different versions of lxcfs before running the tests
<hallyn> looks like a testrunner eror to me
<infinity> cjwatson: http://paste.ubuntu.com/13368221/
<infinity> cjwatson: So -6 looks reproducibly faster client-side (I assume not true once you swap but, again, we shouldn't support anything with that sort of memory pressure).
<infinity> cjwatson: Anything xz is such a massive win over bzip2 though, that it's really about how much bandwidth win we're getting over gzip.
<hallyn> stgraber: indeed that older version spit out integers
<cjwatson> infinity: Right.  Not a huge amount of difference over -4, so perhaps we can start out with -6 and then drop to -4 if the publisher slowdown is too difficult.
<hallyn> pitti: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxcfs/20151120_051440@/log.gz
<hallyn> pitti: ^ that one is building the xenial-proposed package, but it installs the xenial package, then runs the xenial-proposed tests against xenial pkg (which fails, correctly)
<dupingping> hi, popey_
<dupingping> how are you today?
<dupingping> I sent an email to sabdfl
<popey> ok
<dupingping> at the email, I asked about the time when the cert mail arrived here.
<dupingping> popey: Mark will be very busy, right?
<popey> I did say be patient
<popey> You seem to not be doing that
<dupingping> yes, I'm just waiting.
<popey> pinging mark isn't waiting, but anyway, you choice
<hallyn> stgraber: well this i386 lxcfs crash is not at all what i expected.  seems to be a glibc bug in realloc.
<infinity> hallyn: You have a pointer?
<dupingping> popey: yes, I'll wait.
 * infinity waits for "no, that's the problem."
<hallyn> infinity: not sure what you mean by a pointer - http://paste.ubuntu.com/13368646/ is the gdb stracktrace
<infinity> hallyn: I meant a pointer to the bug, rather than a pointer to memory. ;)
<hallyn> oh.  no open bug i know of but it's https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/l/lxcfs/20151120_091728@/log.gz
 * davmor2 points at infinity "no, you're the problem"  close enough right?
 * hallyn back in a few, sigh
<hallyn> wonder if a little c prog can reproduce this
<dupingping> popey: i got a reply from him.
<dupingping> very kind
<popey> Good stuff
<pitti> hallyn: ah, thanks for pointing that out; indeed, I'll look into that on Monday
<dupingping> So I'll wait.
 * pitti waves
<hallyn> pitti: thx
<hallyn> oh, actually this  may be a bit urgent - it means lxcfs on xenial has unfixed cves until that clears
<infinity> hallyn: We don't promise security support in the devel series, it's not terribly urgent.
<hallyn> ok
<hallyn> so i can't reproduce this standalone so i must be messing something up in the context
<infinity> hallyn: I kinda want to blame fuse, but I haven't looked closely.
<hallyn> infinity: it's possible another thread is to blame i suppose
<hallyn> fwiw http://paste.ubuntu.com/13368976/  shows the relevant values, everything looks sane
<hallyn> maybe if i thread my testcase
<infinity> hallyn: I'm hip-deep in punchcards, but if no one's got a better idea by EOD Monday, give me a jab.
<hallyn> you're supposed to swim in *money* not punchards
<hallyn> thx, will do
<infinity> hallyn: Yeah, I didn't read the fine print.
<rmblrd21> would ubuntu-devel be the right place to report that ubuntu updates break ath10k support everytime an update is coming in?
<rmblrd21> kernel update of course
<rmblrd21> sry, mean firmware file update
<dobey> a bug report on the ath10k package would be the right place i would think
<rmblrd21> ok
<hallyn> shoulda looked higher in the scrollback earlier - http://paste.ubuntu.com/13369752/
<hallyn> i guess glibc is putting its foot down.
<hallyn> stgraber: ok so i do think this is a glibc bug, but i'm going to post a workaround for lxcfs for now
<hallyn> (glibc is throwing an assertion, i think, bc i'm reallocing to a size which isn't big enough compared to the prev size.  shouldn't do that)
<kenvandine> mterry, same failures in a xenial build (sbuild)
<mterry> kenvandine, guh
<kenvandine> sorry, i'm an evil monster :)
<kenvandine> mterry, in case it's useful, http://paste.ubuntu.com/13370636/
<mterry> kenvandine, a bunch of "Failed with an unknown error"...  :(
<kenvandine> yeah, doesn't seem useful
<hallyn> stgraber: proposed fix: https://github.com/lxc/lxcfs/pull/54  but i'm now going to rebuild glibc with some debugging to see the root cause
<mterry> barry, just to give you an update on the duplicity side of the python3-only effort, I have a branch ready to let deja-dup install duplicity on-demand.  But it's apparently not working in all cases.  Working on it slowly
<attente> hi, where is the file /etc/environment coming from?
<attente> what project would i have to checkout to add a line to it?
<infinity> attente: It's written by various installers at install time.  What line did you want to add, and why?
<attente> infinity: GTK_IM_MODULE=Maliit, which will be needed eventually (not yet) to get gtk apps communicating with the osk. but only on the phone, not on the desktop
<infinity> attente: That almost certainly belongs in some sort of graphical session startup, not in /etc/environment.
<attente> infinity: so should the line for QT_IM_MODULE=maliitphablet be moved elsewhere?
<infinity> attente: If that's in /etc/environment on the phone today, yeah, that should probably be elsewhere too. :P
<attente> infinity: heh, ok. any ideas for where would be good? i'll move the QT one too
<infinity> attente: But if it is, and you're just looking to double-up on the same hack, it looks like it lives in livecd-rootfs//livecd-rootfs/live-build/ubuntu-touch/hooks/48-setup-env.chroot
<infinity> attente: I have no strong opinions about where it *should* be, but I suspect someone in #ubuntu-desktop could point you at how graphical sessions are meant to be set up.
<infinity> attente: For now, though, the path of least resistance would be to pile on top of the existing livecd-rootfs hack, it seems.
<attente> infinity: ok, great, thanks. i won't add it since i don't need it quite yet, but it's good to know just in case
<barry> mterry: ok, thanks for the update
<tdaitx> infinity, I just grabber a xenial schroot and its sources.list file is set to wily
<infinity> tdaitx: Yup.  It's a wily chroot, lp-buildd overrides sources.list.
<tdaitx>  http://launchpadlibrarian.net/222053869/chroot-ubuntu-xenial-amd64.tar.bz2
<infinity> tdaitx: I should probably freshen them soon.
<tdaitx> infinity, oh, sbuild-launchpad-chroot does not override that
<infinity> tdaitx: No, indeed, I think cyphermox had a patch to fix that.
<cyphermox> err, it's in xenial already
<infinity> tdaitx: There you go.  Grab xenial's version.
<cyphermox> tdaitx: you want sbuild-launchpad-chroot 0.13 yeah
<tdaitx> yeah that explains, I'm using a wily distro,
<tdaitx> cyphermox, thanks =)
<tdaitx> infinity, thank you o>
<infinity> RAOF: Hey, you know how long ago, Debian X tried really hard (and very successfully) to make X completely scorched-earth bootstrappable by splitting out x11proto-* and lib* and such, and carefully avoiding circular deps?
<infinity> RAOF: That's totally broken in Ubuntu now with mesa and mir interdepending. :P
<infinity> RAOF: (Easy loop to break, but annoying)
<mterry> kenvandine, testing the branch on my other wily laptop, everything passes and I was able to install duplicity
<tdaitx> infinity, heh, my first run in with circular dependencies in packages was as a gentoo user long ago, trying to build gnome... iirc there was a particular way to go, otherwise it ended up in a circular dependency hell
<mterry> kenvandine, I don't get why we are seeing two very different results
<mterry> kenvandine, I also fixed the crasher I was seeing
<infinity> tdaitx: I'm quite practised at this. ;)
<kenvandine> mterry, dunno... no idea what could be different
<mterry> you tested in a clean xenial environment and got the error.  I don't get why I wouldn't see it in my clean environments
<mterry> kenvandine, is there anything that sbuild takes from your environment/HOME?  ...  does trunk give the same errors for you?
<kenvandine> mterry, freshly created xenial sbuild schroot
<kenvandine> not sure
<kenvandine> i can try trunk too
<mterry> kenvandine, sorry man for the trouble
<kenvandine> no worries
<kenvandine> mterry, trunk has the same failures in sbuild with xenial
<mterry> kenvandine, ok.  so at least no regression...  and I doubt the usefulness of those failures, since deja-dup has built in LP in September
<mterry> with no changes in trunk
<mterry> well...  some changes in trunk
<mterry> but nothing I would expect would cause that (removed some unused code)
<kenvandine> mterry, building it on my vivid laptop now
<kenvandine> mterry, also trying under a fresh user account as well
<kenvandine> mterry, same failures on my vivid desktop when built under a new user account, so that rules out env from my home
<mterry> kenvandine, gar!
<kenvandine> mterry, still building on my laptop... xenial with sbuild
 * mterry is trying to think
<mterry> so something in my account?
<mterry> maybe I'll try a fresh user
<mterry> But LP doesn't mind it...
<kenvandine> maybe it would now
<kenvandine> tests starting on my laptop :)
<kenvandine> 53% tests passed, 45 tests failed out of 95
<kenvandine> same thing on my laptop :/
<kenvandine> mterry, so your box has the secret sauce :)
<mterry> kenvandine, fresh account on my wily box built fine
<mterry> kenvandine, am trying in LP as a tie-breaker build  :)
<kenvandine> mterry, :/
<smoser> infinity, https://bugs.launchpad.net/ubuntu/+source/linux-lts-wily/+bug/1511497 can you make netboot-wily exist in places like http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/ ?
<ubottu> Launchpad bug 1511497 in maas-images "No hwe-w kernel for 14.04" [Medium,Confirmed]
<infinity> smoser: That's the plan.
<infinity> smoser: It's a next-week TODO.
<smoser> k. thanks. if it happens by monday i can snif test amd64 and i386 netboot installers easily enough and verify.
<rharper> is there a maximum length for launchpad userid?  32 chars?
<cjwatson> rharper: No explicit limit
<cjwatson> rharper: It will be rather inconvenient past a certain point :-)
<rharper>  cjwatson: interesting ok;  right;  what would you suggest as reasonable?  < 255 ?
<smoser> ah, but you see, rharper is implementing storage backend in launchpad user names.
<cjwatson> rharper: Er, I don't know.  Why?
<rharper> smoser: the first rule of hidden storage backends is that we don't talk about where we're implementing them
<smoser> DOH!
<rharper> cjwatson: taking input to pass to ssh-import-id lp:<foo> and wanted to have a sensible limit without preventing folks from putting in their launchpad id
<cjwatson> The current maximum length in use on dogfood is 496, almost certainly because at one point there was a bug in collision handling for automatically-generated names that resulted in ridiculous growth
<cjwatson> I suspect names that long are not in fact in use
<smoser> hm.. if you raised that to 512 it'd be much more convenient for block size.
<rharper> haha
<kirkland> :-)
<cjwatson> The maximum name length of person rows who have an sshkey is 210 (again, on dogfood, since that's what I can query directly)
<rharper> cjwatson: cool, thanks
<kirkland> rharper: should I be expecting a patch from you on this?  :-)
<rharper> kirkland: no, no changes to ssh-import-id
<cjwatson> and that's a username I really can't believe anyone is actually using, and yet it has an sshkey ...
<cjwatson> maybe the victim of some peculiar renaming bug
<cjwatson> everything over 64 with an sshkey either has multiple -deactivatedaccount on the end or is one of the victims of https://bugs.launchpad.net/launchpad/+bug/1099297 and thus has ridiculous amounts of junk prepended and appended to a tiny local part
<ubottu> Launchpad bug 1099297 in Launchpad itself "generate_nick only seeds random state from localpart" [Critical,Fix released]
<ichdasich> heho
<ichdasich> a little far fetched, but is there a valid security contact process for canonical infrastructure?
<sbeattie> ichdasich: for canonical infrastructure? security@canonical.com (security@ubuntu.com is for issues with the distro itself)
<ichdasich> sbeattie: kthx, did not come clear from the cannonical page
#ubuntu-devel 2015-11-21
<darkxst> anyone around that can sponsor bug 1518478 to  unbreak ubuntu-gnome live cd's?
<ubottu> bug 1518478 in casper (Ubuntu) "update paths in scripts to /etc/gdm3" [Critical,Triaged] https://launchpad.net/bugs/1518478
<darkxst> cjwatson, infinity : ^
<Acerio> Anyone here a member of Ubuntu Hardened team?
<Acerio> Nevermind.
#ubuntu-devel 2015-11-22
<cimbakahn> I can't find anyone at any of the lubuntu rooms.  Can i get help here?
<hjd> Someone around who can retrigger failed builds for Xenial? It looks like felix-main, guice, httpcomponents-core and jackrabbit were synced at the same time as newer versions of some of their dependencies. I tried with httpcomponents-core and that built successfully locally at least. Could be argued that they might need stricter version requirements for these dependencies, but I don't know whether that's an issue or not...
<ginggs> hjd: rebuilding soon
<hjd> ginggs: ty :)
<hjd> I also found the curious case of bug 1518701, but I don't know how issues like that are resolved in practice...
<ubottu> bug 1518701 in phpunit (Ubuntu) "Circular dependency: unable to install phpunit from -proposed" [Undecided,New] https://launchpad.net/bugs/1518701
<ginggs> hjd: have you filed a bug in debian for that circular dependency?
<hjd> ginggs: No, I haven't.
<hjd> I was mainly looking into what the root cause could be, but I wasn't sure how to proceed.
<hjd> Any suggestions/tips on whether I should include more that what's in the original report, if I end up forwarding it to Debian? (For instance, I haven't found a good way to mark multiple packages as affected there like on Launchpad, but I might be missing something obvious) :)
<JanC> seems like Debian knows about that issue: http://metadata.ftp-master.debian.org/changelogs//main/p/php-codecoverage/php-codecoverage_3.0.2+dfsg-1_changelog
<mapreri> that's really not a debian problem.  some kind of bootstrap is needed, like uploading a binary as done in debian, but this really requires super-super powers in ubuntu
<mapreri> well, unless it's actually possibile to drop the dep, which i fear is not, but worth a try maybe
<JanC> maybe just changing the dependency versions can fix it?
<JanC> if one can work with an older version of the other
<cjwatson> hjd,ginggs,mapreri,JanC: I'll bootstrap it.
<mapreri> cjwatson: cool.  OOI are you going to upload the binary of php-codecoverage ?
<cjwatson> mapreri: Only to a bootstrap archive used only for build-deps.
<cjwatson> mapreri: Even I can't upload binaries directly :-)
<cjwatson> mapreri: But I do have superpowers to inject build-deps.
<mapreri> wow
<mapreri> cjwatson: but are there people who can push binaries directly to the ubuntu archive nowadays?
<cjwatson> mapreri: No.
<mapreri> oh, that's cool, actually
<cjwatson> Quite deliberate :-)
<mapreri> eheh
<cjwatson> Hasn't been possible for a long time.
<cjwatson> (If it ever was, which I slightly doubt.)
<cjwatson> I guess maybe pre-Launchpad.
<mapreri> maybe, but those details are hard to grasp from the outside...
<cjwatson> infinity: Oh hai.  The xenial chroots don't include the bootstrap archive right now.
<cjwatson> OK, so I can't do this easily right now, can do it once infinity deals with the above.
<cjwatson> (Could in principle, but I don't really want to upload new chroots ...)
<infinity> cjwatson: It was possible even post-LP, I used to inject binaries into the upload queues to bootstrap waaaay back when.
<infinity> cjwatson: But I haven't done that in years, and I *think* the shell access required to do so is something none of us have anymore anyway.
<infinity> cjwatson: Anyhow, I can refresh and fix the chroots.  They're still copies of wily-release chroots right now.
 * infinity glares at his Unity launcher, which seems to have decided that auto-hiding isn't hip and cool anymore, despite its settings.
<cjwatson> infinity: Ah, yes, now you mention it I think that was one of my motivations for rewriting the archive admin scripts. :P
<infinity> cjwatson: Yeah.  We went from bootstrapping via binary-into-archive injection (eeeevil) to chroot injection (less evil, but still gross) to the bootstrap archive (mostly not gross, ish).
<infinity> cjwatson: But I distincly remember perpetrating the evil method in the early LP days, since it was just a carryover of the status quo from jackass.
<Unit193> cjwatson: Do you have a nice page somewhere on using reposurgeon to convert bzr repos to git?
<infinity> cjwatson: After I'm done my lazy afternoon TV watching, I'll refresh the xenial chroots and turn the bootstrap back on.
 * infinity is finding it oddly satisfying to watch the s390x stage1 bootstrap autobuild.
<infinity> Well, "auto"build.  Shell loop of doom, but whatever. :P
<hjd> cjwatson: Thank you :)
<hjd> infinity: s390x for Ubuntu?
<infinity> hjd: http://mainframeinsights.com/ubuntu-distribution-announced-for-linuxone-and-ibm-z-systems/
<mapreri> now, why does http://archive.ubuntu.com/ubuntu/dists/xenial/Release lists armhf, arm64, ppc64el, powerpc which are not in archive.u.c but on ports.u.c, and conversely ports.u.c's Release lists amd64 and i386, which are only on archive.u.c
<mapreri> -.-'
<mapreri> that's ain't funny, guys
<infinity> mapreri: Because the archive split is done on a machine other than the one that signs Releases, so it can't perform surgery and re-sign.
<infinity> mapreri: A bug, perhaps, but hardly one that causes any real issues, since it's been like that for a decade.
<mapreri> infinity: usually how can a person figure whether an architecture is in ports or the main archive without trying and hitting 404?
<infinity> mapreri: archive = amd64/i386, ports = everything else?
<JanC> well, that could change of course
<mapreri> infinity: will it ever be that way, written in a rock?  (ok, not that i expect something so stable, but listing archs is evil)
<mapreri> well, it has been for the past decade...
<infinity> It *could* change, but it's based on traffic/demand, as long as x86 so firmly eclipses all the other ports, it's not likely we'll change the list.
<mapreri> isn't ports mirrored?
<infinity> If it did change, I don't think it would be a hard cutover, we'd do something like publish ppc64el to both archive and ports, so the world isn't disrupted.
<infinity> ports has ccTLD DNS in place, but it's only mirrored in the UK and US right now.  Would be nice to expand that, but we don't have people beating down our door to do so.
<mapreri> eheh
<hjd> infinity: aaah, I see
<JanC> you could also parse e.g. http://archive.ubuntu.com/ubuntu/dists/xenial/ & http://ports.ubuntu.com/dists/xenial/ (or ftp:same) for Contents-*.gz  :)
<Unit193> infinity: What're you doing active on the weekends for?! :P
<infinity> Unit193: Being a derpaholic.
<Unit193> Haha, alright. :D
#ubuntu-devel 2016-11-21
<kees> anyone working on the nvidia regression?
<kees> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304/+bug/1639663
<ubottu> Launchpad bug 1639663 in nvidia-graphics-drivers-304 (Ubuntu) "vdpau permissions incorrect in 304.132-0ubuntu0.16.04.2" [Undecided,Confirmed]
<kees> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304/+bug/1639215
<ubottu> Launchpad bug 1639215 in nvidia-graphics-drivers-304 (Ubuntu) "After upgrade of Nvidia 304 drivers, mythfrontend.real crashed with SIGSEGV in QGLFormat::openGLVersionFlags()" [Undecided,New]
<kees> :(
<rbasak> mdeslaur, tseliot (not here?): ^
<cpaelzer> good morning
<ANTI_psychiatry> Psychiatry         i __ s :     F__R__A__U__D       F__R__A__U__D      F__R__A__U__D                      !!!!!!!!!!!!!!!!!!           PLS,visit: antipsychiatry.org
<cpaelzer> pitti: hi, the gnutls28 fix is blocked on some dep8 regressions on libaws and network-manager
<cpaelzer> pitti: it doesn't appear really to be related to me - is that a "known to happen, just buzz on retest" or what would you think?
<pitti> Good morning
<pitti> cpaelzer: libaws is part of the "gnat broke recently", we can just ignore that; and NM is flaky indeed; I'll have a look
<cpaelzer> pitti: ok, thanks
<mdeslaur> kees: nothing much we can do, nvidia hasn't published a fixed driver yet
<mdeslaur> kees: binary blob ftw
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<hron84> Hi! I trying to re-create a binary deb package without source (i have no access to the source package, this is a legacy, discontinued software) with fixed dependencies for Ubuntu Yakkety. However, I faced with error when trying to run dpkg-buildpackage against these configs: https://gist.github.com/hron84/dc1e009852e23e3357527ceefefa77cb the error is "binary build with no binary artifacts found; cannot distribute". What do I miss from my configs?
<hron84> (cross-posted from #ubuntu and #ubuntu-app-devel)
<lamont> recently, zesty seems to have decided that I don't need about 3 inches of my second display's width.
<lamont> not even sure which package to file that bug against
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: mterry
<vimpulse> lamont:  If this were Debian, you might be able to file it against "unknown" or maybe "general".  In Ubuntu, I'm not sure if you have any such option.
<vimpulse> lamont:  So -- ask us which package to file it against!
<LocutusOfBorg> rbasak, sorry, when does the addition to the team happens?
<nacc> mdeslaur: it seems like there might have been an upgrade-regression with mysql-5.5 in trusty (LP: #1637280)
<ubottu> Launchpad bug 1637280 in mysql-5.5 (Ubuntu Trusty) "Upgrade to 5.5.53-0ubuntu0.14.04.1 fails to start daemon, due to missing secure_file_priv directory" [Undecided,New] https://launchpad.net/bugs/1637280
<mdeslaur> nacc: that's weird. any idea why the postinst isn't being run?
<nacc> mdeslaur: not yet, that might be something good to test in a container/VM and try to run the postinst manually to see if it does work (then it's a matter of debugging why it didn't get invoked)
<nacc> mdeslaur: do you mind putting that in the bug?
<mdeslaur> nacc: I did run upgrade tests and it worked
<nacc> mdeslaur: ack
<nacc> rbasak: full bind9 import with patches-applied and unapplied in the history: https://git.launchpad.net/~nacc/ubuntu/+source/bind9
<nacc> rbasak: is LP: #1637703 one of the known classes of upgrade bugs?
<ubottu> Launchpad bug 1637703 in mysql-5.7 (Ubuntu) "package mysql-server 5.7.16-0ubuntu0.16.04.1 failed to install/upgrade: Ð¿ÑÐ¾Ð±Ð»ÐµÐ¼Ñ Ð·Ð°Ð²Ð¸ÑÐ¸Ð¼Ð¾ÑÑÐµÐ¹ â Ð¾ÑÑÐ°Ð²Ð»ÑÐµÐ¼ Ð½Ðµ Ð½Ð°ÑÑÑÐ¾ÐµÐ½Ð½ÑÐ¼" [Undecided,New] https://launchpad.net/bugs/1637703
<powersj> nacc: that user also filed LP: #1637701 which I just looked at
<ubottu> Launchpad bug 1637701 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.16-0ubuntu0.16.04.1 failed to install/upgrade: Ð¿Ð¾Ð´Ð¿ÑÐ¾ÑÐµÑÑ ÑÑÑÐ°Ð½Ð¾Ð²Ð»ÐµÐ½ ÑÑÐµÐ½Ð°ÑÐ¸Ð¹ post-installation Ð²Ð¾Ð·Ð²ÑÐ°ÑÐ¸Ð» ÐºÐ¾Ð´ Ð¾ÑÐ¸Ð±ÐºÐ¸ 1" [Undecided,Incomplete] https://launchpad.net/bugs/1637701
<rbasak> nacc: neat, thanks.
<rbasak> nacc: maybe add the filename to the subject if "No DEP3 Subject or Description header found"? Sometimes if there's nothing else the filename is still informative.
<rbasak> nacc: I'm starting to suspect a new bug affecting release upgrades from 14.04 to 16.04 causing that error (7703).
<rbasak> I had reproduction steps until diglett broke (I still have them but haven't retried yet).
<nacc> rbasak: the filename for a patch is alwasy present
<nacc> rbasak: Gbp-Pq: ...
<rbasak> nacc: I mean right there in the summary.
<nacc> rbasak: oh but you want it in the commit message summary, ok
<rbasak> nacc: right. See https://git.launchpad.net/~nacc/ubuntu/+source/bind9/log/?h=applied/ubuntu/zesty-proposed for example
<rbasak> Perhaps even put just the filename, and "No DEP3 Subject or Description header found" only in the body?
<rbasak> Then the summary will be bad, and the body will explain why. But that is more useful than no summary at all.
<nacc> rbasak: so reverse the order? Gbp-Pq: as the summary ?
<nacc> rbasak: or on ly in the case of no header found?
<rbasak> You might still need Gbp-Pq: in the body for consistency with gbp and automation.
<rbasak> So...if no dep3, then filename (only) in subject, both "No DEP3 Subject or Description header found" and Gbp-Pq: ... in body.
<nacc> rbasak: ack
<rbasak> philroche, Odd_Bloke: FYI, gce-compute-image-packages added to the ubuntu-cloud packageset for yakkety and zesty.
<philroche> rbasak: Thank you
<LocutusOfBorg> nacc, php-imagick merge to probably fix testsuite? (imagemagick)
 * LocutusOfBorg leaves
<nacc> lutostag: will look at it, yep
<nacc> rbasak: would it make sense for mysql-server to detect 'thread_concurrency=...' like it does for key_buffer and myisam-recover? (LP: #1638521)
<ubottu> Launchpad bug 1638521 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.16-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1638521
<rbasak> nacc: yes. Please dupe to bug 1612517.
<ubottu> bug 1612517 in mysql-5.7 (Ubuntu) "Server fails to start after upgrade because of customized config and obsolete/renamed directives" [Undecided,Confirmed] https://launchpad.net/bugs/1612517
<nacc> rbasak: thanks!
<nacc> barry: is there a sensible way forward for LP: #1638583? I know little about mailman, just trying to understand the bug
<ubottu> Launchpad bug 1638583 in mailman (Ubuntu) "mailman 1:2.1.16-2ubuntu0.2 fails to upgrade on Trusty" [Undecided,New] https://launchpad.net/bugs/1638583
<nacc> powersj: would it make sense for the triage list to not list bugs where Ubuntu Server is already subscribed and the bug is >= triaged?
<barry> nacc: it's a tricky one because of some choices the debian maintainers have made.  basically, the packaging refuses to upgrade if there are "qfiles" laying around.  these files are the on-disk representation of the messages and their states between processing queues.  a running mailman system will almost always have these files laying around so it effectively means mailman can't be upgraded without sysadmin intervention.  i think it's
<barry> an overabundance of caution because lots of sites install from source where that isn't a restriction, and we try very hard not to break the qfile pickle format (i can't remember the last time we even changed it)
<barry> nacc: tbh, i would file a bug with debian and not worry about that for unattended upgrades, but still allow it for manual upgrades, if that's possible.
<rbasak> nacc: in that circumstance, it may still be a user volunteering a patch, in which case we might want to pay more attention.
<barry> but i'm not the debian maintainer of the package ;)
<nacc> rbasak: yes, that's true -- i think we could split it into two lists, though
<nacc> rbasak: purely updates, versus those that need to be triaged properly
<rbasak> nacc: what would be the benefit of doing that?
<nacc> rbasak: i'm only noticing that right now, particularly when i get behind, as i always do, the list is full of bugs that i don't need ot triage
<nacc> rbasak: it was purely a question, feel free to disregard
<nacc> rbasak: is LP: #1642275 familar to you?
<ubottu> Launchpad bug 1642275 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.16-0ubuntu0.16.04.1 failed to install/upgrade: podproces instalovanÃ½ post-installation skript vrÃ¡til chybovÃ½ status 1" [Undecided,New] https://launchpad.net/bugs/1642275
<rbasak> 2016-11-16T13:45:43.192868Z 0 [ERROR] InnoDB: Unable to lock ./ibdata1 error: 11
<rbasak> nacc: no, not seen that before.
<nacc> rbasak: i've seen that particular issue in a few bugs so far (the unable to lock in the logs)
<robert_ancell> slangasek, did you upload snapd into Debian? Would you be able to sponsor snapd-glib there too?
<slangasek> robert_ancell: I could do a sponsorship, for sure; what's the long-term plan for who will maintain this in Debian?  would you be the maintainer (are you a DM)?  have you talked to zyga about it?
<robert_ancell> slangasek, jbicha wanted it there. I'm not a DM and don't plan to be one. Haven't talked to zyga.
<slangasek> robert_ancell: does jbicha want to maintain it? :-)
<robert_ancell> slangasek, mostly wanted to check who would be best to do the sponsorship
<robert_ancell> I'm hoping :)
<slangasek> I could help out with sponsorship, but it's best if there's a path for someone closer to the action to get direct upload rights on it in Debian (DM)
<robert_ancell> slangasek, thanks. Will ask jbicha then
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<tsimonq2> mterry: Hello, ping. :)
#ubuntu-devel 2016-11-22
<smoser> nacc, hey.
<smoser> usd import -v --directory=isc-dhcp --lp-user=smoser --lp-owner=usd-import-team isc-dhcp
<smoser> KeyError: "Cannot describe - No tags can describe '02c1acc925e9b52df3cdb807c525d56464102d26'."
<smoser> never mind. seems better now (after a git pull)
<smoser> well, now i get
<smoser>  NameError: name 'remote_namespace' is not defined
<smoser> nacc, i pushed fix
<pitti> Good morning
<cpaelzer_> good morning
<cpaelzer> hi pitti, thanks for pushing gnutls through
<pitti> cpaelzer: no worries
<cpaelzer> tjaalton: hi, since you have the required "powers" and were related to bug 1640805 in the past, could you take a look at reviewing and uploading the fix I attached?
<ubottu> bug 1640805 in sssd (Ubuntu) "SSSD authentication fails after upgrade to 1.11.8-0ubuntu0.2" [High,Fix released] https://launchpad.net/bugs/1640805
<cpaelzer> That is the Trusty SRU portion of it which needs a sponsor
<tjaalton> cpaelzer: yep, uploaded
<cpaelzer> thank you tjaalton
<tjaalton> and committed to git
<cpaelzer> tjaalton: sorry I didn't check on the VCS - thank you
<tjaalton> no worries, easy to apply the debdiff
<cpaelzer> tjaalton: would that have been a LP git or is the Ubuntu branch on alioth
 * cpaelzer is looking up the pkg
<tjaalton> on alioth
<cpaelzer> ah ok
<tjaalton> i'm not sure how to best integrate with lp
<mwhudson> pitti: hello
<pitti> hey mwhudson, how are you?
<mwhudson> pitti: fine, wondering about autopkgtests again
<mwhudson> pitti: is the process by which the tests to run for a given upload to -proposed documented somewhere?
<pitti> mwhudson: the top-level page is https://wiki.ubuntu.com/ProposedMigration; it links to various details
<mwhudson> pitti: in particular, does a depends on $foo in $bar's debian/tests/control mean that an upload of $foo will run $bar's tests?
<pitti> mwhudson: yes, britney has done reverse test dependency triggering for a few months now
<mwhudson> pitti: great, thanks
<mwhudson> pitti: the wiki is slightly out of date then i think :-)
<smb> good to know :)
<pitti> we hadn't had that for many years, but it led to hard-to-diagnose regressiosn
<pitti> mwhudson: I don't think "out of date", but I'm happy to clarify "reverse dependencies" to ".. binary and test .."
<mwhudson> pitti: ok, i have the edit page open anyway :)
<mwhudson> https://wiki.ubuntu.com/ProposedMigration?action=diff&rev2=25&rev1=24
<mwhudson> pitti: anyway, thanks
<pitti> thanks
<tinoco> cpaelzer: https://bugs.launchpad.net/qemu/+bug/1626972
<ubottu> Launchpad bug 1626972 in qemu (Ubuntu Zesty) "QEMU memfd_create fallback mechanism change for security drivers" [Undecided,In progress]
<tinoco> is done for you. waiting on sponsors now
<tinoco> ill continue working with vhost log upstream in parallel
<tinoco> cpaelzer: btw, are u a sponsor by any chance ;) if you are, feel free to test/upload it :o)
<cpaelzer> tinoco: hi
<tinoco> cpaelzer: o/
<cpaelzer> tinoco: I just uploaded a minor fix to zesty which means one more debdiff for you - but not more I hope
<tinoco> cpaelzer: i didn't do zesty
<tinoco> since it was behind xenial
<cpaelzer> behind yakkety I know
<tinoco> oops, yakkety
<cpaelzer> but I did the upload while you were writing this :-)
<cpaelzer> just replied to you via mail as well
<tinoco> cpaelzer: ok, let em check then. i can provide the debdiff, no problem
<cpaelzer> tinoco: ok, I will throw all these at a ppa of mine and run some more tests against it
<cpaelzer> tinoco: opening a query to discuss what you already tested ...
<tinoco> cpaelzer: awesome!
<doko> is anybody able to start quassel-client on a Unity desktop? the UI doesn't come up. on all of xenial, y and z. happened with a recent update ...
<doko> python-vmware-nsxlib/amd64 unsatisfiable Depends: python-netaddr (>= 0.17.3)
<doko> python3-vmware-nsxlib/amd64 unsatisfiable Depends: python-netaddr (>= 0.17.3)
<doko> zul: ^^^
<zul> doko: cool thanks ill have a look today
<nacc> smoser: thanks, i was just about to fix the same way, thanks!
<nacc> smoser: sorry for the breakage
<nacc> rbasak: i think i found another attribute case, if a .gitattributes has specific files listed with eol, then '* -text' doesn't help :/
<slangasek> infinity: stgraber: kees: mdeslaur: TB meeting in 18minutes
<mdeslaur> ack
<slangasek> rbasak: oh, you can't assign bugs to us?  well that's not good
<slangasek> rbasak: on Gunnar's bug I ran the commands you requested, but that doesn't put any packages in that packageset; is that part something the DMB can take care of or should I do that too?
<nacc> smoser: just pushed a small fix for gbp import-orig, fyi
<nacc> smoser: to use the new tag namespace correctly on import
<hjd> How can transition status be unknown? (http://people.canonical.com/~ubuntu-archive/transitions/html/html/glew.html)
<hjd> Also, if I'm reading http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt correctly, the on-going glew transition is why for instance https://launchpad.net/ubuntu/+source/widelands hasn't migrated to zesty-release, right?
<Laney> hjd: Affected but neither good nor bad
<rbasak> slangasek: assign bugs> yeah, that was surprising to me. I guess I need to be a member of the community team or something.
<rbasak> slangasek: yes, I can take care of populating the packageset. Thanks!
<Laney> rbasak: FYI edit-acl has a 'copy' action
<Laney> Which creates and copies the packages
<Laney> Might want to advise the TB to use that next time
<rbasak> Oh, neat. Thanks!
<rbasak> "<slangasek> I suggested using the bug tracker"
<rbasak> slangasek: I don't see an email. Did I miss a note somewhere?
<rbasak> slangasek: also I'd be quite happy if the process was manual - I file a bug *and* send to the ML. As long as I can forget once fired :-)
<nacc> smoser: fyi, another fix pushed!
<slangasek> rbasak: I did cc: you on my email reply
<nacc> smoser: what would be the ideal way (given our usd.run) to invoke `git tag -a` for creating an annotated tag (using the git-tag spawned editor)?
<nacc> smoser: nm, i think i figured it out
<smoser>  run.run(['git', 'tag', '--annotate', 'foo'], stdin=None, stdout=None, stderr=None)
<smoser> nacc, i think that works
<nacc> smoser: well, then how would you get input to the tag command? it'll just sit forever, afaict
<nacc> smoser: i think run() doesn't actually work without a string as an argument if shell=True
<nacc> smoser: it ends up calling 'sh -c git tag -a upload/1%9.10.3.dfsg.P4-10.1ubuntu2 HEAD'
<nacc> smoser: note the missing "" around the command
<nacc> smoser: if i put "" around that command (e.g., sh -c "git tag -a upload/1%9.10.3.dfsg.P4-10.1ubuntu2 HEAD"), it runs from the shell; without it, git just spits out its usage
<smoser> hm. it worked forme
<smoser> in ipython
<smoser> it brought up an editor
<nacc> smoser: strange, i'll keep testing then, might be something elese
<smoser> nacc, i just tagged the usd repository with 'foo', by doing:
<smoser> python3 -c 'from usd import run; run.run(["git", "tag", "--annotate", "foo"], stdin=None, stdout=None, stderr=None)'
<nacc> smoser: oh! i see what i'm doing wrong
<nacc> smoser: thanks!
<smoser> and, fwiw, both:
<smoser>  python3 -c 'from usd import run; run.run(["ls"], stdin=None, stdout=None, stderr=None, shell=True)'
<smoser> and
<smoser>  python3 -c 'from usd import run; run.run("ls", stdin=None, stdout=None, stderr=None, shell=True)'
<smoser> work for me
<nacc> smoser: yeah, my problem was not passing all of the None arguments
<nacc> smoser: thanks for the pointers!
<jgrimm> smoser, stgraber, slangasek: any idea why '::1' line in /etc/hosts differs between cloud-images and ISO d-i installed?   the latter, includes 'localhost', the former does not.
<stgraber> not sure. it does make sense having localhost listed for ::1 though, otherwise "ping6 -n localhost" wouldn't work
<smoser> jgrimm, i suspect that the process that writes that file is older than writing ipv6 localhost
<jgrimm> stgraber, indeed
<jgrimm> smoser, agreed.. though my desktop is missing it too
<slangasek> my desktop is not missing it fwiw
<jgrimm> slangasek, interesting
<slangasek> but my desktop was installed with d-i, not ubiquity, because lvm+crypt
<jgrimm> ah
<slangasek> I'm trying to remember if this was a bug we fixed in ubiquity
<jgrimm> mine was ubiquity installed, circa wily
<jgrimm> slangasek, ryan found an old one claiming it was fixed
<slangasek> so, I think the right answer is to include localhost for the ipv6 address, and we should fix the cloud image build scripts to match d-i here
<jgrimm> slangasek, cool. that's was my gut feel, except to wonder if someone intentionally backed it out at some point??
<slangasek> jgrimm: checking the current /var/lib/dpkg/info/netbase.postinst, which should be considered authoritative, we are including localhost for ::1.
<smoser> well, if that were the case then hopefully said process has version control on its /etc/hosts writing.
<smoser> slangasek, is it 'localhost' ?
<slangasek> things that deviate from that probably do so out of ignorance rather than by design
<smoser> i have ip6-localhost and ip6-loopback
<slangasek> smoser: in /var/lib/dpkg/info/netbase.postinst?
<smoser> no, in /etc/hsots
<smoser> yeah, i have no 'localhost' entry for ::1
<jgrimm> smoser, then presumably you were a cloud-image, or ubiquity installation
<smoser> ubiquity, yeah.
<smoser> i didnt realize we were speciically speaking of 'localhost'
<jgrimm> no worries
<jgrimm> slangasek, given responses i'll just open bugs against the offenders
<slangasek> jgrimm: I suspect livecd-rootfs for both
<jgrimm> slangasek, cool. thanks
<jgrimm> 1644009
<jgrimm> bug 1644009
<ubottu> bug 1644009 in livecd-rootfs (Ubuntu) "/etc/hosts ::1 line should additionally include 'localhost'" [Undecided,New] https://launchpad.net/bugs/1644009
<nacc> rbasak: jgrimm: well, in pleasant news, even with all the changes to the importer, continuing the php-imagick import to re-merge worked and the rebase went through straightforwardly. In that particular case, we may be able to drop parts of the delta (testing those cases now), but it's nice to see.
<jgrimm> nacc, nice!
<jgrimm> nacc, did you see my poke about usd merge error I was getting this morning?
<nacc> jgrimm: no, sorry!
<nacc> jgrimm: too many overnight pings, i expect
<jgrimm> :)
<nacc> jgrimm: can you resend?
<jgrimm> ack
<jgrimm> nacc: pretty simple, i was just trying to do a usd merge, with a fresh usd, and fresh clone
<jgrimm> nacc, ERROR:Failed to create local branch (debian/sid). Does it already exist (pass -f)?
<nacc> jgrimm: ok, i just pushed those fixes before lunch
<jgrimm> nacc, ok i'll retry, thanks
<nacc> jgrimm: can you try it again and let me know, and if it stilld oesn't work, send me the src pkg name and i'll reproduce
<jgrimm> nacc, different behavior at least.  fyi, i did a fresh clone again too
<jgrimm> nacc, ERROR:tag is not a defined object in this git repository.
<jgrimm> nacc, the package is at
<nacc> jgrimm: ah, sorry, i just changed behavior! :)
<nacc> jgrimm: just run `usd merge ubuntu/devel`
<jgrimm> nacc, ah... :)
<nacc> jgrimm: the subcommands were unnecessary -- in the general case you'll do both back to back
<nacc> jgrimm: that succeeded for me locally
<nacc> let me update the wiki too
<jgrimm> nacc, thanks sir
<jgrimm> nacc, indeed verified that works
<nacc> jgrimm: note that if you are doing a re-merge
<nacc> jgrimm: meaning there is an upload tag earlier
<jgrimm> its not a remerge
<nacc> jgrimm: then you might want `usd merge --tag-only`, and then actually do a git-rebase
<nacc> jgrimm: ok
<jgrimm> good to know tho!
<nacc> jgrimm: presuming no new delta added, that is; (meaning your last upload/ tag matches ubuntu/devel)
<nacc> jgrimm: i'll try and document these cases on the wiki
<jgrimm> nacc, sounds good!  fyi <cmd> -h output on wiki page are stale too
<nacc> jgrimm: yep, i was trying to stabilize the tooling and then c&p again
<jgrimm> thanks sir
<nacc> jgrimm: will update by EOD
<nacc> mdeslaur: i think your imagemagick upload clobbered the fixes that were in 8:6.8.9.9-7ubuntu4 (and thus it regresses php-imagick)
<nacc> mdeslaur: this is because (and i'm pretty sure i reported this to the debian maintainer who ignored it), the debian backports of certain upstream fixes are wrong/incomplete
<rbasak> slangasek: that's odd. I think I'm missing it. Did you Cc the list too? https://lists.ubuntu.com/archives/technical-board/2016-November/thread.html doesn't have it either.
<rbasak> jgrimm, nacc: that's odd. "ERROR:Failed to create local branch (debian/sid)" was what I complained about the other day too, but it since worked for me since before today.
<nacc> rbasak: it was the importer -> lpusip change
<LStranger> could anyone tell me why openbox-3.6.1-3 is still in proposed? gilir put it there a month ago and it's still there.
<rbasak> Ah
<nacc> rbasak: it should work now on a fresh clone and merge
<rbasak> OK, thanks.
<nacc> LStranger: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openbox
<nacc> LStranger: it regressed plasma-framework's autopkgtests
<LStranger> nacc: ah, I see, thank you very much
<LStranger> probably I should poke debian maintainer to add the dependency in debian too
<LStranger> or may be just open a RC bug instead :D
<LStranger> if I get it right, the openbox-kde session would not work in current state unless kde session is installed
<tarpman> LStranger: are we looking at the same log? the failure linked there looks like bug 1590956 to me... doesn't look like openbox's fault
<ubottu> bug 1590956 in plasma-framework (Ubuntu) "plasma-framework 5.22.0a-0ubuntu1 fails tests on s390x" [Undecided,Confirmed] https://launchpad.net/bugs/1590956
<mdeslaur> nacc: hrm, I'll take a look tomorrow. Is there a bug for php-imagick being broken now?
<mdeslaur> nacc: I have another imagemagick update coming out in a few days I believe, so I can fix it at the same time
<slangasek> rbasak: oh wow, my local dns is broken and mail not going out, thanks for the prod :)
<nacc> mdeslaur: i think what's missing is that the deb8u5 did refresh one bug and pick up the patch, but the original backport that was refresh is still wrong (see my messages in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811308)
<ubottu> Debian bug 811308 in imagemagick "Multiple minor security issues" [Normal,Fixed]
<nacc> mdeslaur: that has the three upstream backports that are missing, and cause php-imagick to fail
<nacc> mdeslaur: well, imagemagick is stuck in proposed
<nacc> mdeslaur: so no bug, but i can file one :)
<LStranger> tarpman: well, I thought it was about missing dependency on plasma-workspace there, probably I'm wrong
<nacc> mdeslaur: so the issue is ubuntu9's 0070-Fix-PixelColor-off-by-one-on-i386.patch and ubuntu10's are different. I'm guessing that is due to taking Debian's version
<nacc> mdeslaur: but our version had add-on fixes, i apologize for my poor changelog not indicating that more clearly (i've since learned better!)
<nacc> mdeslaur: would it be more productive to just merge imagemagick?
<mdeslaur> nacc: I have to see if the cves are fixed in unstable, but sure we should be merging it
<mdeslaur> nacc: sorry for overwriting your fix, I'll make sure to correct it in my next updates to the stable release
<nacc> mdeslaur: sorry, just to make sure i'm not crossing wires -- i'm only seeing the failure to migrate in z-p
<mdeslaur> oh! Does it just affect the autopkgtest?
<nacc> mdeslaur: we'd be able to drop my backports, at least, if we merge, as they are fixes from upstream that were mis-cherry-picked back. I'm happy to take a look at the merge, if you want
<nacc> mdeslaur: yeah, i think so -- i mean it's a functional bug in the package, that only php-imagick provokes :)
<mdeslaur> nacc: sure, could you handle the merge?
<mdeslaur> nacc: I can check tomorrow if all the cves are fixed in unstable
<nacc> mdeslaur: yep, i'll add it to my list, most of the updates to the package were by me :)
<mdeslaur> cool, thanks!
<nacc> mdeslaur: thank you!
<slangasek> pitti: so, systemd-resolved apparently stopped resolving ipv6 names for me, and I'm not sure how to debug
<juliank> Hmm, should I pass -v1.2.15 when building apt 1.2.17 which replaces the 1.2.16 in the xenial-proposed unapproved queue (1.2.15 is the one in -updates), or does that not matter at all?
<juliank> Currently it also has a weird test failure, not sure what's going on there...
<LStranger> anyway, I've filed an RC bug against Openbox in Debian, should it help to get openbox from proposed into zesty?
<LStranger> why I'm interested - my friends need #1336521 to be fixed in LTS releases.
<Unit193> (Debian #845386)
<ubottu> Debian bug 845386 in openbox-kde-session "openbox-kde-session package is unusable" [Grave,Open] http://bugs.debian.org/845386
<LStranger> for myself I've created a patched package but I want others to have fix too. :)
<LStranger> tarpman: so far, if that isn't openbox fault, what can be done to let openbox 3.6.1-3 enter zesty? this another bug will be fixed later then.
<juliank> Hmm, the arm64 build failure for trusty bash holding back bug 1422795  is not a regression of that upload (the failing file was not changed at all) Should I still generate a  regression-proposed bug report for that?
<ubottu> bug 1422795 in bash (Ubuntu Trusty) "bash crashes often if inputrc contains revert-all-at-newline" [High,Fix committed] https://launchpad.net/bugs/1422795
<juliank> The fix is basically ready
<tarpman> LStranger: you have to find someone who has the ability to bypass that autopkgtest regression... I don't know who that would be. someone here, I'm sure
<juliank> Proposed bash fix: http://paste.ubuntu.com/23519397/
<LStranger> well, I'm asking such someone then -- do it, please, bug 1336521 is pretty annoying for people
<ubottu> bug 1336521 in pcmanfm (Ubuntu) "Application Startup Notify fully ignored" [Undecided,Confirmed] https://launchpad.net/bugs/1336521
<Unit193> LStranger: They tend to want you to attach debdiffs, and sub sponsors.
<LStranger> Unit193: the matter is in migration Debian updated package into Ubuntu
<juliank> Hmm, it's even stranger.
<juliank> The same line causing the error on arm64 in trusty is present in zesty as well, but it works there.
<LStranger> Unit193: the difference in 3.6.1-1ubuntu2 was kde-workspace was replaced with plasma-desktop, which is also wrong but in 3.6.1-3 that kde-workspace-bin dependency is removed so no difference except missing dependency, which I filed as a grave bug so it will be fixed soon
<juliank> doko: You might want to look into bug 1644048 - there's a printf(ngettext(...)) line in bash's builtins/help.def that causes a FTBFS on arm64 in trusty, but not on other architectures, and not in newer releases.
<ubottu> bug 1644048 in bash (Ubuntu Trusty) "4.3-7ubuntu1.6 FTBFS on arm64" [Undecided,New] https://launchpad.net/bugs/1644048
<LStranger> so far it fits into zesty so I hope someone would push a button here
<LStranger> well, time to sleep for me :)
#ubuntu-devel 2016-11-23
<nacc> rbasak: if you have time, i'd like to pick your brain on a few things tmrw; particularly, it seems like my naive approach doesn't quite work for figuring out what branch should be used for the 'devel' branch for stable releases (possibly even for the ubuntu/devel branch?) e.g. php7.0's latest version is in xenial-security or xenial-updates, but not in xenial-proposed
<pitti> Good morning
<pitti> slangasek: usually, stop systemd-resolved.service, and run the binary in a terminal with SYSTEMD_LOG_LEVEL=debug, then try to resolve the name
<pitti> slangasek: or, just temporarily increase the global log level with "systemd-analyze set-log-level debug" and then grab it from journalctl -u systemd-resolved.service
<Unit193> infinity: Can't remember what I was going to ask you now, but any chance you'll merge dpkg from Debian for .buildinfo support?
<pitti> stgraber: could you add zesty to "lxc image list ubuntu:"? I would have thought that even happened automatically (we do import them through simplestreams in scalingstack), but apparently it doesn't?
<rbasak> pitti: use ubuntu-daily:zesty
<pitti> stgraber: erk, nevermind -- ubuntu-daily:
<rbasak> :)
<pitti> yeah, instance # 2234982 of finding the solution right after you publicly ask
<pitti> rbasak: .. and good morning to you!
<rbasak> Good morning!
<ginggs> hi, src:grunt hasn't sync'd automatically from Debian, should I do it manually? grunt is not in sync-blacklist, but another package with the same name was removed in 2009
<rbasak> ginggs: http://people.canonical.com/~ubuntu-archive/auto-sync/current.log suggests it isn't auto-synced because it existed previously in Ubuntu and was deleted manually. So if it now should go in Ubuntu, then I believe it needs a manual sync.
<rbasak> http://people.canonical.com/~ubuntu-archive/auto-sync/current.log
<rbasak>  0.5.1 (karmic): Deleted (removed by Steve Langasek: (From Debian) ROM; No upstream release since 2002; UUCP obsolete)
<ginggs> rbasak: thanks for confirming, sync'd
<ricotz> doko, barry, hi, it looks like python2.7 in zesty-proposed (2.7.12-7) breaks at least bzr
<Tribaal> Hi all, I *think* I got all I need to ask for sponsorship to push my patch into zesty for https://bugs.launchpad.net/python-jujuclient/+bug/1644153 . Could anybody confirm, maybe? (I attached a debdiff adding a quilt patch to the bug)
<ubottu> Launchpad bug 1644153 in python-jujuclient (Ubuntu) "SSL handshake fails on xenial" [Undecided,New]
<caribou> rbasak: arges: Are you taking care of SRU today ? If so, could someone release the Trusty SRU for LP: #1584485 ?
<ubottu> Launchpad bug 1584485 in samba (Debian) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [Unknown,New] https://launchpad.net/bugs/1584485
<caribou> we'll worry about the other releases later
<rbasak> caribou: yes. I'll take a look.
<caribou> rbasak: thanks
<caribou> rbasak: thanks!
<rbasak> You're welcome!
<rbasak> juliank: most of your apt SRU bugs seem to be missing SRU information.
<juliank> rbasak: Yeah, I was asking someone to provide these who actually has these bugs. I just know that they are fixed....
<juliank> rbasak: The gdebi one should be easy to rework, the ubiquity one is a bit more complicated, as I'm not sure what exactly the steps are there.
<rbasak> juliank: if we struggle to find someone impacted, I'm not sure we should be SRUing.
<juliank> But I know that those are fixed, because the code was generalized.
<juliank> That is, we abstracted the formatting of the progress logging and made it locale-independent
<rbasak> zul: your nova-lxd upload in the trusty queue appears to overwrite the previous changelog message.
<mitya57> ricotz, doko, barry: FWIW I filed Debian #845335 for bzr breakage
<ubottu> Debian bug 845335 in bzr "bzr: Broken with python2.7 2.7.12-7" [Grave,Open] http://bugs.debian.org/845335
<zul> rbasak: can you reject it please
<rbasak> zul: are you backporting newer packaging or adding to the existing Xenial packaging?
<rbasak> Though I suppose if backporting then the changelog should say that.
<zul> rbasak: backporting newer version of nova-lxd
<juliank> rbasak: The ubiquity-related one has 422 heat, the other 90. I think people are affected by it. I now added the information based on the initial bug reports, I think that should suffice. And basically all those bugs are fixed by the same commit...
<rbasak> zul: I think this has come up before, and we concluded that it doesn't matter too much what you base the changelog on. But I think the choices are to base it on what was previously in xenial-updates, or basing it on wherever the backport is coming from please.
<juliank> bug 1593583 is an odd one: The commit fixing it and the commit causing it are both in the 1.2.16 release.
<ubottu> bug 1593583 in apt (Ubuntu Yakkety) "Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_yakkety-proposed_InRelease" [Undecided,New] https://launchpad.net/bugs/1593583
<juliank> rbasak: Also I should note that 1.2.17 should be hitting the queue in a few hours to fix bug 1642386
<zul> rbasak:  yeah im going to base the changelog whatever is on xenial-updates, it wasnt in the git tree when i did the upload
<ubottu> bug 1642386 in apt (Ubuntu Xenial) "At least one invalid signature was encountered." [Undecided,Triaged] https://launchpad.net/bugs/1642386
<rbasak> zul: OK, thanks.
<juliank> I gotta get to work now, though, so I'll be gone for up to 3 hours.
<rbasak> bdmurray: for bug 1640318, why not use the errno module's symbolic constants rather than hardcoding a number everywhere? Also, that's a whole load of duplication - could that be in a "attempt_print" function or something?
<ubottu> bug 1640318 in update-notifier (Ubuntu Yakkety) "/usr/lib/update-notifier/package-data-downloader:OSError:process_download_requests:/usr/lib/update-notifier/package-data-downloader@305:process_download_requests:print_exc:print_exception" [High,In progress] https://launchpad.net/bugs/1640318
<rbasak> bdmurray: That's more for the development release. I guess it probably doesn't matter too much for an SRU.
<rbasak> Are errno values the same across all architectures?
<barry> mitya57: ouch.  i'm not sure if i'll get a chance to look at it before usa thanksgiving holiday weekend
<mitya57> To me it looked like Bzr doing something crazy (i.e. a bug in Bzr, not in Python)
<doko> then why file a RC issue for python?
<mitya57> I filed it against Bzr
<mitya57> Just X-Debbugs-Cced you :)
<ginggs> so it seems that node-lex-parser needs to be bootstrapped because of a circular dependency with jison
<doko> ahh
<rbasak> caribou: I'm confused by your makedumpfile upload in the Xenial queue. It seems to be making six changes but you only have one bug?
<rbasak> caribou: eg. "Support Hyper-V hypervisors" sounds like it should have a bug reference with SRU paperwork.
<caribou> rbasak: those were Debian bug that got fixed with the Zesty sync
<caribou> rbasak: i can create new bugs for each one of them if you want
<caribou> rbasak: so those bugs where never reported as Ubuntu bugs, but rather as Debian bugs
<rbasak> caribou: we either need one bug per issue being cherry-picked. Or if you want to backport fixes in a new upstream release wholesale, we have a process for that too.
<rbasak> But as it is now, we'll miss appropriate SRU verification for most of your proposed update.
<rbasak> caribou: for example, what regressions might "Support Hyper-V hypervisors" accidentally introduce? Right now, that isn't being considered.
 * juliank basically does apt upstream stable releases, but they only end up in Ubuntu right now which makes SRUs a bit "confusing" :)
<caribou> rbasak: then you may want to reject the X & Y SRU; I'll adjust to what can be verified on Ubuntu & respin
<juliank> doko: Any reason not to upload the fix for bug 1644048 to zesty? I mean, gcc does not detect it there, it only detects the format-security issue in trusty on arm64.
<ubottu> bug 1644048 in bash (Ubuntu Trusty) "4.3-7ubuntu1.6 FTBFS on arm64 only with format-security error" [Undecided,Confirmed] https://launchpad.net/bugs/1644048
<juliank> But the code is the same.
<rbasak> caribou: OK thanks.
<juliank> So, I figured, I push the fix to zesty first, and then do the trusty SRU
<doko> juliank, didn't have time to look at it. but why upload it when it's ok in zesty?
<juliank> doko: Well, it's arguably a gcc bug that it does not detect it there - it's a printf(ngettext(...)) and supposedly bugs have to be fixed in devel first before being SRUed )
<doko> well, it is fixed, apparently in gcc-6
<juliank> doko: Well, I'd say gcc is broken, and only works correctly for that on trusty arm64. Because printf(ngettext(...)) should really do the format-security warning AFAICT
<juliank> because ngettext might return stuff with % in it, and passing that as the first argument to printf() is "dangerous" :)
<juliank> I can only fix that in trusty for now and we can investigate why it does not fail in zesty, as long as rbasak does not come and say: Hey, that bug needs to be fixed in zesty first :D
<rbasak> If the bug doesn't exist in Zesty, I think that's OK :)
<juliank> Well, OK, I'll do that after work then together with the apt 1.2.17 SRU
<rbasak> If it's a latent bug that still exists in Zesty but happens to not trigger right now, then it should probably be fixed in Zesty first though.
<juliank> rbasak: It's the same line of code, but gcc only fails in trusty on arm64 (and only now, it did not use to with the previous uploads, despite the code being unchanged). So it's like gcc got better at detecting that issue in a trusty SRU but only on arm64, and not in newer releases...
<juliank> It's rather strange that this happens.
<juliank> But I don't really care why it happens that way, I just want to get the SRU building everywhere, and already verified a built binary on xenial (on amd64, not on arm64)
<ginggs> i tried boostrapping node-lex-parser in a PPA, but it fails with npm could not be installed. https://launchpad.net/~ginggs/+archive/ubuntu/testing/+sourcepub/7156939/+listing-archive-extra any ideas?
<juliank> rbasak: While you're complaining about SRUs: I don't know how launchpad deals with .changes files, does it make sense to include -v1.2.15 when replacing the 1.2.16 SRU with 1.2.17?
<rbasak> juliank: I'd say so, because your upload (IIRC) hasn't been published at all yet. Then the changes file will be accurate completely with all relevant bug references.
<juliank> Alright.
<juliank> Thanks, I thought that makes sense :)
<juliank> This week, we'll also see 1.4~beta1 for zesty (bringing about 15% more performance) and In a few weeks we'll have 1.3.2 and 1.2.18 fixing some more issues :)
<juliank> Anyone here has Description-md5 values containing upper case characters? Dropping support for that gives us another 6% performance increase...
<juliank> It never worked in cupt, and probably in other tools either
<rbasak> Laney: your gstreamer-vaapi upload in the Xenial queue makes the version number go backwards wrt. Yakkety.
<rbasak> Unless I'm missing something?
<Laney> does it?
<Laney> It might, I don'ot remember explicitly checking that
<Laney> DON'OT
<Laney> rbasak: Correct, I meant to put a ~ there
<Laney> See the version in -updates
<rbasak> Did I pass the SRU team newbie test? :-)
 * rbasak hopes Laney doesn't remember rbasak's screwup with gst-plugins-bad1.0 five minutes ago :-)
<Laney> rbasak: What screwup? :P
 * Laney calls it even
<Laney> This gst SRU has come back from the dead lately
<rbasak> \o/
<Laney> I forgot about it, nobody reviewed it and then a security researcher decided to poke gstreamer with a stick
<Laney> s/reviewed/verified/
<rbasak> tjaalton: I'm going to skip reviewing the libdrm SRU since I don't yet know about what you normally do wrt. test plans etc. for HWE, and I expect other SRU team members know more.
<rbasak> Whatever the plan is should probably be documented somewhere and linked to from the bug though.
<tjaalton> rbasak: libdrm is always backported as-is
<tjaalton> it doesn't break, period :)
<slangasek> pitti: if I run systemd-resolved that way, it spits me a whole lot of output; when I do the lookup that's been failing, it fails (only when systemd-resolved is running) but I see no mention of it in output; if I redirect systemd-resolved output so that I can search it instead of vgrepping the console, I get no output at all...
<pitti> slangasek: is that on a desktop? i. e. is it actually resolved which does hte lookup, or dnsmasq from NM?
<slangasek> pitti: aha, finally managed to catch some output in the vgrep
<slangasek> pitti: it is systemd-resolved; if I take resolve out of nsswitch.conf the bug goes away
<pitti> ah
<slangasek> and yes it's on the desktop
<slangasek> pitti: this appears to be the relevant bits of the log file; systemd-resolved claims a lookup failure, doesn't explain why, everything except systemd-resolved is happy resolving it http://paste.ubuntu.com/23522691/
<slangasek> pitti: it's a public hostname if you want to try to reproduce locally
<pitti> $ systemd-resolve becquer.dodds.net
<pitti> becquer.dodds.net: 207.224.24.209
<pitti>                    2001:470:e980::2
<pitti> ^ on my bos
<pitti> box
<slangasek> pitti: and here, it only returns the IPv4
<nacc> rbasak: available for a quick chat today?
<slangasek> pitti: to be clear, 'dig' against any of the nameservers around me (including against dnsmasq) returns the AAAA record; only resolved for some reason has pruned it.  Is there a cache I need to worry about clearing?  Is there any verbosity beyond 'debug'? :)
<shemgp> bzr branch ubuntu:cups cups.dev is not working for me. It says bzr: ERROR: Not a branch:
<shemgp> I'm trying to follow: http://packaging.ubuntu.com/html/udd-getting-the-source.html#branching
<nacc> shemgp: udd is deprecated :/
<infinity> s/deprecated/dead/
<nacc> shemgp: if you need the souce for cups, do `pull-lp-source cups`
<nacc> infinity: :)
<pitti> slangasek: it seems you cut out the interesting parts of the lookup from your paste?
<infinity> nacc: deprecated implies it might still work. :P
<shemgp> nacc, any pointers to updated docs?
<infinity> nacc: We stopped imports a long time ago
<slangasek> pitti: I didn't see anything else in there about it
<nacc> infinity: yes, good point :)
<nacc> shemgp: there aren't really any :/
<nacc> shemgp: the above will just download the current source package, e.g.
<slangasek> pitti: which bits are "interesting"? I see a bunch of unrelated messages
<infinity> shemgp: man pull-lp-source
<shemgp> so how do I submit a patch?
<infinity> shemgp: From there, other than the part where it's not a bzr repo, it's pretty much the same.  dpkg-buildpackage, etc.
<slangasek> pitti: in fact, the only messages in between that I cut are other dbus sent/received logs
<pitti> slangasek: I get this: http://paste.ubuntu.com/23522732/ (on the query above)
<infinity> shemgp: Make changes, dpkg-buildpackage -S, debdiff old.dsc new.dsc, attach diff to bug.
<slangasek> pitti: aha - I found it
<shemgp> Ok. I'll do that. Thanks
<slangasek> pitti: I had the IPv4 address of that host in my /etc/hosts, for network recovery purposes.  The IPv6 was not listed in /etc/hosts.  So systemd-resolved didn't bother asking DNS for the IPv6 name
<slangasek> pitti: that's a systemd-resolved bug, for sure; should I log it?
<slangasek> or is there already one somewhere?
<pitti> slangasek: ah, did that actually ask resolved? /etc/hosts is already done by "files" in nsswitch.conf's "hosts:"
<pitti> slangasek: but yes, if resolved consults /etc/hosts (I wasn't aware of that) and misbehaves there, please file a bug; I'm not aware of an existing one there
<infinity> pitti: It must have.  Note his earlier "if I remove resolve, it works".
<slangasek> pitti: it did, because 'files' didn't return an ipv6 answer, so it kept looking, so it got to resolved, which asked files, which didn't return an answer ;P
<pitti> right, sounds plausible
<pitti> slangasek: confirmed, thus straightforward to reproduce
<brendand> x
 * Laney blushes at brendand 
<brendand> Laney, that was for everyone, because we're all so awesome
<brendand> Laney, that, or i pressed enter with the wrong window focused. one of the two
<Laney> I choose to believe it was an outpouring of affection
<tvoss> rbasak: o/
<tvoss> rbasak: thanks for your feedback on https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1640823
<ubottu> Launchpad bug 1640823 in util-linux (Ubuntu Trusty) "[trusty] mount -o loop is limited to 8 loop devices" [Undecided,Fix committed]
<tvoss> rbasak: updated the patch, pitti is handling the upload, diff in my comment
<tjaalton> hm, noticed that log rotation has been broken for syslog on my laptop since feb 28th 2015..
 * pitti fixes a gazillion new "E741 ambiguous variable name 'l'" pycodestyle errors
<pitti> barry: ^ that's going to be fun, smells like a bunch of new FTBFS :)
<pitti> "E987 programmer is too lazy to type for verbatim variable names"
<pitti> err, "verbose"
<barry> pitti: i know :(  we've been hitting it in several upstreams.  we've seen a lot of E301->E306s and probably a bunch more new, split, or renumbered error codes
<pitti> barry: yeah, the new version now spots "expected 2 blank lines after class or function definition," in places the old one didn't
<pitti> but that's actually correct
<barry> yep
<barry> seen that too ;)
<pitti> quite an amazing tool :)
<pitti> (honestly)
<Laney> Automated testsuites running pep8 make me want to stab
<rbasak> Is it catch *all* short variable names?
<pitti> no, I think just 'l' in an expression
<rbasak> I tend to use them in small scopes or otherwise obvious scenarios.
<rbasak> Ah, OK.
<pitti> presumably because it's too similar to '1'
<pitti> yeah, I use those for two/three line scopes too, like
<pitti> for l in my_fd:
<pitti>    [.. do something with that line ]
<rbasak> Right.
<rbasak> Or def __setattr__(self, k, v)
<barry> flake8 is better imho, but yeah, it causes pain when they change the error codes
<rbasak> Or any other k, v pair in a dictionary comprehension, etc.
<pitti> barry: isn't flake8 just pycodestyle+pyflakes?
<barry> pitti: yeah, + plugins and better config
<barry> pitti: https://gitlab.com/warsaw/flufl.testing :)
<NixkorN> isnt that in poland?
<barry> among other places :)
<attente> https://www.irccloud.com/pastebin/Ba3yELUh/
<attente> has anyone noticed this problem recently with googletest/google-mock?
<seb128> attente, https://launchpad.net/ubuntu/+source/cmake-extras/0.7+17.04.20161123.5-0ubuntu1 ?
<seb128> attente, reading the bug seems it needs more work
<seb128> mir hits the issue as well
<attente> seb128: thanks!
<seb128> yw
<attente> yeah...
<attente> kenvandine: ^
<kenvandine> attente, ah
<slangasek> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1644330
<ubottu> Launchpad bug 1644330 in systemd (Ubuntu) "systemd-resolved assumes that /etc/hosts for one address family means it doesn't ask DNS for another" [Undecided,New]
<juliank> Uploaded a fixed bash to trusty now to fix the regression-proposed tracked in bug 1644048. It's a simple 6 character fix, changing printf(ngettext(...)) to printf("%s", ngettext()) - I'd really appreciate if someone could take a look at it and accept it to -proposed.
<ubottu> bug 1644048 in bash (Ubuntu Trusty) "4.3-7ubuntu1.6 FTBFS on arm64 only with format-security error" [Undecided,In progress] https://launchpad.net/bugs/1644048
<juliank> And the verification basically consists of checking it builds on arm64, so that's a piece of cake too
<infinity> juliank: The real curiosity there is why only arm64 cared...
<juliank> infinity: Yep. Probably a compiler bug - That's really deep in doko's area of expertise, though.
<infinity> juliank: Oh.  Perhaps not a compiler bug, but a misfeature, in that maybe arm64 is the only arch without a builtin printf(), thus the only one that throws the error correctly. :P
<juliank> Well, yeah.
<infinity> juliank: Though, unless that code is new in the previous SRU, still a mystery.
<juliank> Right, it's not new.
<juliank> That really must have regressed in some libc or gcc SRU at some point without someone noticing.
<infinity> juliank: OOI, is that format bug fixed in X/Y/Z?
<juliank> It's exactly the same there
<infinity> https://patchwork.openembedded.org/patch/127967/
<infinity> juliank: ^-- Well, you're not alone, at least. :P
<juliank> Nice
<infinity> juliank: That being OE may point at it also being ARM-specific. ;)
<infinity> juliank: Anyhow, in the interest of "bugfixes shouldn't get lost", and "this sure looks like a real bug to me", I'd like to see uploads for at least X and Z.
<infinity> juliank: And if you're doing those, Y isn't hard. :P
<infinity> juliank: The gcc behaviour change in trusty is an entirely different bug (and perhaps worth filing for doko), but not relevant to bash itself being obviously buggy.
<infinity> Hrm.
<infinity> Or is it?
<infinity> gettext/ngettext return a string.
<nacc> mdeslaur: working my way slowly through the imagemagick merge. I am noticing that the debian patches are not all correct. e.g., 0089-Fix-a-buffer-overflow refers to https://github.com/ImageMagick/ImageMagick/commit/78f82d9d1c2944725a279acd573a22168dc6e22a but adds a #define that is not present upstream. And seems unnecessary, as the macro is already called in that file?
<sarnold> nacc: imagemagick upstream source control is a pile of shit
<nacc> sarnold: no joke.
<nacc> sarnold: well, debian's is not much better, tbh :/
<sarnold> nacc: they check in unrelated things into checkins, back half of it back out again two commits later, etc. half the checkin comments are "...". At least those aren't misleading.
<nacc> sarnold: missing  parts of backports, i guess it's symptomatic of upstream
<nacc> sarnold: yeah, i've noticed the '...'
<sarnold> nacc: yes. upstream's even worse at git than I am. :)
<sarnold> nacc: I suspect they never once asked "how do I see what I'm about to check in?"
<nacc> sarnold: yeah :/
<infinity> -checking for GNU gettext in libc... yes
<infinity> +checking for GNU gettext in libc... no
<infinity> +checking for GNU gettext in libintl... no
<Unit193> infinity: I remembered.  What's the procedure for something in main to get "auto" updates like firefox, virtualbox, etc?
<infinity> juliank: That's the real change between the builds.
<sarnold> infinity: O_o
<infinity> juliank: It's using a local libintl due to configure failing to find the real one.
<juliank> infinity: Oh
<infinity> juliank: And the local libintl probably has a slightly different prototype for ngettext.
<juliank> weird
<infinity> So, where the heck did gettext go? :P
<sarnold> nacc: I'm sorry to say that I don't know what this means for -you- -- just that you ought to be aware that upstream's patches are _terrible_. They include unrelated things and they spread important things across multiple checkins, and the checkin comments are best ignored entirely.
<infinity> Seems like a glibc SRU almost certainly couldn't have broken this.
<nacc> sarnold: yeah, i'm not looking at the upstream for that, per se
<nacc> sarnold: the issue i ran into is that a claimed backport of upstream in a debian srcpkg is adding things
<infinity> Unit193: An amazingly compelling argument for why that thing should be a unique snowflake.  With a 99% chance of you being told no.
<juliank> sarnold: Oh, I don't know if you noticed it - The apt 1.2.17 upload took one hour longer than the 48 hours max I estimated.... ;)
<nacc> sarnold: i'm tempted to just fix imagemagick in z-p, but that's just delaying the inevitable pain of this merge
<sarnold> juliank: ha! I haven't gotten to that yet. nice. :)
<infinity> Unit193: Firefox has an exception there for all sorts of icky reasons, but it's not an example to be followed.
<Unit193> infinity: Figured, thanks.  I'll continue with the PPA route.  Yeah, know it's not normal at all, thus exceptions, just like tzdata isn't normal (I'm thinking of geoip-database.)
<juliank> infinity: So, we probably should find out where gettext went on arm64 and really check if that's a bash-only problem.
<infinity> Unit193: Oh.  geoip-database may well qualify for the same sort of exception we use for tzdata.
<infinity> Unit193: Framing it as "like firefox" is why I responded with "eff off". :P
<infinity> Unit193: "Like tzdata" is much more compelling argument for "pure data" sorts of packages.
<Unit193> Well, "like firefox" does deserve that. :P
<Unit193> infinity: And non-static data, at that.
<infinity> juliank: Indeed.
<infinity> Unit193: Yep.  We've been looking at the same thing for wireless-regdb as well.
<Unit193> That's the other one I couldn't think of.
<infinity> Unit193: And we also do the PCI/USB databases in pciutils/etc occasionally.
<infinity> juliank: So, I could work around it, perhaps, by copying the SRU to the security PPA and back again. :P
<infinity> juliank: So it builds without -updates.
<infinity> *cough*
<nacc> mdeslaur: so i'm feeling kind of overwhelmed by the merge. I think I have everything but hte upload in z-p merged to the latest Debian. Would you be ok with replaying that on top of a new upload? I can also send you the debdiff from Debian as a base (or point you at the git tree)
<infinity> juliank: That would unblock 1.6.  But the "where the heck did gettext go" thing should still be investigated.
<juliank> infinity: As long as we get it unblocked, everything is fine with me :)
<infinity> juliank: Yeah, doing that now.
<infinity> juliank: And seeing if it helps..
<infinity> https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/11247502
 * infinity waits with bated breath.
<infinity> juliank: So, it's worth noting that your patch is probably still a valid upstream submission.
<infinity> Since, in the case where the bunldled libintl gets used, then -Wformat-security will indeed explode there.
<infinity> But in Debian/Ubuntu, the bundled libintl should NEVER be used.
<infinity> So...
<infinity> Whee.
<robert_ancell> slangasek, can you help demote some packages to universe? bug 1643194
<ubottu> bug 1643194 in mozc (Ubuntu) "Please demote these binary packages to universe" [Undecided,New] https://launchpad.net/bugs/1643194
<robert_ancell> It will unblock a gnome-software update
<infinity> robert_ancell: Doesn't need a bug (we have reports about it anyway), but fixing.
<infinity> slangasek: ^-- disregard robert_ancell, I'm fixing it.
<robert_ancell>  infinity, ok, thanks!
<infinity> robert_ancell: Done.
<robert_ancell> infinity, ta
<infinity> checking for GNU gettext in libc... no
<infinity> #*!*%%
<infinity> Oh.  Because trusty-security has the latest gcc SRU in it, probably.
<infinity> Grr.
<infinity> Guess I get to ask a porterbox WTF.
<robert_ancell> cjwatson, hey I noticed the Launchpad homepage lists the number of Git repos in LP - do we have any data on how fast that is growing?
<infinity> ARGH.
<infinity> juliank: Oh wow, the plot thickens.  It actually does a configure check *twice* for gettext in libc.  The first time passes, the second doesn't.
<juliank> Wow
<infinity> I assume the second configure is called in a way that's breaking gcc slightly. :P
<infinity> But at least I can reproduce in a porter chroot, so should be able to see.
<infinity> Hah.
<infinity> It's binutils.
<cjwatson> robert_ancell: unfortunately not AFAIK
<robert_ancell> cjwatson, ok, thanks
<infinity> juliank: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1644363
<ubottu> Launchpad bug 1644363 in binutils (Ubuntu) "[trusty/arm64] binutils segfaults on bash gettext configure test" [Undecided,New]
<juliank> infinity: Aaaaah
<juliank> :(
<infinity> juliank: :( indeed.
<juliank> Bad ld!
<infinity> Bad bug. :/
<infinity> Makes one wonder how many other configure scripts it's silently broken in trusty updates.
<infinity> This one only breaks due to a mild fluke in bash's being incompatible with its own bundled libintl.
<cjwatson> robert_ancell: we need to hook some bits of LP up to statsd at some point
<cjwatson> (we have other graphing infrastructure, but it's pretty awkward to get at)
<robert_ancell> cjwatson, I was impressed with the number of git repos, it seems like it must be getting good use.
<infinity> juliank: Though, if it's a bug with -static, I guess that sees such infrequent use that hopefully the issue isn't widespread.
<infinity> doko: Insight on https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1644363 would be appreciated.
<ubottu> Launchpad bug 1644363 in binutils (Ubuntu Trusty) "[trusty/arm64] binutils segfaults on bash gettext configure test" [Undecided,Confirmed]
<infinity> juliank: On the plus side, I'd say this is truly out of your hands now. :P
<infinity> juliank: Unless you feel like debugging binutils segfaults.
 * juliank hides
<infinity> (Cause isn't that everyone's favourite way to spend an evening?)
<juliank> I do have arm64 hardware, but I don't have root on it...
<juliank> (it's my phone)
<infinity> Heh.
<infinity> I bootstrapped Ubuntu/armhf on a phone. :P
<infinity> I wonder if Sledge is aware that the N900 I sold him was node 0 for the armhf port.
<juliank> pitti: I'm surprised you had to reject the first apt 1.2.17 upload - I'd have suspected it to be incomplete and some queue thing to autoreject it. The second one is exactly the same binaries, I just aborted the first one, but maybe a bit too late.
<sarnold> juliank: fwiw I can't find any evidence of an apt build anywhere :/ not on the excuses page, not on https://launchpad.net/ubuntu/+source/apt and not on https://launchpad.net/builders/
<juliank> sarnold: Sure, it's in the unapproved queue.
<juliank> sarnold: Not built until someone says: Yes, we can let that go into -proposed....
<sarnold> juliank: aha. I'm clearly way undereducated on how The Rest of ubuntu works. :) thanks
<sarnold> juliank: .travis.yml is using wily?
<juliank> sarnold: Yep, that's the newest one. shippable.yml also runs the tests on xenial, but only as root right now, not as a normal user.
<juliank> That is, travis has no newer build environment than wily
<sarnold> juliank: how very odd. I'd expect them to target ltses before the intermediates..
<sarnold> juliank: thanks :)
<juliank> sarnold: Oh sorry. It's actually running trusty, I'm just pulling some stuff from wily
 * juliank attributes the slip to it being past midnight now
<sarnold> aha
<nacc> mdeslaur: https://code.launchpad.net/~nacc/ubuntu/+source/imagemagick/+git/imagemagick/+ref/merge
<juliank> sarnold: On shippable, we build in the standard xenial docker container.
<nacc> mdeslaur: there are some tags that hopefully help in there, but the tip of that branch is the merged (and successfuly autopkgtest'd) version, excluding the latest security update in z-p
#ubuntu-devel 2016-11-24
<nacc> mdeslaur: fyi, the corresponding import tree is present in ~usd-import-team, if you need to reproduce refs/tags along the way
<cpaelzer> good morning
<pitti> Good morning
<pitti> slangasek: thanks! will put that resolved bug on my list
<pitti> juliank: the queue doesn't autoreject it; you can upload the same version 10 times; of course only one of them can be accepted
<juliank> pitti: Maybe I was not clear: I thought it was an incomplete upload, so it should have had wrong hashes...
<pitti> juliank: apparently it made it through :)
<ginggs> pitti: morning! node-lex-parser needs to be bootstrapped because of a circular dependency with jison. apparently it needs to be built locally and then uploaded with binaries. can an archive admin do this?
<ginggs> i was able to build locally by reverting https://anonscm.debian.org/cgit/pkg-javascript/node-lex-parser.git/commit/?id=01595c51513806cfca489bf191c7c6cb349677e3 and adding a build-dep on nodejs-legacy
<ginggs> unfortunately that failed in my PPA with npm could not be installed (i can't see why)
<cpaelzer> pitti: thanks for your extra insight on the apparmor change I had
<cpaelzer> pitti: do you happen to know if there is something similar for disk devices?
<cpaelzer> pitti: I didn't find an abstraction for it, but I have another case where I add /dev/zd, /dev/nvme, ... to the already existing /dev/dm, ...
<cpaelzer> pitti: so a similar case on something that could (should?) be covered by an abstraction/blcokdevices or anything like it?
<pitti> cpaelzer: no, and that wouldn't make much sense
<pitti> cpaelzer: if you can write on block devices, you have unrestricted root
<cpaelzer> pitti: oh in that case it is a list of block device denies actually
<cpaelzer> pitti: that needed to be extended to silence some log noise
<pitti> ah, I see
<pitti> cpaelzer: no, I'm not aware of an abstraction there; that's also a bit tricky as there's a great variety of name patterns
<pitti> cpaelzer: wouldn't it be easier to deny it CAP_SYS_RAWIO or so?
<pitti> ah no, it's not that
<cpaelzer> pitti: I just wanted to make sure I'm not overlooking an abstraction again - if there is none I'm ok for the moment
<cpaelzer> pitti: thanks!
<showaz> mlmmj package without apparmor profile, postfix crash mlmmj-recieve
<showaz> https://lists.opensuse.org/opensuse-bugs/2016-09/msg02847.html
<doko> http://autopkgtest.ubuntu.com/packages/r/rpmlint/zesty/armhf
<doko> A server error occurred.  Please contact the administrator.
<doko> pitti: ^^^
<pitti> doko: ? looks fine to me?
<pitti> doko: these are new PEP-8 failures from new pep8
<doko> awesome, and barry is only handling turkey for a while ...
<pitti> doko: oh, you mean you got that when opening that history page -- that's bug 1639847
<ubottu> bug 1639847 in Auto Package Testing "web results incomplete/error out on locked DB" [Medium,Triaged] https://launchpad.net/bugs/1639847
<pitti> that has bitten a few times, I'll put that higher on my list
<doko> well, if it's a known pep8 issue, then please override these test results
<pitti> well, it's not an issue with pep8 itself, these are pep-8 issues in rpmlint (but I'll override the current version anyway for that)
<pitti> (done)
<mdeslaur> nacc: hi! so I looked at your merge. The _only_ change you need to merge is "Drop dependency on libopenjp2-7-dev". Please remove all the patches and debian/rules change
<mdeslaur> the other issues have been fixed in the actual code without needing to disable the coders, or have been fixed in a better way
<mdeslaur> nacc: that being said, there's a new package in unstable now, so you need to merge that one in
<mdeslaur> nacc: thanks!
<mdeslaur> cpaelzer: any plans on updating qemu in zesty? I was waiting before pushing all the security patches from yakkety into zesty as perhaps we were going for 2.7 soon...
<cpaelzer> mdeslaur: hi, yes there are plans
<cpaelzer> mdeslaur: I'm opening a query for all the not-set-in-stone details not going to the log so that I get yelled at later on :-)
<caribou> anybody from the SRU team not eating turkey today ?
<caribou> rbasak: ^^
<caribou> LP: #1584485 is causing regressions
<ubottu> Launchpad bug 1584485 in samba (Debian) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [Unknown,New] https://launchpad.net/bugs/1584485
<rbasak> bdmurray: we didn't really talk about how to deal with regressions ^
<rbasak> I could push a revert, or I noticed that sru-release has a phasing option.
<rbasak> "sru-release -z 0 trusty samba" maybe?
<rbasak> http://people.canonical.com/~ubuntu-archive/phased-updates.html suggests already done?
<rbasak> pitti: ^ help?
<pitti> rbasak: right, seems someone/something already set the phasing to 0
<rbasak> Should we upload a reverting 2:4.3.11+dfsg-0ubuntu0.14.04.3 and push it through?
<pitti> rbasak: but I still think uploading a revert is useful, particularly if there's no obvious solution in sight
<rbasak> pitti: OK, thanks. Any particular process? Or just review, accept and release immediately?
<pitti> rbasak: basically, yes; the revert should still get some basic testing of course
<rbasak> pitti: ack on basic testing - presumably no 7 day aging period though?
<pitti> right
<rbasak> caribou: could you upload the revert please?
<rbasak> pitti: for the future, is one SRU team member +1 for all of that is OK? And would "sru-release -z 0 trusty samba" be the right way for the phasing stop if it had been needed?
<caribou> rbasak: sure
<pitti> rbasak: yes, and "looks plausible" (I haven't worked with phasing myself yet)
<rbasak> OK, thanks :)
<caribou> rbasak: pitti: ok, just uploaded a reverted version
<rbasak> Thanks, reviewing.
<rbasak> caribou: can you reference the regression bug 1644428 in the changelog please? Otherwise we can't track it with our usual tooling.
<ubottu> bug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Triaged] https://launchpad.net/bugs/1644428
<caribou> rbasak: I thought of it, but didn't want to auto-close it by stating LP: #1644428
<caribou> rbasak: is there a prefered syntax for such things
<caribou> ?
<caribou> rbasak: & can you reject the upload so I can upload it again ?
<rbasak> caribou: auto-close would be fine, no? If that bug claims the regression, and we revert the regression, we also believe that reverting the regression fixes the bug I think.
<caribou> rbasak: true, didn't see it that way
<rbasak> caribou: also I think you should still include the changelog entry from 2:4.3.11+dfsg-0ubuntu0.14.04.2 in the changelog for 2:4.3.11+dfsg-0ubuntu0.14.04.3.
<rbasak> So 3 should be the same as 1, except for debian/changelog, which should be the same as 2 with your entry added as 3 to the top.
<caribou> oops, true :-/
<rbasak> caribou: rejected, but note that you can actually upload another with the same version into the unapproved queue - no need to wait.
<caribou> rbasak: uploaded
 * rbasak waits for it to appear
<rbasak> caribou: c&p error in debian/changelog :-/
<rbasak> (caribou had to pop out; I'll fix up)
<rbasak> pitti: as caribou had to step away and I fixed up his upload, would you mind sanity checking my fixup please? samba in the trusty queue.
<pitti> rbasak: wasn't that SRUed to all releases? or is just trusty affected by the regression?
<pitti> (waiting for it to get diffy)
<rbasak> pitti: it was only released into trusty. It's still in proposed in the other releases.
<rbasak> (never v-d in other releases)
<rbasak> Hmm. sru-review still shows me the old diff.
<rbasak> The web UI seems up to date now though.
<pitti> stgraber, balloons: FYI, bug 1644566 -- please don't backport lxd to stables before this gets fixed
<ubottu> bug 1644566 in lxd (Ubuntu) "juju bootstrap hangs forever at "Attempting to connect to 10.0.4.130:22"" [High,New] https://launchpad.net/bugs/1644566
<pitti> Laney: ^ my woes, FYI
<pitti> and yay for having a working juju again :)
<pitti> rbasak: "debdiff samba_4.3.11+dfsg-0ubuntu0.14.04.1.dsc samba_4.3.11+dfsg-0ubuntu0.14.04.3.dsc" is just d/changelog, so LGTM; accepting
<rbasak> Thanks!
<nacc> mdeslaur: oh excellent
<mdeslaur> nacc: thanks for working on that!
<Odd_Bloke> Do we have a list of "reserved" user names at all?  Things like "squid", "dnsmasq" etc.?
<cjwatson> Odd_Bloke: there's one in user-setup, although it currently includes neither of those
<cjwatson> Odd_Bloke: https://anonscm.debian.org/cgit/d-i/user-setup.git/tree/reserved-usernames
<Odd_Bloke> cjwatson: Thanks. :)
<cjwatson> Odd_Bloke: I'll just add those two upstream, they seem reasonable
<cjwatson> Odd_Bloke: hmm, doesn't squid actually use the "proxy" user though?
<Odd_Bloke> cjwatson: Oh, perhaps; I was (evidently) inventing examples.
<cjwatson> proxy is there
<cjwatson> I've added dnsmasq
<pitti> rbasak: while you are looking at SRUs, any chance you could review my x and y systemd uploads?
<rbasak> pitti: I'm not actually looking at SRUs today - my day was yesterday. I just sorted this samba one because it was a regression. I'm actually in the middle of a massive strongswan merge review. I'm not familiar with systemd so a review would involve a full context switch, sorry.
<rbasak> I can add it to my list though!
<pitti> rbasak: ack, no problem; thanks
<stgraber> pitti: well, 2.6 is aleady in xenial-backports, we don't SRU new releases though so that's not going to hit SRUs or anything
<Son_Goku> stgraber, what? when was that true?
<stgraber> Son_Goku: LXD SRUs stable bugfix releases (2.0.x) to xenial but not new feature releases (2.x), those only hit the dev release + get backported to xenial-backports
<Son_Goku> snapd and snapcraft both get SRUs as feature releases
<stgraber> I said LXD
<Son_Goku> ah
<stgraber> pitti: so hmm, why can't I disable systemd-resolved anymore? that's breaking my networking here which breaks LXD and kinda prevents me from looking into your issue.
<stgraber> pitti: http://paste.ubuntu.com/23528334/
 * stgraber removes the binary from disk for now
<pitti> stgraber: not sure, why can't you disable it? just uninstall libnss-resolve?
<stgraber> pitti: yeah, not sure what was confusing systemd... it was supposed to be disabled+masked :)
<stgraber> anyway, network works again now
<pitti> stgraber: there's nothing obviously broken in 2.6 itself -- the container starts etc, and I figure it's not lxd itself that installs the ssh key?
<stgraber> pitti: correct, it's cloud-init
<stgraber> pitti: juju sets user.user-data in the container config, then cloud-init picks that up and applies it
<stgraber> pitti: reproduced your issue, looks like something's wrong with the cloud-init seed, all the seed files are empty...
<stgraber> pitti: what storage backend are you using in your test?
<stgraber> pitti: so hmm, I'm starting to suspect mwhudson's shared library stuff, because a hand built LXD works fine, a LXD from the archive doesn't.
<stgraber> pitti: I'll do two local rebuilds, a no change one to confirm that my sbuild gives me the same result, followed by a rebuild with shlibs disabled, if that's the issue, then I'll upload that
<stgraber> and I'll write a new upstream test to validate template rendering because this should have been found by autopkgtest rather than you
 * stgraber hopes it's shlibs and not some go source in the archive, because that'd be a PITA to track down
<stgraber> pitti: reproduced with a local rebuild of the package, now trying with shlibs disabled
<stgraber> pitti: confirmed to be a shlibs regression, closing juju-core and lxd bugs, moving to a golang bug and assigning to mwhudson
<stgraber> pitti: I'll upload LXD with shlibs disabled in a minute.
<stgraber> pitti: new LXD uploaded
#ubuntu-devel 2016-11-25
<pitti> Good morning
<pitti> stgraber: yay, merci beaucoup
<Unit193> Howdy.
<cpaelzer> good morning
#ubuntu-devel 2016-11-26
<Logan> xnox: hey, when are we planning to merge OpenSSL 1.10 into Zesty?
<Logan> 1.1.0*
<lifeless> whats the right channel to ask for help etc on ubuntu-core?
<rbasak> lifeless:
<rbasak> lifeless: #snappy maybe? Though I'd guess busier on weekdays.
<lifeless> rbasak: thanks; asking there indeed :)
<LStranger> I still wonder if there is someone who could push a button to get openbox 3.6.1-3 from proposed to zesty... the bug 1336521 it fixes is pretty much annoying and autocheck failure is not relevant to openbox package anyway.
<ubottu> bug 1336521 in pcmanfm (Ubuntu) "Application Startup Notify fully ignored" [Undecided,Confirmed] https://launchpad.net/bugs/1336521
<dobey> LStranger: looks like there was a test regresion on s390x that's keeping it held up: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openbox
<tarpman> LStranger, dobey: AFAIK, not actually openbox's fault: bug 1590956
<ubottu> bug 1590956 in plasma-framework (Ubuntu) "plasma-framework 5.22.0a-0ubuntu1 fails tests on s390x" [Undecided,Confirmed] https://launchpad.net/bugs/1590956
<dobey> sure, was just pointing out why it's not gone through yet
<LStranger> dobey: yeah, tarpman already told me that, but he also told me someone can push openbox ignoring that plasma-framework problem, especially since new version of openbox does not have even sligtest dependency on plasma-framework (well, it's actually missing dependency which will be fixed later but for now that's it).
<LStranger> dobey: so I'm trying to find said someone. As for myself, I've rebuilt that package but I want my friends and anyone else to get rid of that bug too. :)
#ubuntu-devel 2016-11-27
<dobey> LStranger: well, or it needs someone to "fix" the s390x test for plasma-framework. it's not about openbox depending on plasma, but plasma depends on openbox
<dobey> LStranger: maybe talk to mirv or slangasek on monday, since it seems they've both commented on that bug.
<ginggs> Is there a problem on the armhf buildds at the moment? Can't locate Dpkg/Arch.pm in @INC (you may need to install the Dpkg::Arch module)
<ginggs> ah, seems it just needed the armhf build of perl 5.24.1~rc4-1 to become available in zety-proposed.
<LocutusOfBorg> is it normal to sync daemontools? the upstart delta seems droppable, right?
<ginggs> LocutusOfBorg: iirc, ubuntu phone still uses upstart
<mrottenkolber> Hi, is there a standard guide for keybindings? E.g. what document defines that C-s should always be "save" and C-q should be "quit" etc in Ubuntu. Is it Freedsktop related?
<Son_Goku> mrottenkolber, no
<Son_Goku> mrottenkolber: no, it's a convention that was inherited from GNOME
<mrottenkolber> there is no reference at all?
<Son_Goku> well, ehh
<mrottenkolber> e.g. a formal reference
<Son_Goku> I think it's mentioned in the GNOME and KDE HIGs
<Son_Goku> but I'm not sure about that
<mrottenkolber> hig? human interface guide?
<Son_Goku> yes
<LStranger> I think the first de-facto keybindings standard was from Microsoft, then all others taken it as a template for convenience.
<LStranger> Or may be even from Apple, cannot remember who was first with wide-spread GUI.
<LocutusOfBorg> ginggs, somebody (pitti maybe?) told that upstart delta should be dropped, sometime ago
<LocutusOfBorg> I opened a bug for this, lets see if we can reach a common decision :)
<LocutusOfBorg> we should put some statement on ubuntu-devel mail list
#ubuntu-devel 2017-11-20
<cpaelzer> nacc: you will likely not read this anytime soone so adding rbasak here as well
<cpaelzer> rbasak: I did not add skip-applied, I had no  reason and didn't use any special option actually
<cpaelzer> of the imlpicit whitelisting if importing I didn't know will take a look and add it right now via a MP
<cpaelzer> rbasak: can review that and merge if ok
<cpaelzer> nacc: rbasak: I usually use stable, but IIRC last week for "client" side things you asked me to go back to edge - so it might have been edge - let me check
<cpaelzer> rbasak: ok so I was on the egde due to the request a few days ago
<cpaelzer> rbasak: did I interpret nacc correctly that imports up until the re-import-the-world should be done back on stable?
<cpaelzer> rbasak: and if so should I kill the two packages that were imported and instead just add the three of them to the whitelist
<cpaelzer> rbasak: I was able to see that they technically import without error - so just adding them to the whitelist would import them "the same way as all others"
<cpaelzer> rbasak: https://code.launchpad.net/~paelzer/usd-importer/+git/usd-importer/+merge/333949
<pitti> Laney: good morning! do the systemd-upstream tests loop again? http://autopkgtest.ubuntu.com/running#queue-upstream-xenial-amd64 hardly makes any progress, and neither does the artful-i386 queue
<cpaelzer> rbasak: nacc: also added an MP to avoid accidential edge/git imports for your review
<fabbione> doko: btw, that valgrind bug is showing up again in Debian Experimental
<fabbione> doko: it doesn't show in debian Unstable
<fabbione> doko: not sure if you are involved with debian toolchain, but i thought you might want to know
<Laney> hey pitti
<Laney> pitti: We made it so that only 10% of the workers would take upstream tests when the distro queue was huge --- I just reverted that, let's see how we get on
 * Laney will watch a log to see if it finishes
<pitti> Laney: ah ok, that would explain it
<pitti> Laney: that's fine, I was just worried about a test tmpfail-looping and eating resources
<pitti> Laney: as the other queues are empty - would this patch also just have used 10% if the other 90% are idle?
<mwhudson> why would this be considered a regression? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/armhf/g/golang-dbus/20171120_075357_70f15@/log.gz
<mwhudson> i'm a bit confused as to why it thinks there are no tests though, they ran (via autodep8) on other arches
<pitti> missing autodep on the runners?
<Laney> pitti: it removed the context from 90% of the workers
<Laney> fairly brutal
<pitti> Laney: ah, I see
<mwhudson> pitti: oh so autodep8 is not necessarily installed on all runners?
<Laney> mwhudson: looking, one second
<pitti> mwhudson: right; it needs to be part of the runner setup charm or cloud-init userdata
<mwhudson> hmm it's not listed in testbed-packages in the artifacts, but it's not listed on the arch in ran in either...
<mwhudson> i guess that's captured to early or something?
<pitti> autodep8 isn't part of the testbed, it needs to be installed on the "outside" runner (side by side with autopkgtest itself)
<mwhudson> ah
<mwhudson> that makes sense when i actually think about it :)
<doko> oSoMoN: libreooffice autopkg test failure on i386, segfaulting
<oSoMoN> o
<oSoMoN> doko, looking
<Laney> mwhudson: fixed!
<Laney> thanks for reporting
<Laney> I needed to upgrade autodep8 :(
<k1l_> Hi, i got a question about the procedure of fixing a bug according to SRU: see bug https://bugs.launchpad.net/ubuntu/+source/corebird/+bug/1730927 The maintainer says he cant get a SRU since the final repos have different majorversions than bionic has got.
<ubottu> Launchpad bug 1730927 in corebird (Ubuntu) "Support the new 280 character limit." [Undecided,Fix released]
<k1l_> but aiui this would make most packages unpatchable in final repos since the unstable version got a different major release most of the time?
<rbasak> k1l_: I've tried to answer in https://bugs.launchpad.net/ubuntu/+source/corebird/+bug/1730927/comments/7 - hope that makes it clear.
<ubottu> Launchpad bug 1730927 in corebird (Ubuntu) "Support the new 280 character limit." [Undecided,Fix released]
<rbasak> k1l_: sorry, I failed to say that I was going to answer _in_ the bug :)
<k1l_> rbasak: alright. this sounds like i interpreted it correctly and it could be patched in the stable repos.
<rbasak> k1l_: agreed. Thank you for chasing this up!
<rbasak> cpaelzer: actually following discussions with nacc late last week we concluded that the importer should always be run from beta (which we'll create, but initially it'd start off the same as edge)
<rbasak> cpaelzer: if you didn't run --skip-applied then something went wrong with your import I think.
<rbasak> The applied branches didn't get imported, and we don't know why.
<rbasak> nacc tried it and he did get the applied branches updated, which is why he thought you'd probably run it with --skip-applied.
<rbasak> So if you didn't, I'm not sure we know what happened.
<cpaelzer> rbasak: hmm :-/
<cpaelzer> rbasak: ok so lets summarize the different things in flight here
<cpaelzer> 1. my import didn't work as it should, should I remove them for now?
<cpaelzer> I didn't realize the applied branches were missing, but if so what is uploaded atm is incomplete
<cpaelzer> too bad, as I imported from edge and as I read that would have been correct after all
<cpaelzer> my console log is gone so I can't check why it worked for me
<cpaelzer> in the past being on xenial was a difference to you and nacc sometimes
<rbasak> I don't think there's any need to remove them. It's better than nothing, and we haven't declared "hash stability" yet. I'm pretty sure didrocks would prefer to have them than nothing at all.
<cpaelzer> I'm ok with that
<rbasak> The rest is accurate. I think Xenial shouldn't make a difference now that the snap embeds the necessary dependencies (and versions).
<cpaelzer> so I could kick of the gtk+3.0 import as well then rbasak?
<cpaelzer> that was taking too long last week
<cpaelzer> or would it be enough to accept the MP which whitelists it
<rbasak> So you stopped it?
<didrocks> yes, I don't really care about git history and hashes for now, the community is just going to cp the content (just having access to latest easily for them will help once we get hash stability and can branch)
<cpaelzer> I let it run, but it welcomed me with a timeout this morning
<rbasak> I mean: that's fine, just want to understand current status.
<rbasak> OK
<cpaelzer> rbasak: actually I ahve the local tree
<cpaelzer> rbasak: maybe there is some --re-import flag or so to not do it all over again
<rbasak> cpaelzer: I wonder if you could try again locally and tee the output to a log?
<cpaelzer> to just check on latest status and push then
<rbasak> You can use --no-fetch I think.
<rbasak> But that might imply --no-push. I don't recall.
<cpaelzer> it does
 * rbasak doesn't know if there's a --no-no-push.
<cpaelzer> hehe
<cpaelzer> let me check on this gtk+3.0 first
<rbasak> cpaelzer: if possible, I'd like you to try again to see if you can reproduce the previous problem but with log output (-v).
<cpaelzer> this issue was on gnome-shell
<cpaelzer> so I'd run that again in another console
<rbasak> cpaelzer: if that doesn't work or is difficult, then we can just add to the whitelist. Either way we can certainly add to the whitelist.
<cpaelzer> but with verbose and keeping the logs
<cpaelzer> rbasak: the MP for the whitelist is up
<rbasak> Right now, after adding to the whitelist, the central importer will only run after it sees an upload. Someone still has to manually do stuff (though I can do it from the bastion).
<cpaelzer> rbasak: then we will do this
<cpaelzer> 1. you can review and merge the MP to whitelist
<cpaelzer> 2. I will create a local import of gnome-shell with logs to check what might have happened
<cpaelzer> 3. I check if I can re-use all the work done on gtk+3.0 by uploading it
<cpaelzer> well for 3. not just push but some sort of git ubuntu import --flags
<rbasak> I can do that, but won't updating the whitelist potentially clash with our examination in case there is an upload for that package?
<cpaelzer> rbasak: ok hold back the merge until I have a log provided
<cpaelzer> rbasak: but even so a --no-fetch would then still be the same
<cpaelzer> gnome shell import with --no-push is running to create logs
<cpaelzer> now looking at gtk+3.0
<cpaelzer> even with "--no-clean --no-push" it starts over again, but just pushing the repo is too unclean
<cpaelzer> I start it again fresh
<cpaelzer> we can afford those few hours
<cpaelzer> and I'll collect logs on that as well to be sure
<cpaelzer> my problem with the last gtk+3.0 import was that a screen lock implies I need to unlock gpg again
<cpaelzer> and since it was still running when I went EOD that was the case
<cpaelzer> due to that the timeout eventually
<cpaelzer> both now running fine and logging away rbasak
<cpaelzer> I'll ping with logs once they completed
<rbasak> Thanks!
<LocutusOfBorg> pitti, how do you feel about rfkill sync? the delta seems mostly upstart-only, but I prefer to not touch it
<pitti> LocutusOfBorg: looking
<pitti> LocutusOfBorg: confirmed, looks good; so you want me to sync? doing
<LocutusOfBorg> <3
<cpaelzer> rbasak: gnome-shell is complete - what would I want to look for?
<cpaelzer> branches with --applied?
<cpaelzer> http://paste.ubuntu.com/26004584/
<cpaelzer> rbasak: LGTM in the log
<cpaelzer> it has applies and unapplied branches
<cpaelzer> even the remote actually has them already from last week
<cpaelzer> rbasak: but then I didn't follow your discussion back then, what was missing?
<rbasak> cpaelzer: is importer/applied/ubuntu/devel recent?
<rbasak> cpaelzer: it appeared that none of the applied branches had been updated
<rbasak> (in the other repo the other day)
<cpaelzer> hmm, no it seems old
<rbasak> cpaelzer: so if the applied branches are current, then it's not the same problem.
<cpaelzer> 2.28.1~git20091020-1 of 2009
<rbasak> Interesting. So you can reproduce.
<cpaelzer> yeah by doing "git ubuntu import --verbose --directory /tmp/import/gnome-shell --no-push gnome-shell"
<rbasak> Does the hash match the output of line 4773 in your pastebin?
<cpaelzer> maybe that fetched the state as-is ?
<cpaelzer> I can re-run with no-fetch if needed
<cpaelzer> the hash matches
<cpaelzer> rbasak: can you see from the log if it just fetched what it imported last week?
<rbasak> OK: but the hash is old?
<cpaelzer> yes
<cpaelzer> the hash matches and it is old
<cpaelzer> it seems all applied are the same
<cpaelzer> look at this
<cpaelzer> http://paste.ubuntu.com/26004608/
<cpaelzer> it seems all applied are "on" this hash
<rbasak> Let me see if I can reproduce here
<rbasak> Can you confirm your snap version please?
<cpaelzer> I also started one with --no-fetch as well to check on that
<cpaelzer> was 335 this morning
<cpaelzer> just a sec
<cpaelzer> yes still on 335
<rbasak> OK
<cpaelzer> rbasak: you might need --no-fetch as well
<cpaelzer> when you try to reproduce
<rbasak> But you didn't in that pastebin, right? I don't understand why you think I may need it.
<cpaelzer> I didn't use in the pastebin and got to the same result
<cpaelzer> as last week
<cpaelzer> but maybe I "now" got to the same result as it just fetched many things
<cpaelzer> so as lon as gnome-shell is in usdi as a repo anything without --no-fetch might not be a valid reproduce of the actual issue
<rbasak> I see
<doko> oSoMoN: I see that this failure gets ignored by other packages: gcc-5 libreoffice/1:5.4.1-0ubuntu3
<ginggs> doko: hint just needs updating? https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/2652
<rbasak> cpaelzer: reproduced
<doko> ginggs: -> #ubuntu-release
<cpaelzer> rbasak: ok, glad to hear it is not me
<cpaelzer> OTOH it means "new bug"
<cpaelzer> :-/
<cpaelzer> didrocks: sorry for the delays, but well things are in development - better to catch those now
<didrocks> cpaelzer: no worry! better to catch that before we go all in ;)
<didrocks> and thanks for keeping me posted!
<cpaelzer> yw
<doko> oSoMoN: is the i386 LO autopj
<doko> oSoMoN: is the i386 LO autopkg test failure addressed with your recent upload?
<oSoMoN> doko, that upload is to make LO icu60-friendly, it's not related to i386 autopkgtests failures
<oSoMoN> doko, the i386 failures look related to bug #1699772
<ubottu> bug 1699772 in linux (Ubuntu) "linux-image-4.13.0-12-generic, linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic | Regression: many user-space apps crashing" [Critical,Confirmed] https://launchpad.net/bugs/1699772
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<doko> seb128, didrocks, Laney: there are a lot of autopkg test failures for gvfs triggered by various packages. afaics none yet blocking
<seb128> doko, those seem to be "Error initializing camera" errors from gphoto so probably a problem in that stack
<rbasak> oSoMoN: BTW, it's odd that https://launchpad.net/~osomon/+uploaded-packages lists only a tiny subset of your actual sponsored uploads.
<rbasak> oSoMoN: is it that your changelog email address isn't registered in Launchpad perhaps?
<rbasak> See http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*tilloy*&sponsoree_search=name for example.
<oSoMoN> IÂ use my @canonical.com e-mail address
<oSoMoN> and it's registered in LP
 * rbasak doesn't know then
<oSoMoN> it's weird indeed
<seb128> rbasak, could it be that this package only list the most recent upload of a package (by serie)?
<seb128> like if you upload 15 times libreoffice to xenial you only get the most recent one
<rbasak> I thought it listed all uploads.
<oSoMoN> that would make sense, as there's one chromium-browser entry for artful, and one for bionic
<rbasak> But also, oSoMoN has uploaded to previous series.
<rbasak> Oh
<seb128> it seems to limit to 1
<seb128> like I looked for Till or robert-ancell
<seb128> who often upload the same packages
<rbasak> I suppose that could explain it then!
<seb128> and they also only have 1 instance of package/serie
<seb128> but that's just guessing
 * rbasak would prefer it not to limit for DMB application review purposes
<seb128> could be a question for #launchpad
<Laney> I think it's more that many of the uploads are copies and those aren't recorded as sponsorships (e.g. https://launchpad.net/ubuntu/+source/chromium-browser/62.0.3202.89-0ubuntu0.14.04.1213)
<seb128> Laney, well, if you look at https://launchpad.net/~robert-ancell/+uploaded-packages ... I'm pretty sure robert did more gnome-software uploads than that
<seb128> there is 1 for artful on that page
<Laney> we're not talking about the sponsorship miner?
<seb128> and he doesn't do copies afaik
<Laney> let's see one that's not listed?
<seb128> Laney, dunno, I was replying to "it's odd that https://launchpad.net/~osomon/+uploaded-packages lists only a tiny subset of your actual sponsored uploads."
<seb128> Laney, for robert you can take https://launchpad.net/ubuntu/+source/gnome-software/3.25.91-1ubuntu3 for example
<Laney> so it looks like it shows the currently published version
<seb128> ah, could well be
<seb128> unsure if that's by design or buggy though
<Laney> yeah don't remember
<Laney> I used to use the miner back in DMB days
<Laney> so might not have noticed
<clivejo> is gunzip broken in bionic?
<dmj_s76> sforshee: This bug just got brought to my attention: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1089195
<ubottu> Launchpad bug 1089195 in update-manager (Ubuntu) "linux-headers will eat your inodes on LTS." [Undecided,Confirmed]
<sarnold> clivejo: it might be, I saw someone else complain about it last week
<sarnold> clivejo: please file bug :)
<sarnold> dmj_s76: wow, what a dumping ground of a bug. it's filed against update-manager but more than one person in ther comments that it happened on their server systems with unattended-upgrades installed, etc
<sforshee> dmj_s76: that's the same for all kernel packages, 'apt-get autoremove' does remove them though
<dmj_s76> sforshee: Yeah, this was commented to me as well.  It's described as "Not that difficult to recover from once you know what's going on and how to fix it, but really annoying the first time."
<dmj_s76> Essentially, you get a broken system if you set unattended upgrades and expect that to work unattended.
<sforshee> dmj_s76: it's been discussed before, though I wasn't much involved. There are definitely some issues with automatically removing kernel packages, not sure if they were insurmountable
<doko> mdeslaur, cpaelzer: your postgresql-9.6 upload to bionic went wrong
<slangasek> rbasak, nacc: so the lp:ubuntu remapping, did that happen?  and does the branch that was at bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/shim-signed/ still exist somewhere?  My understanding was that only the mapping was going to be changed, but I don't seem to find that branch now
<rbasak> slangasek: we haven't actually made any mapping changes yet
<slangasek> hmm ok
<rbasak> AIUI the bzr mappings are independent
<slangasek> rbasak: then I'll chase up the question of the MP I thought I saw and can no longer find with cyphermox instead, thanks :)
<rbasak> And separately there's the default VCS of the ubuntu project
<slangasek> right
#ubuntu-devel 2017-11-21
<sarnold> do we archive ports anywhere when they're retires, similar to old-releases.ubuntu.com?
<sarnold> someone's trying to build a PS3 cluster and I think would be happy to find a bunch of old lucid or similar ports stuff
<hloeung> sarnold: doesn't old-releases cover ports as well?
<hloeung> sarnold: e.g. http://old-releases.ubuntu.com/ubuntu/dists/lucid/main/ has a much of arches
<hloeung> sarnold: http://old-releases.ubuntu.com/ubuntu/pool/main/l/linux/ also has packages for armel etc.
<xnox> sarnold, PS3 is that powerpc? or the ppc64 (big endian) which we were working on, but never shipped due to contract-deal failure?
<cpaelzer> thanks doko for the ping, taking a look
<cpaelzer> actually in bionnic it should become pg-10 anyway, but that needs a few more steps to complete
<cpaelzer> -n
<cpaelzer> oh I see it actually is a confluct with pg10 which is what we want to reach
<cpaelzer> I didn't want to look at it yet, but it seems so many things already dep on pg-10 to complete
<cpaelzer> I need to look at it now ... :-/
<cjwatson> xnox: PS3 was powerpc, 32-bit big-endian
<cjwatson> xnox: shipped in feisty and gutsy
<cjwatson> (IIRC)
<xnox> cpaelzer, i have been working on postgresql-10 transition.
<xnox> cpaelzer, it's currently a valid candidate
<xnox> cpaelzer, and there should not be any 9.6 uploads into bionic.
<cpaelzer> xnox: yeah I've seen it
<cpaelzer> I saw your ping yesterday and checked excuses this morning to find nothing left blocking
<cpaelzer> I'm working on a related issue on postgresql-filedump but that is not a blocker
<cpaelzer> xnox: also ack that there should be no (new) 9.6 uploads at all
<cpaelzer> xnox: that is what I replied to doko this morning
<cpaelzer> I think that was pushed to B as well by accident on the last MRE
<cpaelzer> filedump is likely fixed with a rebuild (testing that atm) see bug 1733525
<ubottu> bug 1733525 in postgresql-filedump (Ubuntu) "Test Regression on ppc64 in version 10.0-1" [Undecided,New] https://launchpad.net/bugs/1733525
<cpaelzer> xnox: I've seen bug 1733341 from you - thanks
<ubottu> bug 1733341 in postgresql-mysql-fdw (Ubuntu) "fails to work with postgresql 10.1" [Undecided,Confirmed] https://launchpad.net/bugs/1733341
<cpaelzer> I subscribed myself on GH as well
<cpaelzer> xnox: I started bug 1733527 to track what is left to remove src:postgresql-9.6 - but I thought pg-10 should fully migrate before I ask about that
<ubottu> bug 1733527 in postgresql-9.6 (Ubuntu) "Please remove postgresql-9.6 from bionic" [Undecided,New] https://launchpad.net/bugs/1733527
<cpaelzer> that is where I try to track remaining misses for the transition
<cpaelzer> xnox: thanks for all your help on this transition
<cpaelzer> xnox: I just proved that the rebuild would fix postgresql-filedump - that would be a no change upload of postgresql-filedump 10.0-1
<cpaelzer> xnox: I don't want to mess with the migration, I think it would not affect it but an ack by you that I can upload postgresql-filebug would be nice
<xnox> cpaelzer, what is it? a new package?
<xnox> bah i misspelled
<xnox> cpaelzer, it should be fine, it's leaf.
<cpaelzer> normal sync from debian, just when it synced the timing was bad and it has no rdeps
<xnox> cpaelzer, we turned autosync off.
<xnox> cpaelzer, so if it's autosync stuff, just leave it for now. we will be turning autosync back on, after the migration of doom.
<cpaelzer> xnox: there is no newer version in Debian it would sync
<xnox> upload things to debian; or upload things you do need fixes for now -> like e.g. i'm uploading systemd again, to fix more test suite failures; and stop using nested kvm....
<xnox> cpaelzer, ah.
<cpaelzer> xnox: it even built correctly, but then failed on the autopkgtest
<cpaelzer> so it would not realize it had to sync
<cpaelzer> therefor I want to upload it as no change rebuild
<xnox> cpaelzer, yeap, makes sense to do that! even now!
<cpaelzer> xnox: done
<cpaelzer> xnox: I only see valid candidates on pg-10 - what is the next step to do there so that it actually moves?
<xnox> it's entagled with 100s of packages at the moment... icu... qt... and a bunch of other transitions
<xnox> libreoffice....
<xnox> i think we are waiting for libreoffice to build on armhf (that takes like 2 days)
<xnox> and systemd which i am about to upload.
<Laney> it's more like 7 hours nowadays
<xnox> apart from an 19h hang last night and restart from scratch? =)
<xnox> i do wonder, if we should be cross-compiling libreoffice for armhf
<Laney> yes, apart from that
<cpaelzer> icu LGTM this morning, but thanks for the overview
<doko> ruby-em-http-request tests are broken, even in the build ...
<xnox> cpaelzer, there is mariadb upload 8 days old with an s390x regression
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mariadb-10.1
<xnox> anybody looking into that?
<xnox> it failed a test
<cpaelzer> xnox: IIRC rbasak had such an error on his radar
<cpaelzer> I checked a few details with him a while ago, need to look if those are the same
<cpaelzer> xnox: yeah I remember this pcre thing to be part of the context what I disussed with rbasak
<cpaelzer> bug 1723947
<ubottu> bug 1723947 in mariadb-10.1 (Ubuntu) "Current upload for 10.1.28-1 fails dep8 unitest on s390x" [Undecided,New] https://launchpad.net/bugs/1723947
<cpaelzer> I was lost inside pcre but had a proposal on skipping this particular test (but keeping all others) for now
<cpaelzer> and was waiting on feedback on that
<cpaelzer> rbasak: maybe you could look at that change today?
<rbasak> cpaelzer: I agree to force-badtest it. But that needs a release team member to actually do it.
<cpaelzer> rbasak: what did you tihnk of my suggest to only skip thta particular test
<cpaelzer> rbasak: would loose less test coverage?
<doko> rbasak, cpaelzer: is nacc online? or could you look at the kopanocore autopkg test failure?
<doko> the autopkg tests don't fail in debian apparently
<rbasak> cpaelzer: oh, sorry. Yes, skipping that particular test would be fine. I'd forgotten about that part.
<cpaelzer> doko: he won't be available for some time
<cpaelzer> I'm giving up to get to do what I planned for today and will take a look
<cpaelzer> :-)
<pitti> cyphermox, xnox: the various network-manager/s390x failures in excuses (http://autopkgtest.ubuntu.com/packages/n/network-manager/bionic/s390x) seem to be due to the s390x testbed changes? any idea what that is?
<cyphermox> pitti: now has isolation, I think?
<xnox> pitti, used to be lxc, now openstack nova kvm.
<cyphermox> right, that's it
<xnox> and somehow testing wpa & urfkill makes little sense on big iron
<cyphermox> there, cfg80211 isn't being bult in the kernel (for one thing), probably the same story for rfkill; someone should revise the skipping those tests on s390x
<cyphermox> +1
<xnox> cyphermox, previously it skipped
<cyphermox> yes, because of isolation.
<xnox> wpa-dhclient         SKIP Test requires machine-level isolation but testbed does not provide that
<xnox> nm                   SKIP Test requires machine-level isolation but testbed does not provide that
<xnox> killswitches-no-urfkill SKIP Test requires machine-level isolation but testbed does not provide that
<xnox> urfkill-integration  SKIP Test requires machine-level isolation but testbed does not provide that
<xnox> autopkgtest [07:51:18]: @@@@@@@@@@@@@@@@@@@@ summary
<xnox> wpa-dhclient         SKIP Test requires machine-level isolation but testbed does not provide that
<xnox> nm                   SKIP Test requires machine-level isolation but testbed does not provide that
<xnox> killswitches-no-urfkill SKIP Test requires machine-level isolation but testbed does not provide that
<xnox> urfkill-integration  SKIP Test requires machine-level isolation but testbed does not provide that
<xnox> right.
<cyphermox> the test defines it needs it.
<cyphermox> now we need to skip some other way, because cfg80211 and rfkill don't make all that much sense on s390x.
<xnox> but also a bug in britney if this is considered a "regression"
<cyphermox> arguably, yeah
<cyphermox> if it was skipped before and now fails it probably should be an always-failed, but it's not wrong to mark it a regression either, we do have a change in behavior and it's good to revise the tests and see if we should keep skipping or fix something else
<xnox> pitti, urgh, one cannot specify Architecture: !s390x in debian/tests/control =(
<pitti> xnox: right, you have to encode that in the test itself
<pitti> xnox: I suppose it's just the module build not being supported on s390x?
<cpaelzer> I know to pull something in main I'd add a dependency from a pkg in main
<cpaelzer> but if I want to add a binary pkg to a src that is in main
<cpaelzer> can I just add (and not add any stronger dep than suggest) and it will be in universe?
<cpaelzer> or would a bin from src in main appear "in main" by default?
<cpaelzer> rbasak: ^^ on my question of before
<pitti> cpaelzer: it will land in binNEW, and it can be chosen there
<pitti> cpaelzer: AFAIK Launchpad will default to teh same component as the source (i. e. main)
<cpaelzer> oh chosen, interesting
<pitti> but it will quickly appear on http://people.canonical.com/~ubuntu-archive/component-mismatches.html and then be demoted
<pitti> so it doesn't matter that much if it's NEWed wrongly
<cpaelzer> ok, that means on the transition of the NEW queue I can coordinate with someone
<cpaelzer> thanks pitti
<xnox> cpaelzer, there is no coordination required on your part, it should drop down to universe via regular archive maintainance.
<cpaelzer> great, thanks
<cpaelzer> and in case it doesn't I could still reach out to someone
<cpaelzer> thank you both
<sarnold> hloeung,xnox: I thought old-releases would have worked for the reporter but he said apt kept reporting "no packages available" or something similar.. I got to wondering if maybe ppc details I don't know were involved, I never figured out the BE vs LE vs which PPC chips were 64bit vs 32bit .. what little I did know from my g3 ibook days is long since atrophed, hehe
<xnox> it should just work(tm)
<sarnold> :D
<xnox> maybe installer is not run at low priority to specify old-releases?
<xnox> and security pocket to old releases too?
<xnox> old-releases is not excatly easy to use.....
<sarnold> *sigh* the reporter's offline..
<sarnold> indeed
<sarnold> but the guy had 300 PS3 slim units or something silly he wanted to cluster :)
<juliank> rbalint: I feel like we should just continue to use SIGUSR1 for old unattended-upgrade versions, rather than backporting the unattended-upgrade SIGTERM change. Since we have to manually forward signals in apt-daily.service anyway, this way we don't need any coordinates SRUs at least (and it should work in Debian too).
<sarnold> so I figured he'd be motivated to figure it out
<juliank> It should not be too hard to just send SIGUSR1 for u-u before artful :)
 * juliank just needs to add another varaible to the cron job
<juliank> Optimally, u-u would accept both SIGUSR1 and SIGTERM for graceful stopping
<juliank> cjwatson: The apt PPA daily builds fail to upload with "[lplibrarian-public-upload.internal:10004]: [Errno 111] Connection refused" and "[lplibrarian-public-upload.internal:10004]: [Errno 113] No route to host" - what's going on? I think I had 4 emails now in a few seconds
<bmw> rbasak: I wanted to check in with you again about Certbot packages
<bmw> I'm curious what I can do to help finally finish out the Certbot SRU and I wanted to ask you again about potential problems for future SRUs caused by us splitting our JOSE library into a separate package
<bmw> for the latter, most distros asked us to just split the package rather than continuing to vendorize it, but I wanted to make sure you're OK with this plan before I pull the trigger and do a release like thsi
<slangasek> infinity, stgraber, mdeslaur, kees: TB meeting in 15
<mdeslaur> ack
<stgraber> will be there
<cjwatson> juliank: one of our frontends was rebooted and it looks like the admin who did it wasn't careful to take it out of DNS first
<cjwatson> I've left them a note
<juliank> cjwatson: thx :)
<smoser> i have a deb that i want to install (locally built).
<smoser> dpkg -i foo.deb
<smoser> can fail because of m issing packages.
<smoser> apt-get -f install will normally "fix" that.
<smoser> except when foo.deb is older than the version in the archive. apt will choose to upgrade it to the archive version. which isnot what i want.
<smoser> i tried holding 'foo' before 'apt-get -f install' and that actually works
<smoser> but only when foo is older than the version available in the archive.
<smoser> if its *newer*, then apt complains about pkgProblemResolver
<smoser> like https://jenkins.ubuntu.com/server/job/cloud-init-ci/536/console
<smoser> i'd like to avoid 'mk-build-deps' and local package repos if i can.
<smoser> any thoughts ?
<sarnold> smoser: can you install the dependencies first?
<smoser> well, i could, but then i have to know them.
<sarnold> ah
<smoser> i can query them , but you get stuff like
<smoser> # dpkg-query --show '--showformat=${Depends}' cloud-init
<smoser> init-system-helpers (>= 1.18~), python3-configobj, python3-jinja2, python3-jsonpatch, python3-jsonschema, python3-oauthlib, python3-requests, python3-six, python3-yaml, python3:any (>= 3.3.2-2~)
<smoser> which is i guess not too bad here.
<cjwatson> smoser: apt install ./path.to.deb
<smoser> but when there are '|' and such.
<smoser> \o/
<sarnold> wow apt can do that?? neat
<cjwatson> nowadays yes
<smoser> oh. apt.
<cjwatson> possibly apt-get too, I forget
<smoser> apt-get does seem to work on 16.04, and that is old enough for me.
<smoser> thanks cjwatson !
<cjwatson> (apt will work on 16.04 too FWIW)
<cjwatson> np, it definitely made my life easier when that happened
<smoser> i'd just generally stay away from 'apt' if i can.  due to warnings i've seen it spew out when output is not a terminal.
<smoser> that say "dont use this from scripts"  or somethign
<juliank> yeah, it's interface is not 100% stable like apt-get
<juliank> but otherwise it's mostly nicer
<mwhudson> what happened here? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/d/docker.io/20171121_211648_60458@/log.gz some infrastructure failure?
<mwhudson> also are we not running arm64 autopkgtests for xenial yet?
<mwhudson> i guess we don't have a baseline there...
#ubuntu-devel 2017-11-22
<slangasek> mwhudson: we have a baseline now on xenial/arm64, but haven't turned on ongoing tests (and britney checking of results) until the backlog has cleared for all releases
<slangasek> mwhudson: (which is any day now; only 459 arm64 tests left in the queue)
<slangasek> mwhudson: dpkg database locked though, that's an impressive testbed failure
<slangasek> could be a buggy inclusion/triggering of unattended-upgrades in the base image?
<mwhudson> slangasek: ah ok
<slangasek> mwhudson: fwiw http://autopkgtest.ubuntu.com/statistics for the overview of what has been run
<mwhudson> slangasek: if it ever loads
<doko> only 386 left. but pretty please don't turn that on before we finish our current transition
<doko> http://autopkgtest.ubuntu.com/running might load faster
<Unit193> Well I'll be, https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=34da04daec82077571558ac3fe1ec0c1203a01ad
<tjaalton> Unit193: huh?
<fnordahl> xnox: hello
<xnox> fnordahl, hi!
<fnordahl> xnox: with regards to your previous uplods to partman-partitioning would you consider sponsoring my patch in bug 1733276
<ubottu> bug 1733276 in debian-installer (Ubuntu) "Cannot resize partitions on NVME devices due to bad device name parsing" [Undecided,Confirmed] https://launchpad.net/bugs/1733276
<xnox> fnordahl, yes
<fnordahl> xnox: thank you Sir!
<doko> jamespage: designate's b-d python-sphinxcontrib-httpdomain doesn't exist anymore
<doko> same for mistral
<doko> and sahara. it's now python-sphinxcontrib.httpdomain
<thresh> hello.  I think perl is somehow broken with the 5.24 to 5.26 transition.  I've noticed that on libcache-memcached-fast-perl package;  bug filled at launchpad: https://bugs.launchpad.net/ubuntu/+source/libcache-memcached-fast-perl/+bug/1733655
<ubottu> Launchpad bug 1733655 in libcache-memcached-fast-perl (Ubuntu) "does not work / does not pass own tests on Artful 17.10" [Undecided,New]
<thresh> There seems to be an upstream bug as well, which came to the same conclusion as I did: https://github.com/JRaspass/Cache-Memcached-Fast/issues/12
<thresh> Now I wonder what can I do to make perl maintainers aware of such a problem?
<smoser> is there a way for a autopackage test to copy files into a place that they'll get picked up by artifacts ?
<smoser> specifically i'm interested in autopkgtest.ubuntu.com
<smoser>  http://autopkgtest.ubuntu.com/packages/o/open-iscsi/bionic/amd64
<Laney> smoser: put it in $AUTOPKGTEST_ARTIFACTS
<Laney> https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
<Laney> e.g. pristine-tar does this
<smoser> Laney: thanks.
<bdmurray> blackboxsw: Bug 1733653's description doesn't match the version in the SRU queues - is something wrong?
<ubottu> bug 1733653 in cloud-init (Ubuntu Artful) "sru cloud-init (17.1-27-geb292c18) update to (17.1-42-gbbe91cdc)" [Medium,In progress] https://launchpad.net/bugs/1733653
<bdmurray> Also the changelog in the bug description has stuff not in the upload.
<Unit193> tjaalton: Had/have an issue with login loops, making it even worse was switching to a TTY just flipped me back.  Happened to see that, good to know it's fixed upstream.
<tjaalton> Unit193: ok, can be sru'd too
<smoser> bdmurray: looking
<smoser> bdmurray: i'll update the subject of the bug. the next commit (-42) wasnt in bionic, so we uploaded -41. it only affected non-ubuntu.
<smoser> fixed.
<bdmurray> smoser: The Changelog in the bug still contains unfixed things afaict
<smoser> fixed.
<smoser> unfixed how?
<smoser> bdmurray: ?
<bdmurray> smoser: The parts at the bottom of the description like "- sysconfig: Correctly render dns and dns search info.
<bdmurray>       [Ryan McCabe] (LP: #1705804)"
<ubottu> Launchpad bug 1705804 in cloud-init "sysconfig renderer should render DNSx= and GATEWAY= lines" [Medium,Fix committed] https://launchpad.net/bugs/1705804
<bdmurray> smoser: that's not in the changelog uploaded to the SRU queues
<bdmurray> I guess that's the only one though.
<smoser> ok. yeah, that just shouldnt be there. sorry. i'll fix.
<bdmurray> No problem, I just want to avoid confusion / misleading people.
<smoser> is there a way to make systemd not print tis stuipd sliding star ?
<smoser> but smething more readable ?
<smoser> [**    ] A start job is running for dev-diskâ¦-UEFaI.device (1min 2s / 1min 31s)
<Winwin> https://cryptosrevolution.wixsite.com/beta/
<sdeziel> are the patch pilot still a thing? https://calendar.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&gsessionid=OK shows nothing since March
<sdeziel> and I've been waiting for the past few weeks for a little debdiff :)
<mdeslaur> xnox: ^
<xnox> sdeziel, mdeslaur: a calendar has moved, but i think nobody got scheduled for november =(
<sdeziel> xnox: I got the calendar link from https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Schedule
<xnox> sdeziel, yes, that link is out of date.
<mwhudson> i certanly haven't been nagged about patch pilot duties in a long time :/
<sdeziel> don't tempt me ;)
<Unit193> mwhudson: I could nag you if you wished.
<mwhudson> i am sufficiently nagged at the moment but maybe later
<Unit193> :'(
#ubuntu-devel 2017-11-23
<ginggs> tseliot: any ideas why nvidia-cuda-toolkit is not installable? see https://launchpad.net/ubuntu/+source/eztrace-contrib/1.1-7-1 https://launchpad.net/ubuntu/+source/hwloc-contrib/1.11.8-1
 * tseliot lookinh
<tseliot> *looking
<tseliot> ginggs: something probably broke in bionic. I'm creating a chroot to check that out
<ginggs> tseliot: thanks
<tseliot> ginggs: apt-get build-dep eztrace works fine in the chroot
<tseliot> maybe the archive was temporarily broken?
<ginggs> tseliot: i gave them back an hour ago, and they've been retried a few times in the last 3 weeks
<tseliot> not a good sign...
<rbalint> juliank: apt-daily.service does not have to forward signals to u-u per design, u-u-s.service signals u-u, apt-daily.service just must not let all the child processes to be killed
<juliank> rbalint: But I want it to. Everything else is just a bad user experience.
<juliank> rbalint: Not only that, it also breaks the locking between the two apt-daily services
<juliank> heck, it might even allow you to start apt-daily while u-u is still running from a previous apt-daily-upgrade job, considering that systemd considers apt-daily-upgrade to be inactive at that point.
<rbalint> juliank: i'm speeding up the SRU for u-u to accept SIGTERM if you would like to send the signal
<rbalint> juliank: would that work for you?
<juliank> rbalint: I'd mostly like to avoid the dependencies between the SRUs. zesty is in sync with stretch, it would be nice to keep it that way (and I want to make it work in stretch too, so I need the SIGUSR1 dance for that)
<rbalint> juliank: i'm not sure what problem would be caused by starting apt-daily while apt-daily-upgrade is running
<juliank> I'm not sure either, but they were not designed to be run together.
<juliank> There are probably some race conditions in there.
<rbalint> juliank: i can do a stretch update, too, to u-u if that helps
<juliank> I don't think the Debian RT would accept that.
<rbalint> juliank: as i see apt-daily does nothing that breaks apt-daily-upgrade thus we may be trying to fix something that nevar causes actual problems
<juliank> It definitely replaces your Packages files, so depending on how far u-u is, it might get problems parsing stuff.
<juliank> Or you might just end up with lock races between the two
<juliank> The locking situation is a bit unclear.
<rbalint> juliank: as i saw the lock is held in u-u thus apt-daily may just fail, but have to check to be sure
<juliank> There are 4 locks involved, and one lock is repeatedly released.
<juliank> The apt code is almost 2 decades old and nobody has a clear picture of which locks are hold when
<rbalint> juliank: ok.
<rbalint> juliank: u-u handles failure gracefully in artful and up so with the backport i don't think we need signaling from apt's scripts
<rbalint> juliank: apt-daily failing is also ok IMO
<juliank> I guess even if I signal u-u from apt's script, it's not going to be a regression, it's just setup work.
<juliank> So we would not _really_ need dependencies between those two
<juliank> It's just that if you upgrade from e.g. 1.5 to 1.5.2 that nothing changes
<juliank> but as soon as you upgrade u-u as well, everything works as expected.
<rbalint> juliank: sending a signal which kills u-u instead of triggering the graceful termination would cause serious regressions
<juliank> Compared to just terminating the entire cgroup?
<juliank> Currently we terminate the script, u-u, and all children
<juliank> the current "broken" fix is only in -proposed.
<rbalint> juliank: no, comparing to exiting in apt's scripts
<juliank> Right, but that's irrelevant seeing as that is only in proposed and has not made it to updates.
<rbalint> juliank: can i help moving it to release?
<juliank> Well, sure if you mark the bug as verified-done, it's basically releasable. Well, xenial needs one more test for bug 1613184 as the specified one does not apply.
<ubottu> bug 1613184 in apt (Ubuntu Zesty) "method mirror broken at 1.3" [Medium,Fix committed] https://launchpad.net/bugs/1613184
<juliank> But I don't really feel good about it
<rbalint> juliank: ok, let me take a second look and mark it as such
<juliank> You also have to change the testing scenario for the u-u bug
<juliank> because it says that stopping apt-daily-upgrade waits until u-u exits
<rbalint> juliank: yes, the test is wrong
<juliank> but it stops immediately.
<juliank> I would have never merged the patch if I had known that it does not work that way.
<juliank> I mean, the whole timeout thing is nonsense.
<juliank> I expected it to actually work as specified.
<rbalint> juliank: let me follow up in the bug
<rbalint> juliank: the after a timeout everything gets killed and upgrades can be slow, thus both the timeout and killing only the top process is a must :-\
<juliank> I don't think it does anything.
<rbalint> juliank: ?
<juliank> I mean, the service is considered stopped as soon as the script exits, which is immediately.
<juliank> so it already reaches the point we are measuring the timeout for immediately.
<rbalint> juliank: yes, the timeout starts ticking immediately for killing all children, but how is this a problem?
<juliank> The timeout starts when you say stop (and also when you say start).
<juliank> But then the service is stopped immediately
<juliank> So I don't see how the timeout would work
<rbalint> juliank: btw instead of signaling you could use u-u --stop-only form 0.98
<rbalint> s/form/from/
<juliank> Most of our targets are < 0.98?
<juliank> and on 0.98: unattended-upgrade: error: no such option: --stop-only
<rbalint> juliank: sorry, u-u-s
<rbalint> juliank: the timeout should prevent killing all running children of the exited service immediately
<juliank> What I'm saying is that the timeout should never be elapsing anyway, so nobody will get killed.
<juliank> ever.
<juliank> Well, at least not if you are stopping.
<juliank> Ah it is a TimeoutStopSec
<juliank> So yes, you say stop within 900s
<juliank> but stopping just stops the script.
<juliank> hence it stops immediately.
<rbalint> juliank: yes
<juliank> I don't see the 900s coming into effect if systemd says the service is stopped immediately.
<juliank> because 0 < 900
<rbalint> https://www.freedesktop.org/software/systemd/man/systemd.kill.html
<juliank> Ah you mean "If then, after a delay (configured via the TimeoutStopSec= option), processes still remain, the termination request is repeated with the SIGKILL signal (unless this is disabled via the SendSIGKILL= option)"
<rbalint> juliank: yes
<juliank> let's see
<rbalint> juliank: and i think the documentation is a bit vague, and the "main" process is geussed based on rules that may end up considering u-u the main process and this case I did not want to have it SIGKILL's immediately
<rbalint> juliank: so the timeout is a bit of playing safe because the semantics and promises on systemd's side were not crystal-clear
<juliank> It actually does not terminate anything
<juliank> I just configured the service with a 5s timeout
<juliank> added sleep 10000 or something
<juliank> stopped it
<juliank> sleep is still running
<juliank> it's considered:    Active: failed (Result: signal) since Thu 2017-11-23 16:04:10 CET; 1min 11s ago
<juliank> So the doc is wrong
<rbalint> juliank: do you have your test case?
<juliank> I just changed TimeOutStopSec= to 5, and added a sleep after the whole lock checking thing into the script
<juliank> Output: http://paste.ubuntu.com/26028356/
<rbalint> juliank: i need to check again but i say timeout taking effect in one of the logs while testing the u-u fix
<juliank> rbalint: Maybe you saw the u-u-s timeout?
<rbalint> juliank: most likely
<juliank> The point remains that the patch for apt does not do what it looks like it does.
<rbalint> juliank: but my bigger concert was systemd picking u-u as the main process despite being a children of apt's script
<juliank> rbalint: sorry, I gotta ask: is your n near your t or do you just write concert (as opposed to concern) a lot? Because that seems a really funny typo (and I don't know your keyboard layout) ;)
<juliank> I have no idea how the pid guessing works
<juliank> Sleep is still running, BTW
<rbalint> juliank: n->t :-D
<juliank> so it really seems to have no effect :)
<juliank> um, :(
<rbalint> juliank: if you decide to go with u-u-s --stop-only in later releases instead of just sending a signal timeout will become useful
<juliank> I think I want the signal forwarding for the other executed programs too
<rbalint> juliank: but yeah now it does not seem to have effect
<juliank> my idea was just to stay with SIGUSR1 for zesty and below. I don't know how you plan to SRU them
<rbalint> juliank: the n->t is brobably due to a funny muscle memory caused by hunger and a screaming baby behind my back :-)
<juliank> I think you once wanted to just push 0.98 everywhere, but I'm not sure that's still the plan.
<juliank> I think someone said no
<rbalint> juliank: i could not visit the u-u SRU because i got stuff assigned with higher priorities :-\
<rbalint> juliank: IMO there is absolutely no need to signal u-u from apt's scripts because u-u.service does the signaling upon shutdown and in 0.98 it works well finally
<juliank> Look, all I want is systemctl stop apt-daily-upgrade to wait until the service is really stopped.
<rbalint> juliank: if you really want to send signals anyway please don't send them upon upgrade of apt
<rbalint> juliank: you mean stop when u-u is exited, too?
<juliank> yes.
<juliank> I don't want runaway processes.
<juliank> It's ugly to have one service with runaway processes and another cleaning them up
<rbalint> juliank: ok, then please keep the timeout and use u-u --stop-only which does wait for you
<rbalint> juliank: i plan backporting that part for sure to not break on hibernation
<rbalint> juliank: u-u-s --stop-only
<juliank> Then I can just trap "u-u-s --stop-only" SIGTERM I think
<juliank> before running u-u
<rbalint> juliank: also please don't send signal when upgrading apt
<juliank> why should I send a signal when upgrading apt?
<juliank> I mean, it used to restart the service when upgrading
<juliank> but that was a long time ago
<juliank> fixed almost a year ago :)
<rbalint> juliank: ok, then np :-)
<juliank> Can you backport the stop-only to stretch as well? That would be vastly useful then I think.
<juliank> I'll start with bionic and artful
<juliank> The patches for the next artful SRU are collected already :)
<rbalint> juliank: yes, i plan fixing stretch, too
<rbalint> juliank: i'm sorry i have to grab something to ead
<rbalint> eat
<juliank> Then in the worst case, all you get is an error message about unsupported --stop-only if you upgrade apt before you upgrade u-u there and in <= zesty :)
<juliank> OK
 * juliank does not really eat during the day, he gets sleepy afterwards
<juliank> Ew, I still need to forward SIGTERM from the outer apt.systemd.daily invocation to the inner.
<juliank> (locking in) shell sucks
<juliank> Maybe I should just not do the whole subprocess dance just to avoid fd 3 with a lock file being around.
<juliank>     # We hold the lock.  Rerun this script as a child process, which
<juliank>     # can run without propagating an extra fd to all of its children.
<juliank> ^ this stuff
<juliank> My fear is that it leaks into an apt hook or something and never gets released.
<cpaelzer> what is the most clear way for one of many autopkgtests in a d/t/control  to say "not on this arch"?
<cpaelzer> I'm looking for the restrictions spec but it hides from me
<cpaelzer> so recomendations welcome
<cpaelzer> pitti: in case you are around, I'm sure you knopw :-) ^^
<doko> afaik that's not possible. so add a if dpkg --print-architecture ...; then in the test
<pitti> cpaelzer: there is currently no declarative Architecture: field; your test has to ... that
<juliank> I don't see anything in the doc either
<cpaelzer> ok, thanks
<cpaelzer> unfortunate that this is a Test-Command :-)
<cpaelzer> but ok, I know where to change it
<juliank> Maybe we should have an architecture field?
<pitti> cpaelzer: you can add an if [ arch ] there, too
<pitti> cpaelzer: OOI, what's your use case?
<pitti> (usually feature tests are preferrable to architecture tests)
<cpaelzer> bug 1734148
<ubottu> bug 1734148 in resource-agents (Ubuntu) "bionic autopkgtests failing (and blocking since for whatever reason they worked once before)" [Undecided,New] https://launchpad.net/bugs/1734148
<cpaelzer> I have a generic solution for 2/3
<cpaelzer> but for the remaining one I need to mask it on s390x for now
<pitti> in the past we usually solved that by resetting the "ever passed" flag and moved it to "always failed"
<cpaelzer> I'm so close to make this work, now I want to solve it :-)
<cpaelzer> test coverage FTW
<pitti> adding an Architecture: restriction to mask a broken test seems wrong  to me, particualrly as the test is not intrinsically invalid on s390x?
<cpaelzer> on this particular case I want to mask it because I give up on recteating
<cpaelzer> so not the best example to discuss such a restriction
<pitti> right, understandable - but making it an alwaysfail seems preferrable to me than hacking the source?
<pitti> (or more simply, a force-badtest britney hint)
<cpaelzer> pitti: this has 14 tests, 13 work
<cpaelzer> so masking the one in s390x gives coverage of 13
<cpaelzer> and a hint will just make it go undetected
<pitti> ah, ok
<pitti> so [ `uname -m` = s390x ] || .. it is?
<cpaelzer> yep that is what I'm writing atm
<cpaelzer> in the Test-command
<xnox> dpkg --print-architecture
<xnox> is my choice usually =))))) hehe
<rbalint> juliank: i get sleepy, too, when i eat sugar and similar carbs, so i don't do that ;-)
<juliank> I do eat some cashews
<juliank> brain power!
<NikTh> Hi, any clue why this build has failed ? https://goo.gl/YvqqPQ
<mdeslaur> missing #include <errno.h> ?
<NikTh> mdeslaur: maybe this has something to do ? https://patchwork.kernel.org/patch/9162433 .I couldn't find any other relevant patch.
<mdeslaur> NikTh: what are you trying to build exactly?
<juliank> mdeslaur: Job: linux_4.14.0-10.201711231748.dsc the log says
<juliank> it failed building a userspace tool
<juliank> or well, libunwind
<NikTh> juliank: and only on i386.
<juliank> NikTh: Anyhow, probably missing include
<juliank> but no, there is an #include <errno.h>
<mdeslaur> NikTh: http://kernel.ubuntu.com/git/ubuntu/unstable.git/commit/tools/perf/arch/x86/util/unwind-libunwind.c?id=4443d3b93af3c511e07cfc572803ebfa1f2b1c36
<mdeslaur> NikTh: do you have that?
<NikTh> mdeslaur: I think you found it! This is great. Let me try building with again, but I'm quite sure that's the solution.
<NikTh> mdeslaur: Thank you very much !
<mdeslaur> np
<_9_aleksandr_9_> Hello. I am new Ubuntu user. At the first time when I started Ubuntu from usb flash in live mode I had not problems. Installer had not saw any hard drives. He saw only usb flash. But when I tried to turn on my PC again from usb flash for installing Ubuntu installer not started. I have saw it http://qoo.by/3133 (the link contains also photos of bios).
<juliank> _9_aleksandr_9_: hi, you might want to go to #ubuntu for user support
<juliank> _9_aleksandr_9_: this channel is for development of ubuntu :)
<_9_aleksandr_9_> juliank: Unfortunately they don't help me. Maybe you can help. If yes I will be thankful)
<juliank> _9_aleksandr_9_: I'm over in #ubuntu now, that's the appropriate forum to discuss this
<_9_aleksandr_9_> juliank: Ok. I am in #ubuntu also
<_9_aleksandr_9_> juliank: please watch my video in #ubuntu or ##linux
<cesdo> https://youtu.be/1VvCFWWt6-s
#ubuntu-devel 2017-11-24
<doko> coreycb: swift ftbfs in -proposed
<tarzeau_> is the swift src pkg available to test?
<tarzeau_> i supposed that's swiftlang?
<cpaelzer> rbasak: I slightly remember that there was a discussion about mysql retaining user set permission/ownerhip on paths already
<cpaelzer> rbasak: I can't find it :-/ but it would be what I need to dup a new bug on
<cpaelzer> thought it was about ucf or some other infra to usually cover that
<joelkraehemann> hi all
<joelkraehemann> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882513
<ubottu> Debian bug 882513 in gsequencer "gsequencer: autopkgtest is broken" [Normal,Open]
<joelkraehemann> we actually decided to not run the integration tests
<cpaelzer> xnox: ^^
<joelkraehemann> so I didn't take care much about the functional-system-tests.mk.am file
<joelkraehemann> but the patch provided fixes the issues
<joelkraehemann> about the missing line in configure.ac
<joelkraehemann> well I would love to know who runs the integration tests :)
<joelkraehemann> note the VM should have a soundcard
<cpaelzer> rather unlikely to have real sound passed through
<cpaelzer> joelkraehemann: I highlighted xnox above as he was the one doing the report
<cpaelzer> joelkraehemann: thanks for your response and fixes already
<cpaelzer> as xnox has th context on this it is best if he picks that up once he is around
<joelkraehemann> you could modify the config passed to the tests
<joelkraehemann> and use pulseaudio
<joelkraehemann> I personally prefer ALSA
<joelkraehemann> I think there is a null device available in ALSA
<joelkraehemann> but this is up to you
<joelkraehemann> Each test provides its very own config file
<joelkraehemann> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/test/X/ags_functional_editor_workflow_test.c?h=1.1.x#n67
<joelkraehemann> I will provide a patch that makes use of pulse backend
<rbasak> cpaelzer: I'm not sure what you mean. Can you expand on that and see if it prompts my memory please?
<cpaelzer> rbasak: it was about something like "I had set custom perm/owner on /varlib/mysl ..." and want to keep that on updates
<cpaelzer> rbasak: in that was a suggestion how to do so but it was neglected for having more potential trouble than benefit
<cpaelzer> rbasak: today I had a similar bug, but without the suggestion, so I wanted to dup or link it
<cpaelzer> all my searches didn't find what my partial memory remembers
<cpaelzer> rbasak: do not spend too mcuh time on it, I think I triaged it well without
<cpaelzer> it just would have been a good match
<rbasak> OK. I don't recall a specific bug, so we can leave it as you've already handled it :)
<xnox> joelkraehemann, thanks a lot!i'll try applying all that, and will check if i can get the tests going. We currently have capacity to run integration tests on amd64, i386, arm64, ppc64el, s390x VMs and containerized armhf.
<joelkraehemann> xnox: note I just do additional package
<joelkraehemann> currently only enumerated alsa card ids are supported
<joelkraehemann> gsequencer-1.1.5 shall provide improvements
<joelkraehemann> xnox: I try to get different isolation level running
<joelkraehemann> "isolation-container"
<coreycb> doko: rebuilding. looks like breakage in python-eventlet that's since been synced.
<buxy> cyphermox: hey, can you point me to the commit or code section that changed in busybox that explains why environment variables with "/" coming from the kernel are no longer accepted?
<buxy> (moved the question to #debian-boot on OFTC since you are there too)
<Odd_Bloke> Laney: o/ I noticed you've done some transparency-related uploads of gnome-terminal (relatively) recently, so I thought I'd bring these bugs to your attention: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1726262 https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1733369
<ubottu> Launchpad bug 1726262 in gnome-terminal (Ubuntu) "17.10 - flickering overlay patterns in gnome-terminal" [Undecided,Confirmed]
<ubottu> Launchpad bug 1733369 in gnome-terminal (Ubuntu) "Ghosting with "Use transparency from system theme" enabled on an external monitor" [Undecided,New]
<Laney> hi Odd_Bloke, thanks for pinging, I'm away next week so won't be able to look until after that I'm afraid. If it's important to you you can ask Trevinh_o if he has time maybe.
<Odd_Bloke> Laney: No worries, thanks for letting me know!  If I have a bit of down time, I'll bug them. :)
<joelkraehemann> xnox: currently I am running https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/debian/tests/ags-integration-test
#ubuntu-devel 2017-11-26
<Pwnna> does anyone work on btrfs for ubuntu?
<Pwnna> the choice of mounting / as subvol=@, is there a particular reason for this? This choice has made it impossible to use snapper without getting rid of that option all together.
<wxl> `mk-sbuild trusty` on trusty results in: E: 99check: E: Failed to execute â99checkâ: No such file or directory. any ideas how to fix this?
#ubuntu-devel 2018-11-19
<pchamtaczke> Hi! Do you know some tool or api to download your bulletins and packages? For example: https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-14494.html
<ubottu> dnsmasq before 2.78, when configured as a relay, allows remote attackers to obtain sensitive memory information via vectors involving handling DHCPv6 forwarded requests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14494)
<pchamtaczke> I develop tool to download bulletins and cve with vulnerable packages from many sources and either yours!
<TJ-> pchamtaczke: try the channel #ubuntu-hardened where the security team are
<pchamtaczke> Currently I try to parse your website, but its hard. Mainly because, there is not strict reference to every field
<pchamtaczke> Thanks! So im going there
<acheronuk> mwhudson tianon: thanks. for the record, I need disco to set up Kubuntu CI to do builds for disco
<ahasenack> hi, I believe this MIR is complete (https://bugs.launchpad.net/ubuntu/+source/mecab/+bug/1781529), could an AA act on the mecab-ipadic package too please?
<ubottu> Launchpad bug 1781529 in mecab-ipadic (Ubuntu) "[MIR] mecab" [Undecided,Fix committed]
<ahasenack> mecab was done a few days ago
<rbasak> Skuggen: you said in the bug "Both mecab and MySQL have a dependency on mecab-ipadic" but there doesn't seem to be a dependency on mecab-ipadic now?
<rbasak> nacc, kstenerud: how about 1600 UTC tomorrow for the PHP sync? If that's too early for you nacc, then kstenerud are you available after EOD one day this week please?
<nacc> rbasak: i think that should work for me
<nacc> rbasak: can you send me a calendar invite?
<rbasak> nacc: sent I think.
<nacc> rbasak: received. I'm in CST now, so it's not bad for me at all
<rbasak> Great!
<sil2100> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<Odd_Bloke> tdaitx: Congrats!
<tsimonq2> Does anyone know where the udevbot code lives?
<xnox> maybe try asking on #ubuntu-irc ?
<doko> jamespage, coreycb: python 3.6.7 and 3.7.1 are now in bionic-updates
<coreycb> doko: great thanks for the update
#ubuntu-devel 2018-11-20
<mwhudson> acheronuk: ubuntu:19.04 is on the docker hub now fwiw
<Logan> hey, this might've been asked before, but why do we still mark Precise as supported on Launchpad? Hasn't it been EOL for over a year?
<sarnold> ubuntu advantage customers have "ESM" support for precise
<sarnold> that provides support for a subset of packages from the server seed
<Logan> ahh, I see. Thanks!
<Logan> I wonder if we could have a separate status for it on Launchpad
<Logan> since "Supported" probably isn't the right status
<Unit193> It's really not, though at least PPAs still work.
<sarnold> Logan: yeah, but it's asking an awful lot of one or two words in parenthesis to describe what status it *is* .. heh
<Logan> heh, true
<Skuggen> rbasak: Oh, you mean that mysql doesn't depend on it? That's a bug in our packaging, actually :)
<Skuggen> We also need to add the ipadic dictionary to the apparmor profile to make the mecab plugin work out of the box
<rbasak> Skuggen: fancy working on that please? :)
<Skuggen> Yup, I'll make a patch for it :)
<Skuggen> There are mecab tests in the upstream test suite, but they're not in the main suite we run. Maybe also try running them on the side
<acheronuk> mwhudson: thank you!
<jamespage> doko: could you do the honours on bug 1804209 ? blocking neutron migration (along with neutron-taas which I'm about to fixup)
<ubottu> bug 1804209 in networking-arista (Ubuntu) "[RM] networking-arista, networking-ovs-dpdk" [Undecided,New] https://launchpad.net/bugs/1804209
<jamespage> any archive admins around who could look at the NEW binary for https://launchpad.net/ubuntu/+source/hvac/0.5.0-0ubuntu1~ubuntu18.04.1/+build/15656027 in bionic please?
<cpaelzer> back with some insanity, a few days before I asked about ideas on a "too many levels of symbolic links" error that hits me
<cpaelzer> Now I have a build log that I think alternating 1. proves that it is not a symlink loop (with namei) and then shows copy to fail on it in strace
<cpaelzer> see https://launchpadlibrarian.net/398333658/buildlog_ubuntu-disco-ppc64el.gpsd_3.18.1-2~ppa18_BUILDING.txt.gz
<cpaelzer> I'd be happy about any suggestions what this might be
<cpaelzer> my local repro is no more able to trigger it, i only see it on ppc64el launchpad builders
<doko> jamespage: done
<jamespage> doko: thanks
<rbasak> nacc: ping
<nacc> rbasak: omw sorry
<Coren> Hey all.  (Not clear if this is the correct channel or not - feel free to redirect me).  I'm hitting a really odd thing while trying to build a package under bionic: I have libtool crash on a Trace/breakpoint trap at unclear but deterministic spots.
<Coren> Specifically, the 3.1.3-1 proposed of https://launchpad.net/ubuntu/+source/tpm2-tools
<Coren> (debuilld, not pbuilder though I suppose I should try /that/ next)
<mwhudson> coreycb, jamespage: are python-murano-pkg-check and python-diskimage-builder on your hit list?
<mwhudson> only things in archive still depending on python3.6 i think
<coreycb> mwhudson: wow getting there, cool. we'll get those.
<mwhudson> coreycb: http://people.canonical.com/~ubuntu-archive/transitions/html/html/python3.7-only.html
<mwhudson> coreycb: yeah, i'm surprised it's so close already
<coreycb> mwhudson: well you know a few skipped tests here and there
<coreycb> mwhudson: and some fixed as well!
<mwhudson> coreycb: sssh
#ubuntu-devel 2018-11-21
<doko> coreycb, jamespage: murano-dashboard depends on django-floppyforms, which was removed already
<seb128> xnox, hey, we would like to get https://github.com/systemd/systemd/commit/c6d7a5e9 cherry picked in disco, what's the best way go about that? ask you directly? open a bug on launchpad? just do the cherry pick & upload without bothering you? (there is a customer request for a SRU, first step is to include to disco)
<zfer> Hi
<zfer> How to add tag to a bug report on launchpad?
<seb128> bdmurray, could you review/accepted the new gvfs upload to the cosmic SRU queue? the version you accepted yesterday was missing a patch from the series and failed verification, the follow up just add that one line ... also would be nice if you could accept unity-settings-daemon/xenial (it's the same fix you accepted in bionic&cosmic yesterday)
<zfer> I'm logged in
<seb128> zfer, hey, under the description you have a "tags: ..." and a round pencil icon, click that one
<zfer> seb128: thank you
<zfer> done!
<seb128> yw
<zfer> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1793953
<ubottu> Launchpad bug 1793953 in linux (Ubuntu) "resume from suspend fails after upgrade from 16.04 LTS to 18.04 LTS" [Medium,Confirmed]
<bdmurray> seb128: I looked at u-s-d yesterday but there is an existing unverified SRU in -proposed. I'll have a look at gvfs though.
<seb128> bdmurray, ah, good point for u-s-d, I will try to get unblocked, thx
<xnox> seb128, that one looks easy.
<xnox> seb128, please open a bug report against systemd package, please copy and fill out the SRU template, and do add the link to the commit id to cherrypick.
<xnox> seb128, i will roll SRUs with that included as far back as needed, do specify how far back.
<xnox> seb128, in terms of ETAs. The September batch of SRUs has landed in xenial; and is attempting to land in bionic still, but got trumped by two security uploads.
<xnox> seb128, once the current bionic SRU is out, a new SRU cycle will start immediately.
<xnox> seb128, of if you can't be bothered to do the SRU bug report that everyone can track.... i can open one myself.
<Laney> Hotwire: I don't know if there's
<Laney> oops
<Laney> ECHAN
#ubuntu-devel 2018-11-22
<Logan> if you were the one who uploaded an SRU fix, can you mark it as verification-done if you've verified the fix works? Or does it have to be a different person?
<sarnold> I think it's considered poor form but I haven't seen any actual rules against it
<teward> there's a couple cases where I've done it
<teward> but they were minor changes or just changing a default config file option
<Logan> hmm, okay. I think I'll give it a week or so to see if the original bug reporter verifies it, and I'll verify it otherwise
<teward> and sarnold has seen at least two of those such SRU 'fixes' I uploaded which I approvified.
<Logan> since I would like to see this fix pushed out
<sarnold> it's hard enough to get folks to help test though :(
<teward> sarnold: especially with more obscure things
<sarnold> yeah
<teward> sarnold: 'course when it's nginx I give a pretty good test case to run through
<teward> then anyone can
<Logan> either of you running Cosmic and want to verify? :P It's not very obscure. It's getting reportbug to work
<sarnold> and half the time the reporter has reinstalled or gave the machine away or something
<teward> sarnold: or, it's security related and i bother you all anyways
<teward> Logan: sorry, I'm an LTS-follower, 18.04, not 18.10
<Logan> :(
<teward> i can maybe install a VM?
<sarnold> Logan: I'm on bionic.. would it go in an lxd instance?
<Logan> I don't want to make you do that, haha
<Logan> I don't see why not?
<teward> oh i can do that too *spin spin spin*
<teward> got a test case and a bug # ?
<Logan> https://bugs.launchpad.net/ubuntu/+source/pysimplesoap/+bug/1794235
<ubottu> Launchpad bug 1794235 in pysimplesoap (Ubuntu Cosmic) "pysimplesoap broken with python-httplib2 >= 0.10" [High,Fix committed]
<Logan> basically, reportbug -B debian fails in the current Cosmic install. When it tries to fetch current bugs from the Debian BTS for the source package you specified, it throws an error that it can't connect to the BTS
<teward> blurgh, the ubuntu cloud images for LXD server is being slow
<teward> sarnold: do I throw salt at stgraber for that or SA?
<sarnold> probably stgraber.. funny thing, it started at 700kb/s for me but finished at 11MB/s
<teward> it's lagging at 565kBps here
<teward> and getting slower
<teward> and I"m jacked into a gig ethernet uplink
<sarnold> Logan: is there a standard "i'm just testing" package?
<teward> with a gig internet speed :P
<teward> Logan: or alternatively, do you have another test case for how we can test this that DOESN'T involve reportbug
<teward> because Debian hates it when I test things on their prod infa
<teward> infra*
<Logan> sarnold: hmmm... anything should trigger it
<Logan> gedit?
<Logan> and then you can just skip putting in a version
<Logan> teward: this isn't really testing on their prod infra - it's just starting to try to report a bug and failing :P
<Logan> (I guess you could consider that testing, but still)
<teward> ah
<stgraber> teward, sarnold: cloud images (ubuntu: and ubuntu-daily:) come from cloud-images.ubuntu.com which is UK-only and can be overloaded...
<teward> well i have 50 bugs to report so I mean :P
<teward> stgraber: which could explain the slow speed
<teward> stgraber: no mirrors I take it :|
<stgraber> teward, sarnold: the community image server (images:) is geoip-ed with US and UK servers and tends to have much less of a bandwidth issue
<teward> which explains the 30MBps I got for the Debian image heh
<stgraber> there have been talks about getting Canonical IS to setup the same geoip environment for cloud-images.ubuntu.com, but not much progress has been done so far...
<teward> Logan: is there a package sitting in proposed awaiting testing and verification?
<Logan> that is correct
<teward> ACK
<teward> *test*
<sarnold> Logan: does this look useful? https://pastebin.ubuntu.com/p/3trVMSHtpy/
<sarnold> stgraber: oh cool, thanks
<Logan> sarnold: not quite, unfortunately. Before installing the fixed version of python3-pysimplesoap, please try running "reportbug -B debian" (again, after configuration) and putting in a source package name and then a blank version. It should then fail to query the BTS
<Logan> then, after installing the fixed python3-pysimplesoap, doing the same thing should show a list of bugs for that source package in the Debian BTS
<teward> uhm....
<teward> oh that's why  1 moment
<sarnold> Logan: okay, I destroyped and started over.. it looks pretty similar :/ https://pastebin.ubuntu.com/p/4HGk5WCxw7/
<teward> Logan: verified that it works, at least for Report Bug
<teward> sarnold: test using 'nginx' as a target
<teward> something you don't have installed
<Logan> yeah, sarnold, where it said you had a newer version and you just exited out, that avoided the failure path
<teward> you'll get the bug list pulled eventually.  and leave version string blank
<teward> Logan: verification-done-cosmic (per my tests)
<Logan> sweet, thanks teward! And thank you sarnold as well :)
<teward> https://paste.ubuntu.com/p/SpH22V25Td/
<sarnold> d'oh :D
<Logan> teward: and you reproduced the failure case before upgrading pysimplesoap?
<sarnold> Logan: so, all good?
<Logan> yup, I believe so :)
<Logan> although I just found another bug
<Logan> that will need another SRU
<Logan> good times
<sarnold> oh man
<Logan> and it's in the same package!
<sarnold> isn't that the way it always goes? every time I look at source code I find something.
<teward> Logan: affirmative, as the case was stated :P
<Logan> the Debian maintainer removed the egg info for the Python package for no explained reason
<Logan> so if you try running the debianbts command, it fails because it can't find the distribution for pysimplesoap
<Logan> that's an easy test case - just run that command, and it fails
<Logan> teward: :)
<Logan> and to be clear, it's broken in both the original version in Cosmic and in the SRU upload - not a regression from the SRU
<teward> Logan: I'mma verification-done the SRU as is
<Logan> ty!
<teward> that way it can be 'acceptified'
<teward> and yes i know that's not a word i've been drinking a little this evening sue me
<Logan> :D
<teward> bug updated
<Logan> re the above that I just mentioned: I fixed pysimplesoap to actually install its egg-info, but it turns out that the debianbts command doesn't actually do anything. Yay?
<Logan> â¯â¯â¯ debianbts
<Logan> 2018-11-21 21:35:01,159 WARNING debianbts Not implemented yet, sorry!
<Logan> glad they're installing a binary that's not implemented -_-
<teward> lol...
<Logan> (apparently the command I was thinking of is bts, which *is* implemented)
<seb128> xnox, hey, thx for the systemd fix, I reported bug #1804584 with the SRU details etc
<ubottu> bug 1804584 in systemd (Ubuntu) "LG screen reported as being a Goldstar one" [Low,Triaged] https://launchpad.net/bugs/1804584
<doko> jbicha: thanks for resetting the postgresql-common tests :-(((
<tjaalton> seb128: please also nominate it for the series
<seb128> tjaalton, that's a comment from a SRU team perspective? (others have not been asking for that and it's not documented on the wiki that nominations are required)
<RAOF> tjaalton: the `sru-review` tool should automatically add an appropriate task (as long as there's at least one Ubuntu task already there)
<tjaalton> seb128: yes, and true that it's not mentioned on the wiki
<tjaalton> RAOF: ah, well having the nominations there would tell me to go look the other queues next
<tjaalton> just that pretty much everyone else seem to add those :)
<doko> jamespage: please have a look at https://bugs.launchpad.net/ubuntu/+source/python-oauth2client/+bug/1804606 there is an old MIR, but that expired.
<ubottu> Launchpad bug 1804606 in python-oauth2client (Ubuntu) "MIR: python-oauth2client, new dependency of cinder" [Undecided,New]
<jamespage> looking
<jamespage> doko: cinder -> resource-agents (but lp keeps timing out on me)
<doko> o python-googleapi: python3-googleapi
<doko>    [Reverse-Recommends: resource-agents (MAIN)]
<doko> so only a recommends?
<doko> jamespage: make it a suggestion?
<jamespage> doko: that might make sense yes
<jamespage> just looking
<jamespage> doko: yeah that will work fine
<jamespage> doko: uploading now
<doko> jamespage: ok, closing that report as invalid
<jamespage> doko: ack - I think I already did that
<doko> ta
<mdeslaur> tkamppeter: are you working on ghostscript 9.26 in disco? I want to make sure I use your orig tarball for the stable releases
<seb128> xnox, I'm about to close IRC/call it a day but just as a fyi, I commented on bug #1799364, that change is problematic and got reverted upstream since so I think we should rediscuss the issue before SRUing it
<ubottu> bug 1799364 in systemd (Ubuntu Cosmic) "The wlan/bt hotkey doesn't work for all Dell Latitude and Precision computers" [Undecided,New] https://launchpad.net/bugs/1799364
<seb128> FourDollars, ^
<seb128> bdmurray, oh, the unity-settings-daemon which was in xenial-proposed cleared off and migrated to update, if you could have another look to the one in the queue which we discussed the other day :)
<seb128> oh that note calling it a day, see you tomorrow ubuntu-ers!
#ubuntu-devel 2018-11-23
<FourDollars> seb128: OK. Let me check if I can borrow the problematic hardware to see what is going on.
<mwhudson> root@disco:~# for x in `seq 1000`; do ./int64test nan; done | sort | uniq -c
<mwhudson>     504 result -9223372036854775808 status 0
<mwhudson>     496 result 0 status 1
<mwhudson> icu in disco-proposed :(
<mwhudson> mind you icu in disco release does the same with NaN
<mwhudson> and of course it's completely consistent if you turn aslr off :(
<doko> tkamppeter: https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/1804772 isn't that because hplip is installing stuff from the web?
<ubottu> Launchpad bug 1804772 in hplip (Ubuntu) "package python3-gdbm:amd64 3.6.7-1~18.04 failed to install/upgrade: afhÃ¦ngighedsproblemer - efterlader den ukonfigureret" [Undecided,New]
<zfer> Hi
<zfer> dpkg -i | grep linux-image
<zfer> returns many kernel version, but I need to test 4.4 version and booting with Shift doesn't list it. How can I make kernel 4.4 available for ubuntu advanced options during boot?
<zfer> according dpkg -i I've 4.4 already installed
<Faux> `sudo update-grub` (relatively harmless) is a good way to see what will be on the boot menu.
<zfer> Faux: thank you
<zfer> There is not 4.4 version of kernel listed from update-grub
<zfer> How can I add it?
<Faux> I wouldn't try and do it by hand. Find a repo that has a 4.4 kernel in that's compatible with your release, and install it from there. (This isn't really a good channel.)
<ahasenack> jbicha: around?
<jbicha> yes
<ahasenack> jbicha: any particular reason you synced ndctl ffrom debian?
<jbicha> because I didn't realize how broken ndctl was :/
<ahasenack> it introduced some packaging regressions compared to what we had in bionic and cosmic
<jbicha> yes LP: #1804725
<ubottu> Launchpad bug 1804725 in ndctl (Ubuntu) "Fix up ndctl upgrade from cosmic to disco" [High,New] https://launchpad.net/bugs/1804725
<jbicha> we already had to NMU it twice in Debian
<ahasenack> I was kind of in touch with the debian maintainer(s) about it, they pinged me a few weeks ago asking if they could upload ubuntu's package into debian
<ahasenack> Adam Borowski <kilobyte@angband.pl>
<jbicha> that's the guy that did the NMU
<jbicha> https://tracker.debian.org/pkg/ndctl
<jbicha> if I (or someone) is going to change the binary package names, I want to confirm with the maintainer (Breno) first
<ahasenack> I asked to co-maintain, he said great, then disappeared, and I didn't ping him again either
<ahasenack> I jsut emailed him today asking to at least create a salsa repo
<jbicha> Adam is not the maintainer. You should ask those questions to Breno
<ahasenack> he later found breno's package, I think it was in their NEW queue
<ahasenack> anyway, the ubuntu changes were lost, we can start the work to re-add them, and if debian gets the package in salsa, we can coordinate better
<jbicha> Adam & I have sort of been hijacking ndctl since the package was basically unusable as originally uploaded
<ahasenack> I need to rejoin, 1s, xchat is behaving erratically
<ahasenack> better
<rbasak> jbicha: I'm having some trouble following why we aren't just uploading a +really back into Ubuntu to revert your sync.
<jbicha> rbasak: we don't need a really. We just need to rebase on top
<jbicha> ahasenack: do you want to fix up the disco package or do you want me to do it?
<rbasak> Are you planning on doing that soon?
<ahasenack> jbicha: how would you do it?
<jbicha> I would go through the issues I listed in bug 1804725. Some of the Debian changes are probably ok
<ubottu> bug 1804725 in ndctl (Ubuntu) "Fix up ndctl upgrade from cosmic to disco" [High,New] https://launchpad.net/bugs/1804725
<ahasenack> go for it then
<jbicha> ok
<ahasenack> also note that in this new upstream version, that new service, monitor-something, won't start, but at least dpkg doesn't fail
<ahasenack> I added that and other info to the bug
<jbicha> thank you. I can't do anything about the monitor service but I can fix up the packaging
<ahasenack> it's better already, I remember when I first tried to update to this version (upstream requested), I noted that it would fail hard
<ahasenack> that bit they fixed at least (upstream)
<ahasenack> https://github.com/pmem/ndctl/commit/52a4d38e7b5f56d85712f6bb29758521604a2b3e
<jbicha> ok
<rbasak> jbicha: some suggestions on detecting this:
<rbasak> Before sync, check the Ubuntu changelog for the common ancestor. If there is none, then it needs further investigation.
<rbasak> And speak to the TIL?
<doko> jbicha: libqalculate ftbfs on arm64
#ubuntu-devel 2019-11-18
<mwhudson> has anyone looked at http://autopkgtest.ubuntu.com/packages/g/geoalchemy2/focal/amd64 ?
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<rafaeldtinoco> rbasak: ping
<rbasak> rafaeldtinoco: o/
<rafaeldtinoco> rbasak: =o)
<rafaeldtinoco> rbasak: online ?
<rafaeldtinoco> or just passing by ?
<rbasak> Well, both :)
#ubuntu-devel 2019-11-19
<rafaeldtinoco> lol
<rafaeldtinoco> i was going to ask if you were aware that dnsmasq doesnt provide a leases file for uv-kvt so uv-kvt ssh <machine> is broken (at least in disco). im thinking fixing it by using nss_libvirt_guest for nsswitch
<rafaeldtinoco> no rush though
<rbasak> I tested uvtool against Eoan recently when doing the Python 3 porting work. It seemed to work there.
<rbasak> uvtool reads from either /var/lib/libvirt/dnsmasq/virbr0.status or /var/lib/libvirt/dnsmasq/default.leases
<rbasak> See uvtool/libvirt/__init__.py in the source
<rbasak> Start from the mac_to_ip function
<ailion> Hello, every one.
<ailion> I have followed this tutorial: https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
<ailion> and also this one: https://help.ubuntu.com/community/InstallCDCustomization
<ailion> Now I am trying to combine these two together.
<ailion> Instead of `apt-get install ubiquity-frontend-gtk`, I use `apt-get install subiquity`.
<ailion> After rebooting, subiquity runs but stucks at `Network Connections`.
<ailion> Is there any tutorial on this topic?
<ailion> Thank you!
<cpaelzer> rbasak: was it you that had come up with a helper to check the d/copyright information or was that ahasenack?
<cpaelzer> I only want to make sure d/copyright in a package is up to date
<rbasak> cpaelzer: it was a task for me to write up a spec, but that never bubbled up to the top of my TODO
<cpaelzer> ok using the common tools then
<rbasak> cpaelzer: I think lintian checks for files not covered in a dep-5 copyright file
<cpaelzer> I think they all use https://wiki.debian.org/CopyrightReviewTools
<rbasak> We get that happening in new MySQL upstream releases quite a bit
<cpaelzer> but I'll run a pedantic lintion to be sure
<rafaeldtinoco> ls
<rafaeldtinoco> ops
<rbasak> Skuggen: could you take a look at bug 1853144 please? I think this needs an upstream fix, and in the meantime a patch to the test should be fairly trivial in a distro patch.
<ubottu> bug 1853144 in mysql-8.0 (Ubuntu) "main.mysqlpump_basic_lz4 dep8 test fails with a false positive" [Undecided,Triaged] https://launchpad.net/bugs/1853144
<rbasak> This is currently holding up proposed migration of lz4
<rbasak> Which we could force since it's not a regression in lz4, but we'd still be stuck with mysql failing dep8 in the future so it would be easier to just fix it :)
<mdeslaur> rbasak: I just uploaded a mysql to fix that issue, and am about to upload a fix to the fix
<mdeslaur> Skuggen: ^
<mdeslaur> wait a few minutes, and I'll let you know
<rbasak> mdeslaur: ah. Thanks!
<rbasak> 2>&1 > $LZ4_EXEC_LOG
<rbasak> Hmm
<rbasak> Shouldn't that be the other way roun?
<rbasak> Or are you intentionally outputting stderr to stdout and leaving only stdout to go to the log file?
<rbasak> In this case it'll work either way I think
<rbasak> Since stderr presumably no longer outputs anything
<rbasak> But it won't work with older versions of lz4
<mdeslaur> rbasak: yes, I inverted it by mistake, so it only worked with the new version...with it inverted it should work with both versions
<mdeslaur> I keep inverting it, and I keep using 2&>1 by mistake
<mdeslaur> I suck :)
<cpaelzer> kanashiro: squid LGTM and got sponsored, as usual please track migration in a few hours please
<cpaelzer> mdeslaur: those who do nothing do no mistakes :-)
<kanashiro> cpaelzer, ack, thanks for reviewing and sponsoring :)
<cpaelzer> rafaeldtinoco: I have fixed the qa-regression-tests for strongswan
<cpaelzer> rafaeldtinoco: I have lnked the MP and with the change the test completes as expected
<rafaeldtinoco> cool!
<cpaelzer> so this part of your feedback is handled
<rafaeldtinoco> finishing up
<cpaelzer> rafaeldtinoco: continue to come up with whatever you find
<rafaeldtinoco> cpaelzer: on the Breaks:
<rafaeldtinoco> we have 5.7.2-1ubuntu2 and ubuntu3
<rafaeldtinoco> wouldn't those be broken as well ?
<rafaeldtinoco> trongswan-tnc-ifmap (<< 5.7.2-1ubuntu1)
<rafaeldtinoco> hum.. << and not <=
<rafaeldtinoco> ah ok.. got it #)
<cpaelzer> this is of Eoan
<rafaeldtinoco> yep
<rafaeldtinoco> from eoan and on
<cpaelzer> yes
<rafaeldtinoco> transitional pkg for 1 release
<cpaelzer> for LTS->LTS upgraders it will trigger with 20.04
<rafaeldtinoco> yep
<cpaelzer> for 19.10->20.04 it already happened
<rafaeldtinoco> yep, this type of concern is new to me
<rafaeldtinoco> thats why I ask
<rafaeldtinoco> makes snese
<cpaelzer> I made snese, snot all around - I'll get you rafaeldtinoco
<rafaeldtinoco> :P
<rafaeldtinoco> cpaelzer: +1 for u
<rafaeldtinoco> i think there is still a merge left
<rafaeldtinoco> from the 4 you mentioned yesterday
 * rafaeldtinoco checks
<rafaeldtinoco> nope, i think libseccomp was done already
<rafaeldtinoco> let me know if i missed a MR you'd like a review of
<cpaelzer> rafaeldtinoco: I'm good  for now, thank you
<seb128> hum
<seb128> are autosync happening atm?
<seb128> I was looking at fontforge that got an update in Debian 2 days ago, should it have been synced since?
<cjwatson> [Updating] fontforge (1:20170731~dfsg-2build1 [Ubuntu] < 1:20190801~dfsg-2 [Debian])
<cjwatson>  * Trying to add fontforge ...
<cjwatson> I: fontforge -> fontforge_1:20170731~dfsg-2build1.
<cjwatson> I: fontforge -> fontforge-nox_1:20170731~dfsg-2build1.
<cjwatson> I: fontforge -> fontforge-common_1:20170731~dfsg-2build1.
<cjwatson> I: fontforge -> libfontforge-dev_1:20170731~dfsg-2build1.
<cjwatson> I: fontforge -> fontforge-doc_1:20170731~dfsg-2build1.
<cjwatson> fontforge_1:20190801~dfsg-2 is trying to override modified binary fontforge-extras_0.3-4ubuntu1.  OK (y/N)?  n
<cjwatson> [Updating] fontforge (1:20170731~dfsg-2build1 [Ubuntu] < 1:20190801~dfsg-2 [Debian])
<cjwatson>  * Trying to add fontforge ...
<cjwatson> Oops, sorry for second bit
<cjwatson> https://people.canonical.com/~ubuntu-archive/auto-sync/current.log
<cjwatson> i.e. the new source is taking over a binary package that currently has Ubuntu modifications.  This needs a developer to check it
<cjwatson> Though that modification is a bit odd.  There's no need for a source change to change the section of a binary package - that's done via overrides anyway
<cjwatson> So IMO you could sync that manually and disregard the Ubuntu modification
<cjwatson> seb128: ^-
<seb128> cjwatson, ah, thanks for checking! can you remind me where is the log for the autosyncs so I can maybe try to look myself before asking next time
<cjwatson> 15:37 <cjwatson> https://people.canonical.com/~ubuntu-archive/auto-sync/current.log
<cjwatson> :-)
<seb128> arg, can't read, sorry :(
<seb128> cjwatson, thanks!
<cjwatson> np :)
<rbasak> xnox: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164 looks right to me. Please could you take a look?
<ubottu> Launchpad bug 1853164 in systemd (Ubuntu) "systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error" [Undecided,New]
<seb128> next 'reports" question, sorry channel :/
<seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
<seb128> has
<seb128> glib2.0 (2.62.1-1 to 2.63.1-2) in proposed for 0 days
<seb128>     Regressions
<seb128>  pango1.0/1.42.4-7: amd64 (log, history)
<seb128> but http://autopkgtest.ubuntu.com/packages/p/pango1.0/focal/amd64 has no failure
<seb128> does anyone know what's going on?
<seb128> I guess maybe they don't refresh real time and I need to wait a bit longer...
<rbasak> rafaeldtinoco: https://bazaar.launchpad.net/~uvtool-dev/uvtool/trunk/revision/93 was the fix I'm referring to
<rafaeldtinoco> great. let me re-check
<rafaeldtinoco> $ uvt-kvm ssh strongswan-test-1
<rafaeldtinoco> uvt-kvm: error: no IP address found for libvirt machine 'strongswan-test-1'. Has it had time to boot yet?
<rafaeldtinoco> $ virsh net-dhcp-leases default
<rafaeldtinoco>  Expiry Time           MAC address         Protocol   IP address        Hostname   Client ID or DUID
<rafaeldtinoco> ---------------------------------------------------------------------------------------------------------------------------------------------
<rafaeldtinoco>  2019-11-19 13:52:38   52:54:00:3a:02:05   ipv4       172.16.0.139/24   ubuntu     ff:b5:5e:67:ff:00:02:00:00:ab:11:13:da:41:eb:da:62:95:19
<rafaeldtinoco>  2019-11-19 13:52:47   52:54:00:dd:ca:94   ipv4       172.16.0.186/24   ubuntu     ff:b5:5e:67:ff:00:02:00:00:ab:11:95:f1:d8:ff:c1:31:e8:5f
<rafaeldtinoco> the hostnames are ubuntu because of cloud-init (as these 2 machines were just provisioned)
<rafaeldtinoco> let me check after a reboot
<rafaeldtinoco> I have no /var/lib/libvirt/dnsmasq/default.leases file
<rafaeldtinoco> all leases are queried by libvirt but no leases file
<rafaeldtinoco> is that expected ?
<rbasak> rafaeldtinoco: do you have a /var/lib/libvirt/dnsmasq/virbr0.status file?
<rafaeldtinoco> not
<rafaeldtinoco> nope
<rbasak> Are you using a virbr0 bridge with dnsmasq?
<rafaeldtinoco> nope
<rafaeldtinoco> kvm.status
<rbasak> OK so that's why
<rafaeldtinoco> kvm is my default
<rafaeldtinoco> ah
<rbasak> uvtool doesn't have support for that configuration
<rafaeldtinoco> alright, makes sense now
<rafaeldtinoco> not a bug
<rbasak> So "uvt-kvm ip" and therefore "uvt-kvm ssh" won't work.
<rafaeldtinoco> yep
<rbasak> If you can implement something more generic, then I'll happily accept a patch
<rafaeldtinoco> yep
<rbasak> This is all about uvt-kvm's capability of guessing heuristically
<rafaeldtinoco> perhaps a query for the default
<rafaeldtinoco> $ virsh net-dumpxml default | grep bridge
<rafaeldtinoco>   <bridge name='kvm' stp='off' delay='0'/>
<rafaeldtinoco> rbasak: ^ something like it
<rafaeldtinoco> will give it a try
<rafaeldtinoco> let me open a bug for not to forget
<rafaeldtinoco> ill flag it as a wishlist
<xnox> rbasak:  tagged for foundations to pick up
<rbasak> xnox: thanks!
<rbasak> xnox: I pinged because the bug report claim seemed correct in principle, and it's a trivial fix, patch provided. Not checked the patch itself for correctness or anything.
<rafaeldtinoco> #1609072 uvt-kvm assumes network is on virbr0
<gpiccoli> Hi rbasak, how are you doing? Were you able to check LP #1847924 ?
<ubottu> Launchpad bug 1847924 in mdadm (Ubuntu Focal) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924
<gpiccoli> We are waiting on a consensus to move forward hehe
<rbasak> gpiccoli: sorry I was out last week and have barely caught up
<gpiccoli> no problem rbasak =)
<rbasak> gpiccoli: I replied in the bug
<gpiccoli> THanks Robie =)
<rbasak> gpiccoli: I also want really hard testing for this SRU. I don't think causing users hassle because of a regression in the process of landing this will be very excusable.
<rbasak> (which is why I want a second SRU team member opinion)
<rbasak> It is only just on the right side of the line to qualify for an SRU IMHO
<gpiccoli> ok rbasak, thank you !
<Son_Goku> cyphermox, could you please look at doing this soon? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1824245
<ubottu> Launchpad bug 1824245 in grub2 (Ubuntu Xenial) "Can't create a bootable disk by doing image creation on a loop device" [Medium,Triaged]
<cyphermox> Son_Goku: ok, looking now; but could you please follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure to make sure the bug includes test cases? I don't know what steps need to be taken precisely to verify this; it would be best if it was clearly described
<Son_Goku> cyphermox, let me see if I can make a test case for this
<Son_Goku> I don't know if I can guarantee that I can make one, given the logic is kinda tangled in an internal business tool :(
<Son_Goku> but I'll try
<cyphermox> Son_Goku: if there is no test case, this won't pass for SRU.
<Son_Goku> hmm
<Son_Goku> let me see if I can make a minimal test case
 * Son_Goku grumbles at the fact this tool is written in spaghetti PHP code
<blahdeblah> RAOF: Hi - any chance you can give some general advice on https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1852170 ?  It is a regression from disco to eoan, and the wiki doesn't really give much guidance on how to troubleshoot.
<ubottu> Launchpad bug 1852170 in xorg (Ubuntu) "Severe screen corruption" [Undecided,New]
<RAOF> blahdeblah: Hm. My guess would be mesa (since I've seen there's a critical regression there).
<RAOF> Ah, no, different version.
<RAOF> But trying with the disco version of mesa would be a fine start.
<tjaalton> or kernel
<blahdeblah> So downgrading just mesa packages might be a viable option?
<tjaalton> it's more messy to downgrade mesa than to try an older kernel
<blahdeblah> tjaalton: indeed
<blahdeblah> I have vague memories of a really old wiki page or similar which used to recommend different acceleration options to start disabling to see where the problem lies, but the current state of the X troubleshooting page on the wiki doesn't seem to include anything about display corruption.
<blahdeblah> I'd guess that most of the old advice about acceleration options doesn't apply on modern systems anyway.
<tjaalton> right
<mwhudson> how much ram do buildds have? (arm64)
<bdmurray> cpaelzer: Where did "we agreed to regularly backport those to the latest LTS." from bug 1844834
<ubottu> bug 1844834 in open-vm-tools (Ubuntu Eoan) "open-vm-tools 11.0.0 released" [Undecided,Triaged] https://launchpad.net/bugs/1844834
<blahdeblah> thanks tjaalton & RAOF - I'll make sure the bug gets updated with things tried.
#ubuntu-devel 2019-11-20
<Skuggen> mdeslaur: Sorry, didn't see your highlight. lz4 is still blocked on mysql? If it's not as simple as the bug suggests, we could disable the test for now
<RAOF> Wow. Has LP upstream bandwidth improved? I'm getting ~3MB/s from it now, rather than ~300KiB/s :)
<mwhudson> RAOF: the git service finally migrated to new hardware
<RAOF> mwhudson: and the PPAs, too, it seems!
<mwhudson> RAOF: oh
<mwhudson> i've generally had ok bandwidth for them
<mwhudson> RAOF: i'm sorry about the nbn
<RAOF> mwhudson: huh. Previously, I'd consistently been able to get nearly 9MB/s to various London-hosted things, but only hundreds of KiB/s ppa.launchpad.net
<RAOF> I didn't think that was a âyour ISP needs to buy more transitâ problem ð
<mwhudson> hmm!
<mwhudson> ok maybe something has changed then
<cpaelzer> bdmurray: thanks for asking - I put the answer in the bug so that other SRU Team members will find it as well https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1844834/comments/10
<ubottu> Launchpad bug 1844834 in open-vm-tools (Ubuntu Eoan) "open-vm-tools 11.0.0 released" [Undecided,Triaged]
<xnox> doko:  pytest migrated =) horay
<doko> xnox: it wasn't me, it was mw hudson
<xnox> doko:  well, i think it was partially me as well. Had to retry some tests with postgis/postgres from proposed.
<xnox> it would be nice if someone would fix postgis on s390x such that it would migrate
<xnox> looking at the last try of numpy triggered by python3-defaults, cannot understand why f2py3.8 claims to be not there.... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/n/numpy/20191120_042900_cec9a@/log.gz
<xnox> but I can reproduce this!
<xnox> /usr/lib/python3/dist-packages/numpy-1.17.3.egg-info/entry_points.txt
<xnox> /usr/lib/python3.8/dist-packages/numpy-1.17.3.egg-info/entry_points.txt
<xnox> seems bad to me
<xnox> first one points to 3.7, the later one points to 3.8
<xnox> but the later is nonesence
<xnox> doko:  hm, is python3-numpy packaging broken? i thought it's not ok to have python3.7/dist-packages and python3.8/dist-packages in addition to python3/dist-packages
<mwhudson> xnox: just uploaded a fix for that
<mwhudson> well the autopkgtest
<mwhudson> xnox: hm that stuff under usr/lib/python3.8/dist-packages/ is odd
<xnox> mwhudson:  yeah =) that fixup to entry points should work. I was confused about versioned entry points too.
<xnox> it is all very weird =)
<xnox> $ dpkg -L python3-numpy | grep _dummy
<xnox> /usr/lib/python3/dist-packages/numpy/core/_dummy.cpython-37m-x86_64-linux-gnu.so
<xnox> /usr/lib/python3/dist-packages/numpy/core/_dummy.cpython-38-x86_64-linux-gnu.so
<xnox> /usr/lib/python3.7/dist-packages/numpy/core/_dummy.cpython-37m-x86_64-linux-gnu.so
<xnox> /usr/lib/python3.8/dist-packages/numpy/core/_dummy.cpython-38-x86_64-linux-gnu.so
<xnox> imho the 3.X dirs shouldn't exist at all
<cpaelzer> rafaeldtinoco: the libvirt MPs LGTM, should I sponsor them right away?
<rafaeldtinoco> cpaelzer: yes please.
<coreycb> rbasak: (or sil2100 tomorrow): Hi, if you have a moment can you take a look at the following openstack packages in the bionic unapproved queue? horizon, nova, cinder, keystone
<doko> xnox, mwhudson: yes, these shouldn't exist, but it's not hurting anything. please verify that debian has the issue too and file a report
<xnox> ok
#ubuntu-devel 2019-11-21
<mwhudson> is it possible to turn off sbuild's log filtering?
<mwhudson> ah you can do it in sbuild.conf at least
<seb128> cpaelzer, hey, thanks for the tpm2-tss review, does it include tpm-udev / bug #1852347 ? it looks like that was split out on the way to address some issues
<ubottu> bug 1852347 in tpm-udev (Ubuntu) "[MIR] tpm-udev" [Undecided,New] https://launchpad.net/bugs/1852347
<cpaelzer> seb128: that is separate and IIRC on tuesday cyphermox said he is gonna look at that MIR
<cpaelzer> seb128: my statement only focsussed on tpm2-tss itself not the further dependency chain
<seb128> cpaelzer, k, I though we had fwupd unblocked, seems we are back to square 1 and need a new MIR fully reviewed then :-/
<cpaelzer> :-/
<seb128> will wait for cyphermox then
<cpaelzer> I personally haven't kept track ot the tpm-udev part is that huge or rather big discussion?
<seb128> cpaelzer, I've no idea about it, but looks like it was still part of tpm2-tss when the review started, https://bugs.launchpad.net/ubuntu/+source/tpm2-tss/+bug/1841595/comments/6 covers it
<ubottu> Launchpad bug 1841595 in tpm2-tss (Ubuntu) "[MIR] tpm2-tss" [Undecided,Fix released]
<seb128> and https://launchpad.net/ubuntu/+source/tpm2-tss/2.1.0-4 from eoan has it
<seb128> it was only split as a new source in focal
<seb128> cpaelzer, which is why I was wondering if the MIR review covered it
<seb128> well, hopefully it's a trivial one
<cpaelzer> oh it is for sure
<cpaelzer> let me help
<seb128> thx
<cpaelzer> seb128: done, please pick it up
<cpaelzer> the process exists to ensure quality and maintainability not to feel inhibited by it - and in that case no new full review cycle was needed
<seb128> cpaelzer, great, thanks a lot. I've promoted it now
<cpaelzer> yw
<sil2100> vicamo: hey! I see two backport-iwlwifi-dkms uploads in the eoan queue - one with version 7906-0ubuntu1.1 and one with 7906-0ubuntu2~19.10.1, which one should I review?
<cpaelzer> seb: FYI 1853436
<seb128> cpaelzer, right, I just saw it, we will fix that, thx for reporting!
<rafaeldtinoco> cpaelzer: is the format you used in mysql-router MIR something MIR team uses ?
<rafaeldtinoco> like a checklist for acceptance criteria ?
<rafaeldtinoco> (just curious)
<cpaelzer> rafaeldtinoco: yes
<cpaelzer> rafaeldtinoco: if you consider me being the team
<cpaelzer> rafaeldtinoco: it is what is docuemented on the wiki pages
<rafaeldtinoco> oh you're the only one ?
<rafaeldtinoco> =)
<cpaelzer> no but everyone has his own style
<rafaeldtinoco> gotcha
<rafaeldtinoco> i like yours
<cpaelzer> I converted the wiki + anything that came up since then - into a template
<cpaelzer> rafaeldtinoco: also I like to be transparent in case anybody wonders later on and want to share, therefore https://code.launchpad.net/~paelzer/+git/MIR/+ref/master
<cpaelzer> which includes templates for filing as well as for review
<rafaeldtinoco> super nice
<vicamo> sil2100: please do the one with 19.10.1 postfix
<coreycb> sil2100: Hi, I think we now have everything verified for nova and cinder in disco-proposed (1849192 and 1833406) so they should be ready to release if you have cycles
<bdmurray> seb128: Have you seen bug 1851918?
<ubottu> bug 1851918 in python-imaging (Ubuntu) "`hp-check -r` crashes with "AttributeError: module 'PIL.Image' has no attribute 'VERSION'"" [Undecided,Confirmed] https://launchpad.net/bugs/1851918
<seb128> bdmurray, I did, I subsribed tkamppeter to it 10 days ago
<seb128> tkamppeter, ^ is that on your list of things to investigate?
<seb128> bdmurray, do you believe it's important issue by user feedback/stats?
<bdmurray> seb128: I gather its a regression so yes
<seb128> bdmurray, k, thx, hopefully tkamppeter have some time to have a look soon
<tjaalton> how can I get a snap to access a mountpoint under root?
<tjaalton> nevermind, installed the deb
<ogra> the removable-media interface allows access to /mnt and /media and the mounted bots underneath (assuming the snap packager enable that interface in the snap)
<ogra> s/bots/bits/
<tjaalton> well, I have a zfs mirror elsewhere, and ~400GB worth of photos for darktable, but I'll just use the deb for now
<tjaalton> migrated to a new install, home is on a smaller disk and doesn't hold the photos anymore
<ogra> you could just set up a bind mouont to /media
<ginggs> xnox: i see your pyfftw upload now FTBFS with 'ResourceWarning: unclosed running multiprocessing pool'
<ginggs> I'm seeing the same now in python-xarray autopkgtest, where it passed previously
<ginggs> s/the same/very similar/
<mwhudson> ah i was just wondering what the secret to getting the python-xarray autopkgtest to pass was
<mwhudson> ah ah 0.14.1 is out now
<ginggs> mwhudson: well this works https://launchpad.net/~ginggs/+archive/ubuntu/testing/+sourcepub/10752226/+listing-archive-extra
<ginggs> but i'm wondering where the problem came from (it wasn't present when I sync'd) and now pyfftw has something similar
<mwhudson> ginggs: hmm but i see failures of a different sort with the test triggered by numpy
<mwhudson> (and the numpy change is trivial and can't possibly have broken xarray)
<mwhudson> maybe that needs the pandas from proposed
<ginggs> mwhudson: see http://autopkgtest.ubuntu.com/packages/p/python-xarray/focal/amd64 - the 2019-11-21 18:04:49 UTC test was with all-proposed
<ginggs> from what i can see, all tests passed, but autopkgtest failed due to stderr output
<mwhudson> ginggs: ah!
<mwhudson> ok
<mwhudson> gosh this is all such a mess
<mwhudson> maybe we can make one big python data science package :(
<ginggs> and then RM it?
<mwhudson> ha
<mwhudson> well at least we'll stop building and testing them on x87 soon
<ginggs> \o/
<mwhudson> hmm maybe its dask that's using multiprocessing?
<mwhudson> does pyfftw use dask?
<mwhudson> oorrrrrrrrr maybe this warning is new in python 3.8
<mwhudson> ding ding ding we have a winner
<ginggs> pyfftw does use dask, or at least can replace dask's fft
<mwhudson> yeah i see the string "dask" in the build log
<ginggs> mwhudson: i need to sleep, have a good day!
<mwhudson> ginggs: i think given that the warning is new in python 3.8, changing the autopkgtests to allow-stderr is probably ok
<mwhudson> ginggs: good night!
<ginggs> mwhudson: i can upload that quick
<mwhudson> ginggs: +1
<ginggs> ok, done
<mwhudson> uh pandas has a breaks: on skbio but skbio thinks the problem is ok with new scipy which ubuntu has (but debian does not)
<mwhudson> this calls for more coffee
<mwhudson> hm is there a ppa with gcc 6 (or newer) for xenial?
<mwhudson> ah https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test
#ubuntu-devel 2019-11-22
<teward> i think i discovered an evil in the tar package in Bionic, in that later gitbuildpackage pristine-tar generated items with Tar 1.30+ fail to work with < 1.30
<teward> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897653 is the relevant report in Debian, just hit this for something that the STudio team is working on
<ubottu> Debian bug 897653 in tar "tar 1.30 breaks pristine-tar" [Grave,Fixed]
<Unit193> I have 1.30+dfsg-5, it would seem.
<cjwatson_> From that bug it looks more like we need to upgrade pristine-tar a bit (>=1.44 maybe?)
<cjwatson_> Oh also tar 1.30 isn't in bionic I see
<bryce> we ran into that tar / pristine-tar incompatibility too
<bryce> our packages set up with pristine tar on eoan couldn't be built on bionic
<xnox> ginggs:  it's not just the resourcewarnings, which are harmless there are really test case failures with 3.7 and 3.8 too, which appear to be triggered with a rebuild.
<xnox> ginggs:  note that autopkgtest, with patched testsuite against previous build passed locally for me =)
<xnox> ginggs:  it's all forwarded upstream, opened an issue and a pull request with CI changes to show the issue.
<xnox> mwhudson:  pyfffffffffftw does use dask
<ginggs> xnox: thanks
<xnox> ginggs: mwhudson: i'm not sure, but dask might be passing under python3.8 but not under python3.7
<ginggs> Testing with python3.8
<ginggs> = 6312 passed, 395 skipped, 32 xfailed, 4 xpassed, 20 warnings in 810.41 seconds =
<ginggs> Testing with python3.7
<ginggs> = 6317 passed, 390 skipped, 32 xfailed, 4 xpassed, 20 warnings in 855.78 seconds =
<xnox> hm
<xnox> so no failed with either?!
<ginggs> looks that way, but this is dask itself
 * xnox just read "Error: Quosures can only be unquoted within a quasiquotation context." in the autopkgtest of r-cran-sf and I think I need more coffee. This is worse than ruby's twiddle-wakka and python's walrus operators
<xnox> ah
 * xnox was in pyfftw contex
 * xnox was in pyfftw context
<xnox> nah, pyfftw really fails with python3.8
<ginggs> xnox: did you see pyfftw armhf fails in other exciting ways? probably #917095
<xnox> ginggs:  lovely
<mdeslaur> tseliot_: hi! I'm looking at bug 1852315...it seems those three CVEs are for the vGPU software...is that actually packaged in our driver packages? is it the same thing?
<ubottu> bug 1852315 in nvidia-graphics-drivers-435 (Ubuntu Eoan) "CVEâ2019â5696 5697 5698" [Undecided,New] https://launchpad.net/bugs/1852315
<teward> can anyone assist the Studio team with an oddness?  They've got a lintian ERROR which triggers a fail on an unsafe symlink which they've tried to adjust/patch the change in here in their repository, but dpkg-source barfs.  They are trying to change a symlink's target by editing a symlink, not sure if there's a workaround for that.  As such, however, I can't sign/build/upload the code that Eickmeyer wants uploaded (raysession).
<teward> if anyone has a few moments to poke and see if they can eve do their symlink patch fix, that'd be great.  https://code.launchpad.net/raysession is where the code is, everything's in master (and you can get the pristine-tar for 0.8.1 but you'll need tar >= 1.30 to make it work)
<teward> cjwatson: if we backport 1.30 into Bionic it'd work, I think.  I did this backport from Eoan in a PPA and made it work for pristine-tar in Bionic.  So the issue is the tar package :P  (wrt the tar version and pristine-tar)
<teward> i'm still working on the whole Backports thing with Laney but that's a task for 2020 at this point - helping Studio during dev cycle's taking a bunch of my cycles.  Also working with a few clients as a consultant on things :P
<cjwatson> raysession could fix up the symlink in debian/rules build and restore it to the as-in-orig-tarball state in debian/rules clean.  That's the usual workaround for this sort of thing.
<teward> Eickmeyer: ^
<cjwatson> Or even just put the right thing in place after the upstream 'make install' or equivalent runs, depending on whether it's used during build.
<cjwatson> In fact in that case you could just use dh_link to do it.
<cjwatson> Haven't looked at this package in any detail, but that's the general range of options available.
<Eickmeyer> cjwatson, teward: Thanks. Honestly, not sure how to do that. Do I make a debian/raysession.links and use dh_install_override to remove the bad link?
<cjwatson> dh_link removes anything that's already there all by itself
<Eickmeyer> cjwatson: Ok, excellent. I'll go that route then. Thanks!
<cjwatson> np
<teward> thanks cjwatson
<teward> as for the pristine-tar issue the issue DOES trace back to `tar` unless we need to patch gbp / pristine-tar, but simply backporting tar seemed to fix my issues.
#ubuntu-devel 2019-11-24
<jarnos> I want to build a source package for my ppa, but debuild -S fails, because there is no secret key for the email I gave in changelog. How to add such a key?
<jarnos> Can I use the ssh key I have given in my Launchpad profile.
<cjwatson> debuild/debsign requires a gpg key, not an ssh key
<cjwatson> https://help.launchpad.net/YourAccount/ImportingYourPGPKey
<cjwatson> (includes advice on creating gpg keys too)
<mwhudson> omg pandas migrated
<jarnos> cjwatson, as for the Launchpade help page, I don't know which is the Passwords and Encryption Keys tool, but I have seahorse installed and that has somewhat different kind of UI.
<jarnos> cjwatson, this seems to be an old issue https://askubuntu.com/q/161595/21005
<jarnos> cjwatson, so I created a PGP key pair using seahorse. I am using Xubuntu 18.04. The hkp://keyserver.ubuntu.com has not been added there, but there are couple of other. Should I use that "Hockeypuck" server for Launchpad? Is that a HTTP key server or should I use Custom type?
<jarnos> There I have to choose a port, too.
<jarnos> cjwatson, Also the output of gpg --list-keys has changed so that the page is out of date.
<cjwatson> jarnos: Sending your key to the hockeypuck server at keyserver.ubuntu.com is correct.  As far as I know seahorse is the same as the Passwords and Encryption Keys tool, but different desktop environments may call it something slightly different and I expect there are some variations in its UI between desktop environments and versions.
<cjwatson> jarnos: gpg --list-keys will differ in some aspects, but nothing particularly important.
<jarnos> cjwatson, the key id is not shown, but fingerprint on a separate line. But that can be used as the argument for --send-keys.
<cjwatson> Sounds like you've worked it out
<jarnos> cjwatson, yes. I uploaded the package by default method; if I set sftp there was an error when running dput: paramiko must be installed to use sftp transport. It was too complicated, but I guess the default method will do.
