[00:10] <cjwatson> tkamppeter: I at least used to be an HTTP expert, although I'm pretty rusty these days.  I've posted an analysis to the bug with reference to the governing RFC.
[00:17] <Ampelbein> dinexi: I could be wrong but I think the openssl mod had a license issue.
[00:19] <dinexi> Ampelbein: Hm... that's bad. Do you know if it is included in the source package?
[00:20] <dinexi> Ampelbein: Silly me. Nope, it shouldn't be there. So what to do? Build this thing myself?
[00:22] <Ampelbein> dinexi: I don't know, maybe ask a question on https://answers.launchpad.net/ecryptfs/+addquestion?
[00:23] <dinexi> Ampelbein: did it already. But transformed it to bug because there is a bug in the manpages then. :( But it is the worst news for today.
[00:24] <Ampelbein> dinexi: kirkland is one of the authors of the software
[00:24] <jcole> using debian preseed, im trying to enable all repos in sources.list by adding this multiselect:
[00:25] <jcole> d-i	mirror/udeb/components	multiselect	main, restricted, universe, multiverse
[00:25] <jcole> (maverick)
[00:25] <jcole> but its not working
[00:25]  * kirkland waves
[00:25] <jcole> only main and restricted show up
=== chuck_ is now known as zul
[00:26] <jcole> mainly for this project -> http://linuxcoe.sourceforge.net/
[00:26] <Ampelbein> kirkland: dinexi had a question about the openssl mod in ecryptfs-utils and if it got removed.
[00:26] <kirkland> Ampelbein: dinexi: right, Ubuntu and Debian's policies prevent us from linking gpl code against the openssl libraries
[00:26] <slangasek> which is to say our policy of respecting the license we're given? :)
[00:27] <kirkland> Ampelbein: dinexi: so, yes, you would need to build it yourself, until such time as we rewrite the code to use a different library that is GPL-compatible
[00:27] <jcole> are preseeding server installs supported on ubuntu?
[00:27] <Ampelbein> kirkland: ok, thanks for the explanation.
[00:28] <slangasek> jcole: certainly, but this is not a support channel and the people who are most intimately familiar with the installer are not around, it being past their bedtime; you might try #ubuntu
[00:28] <kirkland> slangasek: it's a tough situation to explain to someone who cares not about internal license politics :-)  -- but yes, of course, you are correct
[00:29] <kirkland> Ampelbein: dinexi: http://www.openssl.org/support/faq.html#LEGAL2 and http://people.gnome.org/~markmc/openssl-and-the-gpl.html
[00:29] <dinexi> kirkland: thanks! but I have two questions. 1) it is very easy to change the manpage, why it can't be done? 2) can I build the package from the source from the ubuntu repos?
[00:29] <dinexi> kirkland: thanks a lot!
[00:29] <jcole> slangasek: can you give me an irc filter for all the "smart" people in #ubuntu so i dont see all 1500 users
[00:30] <kirkland> dinexi: yes, i think you can;  i have not done it in a very, very long time, but I think you merely need the openssl-dev packages installed on your system when you build/install ecryptfs-utils
[00:30] <kirkland> dinexi: i *think* that the ./configure auto detects the presence of openssl and links it in
[00:30] <kirkland> dinexi: like i said, been a long time since i did that
[00:30] <slangasek> jcole: afraid I don't know such a filter :)
[00:31] <jcole> slangasek: *sigh* ok here goes...
[00:31] <cjwatson> jcole: #ubuntu-installer
[00:31] <cjwatson> (I will help you there)
[00:32] <jcole> cjwatson: thanks!
[00:37] <dinexi> kirkland: sorry for the newbie question. I am in /var/cache/apt-build/build/ecryptfs-utils-83, made the change in the debian/rules file. What should I do now to build the package?
[00:39] <Chipzz>   
[00:46] <kirkland> dinexi: #ubuntu-motu is usually the best place to ask package building questions, but I'll give you a couple of hints here ...
[00:47] <kirkland> dinexi: mkdir foo; cd foo; apt-get source ecryptfs-utils; sudo apt-get build-dep ecryptfs-utils; # make your changes here; dch -i ; debuild
[00:49] <dinexi> kirkland: Thank you very much. debuild was a blocker.
[00:49] <kirkland> dinexi: no problem;  good luck
=== dendrobates is now known as dendro-afk
[00:55] <Chipzz> kirkland: didn't that change quite a while ago?
[00:55] <kirkland> Chipzz: huh?
[00:55] <Chipzz> at least that's what I was told the last time I redirected someone to #ubuntu-motu regarding packaging questions
[00:57] <Chipzz> kirkland: #ubuntu-motu being the place to redirect ppl to if they have packaging questions; they're not "OT" here anymore
[00:57] <kirkland> Chipzz: oh, really?  i guess i missed that policy change then
[00:59] <Chipzz> kirkland: maybe I misunderstood (but don't think I did); but that change is several months old already (at least 3 or 4 months I think)
[01:01] <lifeless> kees: ping
[01:07] <dsalvetti> Hi there, I have a weird (packaging?) issue with munin-node on 10.04
[01:07] <dsalvetti> when installing the package the file /etc/munin/munin-node.conf is missing
[01:08] <dsalvetti> even though dpkg think the file is there
[01:08] <dsalvetti> I have tried purging and reinstalling without success
[01:08] <micahg> dsalvetti: file is in the package
[01:09] <dsalvetti> any suggestion on what I could try next to find out where the issue is?
[01:10] <dsalvetti> micahg: yes I've confirmed that with dpkg -c /var/cache/apt/...
[01:11] <dsalvetti> dpkg --status also report the config file being present
[01:11] <dsalvetti> but it's not there and because of that munin-node fails to start properly
[01:17] <micahg> dsalvetti: maybe try #ubuntu-server, I don't see any bugs or questions filed on launchpad for it
[01:19] <micahg> dsalvetti: oh, you could try #ubuntu-cloud
[01:21] <dsalvetti> micahg: thank you, I'll try
[01:32] <psusi> hallyn, hey... I'm here on irc if you want to chat a bit about those bugs btw
=== rickspencer3 is now known as greatcthulu
=== greatcthulu is now known as greatcthulhu
=== greatcthulhu is now known as rickspencer3
[02:46] <YokoZar> slangasek: I tried a test rebuild of ia32-libs last night...and nothing seemed to break?!
[04:38] <slangasek> YokoZar: er, define "break"?
[04:39] <slangasek> YokoZar: is everything from /usr/lib/i386-linux-gnu getting copied into /usr/lib32?
[05:04] <kees> slangasek: so, the -dev packages will ship .a files in /usr/lib/$triplet/libFOO.a but not be Multi-Arch?
[05:12] <slangasek> kees: yes, because they're not reliably co-installable; that's something we need to go back and visit in round 2
[05:12] <slangasek> some headers, for instance, contain arch-specific info, and we'll need to pick those apart
[05:14] <kees> okay, cool. but they will still move to the triplet because they're built from the same --libdir target, etc.
[05:16] <slangasek> yep
[05:21] <kees> slangasek: uhm... does -dbg packages need the Pre-Depends?
[05:21] <slangasek> no, because they don't need to be found by ld.so
[05:23] <slangasek> (it doesn't hurt to have it added, I think, because the substitution will just be empty... but I haven't been bothering)
[05:26] <kees> okay, that's what I suspected.
[05:26] <kees> multiarch tiff passes the security team's regression test suite. ;)
[05:27] <slangasek> I should hope so :)
[05:28]  * kees suddenly realizes he has to teach his system about i386 tuples to test coinstallability
[05:29] <slangasek> hmm, I don't have that part written up yet, do I
[05:29] <slangasek> 'APT::Architectures { "amd64"; "i386"; };' in apt.conf, and 'foreign-architecture i386' in dpkg.cfg
=== dendro-afk is now known as dendrobates
[05:30] <kees> slangasek: do I need a i686-linux-gnu.conf in /etc/ld.so.conf.d too?
[05:30] <slangasek> no, libc6:i386 adds that
[05:30] <kees> ah-ha, righto
[05:32] <kees> is something like /etc/apt/apt.conf.d/60multiarch and /etc/dpkg/dpkg.cfg.d/60multiarch sane?
[05:34] <slangasek> sure
[05:36] <kees> oh whoops, didn't actually add Multi-arch: same. har har
[05:36] <slangasek> :-)
[05:37] <kees> slangasek: btw, I added this section quickly: http://wiki.debian.org/Multiarch/Implementation#Usingmultiarch
[05:37] <slangasek> ok
[05:38] <kees> heh, vim syntax needs updating! :)
[05:38] <slangasek> eventually I think that should be its own page, but that's great for now
[05:38] <slangasek> oh? updating for what?
[05:38] <kees> syntax hilighting "Multi-Arch:" correctly :)
[05:38] <slangasek> ah :)
[06:00] <kees> slangasek: okay... what am I doing wrong? The "Multi-Arch: same" field doesn't seem to be making it's way into the binary package. *scratch head*
[06:00] <slangasek> kees: pastebin?
[06:01] <slangasek> kees: or control.in? :)
[06:02] <kees> wait, no, I know what stupid thing I did. disregard. :)
[06:03] <wgrant> slangasek: What changes will be needed from the LP/buildd end, and when?
[06:04] <wgrant> I guess we'll need a new sbuild resolver.
[06:04] <slangasek> wgrant: nothing at all this cycle
[06:04] <StevenK> wgrant: s/ resolver//
[06:04] <wgrant> "this cycle" being natty?
[06:04] <slangasek> yeah
[06:04] <wgrant> But that's over in a month :)
[06:04] <slangasek> yeah ;)
[06:04] <StevenK> IE, please file bugs now so LP has time? :-)
[06:05] <slangasek> wgrant: we'll need to sit down at UDS and start figuring out what a sensible policy should even be for permitting cross-build-deps
[06:05] <wgrant> slangasek: Yeah.
=== _LibertyZero is now known as LibertyZero
[06:07] <YokoZar> slangasek: I mean fetch and build completed and the package built, although it probably is missing some things now
[06:07] <twb> Stupid question: why is it "from debian_bundle import deb822" in lucid, when in wheezy it's "from debian import deb822"?
[06:08] <slangasek> YokoZar: yes, I expect a lot of libs are either just plain missing, or installed to the wrong path
[06:09] <slangasek> twb: someone changed their mind about the name?
[06:10] <twb> I just ran into it because <script> barfed and it seems like a pointless change :-/
[06:10] <wgrant> debian_bundle has been deprecated for a while.
[06:10] <wgrant> It must have finally been removed.
[06:11] <twb> Note that this is lucid; I don't touch non-LTS releases
[06:11] <twb> OK, I checked the changelogs.  It's not an ubuntuism, the module name just changed upstream in Debian (0.1.16)
[06:11] <twb> Sorry to bother you
[06:11] <SpamapS> twb: err.. wheezy is the current testing isn't it?
[06:12] <twb> SpamapS: yes but I'm not using that in production, just my personal laptop :-)
[06:12] <SpamapS> looks like your *testing* of testing.. produced fruit. :)
[06:12] <StevenK> SpamapS: Boo, hiss
[06:14] <StevenK> RAOF: WTB Do plugin for Quod Libet
[06:16] <YokoZar> slangasek: is there an easy list of multiarch-ready libs that I can cross reference the list with?
[06:16] <slangasek> YokoZar: grep-dctrl -FMulti-Arch same -sPackage
[06:19] <StevenK> Compat level 9? Wow, where did 8 go ...
[06:21]  * StevenK idly wonders how brutally slangasek will slay him if he provides a recipe for converting a yada using source package to multi-arch ...
[06:21] <kees> StevenK: compat level 8 is too mainstream
[06:22] <kees> (hipster dh)
[06:23] <slangasek> StevenK: I figure if you survive the attempt, you deserve to live
[06:24] <StevenK> Haha
[06:34] <RAOF> StevenK: To do what?  Just play/pause/forward/backward?
[06:35] <StevenK> RAOF: Yah
[06:36] <RAOF> That should be trivial to whip up.  Does it support mpris?  If so, I could just do a generic mpris control plugin.
[06:36] <RAOF> Incidentally, the ‘focus’ Do action is quite useful when you're scared of alt-tabbing because unity crashes :)
[06:41] <StevenK> RAOF: How do I check if it supports mpris?
[06:41] <RAOF> You could see if it exports the appropriate interface on dbus.
[06:43] <RAOF> But, really, I could just install quod libet myself and see :)
[06:44] <StevenK> RAOF: That sounds better to me. :-P
[06:45] <kees> sudo apt-get install libc6:i386  <- so much hotness
[06:59] <linuxuz3r> hi
[06:59] <linuxuz3r> where do i get sys/processor.h
=== _LibertyZero is now known as LibertyZero
[07:05] <linuxuz3r> where do i get sys/processor.h
[07:06] <RAOF> From the package found by “apt-file search sys/processor.h”
[07:10] <linuxuz3r> RAOF, do you have the library for it
[07:12] <RAOF> No, but I've pointed you at the way to find the package which contains sys/processor.h.  Which apparently doesn't exist, and least on amd64, so you'll need to give more information.
[07:12] <RAOF> Probably in a different channel, because this doesn't sound like a question related to the development of the Ubuntu distribution :)
[07:13] <linuxuz3r> RAOF, last question
[07:13] <linuxuz3r> do you know if 32 bit ubuntu has it?
[07:14] <RAOF> No.  I'd *guess* that the package that you're after is linux-headers-generic, but since you've not given any context as to what you'd like to *do* with processor.h, that's just a guess ;)
[07:24] <linuxuz3r> its for a project that im doing
[07:29] <StevenK> RAOF: So, uh, does it? :-)
[07:34] <dholbach> good morning
[07:37] <YokoZar> slangasek: so that grep-dctrl command has been running for two hours and not returning anything...
[07:38] <cjwatson> YokoZar: it's waiting for input
[07:38] <cjwatson> YokoZar: try s/grep-dctrl/grep-aptavail/
[07:39] <YokoZar> cjwatson: ah hah, great ;)
[07:39] <YokoZar> cjwatson: btw did you have a theory about the binfmt warnings on wine1.2->wine1.3 switch?
[08:05] <cjwatson> YokoZar: not yet, haven't had a chance to think about it
[08:25] <pitti> Good morning
[08:31] <pitti> cjwatson: yesterday I added a gir1.2-* Extra-Include: to the supported seed, FYI; I don't think it makes too much sense to move all the autogenerated bindings of libraries to universe, as (1) we are going to need them in the near future, and (2) we really support them as well now (i. e. want to make sure that they work)
[08:31] <pitti> cjwatson: does that sound ok to you? if so, I'd like to promote the remaining girs to main (see c-m.txt)
[08:31] <cjwatson> pitti: sure
[08:33] <didrocks> good morning
[08:34] <amitk> is it normal (in the brave new world of unity) to *not* have a application launch when you click on the icon; instead you get taken to the existing instances of application. Nice for browsers, *very* annoying for terminals. I guess Ctrl-Alt-T will get more users...
[08:36] <pitti> amitk: middle click opens a new instance FYI
[08:37] <amitk> pitti: thx! where is all this documented? Is there a Unity starters guide?
[08:38] <pitti> http://askubuntu.com/questions/28086/unity-keyboard-mouse-shortcuts/28087#28087
[08:38] <pitti> (don't ask me for an easier address, I got it from https://wiki.ubuntu.com/Unity/KeyboardShortcuts
[08:39] <amitk> heh :)
[08:39] <didrocks> yeah, that's the best uptodate place :)
[08:39] <pitti> I hope that will get a slightly more discoverable address :)
[08:40] <didrocks> pitti: jcastro wants the askubuntu post to become the principal adress for it. But yeah, we need the officiel doc mentionning it with a link redirection
[08:42] <pitti> slangasek, doko__: seems the multiarch transition is still missing a bit for libgcj-bc; that one has a symlink ./usr/lib/libgcj_bc.so.1 -> libgcj.so.11 which doesn't currently even get *installed* (does dpkg not install broken symlinks? apparently so); I guess that path should be fixed
[08:45] <pitti> slangasek, doko__: want me to fix this?
[08:46] <pitti> Sweetshark: so I guess what's happening is that dpkg simply ignores broken symlinks; that sounds wrong to me, but I have no other explanation as the libgcj-bc doesn't have any maintainer scripts
[08:46] <Sweetshark> pitti: k
=== hunger_ is now known as hunger
[08:50] <pitti> smb`, cjwatson: it seems that linux-ports-meta is obsolete in natty, linux-meta builds the ports as well; correct?
[08:51] <cjwatson> that's what I vaguely remember but I'd check Sources/Packages before believing me :-)
[08:52] <cjwatson> it certainly looks that way
[08:53] <pitti> cjwatson: I looked at the binary packages produced by linux-meta
[08:53] <pitti> I better wait for smb's confirmation, though
[08:55] <cjwatson> $ M -S linux-ports-meta
[08:55] <cjwatson> linux-ports-meta | 2.6.35.24.18 |         natty | source
[08:55] <cjwatson> suggests so
[09:03] <pitti> cjwatson: man brainstorm implementation> awesome turnaround time! *applauds*
[09:07] <cjwatson> pitti: you're welcome :)
[09:37] <doko__> pitti, slangasek: sounds fine. I assume we need to move /usr/lib/gcj, used by the -gcj packages in the mid-range term too
=== doko__ is now known as doko
=== MacSlow is now known as MacSlow|errand
[09:46] <pitti> doko: hm, that dir is not shipped by gcc-defaults, is it? I don't have it here, anyway
[09:47] <doko> pitti: yes, but used/created in update-gcj-db
[09:59] <fta> popcon needs a fix for the multiarch thing
=== smb` is now known as smb
=== jjohansen is now known as jj-afk
[10:38] <smb> pitti, cjwatson ports and the rest had been building from the same source package before but I think that I remember something about merging back the meta package as well for natty. Let me check to be sure
[10:42] <smb> pitti, So the normal package generates omap, versatile and powerpc stuff. And afaik powerpc is the only ports things left beside of arm
[10:42] <pitti> smb: right now linux-ports-meta does not produce any binaries any more, and wants to go to universe; so I wondered if we should just remove it completely as it's obsolete
[10:48] <smb> pitti, At the danger of getting beatings from Andy, but I would also think that is obsolete and can go.
[10:51] <pitti> smb: well, easy enough to reupload if it should get useful again :)
[10:51] <pitti> doko: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gcc-defaults/natty/revision/58 works here
[10:51] <smb> :) right
[10:51] <ubottu> Error: Launchpad bug 58 not found
[10:52] <pitti> doko: ok to upload that? (kinda urgent, as it breaks the LibO build)
=== MacSlow|errand is now known as MacSlow
[10:56] <doko> pitti: sure, looks good. would be nice to introduce a with_multiarch macro to be able to build on older releases
[10:57] <pitti> doko: you mean dynamic by parsing debian/changelog, or just a switch on the top?
[10:58] <doko> switch on the top
[10:58] <doko> # is this a multiarch-enabled build?
[10:58] <doko> ifeq (,$(filter $(distrelease),lenny etch squeeze wheezy sid dapper hardy jaunty karmic lucid maverick))
[10:58] <doko>   with_multiarch_lib := yes
[10:58] <doko> endif
[10:58] <pitti> doko: shouldn't that be natty only?
[10:58] <pitti> ah, nevermind
[10:58] <pitti> sure, doing
[10:59] <yofel> pitti: why does apports postinst script error out again if it can't start apport? (bug 723670 and bug 741436)
[10:59] <ubottu> Launchpad bug 723670 in apport (Ubuntu) "package apport 1.18-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Triaged] https://launchpad.net/bugs/723670
[10:59] <ubottu> Launchpad bug 741436 in apport (Ubuntu) "apport won't install in a natty chroot on a Debian squeeze machine, due to missing upstart" [Undecided,New] https://launchpad.net/bugs/741436
[11:01] <yofel> it runs 'invoke-rc.d apport start || exit $?' - shouldn't that be '|| exit 0' ?
[11:01] <yofel> or is that a bug in dh_installinit?
[11:03] <pitti> yofel: that seems to be a regression in either dh_installinit or in upstart itself
[11:04] <pitti> yofel: the pre-start script is meant to exit with nonzero if the service shouldn't be started, AFAIUI (and it was Keybuk himself who wrote this code, too)
[11:06] <yofel> ah, it doesn't though, it checks "[ "$enabled" = "1" ] || [ "$force_start" = "1" ]" which both return 1 in this case and thus the script itself returns 1
[11:06] <pitti> right, that will keep it from starting
[11:07] <pitti> and in maverick the postinst didn't freak out because of that
[11:07] <pitti> there might be a newer way of blocking a service from starting, of course
[11:07] <pitti> jhunt_: ^ did that change recently?
[11:08] <pitti> doko: does that snippet come from another package? do you parse $(distrelease) from dpkg-parsechangelog?
[11:09] <pitti> doko: or from lsb_release?
[11:09] <doko> distrelease     := $(shell lsb_release -cs)
[11:09] <pitti> ah, ok
[11:11] <jhunt_> pitti: is this bug 707971 once again?
[11:11] <ubottu> Launchpad bug 707971 in upstart (Ubuntu Natty) "package apport 1.17.1-0ubuntu3 failed to install/upgrade: invoke-rc.d: initscript apport, action "start" failed." [Critical,Fix released] https://launchpad.net/bugs/707971
[11:12] <jhunt_> pitti: if so, I believe it's with slangasek
[11:12] <pitti> jhunt_: looks like it; at least it's the same symptom
[11:12] <chrisccoulson> dholbach, does opening links in tbird work for you now? it works for me, but the reporter of bug 709216 says it isn't fixed for him
[11:12] <ubottu> Launchpad bug 709216 in thunderbird (Ubuntu) "clicking on a link dont open the page " [Low,Triaged] https://launchpad.net/bugs/709216
[11:13] <chrisccoulson> (although, he did say it was fixed once already and then changed his mind again, so i'm not sure how much i trust him)
[11:18] <pitti> doko: tested for both cases, works; pushed
[11:35] <doko> Sweetshark, pitti: libtextcat tries to pull in automake1.7 ... whoever did propose/sync this ...
[11:35] <pitti> doko: already at it
[11:35] <pitti> (fix uploaded already)
[11:35] <doko> ;p
[11:41] <pitti> hm, I tried to revive the three broken armel buildds, but no luck; I'm afraid that's a lamont problem
[11:42] <lamont> pitti: yes.  and many thanks to the big phat packages that keep knocking them down in a row as they get retried on subsequent builders
[11:42] <pitti> poor armel :(
[11:42] <lamont> I'm specifically waiting for a new openjdk before I even worry about the buildds, since it's just gonna knock them over again
[11:43] <lamont> (and that's inbound, I'm told)
[11:43] <pitti> ogra_, didrocks: sorry, I think we already talked about it, but what was the decision about ubuntu-netbook{,-efl}-default-settings? remove or demote?
[11:44] <didrocks> pitti: I think we decided to remove it, isn't it ogra_ ?
[11:44] <ogra_> pitti, keep in universe for someone to adopt
[11:44] <pitti> they want to go to universe, but no point in keeping them in the archive if nobody will look after them any more
[11:44] <didrocks> ogra_: do you stil have the netbook-efl-launcher?
[11:44] <didrocks> still*
[11:44] <pitti> isn't it unity-2d now?
[11:44] <ogra_> no
[11:44] <didrocks> so, no point to have the settings package? no more netbook-launcher nor its -efl brother
[11:45] <ogra_> we dont use it, but there are some linaro partners that have interest in taking oveer efl stuff
[11:45] <ogra_> -settings can surely go
[11:45] <ogra_> buut keep the binaries
[11:45] <pitti> ok; I see we have netbook-launcher-efl in universe still as well, so we shoudl keep the efl-default-settings as well
[11:45] <ogra_> if nobody adopted it by OO we can still drop it
[11:45] <pitti> but I think we should remove ubuntu-netbook-default-settings
[11:46] <ogra_> efl-default-settings can go too
[11:46] <pitti> ok
[11:46] <ogra_> just keep the binaries for the apps
[11:46] <pitti> right
[11:46] <ogra_> so there is something for someone to pick up and work with
[11:47] <pitti> *flush*
[11:47] <soreau> Ok guys, can someone please clarify this for me about jockey? What do you have to do to make drivers appear in jockey?
[11:47]  * didrocks waves byebye to the settings :)
[11:47] <pitti> ogra_: x-loader-omap4 wants to go to universe as well; is it still being used?
[11:47] <soreau> It seems removing the modalias packages removes drivers from the list but reinstalling them does not make anything reappear in jockey
[11:47] <pitti> soreau: have hardware who needs them, usually
[11:47] <pitti> soreau: the modalias packages are obsolete and shoudl be removed on upgrade
[11:47] <ogra_> pitti, i dont think so, need to check, but i think it can actually be removed
[11:48]  * ogra_ checks code 
[11:48] <soreau> pitti: I dont get it though. You have a card supported by binary drivers, remove modalias packages and disappears from jockey
[11:48] <pitti> ogra_: no rdepends, anyway
[11:48] <soreau> Install modalias and they do not reappear
[11:48] <soreau> what is the deal?
[11:48] <pitti> soreau: hang on, are you on 10.10 or natty?
[11:48] <soreau> How do you make drivers appear in jockey? (provided you have the hardware)
[11:48] <ogra_> pitti, thats a binary ?
[11:49] <soreau> pitti: It doesnt matter what I am using
[11:49] <pitti> ogra_: source package
[11:49] <ogra_> hmm
[11:49] <pitti> soreau: it matters a lot
[11:49] <soreau> this is a question so I can do better support
[11:49] <soreau> pitti: Not my problem, I use all open drivers
[11:49] <pitti> soreau: in 10.10 we used the modalias packages, in natty we dropped them
[11:49] <soreau> But you are avoiding my question
[11:49] <ogra_> pitti, can go, the new package is "x-loader" ... note that our bootloaders never have rdepends ;)
[11:50] <pitti> soreau: I can't give you a definitive answer before you tell me which release you are running on
[11:50] <soreau> <soreau> pitti: Not my problem, I use all open drivers
[11:50] <pitti> soreau: so *shrug*, my answer is: if you are on 10.10 or below, you need to have the modalias packages installed for jockey to work
[11:50] <soreau> Ok thats all you had to say
[11:50]  * pitti is confused now -- was I being offensive?
[11:51] <Kmos> not at all
[11:51] <pitti> ogra_: aanyway, x-loader-omap4 is both a source and a binary, and no rdepends at all
[11:52] <pitti> ogra_: package was introduced in maverick
[11:56] <nobuto> mvo: I have gathered affected locales list for Bug #573502 in Ubuntu Translators mailing list.
[11:56] <nobuto> mvo: It would be great if you will disable loading translations to the locales on the list https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/573502/comments/13
[11:56] <ubottu> Launchpad bug 573502 in Ubuntu Japanese Kaizen Project "unreadable characters in recovery mode" [High,Triaged] https://launchpad.net/bugs/573502
[11:56] <ubottu> Ubuntu bug 573502 in Ubuntu Japanese Kaizen Project "unreadable characters in recovery mode" [High,Triaged]
[12:00] <mvo> thanks nobuto
[12:03] <pitti> Kmos: (sorted it out in /query now..)
[12:04] <ogra_> pitti, right, in natty linaro introduced x-loader (with no suffix) so the source with suffix can go
[12:04]  * pitti cruft busting more
=== nigelbabu is now known as nigelb
=== MacSlow is now known as MacSlow|lunch
[12:14] <dholbach> chrisccoulson, works for me too
[12:16] <ogra_> hmpf ... so i uploaded metacity 2.30.3-0ubuntu7 but didnt get any mail for it
[12:17] <chrisccoulson> dholbach, thanks. i guess the reporter has either messed up their configuration or hasn't actually upgraded everything yet
[12:17] <pitti> ogra_: didn't land on LP either; the most common cause is an unsigned source.changes
[12:18] <dholbach> chrisccoulson, or not restarted the session
[12:18] <chrisccoulson> dholbach, yeah, possibly ;)
[12:21] <pitti> ogra_: looks better now :)
[12:21] <ogra_> yep
[12:22] <ogra_> i re-rolled the source package
[12:22] <ogra_> weird thogh, i'm sure i signed the first time too
[12:24] <mvo> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | 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: smoser, mvo
=== yofel_ is now known as yofel
[12:31] <doko> bdrung: lintian ping
[12:31] <soren> pitti: for me, dput refuses to upload unsigned .changes.
[12:35]  * dholbach hugs mvo
=== claudinux is now known as Claudinux
[12:41] <bdrung> doko: i made some progress, but still some issues left: http://paste.ubuntu.com/584244/
[12:42] <doko> bdrung: nice!
=== sconklin-gone is now known as sconklin
=== njpatel is now known as njpatel_
=== claudinux is now known as Claudinux
=== htorque__ is now known as htorque
[13:35] <bdrung> doko: two issues remain: 1. dpkg-source fails in one test. 2. the test complains about the ubuntu changelog entries
=== MacSlow|lunch is now known as MacSlow
[14:00] <ximion> hi!
[14:01] <ximion> could someone please apply my patch against packagekit pkg and upload the new packagekit package?
[14:01] <ximion> https://bugs.launchpad.net/ubuntu/+source/xulrunner-2.0/+bug/740815/+attachment/1936588/+files/packagekit_0.6.11-2ubuntu2.debdiff
[14:01] <ubottu> Ubuntu bug 740815 in Mozilla Firefox "[FFe] Updates to enable us to drop xulrunner from main" [Medium,In progress]
[14:01] <ximion> solves the bug mentioned above
=== njpatel_ is now known as njpatel
[14:02] <ximion> (I cannot request sync with Debian this time, cause we're still waiting on some deps for the new PK version to enter unstable)
[14:04] <bdrung> kees: your last upload of tiff let's vlc 1.1.8-1ubuntu1 fail to build: libtool: link: `/usr/lib/libtiff.la' is not a valid libtool archive
[14:06] <fta> slangasek, multiarch? http://paste.ubuntu.com/584828/
[14:06] <micahg> bdrung: whichever file references that one needs dependency_libs emptied
[14:07] <bdrung> micahg: that's the end of the build log: http://paste.debian.net/111812/
[14:10] <micahg> bdrung: here's the culprit: libsdl-image1.2-dev
[14:11] <micahg> bdrung: dependency_libs needs to be emptied at build time
[14:12] <ari-tczew> ogra_: https://code.launchpad.net/~om26er/ubuntu/natty/metacity/metacity-fix-717216/+merge/52199 you should upload with Omer's d/changelog entry.
[14:12] <ubottu> Ubuntu bug 52199 in darcs (Ubuntu) "darcs-server cache dir" [Low,Fix released]
[14:12] <ogra_> ari-tczew, to late :)
[14:13] <ari-tczew> ogra_: yes, but please remember about that in future.
[14:13] <ogra_> hard to do if you have to mangle the patch
[14:13] <bdrung> micahg: what's the best way to do that?
[14:13] <ogra_> but yes, next time if we have more time i'll ask him to do the origin and upstream bug entries himself
[14:13] <ari-tczew> ogra_: it is possible, trust me ;)
[14:13] <ogra_> i know that its possible
[14:14] <ari-tczew> debuild -kYOURKEYOREMAIL
[14:14] <micahg> bdrung: I did it in gtkglext, following the example of gnome-pkg-tools clean-la.mk file, there have been several similar uploads in the past week
[14:15] <ogra_> ari-tczew, the version was outdated, i had to do changes to the patch too ... so i decided to make a new changelog entry
[14:15] <bdrung> micahg: thanks
[14:15] <ari-tczew> ogra_: your choice, but it makes sometimes contributor unhappy.
[14:16] <ogra_> its not that i didnt mention him or anything
[14:16] <ari-tczew> I know
[14:16] <ari-tczew> but some contributors like to have his patch as uploaded package
[14:16] <ogra_> well, then i would have had to ask him to do the changes
[14:16] <ari-tczew> and sponsoring means that we should keep their changelogs
[14:17] <ogra_> which would likely have resulted in that patch not making the freeze
[14:17] <ari-tczew> if wouldn't be there entry in d/changelog, then fine
[14:17] <ogra_> i'm happy to explain what i do if i do it to people that want to complain to me
[14:18] <ari-tczew> ogra_: I'm stopping this discussion at this moment as some persons here will take this as attack (which is not...). I gave you only my views.
[14:26] <matttbe> Hello,
[14:26] <matttbe> I'm from Cairo-Dock team and I want to update Cairo-Dock packages on Ubuntu. I've opened two bug reports (cairo-dock and its plug-ins) one month ago with two linked branches: https://code.launchpad.net/bugs/723994 & https://code.launchpad.net/bugs/723995
[14:26] <ubottu> Ubuntu bug 723994 in cairo-dock (Ubuntu Natty) "FFe: Please update Cairo-Dock to 2.3.0~0rc1 version" [Wishlist,New]
[14:26] <ubottu> Ubuntu bug 723995 in cairo-dock-plug-ins (Ubuntu) "Please update Cairo-Dock Plug-ins to 2.3.0~0rc1 version " [Undecided,New]
[14:26] <matttbe> The merge proposal status is still marked as "Needs Review" and micahg said to me that I've to contact mvo about these merge proposals: https://code.launchpad.net/~cairo-dock-team/ubuntu/natty/cairo-dock/2.3.0-0rc1/+merge/51034 & https://code.launchpad.net/~cairo-dock-team/ubuntu/natty/cairo-dock-plug-ins/2.3.0-0rc1/+merge/51035
[14:26] <ubottu> Error: Launchpad bug 2 not found
[14:26] <ubottu> Error: Launchpad bug 2 not found
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
=== SolidLiq is now known as solid_liq
[14:30] <mvo> matttbe: I have a look now
[14:30] <matttbe> I also want to note that we can't use the Debian versions because they don't respect what the upstream want to have (a bug has been reported about that) and the sponsoring said that "the merges were missing the original tarballs from upstream (upstream tag in UDD)"
[14:30] <matttbe> mvo: thank you!
[14:34] <slangasek> YokoZar: sorry, I was assuming you were familiar with grep-dctrl already - you have to pass it a path to your natty Packages file as an argument
[14:34] <slangasek> pitti: odd, I know I tested libgcj_bc.so.1 earlier
[14:35] <pitti> slangasek: it seems to work now, anyway
[14:35] <mvo> matttbe: this needs a feature freeze exception from the release team, if that is granted I'm happy to sponsor the upload
[14:36] <matttbe> mvo: thank you but how can I receive this FFe? (an ACK?) Who can I contact?
[14:37] <BlackZ> matttbe: https://wiki.ubuntu.com/FreezeExceptionProcess
[14:37] <matttbe> BlackZ: thank you :)
[14:37] <mvo> matttbe: #ubuntu-release may help, but the usually process them via bugreports, not via irc (and what BlackZ said)
[14:38] <jelmer> barry: hi
[14:38] <Sweetshark> pitti: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-nattytest <- there is a libreoffice version in there, l10n is in /home/bjoern/lo33/ on chinstrap
[14:38] <slangasek> pitti: did you have to change something to get it to work?
[14:38] <matttbe> mvo: ok I will do that!
[14:39] <mvo> good luck :)
[14:39] <Sweetshark> pitti: ok, Im 20 minutes late, but I still get twiddlefingers from libreoffice packaging.
[14:39] <barry> jelmer: hi.  wanna chat about udd+uds?
[14:39] <pitti> slangasek: yes, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gcc-defaults/natty/revision/58
[14:39] <micahg> mvo: skaet said to ping her when it was in shape, I already discussed with her before but the actual update was some days off
[14:39] <ubottu> Error: Launchpad bug 58 not found
[14:39] <micahg> mvo: re cairo-dock
[14:39] <pitti> slangasek: (and r59 for beautification)
[14:40] <slangasek> pitti: oh, this symlink is in gcc-defaults... that'll be how I missed it, sorry
[14:40] <pitti> slangasek: no problem at all :)
[14:40] <pitti> slangasek: this libgcj-bc is a horrible hack..
=== Quintasan_ is now known as Quintasan
[14:41] <slangasek> jhunt_: hmm, what's this about bug #707971 resurfacing?
[14:41] <ubottu> Launchpad bug 707971 in upstart (Ubuntu Natty) "package apport 1.17.1-0ubuntu3 failed to install/upgrade: invoke-rc.d: initscript apport, action "start" failed." [Critical,Fix released] https://launchpad.net/bugs/707971
[14:41] <Sweetshark> pitii: freedesktop bug 33915 / launpad bug 731556 seems not to be ubuntu only, but I still dont like it.
[14:41] <pitti> Sweetshark: sponsoring..
[14:41] <ubottu> Freedesktop bug 33915 in Libreoffice "user settings get lost after several restarts" [Major,Reopened] http://bugzilla.freedesktop.org/show_bug.cgi?id=33915
[14:41] <ubottu> Launchpad bug 731556 in LibreOffice Productivity Suite "LibreOffice erases user settings, and block the use of interface styles..." [High,Confirmed] https://launchpad.net/bugs/731556
[14:41] <mvo> micahg: aha, ok. was that writen in the bugreport? i did not see it there. happy to sponsor it if it has approval
[14:41] <pitti> Sweetshark: did you get some more data for it?
[14:42] <micahg> mvo: it was a "let's evaluate when it's ready type of thing", so no explicit ACK yet
[14:45] <Sweetshark> pitti: well: it happens with our build and with the LO build, it happens on OpenSUSE. So its not just us. However, it still happens with 3.3.2, which I hoped would solve it (because some werent experiencing it anymore). Unfortunatly, still no easily reproducable scenario.
=== dendrobates is now known as dendro-afk
[14:51] <jelmer> barry: Yes, that'd be great
[14:59] <jhunt_> slangasek: sorry - it's not the same problem now I look at it more closely. But bug 741436 is rather nasty - invoke-rc.d calls /lib/init/upstart-job which fails since the environment outside the chroot doesn't have upstart installed.
[14:59] <ubottu> Launchpad bug 741436 in apport (Ubuntu) "apport won't install in a natty chroot on a Debian squeeze machine, due to missing upstart" [Undecided,New] https://launchpad.net/bugs/741436
[15:00] <jhunt_> slangasek: we can detect from within the chroot whether upstart is available outside it, but what I don't know is what we should do if upstart *isn't* outside. return 0 and not start the job? or error (as is currently happening anyway)?
[15:01] <slangasek> jhunt_: ah; isn't the right behavior here to divert /sbin/initctl? :)
[15:01] <jhunt_> slangasek: /bin/true?
[15:01] <slangasek> yeah
[15:01] <slangasek> that's part of a normal chroot setup, I think :)
[15:02] <jhunt_> I haven't honestly tried that and I don't know what happens with the new version of upstart which... err... "sort of" has chroot support.
=== dendro-afk is now known as dendrobates
[15:02] <jhunt_> slangasek: where "sort of" equates to "is broken" :)
[15:02] <slangasek> heh :)
[15:04] <jhunt_> slangasek: I guess we stick with divert until I've fixed chroots, which makes that bug invalid presumably as the chroot environment isn't setup as expected.
[15:05] <jhunt_> slangasek: maybe we should package upstart to auto-detect when it's installed in a chroot and do the divert automatically?
[15:05] <slangasek> I wouldn't
[15:05] <slangasek> note that all server installations start out as a chroot unpack
[15:05] <slangasek> for that matter, so do liveCD builds at some point
[15:05] <jhunt_> slangasek: ah! right :)
[15:07] <Chipzz> is there a proper way you can detect if you're being run in a chroot?
[15:07] <Chipzz> can't immediately think of one myself
[15:07] <jhunt_> Chipzz: "stat /" seems to work :)
[15:08] <Chipzz> I'm wondering... how hard would things break if you did chmod o-x / ? :P
[15:09] <Chipzz> or rather, what would not break :P
=== tkamppeter__ is now known as tkamppeter
[15:10] <cjwatson> there's a set of chroot detection runes that exists in various packages' maintainer scripts.  I'm with slangasek on this though
[15:11] <Chipzz> cjwatson: well I was going to say (but I think you already guessed that) detect it at runtime
[15:11] <cjwatson> (though perhaps, if it's emitting an error message, the error path could be augmented with chroot detection to make the message more helpful)
[15:11] <Chipzz> then again, you would have to manually start upstart IN the chroot, which makes little sense I guess
[15:15] <Chipzz> jhunt_: so what was the reason for diverting not being a valid solution?
[15:15] <Chipzz> uh
[15:15] <Chipzz> nevermind
[15:16] <Chipzz> head full of snot, not focussed, meh. sorry
[15:16] <jhunt_> Chipzz: I'm not saying it's not valid, but we're trying to add full chroot support to upstart atm, so the advice might change when that happens. Also, I was wondering at the possibility of not having to have to manually do the divert.
[15:17] <Chipzz> jhunt_: right, I read the last lines of the discussion, then went to read the top of my screen, and somehow I managed to overlook "16:04 < jhunt_> slangasek: I guess we stick with divert..."
[15:17] <Chipzz> jhunt_: hence why I said nevermind :)
[15:18] <Chipzz> jhunt_: but how exactly are stat / inside and outside of a chroot supposed to differ?
[15:20] <Chipzz> looking at the 2 and can't spot any obvious differences, but I'm probably overlooking it
[15:21] <cjwatson> you stat / inside the chroot and compare it with /proc/1/root
[15:21] <cjwatson> if they're different you're in a chroot
[15:21] <Chipzz> ah k
[15:22] <jhunt_> Chipzz: or [ `stat --printf="%i" /` != 2 ] && echo "in chroot" || echo "NOT in chroot"
[15:22] <Chipzz> sth that did catch my eye too, is "Inode: 2"
[15:22] <cjwatson> yes, though I wouldn't want to trust that as not being fs-specific
[15:22] <jhunt_> cjwatson: true!
[15:23] <Chipzz> inode 1 is the journal I think?
[15:23] <cjwatson> also, it only means you're at the root of a filesystem; it does not mean you aren't in a chroot, since the chroot might start at the root of a filesystem
[15:24] <Chipzz> thx :)
[15:24] <Chipzz> that would make for a good question on a google interview :)
[15:31] <SpamapS> yaaay.. bug #696996 is fixed now.. I can run unity all the time.
[15:31] <ubottu> Launchpad bug 696996 in unity "Unity is offset down by difference in resolutions when Nvidia twinview is used" [Undecided,Triaged] https://launchpad.net/bugs/696996
=== sconklin is now known as sconklin-afk
=== deryck is now known as deryck[lunch]
[15:49] <kim0> Hi folks .. Letting you know Ubuntu Cloud Days starting in 10mins in #ubuntu-classroom .. You can discuss in #ubuntu-classroom-chat .. Thanks
[15:57] <shadeslayer> mdeslaur: Hi!
[15:57] <mdeslaur> shadeslayer: hello
[15:58] <shadeslayer> mdeslaur: Just wanted to inform you on the issue with the revoked certs and how rekonq/konqueror will handle it, a patch for QSslSocket is being formed as we speak, will track it and get back to you :)
[15:59] <mdeslaur> shadeslayer: cool...thanks
=== dendrobates is now known as dendro-afk
=== jj-afk is now known as jjohansne
=== jjohansne is now known as jjohansen
[16:06] <Pilif12p> I'm probably in the wrong channel, but in the 11.04a3 installer it has a screenshot of OpenOffice but it says LibreOffice.. I know that they're pretty much the same but it still says "OpenOffice.org" in the title bar.
[16:08] <ScottK> Pilif12p: Please report a bug against the ubiquity-slideshow-ubuntu package.
[16:09] <Pilif12p> okay
=== herton is now known as herton_lunch
=== diwic is now known as diwic_afk
[16:21] <pitti> kees, jdstrand: releasing lucid and maverick linux-mvl-dove linux-meta-mvl-dove to -updates and -security
[16:26] <mdz> cjwatson, pitti, kees, TechnicalBoardAgenda says 1800 UTC but the calendar says 1700 UTC (US DST damage)
[16:28] <cjwatson> mdz: earlier is better for me, but pick one I guess
=== dendro-afk is now known as dendrobates
[16:31] <pitti> mdz: ^ same for me
[16:32] <doko> Sweetshark: misusing the buildds as test machines? ;-P
[16:37] <mdz> cjwatson, pitti - Keybuk is supposed to chair, and I believe he said he couldn't make the earlier time slot (when we were setting the new meeting time)
[16:37] <mdz> I guess it depends on what kees and Keybuk are expecting
[16:37] <pitti> ok, so 1800 UTC
[16:37] <mdz> I have a dinner engagement this evening which I scheduled based on the 1700 time slot, so if it's 1800 I will have to leave early
[16:37] <mdz> 1830 or so
[16:37] <pitti> ok, 1830 WFM
[16:40] <Sweetshark> doko: "yesterday it still worked"
[16:40] <cjwatson> mdz: ok, let's make it 1800 and be snappy then
[16:41] <mdz> cjwatson, ack
[16:42] <mdz> pitti, thanks a lot for working on the brainstorm review
=== deryck[lunch] is now known as deryck
=== herton_lunch is now known as herton
[16:59] <jamespage> slangasek: are you avail. to discuss bug 737603 and how we resolve it?
[16:59] <ubottu> Launchpad bug 737603 in openjdk-6 (Ubuntu) "JNI unable to find libpam.so" [High,Triaged] https://launchpad.net/bugs/737603
[16:59] <slangasek> jamespage: sure
[17:00] <jamespage> slangasek: excellent
[17:00] <jamespage> so first things first - I am in no way saying that loading unversioned libraries is a 'correct' thing todo in Java
[17:01] <slangasek> jamespage: yep - and I'm not meaning to block you from getting things fixed, I'm just pointing out that anything that does load_this_library("pam") is broken in all kinds of ways and I want to make sure we're not adding extra hacks we shouldn't need to in support of a fundamentally broken model
[17:03] <jamespage> slangasek: I don't particularly like the way either the JVM or JNA does this stuff; but ultimately there is a bunch of code out there that depends on load_this_library("pam") working in some fashion on Ubuntu
[17:03] <jamespage> (mainly because thats what Sun said should work way back in Java time)
[17:04] <jamespage> slangasek: fundamentally libjna-java is a bit of a hack to make Java and native libraries work in some sort of fuzzy fashion
[17:05] <pitti> mdz: you're welcome; first responses are already trickling in :)
[17:05] <jamespage> slangasek: I'll fix to specific versions where I can in the Jenkins codebase (which will help not make this any worse)
[17:05] <slangasek> jamespage: and was that working reliably before the switch to multiarch, as a result of the code in the standard library that pokes around the filesystem for something that matches the pattern lib${arg}.so.*?
[17:06] <jamespage> slangasek: yes - but only because of the fuzzy matching that libjna-java provides as you state
[17:07] <slangasek> and libjna-java is all bytecode, no jni bits of its own I guess? :)
[17:07] <jamespage> So it does provide one native library which gets installed into /usr/lib/jni
[17:08] <slangasek> ok
[17:08] <jamespage> this is used to bypass the normal JVM loadLibrary call which does not work
[17:08] <jamespage> it calls dlopen directly
[17:08] <jamespage> but theres a bit of Java infront of that which scans an automatically generated library path to determine which absolute path name to pass to dlopen
[17:09] <slangasek> but the path resolution is done in the java code, not in the native lib, so it's non-trivial to fix things to just pick up the correct library path at build-time -hmm
[17:09] <jamespage> you got it - hence the nasty code in Java to build the path based on cpu etc... to be multi-path compatible.
[17:09] <jamespage> sorry - mutli-arch
[17:09] <jamespage> or even multi-arch
[17:09] <jamespage> :-)
[17:10] <slangasek> right
[17:10] <slangasek> so yes, this is all very nasty, but I don't see any other viable short-term solutions
=== MacSlow is now known as MacSlow|break
[17:11] <jamespage> I agree - I think the best longer term solution is to work with dependent packages to fix to specific versions of libraries (which it does support) rather than using wildcards.
[17:11] <slangasek> long-term, I think we should skip right over trying to handle the multiarch path in the native code and instead try to propagate the news that calling loadme("pam") is wrong
[17:11] <slangasek> yep, seems like we're aligned
[17:12] <slangasek> and just needed to get the realtime exchange here to verify this :)
[17:12] <jamespage> agreed
=== sforshee is now known as sforshee-lunch
[17:13] <jamespage> So I'll complete the patch for libjna-java for Natty; hopefully we can then drop this at some point in the future
[17:13] <slangasek> sounds good to me
[17:14] <slangasek> so you'll fix up the armel handling and resubmit?
[17:14] <jamespage> I'll also post to debian-java to generate some discussion around this; specifically moving to using versioned .so's with libjna-java.
[17:14] <slangasek> (armhf can be deferred for now)
[17:14] <jamespage> Yep - I'll update the branch to handle armel correctly as specified in the merge proposal.
[17:14] <slangasek> great, thanks :)
[17:15] <jamespage> I just need a quick check on what openjdk defines for os.arch on armel so if anyone has a bit of arm kit that could confirm much appreciated.
[17:18] <slangasek> jamespage: toss me a quick'n'dirty java prog I can use to grab that from an arm system?
[17:19] <jamespage> slangasek: OK - I'll stick something together now
[17:20] <ScottK> slangasek: Aren't dirty and java program redundant?
[17:20] <slangasek> ScottK: "quick" and "java program" aren't, and "quick&dirty" is a package deal ;)
[17:20] <ScottK> True.
[17:21] <ScottK> First time my wife did a program in Python after having done Java stuff she was SURE she was missing something because it was too easy.
[17:21] <jamespage> slangasek: http://pastebin.com/Y2GEjz7a - drop it into a file called OSArch.java; javac OSArch.java; java OSArch should do the trick
[17:23] <jamespage> ScottK: I know exactly how she felt :-)
[17:23] <jamespage> slangasek: thanks for doing that.
[17:23] <slangasek> ScottK: haha :)
[17:24] <slangasek> jamespage: is it safe for me to build it on x86 and copy the result over to armel?  Otherwise I'll be waiting a bit for openjdk to install on my beagle :)
[17:24] <jamespage> slangasek: should be - Java bytecode is mean't to run anywhere
[17:25] <psusi> I still claim that Java was invented by C programmers as a means for universities to crank out crappy programmers so they couldn't compete for the older guys's jobs ;)
[17:25] <slangasek> jamespage: yeah, I know that's the /theory/ ;)
[17:25] <psusi> and I FINALLY decided to give python a shot recently and it's pretty sweet
[17:25] <jamespage> slangasek: well you never know...... :-)
[17:26] <kees> slangasek: how do I get a list of the i386 packages I have installed on my amd64 system? apt-cache policy isn't much help
[17:27] <slangasek> kees: dpkg -l '*:i386'
[17:27] <kees> oh-ho! nice.
[17:32] <jdstrand> pitti: hi! I am trying to use 'apport-collect 741908', and then get the familar "Waiting to hear from Launchpad about your decision..." in the terminal, but it opens in firefox and I get "Not allowed here" (logged in as jdstrand)
[17:32] <pitti> jdstrand: le huh?
[17:32] <jdstrand> pitti: I feel I am missing something-- does apport stash its creds somewhere?
[17:33] <pitti> jdstrand: yes, it's supposed to, and seems to work her
[17:33] <pitti> e
[17:33] <pitti> ~/.cache/apport/launchpad.credentials
[17:33] <jdstrand> k
[17:33] <pitti> jdstrand: that should even continue to work with the old tokens (by-app), it shouldn't insist on a per-machine one
[17:34] <jdstrand> pitti: ok, I removed that and it worked. I had removed a bunch of crufty authorizations a little while ago and it seems apport was using a cached one that I removed in LP
[17:34] <jdstrand> pitti: all is well now, thanks!
[17:35] <pitti> jdstrand: ah, good
[17:37] <ScottK> pitti: Would you have a moment to do the sync in Bug 741886?  It'd be nice to get it in before Beta 1 freeze.
[17:37] <ubottu> Launchpad bug 741886 in python3-defaults (Ubuntu) "Sync python3-defaults 3.2-1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/741886
[17:39] <pitti> ScottK: sure
[17:39] <ScottK> pitti: Thanks.
[17:50] <kees> slangasek: I'm completely at a loss on how ia32-libs loads libraries. in a chroot, /usr/lib/nspluginwrapper/i386/linux/npviewer.bin loads fine. LD_DEBUG=libs ... shows the /lib32 paths. "ldconfig -v" does not. and on my real machine, I cannot run npviewer.
=== sconklin-afk is now known as sconklin
=== sforshee-lunch is now known as sforshee
[17:53] <slangasek> jamespage: $ java OSArch
[17:53] <slangasek> arm
[17:54] <slangasek> kees: hrm, I'm not sure how that's meant to work
[17:54] <slangasek> let me poke around here
[17:55] <slangasek> kees: ldconfig -v doesn't show it because ldconfig belongs to the 64-bit libc, which doesn't know about lib32, and ia32-libs doesn't install anything to /etc/ld.so.conf*
[17:56] <slangasek> kees: or rather, libc6-i386 doesn't
[17:56] <cjwatson> Keybuk: are you available to chair the TB meeting today?
[17:56] <cjwatson> (hi :-) )
[17:57] <slangasek> kees: so the question is whether libc6-i386 still has the right built-in library path, or if we managed to break that with multiarch
[17:57] <slangasek> kees: er... no, more than that.  if you have libc6:i386 installed, this *replaces* libc6-i386's linker
[17:57] <slangasek> because they're the same filesystem path, obviously
[17:58] <Keybuk> cjwatson: yup
[17:58] <cjwatson> great
[17:58] <cjwatson> whoops
[17:58] <slangasek> kees: so I guess as a bandaid, libc6:i386 needs to know about /lib32
[17:58] <kees> slangasek: hhmmm.
[17:58]  * cjwatson hears dinner being dished up
[17:58] <cjwatson> perhaps I ought to have warned Kirsten about the meeting :-/
[17:58] <kees> I uninstalled libc6:i386... perhaps I need to reinstall ia32-libs now
[17:58] <slangasek> kees: oh, haha
[17:58] <slangasek> yeah, that would also do it
[17:59] <kees> slangasek: well, I mean, I uninstalled libc6:i386 as part of the debugging process.
[17:59] <slangasek> as /lib/ld-linux.so.2 would be missing now
[17:59] <slangasek> ah, right
[17:59] <slangasek> so yes, reinstalling ia32-libs should bring back the linker that knows about lib32
[18:00] <slangasek> I think we should have libc6-i386 install an ld.so.conf snippet to deal with this, rather than embedding lib32 knowledge in libc6:i386
[18:02] <kees> sudo apt-get --reinstall install libc6-i386  <- fixed it
[18:02] <slangasek> yep
[18:02] <slangasek> and sudo apt-get install libc6:i386 should break it again
[18:02] <kees> and all that snippet should look like would just be adding /lib32 and /usr/lib32 ?
[18:03] <slangasek> yep
[18:03]  * kees attempts
[18:06] <kees> winning
[18:12] <xjunior> My sound device stopped work. I'm on natty, living in the edge. can you help me to figure out why, maybe fix it or at least help the ubuntu dev team to fix this for future releases?
[18:12]  * bcurtiswx drum hits
[18:16] <shadeslayer> xjunior: support in #ubuntu+1
[18:20] <kees> slangasek: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/741949  look right?
[18:20] <ubottu> Ubuntu bug 741949 in eglibc (Ubuntu Natty) "libc6-i386 co-installed with libc6:i386 breaks ia32-libs" [Low,New]
[18:25] <slangasek> kees: yeppers
[19:04] <pitti> ev: for bug 723813, should we now close the ubiquity task as "wontfix" as well?
[19:04] <ubottu> Error: Launchpad bug 723813 could not be found
=== MacSlow|break is now known as MacSlow
[19:04] <psusi> keybuck is a frigging genious.  he made mountall so smart, at first I thought it was a bug for ignoring the fsck order argument in fstab, but he actually figures out what fs are on the same physical disk, and uses ionice to make sure only one fsck at a time has priority access to the disk.
[19:07] <jamespage> slangasek: thanks - made a good first guess in that case!
[19:07] <ev> pitti: I don't agree with the decision, but far be it from me to co-opt the entire installer team in such a manner. Go ahead.
[19:08] <pitti> ev: ok; at least it's not through your own hand then :)
[19:09] <ev> indeed
[19:21] <Keybuk> psusi: I'm afraid I can't take the credit ;)
[19:21] <Keybuk> ion wrote that code
[20:03] <pitti> Laney, directhex, hyperair, RAOF: we are currently trying to get rid of the obsolete xulrunner-1.9.2 (discontinued upstream, open security holes), see bug 740815; the one remaining rdep is libgluezilla, which is only needed by libmono-webbrowser0.5-cil, which is only needed by libmono-cil-dev and libmono-winforms2.0-cil
[20:03] <ubottu> Launchpad bug 740815 in xulrunner-1.9.2 (Ubuntu) "[FFe] Updates to enable us to drop xulrunner from main" [High,In progress] https://launchpad.net/bugs/740815
[20:03] <chrisccoulson> pitti - xulrunner-1.9.2 isn't quite discontinued yet, but it probably will be soon
[20:03] <pitti> Laney, directhex, hyperair, RAOF: as libmono-webbrowser0.5-cil does not have any other dependencies, would it be possible to just disable this?
[20:04] <directhex> pitti: it will have no adverse effects on in-archive apps, but will prevent any apps written on Windows which use the WebBrowser widget from working
[20:05] <chrisccoulson> directhex, so, we don't have any applications in the archive using it?
[20:05] <pitti> directhex: I guess there is no way to use webkit for that?
[20:05] <pitti> chrisccoulson: if so, they should depend on it surely?
[20:05] <directhex> pitti: i can give you a slight improvement, a gluezilla snapshot which will build (but not run) against 2.0. well, it'll run until the garbage collector tries to work, at which point it'll go "clunk"
[20:06] <pitti> directhex: by "no way" I mean "already supported in the source", not "someone with infinite time could code it"
[20:06] <kees> micahg: wow... a _lot_ of packages have bad dependency_libs :(
[20:06] <chrisccoulson> directhex, the issue is that 2.0 will be unsupported 3 months after natty release
[20:06] <chrisccoulson> and we just can't realistically provide security support for it
[20:06] <pitti> directhex: we are eliminating xulrunner-2.0 from main as well, though
[20:06] <directhex> chrisccoulson: which is why i've been encouraging andreia to move from gluezilla to webkit-sharp to provide that widget. it's now possible with webkit 1.3, but only half finished
[20:07] <pitti> directhex: ah, it's great to hear that this is already underway, though!
[20:08] <directhex> she was going to push to git, let me see if she did
[20:08] <chrisccoulson> thanks
[20:09] <directhex> i've pinged her
[20:09] <directhex> she did mention something about the webkit gir files being wrong, though
[20:10] <pitti> directhex: oh, mono is using GIR and GI now?
[20:10] <pitti> directhex: perhaps you can get her in contact with me, I might be able to help fixing up the annotations
[20:10] <directhex> pitti: there are a few efforts underway to produce (for now) static bindings from .gir source, by converting from gir to mono's gobject codegen format (gapi)
[20:10] <pitti> directhex: I did quite some GTK and other library annotation fixes in the past
[20:11] <pitti> directhex: awesome; that's similar to the current vala approach
[20:11] <pitti> directhex: fixing the webkit gir would be useful for other areas as well
[20:12] <pitti> directhex: perhaps she could file a bug somewhere and subscribe me?
[20:12] <directhex> pitti: i'll try to get her in direct contact with you, once she shows signs of being online
[20:12] <pitti> directhex: cool, thanks
[20:12] <directhex> pitti: she's in .pt timezone, so that shouldn't be too difficult to do
[20:12] <pitti> Portugal?
[20:13] <directhex> yeah
[20:13]  * pitti toddles of for some late dinner at last
[20:14] <directhex> yeah, i need to go cook
[20:15] <chrisccoulson> directhex, pitti - thanks!
[20:15] <directhex> chrisccoulson: i hoped it had a little more time for this one. i first noticed there was an imminent issue when rebuilding gluezilla against xulrunner in debian experimental
[20:16] <directhex> although the debian mono team has always advocated s/xulrunner/webkit/ for everything we do, since the binding is so much cleaner. apparently this wasn't possible for replacing gluezilla due to lack of DOM access, until webkit 1.3 added it
[20:17] <chrisccoulson> yeah, webkit seems more supportable right now
[20:17] <directhex> i've been bugging andreia to move gluezilla to webkit for about 2 years now ;)
[20:18] <slangasek> kees: yeah, I'm cleaning up libgd2 just now, so I can finish fixing the php5 ftbfs.  Are you looking into the bad dependency_libs problem as a whole?
[20:19] <kees> slangasek: I am, yes.
[20:19] <kees> slangasek: I have _34_ packages in the archive that ship .la files with dependency_libs listing /usr/lib/libjpeg.la
[20:19] <slangasek> kees: we obviously want to prioritize the ones that point at .la files that have moved for multiarch... right, like those :P
[20:19] <slangasek> 34 source or binary?
[20:19] <kees> binary. source is...
[20:20] <kees> 28
[20:20] <kees> 7 in main
[20:20]  * slangasek nods
[20:21] <RoAkSoAx> howdy, is there a tool that checks if the dependencies for a certain packages are already in main?
[20:21] <RoAkSoAx> or to see if all the packages in a seed are in main?
[20:21] <kees> anyway, I have an optimized archive searching tool that can find these, so I can try just handing it a list of all the libs that are multiarch now
[20:21] <slangasek> kees: cool - would love to have at that list
[20:22] <slangasek> 28 is probably too many to want to fix up properly, we might just fire some no-change rebuilds to get this unblocked
[20:22] <kees> slangasek: I'm going to build a list of the shipped .la files in multiarch libs and then from there generate the list of packages listing them...
[20:23] <slangasek> ok
[20:23] <slangasek> I was thinking in terms of : grab the list of multi-arch: same libs; grab all -dev packages that are reverse-dependencies of those libs; grab all -dev packages that are reverse-dependencies of those, and look for non-empty dependency_libs
[20:23] <kees> slangasek: a no-change rebuild will fix up the paths, but not really solve the problem ultimately, right?
[20:24] <slangasek> correct
[20:24] <kees> http://paste.ubuntu.com/585027/ <- my work plan
[20:25] <slangasek> yep, that can also work
[20:25] <slangasek> and will pick up those -dev packages that are broken because they don't actually have deps on the other -dev packages
[20:25] <slangasek> like libjasper
[20:25] <kees> yeah. grr :)
[20:29] <kees> slangasek: do you have a la-cleaner snippet for "classic" debhelper? I've only found dh(1) and cdbs
[20:29] <slangasek> kees: Debian bug #619210 for an example
[20:29] <ubottu> Debian bug 619210 in meanwhile "meanwhile: please wipe out dependency_libs from .la files (Policy 10.2)" [Normal,Open] http://bugs.debian.org/619210
[20:29] <kees> thx
[20:31] <kees> hm, maybe I'll use $$(find debian/tmp/usr/lib -name '*.la') ...
[20:33]  * slangasek reads over that bug report and goes cross-eyed.  "As long as meanwhile"? Stupid plain english package names
[20:33] <slangasek> kees: yeah, that's more future proof; otoh it's a minor thing to fix up the path when multiarch arrives
[20:33] <slangasek> frankly, it's libtool - whatever stops it is good enough IMHO ;)
[20:34] <kees> can't we fix libtool instead?
[20:34]  * slangasek waves his hands vaguely
[20:34] <slangasek> part of the problem is that libtool is embedded in upstream software releases
[20:34] <kees> yeah, I figured "no" since it could break non-distro builds
[20:34] <kees> yeah
[20:43] <mvo> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | 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: smoser
[20:48] <slangasek> lool: Debian bug #458851 is a problem for avahi multiarchification.  what would you recommend here?
[20:48] <ubottu> Debian bug 458851 in libavahi-common-data "Ships arch-dep file in /usr/share" [Minor,Fixed] http://bugs.debian.org/458851
[21:06] <RoAkSoAx> cjwatson: howdy! You might be able to help me. I need to know if all the packages(and dependencies) of a seed (UEC) are in main.  Is there a tool that allows me to do that?
[21:08] <hallyn> jbernard: hey, are you familiar with the libcgroup security update in squeeze?  I just did a 'bzr branch lp:debian/squeeze/libcgroup' but don't see the claimed fix...
=== sconklin is now known as sconklin-gone
[21:23] <cjwatson> RoAkSoAx: everything in the ubuntu.natty seed collection (which contains uec) is either in main or will show up as a candidate for promotion on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[21:26] <sladen> cjwatson: is there anything that uses connman.  There a request for a missing icon, but if it's not shipped somewhere as a default and not subject to UI freeze I won't bother
[21:26] <cjwatson> sladen: it's in universe; if there is, it can't be anything we ship by default
[21:26] <slangasek> lool: disregard, --libdir is automatically putting the db file in /usr/lib/<triplet>, so I guess it can be M-A: same
[21:30] <lool> slangasek: Eh ok
[21:30] <lool> slangasek: was just closed apparently?
[21:31] <lool> From unknown Thu Mar 24 21:12:03 2011
[21:31] <lool> slangasek: sjoerd just closed with an upload
[21:31] <slangasek> that's weird
[21:31]  * kees wonders why lintian doesn't scream about dependency_libs
[21:31] <slangasek> lool: I didn't even notice that, I was looking at a comment you made about this bug in an /old/ changelog :)
[21:32] <slangasek> lool: indeed, the closure is from 2008
[21:32] <slangasek> really, the question was whether to move this file to the multiarch dir or to figure out how to make it arch-indep
[21:32] <slangasek> the naive solution does 1) for me, so I'm happy
[21:32] <pitti> RoAkSoAx: I checked bug 738757, will take care of it
[21:32] <ubottu> Launchpad bug 738757 in hdparm (Ubuntu) "spindown settings lost on pm-suspend indirectly affects powernap power savings" [Undecided,Triaged] https://launchpad.net/bugs/738757
[21:33] <bdrung> pitti: i can't install libtextcat-dev, because it wants to install libtextcat-data and remove libtextcat-data-utf8, which leads to a libreoffice removal
[21:34] <pitti> bdrung: -utf8 is gone indeed; we currently have a libo rebuild going on which ought to fix that, though
[21:35] <bdrung> ok, thanks
[21:38] <kees> slangasek: 119 source packages need dependency_libs cleaning. 20 in main. (minus 2, since you just did libgd2 and I just did jasper)
[21:39] <slangasek> kees: manageable.  Where's the list?
[21:39] <kees> http://paste.ubuntu.com/585057/
[21:39] <slangasek> kees: which end of the alphabet do you want to start from? :)
[21:40] <kees> djvulibre fontforge imlib2 libgphoto2 libwmf are already on my list due to libjpeg6b upload breakage
[21:40] <slangasek> ok, I'll start from the tail end then
[21:42] <RoAkSoAx> pitti: awesome! thank you!
[21:43] <RoAkSoAx> cjwatson: ok thanks ;)
[21:43] <RoAkSoAx> win 21
[21:43] <RoAkSoAx> arg
[21:45] <kees> /usr/share/cdbs/1/rules/clean-la.mk:38: *** missing `endif'.  Stop.
[21:45] <kees> aaarg
[21:48] <pitti> weird, when did that break? we ahve used clean-la for ages
[21:48] <pitti> ah, r192
[21:48] <pitti> kees: want me to upload a quick fix?
[21:49] <pitti> or are you at it?
[21:49] <kees> pitti: I'm stuck in some other things; if you have it handy, that would be great
[21:53] <bdrung> doko: bug #742092
[21:53] <ubottu> Launchpad bug 742092 in lintian (Ubuntu) "lintian FTBFS" [High,New] https://launchpad.net/bugs/742092
[21:58] <shana> evening
[21:58] <directhex> moo!
[22:01] <shana> aah!
[22:01]  * shana pokes cow
[22:01] <shana> so
[22:01] <shana> who do I need to poke?
[22:01] <shana> pitti?
[22:02] <pitti> hello shana, how are you? you are the mistress of mono webkitification?
[22:02] <shana> yesh
[22:02] <pitti> pleased to meet you :)
[22:03] <pitti> shana: directhex mentioned that you had some trouble with the webkit gir, and I wondered if I could help out
[22:03] <shana> I was appointed the browser bindings mistress as a consolation prize for not working on the moonlight hackathon back in 2008
[22:03] <shana> yeah, all the parameter names on signals are wrong
[22:04] <shana> for instance, <glib:signal name="hovering-over-link"> has <parameter name="object" transfer-ownership="none">
[22:04] <shana> note the "object" name on the parameter
[22:05] <shana> all parameters seem to follow the pattern "object", "p0", "p1", "p2", etc
[22:06] <pitti> shana: that sounds like default names due to missing annotations indeed
[22:07] <pitti> shana: do yo know if there is a bug report for this already, perhaps even with a small test case?
[22:07] <shana> I just stumbled upon it last night, haven't opened any bugs on it yet
[22:08] <pitti> shana: I'm about to go to sleep, and won't have time tomorrow, but I think I could work on that next week
[22:08] <shana> I just finished fixing up the gir for 1.3 with the proper names, some signals are hard to figure out
[22:09] <shana> pitti: cool cool
[22:09] <pitti> kees: there, fixed cdbs
[22:11] <shana> pitti: I can get you versions of the 1.2.5 and 1.3 gir files with correct names, if it helps
[22:12] <kees> pitti: great, thanks!
[22:12] <pitti> shana: you hand-edited them, or you patched the source to build them correctly?
[22:12] <shana> hand-edit, haven't had time to go through the source yet to fix it
[22:13] <directhex> i couldn't even see where the gir is generated in the webkit source
[22:13] <pitti> shana: it certainly can't hurt, then at least we could compare the autogenerated one to your's
[22:13] <directhex> there's no .gir.in or anything fancy like that
[22:13] <shana> pitti: do you want me to open up a bug somewhere?
[22:13] <pitti> directhex: no, it's generated from the source .c files (or .cpp)
[22:13] <pitti> shana: that would be useful, with above example signal (and attach your files there)
[22:13] <shana> nod
[22:14] <shana> where?
[22:14] <pitti> much easier for tracking
[22:14] <pitti> shana: upstream or launchpad, whatever you prefer
[22:14] <pitti> we'll need an upstream bug eventually anyway, of course
[22:14] <directhex> i wonder if anyone in the office knows about this issue
[22:15] <shana> oh man, I haven't been to webkit's bugzilla in such a long time
[22:15] <pitti> oh man, most critical bug ever -- stop shipping webkit! https://bugs.webkit.org/show_bug.cgi?id=19371
[22:15] <ubottu> bugs.webkit.org bug 19371 in Evangelism "WebKit Needs T-Shirts" [Enhancement,New]
[22:15] <shana> seriously?
[22:16] <shana> hehe
[22:16] <pitti> shana: I can't find an existing upstream bug report, anyway
[22:16] <shana> I don't think anyone is really using gir actively
[22:17] <pitti> shana: well, we do in Ubuntu now
[22:17] <pitti> shana: we have about 6 packages ported from pygtk to pygi
[22:17] <pitti> more to come in oneiric
[22:17] <shana> I still don't quite understand why there's virtual-method and glib:signal nodes for the same things
[22:18] <shana> where's the xsd for the gir format?
[22:18] <seb128> GNOME3 does as well, well for a definition of  'actively', they don't use python a lot
[22:18] <pitti> shana: http://www.piware.de/tag/gobject-introspection/
[22:18] <pitti> seb128: they do use it with javascript, though?
[22:19] <pitti> shana: I don't think they have a schema
[22:19] <seb128> pitti, well, they have the gnome-menus gmenu-simple-editor or some applets ported to gi pygtk3
[22:19] <pitti> seb128: I thought gnome-shell is all over this stuff
[22:19] <seb128> rather "pygobject gi gtk3"
[22:19] <seb128> pitti, right, it is, I was speaking about python gi
[22:19] <shana> it's a shame people don't rely on schemas, you can do some really nice things with xsd
[22:19] <seb128> pitti, g-s is gjs and gi indeed
[22:20] <shana> like generate instant parsers
[22:20] <shana> anyways
[22:21] <shana> pitti: why virtual-method and glib:signal for the same thing (but not all)? what do they represent exactly?
[22:21] <pitti> shana: I don't know details about these virtual-method thingies either, I'm afraid; the ones I saw were not something I'd ever call from a binding
[22:22] <shana> hmmm
[22:22] <shana> I need to figure out who's responsible for gir
[22:22] <shana> if this thing is going to be a standard way of describing apis, it better be well nailed down
[22:22] <pitti> #introspection on irc.gnome.org would know (in particular, J5 and tomeu)
[22:23] <shana> ah, thanks!
[22:23] <shana> pitti: I'll let you know about the webkig bug when I open it, bit on the tired side now :)
[22:23] <directhex> aha, i knew i'd be able to blame someone at work
[22:24] <shana> directhex: who?
[22:24] <pitti> shana: thanks
[22:25] <shana> in the meantime
[22:25] <shana> webkit# bindings for 1.2.5 and 1.3 are almost done here
[22:25] <directhex> shana: tomeu is a collaboran
[22:25] <shana> and gluezilla is dead
[22:25] <shana> well, suffering
[22:26] <shana> directhex: aaaah, fingers to point, that's good :)
[22:29] <directhex> shana: i've relaid your complaint on our internal irc ;)
[22:30] <shana> yayness :)
[22:31] <directhex> reaction from kov, that's a good sign
[22:31] <shana> I wish I was there when it was drawn up, the multitude of non-default namespaces makes for very verbose xpaths
[22:32] <shana> but I do like the way it turned out
[22:33] <shana> minus the quirky signals thing
[22:36] <pitti> shana: oh dear, http://launchpadlibrarian.net/66063126/buildlog_ubuntu-natty-i386.webkit_1.3.12-0ubuntu3_BUILDING.txt.gz shows two metric tons of annotation errors
[22:37] <seb128> pitti, check with kov on #debian-gnome maybe if there is any work going on on that before starting
[22:37] <pitti> but I still don't see an obvious error in the annotation
[22:37] <directhex> each error weighs 4.29184549?
[22:37] <pitti> seb128: yeah, will doo
[22:37] <slangasek> pitti: cdbs> ah, missed that other ifndef up top, mistook the endif there for one I'd added :/
[22:37] <directhex> kg, that is
[22:37] <pitti> but before I'll get some sleep :) good night everyone!
[22:37] <shana> missing transfer annotations
[22:37] <seb128> pitti, he's maintaining webkit in debian and working on it upstream as well
[22:37] <seb128> 'night pitti
[22:37] <shana> those are important :P
[22:37] <pitti> shana: yeah, all those will turn out to be not introspectable (i. e. not usable from bindings)
[22:37] <directhex> seb128: kov implies it's not been seriously worked on
[22:38] <seb128> ok
[22:38] <shana> well, I ignore missing transfer annotations currently
[22:38] <pitti> shana: but that doesn't affect signals
[22:38] <pitti> shana: hmm, that sounds kinda dangerous
[22:38] <shana> they're important for strings, for other objects not as bad
[22:39] <shana> as in, things don't blow up for non-strings if the annotation is missing
[22:39] <shana> but it's not good
[22:39] <pitti> how so? treating "full" for "none" is a crash, treatin "none" for "full" is a memleak
[22:39] <shana> exactly, they don't crash
[22:39] <pitti> so just eating tons of memory then?
[22:39] <shana> doesn't mean it doesn't leak and that's bad
[22:39] <shana> engxactly
[22:40] <shana> which is bad on a level 4.5, blowing being level 5 bad
[22:40] <pitti> heh
[22:40] <pitti> shana: what's the worst level on that scale?
[22:40] <shana> I think that, in webkit's case, all those missing annotations are full
[22:40] <shana> since webkit returns loose objects on the dom
[22:41] <pitti> shana: stuff like webkit_dom_node_get_previous_sibling() is almost certainly "none"
[22:41] <pitti> it would be very weird to return full copies during iteration
[22:41] <shana> or none, orry, I might be confused
[22:41] <shana> webkit returns shallow wrappers that can be disposed off at any time
[22:41] <shana> iirc
[22:42] <shana> it's not the actual real dom object, it's just a disposable accessor
[22:42] <pitti> ah
[22:42] <shana> which is totally annoying when you're trying to compare objects
[22:42] <shana> I had to hack up a solution for that on moonlight for chrome
[22:43] <shana> if there's a standard ownership for returned dom objects on webkit, even if the annotations are missing you can assume an ownership value on the gir
[22:43] <shana> I don't know, I haven't eaten for a few hours and my brain is starting to go, so don't take my word for it :)
[22:44] <pitti> shana: so, when I resume work on this I'll talk to kov?
[22:45] <pitti> shana: I can certainly give a hand with fixing the annotations, but I'd like to coordinate this to get the patch merged quickly (as it'll be quite large and thus will bitrot quickly)
[22:45] <pitti> shana: as for the signal ones, that needs a deeper look (and a built tree), will do that next week
[22:45] <shana> kov does gir, right?
[22:46] <pitti> shana: well, it was you who brought him up, wasn't it?
[22:46] <shana> that was directhex
[22:46] <shana> I think
[22:46] <shana> :D
[22:46] <pitti> shana: the gir gurus are mostly tomeu and J5, but there's a lot more people involved, of coruse
[22:46] <shana> I think we're a bit too tired for this conversation :D
[22:47] <shana> when you have the time to fix up the annotations, ping me and we'll coordinate
[22:48] <shana> I think it might be useful for projects of this size to have a global default annotation for ownership that would be assumed for all methods unless otherwise defined there
[22:50] <pitti> shana: I think webkit is a bit of a special case here due to the magic accessors, but it would be handy here indeed
[23:03] <slangasek> kees: I think your search missed a few; I can't rebuild pacemaker to clear its .la because cluster-glue also has broken .las and is a build-dep of pacemaker
[23:04] <slangasek> (and cluster-glue is not in your list)
[23:06] <kees> slangasek: hrrrm
[23:06] <kees> slangasek: ah, I only looked at packages named -dev
[23:06] <kees> let me see what happens if I invert the list
[23:12] <kees> yikes, this is a long list
[23:12] <kees> only up to "e"...
[23:14] <slangasek> invert it?
[23:24] <kees> slangasek: "not -dev"   http://paste.ubuntu.com/585103/
[23:24] <kees> slangasek: those are the source packages that ship binary packages in main not ending in "-dev" with offending .la files
[23:25] <kees> slangasek: however, I see that cluster-glue is still missing
[23:29] <slangasek> kees: well, cluster-glue's binary packages end in -dev anyway
[23:29] <kees> weird.
[23:29] <kees> egrep '^dependency_libs=.*lib(acl|atk-1|attr|db-4|db_cxx-4|db_java-4|curl-nss|curl|expat|expatw|freetype|gdbm|gdbm_compat|gio-2|glib-2|gmodule-2|gobject-2|gthread-2|gnutls|gnutls-extra|gnutls-openssl|gcrypt|gpg-error|jpeg|tasn1|pango-1|pangocairo-1|pangoft2-1|pangox-1|pangoxft-1|sqlite3|tiffxx|tiff|udev|gudev-1|ossp-uuid\+\+|ossp-uuid).la' $(find . -name '*.la')
[23:29] <kees> ./stonith/plugins/stonith2/drac3.la:dependency_libs=' /usr/lib/libcurl.la -lbz2 /usr/lib/libxml2.la -lc -luuid -lrt /usr/lib/libglib-2.0.la /usr/lib/libltdl.la -ldl'
[23:29] <kees> it certainly hits.
[23:30] <kees> back later...
[23:30] <kees> imlib2 hates me. won't build even before changes.
[23:30] <kees> taking a break for a bit.
[23:32] <slangasek> heh, heartbeat is /also/ a build-dep of pacemaker, right
[23:32] <slangasek> guess I'll be doing that whole cluster
[23:32] <jbernard> hallyn: you should see patches in debian/patches for CVE-2011-1006 and CVE-2011-1022
[23:32] <ubottu> Heap-based buffer overflow in the parse_cgroup_spec function in tools/tools-common.c in the Control Group Configuration Library (aka libcgroup or libcg) before 0.37.1 allows local users to gain privileges via a crafted controller list on the command line of an application.  NOTE: it is not clear whether this issue crosses privilege boundaries. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1006)
[23:32] <ubottu> The cgre_receive_netlink_msg function in daemon/cgrulesengd.c in cgrulesengd in the Control Group Configuration Library (aka libcgroup or libcg) before 0.37.1 does not verify that netlink messages originated in the kernel, which allows local users to bypass intended resource restrictions via a crafted message. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1022)
[23:34] <hallyn> jbernard: hm, maybe the bzr tree didn't get updated
[23:35] <jbernard> hallyn: very possible; the patches are in squeeze currently
[23:36] <hallyn> jbernard: ok, i'll dget it.  thanks.
[23:36] <hallyn> jbernard: oh, well - were you already planning to merge those into ubuntu's packages?
[23:36] <hallyn> (i'd like to get the natty one in asap, obviously :)
[23:37] <jbernard> i can prepare a debdiff, i just need someone to sponsor the upload
[23:41] <hallyn> drat, that's not one of the ones i got access for :)
[23:41] <jbernard> perhaps just a sync-request is all that's needed?
[23:42] <hallyn> i think so
[23:46] <ohsix> oog icons keep changing
[23:49] <ohsix> so, this probably fixed 2 bugs i filed the other day https://bugs.launchpad.net/ubuntu/natty/+source/xorg-server/+bug/723905 what do i do with those bugs? close them or somehow point it to that bug?
[23:50] <ubottu> Ubuntu bug 723905 in xorg-server (Ubuntu) "Semi-multitouch devices should be disabled in Natty" [High,In progress]
[23:50] <hallyn> jbernard: yeah, natty is same as sid, so, cool.
[23:51] <sladen> pitti: slangasek: still have a few design-team originated non-code UI Freeze changes to push (#741804, #740579, #741813/#741862), but they aren't going to get done in 10 minutes.  So I'm going to sleep on it for a bit.
[23:54] <cjwatson> bryceh: is there a bug# for this fglrx black-screen-on-VT-switch bug?
[23:58] <ohsix> cnd: oh, it was you i was talking too; kudos! :D