[00:00] <crimsun> mateusz: you'll probably find https://wiki.ubuntu.com/KernelMaintenance#head-ef6ca858b4b97c1ad30639e34d92abb11ef37cf8 useful, but I recommend you inspect updating it for a hardy SAUCE one.
[00:00] <crimsun> inspect->consider working on
[00:03] <mateusz> crimsun: I am not using hardy
[00:04] <crimsun> mateusz: that's fine; I merely mentioned consider benefitting others.
[00:05] <mateusz> crimsun: there must be a reason why this patch is from 2006 now in mainline of kernel
[00:06] <mateusz> no in mainline
[00:31] <mateusz> crimsun: is ubuntu 2.6.22 kernel modifed ?
[00:31] <mateusz> crimsun: I thought the sources are vanilla
[00:31] <mateusz> so it should be possible to applay patch on 2.6.22.9
[00:32] <crimsun> mateusz: yes, the Ubuntu kernels are modified.
[00:32] <mateusz> quilt or dpatch ?
[00:32] <mjg59> No
[00:32] <crimsun> mateusz: git.  https://kernel.ubuntu.com
[00:32] <mateusz> heh.. but the tar.bz shouldnt be modified
[00:33] <mateusz> then how am I suppose to applay patch which only applays on vanilla while preserving all ubuntu patches ?
[00:34] <mjg59> If it only applies to vanilla, then the Ubuntu patches would be unlikely to apply after you applied it
[00:49] <mateusz> mjg59: if I want to make a patch for current ubuntu kernel
[00:49] <mateusz> mjg59: what I should do?
[00:49] <mateusz> mjg59: for the 2.6.22-14 I guess this one is in gutsy
[00:50] <mjg59> Grab the kernel source, and generate a patch against it
[00:50] <mateusz> from git?
[00:50] <mateusz> or from source package /
[00:50] <mjg59> If you don't want it to go to the main distribution, then just apt-get the source
[00:51] <mateusz> No, I want it to go to main dist
[00:52] <mjg59> Then the best way is to pull the git tree, make your change, commit it and then publish your git tree
[00:52] <mjg59> Then you can ask kernel-team@ubuntu.com to pull from your tree - best way is to file a bug report and mention that in the pull request
[00:52] <mjg59> But only critical bug fixes are likely to be applied against the gutsy tree
[00:53] <mateusz> this is serious bug
[00:53] <mateusz> as there are packages in gutsy
[00:53] <mateusz> which need that patch
[00:53] <mateusz> they're useless
[00:54] <mateusz> and its very misleading
[00:55] <mateusz> mjg59: is it possible to use hardy as desktop?
[06:58] <pitti> Good morning
[06:59] <dholbach> good morning
[08:06] <warp10> Good morning!
[08:07] <pitti> hi warp10
[08:08] <warp10> pitti: :)
[09:04] <pitti> does anyone know a good shell pendant of wait(..., NOWAIT), i. e. checking if a backgrounded process finished? "jobs | grep Done" smells too much like a hack to me
[09:04] <seb128> hey pitti
[09:04]  * pitti hugs seb128
[09:04]  * seb128 hugs pitti
[09:07] <soren> pitti: test -d /proc/$pid ?
[09:08] <soren> or
[09:08] <soren> ps -p $pid > /dev/null
[09:10] <pitti> soren: hm, that could work; so I just need to convert the jobspec (%1) to a pid
[09:11] <pitti> jobs -l
[09:11]  * pitti notices that jobs -s and -r options don't actually work
[09:12] <persia> jobs -r works for me
[09:12] <pitti> -r shows "done", and -s shows "Running" ones for me
[09:13] <pitti> heh, maybe I should just trap SIGCHLD
[09:14] <soren> pitti: Can't you just grab the pid when you just started it?
[09:14] <soren> From $!..
[09:15] <pitti> oh, handy
[09:15] <soren> Very :)
[09:15] <pitti> (that's not in man dash)
[09:15] <soren> Sure it is.
[09:15] <pitti> nor in man bash
[09:15] <soren> In the "Special parameters" section.
[09:16] <soren> !            Expands to the process ID of the most recent background command executed from the current shell.
[09:16] <soren> For a
[09:16] <soren>                   pipeline, the process ID is that of the last command in the pipeline.
[09:18] <lool> I do find these $.* expansions hard to grep for in the *sh man pages too  :)
[09:19] <soren> lool: I usually just grep for something like ! and then scroll up and down a bit :)
[09:23] <pitti> soren: ah, too bad; the process needs to be fg'ed/wait'ed on, otherwise it'll stay in ps output forever as Z
[09:23] <pitti> soren: (likewise, kill -0 keeps succeeding)
[09:23] <pitti> bah
[09:24] <pitti> oh, hm, now it works; odd
[09:24] <pitti> while kill -0 $!; do
[09:24] <pitti> ok, that seems to do the trick
[09:26] <soren> dash has a "wait" builtin.
[09:26] <soren> AFAIR
[09:26] <pitti> right, but that blocks
[09:26] <soren> point
[09:26] <pitti> I want to move fsck into the background, update usplash in teh foreground
[10:21] <soren> When is the source changes file supposed to contain the Description field?
[10:21] <soren> I see that it changed with my new dpkg merge and I'm wondering if I bollocksed it up somehow.
[10:22] <pitti> that's news to me, too
[10:22] <soren>   * Some code refactoring on dpkg-genchanges and bug fixes in the generation
[10:22] <soren>     of the Description: field. As a result, source only uploads will no more
[10:22] <soren>     have Description fields.
[10:22] <soren> That explains it :)
[10:22] <soren> Ok, so I didn't break it. \o/
[10:23] <thegodfather> soren: did you complete the libvirt transition now?
[10:23] <pitti> well, I guess few, if any, people actually want to read that
[10:23] <thegodfather> (vs libxen)
[10:23] <soren> thegodfather: I belive I did so on Friday.
[10:24] <thegodfather> soren: ok thanks
[10:25] <soren> :)
[10:25]  * thegodfather prepares a new cluster upload
[10:25] <soren> Yay!
[10:26]  * soren taps his fingers waiting for the clock to hit 11:29 so that he can get shiny, new, working server install iso's. Whee!
[10:28] <pochu> soren: the gtk-vnc patch is used by your virt-* combo keys stuff, am I right? I'm wondering whether it makes sense to forward the patch to the Debian maintainer, but I thought it would only make sense if the virt-* maintainers were going to use it. But as he maintains virt-viewer I think I'll forward it to him and let him decide if he wants it or not
[10:29] <soren> pochu: No, they're entirely separate.
[10:30] <soren> pochu: The patch enables an extension to the VNC protocol that sends key codes rather than keysyms over the wire. This alleviates practially all problems you might encounter if you're not using US keymapping everywhere.
[10:30] <soren> pochu: The combo keys stuff is just a one-liner. (assuming we're talking about the same combo keys stuff)
[10:41] <Riddell> pitti: can you move the feisty and gutsy packages of bug 184149 to -updates sometime?  they've been verified by sru-verification
[10:41] <ubotu> Launchpad bug 184149 in kdelibs "[hardy]xembed and flash support patches doesn't work for konqueror" [Undecided,Fix committed] https://launchpad.net/bugs/184149
[10:42] <pitti> Riddell: yes
[10:44] <lool> soren: I saw this in a cl when updating: http://paste.ubuntu.com/4426/ perhaps it's worth cherrypicking the dpkg-gensymbols changes?
[10:46] <pitti> Riddell: done; doing kitchensync now, too
[10:49] <Riddell> thanks
[10:50] <soren> lool: dpkg 1.14.16.6ubuntu1 will be uploaded later today.
[10:51] <eradicus>  /j #ubuntu-kernel
[10:51] <eradicus> oops
[10:52] <lool> soren: Excellent; thanks!
[11:33] <tkamppeter> hi pitti
[11:35] <pitti> hi tkamppeter
[11:57] <tkamppeter> pitti, have you seen my mails about the Brother driver packages?
[11:58] <pitti> tkamppeter: yes, and answered one which was incomplete; your review was good otherwise
[11:59] <slytherin> elmo: lamont: Is it possible preseed the debconf question for j2sdk package on buildd. batik has an FTBFS currently and uses j2sdk as build dependency.
[12:05] <tkamppeter> pitti, your answer did not arrive in my mailbox, did you send it only to Jeremy?
[12:06] <pitti> tkamppeter: no, To: was you, and CC: was Jeremy and Saïvann
[12:10] <tkamppeter> It really did not arrive at me, I even looked into my spam folders.
[12:11] <pitti> tkamppeter: let me boot my notebook and check if it's stuck in its local MTA
[12:21] <pitti> oh, argh
[12:21] <pitti> there are 24 mails stuck in the local MTA, sorry
[12:23] <pitti> ok, flushed
[12:24] <pitti> tkamppeter: you should get it any second now
[12:28] <tkamppeter> pitti, I got them now. Thanks.
[12:29] <pitti> tkamppeter: thanks for poking me about this; I now added a 'stuck MTA' check into my .bashrc :)
[12:30] <Hobbsee> pitti: like the mega killall gnome script?
[12:30] <pitti> much less intimidating :)
[12:30] <Hobbsee> awww
[12:30] <pitti> mailq | grep -v 'is empty'
[12:30]  * Hobbsee wonders what else pitti has
[12:38] <slytherin> pitti: Sorry I couldn't be available on weekend for testing jockey. Have you created handler for broadcom?
[12:39] <pitti> slytherin: yes, and tested by TheMuso; I uploaded it to Hardy this morning (2ubuntu3), so maybe you can test that version in the archive?
[12:39] <slytherin> pitti: Ok. I will do it tomorrow probably
[12:39] <pitti> slytherin: great, thanks
[13:03] <geser> pitti: please give back: gutsy-wallpapers feisty-gdm-themes. They failed to upload due to main -> universe demotion. Thanks.
[13:05] <Hobbsee> geser: (done)
[13:06] <geser> Hobbsee: thanks
[13:58] <DarkSun88> Hi all
[14:09] <Mithrandir> pitti: why is it the ConsoleKit dbus policy allows root to send to "org.freedesktop.ConsoleKit.Manager" with a member of "OpenConsoleWithParameters", but disallows others to use the member "OpenSessionWithParameters"?  (Note different member parameter)
[14:10] <pitti> re
[14:10] <seb128> StevenK: could you update bluez-utils to 3
[14:10] <seb128> 3.26?
[14:10] <pitti> geser: done
[14:10] <Hobbsee> seb128: (he'll probably be asleep by now)
[14:10] <Mithrandir> seb128: any interesting changes or just because it has a higher version number?
[14:10] <pitti> Mithrandir: hm, good question; might be a typo
[14:10] <seb128> Mithrandir: the new gnome-bluetooth requires the new version
[14:10] <Mithrandir> seb128: ok
[14:11] <seb128> Mithrandir: I'm pinging StevenK because he did the previous update, if you want to do it you are welcome ;-)
[14:12] <Mithrandir> pitti: yes, that was what I was wondering.  And I'm wondering how I'm going to write something that is to CK like how seahorse, gpg-agent, ssh-agent and friends are to their programs.
[14:12] <Mithrandir> seb128: yeah, pondering it, to take my brain away from being fried on OverdoseKit.
[14:13] <pitti> Mithrandir: I'll file a bug upstream and see what they say
[14:13] <Mithrandir> pitti: coolie
[14:17] <pitti> Mithrandir: freedesktop bug 14459; I checked that it's still like that in git head
[14:17] <ubotu> Freedesktop bug 14459 in Daemon "Typo in dbus.conf: OpenConsoleWithParameters()" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=14459
[14:17] <pitti> Mithrandir: thanks for pointing out
[14:18] <Mithrandir> pitti: happy to help.
[14:24] <zul> pitti: when you get a chance can you look at the vblade MIR again.
[14:27] <pitti> zul, soren: dnsmasq? why can't kvm etc. use our standard dhcp3-server?
[14:27] <pitti> in hardy we try to *reduce* duplication, not introduce more of it :/
[14:31] <pitti> zul: vlade> ack
[14:31] <zul> pitti: thanks
[14:39] <mateusz> Is Ubuntu kernel patched with hdaps_protect ?
[14:41] <Ko_deZ> Hi all
[14:41] <Ko_deZ> I am playing with pbuilder, and having some problems
[14:42] <Ko_deZ> I am trying to compile the latest dvb-apps (linuxtv project), and it fails.
[14:42] <Ko_deZ> http://pastebin.com/d1a7bb138
[14:43] <Ko_deZ> actually it fails when compiling on my local system as well.
[14:43] <soren> pitti: Because dnsmasq is small and lovely unlike that other thing.
[14:43] <Ko_deZ> Could anyone give me a hint on what makes this error appear?
[14:44] <Ko_deZ> I am running kubuntu 7.10
[14:44] <pitti> soren: but we have used and supported dhcp3-server for years, and suddenly pulling in another one sounds bad both maintenance and support-wise
[14:46] <soren> pitti: The alternative is to maintain weird, ugly patches to stuff like libvirt.
[14:47] <Riddell> Ko_deZ: talk to upstream
[14:47] <pitti> soren: to change the called command from dnsmasq to dhcp3d?
[14:47] <soren> pitti: You realise they're not cli compatible?
[14:48] <pitti> sure
[14:48] <soren> pitti: ...and that dnsmasq also provides dns.
[14:48] <cjwatson> mateusz: #ubuntu-kernel would be more effctive
[14:48] <cjwatson> effective
[14:48] <soren> pitti: and is made for this particular scenario..
[14:49] <pitti> soren: why not have the dhcp server just pass the host nameserver?
[14:49] <pitti> soren: can you please list some reasons in the MIR?
[14:49] <Ko_deZ> Riddell: I have been trying to get help on their irc channel for a while. No luck. I was hoping someone could tell me if there is a dev or header file I need to install for this.
[14:50] <pitti> TBH, we have enough bugs on dhcp3, we don't really need more from dnsmasq
[14:50] <pitti> and we should check this with the support team, too
[14:50] <pitti> soren: I perfectly see the rationale for dnsmasq on an embedded system like openwrt
[14:51]  * soren is on the phone
[14:51] <pitti> but on a server which is beefy enough to run kvm it hardly matters
[14:51] <soren> Gimme 5 minutes.
[14:51] <pitti> soren: ah; no problem, take your time :)
[14:51] <pitti> (random note: just got a wrt54 on the weekend, with openwrt; nice toy!)
[14:53] <Mithrandir> there, new bluez-{libs,utils} uploaded.
[14:54]  * seb128 hugs Mithrandir
[14:54] <seb128> Mithrandir: thanks
[14:54] <seb128> crevette: ^
[15:10] <Riddell> evand: tm_t has been talking to you about windows profile for qt ubiquity?
[15:11] <evand> Riddell: indeed, in the middle of a conversation with him now about it
[15:11] <evand> I'm unfamiliar with COSS.fi though.
[15:12] <Riddell> evand: if he gets it are you happy to answer his questions about the debconf side?
[15:13] <tjaalton> coss.fi is an organization promoting the use of open-source software in Finland
[15:13] <evand> Riddell: yeah, I basically said the important bit is the core migration-assistant C code.  Things outside of that, like the ubiquity GUI bits are either bonus, or can be learned along the way (Debian policy, debconf, if needed at all)
[15:14] <Riddell> evand: surely it's not much use without a GUI?
[15:16] <soren> pitti: I've added a bit of info to https://wiki.ubuntu.com/MainInclusionDnsMasq
[15:16] <evand> well no, it's not.  But my point was that the GUI is a small aspect of the code nowadays.  It's just a matter of updating the KDE ubiquity UI to match the GTK side.
[15:17] <evand> Riddell: ^
[15:17] <Riddell> evand: ok, thanks
[15:17] <evand> But it's a just a treeview with the GTK set/get code already there, so it should be a simple port.
[15:18] <pitti> soren: why do we need bind for kvm in the first place?
[15:19] <selckin> soren: debian maintance link 404's
[15:19] <pitti> soren: and our libc already DTRT for resolv.conf changes
[15:19] <soren> pitti: It's for libvirt. Does it say kvm?
[15:19] <soren> That's a mistake.
[15:19] <pitti> well, yeah, libvirt
[15:20] <soren> pitti: Why? Er.. Becuase I'm running virtual machines in it that would like to lookup stuff in dns?
[15:20] <soren> pitti: libc does not come into play at all.
[15:20] <soren> pitti: er.. for dns lookups at least.
[15:20] <soren> pitti: And we don't need bind. We need dnsmasq :)
[15:21] <pitti> my question is, why do we need a nameserver at all?
[15:21] <soren> ..
[15:21] <pitti> the guests can just use the host's nameserver (that works fine for me at least)
[15:21] <soren> Tons of reasons.
[15:21] <soren> a) the host's dns might change.
[15:21] <soren> b) you might move your vm to another host.
[15:22] <pitti> ^ good reason
[15:25] <soren> selckin: Fixed. Thansk.
[15:25] <soren> alias Thansk=Thanks
[15:25] <soren> ah..
[16:04] <dholbach> can somebody moderate my ubuntu-devel-announce mail?
[16:05] <dholbach> mvo: your stuff in OpenSUSE and Slackware: http://blogs.warwick.ac.uk/bweber/entry/untitled_entry_1/ - http://www.fredemmott.co.uk/blog_133
[16:18] <mvo> dholbach: meh, cool!
[16:18] <seb128> mvo: what is cool?
[16:19] <mvo> seb128: command-not-found seems to become popular in other distros as well
[16:19] <seb128> ah, nice
[16:19] <seb128> mvo: what distro is using it now?
[16:20] <dholbach> seb128: opensuse and slackware
[16:21] <seb128> slackware has a packaging system now? ;-)
[16:23] <mvo> heh :)
[16:35] <asac> soren: avail?
[16:35] <soren> asac: Wazzup?
[16:36] <asac> soren: lol :) ... what do you think about nm vpn plugins going to main?
[16:37] <asac> soren: i assume you know better how well upstream deals with security updates and how much they care about stable branch maintenance
[16:38] <asac> soren: and maybe you know about any blocker that might lead to a bad user experience
[16:38] <soren> asac: I'm afraid noone gives much attention to the vpn plugins.
[16:38] <soren> asac: Last I checked, they never even had a proper release. I've always just grabbed a random svn checkout.
[16:39] <asac> ok. i think that would be enough of a blocker to disqualify them from entering main :/
[16:39] <asac> who maintains them upstream? is it the same team that does NM ?
[16:40] <soren> asac: I'm not sure to be honest. I'd ask on the mailing list if I were you.
[16:40] <asac> soren: ok ... do you speak for all vpn plugins or just the vpnc one?
[16:40] <soren> I haven't looked into them for over a year and even then I mostly just did the packaging and wrote a few small patches.
[16:41] <asac> ok thanks
[16:41] <soren> asac: vpnc and openvpn, but I have the feeling it's true for all three (or four if the ipsec one was ever finished).
[16:41] <soren> ...things might have changed over the last year, but I haven't seen much activity about them on the nm mailing list.
[16:42] <asac> yeah
[16:43] <soren> I think the functionality is really cool, but I'm afraid this is one of the times where the lack of activity can't be excused by "if it works, don't fix it" :)
[16:44] <asac> right ... there are definitly a few bugs that might justify some activity
[16:44] <soren> Quite so.
[17:12] <DarkSun88> Hi all
[17:22] <wasabi> So... the 'kvm' module keeps loading... even though I have it black listed... and it's incompatible with vmware (causes system to crash). Why might the blacklist be ignored in this case?
[17:46] <pitti> Mithrandir: got a response from CK upstream; so it's really s/Console/System/ in the dbus conf
[18:17] <TeXnicer> Moin!
[18:17] <TeXnicer> Is this english?
[18:18] <TeXnicer> Nihongo? Farsi? Francais? Neederlaans?
[18:19] <_MMA_> TeXnicer: DO you want to know the language of the channel? If so, its English.
[18:19] <thom> english
[18:19] <TeXnicer> Rgr. Thx.
[18:20] <TeXnicer> Well, this IS a support question, while I was redirected from #ubuntu-de -> #debian-de -> #ubuntu-devel... looking for help concerning my Harddiskdrive
[18:20] <mjg59> TeXnicer: Then I'm afraid this isn't the right place to ask
[18:20] <TeXnicer> 2.5" Toshiba 6GB rather old, was accessed well under 6.10, since 7.10 I get bad bootmessages
[18:21] <TeXnicer> like in pata and /grub/menu.lst   ... any clue -- or at least where to look?
[18:22] <TeXnicer> mjg59: Where might be the right place to ask or lookup?
[18:23] <TeXnicer> BTW: Where can I push forward the translation-programm (german)?
[18:24] <_MMA_> TeXnicer: #ubuntu #ubuntu-forums or the Ubuntu Forums themselves.
[18:24] <_MMA_> Sorry, #ubuntuforums
[18:24] <TeXnicer> mma just got forwarded? LOL
[18:24] <TeXnicer> ubuntu-forums
[18:26] <TeXnicer> Thx! Go ahead! Keep it on, folks... I thank you for such an nice distri!
[18:26] <_MMA_> TeXnicer: I'm gonna say bad hardware or something to do with the libata transition. Anymore than that, I would say look into the places above.
[18:30] <TeXnicer> hardware seems to be okay under 6.10
[18:30] <TeXnicer> i try in -forums now, thx&bye!
[19:21] <bSON> hi
[19:21] <bSON> (05:31:11 PM) denisw: where does apport save the apps for which it shouldn't show any bug reporting dialogs for?
[19:21] <bSON> oops, yeah the question is copy-pasted here ;)
[20:28] <geser> pitti: it looks like pkg-create-dbgsym got broken, all builds fail with "dpkg-gencontrol: failure: cannot read -: No such file or directory
[20:28] <geser> Error: parsed ddeb section or priority is empty
[20:28] <geser> make: *** [binary-arch] Error 1"
[20:29] <geser> e.g. http://launchpadlibrarian.net/11875738/buildlog_ubuntu-hardy-amd64.netpbm-free_2%3A10.0-11.1_FAILEDTOBUILD.txt.gz
[20:33] <seb128> are the LANG and LANGUAGE formats described somewhere?
[20:34] <slangasek> ebman 7 locale?
[20:34] <slangasek> seb128: man 7 locale?
[20:43] <seb128> slangasek: no LANG or LANGUAGE there on my hardy
[20:43] <seb128> ups
[20:43] <seb128> no, no description or what they contain
[20:43] <slangasek> hmm, ok
[20:43] <seb128> slangasek: the issue is
[20:44] <seb128> $ cat /etc/default/locale
[20:44] <seb128> LANG="fr_FR.UTF-8"
[20:44] <seb128> LANGUAGE="fr_FR:fr:en_GB:en"
[20:44] <seb128> or gdm use LANGUAGE
[20:44] <seb128> and complains about fr_FR not being a valid locale
[20:44] <seb128> which is right
[20:44] <slangasek> hmm
[20:44] <seb128> and I'm not sure on whether gdm is wrong to expect locales there or if LANGUAGE should be fr_FR.UTF-8:en_GB.UTF-8:etc
[20:44] <slangasek> LANGUAGE isn't supposed to be a list of locales, but a list of languages
[20:45] <slangasek> but it's a GNU extension, I don't know where it's documented
[20:45] <seb128> is that written somewhere?
[20:45] <seb128> hum, k
[21:02] <geser> soren: the new dpkg seems to cause many FTBFS on the buildds
[21:03] <LaserJock> pitti: any ETA on when the gutsy lang packs in PPA will make it to -updates?
[21:06] <slangasek> geser: how do you know it's the new dpkg?  the new dpkg was uploaded some time ago, was it not installed on the buildds until now?
[21:09] <seb128> slangasek: the build log he pointed before has the new dpkg installed
[21:10] <seb128> slangasek: and looks like a pkg-create-dbgsym issue, likely created by the dpkg changes
[21:10] <slangasek> seb128: but so does an older, successful build log from earlier
[21:11] <slangasek> er, oh
[21:11] <slangasek> no, now I see the new dpkg, n/m :)
[21:13] <geser> slangasek: dpkg 1.14.16ubuntu1 got uploaded 3 hours ago
[21:16] <geser> slangasek: http://launchpadlibrarian.net/11876179/buildlog_ubuntu-hardy-amd64.scrapbook_1.3.2.5-2ubuntu1_FAILEDTOBUILD.txt.gz might be the same problem but here the package build on i386
[21:31] <slangasek> geser: yes, I was evidently looking at stale archive state and thought dpkg was last uploaded mid-January
[21:53] <soren> Argh, fuck.
[21:53] <soren> slangasek: Got a plan?
[21:54] <soren> slangasek: Any idea what the problem is?
[21:54] <slangasek> soren: no clue at this point
[21:54] <seb128> soren: perfect timing, just when the new GNOME is being uploaded ;-)
[21:54] <slangasek> I was hoping you had a better idea, since you'd done the merge ;)
[21:55] <soren> slangasek: No, I'll look into it right away.
[21:55] <torkel> seb128: re LANGUAGE see http://www.gnu.org/software/libc/manual/html_node/Locale-Categories.html#Locale-Categories
[21:56] <soren> slangasek: Does everything fail?
[21:56] <slangasek> soren: pkg-create-dbgsyms seems to be failing rather consistently, but I haven't verified whether there are cases where it succeeds (I'm not sure how to go about looking those up)
[21:57] <soren> slangasek: Me neither.
[21:57] <soren> No, some things work.
[21:58] <soren> I'm looking at a pure arch:all package that built just fine.
[21:58] <soren> http://launchpadlibrarian.net/11876766/buildlog_ubuntu-hardy-i386.kqemu_1.3.0%7Epre11-8_FULLYBUILT.txt.gz
[21:58] <slangasek> a pure arch: all package shouldn't have pkg-create-dbgsyms try to do anything significant though :)
[22:00] <soren> If I don't have pkg-craete-dbgsyms locally everything works, yes.
[22:00] <soren> That explains why I didn't see it while testing.
[22:02] <geser> soren: http://launchpadlibrarian.net/11875714/buildlog_ubuntu-hardy-amd64.flex_2.5.34-2.1_FULLYBUILT.txt.gz has some interesting warnings: "Use of uninitialized value in hash element at /usr/bin/dpkg-genchanges line 468."
[22:04] <seb128> torkel: thanks
[22:04] <soren> geser: Erk, yes, that doesn't look too well.
[22:05] <slangasek> soren: I guess it's dpkg-gencontrol that's failing, right? there are a number of changes to that file in the merge; how does pkg-create-dbgsyms invoke it?
[22:05] <soren> slangasek: I'm trying to figure that out.
[22:05] <slangasek> ok :)
[22:07] <soren> The only changes I made to dpkg-genchanges are about Launchad-Bugs-Fixed magic.
[22:07] <soren> At least that was the intent.
[22:07] <soren> :)
[22:07] <geser> soren: but this warning exist also in http://launchpadlibrarian.net/11869736/buildlog_ubuntu-hardy-amd64.apt_0.7.9ubuntu9_FULLYBUILT.txt.gz which still used the old dpkg, so nothing new
[22:08] <soren> geser: Lovely, thanks for looking that up! That's likely to have saved me quite a bit of head ache :)
[22:08] <slangasek> soren: right; it's dpkg 1.14.16.6 that has the sweeping changes to dpkg-gencontrol
[22:08] <soren> pitti: around?
[22:11]  * soren boggles at the fact that there's logic in pkg-create-dbgsym for debhelper compat level 1
[22:12] <soren> Ah... I've got a good guess as to what's going on..
[22:17] <soren> Er...
[22:17] <soren> I'm no perl guru, but isn't the third argumennt to open supposed to be the flags?
[22:17] <soren> From the new dpkg: open(CDATA, "<", $file)
[22:17] <soren> Kaboom!
[22:18] <soren> The old dpkg:
[22:18] <soren>     open(CDATA, "< $controlfile") ||
[22:20] <blueyed> soren: maybe open(CDATA, "<".$file) was intended (but no perl guru either)
[22:21] <soren> That would probably work, too. I've change it to "< $file".
[22:21] <slangasek> soren: that appears to be legal use of perl open(), but if you want to use the magic '-' value for stdin or stdout it apparently doesn't work so well
[22:21] <slangasek> "In the 2-arguments (and 1-argument) form opening ’-’ opens STDIN and opening '>-' opens STDOUT." perlfunc(1)
[22:22] <slangasek> and if you use the comma, you obviously aren't using the 2-argument form, so. :)
[22:22] <soren> slangasek: How do we fix this?
[22:22] <slangasek> soren: I think the fix you just described would be correct
[22:22] <soren> slangasek: If I just upload the new one, it'll fail to build.
[22:22] <slangasek> will it? are there dbgsym packages built from dpkg?
[22:22] <soren> Sure.
[22:23] <soren> Only dpkg-dev is arch:all.
[22:23] <slangasek> well, upload the fix all the same, and then we can beg a manual bootstrapping from a buildd admin
[22:23] <geser> I've tested the new dpkg-dev with the old /usr/bin/dpkg-genchanges but still the same error
[22:23] <soren> geser: YEs, it's in $PERL/Dpkg/Control.pm
[22:23] <soren> slangasek: Yeah.
[22:23] <soren> lamont: Around?
[22:23] <lamont> yeah
[22:24] <lamont> in this channel anyway. :-)
[22:24] <soren> Are you following this, or should I fill you in?
[22:24] <lamont> soren: --> infinity
[22:24] <soren> Alright.
[22:24] <soren> infinity: Are you following this?
[22:25] <soren> infinity: New dpkg broke the world. A new upload of dpkg will just ftbfs, so I need manual intervention.
[22:26] <geser> soren: iirc there is an option to disable the package mangling, or will it failed for other reasons?
[22:27] <soren> NO_PKG_MANGE will certainly fix it.
[22:28] <soren> NO_PKG_MANGLE, even.
[22:28] <soren> slangasek: What do you think? Upload a fixed version with that, have it built and published, and the upload a new one without NO_PKG_MANGLE?
[22:31] <slangasek> soren: oh, sure, go for it
[22:31] <soren> Will do.
[22:34] <seb128> soren: right I would do that
[22:35] <soren> I'm on it.
[22:36] <soren> infinity: Never mind :)
[22:42]  * soren uploads
[22:42]  * seb128 hugs soren
[22:49] <soren> debian bug 465340
[22:49] <ubotu> Debian bug 465340 in dpkg "dpkg: Broken call to open in Dpkg/Control.pm" [Important,Open] http://bugs.debian.org/465340
[22:54] <soren> I hope "important" is an appropriate severity. I wasn't sure.
[22:58] <xivulon> TheMuso, re accessibility wanted to show current wubi dialog
[22:58] <TheMuso> xivulon: right
[22:59] <xivulon> this is the current version
[22:59] <xivulon> http://img123.imageshack.us/img123/4568/screenshotwubisetupld0.png
[22:59] <xivulon> but I am not too pleased with it
[22:59] <xivulon> as mentioned in the email, wouldn't it be better if the accessibility and mobility options were not mutually exclusive?
[23:00] <TheMuso> xivulon: I was actually going to reply to your email. Braille at this point should not be a check box, because on the live CD boot menu, it can not be used as such. It shoudl be a radio button like the rest.
[23:00] <xivulon> that would translate to all checkbox in the dialog (without "None" option)
[23:01] <TheMuso> xivulon: At the moment this is not possible, due to the way the live CD boot menu works, and I don't think they can be turned on and off in that menu. cjwatson, do you have any idea whether having the accessibility menu act like check boxes, instead of single selectable options only is possible?
[23:01] <TheMuso> And, for many of them, it doesn't make sense. One would either want one, or the other.
[23:01] <soren> Er.... I'm not getting an ACCEPT mail..
[23:04] <seb128> soren: maybe elmo did something again
[23:04] <xivulon> TheMuso, I am no expert, but I would expect that someone might want both visibility and keyboard-modifiers
[23:04] <xivulon> or magnifier + screen reader
[23:04] <seb128> soren: I didn't get accepted mail either for my gnome-desktop upload
[23:05] <soren> seb128: What did you do? Reupload?
[23:05] <TheMuso> xivulon: Yes, however the underlying code on the Linux side doesn't really support this properly yet, and its probably a little too late to go changing it for hardy, as its working quite well at the moment. However, this is certainly something we can look at doing for hardy+1.
[23:06] <seb128> soren: no, the gnome-desktop upload was from 15 minutes ago or so
[23:06] <soren> seb128: Oh, ok.
[23:06] <seb128> soren: but the uploads were not processed this morning neither, some people asked on IRC and elmo fixed it
[23:06] <soren> Hrm..
[23:06] <evand> TheMuso: cjwatson recently added checkbox support to isolinux, so yes, it is possible.
[23:06] <xivulon> casper-bottom can probably take multiple arguments not sure about gfx interface
[23:07] <soren> elmo: Around? It seems that soyuz might be failing to pick up uploads.. Rumour has it that you're the man to fix it.
[23:07] <TheMuso> evand: Ooo ok, I wonder how much work it is to change the a11y menu. If its not too difficult, I could easily hack on the code for casper to get it support such a configuration by thursday.
[23:07] <TheMuso> xivulon: Yes it can take multiple arguments, but its the code that processes those arguments and takes the appropriate action that needs to be changed.
[23:07] <evand> TheMuso: the casper code works with multiple a11y arguments alreayd.
[23:07] <evand> already*
[23:07] <TheMuso> evand: Are you sure?
[23:08] <evand> TheMuso: yes, it processes every /proc/cmdline option.
[23:09] <xivulon> can we the have boot parameters such as accessibility_v1 accessibility_m2 accessibility_braille
[23:09] <TheMuso> evand: I know that, but I am referring to the code withint eh individual cases. We'd need to be sure that one profile doesn't overwrite another's settings./
[23:09] <evand> TheMuso: ah, indeed
[23:10] <evand> xivulon: what's wrong with the way they're currently implemented?
[23:10] <TheMuso> evand: Heh I was the original author of that file back in 2006.
[23:10] <TheMuso> It has since undergone way too many changes to keep track of. :p
[23:11] <evand> TheMuso: heh, indeed :)
[23:11] <geser> soren: luckily today is not friday, usually such things are reserved for fridays
[23:12] <xivulon> evand, IIRC now it sets a single variable
[23:13]  * xivulon looking at code
[23:13] <xivulon> no it does not
[23:14] <evand> indeed, it should work fine as is
[23:14] <xivulon> current implementation is fine, other than the caveat from TheMuso
[23:14]  * TheMuso looks at the code again.
[23:14] <evand> indeed, I was just going to say
[23:14] <evand> TheMuso: be sure to look at the copy from bzr
[23:14] <TheMuso> evand: Yeah I saw your upload.
[23:14] <evand> I have changes in there that haven't made it to the archive yet
[23:14] <evand> ok
[23:14] <TheMuso> I just pulled the latest changes.
[23:14] <evand> fantastic
[23:15]  * TheMuso goes to scour the code now.
[23:16] <soren> Aw, shame on me for not passing proper -vstuff to dpkg-genchanges when merging dpkg.
[23:18] <TheMuso> evand: Any reason why you used orca-customizations.py, and not the standard user-settings.py file?
[23:20] <evand> TheMuso:
[23:20] <evand> whoops
[23:21] <evand> TheMuso: "Generated by orca. DO NOT EDIT THIS FILE!!!"
[23:21] <TheMuso> Fair enough.
[23:21] <evand> orca-customizations.py seems to be the proper place for such things
[23:22] <TheMuso> evand: It also seems that for the magnifier and braille profiles, you've enabled speech when speech is not needed.
[23:22] <TheMuso> s/needed/wanted/
[23:24] <elmo> seb128/soren: I broke soyuz temporarily while doing emergency maintenance for the kernel root exploit - I'm definitely not the go to guy everytime soyuz stops working
[23:25] <evand> TheMuso: I think I just did a simple sed, let me check though.
[23:25] <seb128> elmo: ok, sorry, I though you might have been working on the same thing that this morning
[23:25] <xivulon> better http://img405.imageshack.us/my.php?image=screenshotwubisetup1ka0.png
[23:25] <TheMuso> xivulon, evand. The only profile where things get overwritten/are shared between profiles but different settings, are the two motor disability profiles, i.e m1 and m2. I am also not sure as to whether the KDE/XFCE stuff overwrites itself for different profiles, but gconf wise, and orca wise, all other profiles do not break each other.
[23:26] <soren> elmo: Was that this morning or just now?
[23:26] <elmo> soren: this morning
[23:26] <xivulon> TheMuso in this case if both m1 and m2 are true we go with m2
[23:26] <xivulon> I guess
[23:27] <TheMuso> xivulon: Well its up to the code to work that out, but I wouldn't make those two check boxes, however it also depends on the gfxboot possibilities.
[23:27] <soren> elmo: Ok. So cprov/bigjools?
[23:27] <evand> TheMuso: so I did, thanks for catching that.
[23:27] <cjwatson> TheMuso: should be possible to make the access stuff checkbox, though it would change the keyboard navigation a bit (at the moment you'd have to press a number then escape)
[23:27] <cjwatson> TheMuso: but at the moment a menu can only be all-checkbox or all-radio, not a mix
[23:27] <TheMuso> evand: While you're at it, I'll get you to uncomment the enable_esd line in the blindness profile. We can finally have sound using pulse for speech.
[23:27] <TheMuso> cjwatson: Right I thought as much.
[23:28] <evand> TheMuso: will do
[23:28] <cjwatson> so from what you were saying from the time being we might be better off staying with what we have
[23:28] <TheMuso> cjwatson: I totally agree. It also makes things harder for those who can't see what they are doing.
[23:28] <TheMuso> As there are more keys to press, with little to no feedback.
[23:29] <xivulon> TheMuso on my side I am ok http://img183.imageshack.us/my.php?image=screenshotwubisetup2mn9.png
[23:29] <xivulon> cjwatson have a look at the image above would like to stay close to cd interface
[23:31] <xivulon> so do we go back to all radio buttons?
[23:31] <elmo> soren: normally yes
[23:31] <elmo> soren: mthaddon's fixed it
[23:32] <TheMuso> xivulon: I'd say so, simply because we can't have a mix on the gfxboot menu. However its nice to know that the code is pretty much fine if in the future we wish to change things.
[23:32] <TheMuso> And, that is actually something worth considering for the future.
[23:33] <TheMuso> At the start of the next cycle, I'll see what the community has to say about that idea.
[23:33] <soren> elmo: Excellent. Thanks very much.
[23:34] <evand> TheMuso: enable_esd is on by default.  In fact, the commentted out line actually disables esd.  Any objection to me just removing the comment entirely?
[23:34] <xivulon> last http://img155.imageshack.us/my.php?image=screenshotwubisetup3kd3.png
[23:35] <TheMuso> evand: Sorry, I got confused, yes remove that, and the comment above it, thanks.
[23:36] <evand> will do
[23:36] <TheMuso> xivulon: I don't personally care how it looks, as long as it works, and windows screen readers can work with it. Let me know when this is available for testing, and I will test it.
[23:36] <TheMuso> And get others with other screen readers to test it also.
[23:37] <xivulon> TheMuso, tonight wubi build will include that, but it won't work until the new ISO is up with grub-installer/lupin patches
[23:38] <TheMuso> xivulon: Right. Is all of that likely to land for hardy?
[23:38] <xivulon> Should be it'has been released already mostly
[23:38] <TheMuso> xivulon: Ok.
[23:38] <xivulon> But I am not the one in charge...
[23:39] <TheMuso> xivulon: Ok I understand.
[23:41] <TheMuso> cjwatson: I was looking over my logs from the weekend, and noticed talk about dmraid, and its possible inclusion into main, once partman-dmraid or whatever it was gets testing. Woudl you, 1) like me to test it, as I have a PCI card that uses such metadata that dmraid reads, and 2), integrate it into the initramfs error handling spec?
[23:52] <xivulon> TheMuso, last build with accessibility page: http://wubi-installer.org/devel/minefield/Wubi-8.04-alpha-rev411.exe
[23:53] <TheMuso> xivulon: Ok thanks. I'll have a look when I get a chance.
[23:53] <cjwatson> TheMuso: 1) sounds good, coordinate with evand 2) if you have time, absolutely
[23:53] <cjwatson> although I'm not sure how dmraid works with regard to the initramfs
[23:53] <TheMuso> cjwatson: Well I'll have a look at the code at least.